Oculus VR - one of the Facebook acquisitions, was vulnerable to many severe issues including RCE, multiple SQL-injections, and a couple of CSRFs.
Many researchers including Jon of Bitquark, Inti De Ceukelaire and Josip Franjković squeezed it to a more secure level. I knew that all the low hanging fruits must had been gone. Nevertheless, I gave it a shot. It is my second finding on Oculus; first was something which allowed me to add anyone’s email to an account and verify it without their interaction by crafting a verification link; which led to full account takeover. This one is also somewhat similar, which enabled me to reset random-user’s password resulting in successful authentication into their account. Each time I reproduced the request, got access to different accounts, which in turn changed their passwords as well.
Since this application was running on PHP, the first idea that caught my mind while testing the password reset functionality was to test for type juggling issues. And indeed developers made that usual mistake here.
Watch the video!
I sent the query parameters as arrays to confuse the application which resulted in skipping some condition checks in the logic responsible for the password reset.
A nice bounty followed up after it was reported to the Facebook security team.
When a new Facebook account is created a verification code is sent to the email of the user to confirm their identity. Email contains an option to disavow the confirmation link in case the email was misused or used by someone else to create an account.
The link behind
Didn't sign up for Facebook?
had a confirmation code in it, which was a 5 digit code :
We all have seen many kind of verification processes while starting an account with most web applications. The most common form of verification method is either through email address or phone number or a mix of both.
This post demonstrates how I bypassed the email address verification system implemented for Oculus, a Facebook acquisition. Normally, abusing this kind of vulnerabilities, attackers can use anyone’s email address to create an account, which stops the original owner from creating an account since the email address is already taken.
But here, the case was even worse. Oculus developer platform worked in a different way. Since companies could register for an account, it recognized company’s domain-name from the email address and added every user account created with a
company’s domain-name,to the company’s account as members. Bang!!
For eg: Suppose xCompany has it’s email address as [email protected] and they uses it to register a company account. Now the admin can add users into the dashboard.
Also, any user who registers for a normal account with their employee email for eg:, [email protected] would be automatically added to the company account as a member.
For all of the things mentioned above to happen, the users should verify their email address by clicking on a verification link received to mail inbox.
What if an attacker manages to bypass the verification system?
He can create an account/replace existing email with target’s email address([email protected]) and can end up being a member of the developer team for xCompany.
Description
I’ve encountered it multiple times that some web-applications accepts the same secret-token or verification-code on multiple endpoints. To be more specific, when we request for a password recovery, a password reset token is sent
to our email address. Consider the link received through email looks like this:
Step 1 : Attacker creates an account with his own email address (for eg,[email protected]).
Step 2 : Attacker verifies the email address by clicking on the email verification link received to his inbox.
Step 3 : Attacker requests for a password recovery link for his account and extracts the token received. Let’s call it passtoken.
Step 4 : Attacker goes on and edits the account settings to change his email to an email address with target’s domain name ([email protected]) which sends an email verification link (with verifytoken)to that email address which doesn’t even exist.
Step 5 : Attacker uses the initially extracted token (passtoken) on email-verify endpoint and circumvents the protection ending up being a member of xCompany. Profit!!
It worked because, both the passtoken and verifytoken were still valid for his account, and the application failed to validate/differentiate it’s purpose.
Report sent : 28 Aug 2014
Escalation : 29 Aug 2014
Fix : 07 September 2014
Bounty awarded : 08 September 2014
This post is about a simple bug I found in Facebook which allowed me to chat with any minor,even if they are not in our friendslist.
It was a privacy issue where a user could send messages to a minor who was a total stranger when they shouldn’t be able to do so.
According to Facebook,
Minors can receive messages only from people who are friends of friends and people who have their contact information (ex: email address or phone number). This may include adults they don’t know.
But there I found a bug which was very easy to find and exploit to circumvent this security feature.
For a minor who have changed his/her message preferences from Basic Filtering to Strict Filtering (for more privacy)
in privacy settings,this trick worked.
First of all we need to extract the target’s profile id.
Do a graph check to get fbid.
http://graph.facebook.com/victim
Visit
https://www.facebook.com/messages/<FBID>
Name of the minor appeared in the field “To:”
I sent a “hi” without seeing any error as usual. Yes, that was it. Sometimes the bug finds us before we get to them.
Then I logged in to the target’s account to check if the message was received and found it was showing up right in their inbox.
Issue was fixed and rewarded me a bounty after it was reported to the security team.