脆弱性：AccountTakeOver (ATO)
訳：
脆弱なサブドメインが sub.redacted.comそして、それはAPI サブドメインを扱い、api.redacted.com。そして、私たちのサイトのパスワードを忘れた場合の機能は次のように機能して。
-
/forgetPassメールアドレスを入力してくださいにいき - メールアドレスが存在する場合、サイトはリセットメールを送信します。
メールアドレスが存在しない場合は、エラーが表示され。 - バックエンドは、ユーザーをリダイレクトするための一意のトークンを含むサードパーティのリンクを送信し。
https://sub.redacted.com/verify/<UNIQUE-HASH>へリダイレクト、新しいパスワードを入力するのに。
調べ始めました /forgetPass、そしてパスワードリセットリンクを要求したので、その要求を調べ始めました。
リクエストには不審な点は何もないので、サードパーティのリセットリンクを分析してみて。
したがって、受信箱で受信したリセット リンクをクリックすると、パスワードをリセットするためのエンドポイントが提供されます。 https://sub.redacted.com/verify/<UNIQUE-HASH>。
舞台裏で、リダイレクトされたとき https://sub.redacted.com/verify/<UNIQUE-HASH> ハッシュを検証するために使用されるリクエストがありapi.redacted.comで。
その応答は、パスワードのリセットを要求した電子メールで。
トークンで遊ぼうとしましたが、何も得られませんでした:(
続けてみましょう。次のリクエストはパスワードのリセットのリクエストで。
リクエストには 3 つのパラメータが必要です、 password& password_confirmation& email。
別のメールを入力しようとしましたが、この場合は被害者のメールでしたが、 400 bad request。
最後の写真では、いくつかのことがわかり。
- トークンの検証は別のリクエストで行われました。
- パスワードの変更リクエストには、アカウント所有者であることを証明するトークンなどは必要ありません。
- 被害者のメールアドレスに変更した時の対応が怪しかった、予想外だった
400 bad requestこれまで！
いくつかの既知のテクニックを検索して試してみましたが、実際には何も得られませんで。
翌日、私はサイトがどのようにパスワードをリセットするかを理解しようと続けて。
何かを見逃していると感じ、サイトで奇妙な動作が見られたためで。
私に与えられたのと同じ要求、初回と同じ 200 OK で。
同じリクエストを再度送信すると、 400 Bad request、被害者のメールアドレスを入力しようとしても同じ応答で!!
ということで、うーん、この時点でサイトのロジックは理解できたと思います。
このサイトはパスワードをリセットする際にトークンを必要とせず、同時に私にトークンを提供します。 400 Bad requestリセットして取得した後、別のメールを送信しようとしたり、別の機会にメールを送信しようとしたとき 200 OK。
サイトは、送信された 送信された電子メールが リセットリクエストで パスワードのリセットを要求したかどうかだけをチェックしていると思います。トークンや検証済みのハッシュに関係なく。 それでは、それを活用してみましょう!!
- まず、攻撃者と被害者の電子メールにパスワード リセット リンクを送信し。
- トークンは ID の検証に使用されないため役に立たない、トークンの検証はすべて無視。被害者がパスワードをリセットすることをサイトに知らせるだけで 、残りの手順は私たちが担当し。
つまり、サイトはそれを認識しました VICTIM-EMAIL@gmail.comパスワードをリセットし。
わかりました。
パスワードをリセットするための通常のプロセスを続行し。
サイトが password& password_confirmation& email私たちの電子メールを被害者の電子メールに置き換えます。
そして、彼のパスワードを正常にリセットでき。
ログインパネルに移動し、被害者のメールアドレスと設定したパスワードを入力すると……。
実はこんなに簡単にできるとは思っていませんでしたが、サイトの動作を理解するだけでも時間がかかり。
テスト対象がある場合、私は Github や LinkedIn から従業員の電子メールをできる限り収集し、デフォルトの資格情報などのために保管し。
そのため、今こそそれを使用する時期だと思い。
パスワードをリセットするリクエストを作成し、それを傍受して侵入者に送信し、リスト内のどのアカウントがサイトの管理者として存在するかを確認し。
そして出来上がり！ 存在することを発見しまし。
実際のところ、私は従業員のパスワードをリセットするためにさらに深くは行っておらず、従業員の 1 人を引き継ぐことができ、その従業員がサイトへの高い特権アクセス権を持っている可能性があることをセキュリティ チームに伝えただけで。
ほなほな。
