8/7～8にラスベガスで開催されたBlack Hat USAに参加してきました。筆者が参加したのは2016, 2017に引き続き3度目です（ブログ記事 2016年、2017年）。今年もWeb関連のブリーフィングを中心に報告します。

■HTTP Desync Attacks: Smashing into the Cell Next Door

https://www.blackhat.com/us-19/briefings/schedule/#http-desync-attacks-smashing-into-the-cell-next-door-15153

Burpの開発元であるPortSwigger社のJames Kettle氏の講演です。

発表した攻撃は、フロントエンドにプロキシなどが存在する場合に成立しえます。

図1（氏の発表スライドを再構成）

図のように、フロントからバックのWebサーバへの接続には複数のHTTPリクエストメッセージが流されます。攻撃者は、フロントとバックにおいてメッセージの切れ目の解釈が異なるようなHTTPリクエストを送り付けることで、バックにおけるリクエストメッセージの解釈を誤らせます。

切れ目の解釈が異なるようなHTTPリクエストは、例えば下記のようなものです。

図2（氏の発表スライドより）

Transfer-Encodingが「zchunked」となっているのは意図的です。これを一部のソフトウェアは正常なchunkedリクエストと解釈する一方、Content-Lengthにより終端を決めるソフトウェアもあります。

氏はこのような解釈の違いを生じさせることを「Desynchronization」と呼んでいます。発表ではこの「Desync」を利用して、

• フロント側で行なわれるアクセス制御をバイパス
• 他人が送信したメッセージ内容を窃取
• キャッシュポイズニング
• XSS

等の攻撃を行う例を示していました。またDesyncの存在を安全に検出する方法を考案し、ツール化（Burpのエクステンションや本体のシグネチャ）を行ったという成果を発表していました。

氏も触れているように、これらの攻撃の基本的なコンセプトは2005年の「HTTP Request Smuggling」に書かれています。それを再度取り上げたのが2016年のDefconの「Hiding Wookiees in HTTP」です。後者の「Wookiees」は筆者も聴講してブログ記事にしています。

ちなみに、Kettle氏はバグバウンティをやっている複数のWebサイトでDesyncバグを発見・報告し、7万USドルの報奨金を得たそうです（報奨金は寄付をしたとのこと）。

バウンティの話で面白いと思ったのは、「Wookiees」の発表者である@regilero氏が、2016年の発表で「HTTP Smugglingではバグバウンティは稼げない」という発言をしていたことです。

これはregilero氏が間違っていたわけではなく、氏が「DesyncバグをプロキシやWebサーバなどのソフトウェア製品の脆弱性として報告する」という前提に立っていたためです。一方でKettle氏がバウンティを得たのは「Webサイトの脆弱性」として報告したからです。

これが意味するのは、Webサイトのバグバウンティが製品のバグを見つけた研究者に金銭的報酬を提供しているということであり、さらには脆弱性を実証的に研究する大きな実験場も提供しているということです。

基本的には良いことではありますが、一方で製品の脆弱性と知りながら、製品開発元ではなくWebサイトのバグバウンティに報告するケースが増えるおそれもあります。結果として製品の修正対応が遅れたり、製品の0day情報が不必要に拡散したりという負の効果もありえます（発表とは余り関係ない部分の感想です...）。

脆弱性診断の観点で言うと、Desyncバグは純粋な意味でのWebアプリの脆弱性ではなく、それより下のレイヤのソフトウェアの問題です。Webアプリとネットワーク診断との隙間に埋もれてしまいがちな問題となるかもしれません。もう一つ厄介なのは、氏の発表にもあったように、診断の対象となる検証環境と、本番環境では異なるソフトウェア構成となっており、検証環境に対する診断だけでは検出できない場合も多いだろうことです。

■API-Induced SSRF: How Apple Pay Scattered Vulnerabilities Across the Web

https://www.blackhat.com/us-19/briefings/schedule/#api-induced-ssrf-how-apple-pay-scattered-vulnerabilities-across-the-web-14462

PKC Security社のJoshua Maddux氏の発表です。

APIの仕様がSSRF脆弱性を増やす要因になりうるという問題を提起し、その例としてApple PayやWebhookを挙げていました。

Apple Payの例では、Apple Pay決済を利用するサイトのサーバから、Apple側のMerchant Validation URL（https://apple-pay-gateway-*.apple.com）に接続する処理が決済フローの中で発生します。このURLをブラウザから受け取り、検証せずに使用する（そのURLにアクセスする）WebアプリケーションがSSRFに脆弱になります。

Appleに問題を報告したところ、Merchant向けのAPIドキュメントに注意書きが追加されたそうです。

https://developer.apple.com/documentation/apple_pay_on_the_web/setting_up_your_server#3172426

確かに、何らかの仕様が脆弱性を増やすことはあるよな、というのが感想です。

古い話で恐縮ですがOpenID Authenticationを例にすると、DiscoveryによってSSRFに脆弱になったり、XRDSの処理でXXEに脆弱になったり、AssociationでDoSに脆弱になっていたりするサイトを見たことがあります。これらの攻撃の中で、わずかでも仕様書で触れられているのはAssociationによるDoS攻撃だけだったと記憶しています。

多くのユーザが利用する仕様書を作るにあたっては、様々な分野のセキュリティの専門家がレビューして、問題が生じやすい箇所に注記を加えたり、そもそも問題が生じにくい仕組みにしたり、といった考慮をして欲しいところです。

またSSRFに限った話をすると、HTTPクライアントライブラリなどにプライベートなネットワークへのアクセスを禁止する設定オプションがあれば、対処が容易になるケースもあります。そういった方面でも取り組みが進んで欲しいと思いました。

■Managing for Success: Maintaining a Healthy Bug Bounty Program Long Term

https://www.blackhat.com/us-19/briefings/schedule/index.html#managing-for-success-maintaining-a-healthy-bug-bounty-program-long-term-17348

BugcrowdのChloe Brown氏の発表です。

基本的はバグバウンティプログラムの運営者を対象とした講演で、「アクティブな（参加者が多い）プログラムをいかに長期的に維持するか」というテーマです。

参加者を維持・拡大する手法として、下記のような方法に言及していました。

• バウンティの対象を少しずつ拡大する
• 現金以外の報酬（SWAGと言っていました）を与える
• 徐々に報奨金を高くする（時間経過とともにバグ発見が困難になる）
• コミュニティ感・ファミリー感の演出
• ハッカソンなどのコラボレーション、Hall of fame
• 修正後のバグ内容の公表を認める
• プログラムのルールを明確にして公開する
• 支払いまでの期間を短く、etc.

Black Hatのブリーフィングには「Web」「Policy」「Mobile」などのカテゴリが付けられているのですが、今年は「バグバウンティ」カテゴリが新たに加えられていました。それだけバグバウンティの存在感が業界内で高まっているのだろうということで参加したのが、同カテゴリの3つのブリーフィングの1つ（上記）です。

ちなみに筆者はバグバウンティを運営する側ではなく、（どちらかというと）それと競合する脆弱性診断サービスを提供する側の人間です。同時に、個人あるいは会社としてバグバウンティに参加する側でもあります。

過去にはGoogle, Mozilla, Facebook, ZDI（Pwn2Own Mobile）, Samsungの5社のプログラムに参加したことがあります。運営者のパーティに招待されたことも何度かありましたが、その裏側にあるバウンティ運営者側のロジックが、今回のブリーフィングへの参加でより明確に分かりました（分かってどうなるものでもありませんがｗ）。

HTTP Desyncの感想でも書いたように、バグバウンティは近年大きく成長し、脆弱性研究にも貢献をしています。新たな攻撃手法などに関するネット上の情報を見ると、最近はバグバウンティの結果として語られることが増えていると感じます。そういう情報を見ると、筆者も久しぶりにバグバウンティやりたいな...と感じます。

一方で、運営者側の様々な苦労や、構造的な問題などもあるかもしれません。通常の診断サービスとの比較にも興味があります。そういう部分の話もあったら、より参考になったかなと思いました。

■おわりに

今回はDefconを抜きにしたこともあり、参加できたWeb系のブリーフィングの数が少なくて少々残念でした。ただ、新しい情報に触れる場として、そして普段話す機会がない方と情報交換する場としても、Blackhatのようなカンファレンスは有用だなと改めて感じました。

ところでDefconを抜きにした理由は、一つはBlack HatからDefconの5日連続カンファレンス（加えて夕方からの情報交換）が体力的にハードなためですが、もう一つは移動して別のカンファレンスに出るためです。機会があればそちらの模様もブログで報告したいと思います。