Security researcher paid $7500 for finding a Facebook account hijacking flaw
Facebook paid $7500 to a security researcher for finding a critical cross-site scripting (XSS) vulnerability that allowed potential hackers to take over users’ Facebook accounts.
The vulnerability was discovered by UK-based security consultant Jack Whitton who immediately informed Facebook. Facebook engineers quickly took cognizance of the critical flaw and patched it within six hours.
The bug bounty hunter told SecurityWeek that he earned $7,500 for responsibly disclosing the issue, an amount confirmed by Facebook representatives.
“As these sort of issues become harder to find on sites which have a mature bug bounty programme (Facebook & Google), the rewards increase quite a lot, which means the payouts are really worth your time,” Whitton said via email.
Whitton has detailed the XSS flaw in his blog post and states that the attack consists of two vectors, content type and a DNS issue.
Whitton discovered that in some cases it’s possible to get an uploaded file to be interpreted as an HTML simply by changing its extension to .html. Thought the regular photo and video cant be modified, but Whitton found that advertising images uploaded through the Facebook Ads Manager could be modified.
Using a technique described in 2012, the expert managed to encode an XSS payload into a PNG image’s IDAT chunk. Unlike Exif and iTXt data, which are removed by Facebook from uploaded JPEG and PNG images, IDAT chunks are not. Once that was done, Whitton had to bypass the Link Shim system in Facebook and needed to find a way to move from the CDN hostname to a proper facebook.com domain.
He discovered that the DNS entries for the photo.facebook.com domain were pointing to the CDN, allowing him to get his payload executed by navigating to the uploaded HTML file on the photos.facebook.com domain.
Whitton found that several Facebook plugins are designed to be placed in an iframe, which bypasses such protections. Once this was done Whitton could easily steal user’s CSRF token and make requests on the victim’s behalf simply by getting the victim to click on a link.
“In this case, because it’s a client-side issue, an attacker would need to persuade a user to click/visit a link they control,” Whitton told Security Week. “This could be by posting a status with the link, or sending an email.”
“This is a bit easier than it sounds, because the URL is a legitimate facebook.com URL, rather than a suspicious domain. Once they’d clicked it, then the script in the background could do anything with their account – post a status, read private messages. In addition, the script could post a link to itself to the victim’s Facebook account, which could trick their friends into opening it, and so on,” he added.
Whitton told Security Week that Facebook quickly addressed the DNS issue, but left the content type weakness unpatched, most likely because it was a low risk flaw on its own.
Facebook however confirmed to SecurityWeek that it fixed the content type bug as well.
