Risk
5/11/2011
12:54 PM
Connect Directly
RSS
E-Mail
50%
50%

Facebook Patches Access Token Leak

Users should change their passwords to mitigate threats posed by the accidental leak of perhaps millions of account identity details.

How Firesheep Can Hijack Web Sessions
(click image for larger view)
Slideshow: How Firesheep Can Hijack Web Sessions
Have Facebook advertisers and analytics firms been reviewing your private profile? On Tuesday, security researchers warned that, due to how the site handles access tokens, enterprising third parties would have been able to access users' private data and perform any actions with a user's identity, beginning in 2007.

"Third parties, in particular advertisers, have accidentally had access to Facebook users' accounts including profiles, photographs, chat, and also had the ability to post messages and mine personal information," said Nishant Doshi, a senior principal software engineer at Symantec, in a blog post. He discovered the flaw, together with Symantec's Candid Wueest.

Facebook has reportedly acknowledged and fixed the problem.

Whether anyone had exploited the flaw, however, remains an open question. "There is no good way to estimate how many access tokens have already been leaked since the release of Facebook applications back in 2007," said Doshi. "We fear a lot of these tokens might still be available in log files of third-party servers or still be actively used by advertisers."

To mitigate the threat posed by user credentials lingering in advertisers' log files, change your Facebook password. "Changing the password invalidates these tokens and is equivalent to 'changing the lock' on your Facebook profile," said Doshi.

The flaw resulted because of how Facebook iFrame applications handled access tokens. "Access tokens are like 'spare keys' granted by you to the Facebook application. Applications can use these tokens or keys to perform certain actions on behalf of the user or to access the user's profile," said Doshi. "Each token or 'spare key' is associated with a select set of permissions, like reading your wall, accessing your friend's profile, posting to your wall." Users grant specific permissions to an application when they install it.

But because of the way that Facebook validated tokens, it was also leaking data about those tokens to third parties. Notably, while Facebook now uses OAuth 2.0 to authenticate users, it also supports legacy authentication mechanisms, and thus must assess which type of authentication scheme is being used. During that process, Facebook would sometimes generate an access token by sending an HTTP request--containing the application token in the URL--to the application host. As a result, in some cases Facebook was literally sending its users' access credentials directly to advertisers.

Doshi estimates that almost 100,000 applications exhibited the token-leaking behavior, and that in the past few years, millions of access tokens could have been leaked. According to the social networking site, users install 20 million applications per day.

On a related note, on Tuesday, Facebook updated its developer roadmap. Notably, the roadmap now requires that all sites and applications that work on or with Facebook, by October 1, use only OAuth 2.0 for authentication, process signed requests, and use HTTPS, which requires that they obtain an SSL certificate.

"Over the past few weeks, we determined that OAuth is now a mature standard with broad participation across the industry. In addition, we have been working with Symantec to [identify] issues in our authentication flow to ensure that they are more secure," according to Facebook. "This has led us to conclude that migrating to OAuth & HTTPS now is in the best [interests] of our users and developers."

Facebook first began enabling SSL encryption across its site--but not requiring it for applications or providing it for mobile Facebook clients--in January, in the wake of the release of Firesheep, a free tool for hijacking Web sessions relating to a number of sites, including Facebook, for people using an unsecured wireless hotspot.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4973
Published: 2014-09-23
The ESET Personal Firewall NDIS filter (EpFwNdis.sys) driver in the Firewall Module Build 1183 (20140214) and earlier in ESET Smart Security and ESET Endpoint Security products 5.0 through 7.0 allows local users to gain privileges via a crafted argument to a 0x830020CC IOCTL call.

CVE-2014-5392
Published: 2014-09-23
XML External Entity (XXE) vulnerability in JobScheduler before 1.6.4246 and 7.x before 1.7.4241 allows remote attackers to cause a denial of service and read arbitrary files or directories via a request containing an XML external entity declaration in conjunction with an entity reference.

CVE-2014-6646
Published: 2014-09-23
The bellyhoodcom (aka com.tapatalk.bellyhoodcom) application 3.4.23 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2014-6647
Published: 2014-09-23
The ElForro.com (aka com.tapatalk.elforrocom) application 2.4.3.10 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2014-6648
Published: 2014-09-23
The iPhone4.TW (aka com.tapatalk.iPhone4TWforums) application 3.3.20 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Best of the Web
Dark Reading Radio