Exploiting a Race Condition Vulnerability から学ぶ

Bug Report

ソース：

medium.com

脆弱性：RaceCondition

 

訳：

競合状態とは何ですか?

競合状態は、複数のスレッドが共有データにアクセスでき、それを同時に変更しようとすると発生して。
スレッド スケジューリング アルゴリズムはいつでもスレッド間を切り替えることができるため、スレッドが共有データへのアクセスを試行する順序はわからず。
したがって、データ変更の結果はスレッド スケジューリング アルゴリズムに依存し。つまり、両方のスレッドがデータにアクセス/変更するために「競合」し。

 

そのようなシナリオはどこで探せばよいでしょうか?

バグハンティングは、Web アプリケーションまたはモバイル アプリケーションのフローを理解することがすべてで。
ターゲットを理解すればするほど、それを悪用することも容易になり。

クリティカル セクションは、2 つ以上のソースが同じリソースにアクセスしようとするようなタイプのシナリオに対して脆弱になる可能性があって。
最も一般的な攻撃ベクトルは、クーポンコード、招待コード、または特定のユーザーに対して 1 回だけ使用できるその他のデータを含むセクション。
まあ、これはもう意味があります....

 

なんと、バグ報奨金プログラムで同様のバグを発見したのです。

そこで私は、Bugcowd に長い間存在していた公開プログラムを探して。
偵察フェーズから始め。
偵察がバックグラウンドで行われている間、そのWebアプリの機能と動作を観察し。

この機能は現在ほとんどの企業に導入されているため、友達の招待に関するセクションがあって。
友達を誘ったらどうなるのか興味があり。
これに対して、国に応じて複数の報酬が与えられ。

英国には 1 つのオプションがあったように、ユーザーが 3 人の友人を招待し、(1 人あたり) 200 GBP を費やすたびに適用され、招待したユーザーには50GBP(ポンド)の報酬が与えられ。

 

この招待はどのように機能しますか?

招待中に 2 つのオプションが表示されました

  1. リンク経由で招待する
  2. クーポンコードで招待する

クーポンコードを使って遊んでみようと思い。
ここで、私が招待した友人が何度もクーポンコードをヒットし、サーバーはそれらのリクエストを受け入れますが、ユーザーはこれらのコードを 1 回しかヒットできないのはどうだろうかというアイデアが頭に浮かび。

次に、競合状態を調べようと考えましたが、これがどのように役立つでしょうか?

18 人のユーザーを招待したとします。この 18 人のユーザーがそれぞれ 200 GBP (つまり、18*200 = 3600 GBP) を費やすと、3 人のユーザーごとに 50 GBP (つまり、6*50=300 GBP) を得ることができて。

 

攻撃の時間

要件 ：

  1. 2 つのユーザー アカウント (user1 、 user2)
  2. Turbo Intruder (BurpSuite のプラグイン)

Turbo Intruder は、そのように構成されている場合、1 秒あたり 30,000 件のリクエストを送信できる非常に強力なツールです。

Turbo Intruder のインストールと使用法については、ここで完璧なチュートリアルを見つけ:

 

portswigger.net

 

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
.

.

Cookie: {cookie_value}

{“referralToken”:”%s”}

 

ご覧のとおり、ターボ侵入者は選択された招待コードを %s として設定し。

Turbo intruder は、必要に応じてリクエストを構成および実行するための Python スクリプトをサポートし。
スクリプトセクションのスクリプトを押して。

 

ターボイントルーダーのスクリプト

攻撃を実行し

ステータス コードが 200 個で残りが 40 個の応答が複数あることがわかり。 

 

ターボ侵入者攻撃

次に、これらのリクエストがサーバーによって受け入れられ、招待が user1 のプロファイルに反映されるかどうかを確認し。
user1 アカウントに切り替えて、招待されたユーザーを確認し。 

 

user1 プロファイル

競合状態の脆弱性が悪用され。

 

ほなほな。

IDOR Lead to Data Leak から学ぶ

Bug Report

ソース：

melguerdawi.medium.com

脆弱性: IDOR

 

訳：

まず、アプリケーションの機能を分析して理解することから始め。
それがオンラインゲームプラットフォームであることを発見し。

 

テスト プロセスを開始するときに、/profile ページにアクセスし、Burp 履歴で隠れたリクエストを検索し。

 

 

HTTP メソッド OPTIONS を使用したリクエストが見つかり。

リクエストには 2 つのパラメータが含まれて。
player_id_or_name、ユーザーの ID または名前のいずれかを受け入れ。
event, ゲーム名を指定し。

リクエストをRepeaterに送信し、リクエストメソッドを OPTIONSに GET, ユーザーがプレイしたすべてのゲームのリストを取得することができて。

ユーザー名を自分のユーザーから別のユーザーに変更すると、そのユーザーのデータも取得できることがわかり。

 

 

私たちが見つけたデータは次のとおりで。

  • プレイヤーID(非公開)
  • 試合時間
  • 結果（勝ちか負けか）
  • 彼の試合でのハンドル
  • ゲーム名

プログラムはこれを P3 の問題として受け入れ。

 

ほなほな。

Exploiting XXE for SSRF から学ぶ

Bug Report

ソース：

medium.com

脆弱性：XXE, SSRF

 

訳：

xxe および ssrf を使用した EC2 インスタンスの IAM 認証情報の取得

サーバーサイド リクエスト フォージェリ (SSRF) :- SSRF は、攻撃者が脆弱なサーバーにサードパーティ サーバーや内部リソースへの悪意のあるリクエストを強制的にトリガーできる攻撃で。

 

XML 外部エンティティ (XXE): XML 外部エンティティ攻撃は、XML 入力を解析するアプリケーションに対する攻撃の一種で。
多くの場合、攻撃者はアプリケーション サーバー ファイル システム上のファイルを参照し、アプリケーション自体がアクセスできるバックエンドや外部システムと対話することができ、RCE にエスカレーションされる可能性もあって。

 

XXE の脆弱性をエスカレーションして SSRF を実行するにはどうすればよいですか?

これを悪用すると、攻撃者が WAF をバイパスしてローカル インフラストラクチャや内部ネットワークにアクセスし、機密情報の漏洩につながる可能性があり。

XXE のエスカレーションを通じて SSRF を利用するには、対象となる URL によって XML エンティティを識別し、定義されたエンティティを持つデータの値を使用する必要があり。
データ値、つまりアプリケーションの応答で返される特定のエンティティを使用することによって。
これで、アプリケーション応答内の URL からの応答を表示できるようになり。

<!DOCTYPE foo [ <!ENTITY id SYSTEM "http://localhost.com/"> ]>

この XXE ペイロードでは、外部エンティティである「id」が内部インフラストラクチャにアクセスするための HTTP バック接続を作成し。

 

搾取：

XXE に対して脆弱なサーバーがあり、そのサーバーは内部ネットワークへのアクセスを提供して。
ウェブサーバーは、デフォルトの URL で AWS メタデータ エンドポイントを実行していて。
EC2 メタデータ エンドポイントから IAM シークレット アクセス キーを取得する必要があり。

にあると仮定します。脆弱な EC2 インスタンスがこの IP アドレスhttp://192.168.1.220

以下のリクエストは、アプリケーションが XML を使用していることを示して。

 

 

応答では、XML が解析されていることがわかり、XXE の可能性があり。
そこで、さらに詳しく調べるために、XML ペイロードでランダムな文字列「blog」を渡し。
そのため、XXE ペイロード内のランダムな文字列を変更すると、その文字列が応答に反映され。
アプリケーションが XXE に対して脆弱であること。 

 

 

<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE foo [ <!ENTITY id SYSTEM “file:///etc/passwd”> ]>
<product><productId>&id;</productId></product>

 

ここでの id には、外部エンティティを定義し、productId 値でエンティティを使用する /etc/passwd ファイルの値が含まれています。 上記の xxe ペイロードをアプリケーションに応じて操作し、/etc/passwd ファイルの内容をフェッチできるようにファイル スキーマを使用し。

 

リクエストを送信した後。

 

 

Burp Collaborator を使用して SSRF を検証してみて。
ペイロードをクリップボードにコピーし、このペイロード内でその URL を使用し。
 

<!DOCTYPE foo [<!ENTITY ssrf SYSTEM “<Burp Collaborator Client >”> ]>

 

Burp Collaborater からリクエストがあって。
これは SSRF に対して脆弱であることを意味し。
次に、その URL からメタデータ情報を取得してみて。

 

メタデータのデフォルトのパスは「 /latest/meta-data/iam/security-credentials/ 」で。

 

これに指定された IP アドレスを追加して、リクエストを送信し。
以下に示すように、IT は秘密アクセス キーを取得して。

 

   

修復

· 文書型定義 (DTD) を無効にする。DTD を完全に無効にできない場合は、各パーサーに固有の方法で外部エンティティと外部文書型宣言を無効にする必要があって。

· 敵対的な XMS データに対するホワイトリスト ポリシーを実装し、これらのデータを簡単にバイパスできるようにして。

· XML データをアップロードできるファイル アップロードの脆弱性を検証して。

· バイパスの可能性を減らすために、XML プロセッサの更新されたバージョンを使用するようにして。

 

ほなほな。