サイバーセキュリティ

PHP2Shellの悪用で、2000ドル相当のビットコインを餌にしたサーバーが19時間で陥落

Adrian Kessler
Googleで追加する

パッチ未適用のPHPを動かすサーバーが、ビットコインウォレットの秘密鍵を餌として置いたままオンラインにされていたが、持ちこたえたのは1日にも満たなかった。KillaBoi(キラボーイ)というハンドルネームの研究者が、ウェブの大半を支える言語に見つかった2件の重大な脆弱性、PHP2Shellを通じて侵入し、鍵を抜き出した。同じ週末には、Perplexityのセキュリティ責任者が運営するハニーポットでも、攻撃者が実在のサーバーに同じ手口を使う様子が記録された。これにより、脆弱性の悪用は難しすぎて誰にも使えないという、安心感のある見方は崩れた。

これは、ウェブサイトを運営する人にも、そこにデータを置いている人にも関わる問題だ。PHPはWordPress、Drupal、Joomlaをはじめ、共有ホスティングの大半を支えている。今回の脆弱性を悪用されると、アカウントを持たない第三者がサーバー上でコマンドを実行できる可能性がある。修正プログラムが公開されて以降、対応を待つ根拠として主に挙げられてきたのは、公に確認された攻撃がいずれも失敗していたことだった。今回の2つの結果は、その根拠を覆すものだ。

「Steal My Bitcoin」と名付けられたこの企画は、専用ウェブサイトで公開され、フォーラムへの投稿で告知された。cloudlandsdev名義で投稿した企画者は、「PHPのこのRCEを実際に使う方法を誰かが見つけたのか気になっていたので、これを作りました。ここ数日はパニック状態でした。楽しんでください!」と書き込んだ。賞金は当初およそ502ドル相当だったが、寄付によって0.02511679 BTCまで増加。Tom’s Hardwareによると、開始から約19時間後に獲得者が現れた時点で、価値は2,021.22ドルだった。挑戦者が殺到してサーバーには大きな負荷がかかり、ストレージ容量にも限りがあったため、ログをすべて保存できなかった。

その後、キラボーイはGitHubで概念実証コードを公開した。WordPress向けセキュリティ企業Wordfenceの創設者、マーク・マウンダー(Mark Maunder)は、この解説を「#php2shellの悪用がどれほど難しいかについて、これ以上ないほど優れた説明」と評し、攻撃にどれだけ精密な作業が必要だったかを指摘した。だが、難しいからといって時間がかかるわけではなかった。

さらに懸念される結果は、ゲームの外で確認された。Perplexityで検知・対応を率いるアデル・カリミ(Adel Karimi)は、同社のハニーポットが、PHP 8.4.26を動かすApacheサーバーに対するリモートコード実行を確認したと明らかにした。BleepingComputerの報道によると、カリミは「これは、クラッシュ後に不審なプロセスが起きたというだけではなく、利用可能なメモリ情報の漏えいを伴うRCEが確認されたものだ」と記している。成功した攻撃に関する主張を追っていたExpelの脅威研究者、マーカス・ハッチンズ(Marcus Hutchins)は、「これまでに見た、実際の環境におけるphp2shell悪用の確認事例の中で、群を抜いて質が高い」と述べた。それまでは、Cloudflare、watchTowr、Patchstackなどのセキュリティ企業が記録していたのは失敗した試みだけで、Amazonの脅威インテリジェンスチームはパッチ公開の4日前からスキャンの開始を確認していた。

どちらの結果も、パッチ未適用のサーバーがすべて明日にも侵入されるという意味ではない。キラボーイが回収した鍵は、サイトで告知されていたウォレットアドレスと一致しなかった。Cointelegraphによると、主催者は設定ミスだったと説明し、資金を移すと述べた。また、セキュリティサイトCyberpressは、公開された証拠が示しているのは鍵の取得であり、賞金の窃取ではないと指摘している。公開されたエクスプロイトも、特定のPHPビルドに合わせて調整されており、同じバージョンの別ビルドでは動作しないため、ワンクリックで使えるツールではない。もはや通用しないのは、誰も成功させていないという弁明だ。

影響は世界規模に及ぶ。Cointelegraphによると、オランダ、オーストラリア、日本、フィンランドの政府機関は、パッチの準備中に重要なウェブサイトをオフラインにした。セキュリティ企業MalloryがShodanを使って調べたところ、公式修正の提供が終了したPHPバージョンを公開している、インターネット接続可能なホストは約88万4,000台に上った。Notebookcheckによると、これはバージョンを公開している約150万台のうち59%にあたる。ただし、これはバナー情報に基づく台数であり、被害が確認されたホスト数ではない。Linuxディストリビューションでは、バージョン番号を変えずに古いパッケージへパッチを適用することがよくあるためだ。

サイト運営者が取るべき対策に変わりはない。修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35で、いずれもCVE-2026-109618とCVE-2026-109619への対応として10月21日に公開された。どちらの脆弱性も、10点満点中9.2と評価されている。共有ホスティングの場合、更新を行うのはWordPressやプラグインではなくホスティング事業者だ。事業者に確認すべきなのは、自分のサイトがどのPHPビルドで動いているか、そしていつパッチが適用されたかである。米国のサイバーセキュリティ機関CISAは、更新できない組織やPHP 8.1以前を使い続けている組織に対し、更新できるまで該当システムをオフラインにするよう求めている。

次の問題は、すでに浮上している。金曜日、PHPチームは3件目のリモートコード実行脆弱性、CVE-2026-115560への回避策を公開した。まだパッチはなく、「設定とアプリケーションコードが通常とは異なる組み合わせ」のシステムだけに影響する。修正プログラムが公開されるまでは、PHP開発者はsession.upload_progress設定を無効にするよう勧めている。PHP2Shellのパッチ公開前にも推奨されたのと同じ対策だ。PHP 8.2のセキュリティサポートは2026年12月31日に終了する。8.1から移行していないサーバーは、すでにサポート終了を迎えている。

タグ: , , , , ,

Googleで追加する

ディスカッション

0件のコメントがあります。