正文
我测试的应用程序有多个子域名:
1、account.example.com:处理用户账户管理。
2、project.example.com:管理用户拥有或被邀请的项目。
3、org.example.com:一个新的子域,用于管理多个项目的组织。
4、collaborator.example.com:一个最近更新的子域,允许外部协作者向项目发送加入请求。
我发现该应用程序允许在没有邮件确认的情况下注册,但在确认邮件之前会施加许多限制。 五年前的黑客活动报告中详细描述了邮件确认绕过的漏洞(并且有一些丰厚的奖励)。我受到鼓舞,决定自己找一个,所以我最初的尝试很经典:
-
通过重置密码链接绕过确认?没有成功。 -
猜测确认 URL 中的令牌?也没成功。
经过几个小时的测试,我一度陷入死胡同。但我没有放弃,继续做笔记,转而探索其他域名。
在探索 project.example.com 域时,我发现了一个有趣的地方:当你邀请用户加入项目时,受邀者接受邀请后会通过邮件确认其邮箱。听起来很合乎逻辑,对吧? 然而,活跃用户的邮箱不能通过用户界面进行修改。我使用 Burp Suite 拦截了修改用户角色的请求,并添加了一个参数来更改邮箱。结果却是“不允许修改邮箱。”
然后,我注意到对于待处理用户(那些尚未接受邀请的用户),邮箱可以通过拦截请求进行修改。系统甚至会向更新后的邮箱发送新的邀请,但问题是通过旧的邀请链接创建的账户仍然会验证原始邮箱。
接着,我深入研究了 org.example.com 和 collaborator.example.com,并且发现了以下内容:
1、org 域引入了多项目管理,允许在多个项目之间共享资源(包括用户)。2、collaborator 域允许外部用户请求加入项目。这些请求可以被项目管理员接受或拒绝,从而创建了新的用户类型:
-
活跃用户(已完全注册并确认的用户) -
待处理用户(已邀请但尚未注册的用户) -
协作者用户(请求访问的用户)
通过测试,我发现:待处理和协作者用户的邮箱可以通过拦截请求进行修改。
org 域有一个新功能:重新发送邀请。活跃用户和协作者用户可以越权使用这个功能。
漏洞步骤
以下是我将这一切拼凑起来的过程。
我创建了三个账户:
[email protected]:在 org.example.com 上注册。
[email protected]:在 collaborator.example.com 上注册。
[email protected]:目标账户。
以[email protected]的身份,我在 org.example.com 上创建了一个项目;以[email protected]的身份,我向该项目发送了一个加入请求。
[email protected] 接受了请求,并使用重新发送邀请功能将邀请链接发送给[email protected]。
我在 project.example.com 上拦截了请求,并将[email protected] 修改为[email protected]。
使用之前发送的重新发送邀请链接,我模拟受害者,用[email protected] 账户打开了链接并完成了注册过程。
不出所料,现在[email protected]现在已是经过验证的账户,无需攻击者确认其电子邮件。(即[email protected]的账户被验证,但实际上是我控制的账户。)
为了展示漏洞的影响,我设计了一个预账户接管的场景:
1、邀请一个高权限用户加入项目。
2、利用该绕过漏洞,将验证过的邮箱与攻击者的账户关联。
3、添加次要登录方法(例如,社交登录)或更改受害者的登录凭据。
我录制了一段展示完整攻击链的 POC 视频,并将其分享给了项目团队。
赏金
最初,这份报告被评为中等(4.8分)。
经过多次讨论,强调了该漏洞的潜在安全影响后,他们将评分提升到5.4分。
培训咨询v
bc52013 或 linglongsec
SRC漏洞挖掘培训
往期漏洞分享
IDOR与JWT令牌破解相结合,实现编辑、查看和删除数万帐户
玲珑安全B站公开课
https://space.bilibili.com/602205041
玲珑安全QQ群
191400300
原文始发于微信公众号(芳华绝代安全团队):绕过电子邮件确认实现预账户接管
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论