【转载】【漏洞分析】Facebook email disclosure and account takeover

I have a preference for apps over web when it comes to hunting, so in January I decided to dive deep into apk endpoints hoping to find something juicy.

比起网络,我更喜欢应用程序,所以在一月份我决定深入 apk endpoints,希望能找到一些有趣的东西。

I downloaded bunch of FB and messenger apks of different versions, grepped all the endpoints, sorted them and was going through them

我下载了很多不同版本的 FB 和 messenger 应用程序,润滑了所有端点,对它们进行了排序,并正在浏览它们

During the process, I came across another an interesting endpoint named:

在这个过程中,我遇到了另一个有趣的端点,名为:

POST auth/flashcall_account_recovery

POST auth/flashcall _ account _ recovery

The endpoint required 3 parameters:
cuid, encrypted_phone_numbers & cli

端点需要3个参数: cuid,encrypted _ phone number & cli

The CUID basically meant encrypted email/phone and can be easily found.

Just supply victim’s email in

CUID 基本上意味着加密的电子邮件/电话,可以很容易地被找到。只要提供受害者的电子邮件在

POST /recover_accounts

POST/recover_accounts

And in response you’d get the CUID.

作为回应,你会得到 CUID。

Secondly, while going through the Facebook’s password recovery flow.

其次,在浏览 Facebook 的密码恢复流程时。

I noticed that in the endpoint responsible for sending the FB OTP code, there was a parameter named:

我注意到,在负责发送 FB OTP 代码的端点上,有一个参数名为:

should_use_flash_call=false

应该使用 flash call = false

If its false, you’d receive an OTP SMS in your phone and if set true, you receive a phone call instead of OTP for account recovery.

如果是假的,你会收到一个 OTP 短信在你的手机,如果设置为真,你会收到一个电话,而不是 OTP 的帐户恢复。

And in the response it contained the required encrypted phone numbers.

在回复中,它包含了所需的加密电话号码。

Now, I could not figure out what cli was.
The only thing coming to my mind was “cli~command line interface

现在,我不知道 cli 是什么,我脑子里唯一想到的是“ cli ~ 命令行界面”

Unable to figure out, I supplied null value instead.

由于无法确定,我改为提供了空值。

When made the request,
I received the userID belonging to the user, whose email value I supplied as the CUID.

当发出请求时,我收到了属于该用户的 userID,我提供了其电子邮件值作为 CUID。

Meaning an attacker could supply anyone’s email/phone as CUID and in response he would be exactly able to determine who that email belonged to.

这意味着攻击者可以提供任何人的电子邮件/电话作为 CUID,作为回应,他可以准确地确定这封电子邮件属于谁。

I quickly submitted the report and it was triaged and fixed within a day.

我迅速提交了报告,并在一天之内进行了分类和修复。

I was veryyyyy curious about this endpoint as I had never used a “phone call recovery” to reset my password.

我对这个端点非常好奇,因为我从来没有用“电话恢复”来重置我的密码。

Neither it was present in my UI, nor was there much info available regarding this account recovery flow in Google as well as Youtube.

在我的用户界面中没有,也没有很多关于 Google 和 Youtube 账户恢复流程的信息。

So I started to analyze how this recovery flow works by reading the smali files.

因此,我开始通过读取 smali 文件来分析这个恢复流是如何工作的。

The endpoint worked in following manner.

端点以下列方式工作。

  1. I enter my email/phone. 我输入我的电子邮件/电话
  2. Choose phone call recovery option. 选择电话恢复选项
  3. I receive a phone call. 我接到一个电话
  4. That phone number will be automatically supplied to the endpoint as: 该电话号码将自动提供给端点,如下:

POST /flash_call_recovery

POST/flash _ call _ recovery

cuid=x&enc_phone=x&cli=+1xxxxx

2.1.1.2.2.2.2.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3.3

Turns out in cli parameter we are basically supposed to supply the phone number from which we received the phone call in Step3.

结果在 cli 参数中,我们基本上应该提供我们在 Step3接到电话的电话号码。

Now it all made sense why it was called phone call recovery🤦‍♂️

现在一切都说得通了,为什么它被称为“复苏电话”(phone call recovery)

I guess the cli means something like caller identification.

我猜 cli 的意思是来电显示之类的。

In an ideal scenario when supplied all valid values, we would then receive this following response:

在理想的情况下,当提供所有有效值时,我们将收到以下响应:

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

{“ id”: “ UserID”,“ nonce”: “ XXXX”,“ skip _ logout _ pw _ reset”: “”}

This nonce value acts as an OTP code and then will be supplied to the OTP verification endpoint.

此 nonce 值充当 OTP 代码,然后将提供给 OTP 验证端点。

The OTP verification endpoint is then responsible for validating the nonce and setting the new password.

OTP 验证端点负责验证 nonce 并设置新密码。

In POST /flash_call_recovery , I initially tested if supplying another user’s valid cli with victim’s cuid would work, but it didn’t.

在 POST/flash _ call _ recovery 中,我最初测试了将受害者的 cuid 提供给另一个用户的有效 cli 是否可行,但没有成功。

I tried flipping every parameters here and there but non of them worked.

我试着翻转每一个参数,但是没有一个有效。

Now, the only option I was left with was bruteforcing the cli.

现在,我唯一的选择就是强迫他们。

Considering how strict FB is with rate limiting since it even has rate limit implemented on non authentication endpoints I had little to no hope.

考虑到 FB 在速率限制方面有多么严格,因为它甚至在非身份验证端点上实现了速率限制,我几乎没有希望。

But to my absolute surprise, it had no rate limit implemented in this endpoint.

但令我惊讶的是,在这个端点没有实施速率限制。

Hence the attack would work like this:

因此,攻击的工作原理如下:

  1. User supplies victim’s 用户提供受害者的cuid and enc_phone_number in flashcall recovery endpoint 在闪点恢复终端
  2. Bruteforces the 粗暴的强迫cli
  3. Receives the 接收nonce from the response 从反应
  4. Supplies the 供应nonce in OTP verification endpoint and sets a new password for victim’s account. 在 OTP 验证端点,并设置一个新的密码为受害者的帐户

Here’s video demonstrating how a default phone call account recovery process works:

下面的视频演示了一个默认的手机通话账户恢复过程的工作原理:

Timeline of Email Disclosure

邮件泄露时间表

Submitted: April 25, 2021
Triaged: April 27,2021
Fixed:
April 27,2021

提交: 2021年4月25日分诊: 2021年4月27日修复: 2021年4月27日

Timeline of Account Takeover

接管帐户时间表

Submitted: April 29, 2021
Triaged : April 30, 2021 at 3:32 PM
Fixed: April 30, 2021 at 3:49 PM

提交: 2021年4月29日分流: 2021年4月30日下午3:32固定: 2021年4月30日下午3:49

It took me more time to verify the fix then FB took to release the fix, lol🤣

我花了更多的时间来验证修复然后 FB 采取释放修复,哈哈

After thorough investigation, Facebook found no evidence of abuse and the issue was finally closed in September 2.

经过彻底的调查,Facebook 没有发现虐待的证据,这个问题最终在9月2日结束。