8/18追記 2023.9.1安定版リリースで、2023.8のアーリーアダプターの内容が取り込まれたため、本記事も安定版に書き換えております。
はじめに
この記事は、Burp Suiteのリリース内容について抄訳した内容と筆者の気になるポイントを記載しています。
Burpを使用して診断を行う方を対象にしていますので、バグ修正のような細かい変更点については本記事で触れない場合がございます。
原文をご確認されたい方は、公式のリリースノートをご覧ください。
このリリースでは、Black Hat USA 2023でJames Kettle氏が講演した「Smashing the State Machine: The True Potential of Web Race Conditions」で初めて発表されました。
Repeaterの新しいシングルパケット攻撃機能は、ネットワーク・ジッターを無効化し、複数のリクエストを並行して送信することを可能にします。これらのリクエストは、非常に小さなタイムウィンドウ内に到着するように同期され、レースコンディションのテストがよりシンプルになります。
その他にも、IntruderにおけるHTTP/1コネクションの再利用機能、Targetツールの新しいプロジェクトレベルのCrawl pathsタブ、スキャン中のGraphQLイントロスペクションのサポートなど、Burp Suite ProfessionalとBurp Scannerに様々な改良を加えました。
Repeaterのグループ並行送信
RepeaterのGroup send optionsメニューに、Send group(Parallel)オプションが追加されました。タブグループでこのオプションを選択すると、Repeaterはグループのすべてのタブからのリクエストを一度に送信します。
Repeaterは並列リクエストを同期して、すべてのリクエストが同時に完全に到着するようにします。使用するHTTPバージョンによって、異なる同期技術を使用します：
- HTTP/2で送信する場合、Repeaterはシングルパケット攻撃を使ってグループを送信します。これは、複数のリクエストを1つのTCPパケットで送信するものです。
- HTTP/1で送信する場合、Repeaterはラストバイト同期を使用します。これは、複数のリクエストが同時接続で送信されますが、グループ内の各リクエストの最後のバイトが保留されます。短い遅延の後、これらの最後のバイトが各接続で同時に送信されます。
同期化されたリクエストを並列に送ることで、競合状態のテストが非常に 容易になります。この方法の詳細と、練習のための意図的に脆弱なラボについては、 Web Security Academy の Race conditions のトピックをチェックしてください。
IntruderでHTTP/1コネクションを再利用して攻撃を高速化
Intruderが複数のHTTP/1リクエストを発行するために接続を再利用するかどうかを制御できるようになりました。
これにより、HTTP/1を使用する場合、Burpがリクエストごとに新しいコネクションを開き、レスポンスを受信した後にコネクションを閉じる必要がなくなるため、攻撃の速度を大幅に向上させることができます。
Intruder > Settings > HTTP/1 connection reuseで確認できます。
サードパーティのプロジェクトファイルを安全に開く
プロジェクトを信頼するかしないかを設定できる新しいスタートアップ設定を導入しました。
[Trust this project]の選択を解除すると、Burpはプロジェクトファイル内に設定されている可能性のある有害な設定を削除できるようになりました。
未知のソースや信頼できないソースから来たプロジェクトファイルを開く場合に便利になります。
この設定はスタートアップウィザード、またはSettings > Suite > Startup behavior > Unrecognized project filesで確認できます。
ハードウェアトークンとスマートカードの中間CA証明書の指定
ハードウェアトークンおよびスマートカード用の新しい PKCS#11 証明書を追加するときに、中間証明書を設定できるようになりました。これにより、中間 CA を直接信頼しないターゲット・アプリケーションをテストできます。 Settings > Network > TLS > Client TLS certificatesで確認できます。
リピーターでのカスタムSNI値の設定
RepeaterでカスタムSNI値を設定できるようになりました。
SNI内のCollaboratorペイロードを使用してScannerが検出した外部サービスとの相互作用の問題を再現できるようになります。
この設定はRepeater > Configure target detailsで確認できます。
プロジェクトレベルのスキャンのクロールパス
プロジェクト内のすべてのスキャンでクロールパス情報を共有できるようになりました。
新しいスキャンを実行する際にBurp Scannerが既に発見したパスをもとにスキャンを行うことができます。
TargetメニューのCrawl pathsタブから確認することができます。このタブは、既存のスキャン結果のCrawl pathsタブと同じ方法でパス情報を表示しますが、個々のスキャンではなく、すべてのスキャンのクロールパスが追加されます。新しいスキャンを実行すると、このタブに表示される情報を参照し、追加することができます。
Isolated Scan
グローバルなクロールパスの作業の一環として、スキャンランチャーにRun isolated scanオプションを追加しました。isolated scanの結果は、Target > Site map or Target > Crawl pathsタブ、およびダッシュボードのissueアクティビティログには表示されません。
この機能は、ライブスキャンの結果に影響を与えずに設定をテストしたい場合などに便利です。
Tasks > View details > Target タブで、isolated scanのサイトマップとクロールパスの情報を表示できます。このタブに表示される情報は、選択したスキャン タスクにのみ適用されます。
GraphQLイントロスペクション
Burp ScannerはGraphQLエンドポイントでイントロスペクション・クエリーを実行し、利用可能なクエリーや変異に関する情報を取得できるようになりました。
イントロスペクション・クエリーが成功した場合、Burp Scannerは発見された各クエリーと変異に対してさらにリクエストを送信し、可能な限り多くの攻撃対象領域を発見しようとします。GraphQLイントロスペクションを有効にするには、スキャン設定のMiscellaneousセクションで新しいPerform GraphQL introspection設定を選択します。
クロールでGraphQLエンドポイントが見つからなかった場合、Burp Scannerは一般的なエンドポイントの接尾辞のリストを使用してGraphQLエンドポイントの推測を試みることもできるようになりました。
GraphQLエンドポイントの推測を有効にするには、Crawlスキャン設定のMiscellaneousセクションで新しいTest common GraphQL endpoints設定を選択します。
スキャンの自動スロットリング
スキャンランチャーのResource poolセクションに新しいAutomatic throttling設定を追加しました。Burp Scannerがリクエスト間に短い遅延を導入するHTTPレスポンスコードを設定できるようになりました。以前は、サーバーがHTTP 429コードで応答した場合のみ、Burp Scannerはリクエストをスロットルすることができました。
その他のBurp Scannerの改善点
興味深いコンテンツが見逃される可能性を減らすために、クロールの最適化を改善しました。具体的には、Burp Scannerは、同じイベントリスナーを使用して表示テキストが異なるclickableを別個のエンティティとして扱い、それらをすべて訪問するようになりました。
バグ修正
以下のような細かいバグを修正しました：
- 302/400 レスポンスを検査した後に 200 レスポンスを検査すると、Proxyのresponseパネルがフリーズする問題を修正しました。
- Send to Organizer機能の信頼性を向上させました。
- 一部の古いバージョンのBurpでIntruderによって生成されたリクエスト/レスポンスが、新しいバージョンで表示されない問題を修正しました。
- クローラーが、DOMの変異を引き起こす低速の非同期クエリーを常に待機して返さないバグを修正しました。これによりページの読み込みが遅くなったり、特定の状況で要素が欠落したりすることがありました。
ブラウザのアップグレード
Burpの内蔵ブラウザをWindowsとLinuxは115.0.5790.110、Macは115.0.5790.114にアップグレードしました。
気になるポイント
Repeaterのグループ並行送信
毎年この時期になると、BHUSAの発表に合わせてBurpにも新機能が搭載されるので、わくわくしますよね！
今年はレースコンディション発表でしたね。論文のほうも文字量が多いので、ゆっくり理解しようと思います。
GraphQLイントロスペクション
Crawlのタイミングで、GraphQLのイントロスペクションクエリの送付や、エンドポイントの探索をするようになりました。
これでよくあるエンドポイントであれば見つけてこれるようになるので、わざわざスキャン対象に含めなくてもよくなりましたね。
時間があれば、どのような内容が送付されるのか、common endpointsはどのような内容なのか別記事でまとめたいと思います！