账户接管

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

授权问题

应尝试更改账号的 email，并且必须检查确认流程。如果发现确认流程薄弱，应将 email 更改为目标受害者的邮箱并完成确认。

Unicode Normalization 问题

  1. 目标受害者的账号 victim@gmail.com
  2. 使用 Unicode 创建一个账号，例如：vićtim@gmail.com

如这场演讲 所述，上述攻击也可以通过滥用第三方 identity providers 完成：

  • 在第三方 identity provider 上用与受害者相似的 email 创建账号，使用一些 unicode 字符（vićtim@company.com）。
  • 第三方提供方不应验证该 email。
  • 如果 identity provider 验证 email，或许可以攻击域名部分，例如：victim@ćompany.com，并注册该域名，希望 identity provider 生成域名的 ascii 版本，而受害者平台对域名进行 normalize。
  • 通过该 identity provider 在受害者平台登录，受害者平台应对 unicode 字符进行 normalize，从而允许你访问受害者账号。

更多细节请参考关于 Unicode Normalization 的文档：

Unicode Normalization

重用 Reset Token

如果目标系统允许重用 reset link，应努力使用如 gau、wayback 或 scan.io 等工具查找更多 reset links。

预先账户接管（Pre Account Takeover）

  1. 使用受害者的 email 在平台上注册，并设置一个密码（应尝试确认该账号，但因无法访问受害者邮箱可能无法完成）。
  2. 等待受害者使用 OAuth 注册并确认账号。
  3. 希望常规注册能被确认，从而能够访问受害者账号。

CORS Misconfiguration to Account Takeover

如果页面存在 CORS misconfigurations，你可能能够从用户处 窃取敏感信息，以 接管其账号 或让其更改认证信息以达到相同目的：

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

如果页面存在 CSRF 漏洞，你可能能够让用户修改其密码、email 或认证信息，从而随后访问该账号：

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

如果你在应用中发现 XSS，可能能够窃取 cookies、local storage，或页面上的信息，从而允许你接管账号：

XSS (Cross Site Scripting)

  • 登录页面上的仅属性反射型 payloads 可以挂钩 document.onkeypress，通过 new Image().src 外泄按键记录，并在不提交表单的情况下窃取凭证。参见 Attribute-only login XSS behind WAFs 了解实用流程。

Same Origin + Cookies

如果你发现受限的 XSS 或子域接管，你可以利用 cookies（例如进行 cookie fixation）来尝试危害受害者账号：

Cookies Hacking

攻击 Password Reset 机制

Reset/Forgotten Password Bypass

信任客户端提供的用户名的 Security-question 重置

如果“更新 security questions”流程接受一个 username 参数，即使调用者已经通过认证，你仍然可以覆盖任意账户的恢复数据（包括管理员），因为后端通常会用你不可信的值执行 UPDATE ... WHERE user_name = ?。模式如下：

  1. 使用一个可抛弃的用户登录并捕获 session cookie。
  2. 通过重置表单提交受害者的 username 加上新的答案。
  3. 立即通过 security-question login 端点使用你刚注入的答案进行认证，从而继承受害者的权限。
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

任何受害者的 $_SESSION 上下文所限制的资源（admin dashboards, dangerous stream-wrapper features, etc.）现在无需接触真实凭证即可被访问。

已枚举的用户名随后可以通过上面的 overwrite technique 定位，或重新用于辅助服务（FTP/SSH password spraying）。

Response Manipulation

如果认证响应可以被简化为一个简单的 boolean，只需尝试将 false 改为 true，看看是否能获得访问。

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. 在发起 password reset 请求后，修改 Host header。
  2. 将 X-Forwarded-For proxy header 修改为 attacker.com。
  3. 同时将 Host、Referrer 和 Origin headers 更改为 attacker.com。
  4. 在发起 password reset 并选择重发邮件后，采用上述三种方法。

Response Manipulation

  1. Code Manipulation: 状态码被修改为 200 OK。
  2. Code and Body Manipulation:
  • 状态码被更改为 200 OK。
  • 响应体被修改为 {“success”:true} 或一个空对象 {}。

这些响应篡改技术在使用 JSON 进行数据传输和接收的场景中有效。

更改当前会话的邮箱

From this report:

  • Attacker 请求将其 email 更改为一个新的
  • Attacker 收到一个用于确认 email 更改的链接
  • Attacker 将该链接发送给 victim，victim 点击它
  • victim 的 email 被改为 attacker 指定的地址
  • 攻击者可以恢复密码并接管该账户

This also happened in this report.

Bypass email verification for Account Takeover

  • Attacker 使用 attacker@test.com 登录并在注册时验证 email。
  • Attacker 将已验证的 email 更改为 victim@test.com（email 更改时没有二次验证）
  • 现在网站允许 victim@test.com 登录，我们已经绕过了 victim 用户的 email 验证。

Old Cookies

正如 in this post 所解释的，曾经可以登录一个账户，作为已认证用户保存 cookies，登出，然后再次登录。
随着新的登录，虽然可能会生成不同的 cookies，但旧的 cookies 又再次生效。

Trusted device cookies + batch API leakage

当 batch API 允许你将不可读的 subresponses 复制到可写的 sinks 时，用于恢复门控的长期有效 device identifiers 可能被窃取。

  • 识别一个 trusted-device cookie (SameSite=None, long-lived)，用于放宽恢复检查。
  • 找到一个 first-party endpoint，它在 JSON 中返回该 device ID（例如，一个 OAuth code 交换返回 machine_id），但该 endpoint 不支持跨源读取。
  • 使用一个 batch/chained API，它允许引用先前的 subresponses ({result=name:$.path}) 并将它们写入可被攻击者看到的 sink（页面 post、upload-by-URL 等）。示例（Facebook Graph API）：
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • 在隐藏的 <iframe> 中加载 batch URL，这样受害者会发送 trusted-device cookie；JSON-path 引用会将 machine_id 复制到攻击者控制的 post 中，即使 OAuth 响应对页面不可读。
  • Replay: 在新会话中设置被窃取的 device cookie。Recovery 现在将浏览器视为可信，通常会暴露较弱的 “no email/phone” flows（例如 automated document upload），允许在没有密码或 2FA 的情况下添加攻击者 email。

参考

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks