The ugly truth: Satan, social networks and security

Summary:Here's the simplest way to get arbitrary code execution in the browsers of millions of users -- ask for permission.

* Jennifer Leggio is on vacation

Guest editorial by Shawn Moyer and Nathan Hamiel, who presented “Satan is on my Friends List: Attacking Social Networks” at BlackHat and Defcon earlier this month.

Satan, social networks and security
Ultimately, we blame Jeff Moss for all of this. Earlier this year, the founder of Black Hat and Defcon asked the security community to join the Black Hat and Defcon LinkedIn groups. To our own occasional chagrin, we're both very active users of social networks (hereafter SocNets, easier to type and we're not being paid by the word), so we found ourselves compelled to join but also a bit skeptical. Would a bunch of paranoid-by-nature and paranoid-by-profession hackers and security professionals fly the SocNet flag and buddy up? No way, right?

Well, both groups have just under 2,000 members at this point, so it looks like the answer is a resounding yes. If a pretty broad sample of InfoSec folks are using SocNets, it seems to stand to reason that things must be improving on the SocNet security front now, right? We couldn't really say for sure. We both had a gut feeling, but wanted to have a better idea of how bad (or, yes, even how good) things really were.

A few months later, at Black Hat and Defcon were pretty flummoxed by the response to what ultimately was a silly talk about privilege escalation on Adult Friend Finder, performing the MySpace equivalent of K-Lining, and using social engineering to poke some fun at journalists and the security blogosphere.

Still, as SocNets and social media become more and more a part of our daily lives, and as the race to go to market and to gain marketshare continues, we think SocNet security will continue to become a larger problem, and recent activity seems to show that the appeal of a large and active userbase as a target for the malware industry is hard to ignore.

Further down the rabbit hole, in which we find some ugly things So, rewinding a few months back... Talk submitted to Defcon and Black Hat, check. Nathan and Shawn working on projects in the same city for a couple of months, check. Cider and box wine acquired, check. We fired up our interception proxies, passive audit tools, a few other toys, cranked up "Waiting Room", and prepared to sequester ourselves a few nights a week for a couple of months, to see what things looked like across the board.

We found our first exploitable bug in around a half hour, on the first SocNet we looked at. This became something of a theme, and we found ourselves pretty disappointed each night if the booze ran out (or it got too late) before we found something troubling, or at least interesting. We both do Web app security testing, mostly for larger ecommerce sites, in our day jobs, and so looking at an architecture as trusting and open as a social network was kind of like playing slow pitch softball over beers in the park after trying to strike out Albert Pujols for nine innings.

The above is certainly not to say that we're ninjas, security masterminds, or anything of the sort. There are lots of very smart people (none of which are us) looking at Web application security. What we found, though, is that attacking someone via a SocNet, or at least via a lot of the SocNets we looked at, often didn't require Javascript filter ninjitsu, multi-stage payloads, or even, at least in our case, a modicum of sobriety. Did we mention we'd been drinking?

Ugly things enumerated: SocNet apps For those taking notes, here's the simplest way to get arbitrary code execution in the browsers of millions of users (no exaggeration — the top SocNet applications on Facebook and MySpace have 21 million and 8 million users, respectively) suitable for BotNet propagation, phishing, pharming, click fraud, DoSing, a fully meshed global RickRolling spam farm, or some other purpose so nefarious we couldn't imagine it ourselves, despite considerable effort and numerous demonic incantations.

Just ask for permission.

Specifically, go through the trivial process of signing up to be a SocNet App developer. On Facebook permission to publish an app means having five friends, on MySpace it means filling out an application form (ours claimed we were working on a messaging system using the "unbreakable ROT13 encryption algorithm"), and providing a few easily-forged bits of personal information. Signing up to develop apps on SocNets is a shockingly trivial process, and results in being given the keys to Dad's car and the liquor cabinet to boot, as it were.

Next: Ugly things won't improve anytime soon -->

To us, then, the most obvious route to mass exploitation via a SocNet seems to be creating an app that gains a large installed base, waiting a few months, and then "going rogue" and delivering a malicious payload. A trojaned SocNet app is especially effective since it doesn't actually require a user have the app installed, just that someone views the profile of a user with the app installed. So, an evil app doesn't just make it possible to attack each user that installs it, but also (because of the interconnectedness hardwired into a SocNet), every connection (and potential connection) the victim might have.

The funny thing to us about how astoundingly bad SocNet Apps are from a security perspective (without even touching on the laundry list of problems in even legitimate apps themselves, as detailed very well by TheHarmonyGuy) is how little the defenses SocNets have built take this attack surface into account. As attackers, why do we care if Javascript is stripped from comments, if apps run in a separate execution domain, if all requests are tokenized against CSRF? We can just compromise the client, via a trojaned application, and have full control of the desktop for any purpose we wish.

Which brings us to an interesting point. The security architecture around SocNet apps does do one thing quite effectively. It protects the apps themselves from the SocNet providers. Unless Same Origin isn't enforced by client browser, ultimately an evil app can't directly attack the SocNet itself, because apps are sandboxed away in a different execution domain. This does little to protect the user from the app, but it does a lot to provide plausible deniability while still allowing developers to create (and users to install) SocNet apps, which (EULAs notwithstanding) appear to have a defacto endorsement from the SocNet and execute on the user's profile page as a component of the user experience.

Ugly things further enumerated: offsite content = Fail For sites that allow HTML markup, image tags, custom stylesheets, and arbitrary linking to external content in comments or in profiles, it's pretty much game over. The SocNet is placing the trust for where the browser goes and what it does in the hands of an external party. This could be used in many different ways, from the straightforward route of linking to malware like the recent comment spam posing as a Flash update, mentioned earlier, is doing, or in more subtle ways like silently surfing other sites for click fraud, or installing malware in the background.

Many sites restrict obvious things like inserting "<SCRIPT>" tags, but there are scads of ways to get content inserted, so allowing users control of both markup and arbitrary offsite content seems like a surefire recipe for failure. A quick (and very much incomplete) hall of shame here includes MySpace, LiveJournal, and Hi5, all of which we're surprised haven't sunk into the East Bay under the weight of their own pwnability. Nathan went into some further detail on his blog about using offsite content on SocNets for request forgery, specific to MySpace, so take a peek if you're interested in more detail.

Ugly things that won't improve any time soon: The Culture of Trust A final source of exposure is one that isn't entirely the fault of SocNets (though a pervasive culture of information sharing is certainly baked in to their business model) — it's the users themselves. And ultimately this is a tough one to solve. We don't sign on to SocNets to lurk and be unapproachable, we sign on to find friends, communicate, and interact, which makes being part of a SocNet so addictive, but it's also why any SocNet attack that integrates a Social Engineering component or utilizes "trusted" connections as a vector is very likely to be effective.

Our recent impersonation exercises on SocNets have been documented ad infinitum, so there's not much point in beating a dead horse. Suffice it to say that if you haven't personally contacted and spoken face-to-face with everyone on your connection list, right now may be a good time to confirm that none of them have, for instance, horns and a vestigial tail.

Shawn Moyer and Nathan Hamiel are both senior security consultants, but for two different consultancies. They worked together briefly for the same client and spent some time planning the apocalypse and presented the talk “Satan is on my Friends List: Attacking Social Networks” at Black Hat and Defcon a few weeks back. They can be reached on a number of SocNets, or emailed at zdnetbloggything [at] agurasec døt cøm.

Topics: Apps, Networking, Security, Social Enterprise

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.