A researcher has earned a significant bounty after finding a serious cross-site scripting (XSS) vulnerability that could have allowed malicious hackers to take over users’ Facebook accounts.
The XSS vulnerability was reported to Facebook by UK-based security consultant Jack Whitton in July 2015 and it took the social media giant roughly 6 hours to patch it. However, the researcher waited until this week to disclose its details.
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.
The researcher’s attack method has two main aspects: one related to content types and a DNS issue.
The expert first attempted to upload a file containing arbitrary HTML code to Facebook. He 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.
The extensions of regular photos and videos uploaded to Facebook cannot be modified, but Whitton found that advertising images uploaded via the Ads Manager did not benefit from the same protection.
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.
However, uploading arbitrary code embedded in harmless-looking files is not enough because files are stored on Facebook’s content delivery network (CDN), which is sandboxed. Facebook and other major companies, such as Google, specifically state in their bug bounty program rules that running code on a sandboxed or CDN domain is out of scope.
The good thing about executing code on a Facebook CDN domain is that the associated URL is not verified by the company’s Link Shim system, which checks all external links for malicious content before the browser requests the page.
With his code uploaded to Facebook and with Link Shim bypassed, all the expert needed to do was 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.
The next step was to find a way to make requests to facebook.com directly, which is normally impossible due to cross-site request forgery (CSRF) protections. However, Whitton found that several Facebook plugins are designed to be placed in an iframe, which bypasses protections. This made it possible for an attacker to steal a user’s CSRF token and make requests on their 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 said in an email. “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 noted in a blog post 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. However, Facebook told SecurityWeek that it fixed the content type bug as well.