Protecting Against Common Risks in Social Networking

Social Networking sites are all the rage. I'm not going to reprise them all - Wikipedia has a good article if you don't know what I'm talking about generally - but I will centre this article around person-centric portal sites like Facebook and LinkedIn since I have more personal experience with both.

Generally, people are more socially vulnerable than social networking sites are technologically vulnerable. Many interpersonal interactions are safeguarded by the lack of scalability when dealing interactively with people. Unless you are a famous person you're unlikely to draw a crowd, and the communication is highly transient - it's only audible when it is spoken.

Email extends the "phosphorescence" attribute of spoken communications -- Abosolute fidelity of 17% of the message. I myself have archived emails going back to 1992, and Google desktop lets me find out what you "said" to me 5 years ago, with insane ease. I once used to describe the first social networking applications - public Fidonet Echos and Usenet newsgroups - as "email for the world to see".

The advent of Dejanews (now Google Groups) made it "email for the world to see forever". Social network sites typically make even the slightest and most flippant communications public forever. This is not good for all people; and that's a function of a person's behaviour.

Risks can be managed to an acceptable level by following better-than-default practices offered by these sites. Educating one's self and adhering to safe behaviours when using a social networking site can allow a good experience and still realize many benefits of social networking. Some of the larger risks when using social networking come from these practices:

• Believing that never logging into a social networking means you don't have an identity on it.
  Instead, consider signing up on the most popular sites and protect your identity. Even if you don't plan to use it, this ensures others won't be able to target you.
  
• Extending trusts to identities as if the identity were the person.
  Instead, attempt to validate the electronic identity though some other means besides the medium you are on. Voice, in person, alternate email address, are all reasonable ways to validate identity without blind faith.
  
• Using the default permissions to implement a simple model of "trusted/not-trusted".
  Instead, implement a multilevel "rings-of-trust" model where you have at least 3 levels of friends, colleagues, associates, acquaintences, strangers, each with progressively fewer permissions. This inherently limits the personal information and aligns with a better, albeit less-than-perfect, real-world trust model.
  
• Posting detailed and personally identifiable information online, believing you will always own and control it.
  Limit how much information is released.
  Canadians are not protected by PIPEDA or other statutes on most of these sites. Consider the information posted as permanent. Needless facts mistakenly published have a phosphorescence of years. Sometimes intellectual property rights are given away when using these sites.
  
• Trusting all application content from a social networking site.
  Use a browser with selectable active scripting such as noscript. Be aware that not all applications available within a social networking site are an intrinsic or trustworthy part of it. Be skeptical and investigate the privacy and security of data when using new applications on social networking sites.

Many will look for the next "firewall" or "anti-this" tool to manage social networking sites. Unfortunately, you can see that many of these risks are difficult to safeguard with new technology. Using common real world practices that protect you, your family and your job from abuse in real life go along way in the blurry border that is real live online life.

W

Legitimate websites face new threats: More viruses spread through trusted

"Legitimate websites face new threats: More viruses spread through trusted hosts"

Active content and so called "Web 2.0" sites are a very rich medium for attack. The sites make heavy use of distributed program code, which is given increasing access to Windows desktops. "Active Content" is the name given to programs that automatically execute (in some limited container) on user's PCs.

Most "sites " today deliver content from many 3rd party destinations. This trend began with ad servers in the late 90s. The type of content being served is also changing. Animated GIFs have long given way to Flash, ActiveX , Java and Javascript. This has more recently extended to 3rd party applications designed to plug into, and pushed by Facebook and similar functionality sites.

The gravity of the threat of active content is exacerbated by browsers allowing users to grant omnibus trust relationships between the remote web site and the local browser, by the vulnerabilities in the container and finally by the deftly-constructed nefarious code. Users are unintentionally and naively extending trust to unknown content. In the chain of trust, very little inspection or approval is performed of the code to be executed remotely. The main driver is deriving advertising revenue dollars derived from a user's subliminal feline desire to click on those flashy moving objects.

The Setup: Application Layer Attacks on "Trusted" Servers

On the server side, my own FHLSim.com Forum site has been hit with a few of these automated application attacks in the past couple of years, and with increasing sophistication. They do not "infect" the host; they manifest inside the application which resides on the host.

In my case, they were able to subvert the stock captcha supplied with PHPBB, eliminating the Forum's ability to differentiate robots from humans. The threat created hundreds of fake accounts and posted spam on the message board. The spam linked to all kinds of exotic sites designed to entice visitors, increase page-rank counts on Google and ultimately make more money. This was fairly benign payload but involved a lot of cleanup, patching, and some custom modifications to the stock software -- including switching to recaptcha. In the worst instances, the message board is compromised, administrator access to the application (NOT the HOST OS) and messages, users and data are deleted from the database in behind the website. None of this can be prevented by widely-deployed omnibus safeguards such as firewalls or intrusion detection systems.

The Problem: Transitive Trust

Back to application exploits at the client site. Malicious active content is happily executed in most browsers since the site is "trusted". The root cause is the issues of transitive trust. Essentially, a user's implied-and-absolute trust in a remote site is re-delegated to a 3rd party site. This site re-delegates that trust again to an unscrupulous or ignorant author and his code. The absolute trust delegated downward does not necessarily diminish in each re-delegation. The last party is motivated by money, and often ignores writing code in a secure fashion because it delays the speed with which they can "get to the money".

The Defense: Knowledge, Awareness and Tools

There are effective safeguards available to reduce the risk to web users:

• Use a browser that can provide fine-grained control over what Active content runs within the browser is the first.
  
• Mozilla Firefox, equipped with the popular "NoScript" plugin is one example. Given a bit of self-education, users can control with high precision the active content executed from website.
  
• This allows one to visit a blog without having the blog site serve up malicious content. It is also handy as an ad-blocker!
  
• Windows Internet Explorer 7.0 also has some inherent permission limitations that prevent some threat manifestations. The biggest advancement is decoupling the browser from the Microsoft Windows OS itself.
  
• Ensure your antivirus software is enabled with on-access scanning. While they won't catch everything, they will catch most of the really bad stuff before it manifests.
  
• Enterprises should use Microsoft Windows Active Directory to enforce security templates, prohibiting or limiting the privileges available to active content from websites.
• Implement effective patch management settings to reduce the vulnerabilities exploited by these sites. Today's "release early, release often" paradigm of rapid software development make regular patching an imperative.
  

With 4 PCs and 5 non-expert web surfers (ranging in age from seven to 30-something), education about what sites should be trusted, supervision to police use and Mozilla Firefox with NoScript has kept the bad stuff off our machines.

W

Service-Oriented-Architecture Security: What's Old is New

"SOAP" is a descendant of XML-RPC, and is another in the procession of web-layer security technologies we IT security professionals must grasp. SOAP provides many benefits to technology. Let's make it real: one of the chief functions it allows is a remote procedure call performed using eXtensible Markup Language (XML) over HTTP over port 80 over TCP/IP from a client to a server, with the answer coming back over the same connection.

We know and love (or hate) XML for its bloated but readable messaging format, where keys and values are used like pastels for HTML text -- the operations for a remote peer application to perform on the text are contained in the key-value pairs that are inside the tags around the text.
ie: "Make this text "Hello world' bold" in HTML = Hello world

RPC's we know and hate because multiple services are piggybacked onto dynamic Layer 3 transports that are connection-context-dependent. We can't tell a firewall at Layer 3 to allow MS Windows to talk only the Exhcange protocol but not offer allow other networking services from those devices. Consequently one wants to block it - because who wants to be vulnerable to a worm originating from a desktop into their Exchange cluster?

XML-RPC and SOAP are the answer to this. Designed to get around firewalls they use HTTP
and so the inference is they are OK to pass. Firewall admins who indiscriminately pass this traffic across security perimeters miss the point of their firewall's existence.

ie: Here is part of a SOAP call illustrating how open it is compared to binary protocols like CORBA/IIOP or DCOM/DCE-RPC.

<getStats xmlns="http://hockeystats.example.com/ws">
<goalieid>827635</goalieid>
</getstats>

There are inherent weaknesses in a perimeter where the enforcement device is unable determine what two peers are swaying to eachother when the speak across a security boundary. The intermediary device is unable to enforce the desired security policies within the protocol. So the peers have unencumbered reign over what information is exchanged between them, rendering the firewall useless. A firewall incapable of containing and managing risk is not meeting its security objective.

So why not just have the enforcement device learn the language and parse the traffic then? The issue is that the higher up the stack we go, the more compute time is required to decode the traffic, and also much more state information to track. This causes performance issues, solved by money and more hardware. The chief barrier is the lack of security policy definition to the precision these devices would need to understand.

Fortunately, many companies are unable to articulate enforcement of their security policies to that level of precision. This a recurring theme in IT security architecture even at layer 3 where I have some clients who years after a new firewall is implemented are unable to get their rules correct. So the security policies are enforced to a level that does not compromise performance of the network, but really that is simply a cover for the lack of precision with which an enterprise implements its security policy.

This has been a pretty simple battle in the past: productivity wins over security function. Perimeters have are brutalized to the point where their ability to reduce the exposure of vulnerable applications to threats has been gravely diminished. Enter IPS, which only kills the worst offending traffic known to be bad. However IPS does not enforce "least privilege", but only an incomplete policy: "Stop the known bad stuff we know about today." Enumerating badness is a trusty hammer. It works for screws too, but...

When serious management of security perimeters is required by the business, XML firewalls are a niche technology that solve this. As traditional firewalls are a TCP/UDP/IP layer big-brother to the application peer communications, XML firewalls perform a similar function to web services communications. XML firewalls are able to validate the XML calls between components in a distributed web services infrastructure. The security objective is to enforce security parameters which are missing or untrusted within the application itself.

This will get increasingly important as the shift back towards executing more on the client side within the browser using techniques like AJAX will make one peer much less trusted than the other. Sites leveraging those techniques will drive browsers to make XML calls directly to web application servers, rather than a simple HTTP request of a web server that causes a (the more trusted) web server to make those web-app calls themselves. It is inevitable as client-side issues with AJAX are already popping up.

More on the XML firewall technology capability in part two.