ソース:
脆弱性:ビジネスロジック、RaceCondition、IDOR、SSRF、WAF
訳:
まとめ:
この対象プログラムは、Web スクレイピング機能と複数のログインアカウントを一度に簡単に利用できるブラウザ サービスを提供する会社で。
これはブラウザで使用するシークレット モードに非常に似ています。
ただし、これにより、何百ものシークレット ブラウザが複雑になることなく一度に提供され。
このアプリケーションは有料の料金プランのみを使用できます。
ソロプランの費用は約 80 ドル、最大 3 ユーザーまでのチームプランの費用は約 170 ドルだとして。
ユーザーが増えるとプラン価格が上がり。
追加のユーザーコストはユーザーあたり 32 ドルで。
また、基本プランさえなければ、アプリケーション機能の 90% にアクセスできない。 そこで私は、事業財務に直接影響を及ぼし、大きな損失を引き起こす 4 つのビジネス ロジックの脆弱性を発見して。
最初のものから始めましょう:
1. 最初の脆弱性: 追加メンバーを招待する際のビジネス ロジック
すでに述べたように、チーム プランでは最大 3 人のメンバーしか招待できず、メンバーあたりの追加料金は 32 ドルで。
すでに 3 人のメンバーを追加しましたが、これ以上追加できず。
まずメンバーを削除してから招待する必要があり。
しかし、ここで大きな設定ミスがあり。
まずは通常の流れを説明し。
- メンバーの詳細をすべて入力し、「招待を送信」をクリックします。
- メンバーは招待承諾リンクを取得し、そのリンクをクリックするだけでユーザーが追加され。
- メンバーがリンクを使用し、チームに追加されました。 このように、最大 3 人のメンバーを追加でき。
しかし、ここでは設定ミスがあり、ユーザーが招待を受け入れるまでメンバー数が増加しません。
つまり、最初に 10 人のメンバーに招待リンクを送信し、その後全員を受け入れることができ。
これをいくつかのステップに分けて説明して。
悪用手順:
- メンバーの詳細を入力し、招待リンクを送信し
- リンクを使用せずに、別のメンバーを再度追加して
- 追加するユーザーの数までこのプロセスを繰り返し
- まだ誰も招待を受け入れていないため、メンバー数は計画では 0 で
- 次に、送信されたすべての招待リンクに 1 つずつアクセスして。
すべてのメンバーは無料で追加され。
このようにして 6 人以上のユーザーを招待し、200 ドルを節約でき。
これにより、一度に 100 人のメンバーを追加することもでき、会社としては 320 ドルの損失が発生し。
彼らはすぐにこの脆弱性に対処し、修正し。
報酬:500USD
2. 2 番目の脆弱性: プランなしのユーザーはメンバーを招待できない
ここでも、計画のないユーザーは、他のメンバーをチームに招待する機能にアクセスできず。
ただし、セキュリティ構成に誤りがあるため、プラン ユーザー セッション トークンなしで招待ユーザーの API 呼び出しを直接送信でき。
したがって、私が実行した手順は次のとおりで。
- 新しいユーザーの招待を担当する POST リクエストをキャプチャし、このリクエストをリピーターに送信し。
- 認可トークンを計画のないユーザートークンに変更します。 ワークスペース ID パラメーターも変更されて。
- リクエストを送信し、成功しま。 禁止されたエラーを表示する代わりに。 ユーザーが招待されて。
報酬: 500USD
3. 3 番目の脆弱性: ブラウザ プロファイル作成時の競合状態
ここで、アプリケーションでは、作成する特定の数のブラウザー プロファイルのみが割り当てられて。
たとえば、ソロ プランでは 300 個のブラウザ プロファイルしか作成できません。
これは、競合状態、つまり、限られたプランのアクセスで 300 を超えるプロファイルを作成できるかどうかをテストするケースのように思え。
手順は次のとおりです。
- 最初に 298 個のプロファイルを作成しま
2. 次に、[新しいプロファイルの作成] を再度クリックし、バープスイートで
リクエストをキャプチャします。
3. このリクエストを内線番号 Turbo Intruder に送信し。
独自の Python スクリプトを使用することもできます。
ペイロード位置としてランダムな位置を追加し、スレッドを増やし。
4. 攻撃が終わったとき。 ブラウザ プロファイルの合計数は 306 で。
これは、競合状態の悪用が成功したことを示していて。 簡単ですよね?
報酬:500USD
4. 4 番目の脆弱性: 権限の低いユーザーが API を通じてワークスペースのデータを参照
アプリケーション内で、ユーザーを招待するとき。
3つの役割から選択できるオプションがあり。
つまり、ユーザー、ランチャー、マネージャー。 「ユーザー」ロールは、ワークスペース内のメンバー、その役割、招待されたメンバー、残高、どのプランに参加しているかなど、一部の詳細を表示できません。
ただし、「ユーザー」ロールの Cookie を使用して API を使用して同じ詳細をリクエストした場合、それらの詳細も取得できます。
エクスプロイトの正確な手順:
- まず、「ユーザー」ロール権限を持つメンバーを招待し
- この役割には、他のメンバーおよび使用されているプランを表示する権限がなく
- ただし、API 呼び出しを直接送信する必要があって。
つまり:
https://api.target.com/workspace/restrictions
https://api.target.com/workspace/users?limit=100&offset=0
https://api.target.com/workspace/invitations?limit=1000&offset=0
https://api.target.com/workspace/user_balance
4. このようにして、権限の低いメンバーとしてすべての詳細を取得することができました。
報酬: 500USD。
追加の脆弱性 : オリジン IP の漏洩によりファイアウォールのバイパスが発生します。
この後、ついに私はオリジン IP の脆弱性を報告して。
これにより、ドメインと機能が IP 経由で直接アクセスできるようになり。
クラウド フレア ファイアウォールの完全なバイパスにつながり。
また、ドメインからはアクセスできなかったが、見つかったオリジン IP を使用してアクセスできるいくつかのエンドポイントにアクセスすることもでき。
この単純な脆弱性に対して、彼らは私に 300 ドルの報酬を与えてくれました。
結論:
IDOR、SSRF、XSS などを見つける必要は必ずしもありません。
場合によっては、機能を理解し、可能な限りあらゆる方法でそれを悪用することだけが必要な場合もあり。
ほなほな。