Email Disclosure and Facebook Account Hijacking

[Teacher]

This article is for educational purposes only. The author is not responsible for any consequences of reading it.

This article is based on the words of the author. The original is here.

When it comes to bug hunting, I prefer mobile apps over the web, so in January I decided to delve deeper into apk endpoints hoping to find something interesting.

I downloaded a bunch of apk files of Facebook and messengers of different versions, found all the endpoints, sorted them and viewed them.

In the process, I came across one interesting endpoint with the title:

POST auth / flashcall_account_recovery

The endpoint requires 3 parameters:

cuid, encrypted_phone_numbersandcli

CUID basically meant encrypted email / phone number, which turned out to be easy to find.

Simply enter the victim's email address at the endpoint

POST / recover_accounts

And in return you will receive a CUID.

Then, you should follow the path of recovering your password on Facebook.

I noticed that the endpoint responsible for sending the OTP code to Facebook had a parameter named:

should_use_flash_call=false

If set to false, you will receive an OTP SMS on your phone, and if set to true, you will receive a phone call instead of an OTP to restore your account.

And the response contained the required encrypted phone numbers.

Now I couldn't figure out what the parameter means cli.

The only thing that came to my mind was the "command line interface (cli)".

Unable to understand, I substituted nullfor the value.

When I made the request, I got a user ID whose email value I specified as the CUID.

This means that an attacker can provide someone's email / phone address as the CUID and in response, they will be able to pinpoint who owns that email address.

I quickly submitted the report and it was accepted and corrected within a day.

I was very interested to know about this endpoint as I have never used "phone call recovery" to reset my password.

Neither my user interface nor Google nor Youtube had much information about this account recovery process.

So, I started to analyze how this recovery process works.

The endpoint worked like this.

1. I enter my email / phone.
2. I choose the option to restore using a phone call.
3. They call me on the phone.
4. This phone number will be automatically transmitted to the endpoint as:

POST / flashcall_account_recovery

It turns out that in the cli parameter, we must specify the phone number from which we received the phone call in step 3.

Now it became clear why this was called phone call recovery. I think that cli means something like caller identification.

Ideally, when we provide all valid values, we get the following response:

{"id": "UserID", "nonce": "XXXX", "skip_logout_pw_reset": ""}

The value nonce acts as an OTP code and will then be passed to the endpoint for OTP verification.

This endpoint validates nonce and sets the new password.

Q POST /flashcall_account_recovery, I first checked if the reset would work if you specify a valid cliother user, along with the cuidvictim, but it didn't work.

I tried replacing all parameters here and there, but none of them worked.

Now the only option I had left was to brute force the parameter cli.

Considering how strict Facebook is with brute-force rate limiting since it has rate limiting implemented even on non-authenticated endpoints, I had almost no hope.

But to my absolute surprise, no rate limiting was implemented at this endpoint.

Hence, the attack will work like this:

1. The user substitutes cuid victims enc_phone_number for the endpoint as wellflashcall_account_recovery
2. Brute force cli
3. We get nonce from the answer
4. Provide nonce OTP verification to the endpoint and set a new password for the victim's account.

Here's a video demonstrating how the default account recovery process using a phone call works:

Email disclosure timeline

Submitted: April 25, 2021

Triaged: April 27,2021

Fixed: April 27,2021

Account capture timeline

Submitted: April 29, 2021

Triaged: April 30, 2021 at 3:32 PM

Fixed: April 30, 2021 at 3:49 PM

It took me longer to test the fix than Facebook to release the fix lol.

After a thorough investigation, Facebook found no evidence of abuse and the matter was finally closed on September 2.