アカウント乗っ取り

Reading time: 9 minutes

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

認証の問題

アカウントのメールアドレスを変更しようとし、確認プロセスを確認する必要があります。もし弱いと判断された場合、メールアドレスを意図した被害者のものに変更し、その後確認します。

Unicode正規化の問題

  1. 意図した被害者のアカウント victim@gmail.com
  2. Unicodeを使用してアカウントを作成する必要があります
    例えば: vićtim@gmail.com

このトークで説明されているように、前述の攻撃はサードパーティのアイデンティティプロバイダーを悪用して行うこともできます:

  • 被害者に似たメールアドレスを持つサードパーティのアイデンティティでアカウントを作成します(例: vićtim@company.com)。
  • サードパーティのプロバイダーはメールを確認しないべきです。
  • もしアイデンティティプロバイダーがメールを確認する場合、ドメイン部分を攻撃することができるかもしれません。例えば: victim@ćompany.comとしてそのドメインを登録し、アイデンティティプロバイダーがドメインのasciiバージョンを生成することを期待します。
  • このアイデンティティプロバイダーを通じて被害者のプラットフォームにログインし、Unicode文字を正規化して被害者のアカウントにアクセスできるようにします。

詳細については、Unicode正規化に関する文書を参照してください:

Unicode Normalization

リセットトークンの再利用

ターゲットシステムがリセットリンクの再利用を許可する場合、gauwayback、またはscan.ioなどのツールを使用してさらに多くのリセットリンクを見つける努力をする必要があります。

アカウント乗っ取り前の準備

  1. 被害者のメールアドレスを使用してプラットフォームにサインアップし、パスワードを設定します(確認を試みる必要がありますが、被害者のメールにアクセスできない場合は不可能かもしれません)。
  2. 被害者がOAuthを使用してサインアップし、アカウントを確認するまで待ちます。
  3. 通常のサインアップが確認されることを期待し、被害者のアカウントにアクセスできるようにします。

CORSの誤設定によるアカウント乗っ取り

ページにCORSの誤設定が含まれている場合、ユーザーから機密情報を盗むことができ、アカウントを乗っ取ることができるか、同じ目的のために認証情報を変更させることができるかもしれません:

CORS - Misconfigurations & Bypass

CSRFによるアカウント乗っ取り

ページがCSRFに対して脆弱な場合、ユーザーにパスワード、メール、または認証を変更させることができ、その後アクセスできるようになります:

CSRF (Cross Site Request Forgery)

XSSによるアカウント乗っ取り

アプリケーションにXSSが見つかった場合、クッキー、ローカルストレージ、またはアカウントを乗っ取ることができる情報を盗むことができるかもしれません:

XSS (Cross Site Scripting)

同一オリジン + クッキー

制限されたXSSやサブドメインの乗っ取りが見つかった場合、クッキーを操作(例えば、固定する)して被害者のアカウントを危険にさらすことができるかもしれません:

Cookies Hacking

パスワードリセットメカニズムへの攻撃

Reset/Forgotten Password Bypass

レスポンス操作

認証レスポンスを単純なブール値に減らすことができる場合、falseをtrueに変更してアクセスできるか確認します。

OAuthによるアカウント乗っ取り

OAuth to Account takeover

ホストヘッダーインジェクション

  1. パスワードリセットリクエストの開始に続いて、ホストヘッダーが変更されます。
  2. X-Forwarded-Forプロキシヘッダーがattacker.comに変更されます。
  3. ホスト、リファラー、およびオリジンヘッダーが同時にattacker.comに変更されます。
  4. パスワードリセットを開始し、メールを再送信することを選択した後、上記の3つの方法がすべて使用されます。

レスポンス操作

  1. コード操作: ステータスコードが200 OKに変更されます。
  2. コードとボディの操作:
  • ステータスコードが200 OKに変更されます。
  • レスポンスボディが{"success":true}または空のオブジェクト{}に変更されます。

これらの操作技術は、JSONがデータの送信と受信に使用されるシナリオで効果的です。

現在のセッションのメールアドレスを変更

このレポートから:

  • 攻撃者が新しいメールアドレスに変更をリクエストします。
  • 攻撃者はメールの変更を確認するためのリンクを受け取ります。
  • 攻撃者は被害者にそのリンクを送信し、クリックさせます。
  • 被害者のメールアドレスが攻撃者が示したものに変更されます。
  • 攻撃者はパスワードを回復し、アカウントを乗っ取ることができます。

これはこのレポートでも発生しました。

アカウント乗っ取りのためのメール確認のバイパス

  • 攻撃者がattacker@test.comでログインし、サインアップ時にメールを確認します。
  • 攻撃者が確認済みのメールをvictim@test.comに変更します(メール変更に対する二次確認はありません)。
  • 現在、ウェブサイトはvictim@test.comでのログインを許可し、被害者ユーザーのメール確認をバイパスしました。

古いクッキー

この投稿で説明されているように、アカウントにログインし、認証されたユーザーとしてクッキーを保存し、ログアウトし、その後再度ログインすることが可能でした。
新しいログインでは異なるクッキーが生成されるかもしれませんが、古いクッキーが再び機能するようになりました。

参考文献

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