Race Condition
Last updated
Last updated
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得：
この技術を深く理解するには、https://portswigger.net/research/smashing-the-state-machineの元のレポートを確認してください。
レースコンディションを利用する際の主な障害は、複数のリクエストが同時に処理されることを確実にすることであり、処理時間の差が非常に少ないこと—理想的には1ms未満です。
ここでは、リクエストを同期させるためのいくつかの技術を紹介します：
HTTP/2：単一のTCP接続を介して2つのリクエストを送信することをサポートし、ネットワークのジッターの影響を軽減します。ただし、サーバー側の変動により、2つのリクエストでは一貫したレースコンディションの悪用には不十分な場合があります。
HTTP/1.1 'ラストバイト同期'：20-30のリクエストのほとんどの部分を事前に送信し、小さな断片を保持し、それを一緒に送信することで、サーバーへの同時到着を実現します。
ラストバイト同期の準備には以下が含まれます：
ストリームを終了せずに最終バイトを除いたヘッダーとボディデータを送信します。
初回送信後に100ms待機します。
TCP_NODELAYを無効にして、Nagleのアルゴリズムを利用して最終フレームをバッチ処理します。
接続を温めるためにピングを送信します。
その後、保持されたフレームを送信すると、Wiresharkで確認できるように、単一のパケットで到着するはずです。この方法は、通常RC攻撃に関与しない静的ファイルには適用されません。
ターゲットのアーキテクチャを理解することは重要です。フロントエンドサーバーはリクエストを異なる方法でルーティングする可能性があり、タイミングに影響を与えます。無関係なリクエストを通じてサーバー側の接続を事前に温めることで、リクエストのタイミングを正規化できるかもしれません。
PHPのセッションハンドラーのようなフレームワークは、セッションごとにリクエストをシリアライズし、脆弱性を隠す可能性があります。各リクエストに異なるセッショントークンを使用することで、この問題を回避できます。
接続の温めが効果的でない場合、ダミーリクエストの洪水を通じてウェブサーバーのレートまたはリソース制限の遅延を意図的に引き起こすことで、レースコンディションに適したサーバー側の遅延を誘発し、シングルパケット攻撃を促進できるかもしれません。
Tubo Intruder - HTTP2シングルパケット攻撃（1エンドポイント）：リクエストをTurbo intruderに送信できます（Extensions -> Turbo Intruder -> Send to Turbo Intruder）。リクエスト内の**%sの値をブルートフォースしたい値に変更できます。例えば、csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%sのように。そして、ドロップダウンからexamples/race-single-packer-attack.py**を選択します：
異なる値を送信する場合は、クリップボードからのワードリストを使用するこのコードで変更できます：
ウェブがHTTP2をサポートしていない場合（HTTP1.1のみ）、Engine.BURP2の代わりにEngine.THREADEDまたはEngine.BURPを使用してください。
Tubo Intruder - HTTP2シングルパケット攻撃（複数のエンドポイント）: 1つのエンドポイントにリクエストを送信し、その後他のエンドポイントに複数のリクエストを送信してRCEをトリガーする必要がある場合は、race-single-packet-attack.pyスクリプトを次のように変更できます:
Repeaterでも、Burp Suiteの新しい「Send group in parallel」オプションを介して利用可能です。
limit-overrunの場合、グループに同じリクエストを50回追加するだけで済みます。
connection warmingのために、グループの最初にウェブサーバーの非静的部分へのリクエストを追加することができます。
delayingプロセスのために、1つのリクエストと別のリクエストの間に追加のリクエストを挿入することができます。
multi-endpoint RCの場合、隠れた状態に送信されるリクエストを最初に送信し、その後に隠れた状態を悪用する50のリクエストを送信することができます。
自動化されたPythonスクリプト: このスクリプトの目的は、ユーザーのメールを変更し、新しいメールの確認トークンが最後のメールに届くまで継続的に確認することです（これは、コード内でメールを変更できるRCが見られたためで、確認が古いメールに送信される可能性があったため、メールを示す変数が最初のもので既に埋め込まれていました）。 「objetivo」という単語が受信したメールに見つかると、変更されたメールの確認トークンを受け取ったことがわかり、攻撃を終了します。
元の研究では、この攻撃には1,500バイトの制限があると説明されています。しかし、この投稿では、IP層のフラグメンテーションを使用してシングルパケット攻撃の1,500バイトの制限をTCPの65,535 Bウィンドウ制限に拡張する方法が説明されており（1つのパケットを複数のIPパケットに分割し、異なる順序で送信することで）、すべてのフラグメントがサーバーに到達するまでパケットの再構成を防ぐことができました。この技術により、研究者は約166msで10,000リクエストを送信することができました。
この改善により、同時に到着する必要がある数百/数千のパケットを必要とするRC攻撃がより信頼性の高いものになりますが、いくつかのソフトウェア制限がある可能性もあります。Apache、Nginx、Goなどの人気のあるHTTPサーバーには、SETTINGS_MAX_CONCURRENT_STREAMS設定がそれぞれ100、128、250に厳格に設定されています。しかし、NodeJSやnghttp2のような他のものは無制限です。
これは基本的に、Apacheが単一のTCP接続から100のHTTP接続のみを考慮することを意味し（このRC攻撃を制限します）。
この技術を使用したいくつかの例は、リポジトリhttps://github.com/Ry0taK/first-sequence-sync/tree/mainで見つけることができます。
前の研究の前に、RCを引き起こすためにパケットをできるだけ早く送信しようとしたいくつかのペイロードがありました。
リピーター: 前のセクションの例を確認してください。
侵入者: リクエストを侵入者に送信し、オプションメニュー内でスレッド数を30に設定し、ペイロードとしてヌルペイロードを選択し、30を生成します。
ターボ侵入者
Python - asyncio
これは、アクションを実行できる回数を制限する場所に現れる 脆弱性の最も基本的なタイプのレースコンディションです。例えば、ウェブストアで同じ割引コードを何度も使用することです。非常に簡単な例はこのレポートやこのバグに見られます。
この種の攻撃には多くのバリエーションがあります。例えば：
ギフトカードを複数回利用する
製品を複数回評価する
アカウント残高を超えて現金を引き出したり転送したりする
単一のCAPTCHA解決策を再利用する
アンチブルートフォースレート制限を回避する
複雑なレースコンディションを悪用することは、隠れたまたは意図しないマシンのサブステートと相互作用するための短い機会を利用することを含むことがよくあります。これにアプローチする方法は次のとおりです：
潜在的な隠れたサブステートを特定する
ユーザープロファイルやパスワードリセットプロセスなど、重要なデータを変更または相互作用するエンドポイントを特定します。以下に焦点を当てます：
ストレージ：クライアント側のデータを扱うエンドポイントよりも、サーバー側の永続データを操作するエンドポイントを優先します。
アクション：新しいデータを追加するよりも、既存のデータを変更する操作を探します。これらの方が悪用可能な条件を作成する可能性が高いです。
キー：成功した攻撃は通常、同じ識別子（例：ユーザー名やリセットトークン）に基づく操作を含みます。
初期プロービングを実施する
特定したエンドポイントに対してレースコンディション攻撃をテストし、期待される結果からの逸脱を観察します。予期しない応答やアプリケーションの動作の変化は脆弱性を示す可能性があります。
脆弱性を示す
脆弱性を悪用するために必要な最小限のリクエスト数に攻撃を絞り込みます。通常は2回です。このステップでは、正確なタイミングが関与するため、複数回の試行や自動化が必要になることがあります。
リクエストのタイミングの精度は脆弱性を明らかにすることができ、特にタイムスタンプのような予測可能な方法がセキュリティトークンに使用される場合に顕著です。例えば、タイムスタンプに基づいてパスワードリセットトークンを生成すると、同時リクエストに対して同一のトークンが許可される可能性があります。
悪用するには：
単一パケット攻撃のような正確なタイミングを使用して、同時にパスワードリセットリクエストを行います。同一のトークンは脆弱性を示します。
例：
同時に2つのパスワードリセットトークンをリクエストし、それらを比較します。一致するトークンはトークン生成の欠陥を示唆します。
これを試すには PortSwigger Lab をチェックしてください。
このPortSwigger Labをチェックして、支払いを行い、追加のアイテムを追加する方法を確認してください。それに対して支払う必要はありません。
アイデアは、メールアドレスを確認し、同時に別のものに変更することで、プラットフォームが変更された新しいものを確認するかどうかを調べることです。
この研究によると、Gitlabはこの方法で乗っ取られる脆弱性があり、1つのメールの メール確認トークンを他のメールに送信する可能性があります。
これを試すには PortSwigger Lab をチェックしてください。
2つの異なる書き込みがデータベース内に情報を追加するために使用される場合、最初のデータのみがデータベースに書き込まれた小さな時間の部分があります。例えば、ユーザーを作成する際に、ユーザー名とパスワードが書き込まれ、新しく作成されたアカウントを確認するためのトークンが書き込まれます。これは、短い時間の間にアカウントを確認するためのトークンがnullであることを意味します。
したがって、アカウントを登録し、空のトークン（token=またはtoken[]=または他のバリエーション）を使用してアカウントをすぐに確認するために複数のリクエストを送信することで、メールを制御していないアカウントを確認することができる可能性があります。
これを試すには PortSwigger Lab をチェックしてください。
以下の擬似コードは、セッションが作成されている間に2FAが強制されていない非常に短い時間があるため、レースコンディションに対して脆弱です：
いくつかの OAUth プロバイダー があります。これらのサービスは、アプリケーションを作成し、プロバイダーが登録したユーザーを認証することを可能にします。そのためには、クライアントがあなたのアプリケーションにOAUth プロバイダー内のデータにアクセスすることを許可する必要があります。 ここまで、google/linkedin/githubなどの一般的なログインで、"アプリケーション <InsertCoolName> があなたの情報にアクセスしたいと考えています。許可しますか？"というページが表示されます。
authorization_code におけるレースコンディション問題は、あなたがそれを受け入れると、悪意のあるアプリケーションに**authorization_codeが自動的に送信されるときに発生します。その後、このアプリケーションは OAUth サービスプロバイダーのレースコンディションを悪用して、あなたのアカウントの**authorization_codeから複数の AT/RT (認証トークン/リフレッシュトークン) を生成します。基本的に、あなたがアプリケーションにデータへのアクセスを許可した事実を悪用して、複数のアカウントを作成します。その後、もしあなたがアプリケーションにデータへのアクセスを許可しなくなった場合、1対の AT/RT は削除されますが、他のものはまだ有効です。
Refresh Token におけるレースコンディション一度有効な RTを取得すると、複数の AT/RTを生成するためにそれを悪用しようとすることができます。さらに、ユーザーが悪意のあるアプリケーションにデータへのアクセスの権限をキャンセルしても、複数の RT はまだ有効です。
WS_RaceCondition_PoC では、レースコンディションを Web ソケットでも悪用するために、並行して WebSocket メッセージを送信するJava の PoC を見つけることができます。
Trickest を使用して、世界で最も高度なコミュニティツールによって駆動されるワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得：
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
AWS ハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCP ハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
