声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

背景介绍：

今天的分享来自一位名为“Faique”的印度白帽小哥，让我们来看看他是如何利用配置错误的2FA（2次认证）和OAuth获得账户接管的。

发现过程：

白帽小哥在挖掘漏洞之前，需要了解一切是如何工作的，尤其是身份验证部分，登录网站的方式有好几种，但大致可以分为两大类：一种是使用普通的电子邮件和密码，另一种则是使用OAtuh，如Google、GitHub...

该网站的一项安全功能就是提供了2FA（2次认证）功能，该功能在漏洞中发挥了重要作用！

一开始小哥从基本的信息收集和‘侦察’开始，很遗憾，并没有找到有价值的东西。于是他转向了身份验证功能，首先创建了一个账户，并测试重复注册、忘记密码、SQL注入等漏洞，然后尝试启用2FA并暴力破解2FA的验证码，但一无所获。

第二天，白帽小哥在Google Oauth账户中启用了2FA，并拦截了每个请求，将请求发送至BP，观察结果。

在获得了N多2FA失败后，白帽小哥心灰意冷，于是关闭了2FA功能，然而却意外地在上图显示的拦截请求中发现收到了一个JWT令牌，于是白帽小哥在想，如果使用一些随机值（如000000）更改身份验证器代码并再次发送请求会怎样呢？

即使在账户中禁用了 2FA 功能，也能够发送该请求获取 JWT 令牌，而这个 JWT 令牌基本上是用于对用户进行身份验证的 Cookie，为了确认这确实是一个漏洞，白帽小哥耐心等待了 1 天后，再次发送请求，Bingo！再次收到了 JWT 令牌，这一刻白帽小哥异常兴奋！

因此我们只需要一种可以直接登录受害者账户的方法，于是小哥继续浏览网站，他看到有一个功能可以为 OAuth 账户设置密码，这样任何人都可以使用电子邮件和密码登录。

使用设置密码请求并将 JWT 令牌替换为上面收到 JWT 令牌，是的，密码被成功修改。

该漏洞不仅影响 Google OAuth 登录，还影响站点使用的其它所有 OAuth ：GitHub、Microsoft、Bitbucket、Azure active directory。

注意：只有当客户在其账户上启用然后再禁用 2FA 时，才会出现该漏洞。

小哥第一时间上报了该漏洞，很快获得了$1000的赏金奖励。

有兴趣的同学也可以关注这位小哥的Twitter：https://twitter.com/imfaiqu3

====正文结束====

原文始发于微信公众号（骨哥说事）：价值 1000 美元的账户接管