Bad Plugins, Vulnerabilities, and Facebook for a Triage of Social Engineering Win

Over the course of the last few months I have worked with clients that are tightly intertwined with Facebook through the use of third party plugins.  These plugins are used by the clients’ customer base for sharing links on their walls, entering promotions, and extending the functionality of the Facebook experience.   These third party applications are just as vulnerable as any other web application, but they have a different platform than a traditional web application, as they are tied directly into Facebook.

This leads to a few interesting opportunities for the attacker who may discover a flaw in one of these applications.  For one, there is an inherent trust in the applications on a Facebook page.  When a user on Facebook adds an application to their profile and it is a company that they view favorably, the thought of security might not cross their mind.  An attacker can use this to their advantage, especially in the context of social engineering, to potentially exploit a weakness in this plugin and have a higher success rate of exploitation.   In addition, many websites make use of Facebook’s share.php function, which parses a website and allows a user to share a link on their wall to the material.   This sharing function can also uniquely be exploited in the event that the third party plugin or site has an open redirect vulnerability.

Open redirection is an interesting vulnerability that simply redirects a user from a seemingly trusted site to an un-trusted site.   As a client side attack, Facebook would be an excellent medium for conducting this type of attack.  On a recent engagement, I came across a mobile website that was tightly integrated into Facebook.  Products and services offered by this company could be shared to Facebook, the non-mobile site had 50,000 or so “likes” on Facebook and even had an associated plugin.  The mobile site was vulnerable to open redirection on every single request.  The website took a base64 encoded URL of the non-mobile site and redirected every request to that URL (reformatted with some JavaScript).   I pulled the HTML and Stylesheets for the product I was interested in sharing, base64 encoded my malicious webserver hosting this content, and let the Facebook share.php function parse the site.  The link pasted to Facebook looked identical to the original and also contained the URL of the trusted site.  After a user clicks the product link shared on Facebook, they are redirected to my site, and client side JavaScript exploits are run.

Why is this particularly interesting?  I could send the same link to users over email.  The interesting part is that the link looks legitimate and Facebook even parses the link’s content to add to its legitimacy.  In addition, if I have already built rapport with people who like this particular client’s products and services, this also assists in the potential effectiveness of this attack.

So to help mitigate this risk, ensure your third party plugins are assessed in the same degree as your web applications.  If you are a company that allows employees to use Facebook, ensure users are educated on the risk of using Facebook and the plugins that tie into the site.

Facebook in the last few months has really ramped up their security efforts by offering a Bug Bounty program.  The program adheres to the principle of responsible disclosure and has been relatively successful as numerous bugs and fixes have been implemented.  Unfortunately, third-party plugins are excluded from this program, and since tens of thousands of third party applications integrate into Facebook, this presents many opportunities for the curious attacker.   It would be nice to see Facebook allow third-party developers to opt into this bug bounty program, but in the mean time it is a step in the right direction.