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

博客启用新域名：https://gugesay.com，由于公众号外链限制，已无法通过点击下方“阅读原文”跳转查看，请手动访问。

背景说明

目标服务器存在WAF，一旦进行扫描尝试，就会立即封锁IP地址，因此只能手动渗透该目标。为了保密，暂将目标网站称为’redacted.com‘，这是一个管理物联网项目、云解决方案、设备等的平台，它允许一个用户创建多个账户，并且只要知道他们的电子邮件地址，就可以邀请不同的用户加入项目。该网站允许灵活的账户注册，但是，每次注册都需要发送至电子邮件的OTP来进行验证，然后才能创建账户。

发现

在注册了一个用户并浏览了平台所有功能特性后， “创建新账户”功能成功引起了白帽小哥的注意。

来看下面这个请求：

在创建新账户时，它不仅有Name字段，而且还包含Email字段。返回的数据包含了idUser，Email，Role和一个名为sso_type的有趣字段。

那么如果在创建账户时将属于另一个用户的Email的值更改会发生什么？

利用另一位用户[email protected]（受害者电子邮件，拥有普通账户权限）。

是的，成功发现第一处漏洞，攻击者可以创建属于另一个用户的帐户。

批量分配漏洞

再次观察请求：在用户界面上，只需要输入名称 -> 但在请求中，需要一个电子邮件地址。

拥有丰富渗透经验的白帽小哥意识到，这里可能存在一个隐藏参数！但是尝试了常见的参数均无任何收获。

在这个时候，白帽小哥考虑到命名规则可能会根据开发者的习惯有所不同 -> 于是白帽小哥尝试以这种方式进行探索，将其与观察到的模式结合起来，有趣的事情发生了！

这显然是一个“批量分配漏洞”（https://portswigger.net/web-security/api-testing#mass-assignment-vulnerabilities）。既然有了密码，那尝试登录看看。

额…完全没有用！这里有两个问题需要思考：

1、如果知道与该用户关联的电子邮件，那么就可以在任何用户中创建任何账户

2、如果不知道那个用户的电子邮件怎么办？如果那个电子邮件从未被用来注册用户怎么办？

使用一个从未注册过的电子邮件尝试，然后在响应包中发现了一些奇怪的东西：

原因找到了，原来是密码不符合密码复杂度要求，重新调整密码复杂度，哦耶～

再次使用Email和Password登录，令人难以置信的是，可以直接登录，而不需要从电子邮件中验证OTP。

账户接管

坦白的说，能够绕过双因素认证确实能够带来更高的影响，但白帽小哥一时想不到更好的方法，于是他向他的一位资深同事（一位经验丰富的黑客）请教，他以一种非常有趣的方式启发了白帽小哥：

假设以下场景：

1、攻击者可以首先使用诸如 passwdAttacker 之类的密码注册用户

2、然后，受害者使用不同的密码 passwdVictim 注册相同的用户

3、如果攻击者仍然可以使用旧密码 passwdAttacker 登录用户，这就意味着：攻击者实现了账户接管，或者更准确地说，是预账户接管

假如仍然可以注册用户 [email protected] -> 那不就OK了？

失败！会检查该用户之前是否存在…

但是一件奇怪的事情是：注册时，网站被重定向到 sso.redacted.com -> 与之前遇到的 store.redacted.com 不同…

1、 检查用户的电子邮件API：

因此，如果电子邮件通过 sso_type:1 验证，则表示用户已通过电子邮件验证；如果未通过验证，则表示 sso_type:null。现在注意type值，分别是sso和local。

如果 sso_type:1 -> 我们将重定向到 sso.redacted.com 中的登录，验证用户没有的功能：“迁移”：

尝试一下该功能：

“成功迁移 SSO 登录” ?

再次检查了这封电子邮件 -> 响应已更改：sso_type:1 & type:sso

现在，这个邮箱就可以正常注册了！

使用不同的密码注册了该用户，并像往常一样验证了 OTP，但是却仍然可以使用旧密码登录该帐户！

那么，成功地进行了一次 Pre-ATO，同一个账户同时存在两个密码！？

发生了什么？

白帽小哥的推断是这样的：

有 2 个不同的数据库，我们称之为 Store 和 SSO，普通用户只能在SSO数据库中注册，只有获得授权的个人（特殊角色）才能在商店中创建帐户，并且“迁移”功能会将该普通用户的电子邮件迁移到 SSO。但是这两个数据库不同步。

• 如果先在 Store 中创建用户，就可以使用“迁移”功能将数据迁移到 SSO -> 就可以同时登录 store.redacted.com 和 SSO.redacted.com

• 如果先在 SSO 中创建帐户，则用户只能在 SSO.redacted.com 登录，并且只能使用第一次注册时的密码

这就是无法在第 2 部分登录的原因。

Pre-ATO 场景如下：

1、攻击者利用在Store数据库中预注册[email protected]帐户的漏洞

2、接下来，攻击者登录[email protected]，并使用“迁移”（Migrate）功能将其转移到SSO数据库，等待受害者注册该帐户

3、受害者注册账户[email protected]并正常使用

4、攻击者仍然可以以[email protected]身份登录并访问所有资源

这就是白帽小哥 Giongnef 带来的分享。

总结

一个非常有趣的案例，可以从中学到很多东西！

可以从漏洞中收获更多的“赏金奖励”！

当大家都在谈论漏洞赏金时，却很少有人问“你睡得怎么样？”

想要有所成就，就需要付出努力！

付出的努力越多，你得到的就越多！

如果你在自己热爱的工作中感到沮丧，那就再努力一点！

感谢阅读，如果觉得还不错的话，欢迎分享给更多喜爱的朋友～

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

原文始发于微信公众号（骨哥说事）：绕过双因素认证至账户接管