Security

Facebook API Abuse Can Expose Private User Data, Say Hackers

Facebook is ignoring a serious shortcoming in the way it limits application developers' access to information about Facebook users, according to a pair of hackers.

The problem is in the way Facebook's APIs (application programming interfaces) work, and could even lead to unauthorized password changes, according to hatter and ErrProne, two members of hacking think-tank Blackhat Academy.

Facebook applications use a special query language called FQL (Facebook Query Language) to extract and modify user information stored in the social network's database. This proprietary language is well documented and the information is public, allowing anyone to learn it.

Querying sensitive user information such as e-mail addresses through FQL requires an API key, a unique identifier Facebook attributes to each app, but a lot of other private information can be extracted from the database without any such restrictions. The two hackers even provided working proof-of-concept code in their advisory.

According to hatter, API keys have too much power from the moment they are issued, and obtaining one is simple. A malicious programmer could obtain and abuse an API key while the associated app was still in development. Applications have access to more data while in that phase, before they are released; after Facebook reviews an app, it will restrict its rights to allow access only to the data the app needs to function.

However, attackers don't even need their own API key to extract data. They can piggyback on the key of a legitimate app by installing it on their profile and feeding it information requests with altered user ids. Depending on the application's permissions, this technique can be used to gather information from other users with the app installed, even if those users only shared the information with their friends.

This sort of abuse would likely be detected quickly by Facebook's security team, but attackers would still have enough time to grab the information they want before being blocked. (See also The Paranoid's Guide to Facebook.")

Blackhat Academy notified Facebook of this issue over two months ago, according to Hatter, and the group decided to publish the details only because the social networking giant doesn't share its concerns.

A Facebook spokesman dismissed the claims, saying: "What this person calls an 'FQL Injection' is simply our Facebook Platform APIs working as intended."

"We have a dedicated team that does a robust review of the applications accessing our APIs. This team uses a risk-based approach, looking at applications' velocity as defined by number of users or pieces of data shared," said the spokesman. "When a potentially bad application is reported to us or detected by our systems, we act swiftly to remove or sanction it before it gains access to data."

The hackers disagree, saying that Facebook probably didn't understand the full scope of the attack. "FQL injection is present in applications -- or you can just query the API directly," said Hatter.

The hacker is not convinced of the efficiency of Facebook's defenses either. "Analyzing applications based on velocity is awesome against worms and malware that spread rapidly. However, if a single user is the desired target, it does not help so much. An attacker could easily trick the target into running a single malicious app," he said.

Facebook's application platform has long been a source of privacy and security risks. Earlier this year, it was discovered that many apps, even top ones, were sharing and in some cases selling user ids to advertisers. This allowed them to build profiles used for behavioral advertising.

Earlier this week Trend Micro reported an incident where attackers managed to serve drive-by download exploits through malicious ads displayed in a legitimate app. These are clear indications that Facebook can't guarantee a good behavior from every app on its network and the overexposed APIs are just one more thing ill-intentioned individuals can exploit.

Subscribe to the Security Watch Newsletter

Comments