This will be a short post detailing how the Facebook domain can be used to serve malware and spear phish unsuspecting users.
I guess this is common knowledge to anyone who has looked into Facebook’s VRP, but the apps.facebook.com domain is used for embedding third-party content (i.e. websites that aren’t Facebook) onto a page with the facebook banner on it. Although this is not within scope of their VRP it is still a security risk – despite the fact that the vulnerabilities would be within external websites rather than Facebook, the outcome of vulnerabilities (think XSS / HTML Injection) would be displayed under the facebook.com domain and under the Facebook banner that the regular user has grown accustomed to. When naive internet users read up on how to prevent their accounts being stolen, they are warned of phishing attacks and told to always check the URL to make sure it’s spelled correctly – when such a user sees the correctly spelled URL, they’ll assume that its completely legitimate and accept it as a trusted source.
You may be wondering why Facebook doesn’t just disallow this content to be embedded under their apps domain, and the answer to that is simple – it would have a detrimental effect on the functionality of the site itself. Most people in infosec are undoubtedly already familiar with this concept, but for those who aren’t, here is a simple diagram that explains it:
“Why is it represented as a triangle? If you start in the middle and move to the point toward Security, you’re moving further away from Functionality and Usability. Move the point toward Usability, and you’re moving away from Security and Functionality. Simply put, as security increases, the system’s functionality and ease of use decrease”
Basically, Facebook are probably already aware of the potential risk here, but have had to decide whether the risk outweighs the functionality of this feature, and they have probably decided that it does not (although i’m sure many people will disagree)
In order for an attacker to use this to their advantage, they would first have to identify a cross site scripting vulnerability in a site that has its content embedded under the apps domain of Facebook. Using some basic google dorks would be the most efficient way to do this, something like:
site:apps.facebook.com filetype:php inurl:search
After that, it’d be a case of finding a suitable vulnerable site that has its content embedded under this domain. For the purposes of this explanation, I will be using the following site:
Note how the site is accessible under the Facebook domain (with the Facebook banner conveniently added):
An attacker could easily craft a malicious URL that looks like it’s part of Facebook, when in reality it is exploiting a vulnerability on a third party website in order to serve malicious content to an unsuspecting user.
Although someone could in theory create their own page embedded under this domain (through legitimate means, i.e. their own Facebook app), serving malicious content in this manner isn’t exactly viable as the Facebook staff would catch on and delete this app – looking for vulnerabilities in currently existing apps then making a one-time link that will serve the malicious content is a more viable option, since there is no malicious page for the Facebook admins to see (unless reported to them w/ screenshots of the URL).
Below is an example page designed to demonstrate how the Facebook domain could be used to serve malware (note that in a real attack time would be spend to make both the content on the page and the URL itself more convincing – this is just for demonstration purposes):
Take note that this will only be working in Firefox, Chrome’s XSS auditor will definitely catch this
You should also note that in this example, the download link isn’t actually a malicious file (but rather an empty file with the .exe extension – once again for demonstration purposes)
In this case, Facebook have definitely chose functionality over security, and the trade-off they have made makes targeted phishing campaigns against Facebook users stupidly easy.
Below is a video PoC, demonstrating how the attack would play out:
That’s all for now, thanks for reading