Account Takeover

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をサポートする

Authorization Issue

アカウントのメールアドレスを変更できるか試み、確認プロセスを必ず検査する。確認プロセスが弱いと判明した場合、メールを対象の被害者のものに変更して確認を行う。

Unicode Normalization Issue

  1. 対象被害者のアカウント: victim@gmail.com
  2. Unicode を使ってアカウントを作成する。例: vićtim@gmail.com

this talk で説明されているように、前述の攻撃はサードパーティの identity providers を悪用して行うこともできる:

  • サードパーティ identity に、被害者と類似したメール（Unicode 文字を含む）でアカウントを作成する（例: vićtim@company.com）。
  • サードパーティ provider がメールを検証しないこと。
  • もし identity provider がメールを検証する場合は、ドメイン部分を狙うことが考えられる：victim@ćompany.com のようにそのドメインを登録し、identity provider がドメインの ASCII 版を生成する一方で被害者側プラットフォームがドメイン名を正規化することを期待する。
  • この identity provider 経由で被害者プラットフォームにログインすると、プラットフォームが Unicode 文字を正規化して被害者アカウントにアクセスできる可能性がある。

For further details, refer to the document on Unicode Normalization:

Unicode Normalization

Reusing Reset Token

Should the target system allow the reset link to be reused, efforts should be made to find more reset links using tools such as gau, wayback, or scan.io.

Pre Account Takeover

  1. 被害者のメールを使ってプラットフォームにサインアップし、パスワードを設定する（確認を試みること。ただし被害者のメールにアクセスできないと不可能な場合がある）。
  2. 被害者が OAuth でサインアップしてアカウントを確認するまで待つ。
  3. 通常のサインアップが確認されれば、被害者のアカウントへアクセスできることを期待する。

CORS Misconfiguration to Account Takeover

If the page contains CORS misconfigurations you might be able to steal sensitive information from the user to takeover his account or make him change auth information for the same purpose:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

ページが CSRF に脆弱であれば、ユーザにパスワード、メール、または認証情報を変更させ、それによりアクセスできるようにすることが可能です:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

アプリケーションで XSS を見つけた場合、クッキー、local storage、またはウェブページ上の情報を盗んでアカウントを乗っ取ることができる可能性がある:

XSS (Cross Site Scripting)

  • ログインページでの attribute-only reflected payloads は document.onkeypress をフックし、new Image().src 経由でキー入力を外部送信し、フォームを送信せずに認証情報を盗むことができます。実践的なワークフローは Attribute-only login XSS behind WAFs を参照してください。

Same Origin + Cookies

限定的な XSS やサブドメイン takeover を発見した場合、クッキー（例えば fixating）を操作して被害者アカウントを侵害することが可能です:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames もし “update security questions” フローが呼び出し元が既に認証済みであっても username パラメータを受け取る場合、バックエンドが典型的に UPDATE ... WHERE user_name = ? をあなたの信頼できない値で実行するため、任意のアカウント（管理者を含む）のリカバリデータを上書きできる。パターンは次のとおり:

  1. 使い捨てユーザでログインし、セッションクッキーを取得する。
  2. リセットフォーム経由で被害者の username と新しい回答を送信する。
  3. 注入した回答を使って security-question のログインエンドポイントで直ちに認証し、被害者の権限を継承する。
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

Anything gated by the victim’s $_SESSION context (admin dashboards, dangerous stream-wrapper features, etc.) is now exposed without touching the real answers.

列挙されたユーザ名は、その後上記の overwrite technique を使って標的にしたり、補助的なサービス（FTP/SSH password spraying）に対して再利用できます。

Response Manipulation

If the authentication response could be reduced to a simple boolean just try to change false to true and see if you get any access.

もし認証レスポンスを単純なブール値に簡約できるなら、false を true に変更してアクセスが得られるか試してみてください。

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. The Host header is modified following a password reset request initiation.

  2. The X-Forwarded-For proxy header is altered to attacker.com.

  3. The Host, Referrer, and Origin headers are simultaneously changed to attacker.com.

  4. After initiating a password reset and then opting to resend the mail, all three of the aforementioned methods are employed.

  5. パスワードリセット要求の開始後に Host ヘッダが変更される。

  6. X-Forwarded-For プロキシヘッダが attacker.com に変更される。

  7. Host、Referrer、Origin ヘッダが同時に attacker.com に変更される。

  8. パスワードリセットを開始してからメールを再送するよう選択すると、前述の3つの方法すべてが適用される。

Response Manipulation

  1. Code Manipulation: The status code is altered to 200 OK.
  2. Code and Body Manipulation:
  • The status code is changed to 200 OK.
  • The response body is modified to {"success":true} or an empty object {}.
  1. Code Manipulation: ステータスコードが 200 OK に変更される。
  2. Code and Body Manipulation:
  • ステータスコードが 200 OK に変更される。
  • レスポンスボディが {"success":true} または空のオブジェクト {} に変更される。

These manipulation techniques are effective in scenarios where JSON is utilized for data transmission and receipt.

これらの操作手法は、JSON がデータ送受信に用いられているシナリオで有効です。

Change email of current session

From this report:

  • Attacker requests to change his email with a new one
  • Attacker receives a link to confirm the change of the email
  • Attacker send the victim the link so he clicks it
  • The victims email is changed to the one indicated by the attacker
  • The attack can recover the password and take over the account

以下は this report からの内容です：

  • Attacker が自分のメールアドレスを新しいものに変更するリクエストを送る
  • Attacker がメールアドレス変更を確認するためのリンクを受け取る
  • Attacker がそのリンクを被害者に送り、被害者がクリックするよう仕向ける
  • 被害者のメールは Attacker が指定したメールに変更される
  • 攻撃者はパスワードの回復を行い、アカウントを乗っ取ることができる

This also happened in this report.

これも this report で発生しました。

Bypass email verification for Account Takeover

  • Attacker logins with attacker@test.com and verifies email upon signup.

  • Attacker changes verified email to victim@test.com (no secondary verification on email change)

  • Now the website allows victim@test.com to login and we have bypassed email verification of victim user.

  • Attacker が attacker@test.com でログインし、signup 時にメールを検証する。

  • Attacker が検証済みのメールを victim@test.com に変更する（メール変更時に追加の検証が行われない）。

  • これによりサイトは victim@test.com でのログインを許可し、被害者の email verification をバイパスできる。

Old Cookies

As explained in this post, it was possible to login into an account, save the cookies as an authenticated user, logout, and then login again.
With the new login, although different cookies might be generated the old ones became to work again.

説明されているように in this post、アカウントにログインして認証済みユーザとして cookies を保存し、ログアウトした後に再度ログインすることが可能でした。
新しいログインでは異なる cookies が生成される場合があるにもかかわらず、古い cookies が再び有効になりました。

Trusted device cookies + batch API leakage

Long-lived device identifiers that gate recovery can be stolen when a batch API lets you copy unreadable subresponses into writable sinks.

  • Identify a trusted-device cookie (SameSite=None, long-lived) used to relax recovery checks.
  • Find a first-party endpoint that returns that device ID in JSON (e.g., an OAuth code exchange returning machine_id) but is not readable cross-origin.
  • Use a batch/chained API that allows referencing earlier subresponses ({result=name:$.path}) and writing them to an attacker-visible sink (page post, upload-by-URL, etc.). Example with Facebook Graph API:

回復を緩和するために使用される長期有効な device identifiers は、batch API が読み取り不可能なサブレスポンスを攻撃者が閲覧可能な書き込み先にコピーさせる場合に盗まれる可能性があります。

  • 回復チェックを緩和するために使われる trusted-device cookie (SameSite=None, long-lived) を特定する。
  • そのデバイスIDを JSON で返す first-party endpoint（例: OAuth の code 交換で machine_id を返す）を見つけるが、それがクロスオリジンで読み取れないこと。
  • 先のサブレスポンスを参照（{result=name:$.path}）して攻撃者が閲覧可能なシンク（ページ投稿、upload-by-URL 等）に書き込める batch/chained API を利用する。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
  • バッチURLを非表示の <iframe> に読み込ませ、被害者がtrusted-device cookieを送信するようにする。JSON-path referenceがmachine_idをattacker-controlled postにコピーするため、OAuthレスポンスがページから読み取れなくても有効になる。
  • Replay: 新しいセッションで盗まれたdevice cookieをセットする。Recoveryはブラウザをtrustedとみなすようになり、しばしばより脆弱な「no email/phone」フロー（例：automated document upload）を露出させ、passwordや2FAなしでattacker 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をサポートする