ソース：
脆弱性：IDOR、ATO
訳：
今日は、興味深い発見と私が学んだ教訓を共有したいと思い。
3 つのバグ (1 つは中程度 + 2 影響なし) を連鎖させると、クリック数 0 のアカウント乗っ取り (高/重大) が発生し。
ターゲットのドメインを target.com とし。
①役に立たないIDOR
最初のバグは「パスワード変更」機能に関するもので。
パスワードを変更するには、古いパスワードと新しいパスワードが必要で。
URL は次のようなものでした: GET /api/v2/customers/change-password/”6_digits_id” 。 この ID は、最後の 4 桁だけが可変であり、ID の変化が増分 ( x+1 ) であるため、総当たり攻撃が容易で。
ID をランダムな 6 桁に変更するだけで、この IDOR を使用する他のユーザーのパスワードを変更できますが、問題が 2 つあり。
1 つ目: 認証 プロセスにはメールアドレスとパスワードが必要なので、パスワードを変更してもメアドがわかりません。
被害者の電子メールを受信すると、被害者は簡単にパスワードをリセットでき。
2 つ目: 変更するための「古い」パスワードがわからず。
影響は?
単純です、ありません。
でも、メモには書いておきました。
②役に立たないno Rate-Limit
先ほども述べたように、パスワードを変更するには新旧のパスワードが必要ですが、この「パスワード変更」リクエストにはレート制限がないことがわかり。
したがって、必要なだけリクエストを送信でき、禁止されたりブロックされたりすることはなく。
影響は？
単純に、それは低いか、まったくありません。
でも、メモには書いておきました。
③ゲームチェンジャーのIDOR
いよいよメインのバグで。
最も重要なものである 「電子メール」を含む他のユーザーの PII を漏洩する 2 番目の IDOR を発見し。
URL は GET /api/orderbox/v2/reseller/customers/”6_digits_id” で。
最初の「役に立たない」IDOR と同じ ID で、 ID をランダムな ID に変更するだけで、メールアドレスを含む顧客情報を取得でき。
④究極のコンボ
これらすべてを連鎖させてみて:
- 3 番目のバグを使用すると、被害者のメールアドレスが得られ。
- 1 番目のバグを使用すると、同じ ID であるため、同じ被害者のパスワードを変更でき。
- 「古い」パスワードの問題を回避するには、2 番目のバグ (パスワード変更のレート制限なし) を使用してブルート フォース攻撃を行い。
このバグが連鎖すると、0 クリックによる大規模なアカウント乗っ取りが発生し。
その日の教訓:
- バグを過小評価しないでください。
ただ書き留めてください。
たぶん後で必要になるでしょう - 影響を拡大するために、常にバグを連鎖させるようにしてください。
ほなほな。
