声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由用户承担全部法律及连带责任,文章作者不承担任何法律及连带责任。 |
博客启用新域名:https://gugesay.com,由于公众号外链限制,已无法通过点击下方“阅读原文”跳转查看,请手动访问。
背景说明
目标服务器存在WAF,一旦进行扫描尝试,就会立即封锁IP地址,因此只能手动渗透该目标。为了保密,暂将目标网站称为’redacted.com‘,这是一个管理物联网项目、云解决方案、设备等的平台,它允许一个用户创建多个账户,并且只要知道他们的电子邮件地址,就可以邀请不同的用户加入项目。该网站允许灵活的账户注册,但是,每次注册都需要发送至电子邮件的OTP来进行验证,然后才能创建账户。
发现
在注册了一个用户并浏览了平台所有功能特性后, “创建新账户”功能成功引起了白帽小哥的注意。
来看下面这个请求:
在创建新账户时,它不仅有Name字段,而且还包含Email字段。返回的数据包含了idUser,Email,Role和一个名为sso_type的有趣字段。
那么如果在创建账户时将属于另一个用户的Email的值更改会发生什么?
利用另一位用户giongfnef26+user2@intigriti.me(受害者电子邮件,拥有普通账户权限)。
是的,成功发现第一处漏洞,攻击者可以创建属于另一个用户的帐户。
批量分配漏洞
再次观察请求:在用户界面上,只需要输入名称 -> 但在请求中,需要一个电子邮件地址。
拥有丰富渗透经验的白帽小哥意识到,这里可能存在一个隐藏参数!但是尝试了常见的参数均无任何收获。
在这个时候,白帽小哥考虑到命名规则可能会根据开发者的习惯有所不同 -> 于是白帽小哥尝试以这种方式进行探索,将其与观察到的模式结合起来,有趣的事情发生了!
这显然是一个“批量分配漏洞”(https://portswigger.net/web-security/api-testing#mass-assignment-vulnerabilities)。既然有了密码,那尝试登录看看。
额…完全没有用!这里有两个问题需要思考:
1、如果知道与该用户关联的电子邮件,那么就可以在任何用户中创建任何账户
2、如果不知道那个用户的电子邮件怎么办?如果那个电子邮件从未被用来注册用户怎么办?
使用一个从未注册过的电子邮件尝试,然后在响应包中发现了一些奇怪的东西:
原因找到了,原来是密码不符合密码复杂度要求,重新调整密码复杂度,哦耶~
再次使用Email和Password登录,令人难以置信的是,可以直接登录,而不需要从电子邮件中验证OTP。
账户接管
坦白的说,能够绕过双因素认证确实能够带来更高的影响,但白帽小哥一时想不到更好的方法,于是他向他的一位资深同事(一位经验丰富的黑客)请教,他以一种非常有趣的方式启发了白帽小哥:
假设以下场景:
1、攻击者可以首先使用诸如 passwdAttacker 之类的密码注册用户
2、然后,受害者使用不同的密码 passwdVictim 注册相同的用户
3、如果攻击者仍然可以使用旧密码 passwdAttacker 登录用户,这就意味着:攻击者实现了账户接管,或者更准确地说,是预账户接管
假如仍然可以注册用户 vrongdethuongv@gmail.com
-> 那不就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数据库中预注册victim@companyA.com帐户的漏洞
2、接下来,攻击者登录victim@companyA.com,并使用“迁移”(Migrate)功能将其转移到SSO数据库,等待受害者注册该帐户
3、受害者注册账户victim@companyA.com并正常使用
4、攻击者仍然可以以victim@companyA.com身份登录并访问所有资源
这就是白帽小哥 Giongnef 带来的分享。
如果你是一个长期主义者,欢迎加入我的知识星球,我们一起往前走,每日都会更新,精细化运营,微信识别二维码付费即可加入,如不满意,72 小时内可在 App 内无条件自助退款