ソース：
脆弱性：RaceCondition
訳：
競合状態とは何ですか?
競合状態は、複数のスレッドが共有データにアクセスでき、それを同時に変更しようとすると発生して。
スレッド スケジューリング アルゴリズムはいつでもスレッド間を切り替えることができるため、スレッドが共有データへのアクセスを試行する順序はわからず。
したがって、データ変更の結果はスレッド スケジューリング アルゴリズムに依存し。つまり、両方のスレッドがデータにアクセス/変更するために「競合」し。
そのようなシナリオはどこで探せばよいでしょうか?
バグハンティングは、Web アプリケーションまたはモバイル アプリケーションのフローを理解することがすべてで。
ターゲットを理解すればするほど、それを悪用することも容易になり。
クリティカル セクションは、2 つ以上のソースが同じリソースにアクセスしようとするようなタイプのシナリオに対して脆弱になる可能性があって。
最も一般的な攻撃ベクトルは、クーポンコード、招待コード、または特定のユーザーに対して 1 回だけ使用できるその他のデータを含むセクション。
まあ、これはもう意味があります....
なんと、バグ報奨金プログラムで同様のバグを発見したのです。
そこで私は、Bugcowd に長い間存在していた公開プログラムを探して。
偵察フェーズから始め。
偵察がバックグラウンドで行われている間、そのWebアプリの機能と動作を観察し。
この機能は現在ほとんどの企業に導入されているため、友達の招待に関するセクションがあって。
友達を誘ったらどうなるのか興味があり。
これに対して、国に応じて複数の報酬が与えられ。
英国には 1 つのオプションがあったように、ユーザーが 3 人の友人を招待し、(1 人あたり) 200 GBP を費やすたびに適用され、招待したユーザーには50GBP(ポンド)の報酬が与えられ。
この招待はどのように機能しますか?
招待中に 2 つのオプションが表示されました
- リンク経由で招待する
- クーポンコードで招待する
クーポンコードを使って遊んでみようと思い。
ここで、私が招待した友人が何度もクーポンコードをヒットし、サーバーはそれらのリクエストを受け入れますが、ユーザーはこれらのコードを 1 回しかヒットできないのはどうだろうかというアイデアが頭に浮かび。
次に、競合状態を調べようと考えましたが、これがどのように役立つでしょうか?
18 人のユーザーを招待したとします。この 18 人のユーザーがそれぞれ 200 GBP (つまり、18*200 = 3600 GBP) を費やすと、3 人のユーザーごとに 50 GBP (つまり、6*50=300 GBP) を得ることができて。
攻撃の時間
要件 ：
- 2 つのユーザー アカウント (user1 、 user2)
- Turbo Intruder (BurpSuite のプラグイン)
Turbo Intruder は、そのように構成されている場合、1 秒あたり 30,000 件のリクエストを送信できる非常に強力なツールです。
Turbo Intruder のインストールと使用法については、ここで完璧なチュートリアルを見つけ:
user1 アカウントから招待クーポンを受け取り。
サインアップ中に招待コードを入力するのを忘れた場合、プロフィールにオプションがあり、後で入力するオプションもあって。
そこで、user2 アカウントでサインアップし、user1 アカウントからコピーした招待コードを入力するセクションに移動し。
次に、そのクーポンコードを入力し、そのリクエストを Burp プロキシでキャプチャし。
本文セクションには次のようなリクエストが表示され。
{“referralToken”:”invitecode”}
招待コードをダブルクリックして選択し、ターボ侵入者にリクエストを送信します
すると、次のようなリクエストが表示され。
POST /gateway/v1/virality/guests/18343692/referrals HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
.
.
{“referralToken”:”%s”}
ご覧のとおり、ターボ侵入者は選択された招待コードを %s として設定し。
Turbo intruder は、必要に応じてリクエストを構成および実行するための Python スクリプトをサポートし。
スクリプトセクションのスクリプトを押して。
攻撃を実行し
ステータス コードが 200 個で残りが 40 個の応答が複数あることがわかり。
次に、これらのリクエストがサーバーによって受け入れられ、招待が user1 のプロファイルに反映されるかどうかを確認し。
user1 アカウントに切り替えて、招待されたユーザーを確認し。
競合状態の脆弱性が悪用され。
ほなほな。
