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欧元的赏金奖励。