Security News Daily

HTTP/2 BombとMicrosoft 365トークン窃取：インフラからモバイルまで広がる緊急脆弱性群

HTTP/2プロトコルレイヤーでの新種DoS攻撃「HTTP/2 Bomb」から、Microsoft 365 Androidアプリのデバッグフラグによる認証トークン漏洩、VS Code経由のGitHub OAuth窃取、Linuxカーネルのコンテナ脱出脆弱性、Gemini乗っ取り攻撃まで。インフラ基盤からモバイル端末、AIアシスタントに至るまで、広範囲にわたる緊急性の高い脆弱性が同時に報告された。

HTTP/2Microsoft 365AndroidセキュリティLinuxカーネルAIセキュリティ

今日のハイライト

本日は、インターネットインフラの根幹を揺るがすHTTP/2プロトコルレイヤーの脆弱性から、エンタープライズモビリティの要であるMicrosoft 365 Androidアプリの重大な設定ミス、そしてAIアシスタントの新たな攻撃ベクトルまで、階層を横断する緊急のセキュリティインシデントが集中発生しています。特に、生産環境に残されたデバッグフラグによる認証トークンの漏洩と、単一マシンから主要Webサーバーを癱瘓させるDoS手法は、即座の対応が求められるレベルの脅威です。

1. Microsoft 365 Android Apps Let Any App Steal Account Tokens via Leftover Debug Flag

概要

Microsoft 365 for Android（Word、Excel、PowerPoint等）の生産環境ビルドに、開発用のデバッグフラグが残存していることが判明しました。このフラグが有効になっていることで、同一デバイス上の任意の第三者アプリがMicrosoftアカウントの認証トークンを要求・取得可能となっており、取得されたトークンを使用してメールの閲覧、OneDriveファイルへのアクセス、カレンダー情報の取得などが行える状態にありました。

考察

実務対策としては、まずMDM（Mobile Device Management）経由での即時アップデート適用が最優先です。組織内にBYOD（Bring Your Own Device）環境がある場合、個人利用アプリと業務アプリが同居するAndroidデバイスではリスクが特に高まります。Microsoft Intune等を使用してアプリ保護ポリシー（APP）を適用し、トークンの暗号化とsandbox化を強制すべきです。また、Azure ADのサインインログを監視し、不審なトークン利用（異常なUser-AgentやIPアドレスからのアクセス）がないか継続的に確認する必要があります。

技術的には、この問題はCI/CDパイプラインにおけるビルド構成管理の不備を象徴しています。android:debuggable属性や開発用のOAuthリダイレクトURIがリリースビルドに混入したことで、AndroidのAccountManagerによるトークン共有制限が無効化されていました。これは、近年増加している「設定ミスによるセキュリティインシデント」の典型例であり、SAST/DASTだけでなく、ビルドアーティファクトの構成解析（SBOMの活用）の重要性を示唆しています。

業界トレンドとして、モバイルアプリのセキュリティテストは機能的な脆弱性（OWASP Mobile Top 10）に偏重しがちですが、ビルド設定やデプロイメント構成のセキュリティが盲点となっているケースが少なくありません。DevSecOpsの文脈で、リリースビルドの自動検証（debugフラグの検出、証明書ピンニングの有効化確認等）をパイプラインに組み込む必要があります。

参照元

2. New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare

概要

「HTTP/2 Bomb」と名付けられた新種のDoS攻撃手法が発見され、NGINX、Apache HTTPD、Microsoft IIS、Envoy、Cloudflare Pingoraなど、主要なWebサーバー/リバースプロキシ全般に影響することが明らかになりました。この攻撃はHTTP/2のヘッダー圧縮（HPACK）とマルチプレックス機能を悪用し、従来のSlowloris攻撃を進化させたもので、単一のマシンから数秒以内に高スペックのサーバーをサービス不能にできる可能性があります。

考察

即座の対策として、HTTP/2接続数の上限設定と、ヘッダー圧縮テーブルのサイズ制限が有効です。NGINXではhttp2_max_concurrent_streamsやhttp2_header_table_sizeの調整、CloudflareやAWS ALB等のマネージドサービスを利用している場合は、レート制限と接続タイムアウトの厳格化を検討すべきです。また、WAFレイヤーでHTTP/2特有の異常パターン（圧縮ヘッダーの過剰な繰り返しや、ストリームIDの異常な増加等）を検出するルールを緊急追加することを推奨します。

技術的背景として、この脆弱性はHTTP/2プロトコルの設計思想と実装のギャップを突いています。HTTP/2はヘッダー圧縮により帯域を節約しますが、攻撃者は小さなリクエストでサーバーのメモリを圧迫しつつ、マルチプレックスにより多数のストリームを同時に開くことで、サーバーのリソース枯渇を加速させます。これは従来のL7 DDoS（アプリケーション層）を超え、プロトコルレイヤー（L6相当）でのリソース管理の脆弱性と言えます。

業界全体として、HTTP/2やHTTP/3（QUIC）への移行が進む中で、プロトコル実装の堅牢性が再び問われています。特に、マイクロサービスアーキテクチャでEnvoy等のサービスメッシュを利用している環境では、単一の攻撃が内部通信網をカスケード的に癱瘓させるリスクがあります。プロトコルバージョンの段階的なロールアウトと、異常時の即座のHTTP/1.1フォールバック体制の整備が重要です。

参照元

3. One-Click GitHub Dev Attack Lets Attackers Steal Full GitHub OAuth Tokens

概要

Microsoft Visual Studio Code（VS Code）を介したワンクリック攻撃により、ユーザーのGitHub OAuthトークンが窃取される脆弱性が公開されました。攻撃者は細工されたリンクやマルウェア入りのVS Code拡張機能を介して、プライベートリポジトリへの読み書き権限を持つトークンを取得可能です。これにより、ソースコードの窃取や、サプライチェーン攻撃を目的としたリポジトリへの悪意あるコード注入が現実の脅威となります。

考察

開発組織は即座に、GitHubのOAuthアプリケーションの権限スコープを見直し、必要最小限の権限（最小特権の原則）に制限する必要があります。特に、組織全体のリポジトリに対する広範なアクセス権を持つ従業員のトークンは、即座の無効化と再発行を検討すべきです。VS Codeの設定では、未確認の拡張機能の自動インストールを禁止し、ワークスペースの信頼設定を厳格化してください。また、GitHubのAudit Logで、異常なクローン操作や、開発者の通常の作業時間外における大量のAPI呼び出しがないか監視を強化します。

技術的には、この攻撃はIDE（統合開発環境）を介したサプライチェーン攻撃の新たなベクトルを示しています。従来はnpmパッケージやDockerイメージが主な攻撃対象でしたが、開発者が日常的に使用するIDEの設定や拡張機能が標的となることで、攻撃の信頼性（信頼境界内での実行）が飛躍的に高まります。OAuthトークンのローカル保存方法（VS Codeの内部ストレージやOSのKeychain）の暗号化強度と、アクセストークンの有効期限（短期間の有効化）の設定が重要な防御ポイントとなります。

DevSecOpsの観点からは、開発者ワークステーションのセキュリティ（Developer Workstation Security）が、CI/CDパイプラインと同等以上に重要であることが再認識されました。GitHubのFine-grained personal access tokensの導入や、SSHキーによるアクセスの段階的な廃止、トークンの自動ローテーション机制の導入が急務です。

参照元

4. Organizations Warned of Exploited Linux Kernel Vulnerability

概要

CISA（米国サイバーセキュリティ・インフラストラクチャー安全保障庁）が、Linuxカーネルの認証不備（Improper Authentication）に関する脆弱性について警告を発しました。この脆弱性は既に実際の攻撃で悪用されており、攻撃者は権限を昇格させ、コンテナ環境からホストOSへ脱出（Container Escape）することが可能です。クラウドワークロード、オンプレミスサーバー、Androidデバイスを含む広大なLinuxベースシステムが影響を受けます。

考察

クラウド環境を運用する組織は、即座にカーネルパッチの適用計画を策定してください。特に、コンテナオーケストレーション環境（Kubernetes、Docker Swarm等）では、ノード単位でのカーネルアップデートが必要となるため、メンテナンスウィンドウの確保と、ローリングアップデートによるサービス中断の最小化が求められます。一時的な緩策として、コンテナの特権モード（privileged mode）の禁止、seccompプロファイルの厳格化、AppArmorやSELinuxによる強制アクセス制御（MAC）の有効化が有効です。

技術的に、この脆弱性はカーネルのネームスペース（namespace）分離や、cgroupの認証メカニズムの不備を突いたものと考えられます。コンテナ脱出は、クラウドネイティブセキュリティにおいて「最悪の事態」に位置づけられ、攻撃者はホストのroot権限を取得し、同一ホスト上の他のテナントのデータにアクセスしたり、暗号通貨マイニング用のリソースを横取りしたりする可能性があります。

CISAのKEV（Known Exploited Vulnerabilities）カタログへの追加を受け、連邦政府機関や重要インフラ事業者に対するパッチ適用の義務化（BINDing Operational Directive 22-01に基づく）が発動されています。民間企業も、CISAのKEVリストを自社の脆弱性管理プログラムに統合し、CVSSスコアだけでなく「実際の悪用状況」に基づいて優先順位付けを行うべきです。特に、マネージドKubernetesサービス（EKS、GKE、AKS等）を利用している場合、プロバイダー側のパッチ適用状況を確認し、自己責任範囲（ノードOS等）の管理を徹底してください。

参照元

5. WhatsApp, Slack Notifications Could Hijack Google Gemini on Android

概要

WhatsApp、Slack、SMS、Signal、Instagram、Messenger等の通知を介して、Google Gemini（Android版のAIアシスタント）を乗っ取る攻撃手法が発見されました。この「間接的プロンプトインジェクション（Indirect Prompt Injection）」により、攻撃者はGeminiを通じて、被害者の連絡先に偽のメッセージを送信させたり、Zoom通話を強制的に開始させたり、Geminiの長期記憶（パーソナライゼーションに使用される過去の対話履歴）を汚染させたりすることが可能です。

考察

現時点での対策として、Geminiの「アシスタント拡張機能」（他アプリとの連携機能）の無効化、および通知アクセス権限の見直しが有効です。Androidの設定から、Geminiに付与されている「通知へのアクセス」や「他アプリの上に表示」権限を制限し、特にメッセージングアプリの通知内容をGeminiが読み取れないように設定してください。また、Geminiの「Memory」機能（長期記憶）に保存されている個人情報を定期的にクリアし、異常な設定変更（自動返信の設定等）がないか確認することが重要です。

技術的に、この攻撃はLLM（大規模言語モデル）のコンテキストウィンドウを介した入力検証の回避を示しています。従来のプロンプトインジェクションは、ユーザーが直接入力するテキストを対象としていましたが、今回のケースは通知システムという「信頼されたパイプライン」を経由して悪意ある指示を注入する点で新しい脅威モデルを提示しています。Gemini等のAIアシスタントは、通知内容を要約・処理する際に、システムプロンプトとユーザーデータの区別が曖昧になりがちで、この「コンテキスト境界の曖昧さ」を悪用しています。

AIエージェントのセキュリティという新たな領域において、これは「AIが自律的に行動できる範囲（アクションスペース）」の制限がいかに重要かを示唆しています。将来的には、AIアシスタントが実行可能なアクション（メッセージ送信、会議開始、購入処理等）に対して、明示的なユーザーコンセント（マルチモーダルな確認）を要求する「Human-in-the-loop」机制の標準化が必要です。現状では、AIアシスタントの権限を最小限に抑え、特に金融取引や機密情報の送信に関する機能は無効化しておくべきです。

参照元

まとめ

本日報告された脆弱性群は、**プロトコルレイヤー（HTTP/2）、OSカーネル（Linux）、モバイルアプリ（Microsoft 365）、開発環境（VS Code/GitHub）、そして新興のAIレイヤー（Gemini）**という、ITシステムの全階層を網羅している点で特筆すべきです。特に、HTTP/2 Bombによるインフラ癱瘓の可能性と、Microsoft 365 Androidアプリのトークン漏洩は、広範囲なユーザーに影響を与える緊急事態です。

今後の注視ポイントとしては、まずHTTP/2 Bombに対する各ベンダーのパッチ対応状況と、実際の攻撃ツール化の動向を監視する必要があります。また、AIアシスタントを介した攻撃（間接的プロンプトインジェクション）は、今回のGemini事例を皮切りに、ChatGPT、Claude、Copilot等への拡大が予想されます。組織は、従来のパッチ管理に加えて、AIエージェントの行動ログの監視と、開発環境におけるID管理の再構築を、セキュリティプログラムの優先事項に加えるべき時期に来ています。

参照元