はじめに
GMO Flatt Securityセキュリティエンジニアのcanalun、ryotaromosao、mn1、fujitargzです。
本ブログでは、2025年8月上旬に開催されたBSides Las Vegas、Black Hat USA 2025、DEF CON 33に弊社メンバーが参加した際の記録、および、特に興味深かったセッションの詳細についてお伝えします！
なお、本稿の作成にあたっては各セッションの発表内容について可能な限り誤りがないように注意を払って記述しましたが、誤りを含む可能性があります。また、各セッションの内容については、筆者独自の考えや解釈を含む場合があります。本稿を通して気になったセッションがあった方は、ぜひオリジナルの文献や発表のアーカイブにアクセスしていただければ幸いです。
- はじめに
- GMO Flatt Security及びGMOの支援制度
- BSides Las Vegas
- Black Hat USA 2025
- Black Hat USA 2025について
- Back to the Future: Hacking and Securing Connection-based OAuth Architectures in Agentic AI and Integration Platforms by ryotaromosao
- Cross-OriginWebAttacksviaHTTP/2 Server PushandSignedHTTPExchange by ryotaromosao
- When Guardrails Aren't Enough: Reinventing Agentic AI Security With Architectural Controls by mn1
- HTTP Raider - The ultimate tool for HTTP hacking by fujitargz
- DEF CON 33
GMO Flatt Security及びGMOの支援制度
GMO Flatt Security には、業務に関係するカンファレンスやセミナーへの登壇や受講を時間に行うことができ、参加に必要な費用を会社に負担してもらえる「カンファレンス・セミナー参加支援制度」という研修制度があります。今回のアメリカ渡航も業務時間内の扱いとなり、渡航やイベント参加にかかる費用も会社から全額補助してもらいました。今回は25卒の新卒2名と中途社員1名をこちらの支援で送り出してもらいました！
さらに、GMOインターネットグループではCTF参加時に必要な費用を会社に負担してもらえる制度があり、こちらの制度でも新卒1名、インターン1名の渡航費用を全額補助していただき、計5名での渡航となりました！
弊社 GMO Flatt Security では新卒・中途を問わずセキュリティエンジニアを積極採用中です！エンジニアであれば全員がこれらの制度に応募するチャンスがあります。ご興味のある方は、ぜひ以下のフォームからカジュアル面談をお申し込みください！
その他、GMO Flatt Securityでの働き方やメンバー、待遇や福利厚生については以下よりご覧ください。
BSides Las Vegas
✈️ラスベガスに滞在中🇺🇸
— GMO Flatt Security株式会社 (@flatt_security) 2025年8月6日
カンファレンス・セミナー参加支援制度による会社の費用補助のもと、今年はGMO Flatt Securityから4人がBlack Hat USA / DEF CON / BSides Las Vegasに参加しています。
現地でメンバーを見かけましたらぜひお声がけください！ pic.twitter.com/d3ySCrMLwV
BSides Las Vegasについて
Bsides Las Vegas は、その名の通り Las Vegas で例年3日間開催されているコミュニティベースのセキュリティカンファレンスで、セキュリティに関する技術的な知識の普及やコミュニティの活性化を目指して開催されています。今年も例年通り Tuscany Suites & Casino で開催され、会場ではサイバーセキュリティに関連する様々なプレゼンテーションや CTF、ネットワーキングイベントが実施されていました。以下では、私達が聴講した中で特に興味深いと感じたセッションについて紹介します！
Rusty pearls: Postgres RCE on cloud databases by fujitargz
このTalkはVaronis社のTal Peleg氏ならびにCoby Abrams氏によるものです。 タイトルの通り、PostgreSQLにおけるRCEを発見し、それがAmazon RDSにおいて実行可能であることを示した、という内容でした。 RCEを達成するためにPostgreSQLの複数の拡張機能を組み合わせていることが特徴的でした。
PostgreSQLはPerl(PL/Perl)などの言語で関数を記述し機能を拡張することができます。 このような拡張機能のうち、Trusted Language Extension (TLE) はファイルシステムや環境変数などシステム環境へのアクセスが制限され安全に利用できることが保証されている拡張機能です。 しかし、PL/PerlにはTLEであるにもかかわらず環境変数へのアクセスが可能である脆弱性(CVE-2024-10979)が存在しました。 この脆弱性を利用すると、例えば攻撃者が任意のファイルをアップロードし環境変数PATHにそのファイルパスを追加することでRCEが可能です。
ただし、この手法は当該脆弱性に加えて攻撃者がファイルをアップロードする必要があるため、Tal氏らはファイルアップロード不要なRCEの可能性について調査を継続しました。 上述の脆弱性を前提とすると攻撃者は環境変数を任意の値にできるため、環境変数を読み込んで動作するgadgetがあれば良い、という直感が得られます。 そのようなgadgetが、同じくPostgreSQLの拡張機能であるPL/Rustでした。PL/Rustで書かれた関数はコンパイルされてから実行されるため、コンパイル時にcargoなどRustの一連のビルドプロセスが動作します。 このとき、cargoはRUST_GDBなど必要な環境変数を読み込んで動作することになります。 ここで、RUST_GDBにコマンドを指定するとrust-gdbが指定されたコマンドを実行してしまいます。 したがって、PL/PerlでRUST_GDBに任意コマンドを指定しPL/Rustで書かれた関数を実行することで、任意コマンド実行が可能になります。 Tal氏らはAmazon RDSで実際にこの攻撃を実行し、/bin/bashで任意のコマンドを実行できたようです。 ただしAmazon RDSのセキュリティ機構によって機微情報へのアクセスなどは防がれていたとのことでした。
複数の拡張機能をチェインさせRCEの攻撃条件を緩くする話はテクニカルではあるものの理屈は明快で、Tal氏らの教育的なスライドも相まってCTFのwriteupを錯覚しました。 現実世界のBughuntで複数の脆弱性をチェインさせると、その過程や攻撃条件は複雑になりがちだと思っていましたが、そのような直感に対する反例として個人的には鮮烈な印象が残っています。 また、環境変数を読み込んで動作する拡張機能を探す作業は愚直に頑張るしかないフェーズであるように思いましたが、AIを活用し効率的に検索を行ったようです。 AIを利用した脆弱性のリサーチ手法としても非常に綺麗なお手本だと感じました。
Tal氏らによるブログもありますので、詳細についてはそちらもご覧ください。
The Scene is Dead by canalun
このセッションは技術そのものがテーマではなく、コミュニティのカルチャーにフォーカスをしていました。
具体的には、サイバーセキュリティに関心を持った若者がサイバー犯罪に手を染める傾向があることを問題視するセッションでした。また、犯罪行為に対して技術力の高さが免罪符になると若者に思わせてしまっている/思われてしまっているようなコミュニティへの問題提起も行われていました。
過去の時代は、サイバーセキュリティに興味を持った場合、最初の入り口にあったのはコンピューターを壊すといった行為だったのが、いまやsextortionの実行やgore videoへの誘導に変化しているとプレゼンターは述べていました。いまやサイバーセキュリティが容易に暴力行為へ転用される時代が来ており、「過去に犯罪を行なっていた者や犯罪をしている者でも技術力があるなら雇ってみよう」というのは、こうした「暴力の時代」("violence era")になる前にできた、今や変えるべき考え方だと主張されていました。
サイバーセキュリティの技術や考え方は、サイバー犯罪のコミュニティで「活用」されているようです。例として、数えきれないほどのswatter(家にswatを呼ぶ嫌がらせを行う人たちのこと)がプロフィールに「sec researcher」と載せていることや、COM(参考: https://cyberinsider.com/fbi-issues-urgent-warning-about-the-com-cybercrime-group)のメンバーがOSINTコミュニティで「CSINT」という言葉を流行らせようと活動していることが挙げられました。
実際にsextortionを行なって逮捕された若者へのインタビュー音声も非常に印象的でした。「被害者のことは事前に綿密に調べたよ、OSINTだよ」といったことを言っており、随所でサイバーセキュリティの概念や考え方が犯罪行為に活用されてしまっていることが浮き彫りにされていました。
セキュリティ、特にオフェンシブなセキュリティの技術を学ぶ人間やコミュニティは自分たちが形成するカルチャーに敏感でなければならないなと思わされました。倫理観を持てといった教育はあらゆる場所・職場で行われていると思いますが、それは切に当たり前のこととして、自分たちが社会にどういう影響を与えていくのかという能動的な観点の教育もやはり視野に入れるべきだと感じます。
技術の話も楽しいですが、このセッションは多くの人が一堂に会する場所でこそ話されるべき重要なトピックだったと思います。実際、セッション後のFAQも質問者の数が多く、有意義なラリーが多かったように感じます。かなり印象に残ったセッションでした。
LLM Mayhem: Hands-On Red Teaming for LLM Applications by canalun
HiddenLayer社がやっているAIレッドチーミングのトレーニングを受けました。事前申し込みはしていなかったのですが、当日たまたま空席があるとのことで受講することができました。
CTF形式のトレーニングです。具体的にはAIを使ったチャットサービスが用意されていて、そこにプロンプトインジェクションを試みるというものです。要するに、AIだけが知っているフラグをAIを騙して教えてもらおうというわけです。実際にさわれるものがあるトレーニングはやはり楽しくてよいですね。
いくつかのプロンプトインジェクションの手法を学びましたが、この会社が提供している、プロンプトエンジニアリングの手法を整理したグラフは見ているだけでも面白かったです。
https://ape.hiddenlayer.com/graph.html
また、手法として目新しく感じたのはKROPと呼ばれるものでした。要するに、与えるプロンプトの中で物事を直接的に表現する代わりに、LLMがすでに学習しているであろう知識の断片の組み合わせで婉曲的に表現することでインプットに対するガードレールを突破するテクニックです。知識でROPするのでKROP(Knowledge ROP)です。
詳しくはこちらの記事を見ていただくのが一番かとは思いますが、例えばプロンプトの一部を、海外のミームとしてよく知られた漫画xkcdの有名な話を使って「[xkcdの第XX話のXXコマ目のセリフ]」と置き換えるやり方があります。これはAIがxkcdの有名な話なら学習済みであるために可能な置き換えです。または各単語を虫食いにしたプロンプトを、LLMに単語当てゲームのようにして与える方法もあります。
KROPの興味深いところは、それを可能にする要因がLLMに求められる性質そのもの、つまり推論力であることです。KROPが成立しないということは、LLM内におけるKnowledge同士の結びつきが人間のそれとは異なるということであり、人間の言語を処理できるというLLMのありがたみはそこに生じ得ないでしょう。つまり、KROPにおけるROPはSemanticであり、通常のROPへの対策として可能なASLR(記号が指し示すものをシャッフルする行為)は通用しないのです。私たちの作るソフトウェアに自然言語を扱う高度な能力が宿ったことで、ディフェンスメカニズムには根本からの再考や、記号論なども交えた学際的な視点からの検討が求められるのだと思います。
なお、トレーニングは全部で5題だったのですが、最後の問題は誰も解けず、正解例も発表されずに終わりました。トレーニング終了時には最後の問題が解けたら連絡してくれと言っていましたが、解けたら雇ってくれるのかもしれません。なお、いまだに解けていません😂
Black Hat USA 2025
Black Hat USA 2025について
Black Hat USA は世界最大級のセキュリティカンファレンスの1つです。カンファレンスでは、以下に示すような様々なコンテンツが提供されています。
- Briefing
- 最新の攻撃手法や脅威アクターの動向等に関する技術的なトピック、及び、サイバーセキュリティに関する法整備や政策、標準化等の動向に関するポリシー系のトピックに関連したプレゼンテーションが提供される。
- Business Hall
- いわゆる企業出展ブースで、世界的に有名なセキュリティベンダーからセキュリティ関連のソリューションを提供するスタートアップ等、様々な企業がブースを出展している。
- Arsenal
- Arsenal は自身が開発した (とりわけオープンソースの) ツールを紹介する場で、開発者はツールのデモを行いながら参加者からの質問に回答したり、議論したりできる。
- Training
- その名の通りセキュリティに関する様々なトピック (マルウェア、ハードウェアセキュリティ、Webアプリケーションセキュリティ、DFIR 等々) に関するトレーニングや講義が提供される。
- Merchandise
- Black Hat 関連のグッズが購入できるブースで、ロゴ入りのアパレルやステッカーが販売される。
初めて会場に着いた時にはその規模の大きさに度肝を抜かされました🤯当日はBlack Hatの公式アプリを利用して聞きたいBriefingやArsenalを予め決めておき、隙間時間にBusiness HallやMerchandiseを回りました！ 以下では、私達が聴講した中で特に興味深いと感じたセッションについて紹介します！
Back to the Future: Hacking and Securing Connection-based OAuth Architectures in Agentic AI and Integration Platforms by ryotaromosao
本セッションでは、Kaixuan Luo氏らによるConnection-based OAuthの脆弱性の発表がありました。AIエージェントに認可をするためのConnection-based OAuthでは、Token Managerがエージェントとツールの間に立ってaccess token管理をしてくれます。しかしながら、FAOAuthクライアントの役割をエージェントとToken Managerに分割するというOAuth2.0の標準外実装のため、かつてOAuth2.0で対策されたはずの脆弱性がBack to the Future🚗のように復活したという内容でした。
以下がConnection-based OAuth 認可フローになります。
- Pre-OAuth
- エージェントはToken ManagerにAPIリクエストを送り、これから開始する認可フローのためのプレースホルダーとなるコネクション（Connection）を作成。
- Token ManagerはConnection IDとユーザーをリダイレクトさせるためのOAuth URLを返す。
- OAuth
- エージェントはユーザーにOAuth 認可URLを提示し、ユーザーはツールのアクセスの許可をする。
- 認可コード（
code）が、Token ManagerのコールバックURLに送られ、Token Managerが認可コードからaccess tokenを受け取る。
- Post-OAuth
- Token Managerは、取得した
access tokenをConnectionに紐づけて保管。 - エージェントは、保持しているConnecion IDを用いてToken Managerから
access tokenを取得してAPIリクエストをする、またはトークンマネージャーにAPIコールを要求する。
- Token Managerは、取得した
そして、Connection-based OAuthによって下記の脆弱性が生まれたと筆者は主張しています。
- Session Fixation
- Open Redirect
- Confused Deputy(Cross-agent Client ID Confusion)
- Confused Deputy(Cross-app/tool OAuth Account Takeover(COAT))
ここでは1. Session Fixationについて解説します。攻撃者は自身のConnectionに紐づいたOAuth認可URLを被害者に踏ませることで、被害者の許可に基づいて発行されたaccess tokenを、攻撃者のConnectionに紐づけて保存することができます。そのため、攻撃者が用意したAIエージェントから被害者のツールを操作することが可能になります。これは本来、user sessionに紐づけて管理されるべきstateに関して、エージェントがuser sessionを、Token Managerがstateを管理していることが原因で発生します。
この対策として、OAuthのコールバック後、再度Agent BackendにAPIリクエストを送ることでユーザーセッションからuser idを取得する方法がありますが、エージェントが機能する場所はブラウザだけではなく、アプリでも機能するため、先述のコールバックが難しい問題があります。そこで、第二の対策としてクロスデバイスフローやCIBA、PINコードなどを利用する方法が提案されています。
Connection-based OAuthの考え方自体は面白いですし、それぞれのエージェントに楽に認可を施せるので便利だと思います。一方、セキュリティのための追加実装がさらに必要になる点を考えるとやはり利便性とセキュリティはトレードオフだなと感じました。 また、エージェントがブラウザやアプリなど様々な箇所で機能するため、その対策も複雑化しているのはこの大genAI時代ならではだなぁと思いました。エージェントへの認可問題、今後どうなっていくんでしょうね？楽しみです。 LLMへの認可制御についてさらに詳しく知りたい方は、弊社ブログ記事「AI 時代の認可制御入門:「AI でつくる人」「AI をつくる人」のための実践ガイド」をご覧ください。
Cross-OriginWebAttacksviaHTTP/2 Server PushandSignedHTTPExchange by ryotaromosao
本セッションでは、Pinji Chen氏によるHTTP/2 ServerPushとSXG(Signed HTTP Exchange)を用いたクロスオリジンの攻撃の発表がありました。
- Originの定義
まず、Originの定義から見ていきます。本来、SOP(Same-Origin Policy)で定義されているURI-basedなOriginはURIのスキーム・ホスト・ポートで構成されています。しかし、HTTP/2では共有SSL証明書がある場合、SAN-based Originが用いられています。これは、TLS証明書のSANフィールドにリストされているホストを全てSame Originとする方法です。例えば、.google.comのTLS証明書は、.android.comや*.youtube.comでも共有されているため、これらは全てSame Originということになります。ちょっと怪しいにおいがしてきましたね…🤔
- HTTP/2 ServerPushとSXG
HTTP/2 ServerPushとは、サーバーがクライアントからのリクエストを待たずに、将来必要になると予測したリソース（CSSやJSファイルなど）を能動的にプッシュする機能のことです。レンダリングに必要なリソースを1回のラウンドトリップで取得でき、表示速度を向上させることができます。 SXGは、コンテンツの作成者がコンテンツにデジタル署名を行うことで、第三者による再配布を許可する仕組みのことです。これにより、ユーザーはコンテンツ配信元のサーバーに直接アクセスすることなく、キャッシュから高速かつ安全にコンテンツを読み込むことができます。
また、特筆すべき点として、これら2つとも配信するコンテンツの生成元を任意に指定することができてしまいます。具体的には、ServerPUSHでは:authorityヘッダーによって、SXGではrequest-urlやvalidity-urlを署名に含めることでコンテンツの生成元を指定することができます😨
SAN-based Originと、ServerPush/SXGを組み合わせることで…何がやりたいかもう分かりましたか…？
- 攻撃手法（CrossPush / CrossSXG）
以下が攻撃のフローになります。
- 攻撃者は、標的のドメイン（
victim.flatt.tech）と攻撃者のドメイン（attacker.flatt.tech）の両方を含む共有SSL証明書を入手する attacker.flatt.techは悪意のあるスクリプトをServerPUSH / SXGで配信、その際、生成元をvictim.flatt.techに偽装- ユーザーのブラウザは、
victim.flatt.techが証明書のSANリストに含まれているため、このスクリプトを正当なものと判断し、victim.flatt.techに関連付けてキャッシュ する - ユーザーが正規の
victim.flatt.techにアクセスすると、ブラウザはサーバーにリソースを要求せず、キャッシュに保存された悪意のあるスクリプトを実行してしまう
これにより、攻撃者は様々なexploitをすることができます。例えば、HTTP bodyを書き換えることによるUniversal XSS、HTTP headerを書き換えることによるCookie manipulation、HSTS bypassなどを行うことができます。
- 緩和策
本攻撃にはユーザーが行える完全な対策がないため、緩和策が提案されています。まず、ブラウザのベンダーは、ServerPushで送られてきたコンテンツの:authorityの値とURI-based Origin / IPアドレスが一致するかを検証や、共有SSL証明書で署名されたSXGの拒否をする必要があります。また、認証局（CA）は、正当なドメイン所有者からSANリストの不審なドメインの削除を求められた時に、削除を円滑に進めることができる仕組みを作る必要があります。最後に、ユーザーは、ドメインを購入・譲り受ける際に、Certificate Transparency (CT) ログを用いて不審な証明書が発行されていないかを確認する必要があります。
と、ここまでセッションの内容聞いて「SAN-based Originやばくね？」となりますよね😢確かに、関連する複数ドメインの通信を単一コネクションに集約したいという意図は分かりますが、それはあくまでSANリストにリスティングされているホストが完全に信頼されていることを前提にしていて、実際はドメインテイクオーバーなどによりその前提は必ずしも担保されるわけではないという印象を受けました。この内容の社内勉強会を行った時には、社内メンバーもSAN-based Origin本当に大丈夫⁉︎という感想を抱いていました。HTTP/2でSSL共有証明書を利用している方や、ドメイン管理、これから購入を検討している方は一度確認してみることをおすすめします。
When Guardrails Aren't Enough: Reinventing Agentic AI Security With Architectural Controls by mn1
mn1です。今年のBlackHatではやはりAI関連の発表が多く、特にLLMアプリケーション特有の観点での攻撃手法が数多く紹介されていました。攻撃手法は技術的に面白いものが多いですが、仕事柄堅牢なLLMアプリケーションの作り方も知りたいものです。NCC Group 社の David Brauchler III 氏による「When Guardrails Aren't Enough: Reinventing Agentic AI Security With Architectural Controls」では堅牢なLLMアプリケーションを作るための新たな緩和策を考察・発表しており、その着想が興味深かったため紹介させていただきます。
NCC Group 社の David Brauchler III 氏による本発表ではまず、現代のLLMアプリケーションにおけるセキュリティ対策の不十分さについて指摘しています。LLMアプリケーションの防御手法としてはLLMガードレールが一般的ですが、WAFと同様あくまで低減策であり、バイパスされるリスクが常にあります。実際、LLMガードレールを導入している多くのアプリケーションでプロンプトインジェクション経由のRCE、機密情報漏洩の脆弱性を発見したと報告しています。具体的な例として、Azureストレージのコンテンツをリストアップするコードを実行し、内部クラウド環境へのアクセスを可能にしたケースや、RAG を介して管理者、ルート、デフォルトのパスワードが漏洩したケース、さらには WAF をトリガーしたユーザーリストの取得を通じたデータ漏洩や管理者セッションの制御の可能性について言及していました。しかし現状ではセキュリティ対策をLLMガードレールに頼り切っているアプリケーションが多いため、新たな対策が必要だとして本発表内容について取り組み始めたとのことでした。
David 氏はプロンプトの信頼度を方針とした対策を提案しています。LLMに入力されるプロンプトは通常、複数ソースからの入力を組み合わせて作られます。シンプルなアプリケーションだと開発者が用意するシステムプロンプトとユーザ入力が組み合わされ、プロンプトが生成されるという流れが考えられます。この時、システムプロンプトは開発者自身が用意するため信頼することができますが、ユーザ入力は何が入力されるかわからないため信頼することができません。信頼度の異なる構成要素がプロンプトに使われているにもかかわらず、全プロンプトに同一の権限(プロンプトから操作できる最大の権限)が与えられているのが問題と考え、信頼度に応じた操作権限の分割、そして重要な操作を実行できる信頼度の高いプロンプトの生成方法について議論していました。
あまり今までにない新しい観点からの対策方針で、議論の幅を広げられる有益な発表だと感じました。一方で、具体策はやはり低減策にとどまっています。例えばIntent-Based Segmentationという手法では、LLMのコンテキストウィンドウを汚染しないために信頼度の高いプロンプト(資料中ではユーザ入力を適切にサニタイズしたものとしています。詳しい説明は資料に譲ります。)からの指示に回答するLLMと、信頼度の低いプロンプトからの指示に回答するLLMをわけるアーキテクチャを提案しています。しかし、プロンプトの内容によって質問先をルーティングする(Intentからルーティングを行う)役割はLLMが担うので、ルーティングを担うLLMにプロンプトインジェクションが行われた場合、信頼度の低いプロンプトで商品購入等を行えるリスクは依然として存在します。プロンプトが自然言語である以上完全な対策というのは不可能だと考え、多層防御をして攻撃困難性をあげるのが現状のベストプラクティスというのは変わらないかなと思います。参考資料ではイラストを使ってわかりやすく説明されているので、ぜひこちらもご覧ください。
参考資料
HTTP Raider - The ultimate tool for HTTP hacking by fujitargz
Arsenalでは、PortSwigger社のMartin Doyhenard氏によるHTTP Raiderの紹介がありました。 HTTP Raiderは同社が開発するHTTP proxy toolであるBurp Suiteの拡張機能として開発されているツールで、Burp Suiteの既存機能とは異なりHTTP通信をstream的に扱えることが特長です。 既存のHTTP proxy toolはHTTPリクエスト・レスポンスを一つのトランザクションのように扱っていたため複数のHTTPリクエスト・レスポンスを一度に扱うことが困難でしたが、その欠点を解消したツールと言えます。
デモを見たところ、基本的なUIはBurp SuiteのRepeaterに似ていて、任意のHTTPリクエストを作成し送信できるようでした。 ただし、Repeaterは単一リクエスト・単一レスポンスを扱いますが、HTTP Raiderは複数のHTTPリクエストを記述し同時に送信可能である点が大きく異なります。 デモではTransfer-Encoding: chunkedを利用するHTTPリクエストを例に、2つのHTTPリクエストが正常に送信できることを示していました。
その他の機能として、tag機能とnetwork visualization機能がありました。 tag機能はHTTPリクエストの一部をtagでマークアップできる機能で、例えばリクエストボディをtagで囲むと、tagで囲まれた文字列の長さなどを呼び出すtagが利用できるようになります。 これにより、例えばContent-Lengthの値をリクエストボディから自動で計算して設定することができます。 また、network visualizationはproxy serverなどのネットワークを視覚的に分かりやすい形で指定できる機能です。 特に、proxy serverは受信したHTTPリクエストの振り分けルールやparserのカスタマイズが可能です。 parserはJavaScriptで任意の実装が可能な様子で、かなり自由度が高そうでした。
network visualization機能についてはHTTP smugglingのような高度な攻撃を手元で再現する際に便利に使えそうだと感じました。 発表者のMartin氏と同じくPortSwigger社のJames Kettle氏がbriefing “HTTP/1.1 Must Die! The Desync Endgame”でHTTP smugglingを利用したattackについて発表されていましたが、氏は以前からHTTP smugglingを利用したattackについて研究されている印象があります。 HTTP RaiderはもともとHTTP smugglingの検証ツールとして開発されたのでは？と勘ぐってしまいますね。
総じて脆弱性診断用途で考えると日常使いするようなツールではないように感じましたが、それは逆説的に、現在知られている多くの攻撃が単一のHTTPリクエストで済んでいて、複数のHTTPリクエストを利用するというパラダイムに我々が対応できていないことを示唆しているのかもしれません。 今後出現するより高度な攻撃手法がHTTP smugglingのように複数のHTTPリクエストにまたがる攻撃であった場合に、我々がそれを正しく理解できるのか？既存のツールで攻撃を再現できるのか？といった点に思いを馳せるきっかけになりました。
DEF CON 33
DEF CON 33について
DEF CONは毎年Black Hatの直後にそのままラスベガスで開催される、世界最大級のハッカーカンファレンスです。Black Hatがビジネスやアカデミックな雰囲気を持つのに対し、DEF CONは徹頭徹尾「参加型」で、ハッカーたちのお祭りのような雰囲気に満ちていました！コミケのようなノリです。自由とカオス。各々が好きなモノ(技術でもデバイスでも)を持ち寄って楽しもうという文化。私たちは楽しむためにここにいるんだ！というメッセージを受け取りました！
お土産 by canalun
DEF CONのお土産選びは、Vendor Areaで行います。一般的な技術カンファレンスのようなロゴ入りのTシャツやグッズもあるのですが、ここの主役はなんと言っても多種多様なハッキングツールです。Black Hatではお目にかかれないようなアヤしい攻撃用デバイスが堂々と販売されている光景がすごく好奇心をくすぐられます！後ろにいた外国の方もめちゃくちゃテンションが上がって、自分はもうダメかも的なことを友達に言っていました😂 ということで、自分もいくつかのベンダーで買い物をしてみました。
Hak5: レッドチームツールの大手で、ブースは常に大盛況です。Bad USBや、Packet Squirrelを購入しました。他にも、普通の見た目と寸分違わない見た目なのにWi-Fiが搭載されている充電ケーブルや無線のいろいろな攻撃がデモンストレーションできる便利ポータブルデバイスなどありましたが、多くは日本の技術基準適合証明(技適)の問題で購入を断念しました……😢興味のある方は公式サイトを眺めてワクワクしましょう
Electronic Cats: 通信関連の攻撃デバイスを開発しているベンダーで、ガジェットのデザインがとてもかわいらしいのが特徴です。ここでは、差し込むとスキミング装置の存在を確認できるクレジットカード型のツール(Hunter Cat)を購入しました。これも、興味のある方はサイトを見てドキドキしてください
Tor Project: ブースで嘘発見器が売られていました。150ドル。けっこうしますね。でもかなりクールな見た目をしています。
ということで購入です。2023年にも売っていたバッジなんですね。気に入っていますがすごく繊細そうなので気軽に使う気になれず、帰国後は棚にずっと置いてあります😂
Appsec Village CTF by mn1
mn1です。DEF CONでは主にAppsec Villageで開催されていたCTFに参加していました。このCTFはアプリケーションを攻撃してフラグを取得するという一般的な形式ではなく、与えられた脆弱なアプリケーションに適切なパッチを実装することができればポイントを獲得できるという形式の問題が主に出題されるという特色があります。他にもプレイヤーにサーバーが与えられ、自分のサーバーを堅牢にしながら他プレイヤーのサーバーを攻撃してポイントを稼ぐAttack & Defense形式の問題も出題されます。 今年はFlattからエンジニア2名、弊社が提供するセキュリティ診断AIエージェントであるTakumiの計3名(?)が参加し、最高3位という結果でした。Takumiも6位という結果を残しており、改めて普段からお世話になっている彼の高い実力を実感できました(僕は8位でした、精進します...)。
今回はスマートコントラクトの問題が多数出題されており、普段中々触れない分野なのでかなり勉強になったなと感じています。問題はSecDimからいつでもチャレンジできるようなので、問題の詳細が気になる方は是非挑戦してみてください。
小ネタ：Hacker Karaoke
カンファレンス後には、DEF CON会場で行われたHacker Karaokeに参加してみました。名前がすごく気になりますからね。hackerのkaraokeってどんな雰囲気なんだよ、と。行って確かめるしかないわけです。
さて、行ってみると、これは誰でも自由に好きな曲をみんなの前で歌うことができるというだけのイベントでした。でもなんだかみんなの歌を聞いていたら楽しくなってきちゃいますね。お酒もあるし！ ということで、せっかくの機会にcanalunが『新世紀エヴァンゲリオン』の『残酷な天使のテーゼ』を歌ってみました👶ちなみにcanalunはシラフです。
なぜか曲を入れてもらった順に進んでいるわけではなく、謎の80分待機($12のbeerで無敵になったryotaromosaoの本気交渉がなければいまでも待っていたかもしれません)の後、canalunはやりきりました。
ちなみに『残酷な天使のテーゼ』はGeminiさんが選んでくれました。「【裏ワザ】」らしいです、アツいですね。アメリカでも頼れる相棒！2025年現在、私たちはAIなしでは生きていけない身体になりつつあります(急にどうしたんだ)
おわりに
本記事では、筆者達が BSides Las Vegas、Black Hat、DEF CON に参加した様子を書きました。本記事をもとに、カンファレンス参加の楽しさや筆者達が実際に聴講した興味深かったセッションの内容、そして GMO Flatt Security の福利厚生である支援制度についてお伝えできたのであれば幸いです。 なお、この場を借りてイベント参加を後押ししてくれた弊社メンバーにも感謝申し上げます。ありがとうございました。
GMO Flatt Security では、カンファレンス・セミナー参加支援や、そこで得た知見の検証などを積極的に行っています。もし自分もこのような活動を行いたい、興味がある、という方がいらっしゃったら、ぜひ弊社採用情報ページをご覧ください。
