绕过双因素认证至账户接管
2024-1-22 17:0:41 Author: 骨哥说事(查看原文) 阅读量:140 收藏

目标服务器存在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 带来的分享。

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

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

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

想要有所成就,就需要付出努力!

付出的努力越多,你得到的就越多!

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

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

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


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5Mzc4MzUzMQ==&mid=2650257799&idx=1&sn=7888701dc5a369dfc236ae0a514369dd&chksm=bf73b7351f0247e6a5962e1a5637e52fefdc0b192ad84a3f0711143c024e3be58a7ff617c212&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh