ATO全称Account TakeOver，中文一般翻译为“帐户劫持或帐户接管”，ATO一般有多种方式可以实现，比如：
- 当攻击者使用以往数据泄露中获取到的用户名、密码尝试未经授权访问其它用户帐户
- 攻击者从用户处获取会话（Session）token（如Sesstion ID、JWT等），使用token而无需用户名、密码从而冒充用户
- 利用XSS漏洞获取用户Cookie或登录凭证后，进行帐户接管
- 通过跨站点请求伪造（CSRF）攻击诱骗经过身份验证的用户在不知情的情况下执行恶意操作
- 利用弱密码策略、不安全的密码存储、可预测的会话token或者用户恢复机制的业务逻辑错误
今天来分享一位Jedus0r_白帽小哥的故事，话说某天，主角白帽小哥在对一个公共项目进行‘狩猎’时，发现了一个很有趣的应用程序，该程序具有很多功能。小哥的做法通常是注册一个帐户，然后更深入的寻找漏洞，今天他却反其道而行，打算先测试一下所有未经身份验证的功能，一是打算真正了解这个应用程序的工作流程，从而推断出他应该更加关注哪种类型的漏洞。
很快小哥便发现了由于没有验证码和速率限制，可以通过字典爆破到用户密码，从而导致帐户被接管，但该漏洞被归类为P4级。
于是小哥继续测试密码重置功能，小哥打算检查用户的‘姓氏“、”名字“是否会反映在电子邮件中，这样便可以尝试HTML注入攻击，然而结果是令人失望的。于是小哥开始查看Burp Suite中的请求与响应信息。
PUT /api/v1/people/forgot_password
小哥注意到在上面的请求中，响应包中显示了他的重置密码Token、个人信息以及密码hash：
接着小哥使用浏览器打开“无痕”浏览模式，然后再次尝试重置密码，令人惊讶的是，收到了同样的响应信息：
{
“activation_code”:”3ce8aeb4461ae0e45eb73a4649babc6529d096da”,
”reset_password_code”:”fb39dfe8cb9200305b34a693c7867fb8",
”id”:4592665,
”first_name”:”\u003cu\u003ehello\u003c/u\u003e”,
”last_name”:”\u003cu\u003ehello\u003c/u\u003e”,
”account”:true,”email”:”[email protected]”,
”crypted_password”:{“raw_pw”:”$2a$REDACTED”
}
此时小哥脑海里开始自问：
- 我是否能够将其升级为帐户接管？
- 我是否可以解密密码hash？
- 响应包中的密码重置token是否有效？
由于目前这个漏洞可以枚举所有用户的PII信息，所以该漏洞会被定义为P1级，但是如果可以使用用户的密码hash或者重置密码token，那么就可以作为帐户接管来提高漏洞的影响力。
经过查看电子邮件收到的重置密码链接，小哥确认了响应包中的重置密码token与邮件中的一致，由此可以得出结论，响应包中的重置密码token是有效的！
- 攻击者向 API 端点“/api/v1/people/forgot_password”发送请求，请求重置受害者帐户的密码
PUT /api/v1/people/forgot_password HTTP/2
Host: REDACTED.COM
{“email”:”[email protected]”}- 攻击者将重置密码token和受害者 ID（从第 1 步的响应中提取）粘贴到以下 URL 中：
https://www.redacted.com/reset_password?code="REPLACE_WITH_RESET_PASSWORD_CODE"&id=REPLACE_WITH_ID_PARAMETER- 攻击者在他的浏览器中打开链接，并重置受害者的密码
- 攻击者无需受害者采取任何操作即可访问受害者帐户（实现帐户接管）
小哥第一时间将漏洞上报，厂商的IT团队在几小时内便迅速的做出了处理，并进行了修复，修复成功的数小时后，小哥也顺利的收获了2500欧元的赏金奖励。
