1. Recalog
  2. 235. 2026/11/01 Binanceから..
2026-11-01 00:00

235. 2026/11/01 Binanceから約1兆円が不正流出

以下のようなトピックについて話をしました。

01. MMX初期運用が正常完了、健全性を確認

JAXAは2026年10月21日、H3ロケット10号機で打ち上げた火星衛星探査機「MMX」が、打ち上げ直後の「初期クリティカル運用フェーズ」を正常に終え、機体の健全性を確認したと発表しました。H3は10月20日4時41分に種子島宇宙センターから打ち上げられ、約1時間11分後にMMXを分離しました。その後、太陽電池パドルの展開、三軸姿勢の確立、通信用ミドルゲインアンテナの保持解放といった重要なシーケンスが順調に実施され、翌21日に健全性が確認されたということです。今後は搭載機器の初期機能確認を進めながら、火星圏へ向かう「往路巡行運用フェーズ」の準備に入ります。

MMXは、火星の衛星フォボスに着陸して表面物質を採取し、地球へ持ち帰るミッションで、成功すれば火星の衛星からの世界初のサンプルリターンとなります。フォボスは火星表面から約6000km上空を回る直径20〜30kmほどの小天体で、本格的な探査がまだ行われておらず、JAXAは「太陽系で最も重要な未踏峰」と呼ばれることもあると説明しています。探査機はフォボスに2回着陸し、10g以上の試料採取を目指します。火星圏への到着は2027年8月、地球帰還は2031年7月の予定で、試料カプセルは「はやぶさ」「はやぶさ2」と同様にオーストラリアで回収される計画です。約5年に及ぶ旅の行方に注目が集まっています。

02. PHPに深刻な脆弱性2件、修正版を公開

2026年10月21日、The PHP Groupは、PHPの深刻な脆弱性2件(CVE-2026-109618、CVE-2026-109619)を修正するセキュリティリリースを公開しました。公表前に情報漏えいや番号の誤流出があり、予告より早い公開となりました。

2件はいずれも認証不要でリモートコード実行(RCE)につながりうる脆弱性で、CVSS v4.0は9.2(Critical)です。前者はメモリ不足(OOM)時の処理中断でメモリが不正な状態になる問題、後者はリクエストをまたいで残る状態が解放後に使われる問題です。PHP-FPMやmod_phpなどWebリクエストを処理する環境が対象で、特にmod_phpでは、アプリのコードが動く前に攻撃できることが実証されています。発見にはWiz、Calif.io、OpenAIが関わり、AIモデルも活用されました。

影響を受けるのはPHP 8.2〜8.5の修正版未満で、修正版は8.5.12、8.4.27、8.3.36、8.2.35です。7.4〜8.1にも最小限のバックポートが提供されました。完全な対策は更新だけで、session.upload_progress.enabled=0やmemory_limitの設定などは一部の攻撃経路を減らす補助策にとどまります。主要なLinuxディストリビューション、国内ホスティング事業者、WAF/IPSベンダーも、修正適用、予防的なサービス停止、遮断ルールの提供などで対応しました。

悪用の試行は修正版公開前から観測され、公開後に急増しました。CISAは10月26日に両脆弱性をKEVカタログへ追加しています。一方、成功した悪用の確証は限られています。公開されたPoCの多くは、PHPのバージョンや構成、メモリ配置など条件が揃わないと動作せず、汎用的な攻撃は難しいとの分析が多くなっています。ただしJPCERT/CCなどは、侵害の有無の確認を求めています。

OOMの問題は、2024年の外部監査で兆候が見つかっていたものの、修正方針の合意が難しく、対応が停滞していました。The PHP Foundationはこれを構造的な失敗と総括しています。

03. eMudhra中間CA秘密鍵漏えいと信頼ストア除外

eMudhra中間CA秘密鍵の危殆化インシデントの要約

2026年10月17日、研究者の報告により、認証局eMudhra(emSign)の中間CA証明書8件(TLS用6件、コード署名用2件)の秘密鍵が、公開鍵から誰でも求められる状態だったことが判明した。原因は2025年4月のキーセレモニーにある。承認済みの逸脱手順の最中にコードの欠陥で弱い鍵対がHSM内に作られ、鍵ラベルが似ていたため誤ってCSR作成に使われ、ルートが署名したという。TLS用の鍵があれば任意ドメインの証明書を発行でき、通信の傍受や改ざんにつながるおそれがあった。

対応は迅速だった。報告当日にChromeがCRLSetで、MozillaがOneCRLでTLS用6件を遮断し、Firefoxへの配信はMozillaの受領から3時間未満で完了した。eMudhraは翌18日に8件を失効し、Sectigoも相互署名分の失効を19日に終えた。悪用の証拠は確認されておらず、CTに記録のない偽造証明書はCT強制クライアントでは信頼されなかったとされる。

しかし10月20日、複数の人物が秘密鍵を独自に回収し一部を公開したことが分かった。Mozillaは失効情報を参照しないクライアントも守るため、ルートのemSign ECC Root CA - G3を信頼ストアから緊急除外した。Chromeも10月27日に配信予定のV43で削除する。これにより、危殆化していない中間CAの証明書約30,000件も再発行が必要になり、その99.9%は米国の研究教育機関向けサービスInCommon関連だった。Canonical、Debian、Red Hat、Go、Node.js、Java、Python、Electron、各種CAバンドルも相次いで対応した。

10月22日、eMudhraは世界向けSSL/TLS証明書事業からの撤退を発表した。理由として、売上比率が約1%にとどまること、規制対応のコスト増、無償証明書の普及、本件で受けた過大な精査を挙げている。影響を受ける顧客の証明書は無償で置き換え、根本原因の報告も約束した。ただしキーセレモニーの詳細など、Chromeや第三者からの質問への回答はまだない。

04. AGENTS.md経由でAIエージェント乗っ取り

2026年10月22日、Forever Securityは、顧客端末でAIエージェントが既知の悪性npmパッケージ「function-color」を導入しようとしたのを、コード実行前に遮断したと公表した。指示の出所は、ダウンロードフォルダにあった AGENTS.md だった。エージェントが起動フォルダの指示ファイル(AGENTS.md、CLAUDE.md)に従い、自らの設定を書き換えて乗っ取られるという手口である。誰がどう置いたかは不明で、実攻撃での配置経路も公表されていない。

同社の再現試験によると、Codexでは、開発ガイドライン風の長い文書が個人設定 ~/.codex/config.toml にMCPサーバーを登録させ、悪性パッケージ導入と全フォルダに及ぶ持続性を実現する。信頼ゲート、起動時のみの読み込み、ネットワークのサンドボックス、タイムアウトの各制御を迂回する構成だ。Codexが試験の90%超でマルウェアを実行したとするが、大半は無害な代替パッケージで、試験回数や版は非公表である。Claude Codeでは、ANTHROPIC_BASE_URL を書き換えてAPI通信を攻撃者側へ向け、OAuthトークンの窃取やサンドボックス無効化によるコード実行を狙う。設定書き込みの成立は約半数、同一セッションでのコード実行は約5分の1だった。

Foreverは、エージェントは設計どおりに動いており、開発元がパッチすべき脆弱性ではないとの立場だ。確認項目として、想定外の [mcp_servers.*] ブロックや不審な接続先設定を挙げ、見つけた場合はトークンを更新するよう勧めている。

公表後の検証では見方が分かれた。BleepingComputerは、PoCページで無害な AGENTS.md が保存されることまでを確認し、成立にはその場所でエージェントを起動する必要があると指摘した。一方、第三者はCodex 0.160.1とClaude Code 2.1.296で計80回試したところ、成功は0回で、両者とも攻撃と認識して拒否した。ただし条件が異なるため、Foreverの結果が誤りだとは断定していない。

05. Linuxカーネルに深刻なUAF脆弱性

2026年10月15日に公開されたLinuxカーネルの脆弱性CVE-2026-98432は、IPv4のTCP接続処理で、要求ソケットのIPオプションが解放された後も別のCPUが読み続けるuse-after-freeです。認証は不要で、接続を受け付けるサーバーにネットワーク経由で到達できれば攻撃対象になります。発見と報告はAnthropicで、10月27日にはMPTCPのリスナーを持つサーバーに対し、遠隔からrootでコマンドを実行する実証を公表しました。この実証では、競合で情報を漏えいさせてKASLRを突破し、続いてバッファ溢れでコールバックを書き換えます。PoCに要した時間は、ポインタ漏えいに48分、コマンド実行までに5分です。

原因は、IPオプション付きSYNの再送処理と接続の破棄が別CPUで競合し、通常のkfree()で解放済みの領域を読むことです。要求ソケットの移行機能を使う経路でも同様の問題が起きます。影響は情報漏えい、メモリ破壊、カーネル停止です。修正はkfree()をkfree_rcu()に変更するもので、影響範囲は4.4以降の各系列の修正版より前のカーネルです。上流の修正版は5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3の8系列です。

評価は分かれています。Linuxカーネル CNAはCVSS 3.1で9.8(攻撃の複雑さLow)としましたが、Red Hat、SUSE、Oracle、Amazonは8.1(攻撃の複雑さHigh)です。Ubuntuは3系で9.8、4.0系で8.3としています。KEVには未掲載です(10月29日版)。

配布元の対応状況(10月30日時点)は次のとおりです。

  • Debian:securityリポジトリで修正済みです。
  • Oracle Linux:UEK向けエラータが提供済みです。
  • Amazon Linux:AL2023の一部で修正済みです。
  • Ubuntu:修正版は未提供で作業中です。
  • Red Hat:RHEL 8〜10などが影響ありとされています。
  • SUSE:製品ごとに対応状況が混在しています。

対応としては、最新のstableカーネルへの更新が推奨されています。Red Hatは、基準を満たす緩和策はないとしています。なおAnthropicの実証条件はMPTCPのリスナーですが、CVEの記述はIPv4のTCPサービス全般で、両者には差があります。

06. Binanceから約1兆円不正流出

2026年10月29日、Binanceのホットウォレットから不正な出金が行われ、被害額はBinance推定で約63億ドル(約1兆円相当)に上った。外部の推計もTRM Labsが約63.6億ドル、Chainalysisが約59.12億ドルと近い水準である。Binanceは損失をSAFUファンドと自社資金で全額補填するとし、利用者資金は安全だと説明している。

初期調査では、DevOpsエンジニアのノートPCが侵害された可能性があり、攻撃者がサービスコンテナ経由で不正な出金トランザクションを送ったとされる。秘密鍵の漏えいの証拠はなく、TRM Labsなどは署名インフラの侵害が有力とみている。

オンチェーン解析によると、攻撃者はTornado Cashで資金を用意し、sweeperコントラクトで予行を重ねた。20時05分(UTC)から、XRP LedgerやSolana、Bitcoinなど複数チェーンで通常の署名済み送金により資金を移した。Ethereumでは、Binanceのホットウォレット「Binance 14」にEIP-7702の委任を設定させ、約3分後に16.15億USDTや16万超のETHなどを一括で抜き取った。

対応では、TetherやCircleが約21時に凍結を開始し、Ripple、World Liberty Financial、Paxos、Arbitrum DAOなども凍結を実施した。AaveやKaminoは予防措置を取り、Binanceの凍結総額は約30億ドルに達した。TRM Labsは、凍結できない形の約24億ドル相当を攻撃者が保有しているとみている。

TRM Labsは、北朝鮮のTraderTraitorによる犯行と高い確度で判断した。一方、BlockaidのCEOは「類似しているが未確認」とし、Binanceも法執行機関と特定を進めている。

Binanceは入出金を一時停止したが、共同CEOは入金が通常稼働していると述べ、48時間以内に出金再開を始める見込みを示した。Binance JapanとBinance THも安全確認のため入出庫を停止した。詳細な技術的ポストモーテムは調査完了後に公表される予定である。

07. HTTP2Shell脆弱性に注意

HTTP2Shell(CVE-2026-111497、別名Node2Shell)は、Googleが開発した圧縮方式Brotliのデコーダーに存在する脆弱性です。細工された圧縮データを展開する際、不正データの処理を打ち切るべき場面で処理が続き、内部バッファの範囲外に書き込みが発生します。その結果、プロセス停止やメモリ情報の漏洩、条件次第ではリモートコード実行(RCE)に至るおそれがあります。名称にHTTPとありますが、HTTP/2に限定された問題ではありません。CVSS v4.0は9.2(Critical)ですが、Node.jsの公式告知ではHighとされています。

攻撃経路は2つあります。1つは、Express 5などがBrotli圧縮されたリクエスト本文を展開する経路です。もう1つは、Node.js組み込みのfetchなどが外部サーバーのBrotli圧縮レスポンスを展開する経路です。

影響範囲はNode.jsにとどまらず、Python関連パッケージ(Brotli、brotlicffi)、Bun、Envoy、Istioなどに及びます。urllib3やrequestsはコードにBrotli呼び出しがなくても、パッケージがあれば自動展開するため確認が必要です。修正版はBrotli 1.2.1、Node.js 22.23.4/24.22.1/26.12.1、Bun 1.4.4などです。Go向け実装でもpanicと接続切断が報告されていますが、任意コード実行は実証されていません。

Impervaは、Node.js 24.22.0でのコード実行を複数回の試行で再現しました。ただし、すべての環境で成立するとは限りません。CISAの評価では、2026年10月23日時点の悪用状況は「none」でした。

対策の基本は修正版への更新です。Node.jsはランタイム自体を更新します。Pythonは仮想環境やコンテナーごとに確認し、イメージを再ビルドします。Bunのbun build --compileで作った配布済み実行ファイルは自動では直らないため、再ビルドが必要です。すぐに更新できない場合は、Brotli圧縮データが展開される前に拒否するか、展開を無効化します。Accept-Encodingからbrを外すだけでは不十分です。更新後は稼働中のプロセスへの反映を確認し、異常終了やログから侵害の兆候も調査してください。


本ラジオはあくまで個人の見解であり現実のいかなる団体を代表するものではありません
ご理解頂ますようよろしくおねがいします

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

JAXAの火星衛星探査機MMXが初期クリティカル運用を終え、フォボスの試料を地球へ持ち帰る約5年のミッションが始まった。続いて、PHPの深刻な脆弱性について、修正の遅れや周辺ツール・古い環境への影響、公開後の緊急対応が語られる。eMudhraでは中間CAの秘密鍵が危殆化し、ブラウザやOS、アプリに残る信頼情報の更新が難しい問題が明らかになった。AIエージェントではAGENTS.mdを介して設定変更や攻撃者サーバーへの通信誘導を狙う手口が紹介され、LinuxカーネルのTCP処理にもUAF脆弱性が報告された。さらにBinanceでは内部端末への侵入を起点に、ブロックチェーン処理の外部化機能が悪用され、1兆円規模の資金流出につながったと説明される。最後にBROTLIデコーダーの脆弱性と、オープンソース依存や更新可能な設計の重要性を確認し、相次ぐインシデントに疲弊しながら episode を締めくくる。

MMXの初期運用完了とフォボス探査
スピーカー 2
いやー、無事、MMX飛びましたね。 飛びましたねー、まあ良かったですね。
もう本編、いきなり言っちゃいましょう。 はーい。
今日はネタが多すぎる。 じゃあ、そらえさんの記事で、JAXAが火星衛星探査機MMXの初期クリティカル運用フェーズ終了を発表というタイトルの記事です。
JAXAは、2026年10月21日付で、H-IIIロケット15機で打ち上げられた火星衛星探査機MMXについて、
打ち上げ直後の重要な運用を正常に終え、探査機の健在性を確認したと発表しました。
打ち上げられたのが20日の午前4時、夜です。 H-IIIロケット15機を使って打ち上げられました。
この初期クリティカル運用フェーズとは何ぞやという話なんですけど、
電力を乱す太陽電池パネルの展開、探査機の動きを3つの軸で安定させる3軸姿勢の確認、
通信用アンテナ1つであるミドルゲインアンテナの保持・開放などを含む重要なシーケンスが正常に実施されたと。
ロケットを打ち上げた後に、体と増して初期展開というところまで完了したという話だそうです。
今後は搭載機器の初期機能確認をしつつ、火星圏へと飛行する機関の運用となる往来巡航運用フェーズに向けて準備を進めるということです。
まだまだ先は長いんですけど、そもそもMMXは何ぞやという話。
スピーカー 2
こちらは火星の衛星フォボスに着陸して、表面の物質を採取し地球へ持ち帰ることを目指すミッションとのこと、
火星の衛星からのサンプルリターンが実現すれば世界初となるというところです。
今後10ヶ月ほどかけて火星圏へ向かうという話。
サンプルリターン全工程を成功させて地球に帰ってくるとすると、期間までは約5年かかるという話なので、
結構気の長い話なんですけども、まず打ち上げ成功おめでとうございます。今後に期待ですねというところです。
ありがとうございます。
スピーカー 1
JAXAの専用ページがあるんですかね。MMXJAXAJPみたいな記事があって、
そこのミッションスケジュールがめっちゃ分かりやすいなと思って聞いてたんですけど、
5ステップくらいあって2031年に帰ってくるという仲いい期間ですけど、
その間どこらへん飛んでるのかとかすごい分かりやすくて面白いなって感じで。
次またニュースにやってきそうなところで言うと、ステップ3のところで
火星の月と同じ周回軌道に入る。
我々地球で言うと月と同じように火星の周りをぐるぐる回るところにたどり着くというのが、
2027年から2030年という幅広い時間スパンで書かれているんですけど、
ここまで来たらまたニュースになりそうって感じですかね。
そうですね。最初は多分観測の方をやっているので、
スピーカー 2
サンプル最初は多分後半だとは思うんですけどね。
2029年、30年くらいなのかなって気はしますけど、
それまでちょっと長い運用期間ですね。
今回携わってらっしゃるプロジェクトマネージャーの川勝さんが、
スピーカー 1
ハヤブサ2とかにも代わってらっしゃるのかな?
まあ勝手な期待じゃないですけど、
ハヤブサ2でのあの成功を見るとワクワクしちゃいますねって感じですね。勝手に。
スピーカー 2
まあそうですね。
スピーカー 1
素人目線では似たようなことをやるんじゃないかと思うけど、中身は全然違うんでしょうね。
スピーカー 2
まあ何事もなく初期運用を満足させるのが一番ですし、
帰還してサンプルリターンする都合上、
次のミッションみたいなのがなかなか難しいのかなと思いますけど、
うまいことやってくれたらいいかなと思いますね。
スピーカー 1
この4ボースからサンプルを持ち帰るってことですけど、
前、ハヤブサとかだと弾丸みたいなの打ち込んで巻き上がったのを回収するとかでしたけど、
今回は普通に探査機が着陸してそこで回収してまた打ち上がるんですかね?
えーと、よく分からないな。
スピーカー 2
今回の回収はなんかローバーみたいなやつを使う…
いや、そんなことないかな。
探査モジュールが別枠であるんですよ。
スピーカー 1
はいはいはい。
スピーカー 2
サンプラーでいいのかな?
スピーカー 1
なるほど。
まさしく最終用の系がある。
スピーカー 2
そうですね。着陸して、何だろう、ちゃんと着陸して回収するみたいな形ですね。
スピーカー 1
なるほどね。
ハヤブサとかと…
スピーカー 1
ハヤブサじゃないわ。
ハヤブサって言ったら探査機のほうだ。
リュウグウでしたっけ?とかと違って、
ちゃんと着陸できるくらいに大きいんですかね、4ボースって。
4ボースの大きさの実感もあんまりないんですけど。
スピーカー 2
4ボースはだいぶ大きいはずですね。
4ボースのサイズ感っていくらだったかしらね、とは思いますけど、
スピーカー 2
半径11kmぐらい。
スピーカー 1
全然ピンとこない。
半径11kmってめっちゃちっちゃいんじゃない?量。
スピーカー 2
地球とかと比べると小さいけど。
スピーカー 1
月と比べても月って半径1700kmくらい。
スピーカー 2
かな?
スピーカー 1
月直径3500kmみたいに出てくるから、約。
4ボースは結構ちっちゃいのでは。
スピーカー 2
そうですね。
ちっちゃいって言ってもあれか。
スピーカー 1
小惑星と比べたら十分大きいのか。
リュウグウの方は直径が0.9kmとかなんで、
さすがに全然違いそう。
スピーカー 2
大阪梅田から考えるとちょうど東京湾あたりぐらい。
東京湾じゃないな。大阪湾ぐらい。
スピーカー 1
東京湾くらいってなったら急にでかくなる。
まあまあまあ、なるほどね。
スピーカー 2
長崎駅ぐらいまでが直径10kmぐらい。
半径10kmぐらい。直線距離で10km。
スピーカー 1
じゃあだいぶでかいね。
そこだけでかけりゃ着陸もできるっしょって感じか。
そうですね。重力は言うとだいぶちっちゃいから、
スピーカー 2
なかなかソフトタッチって感じになる気はするけれど、
足場はあるぐらいみたいなイメージですね。
スピーカー 1
まああれかな、また2027年、
さっき言った2029年頃でしたっけ。
本当に着陸するぞっていう直前になったら、
スピーカー 1
もう少し詳しい解説とかも出てきそうなんで、
ちょっと楽しみだな。
これが得られると、
ああそうか。
スピーカー 1
リュウグウとかは完全に外からやってきて、
太陽系に入ってきたやつをサンプリングしたって話で、
これは遠い昔に火星の重力に引っ張られたものになってて、
火星に何かぶつかって、
飛んだ破片が固まってこれになったのか、
外からやってきたのか、そのままひっついて
この軌道系に乗っかったのかっていうのが分かる?
分かるんかそれ。
スピーカー 1
言っといてなんだけど。
スピーカー 2
確かめるためのデータの一部にはなり得る。
スピーカー 1
はいはい。
なるほどね。
どっちにしてもすごいロマンあるけどな。
なるほど。
まあまあまあ。
スピーカー 1
これ以上は楽しみだな以外のコメントが難しいですけど。
はい。
スピーカー 1
アートシティって言うんだったら、
H3ロケットを落ち着いて打ち上げられるようになってきたなっていう感触があります。
なんか打ち上がったことに対しての驚きというか感動が、
みんなもう打ち上がって当然みたいな雰囲気を顔をしてる人が増えてきた気がする。
これはもう仲の人じゃないか。
仲の人とかいろいろ問題あるし、
この前もなんかいろいろあったけど、
スピーカー 1
世間一般のニュースの雰囲気は、
もう1回打ち上げられたんだから他も成功して当然でしょみたいな風向きになってきて、
ギャップがありそうだなと思ってる。
スピーカー 2
まあ3回打ち上げられたしね、連続で。
うん。
実態は白標の上を歩いてるかのような気持ちかもしれないけど、
世間の評価はだいぶそうなってきたかなって思いますね。
スピーカー 2
まあ打ち上げられてるうちはどんどん打ち上げて実績積み上げていきたいしね。
結構頑張ってるなと思うのが、
6月に6号機打ち上げて、8月に9号機打ち上げて、10月に15号機打ち上げてるから。
2ヶ月に1回ぐらいのイメージで打ち上げられてる。
スピーカー 1
こう言っちゃうんだけどめちゃくちゃと思えないテンポが。
スピーカー 2
まあ詰まってたっていうのはあるだろうけど、
このくらいで打ち上げるのを目標にしてたっていうのはあるから、
このまま頑張って打ち上げられれば、
当初目標の打ち上げ頻度は確保できる気もするけど、
結構大変な感じはするね。
そうね。
スピーカー 1
じゃあ今後も応援ということで。
スピーカー 2
はい。
PHP脆弱性と緊急パッチ対応
スピーカー 1
じゃあ次行きたいと思います。
次からはセキュリティインシデントラッシュなので、
心を強く保ちながら話していきたいんですけれども、
スピーカー 1
ちょっと数も多いし一件一件重たいので、
さらっと話してさらっと次にいければなと思います。
1個目が10月21日にPO6さんの方でも公開された
PHPの脆弱性の話です。
このPHPの問題というのは、
我らが高市さなえ首相が直々に
第1級のお願いですと言ってツイッターに投稿するくらいの
事例案になっていまして、
かなりのインパクトがあるというところです。
世界の7割くらいがPHPの影響を受けるということもあり、
世界的なシステムダウンにつながっていて、
当時21日の日本時間夜にはほとんどのサービスで
メンテナンス中の画面をみんな目にするという、
スピーカー 1
そんな時代になったのかなと思っています。
それくらいのスピード感になっていた理由はいくつかあるんですけれども、
そもそもこの脆弱性というのが、
PHP内部ではとっくに発見されていて、
今回緊急で上がったかのように見えたのは、
そういうふうに昔からある問題だと思っていて、
改めてハッカーニュースとかにポロッと投稿した人が、
前からあった問題だし今どうなってんのくらいの気持ちで
公開したというところからだったので、
クリティカルな脆弱性が、
あんまり悪意なく公開されてしまったといったところが背景にあったりします。
脆弱性のパッチも21日の当日23時には、
23時には当ててないと攻撃始まりますよということを発信したというのもあって、
余計に緊急性の高い脆弱性になったというところになっています。
内容としては一般的な昔からあるような脆弱性で、
メモリ不足、OMと言われるような、
メモリを逼迫させて攻撃する手法になっていて、
別にこの問題自体はよくある話ではあったんですけれども、
対処が遅れた一番の理由としては、
PHPの内部の耐性の問題があって、
当初見つかった時点では、
これの対策方法として、
下位互換性を捨てるか、
PHPを使った周辺ツール、拡張機能ツールを開発している周辺ベンダーに、
全員こういう問題があるから、
その周辺ツールもこうやってパッチ当ててねって言って回って、
全員に対してお金を払っていくかみたいな、
どちらの選択にするかというようなジレンマに陥っていて、
経営層というかPHPのトップ層が判断しきれないまま、
今回の問題に立ったといったところも、
人材的なところも含めて、
脆弱性としては問題が大きかったというところになっています。
この問題自体のパッチは、
皆さん頑張って直したみたいなところはあるんですけれども、
影響が多くてですね、
このPO6さんの記事でも、
かなりの企業名がずらーっと並ぶような事態になっておりますし、
今週、今週じゃないわ、先週か、
この脆弱性の修正が終わった次の週には、
別のクリティカルな脆弱性がPHPで報告されて、
そっちはこの問題ほど大きくなかったんですけれども、
さらなる脆弱性がどんどん見つかっているということで、
PHPを脱せなければならないみたいな動きすら起きているというのが、
現状の動きになっています。
ざっと以上です。
いくつか話したいことがあるかなという感じですね。
スピーカー 2
不具合辞書、脆弱性辞書自体については、
メモリーリークみたいな感じ?
スピーカー 1
そうですね。
スピーカー 2
というイメージなので、
任意のコードが実行できる可能性があるということ。
了解です。
さっき話していた経営層が判断が難しかったという話は、
結局今実行された対策はどういう対策?
どっちの話になったってこと?
スピーカー 1
介護管制の…
あ、違う、逆や。
関係ツールに緊急で直してって言ったっていう状態だった。
スピーカー 2
準備できるところは、
公開と同時にパッチを当てますっていう対応しますって言っていた。
準備できていないところは、
今でも閉店状態みたいな感じになっている。
スピーカー 2
もしくはそのまま開け広げているという感じ。
スピーカー 1
そうね。
だいぶPHP側もお金出したっぽいから、
やってない周辺はないのかなと思うけど。
このPRログの記事で言う、
Linuxディストリビューションなどの対応状況って書いてあるセクションがあるんですけど、
こういう関係者ですよね。
カーネル周りのところもあるから。
修正が済んでいない、または状況が異なるものが次の通りっていうのが末尾にあって、
ここら辺が追いついていなくて、今の状態っていうやつ。
スピーカー 2
でもRed HatとかAzureとかダメなんだ。
スピーカー 1
の一部ですね。
古いやつはもうサポート買いにしますって切り捨てたっていう話。
スピーカー 2
うちはサポート買いですよっていう通知は出しているが、
それを独自で使っている人は面倒まで見れてないので、
穴が開いたまま使っている人もいるであろうという感じ。
スピーカー 1
そうそうそう、そういう感じ。
Windowsとかで言うと、Windows7くらいまでサポートしてたっていうのをずっとWindowsは言い張ってたけど、
Windows7でもこういうPHPの問題みたいなのが見つかったから、
いよいよWindows7はやめるわって言ってバサッと切り捨てた。
けど世の中にWindows7使っている人まだまだいるよねみたいな、そんな感じ。
スピーカー 2
そういう意味で言うと、何て言うのかな。
ディストリビューターは真摯な対応をしていても、
世にはもしかしたら半分以上パッチが対応できていないものを使っているのがあるみたいな感じなのかしらというところですよね。
スピーカー 1
その実態は正直わかんないというか、
そこを調査する人は地獄の窯の蓋を開けるかのような感じになるから、やってないだけな気がするけど。
スピーカー 2
どっかやってるんじゃないのかな。
スピーカー 1
やってるのかな。
スピーカー 2
GoogleあたりがBotでクロールして、あなたのディストリビューションバージョンみたいなのを絶対取得してるでしょ。
してそうではある。
スピーカー 2
セキュリティーカンファレンスとかで言えるんじゃないの?そういうのって気がするけど。
スピーカー 1
まあ確かに。
ちなみにBHPがお金出してとか言ってましたけど、BHPの運営母体ってそんなお金持ってるんですか?
スピーカー 1
The PHP Groupってどこが独立した企業なのかどうかあまり知らない。
スピーカー 2
どうなんだろう。結局Amazonとかが出資してるとかそういう感じなのかな。
あんまり特定企業のお金を受け取っても困るよな。
スピーカー 1
PHP財団による寄付と助成金で運営されてるんだって。
スピーカー 2
なるほどね。
じゃあ寄付ベースのお金ってことね。
スピーカー 1
外部企業から寄付という形はもらってるんだけど、外部企業からお金が回ってくるマネダイズ経路っていうのは一応存在して、
そのPHPのコントリビューターとして中の開発をしつつ、
そういう立場で動いているからということでPHPの開発コンサルをやったりとか、
有料の開発ツールを提供したりとかでマネダイズしてそれをさらにPHPに還元してみたいな動きも主演企業としてあるみたい。
ある種の副業サービスみたいな。
有償での開発委託とかそんなイメージに近いみたいだけど、母体として直接受けてるわけじゃなくてっていう感じみたいです。
スピーカー 2
ちなみにさっき最後に言ってた対応別の脆弱性ってどんな脆弱性?
スピーカー 1
スコア的には8くらいだったと思うんで、そんなに大きくない。その機能を使ってる人は影響ありますよくらいの脆弱性だったと思う。
スピーカー 2
これはメモリーリークなんでマジでみんなメモリーリークできるけど、それは特定機能ベースの脆弱性ってこと?
対応してるところと対応してないところがごっちゃになってると思ってて、正直だいぶ両方全部抜かれる感じがするので、対応してないところを弾くぐらいの強い意思を持ちたい気もするんですけど。
どうなのかな?
それが現実的に可能なのかって話?
スピーカー 2
そう。例えばブラウザのエクステンションで対応してない場所を弾くみたいなオプション。エクステンションというかオプションを有効にしてみたいなーみたいな気持ちもあるけど。
httpsになってないところは今デフォルトでブロックしてるじゃん。
スピーカー 1
そうだね。
スピーカー 2
同じような状況なんじゃないの?っていう気がしてる。
スピーカー 1
そうね。世の中がそこまで過劣な対応を求められるようになれば、それってPHPに限らないじゃないですか。
あらゆるフレームワークやあらゆる言語で脆弱性のクリティカルレベルを対応していないもののままコスティングを続けている企業はブロックされるべきっていう。
そういう世の中になればブラウザ側もサポートするんじゃないですかね。
スピーカー 2
少なくともでもhttpはそうなったわけでしょ。スピード感が全然違うといえば違って、あれも5年10年レベルだとは思うんですけど。
ただ、その5年10年レベルはポストAI時代にはそぐわないので、そこは意識を切り替えてどんどんオプションを増やしていってもいいんじゃないのって気もするけどね。
スピーカー 1
昔から培われてきた長期にあるインターネット資産みたいなのが減少するとかリーチできなくなるとかいろんなことを言う人はいるだろうけど、そうも言ってられないよねっていう感じな気がするな。
スピーカー 2
まあそこはある種の自己責任で今でもだからツーツーのサイトでも行こうと思えば行けるわけで。
スピーカー 1
そうだね。そういうブラウザ側の進化っていうのはもちろんちょっと求められてきそうな気がしますね、社会的に。
スピーカー 2
そうですね。
スピーカー 1
いろんなセキュリティー因子といっぱいあるので、こういう論的な話は一旦最後にもう一回まとめてしたいなと思うので、サクッと次行こうと思います。
eMudhra中間CA秘密鍵の危殆化
スピーカー 2
はい。
スピーカー 1
次はイームードラの署名の話です。これもえぐちぃです。
10月18日、モジラは認証局イームードラの中間紙証明書の秘密鍵が既得化したインシデントをバグジラに起票し10月20日に公開しました。
ここで関連する情報をまとめますということでビオログさんの基地です。
イームードラの中間紙証明書のうちTLS用6件とコード署名用2件の秘密鍵が公開会から誰でも求められる状態だったことが、2026年10月17日に研究者から報告された。
対象はEM-EV-TLS-CA、EM-OV-TLS-CA、EM-DV-TLS-CAのそれぞれG-3BとG-3CとEM-OV-CSCのG-3BとG-3C。
発券はいずれもSectigo AAA Certificate Serviceの総合証明を設けており、同じ鍵の証明書は16件になる。
イームードラ発券ともエンドエンティティ証明書は発行しておらず、本番で使われたのは1件のみとしている。
スピーカー 1
証明書の話をする前に、認証局ってなんぞやって話をまずしないといけなくて、
私たちはブラウザでhttpsでアクセスするときに証明書というものを取り交わしています。
この証明書というのはサーバー側で私たちこういうものですというのが発行されていて、
誰々でどういう人でそこと通信する場合はこんな鍵でやり取りしましょうみたいな、そういうことがいろいろ書いてあるものです。
その証明書の中にある鍵を使うことで、そのサーバーとの間の通信に対しては暗号化されていて、
そのサーバー側でしか複合できないということになって、その人からのぞき見られたりとかそういうことがないようになっているというのが証明書の話になります。
この証明書というのが誰かが勝手に考えた証明書とかになっていると全然意味なくて、
スピーカー 1
誰か個人が俺が考えた最強の証明書だぜって言っても、その証明書が本当に社会的に大丈夫なやつかどうかっていうのが認められていないと、
その特定の個人の人が証明書を横流ししたりとか、同じ証明書を別のサーバーでも使ったりみたいなことをやっていると、
全然さっき言ったような証明書の価値がなくなるということで、第三者証明として認証局というのが設けられるようになっています。
この認証局とアクセスする元のクライアント、ブラザーを開いている人たちの間で、この証明書って本当に大丈夫なっていうのを確認しに行って、
大丈夫、うちがお住みつけているから大丈夫だよっていうのを推してくれる。そんなのが認証局になっています。
スピーカー 1
今回これが大問題なのは、その第三者が証明するというその認証局において問題があったといったところなので、
この信じたいはずの第三者が信用できなくなりましたというニュースで大騒ぎになっているという話です。
実態としてその公開鍵が誰でも求められる状態であったというのが何が起きていたかというと、
本来鍵として設定するための情報というのが、当たり前ですけど256バイトとかすごく長いものになっていて、
簡単にはハッキングできない。量子コンピューターとかだったらもしかしたらハッキングできるかもくらいの難しい暗号を使って、
その証明書の認証を行ったりとか、証明書を認定したりとかするわけですけれども、
今回そのEMoodlerが証明する内容というのがたったの1バイトでしか証明されておらずですね、
スピーカー 1
1バイトなんてもう分析したい放題、解析したい放題という状態になっていて、
全く証明が役に立っていなかったということでした。
現在はこのEMoodlerのその1バイトの証明っていうのは認証できないようになっているんですけれども、
問題はこの証明書の認証局の世の中の取り扱いが良くないという問題があります。
Windowsのところで証明書のインストールをするときに、
信頼されたルート機関という証明書の枠を目にしたことがあるかもしれないんですが、
結構各OSの中にはですね、ここはもう大丈夫だから証明書のサイドのチェックはしなくていいよっていう、
そういう登録ができるわけが存在してしまうんですね。
そこで登録されている証明書とかだと、このEMoodlerにもう一回確認しに行くとかそういうことをしないので、
スピーカー 1
このハックされ得る1バイトでしか証明されていないものを使って通せてしまうということが起きます。
それができてしまうと、本来は怪しいサイトとかで通せないはずのサーバーに無理やりその証明書を使って通すみたいなことができてしまうので、
さっき言ったHTTPSで守られて、それがブラウザではブロックされているみたいな世界から、
実は表面上はHTTPSなんだけど、悪意あるサーバーに不正につながっている状態が検出できなくなるというような、
そんな事態に遭ったものでした。
この問題を受けて各社ブラウザは緊急のパッチリリースを出して、
このEMoodlerの証明書だと検知された場合は即刻無効化するような対処が取られたんですけれども、
先ほど言った通りOSの中に残っている信頼されたルート証明書は消えないし消しようもないので、
これは全クライアント全ユーザーが自分で管理しなければいけないことになっていて、
それの対応がクソ大変という話と、
もう一つは、このHTTPS時代になってですね、
あらゆるネイティブアプリが外部と通信する際に内部で証明書を抱え込んでいるアプリというのが多く存在します。
Javaで作られたアプリとかPythonで作られたアプリとか大体そうですし、ノードもそうなのかな?
本当に世の中で動いているありとあらゆるアプリというのが、
必要な証明書を内部に取り込んで、その証明書で動くというような運用されていることが多くてですね、
結果的にそれらの証明書にこのEMoodlerの件が含まれていたりすると、
スピーカー 1
そこもまだ抜け穴として使い続けられてしまうというようなところもあって、
そういうものを撒き散らしたEMoodlerの罪が大きすぎるんですが、
スピーカー 1
本人たちはすでに撤退して、私たちは知りませんというスタンスを取っているので、
ちょっと社会的にヤバいという感じですかね。
はい、以上です。
スピーカー 2
はい。うーんと、何でしょうね。
えーと、証明書の話はだいたいわかっているんですけど、
まあ超簡単に言うと、ちゃんとこの人は安全な人ですよっていう、
なんていうの?
あのー、保証が書かれた書面があるけれど、
実はそれはひらけごまって言ったら自動的に何枚でも擦れるものでしたというお話。
で、この保証書って本当なんですかって、
本家まで確認しに行けば一応ないってことの差分は取れるけど、
そういうことをいちいちやってられないので、
なんか本物っぽいことが書かれていて、なんか反抗もされてるし大丈夫だわっていうのでみんな通していたのが、
実際そうじゃないよということになったので、
まあその証明書自体の価値が既存されましたと。
うん、そう。
スピーカー 2
これ逆に、いつから?
スピーカー 1
いつからそうだったんだっけな。
スピーカー 2
いつから21バイトだったの?って感じで。
スピーカー 1
2025年4月30日。
スピーカー 2
なんか年間ごとに更新するやつでやってたところで、ぽかやらかしたって感じ。
なのかな。
か、もしくはそれ以前のものはでも抱え込んでたら使ってるところもあるよね。
スピーカー 1
eMoodlerの説明としては、
2025年4月30日のキーセリモニー、キーセリモニーがちょっと分かってないですけど、
の中で作った中間CA24件のうち、B系列とC系列のP384キーにあたるG3BとG3Cは、
スピーカー 2
欧州と米国の運用向けに作られたもの、という説明だそうです。
はい。
で、結構なんか試験的に作られたものがそのまま含まれちゃったっぽい。
はい。
スピーカー 1
だからそんな1バイトでもともといいって思ってたわけではなくて、
とりあえずこういうものがあった方がいいよねっていうので、
スピーカー 1
一旦1バイトくらいで家で作ってそれで試していたものが、
ラベル名が似てて、G3CとかG3Bって聞いてても混乱すると思うんですけど、
そういうラベル名が似てて、そのまま使われて署名されちゃったっぽいです。
スピーカー 2
なくはないけど。
スピーカー 1
ヒューマンエラーに近いのかな、だから。
信用サイトだからそうでもあっちゃいけないことだよねっていう感じで。
スピーカー 2
まあでも1年くらいは意外と誰も試してみてなかった。
1年じゃないか2年か。
2年半くらいは誰も試してなくて、
誰か知らんけど実はハックできるんじゃねってやった人がいて、
そしたらチーンできましたってなったみたいな感じなのね。
スピーカー 1
そうだね。
まあなかなか大変ですね。
スピーカー 2
なんか難しいな。まさか1バイトだとは思わんから、
それの検証ロジとかもね、わざわざ作らんしなみたいな感じ。
スピーカー 1
まあそうだね。さすがに誰も思ってなかっただろうね。関係者も。
スピーカー 2
だから2年破られてなかったわけね。
そうだね。
スピーカー 1
この中間認証局と呼ばれる存在がどれくらい世の中に多いかというと、
3000から4000個くらい存在する。
それの中間じゃない大元のルート証明、最上位の証明機関としては150から200個くらい。
そのうちの実質70社くらいがまともに運用されてて、
そこだけに大量にこの世界中で行われているHTTPSの通信が全部そこに集中したら当然崩壊してしまうので、
中間認証局として委任された機関があるみたいな、そんな感じみたいです。
スピーカー 2
あとは後始末なんですけど。
スピーカー 1
後始末ね。
スピーカー 2
さっき言ってたみたいになんだろうな。
ブラウザからは消されたけど、アプリが個別に持っている分はどうしようもないみたいな話?
スピーカー 1
そうだね。
スピーカー 2
結局そこも今まで問題が生じてなかったから効率のためにそうしているという話なんだろうけれど。
微妙。これもなんかさっきの話と一緒だな。
理想的に効率を重視した上でちゃんと対処するならそのアプリが全員、
じゃあ来週までにこれ対応しろよなんですけど。
スピーカー 1
そうだね。
スピーカー 2
それができない以上、
例えばそのOS側が強制的に閲覧しに行って、
こいつ昔のやつ持ってるから起動させねえみたいな対処が必要かなって感じですね。
スピーカー 1
いろんなところでトラブルは起きるんだけど、
パブリックな証明書についてはもうアプリの中でもっていようがOSの方が優先されるみたいにするとか、
ちょっと何か考えないといけないね。
スピーカー 2
それもあって、認証系はOS側に一括管理してもらって、
それでこれいいっすかってOS側にお伺いを立てるとか。
HTTPS的にどうなんだろう。アプリをまたいで暗号キーのやり取りってどうなんだろう。
スピーカー 1
認証だけ通せばいいのか。
難しいのが相互認証の話で、
サーバー側がさっきは証明書を出してくるって話しましたけど、
逆にクライアント側、送る側にも証明書があって、
私こういう人ですっていうのをサーバー側に渡して、
お互いにその証明書を読み合って、
やっぱり信頼できる人だっていうのを確認してやり取りするという処方証明があるんですけど、
アプリに含まれているケースの3分の1くらいはその目的なんですよね。
特定のサーバー、特定の会社が提供しているアプリが、
スピーカー 1
他の人から同じ口が使われないように、
その証明書を配布しているアプリの中に組み込んでおいて、
そのアプリからのリクエストだけに絞る、みたいな使い方で提供されてたりするから、
その場合ちょっとややこしいんですよね。
そこまでいったらもうちょっとHTTPSという文脈でそれを実現しようとしたっていうのが
テクノロジー的に良くなかったみたいな振り返りになっちゃうのかもしれないけど。
スピーカー 2
あとはアプリの中にOSレベルで自動更新されるコアアプリみたいなのを持っていて、
そいつに全部ぶん投げるとか。
ドットネットとかだったら多分そうできてたんだよね。
スピーカー 1
ドットネットってOS側ってWindowsのフォルダ直下にインストールされてて、
そのOSレベルのリクエストを呼ぶときのライブラリーとして
ドットネットが出されるみたいな感じだったんで、
そのWindowsの上で動くネイティブアプリは必ずWindowsが提供するそのドットネット会社でしか
OSレベルを超えてやりたいことができないみたいな形になってたから
ドットネットのライブラリーさえ更新されていければ
証明書も自動的に一緒についてくるみたいな
OSレベルになっていくって世界観だったんで
そういう作り方してれば多分問題にはならないかな
スピーカー 2
ドットネットってドットネットフレームワークスのドットネット?
スピーカー 1
そう
スピーカー 2
それも久しぶりに聞いたレベルな気がしますけど
スピーカー 1
まだ現役で動いてるやついっぱいいるから
スピーカー 2
最近あそこらへんの手当てしたことないけど
手当てしたことないっていう時点でお察しですよ
スピーカー 1
みんながそこを使ってアプリを作った時の運用とサポートの難しさに
ヘキヘキしてみんなそこから逃げたからね
みんな独自でやっちゃおうって感じ
だから画像証明書インストールしてるアプリが多いんだよな
スピーカー 1
独立して動かせるようにしたいからって
スピーカー 2
なかなか今パッといい例えは出ないと思いますけど
ちょっとここらへんもポストAI時代として
何か考えていく必要がありそうですね
というところまでかな
スピーカー 1
次行きましょう
AGENTS.mdを介したAIエージェント攻撃
スピーカー 1
次がダウンロード先支持ファイルを介した
AIエジェントのノートについてまとめてみたということで
こちらもピオログさんの記事です
これは本当にAI時代っぽい話で
スピーカー 1
AIが頑張っていくのに連れて
セキュリティのインシデントリスクも増えてるよねっていう
それの一例です
ここはさっきまでの話と比べると
見当たらしさだけがあって
重要度は低いのでもうさらっと流しますね
起きたこととしては
スピーカー 1
ある開発環境で
生成AIに指示を出すときに
生成AIに開発だとこんなこと調べて
こんなことを見ながらこんな風に実装してねみたいな
一連の作業の仕方とかを書くようなものがあります
そういう作業の一式っていうのを書くのに
agents.mdというファイルが使われていて
単なるテキストファイルなんですけれども
ここにこんなところを見ながらこんな風にやってねっていうことが
自然言語で記載されているというようなものがあり
世の中ではこれを使った開発効率化っていうのが
どんどん進められているという状態になっています
この中にですね
環境準備
開発をするときにはこういう風にやってねみたいな
ところのセットアップ系について書けるような
ノウハウみたいなのがあって
agents.mdの書き方レベルの話なんですけど
そこにですね
うまく通信ができないときには
こういう風に回避してねこういう風に回避してねっていうような
例外時の対応も書けるようになっています
今回攻撃者によって
行われたのは例外時に振る舞われる
回避策のところに
攻撃者が
持っているサーバーを経由してやってねっていう
そういうことにしますと
スピーカー 1
結果的に生成AIのクロードコードとか
コテックスと言われるものは
本来本家のOpenAIとかアンソロピックと
AIのやり取りをするっていうものになっているんですが
攻撃者のサーバー経由でクロードコードに飛ばすような
ことになっていて
あるユーザーの生成AIの開発
っていうことの中身を全部覗き見れるようになりました
というものでした
こんなのは例明記なのでそういうこともあるわな
っていう話ではあるんですけれども
セキュリティの攻撃対象として
今最もモダンなやり方っていったところに
セキュリティリスクがそのまま入ってくるというような
エージェント.MDの中身の書き方とか
規定されてきたっていうのはまだまだ
標準化されきってなくてですね
スピーカー 1
コテックスやクロードコードでも日々
こういう書き方がいいんじゃないかこんな書き方がいいんじゃないか
かなり模索が続いているようなレベルの段階にあるんですけれども
その言った
出てきてまだ1年くらいしか経ってないようなものに対してでも
攻撃は始まってますよということで
共有でした
スピーカー 2
進むも戻るもいかぬとは
どうしようもないですねという感じ
スピーカー 1
どうしようもないですね
スピーカー 2
そうね
どうしましょうねという感じですけど
スピーカー 1
そうですね内容だけ見ると
本質的にはエージェント.MDは単なる
パスとして使われただけで
本質的にはですね
AIに自律的に回避コードとかを取らせた回避先に
脆弱性を持ってくれば何とでもできちゃうよね
っていう話なので
それってエージェント.MDをどうこうしたりとかやめましょうとかいう話では全然ないんですよね
だから
AIを使って自律的に作業させると
なった時のその振る舞いが
スピーカー 1
第三者によって勝手に悪い方向に
仕向けられる可能性を考慮してAIを動かしましょうねって話になるんですけど
今人間はもう
接AIの動きが早すぎて正直ついていけないみたいになってるので
そこまで細かくモニタリングできない
オープンAIの
サンドボックス抜け出しと似たような話にはなってきてるから
それ考えると
このセキュリティリスクは
本当に何も作業ができないガチガチのサンドボックスでしか
AIを動かせませんみたいな極論しか解決策がないから
変なことしてないか
たまには見ましょうね
くらいしか言えない気がしますね
スピーカー 2
本当?
そうなんですけど
それ以上の言うことがないですね
スピーカー 1
次行きます
LinuxカーネルのTCP UAF脆弱性
スピーカー 1
次がLinuxKernelの脆弱性についてまとめてみたということで
10月15日
LinuxKernelのCNAは
IPv4のTCP処理にあるユーズアフターフリーの脆弱性
CVE-2026-98432を公開しました
ここでは関連する情報はまとめます
LinuxKernelレベルの脆弱性で
CVSSが9.8もあるという
なかなか恐ろしい脆弱性の話です
中身もまた技術的に細かすぎて
私が頑張って読み解いた知識でしゃべるので
間違ってたらごめんなさい
使われた技術としては
マルチパスTCPです
普通のTCPの通信で渡せる
スピーカー 1
データのサイズは決まっているので
何回もそのTCPでデータをやり取りしようと思うと
帯域に上限があると
動画とか大きいデータを捌こうと思うと
なかなかストリームとかダウンロードしてくるの遅いな
みたいなことあると思うんですけど
そういうのを解決するために開発された企画として
マルチパスTCPというのがあって
複数のTCPセッションを張って
同じデータ源なんだけれども
それを一気に複数の帯域で落としてくれるようにすると
そういった機能になっています
今回起きたこととしては
そのマルチパスTCPのリクエストを受けた後に
速攻で通信を破棄する
みたいなことをすると
同時処理のためにいろいろ並列処理を
CPUに回すことになるんですが
その中で
シン・アックというような
応答を返すようなものがあるんですけど
その応答の組み立てを終えて返そうとした時には
すでにその通信が破棄されている状態が作れて
その時にはすでにもう
返す先はないはずなのに
返す先をメモリ上から探しに行く
みたいな動きができて
そこで不正なことをさせられるというものです
なのでこれも
CPUのメルトダウンとかと同じような感じで
先行的に動いている
他の処理がメモリを
リークさせているというか
そういった状態になるものになっています
ここについては本当にTCPレイヤーレベルの話なので
先ほどのOSレベル以上の
攻撃手法たちと比べて
Linux OSであれば
誰でも攻撃できてしまうというものになるので
非常に重たいニュースになっていて
今は各社最新バージョンに上げてくださいね
という形にはなっています
これも大きいところで脅威でした
スピーカー 2
大きいところですけど
同期処理も
なんだろうね
スピーカー 1
パフォーマンスを重視でセキュリティを捨てる
みたいなことになっているケースがあまりに多すぎるよね
スピーカー 2
やっていることが難しいから
そうなるし
人間の限界を超えたところの処理をやっている
ところに対して脆弱性が
発生している感がちょっとある
スピーカー 1
あるある
スピーカー 2
C言語だとメモリリーク起こしやすいから
もうやめましょうレベルで
そういうのもやめたらという感じが
ちょっとあるんですけど
スピーカー 1
わかりますね
スピーカー 2
あとワッパも悪いし
みたいな
スピーカー 1
市場があまりにも性能を求めすぎた
弊害な感じがするよね
スピーカー 2
ちょっと自然回帰した方がいいんじゃないの
って感じが
スピーカー 1
これくらいでみんな我慢しようよって言える世の中にならないと
対処できない
スピーカー 2
ゴリゴリ陶器的処理をやって
性能を上げる方向ではなくて
もっと別の方向
ちょっとわからないですけどね
世界中の頭のいい人が考えた結果これだから
CPUでひたすらクロックを上げていた時代から
超並列化させるようになったみたいな話
別の方向性の成長線を
描いた方がいい気がするなという感じですね
わかる
スピーカー 1
この辺もそうだけど
レガシーな技術
当時は非同期でやることを前提にしていた技術を
無理やり頭ひねってひねってひねり倒して
効率を上げ続けると
こういう穴しか増えないっていう
いい事例な気がするよな
スピーカー 2
これは見つけられたのも凄いしな
スピーカー 1
凄いな凄い
メルトダウンの時と同じくらい凄い
スピーカー 2
よく見つけるわって感じ
AI時代だとこういうのがポロポロ出てきますって感じ
あと一つなんですけど
スピーカー 2
CVEこれで9.8あったら10って何だっていう
感じがちょっとあって
スピーカー 1
そうね
スピーカー 2
ちょっと調べたら
GitLabって10レベルあったらしいんだけど
もはや深度10みたいなレベルだよね
マグニチュード
スピーカー 1
取り上げなかったけど
GitLabの10の方
スピーカー 1
私GitLabを仕事で運用している関係があって
もう阿鼻共感でした
本当に大変だった
スピーカー 2
なんかもうインフレして
9.99みたいな
スピーカー 2
9.88、9.89みたいな
細分化しないと処理できなくなりそうなレベル
スピーカー 1
そうだね
一応スコアの考え方
各社のスコアの出し方は微妙に違う所あるんですけど
ざっくりの考え方としては
攻撃された時の影響度
攻撃のしやすさとか
そういったものでスコアリングされているので
今回のLinuxの件が9.88と留められているのは
攻撃の手法が複雑だから
なるほどね
スピーカー 1
ちょっと難しい
スピーカー 2
そうは言うても他がマックス状態だから
対応しないという選択肢はないわけで
みたいな
スピーカー 1
そうだね
TCPレベルで攻撃できちゃいますと言われると
逃げ先ないんだよな
アプリケーション層ではどうにもならないから
多くのアプリケーション層以上でしか
仕事していない会社機とか
個人ではどうにもならない
スピーカー 2
そういう所に同期的処理なんて
隠し玉をぶち込むから
スピーカー 1
でもそこに同期処理が入っているから
世の中全体が1%でも上がると
大きな効果があるみたいな
スピーカー 2
全員それをやっているわけですからね
まあまあ
スピーカー 1
市場原理は難しい
Binanceの大規模資金流出
スピーカー 1
次の話はお金の規模が大きい話です
推定1兆円相当のバイナンスの
不正出勤事案についてまとめてみた
ピュアログさんの記事です
スピーカー 1
バイナンスさんは
暗号通貨の取引をされているところで
ブロックチェーンを運用されているところです
そこから1兆円規模の
スピーカー 1
資金流出が見られたということで
今は入出金の停止とか
そういった状態になっていたりします
お金自体の補填は
行われるということになっているんですけれども
何が起きたかという話ですね
一番最初の侵害手法は
公表されていないし
今後も公表されないのかなと思うんですけど
バイナンスの中の
運用している人たちのノートPCが
まず侵入されましたというところです
そのPCから
不正なアクセスとして
行われた処理があるんですけれども
それが分かりやすいような攻撃ではなくて
例えばAさんのお財布に
Bの会社にあるお金を一気に移せ
みたいな指示が不正アクセスとして
行われたわけではなくて
スピーカー 1
ブロックチェーンの処理の中に
この一連の処理は
この外部プログラムに移任して行う
処理の異常というルールがありますと
これはブロックチェーンの処理が
集中的にいっぱい行われている中で
全部を中央集権的に処理して回ると
大変なので
どこのホストであれ処理の異常を行って
集中的に発生する
ブロックチェーンの処理自体を外部化する
スピーカー 1
その外部化する先を
攻撃者の持っている
不正な出勤をさせるための
外部処理に向けて
そこを信頼させるというような
不正アクセスを行ったということになっています
なのでバイナンスの表面上から見ると
単にいろんな処理を他に分散しているだけの
一つのワーカーでしかない
処理先でしかないというところが
攻撃者の持っているワーカーに行って
そこから出勤が処理されたという流れになっているようです
私はブロックチェーンもあまり詳しくないので
この辺の説明は若干間違っているかもしれないですが
この問題が大きく取り上げられているのが
ブロックチェーン自体が
こういう不正な攻撃というのに
強いと言われていた最中で起きたものだったので
結構大きなニュースとして
取り上げられているというものになっています
以上です
スピーカー 2
ブロックチェーンの
システムというか
ロジック自体が既存したわけではなくて
ブロックチェーンを管理する
講座に不正アクセスがあって
銀行講座と一緒で
講座から抜き取られた感じ
スピーカー 1
ノリはそうだね
結果的にはそんな感じ
なるほどね
仕組みとしては
EIP-7702と言われている
去年の5月に導入されたばかりの
ブロックチェーンの仕組みの一つみたいです
スピーカー 2
それがちょっと悪用されちゃった
踏み台にされちゃったというか
スピーカー 1
踏み台にされちゃったという表現が正しそう
もちろん一番冒頭に話した
内部コンテナへの侵入経路
スピーカー 1
会社の内部のエンジニアに
侵入されたという経路さえなければ
もちろんこれも起きえなかった
ブロックチェーンの企画自体が悪いというよりは
マイナスチャーに侵入されたことが悪いというものではあるんですけれども
そんな事態になっても強そうと思われていた
ブロックチェーンだっただけに
この問題が重要視されているという感じですかね
スピーカー 2
多数決で決める都合上
過半数を握られなければ
なんとかなるだろうと思っていたけど
下回りというか入出金回り
換金回りと言った方がいいのか
送金回りと言った方がいいのか
送金だね今回は
スピーカー 2
送金回り
送金先の偽装登録という
特定手段に対して
対策を取られなかった
でもそれも
難しいね
口で言ってて思うけど別に
ブロックチェーンだからという
限らないから
スピーカー 1
そうだね
ブロックチェーン以外だったら防げた話は全くなくて
こんな事がされた時点で
ほぼほぼ防ぎようがなかったけど
それでも耐えてくれるのではという
ブロックチェーンの期待が勝手にあったというのが正しいかな
スピーカー 2
そこら辺も
現実が見えてきましたよという話かな
そう考えると
昔ながらの銀行とかってすごいね
昔ながらの銀行とかってすごいね
スピーカー 1
システム障害がやっぱり多かったりとか
パフォーマンスがなかなか出ないとか
運用費がバカみたいにでかいとか
いろいろ問題はあるけど
その分こういう侵入に強い仕組みとか
開発体制とか運用体制とか
いろいろ頑張ってたんだろうなと思いますね
さっきの話と一緒で
スピーカー 2
陶器的処理と一緒で
スピードを
性能を求めすぎると
こういう事もあるよねみたいな話
スピーカー 1
Cityは
今回多分銀行系の人から見たら
ありえないと思われるところでいくと
DevOpsエンジニアのノートPCに
何かマルウェーが侵入された後に
そのまま作業できている状態が意味不明だと
金融の界隈の人から見たら
スピーカー 2
アラート出してそこは強制シャットダウンすべきっていう
スピーカー 1
とか隔離されたりとか
そういうのに検出できてないのも意味不明だし
スピーカー 1
そのDevOpsエンジニアが普段使いしている
ノートPCで金融系の作業を直接できるようになっているのも
おかしいみたいな
ちゃんと隔離されたサーバールーム内のこのPCからでしか
作業できない事前の作業というか
スピーカー 1
リハーサルとかはもちろんできていいんだけど
いざ本当にやるかどうかはサーバールームのPCまで
実際に足運ばないとできないようになっているとか
多分金融系だとそこまでやっていると思うんだけど
今回の件だけ見るとそこまでやってなさそうじゃん
スピーカー 1
多分その辺が
金融界隈からしたら違和感だと思うな
スピーカー 2
確かに物理的な隔離的な
システムごとの隔離
使うサービスはやっぱり
厳選しないといけませんね
スピーカー 1
本当にそうだね
スピーカー 2
適当に信頼して使っちゃいけない
ちょっと正規末感をあふれる
使い方をしないといけなくなっちゃいましたね
スピーカー 1
そうだね
日本の企業が
ちょっと最近失いつつあるんですけど
取り戻したいとこですよね
信頼感で仕事をするみたいなのを
昔の日本を大事にしていたから
そこに戻りたい感じはするね
BROTLI脆弱性とオープンソース依存
スピーカー 1
セキュリティ関係は次最後なのでサクッといっちゃいます
これだけちょっと別の
サイトなんですけれども
http2シェルトはノードJSやパイソンに広がる
ブロトリー
ちょっと読み方分かってないです
スピーカー 1
BROTLI 脆弱性の影響と対策ということで
SQAT
ソフトウェアクオリティアナラシティーム
から上がっている記事です
内容として
ウェブサイトやAPIの安全性を
確認する際は外部からのリクエストだけでなく
アプリケーションを受信するレスポンスにも注意が必要です
http2シェルはGoogleの
ブロトリーデコーダに存在する脆弱性で
採掘された圧縮データの展開によって
情報漏洩や任意コードの実行につながる恐れがあります
ノード2シェルトも呼ばれるこの問題は
ノードJSに加えパイソン関連パッケージや
ブンヘンボーイなど幅広い製品に影響します
本記事では主な攻撃経路が影響を受ける製品
修正版と対策を解説します
これもいろいろ書いてあるんですけど長いのでざっくり言うと
またブラウザの例でいきますが
ブラウザでサーバーと通信するときに
扱うデータ量が多くなってきたら
圧縮したいわけですねデータを
圧縮するときのツールが
スピーカー 1
BROTLIというもののベースと
ZIPみたいなものなんですが
それを圧縮して回答するとき
それをデコーダーと呼びますけれども
回答するときの処理に脆弱性があって
任意な行動が実行できる可能性があるというものです
ここまで聞いてわかる通り
圧縮と展開なんてあらゆるサイトで
ありとあらゆるところで行われていて
どういう圧縮形態で送るかというのが
クライアントのヘッダーで
指定できてしまうというところが本当に恐ろしくて
サーバー側で
そういう圧縮手段を使ってなければいいという問題じゃないんです
送る側がヘッダーに
こんな圧縮手段で送ったよというのを圧縮ヘッダーにつけて
実際にそれで圧縮してしまえば
どういうクライアントからでも
誰でも攻撃に使えてしまうということで
ノードオートやPythonで
ウェブサーバーをホスティングしているありとあらゆる人が影響を受けるということで
問題になっているというものです
ただこれが個人的に
CVSS9.2で済んでいる理由はよく分かっていないです
スピーカー 1
内容的には9.9とかあってもいいんじゃないとか
個人的に思いますけど
特別な事情があるのかもしれませんが
これが9.2でとどまっている
スピーカー 1
攻撃の難しさとか
どういった時にはうまくできない
もしくはできる行動実行の範囲が限定的であるとか
そういったところがあるのかもしれないですけど
攻撃手法的には非常に簡単に
誰でもできる攻撃に見えるというものになっています
はい
スピーカー 2
なんかもうお腹いっぱいですね
スピーカー 1
そうですね今日はお腹いっぱいですね
もういいやという気持ちになるけど
スピーカー 1
もう好きにして
スピーカー 2
もはや言うことなくなってきましたけど
なんだろう
デジタルデトックスした方がいいんじゃないっていう
レベルですね
スピーカー 1
みんなもうインターネットから離れよう
スピーカー 2
そのスマホを窓から投げ捨てようって感じ
スピーカー 1
本当びっくりするわ
このニュース
スピーカー 2
あとはなんだろう
ウェブ系がやっぱり何でもできちゃう分
何でもされちゃうので
もはやオープンウェブではなくて
閉じたコミュニティのサービスを
ちまちま使い続けるとか
スピーカー 1
そうだね
スピーカー 2
かしらって感じですね
スピーカー 1
どうしたらいいんでしょうか
我々に残されている選択肢は非常に少ないです
昔からよく言われていたのは
スクリプト系言語は
ビルドとか何も経ずにそのまま実行してしまうので
攻撃されて危ないって話なんですけど
先ほど話したPHPはスクリプト系言語ではないので
どっちだって一緒じゃんって証明されてしまっていて
選択肢がないんですよね
スピーカー 2
そうですね
スピーカー 1
最近出てきた新しい言語だと
そういうこと少ないよって話はありますけど
歴史が浅いからってだけでしょっていうところなんで
スピーカー 1
本当に選択肢がない
スピーカー 2
使ったら使ったで
また自作性が出てくるし
みたいなところはあるので
開発者側は
スピーカー 2
何かあった時に
すぐ更新できるような
アプリケーションの作りにしとく
って感じかな
それはそうだと思う
スピーカー 1
これ前も話したことの繰り返しになっちゃうんですけど
オープンソースの
依存先が
疲れ切って対応しなくなった瞬間に
アップデートできないサーバーになるんですよね
スピーカー 1
最新バージョンについて来なくて
大体のものを探したりとか
そこを自前で実装しなきゃいけないみたいになるから
なのでオープンソースへの依存度が
高いものほどリスクが高くなっている
って感じだね今は
ノードJSとか
Pythonってオープンソースが多様にあるから
支えられているフレームワークとか
言語体系でもあるので
そんなことを言ったらノードとかPython使うのやめるわ
って話になる世界だから
マジでむずいんだけど
スピーカー 2
なんだろう
とは言いつつ
ある程度の規模の会社だったら自社開発なんてしてて
そこが踏み台にされた日には
もう終わりだよ
って感じだし
スピーカー 1
その場合は世の中で優先にしてくれないからね
その脆弱性を
空きっぱなしで攻撃者がひたすらただ乗りしている状態が
継続して誰も気づかないだけだから
もっと悪いんだよな状態としては
スピーカー 2
利用者的にはもっと悪いけど
どうしようもないね
スピーカー 1
皆さんやっぱりデジタルデトックスして
今すぐITエンジニアの仕事を辞めて
花屋さんとかになりましょう
スピーカー 2
スマホを捨てて山にこぼりましょうという感じでした
スピーカー 1
お腹いっぱいなのでもう騒乱もなく終わろうと思いますけど
いいですか?
ありがとうございました
00:00

コメント

スクロール