When a Business Manager user decides to change his/her business email address under user settings, they should verify the email ownership by clicking on a link sent to that email.
This verification procedure is to prevent abuse.
I found it possible to cicumvent this feature to add any business email address without verification.
Reproduction:
Authenticate into Business Manager.
Go to Business settings –> People.
Edit the email address of say, admin to any address.
Capture the request using any intercepting proxy and edit the value of parameter email to the target business’ email and edit the value of parameter pending_email to attacker’s own email address.
Complete the request and reload the page.
It could’ve added the new email address bypassing the verification process.
Report sent : 04 Dec 2015
It was deemed as a duplicate report by the security team. Thanks for reading!
It is possible for public audience to post contents including photos,videos etc. into a Facebook page if admin allows such
activities through their Page settings.
There is an option for admin to disable posting of photos and videos in Page settings. While checking for access control issues,
I found that page analyst could still post video even though admin disallows it. It was not possible to post photos or
text updates,but I could successfully post a video through the graph API using Analyst’s access_token with publish_actions scope.
Report sent : 31 Mar 2015
Escalation : 31 Mar 2015
Fix : 06 April 2015
Bounty awarded : 06 April 2015
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
According to me:
Clickjacking is an interesting and simple way of exploiting a web application that can lead to serious issues (transfer funds, messaging…). The idea is actually really simple:
We frame a certain website A within an Iframe and using stylesheets, we made it invisible/hidden (when it exists in the background) and reconstruct another site before it. So while you click something on the attacker controlled site, I can actually make you click a button in the framed website.
Owasp have a good example for ClickJacking: For example, imagine an attacker who builds a web site that has a button on it that says “click here for a free iPod”. However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the “delete all messages” button directly on top of the “free iPod” button. The victim tries to click on the “free iPod” button but instead actually clicked on the invisible “delete all messages” button. In essence, the attacker has hijacked the user’s click, hence the name Clickjacking.
The simplest and effective fix for this is the X-Frame-Options header. Even though, Facebook was using one, here is how I bypassed it to make me an attacker do post a status update. :)
The Exploit:
The exploit is really simple and effective; Facebook defends click-jacking in 2 ways. One is alternative to the other. They also use a technique called Frame-busting (using javascript to deny framing request). On interfaces which don’t have a JS support it is sending XFO, not as a
HTTP header, but in a meta tag by putting it in a
Meta-tags that attempt to apply the X-Frame-Options directive DO NOT WORK. For example, <meta http-equiv="X-Frame-Options" content="deny"> will not work. You must apply the X-FRAME-OPTIONS directive as HTTP Response Header.
The main point here is browsers ignores what is given in meta tag and do not defend framing, (tested in Firefox 35).
On interfaces which require JS support, it is possible to bypass JS frame-busting by giving a sandbox in the iframe like:
Simple as that, it was possible to iframe Facebook and make you do undesirable amount of things.
Here is a video demonstrating the seriousness of how this exploit might have been abused:
Reported - March 20 2015
Clarification sent - March 21 2015
Fix & Bounty - March 24 2015
It is similar to the Oculus Email Verification Bypass vulnerability I reported except that it is only involved of changing attacker’s own email address for a couple of times
and generating a new secret-token to the attacker’s own email inbox.
Yeah, and some Base-64 magics too. (not anything exciting!)
Next step is to change the email address to target’s email address. It sends a verification token to his account, which the attacker can’t access.
But attacker then uses initially generated tokens to successfully verify target’s email address on his Instagram account.
What’s less exciting about this bug comparing to the previous one is that it only allowed to use someone’s email address to create an Instagram account and verify it which definitely annoys the target, but never causes any harm in depth. Yet, Facebook rewarded this bug with a generous bounty.
Report sent : 22 Feb 2015
Escalation : Never notified
Fix : 17 March 2015
Bounty awarded : 18 March 2015
