Magento 2 のセキュリティ:ClickFix、PolyShell、CosmicSting の検出と遮断
Magento 2 と Adobe Commerce のストアは、自動化された攻撃キャンペーンの恒常的な標的です。新しい 2.4.x がリリースされるたびに複数のセキュリティパッチが提供され、攻撃者は数日のうちにそのパッチを解析して、未更新のストアに対する実用的なエクスプロイトを組み立てます。本記事では、ここ数か月に観測された主要な脅威、サーバー上に残る痕跡の見分け方、そして駆除と再発防止のための実務的な手順を説明します。
未更新の 2.4.x が最優先の標的となる理由
Adobe は Magento Open Source と Adobe Commerce のセキュリティ情報を定期的に公開し、各情報にはそのリリースで修正された脆弱性が列挙されます。パッチ公開から公開 PoC が出現するまでの時間は、いまや数週間ではなく数時間単位です。古いパッチレベルのまま運用しているストアは、事実上、公開済みで武器化された脆弱性を動かし続けていることになります。したがって最初の対策は常に同じです。コアを最新の安全なバージョンへ更新し、該当ブランチ向けに公開された公式パッチとホットフィックスをすべて適用してください。
ClickFix:偽の人間確認チェックボックス
ClickFix は Magento 自体を悪用するのではなく、訪問者が見慣れた画面に寄せる信頼を悪用するソーシャルエンジニアリング手法です。侵害されたストアでは、チェックアウト画面やランディングページが改変され、Cloudflare の『人間であることを確認してください』という偽のウィジェットが表示されます。訪問者が正規の確認ページと同じ感覚でチェックボックスをクリックすると、スクリプトが警告もなくクリップボードへ書き込まれます。この時点では害はなく、ページはそのまま正常に進んだように見えることもあります。
危険が生じるのは次の段階です。偽ページは、確認を完了するために macOS または Windows でターミナルを開き、コピーした内容を貼り付けるよう指示します。訪問者がこれに従うと、貼り付けられたコマンドが第二段階のペイロードをダウンロードしてクライアント端末上で実行します。利用者側のルールは単純かつ絶対です。Web ページに表示されたコマンドをターミナルに貼り付けてはいけません。管理者側のルールは、挿入されたスクリプトを特定して削除し、改変を許した侵入経路を塞ぐことです。
サーバー側の侵害:PolyShell、CosmicSting、env.php
Magento 2 のインシデント報告では、いくつかの脆弱性ファミリーが中心となっています。PolyShell は REST API 経由の無制限アップロードを悪用し、有効な画像であり同時に有効な PHP でもあるポリグロットファイルを設置します。CosmicSting はテンプレートエンジンを標的とし、未認証のリモートコード実行につながる可能性があります。StyleSmuggler と BlockStrap も、テンプレートインジェクションとフィルタ回避という同様のパターンを持ちます。最も深刻なケースでは、攻撃者が env.php を読み出して保存されている暗号鍵を抽出し、正規の管理者トークンを偽造します。これにより、脆弱な経路を塞いだ後もバックエンドへの持続的なアクセスが維持されます。
| 脆弱性 | 攻撃経路 | 影響 |
|---|---|---|
| PolyShell | REST API 経由の無制限アップロード | pub/media に保存されるポリグロット PHP ファイル |
| CosmicSting | テンプレートエンジンへのインジェクション | 未認証でのリモートコード実行 |
| StyleSmuggler | テンプレートおよびフィルタの回避 | コードインジェクションとデータ漏えい |
| BlockStrap | 入力検証の不備 | 管理画面へのアクセスと鍵の窃取 |
| ClickFix | フロントエンドへのスクリプト挿入 | 訪問者の端末で実行されるマルウェア |
app、vendor、cache に隠された難読化コードの調査
悪意あるコードはめったに目立ちません。攻撃者は標準の .phtml テンプレート、コアモジュール、そして cache や var ディレクトリに生成されたファイルの中に隠します。よく使われるキーワードでの単純なテキスト検索では何も見つからないことが多いのは、ペイロードが base64 文字列や複数の断片を連結して実行時に組み立てられるためです。最近の事例では、vendor フォルダ内の .phtml ファイルがわずかに改変され、悪意ある文字列が複数の変数に分割されていました。
同じバージョンのクリーンなコピーとインストール内容を比較してください。ファイル整合性チェックを使い、更新日時を確認し、公式パッケージと異なるファイルをすべて点検します。感染ファイルを見つけた場合は、ペイロードを削除するだけでは不十分です。公式アーカイブから元のバージョンを復元し、そのうえで書き込みを許した脆弱な経路を更新または遮断してください。
pub/media に PHP を置いてはいけない
media ディレクトリは画像、PDF、その他の静的アセットを保存するための場所です。pub/media 配下に .php、.php7、.phtml、.phar ファイルが存在する正当な理由はありません。それでも攻撃者は絶えずアップロードしており、格好の隠れ場所となるのが、アップロードされたオプションファイルが保存される pub/media/custom_options/ と pub/media/custom_options/quote/ です。これらのディレクトリを再帰的に走査し、見つかった実行可能ファイルをすべて削除し、アップロード設定が想定外の拡張子を拒否していることを確認してください。
Cloudflare、Nginx、Apache による境界での遮断
侵入経路が開いたままでは、サーバーを清掃しても十分ではありません。リクエストが Magento に到達する前に脆弱なパスを遮断します。Cloudflare では、/pub/media/custom_options/ や同様のディレクトリへのリクエストを拒否する WAF ルールを作成できます。また、media パス内の PHP ファイルに到達しようとするリクエストにチャレンジを課す方法もあります。オリジンサーバー側でも Nginx または Apache に同等のルールを追加し、CDN を迂回するトラフィックにも保護が効くようにしてください。
境界のルールは、あらかじめ把握しているリクエストしか止められないことを忘れないでください。パッチ適用、ファイル監視、定期的なコード監査と組み合わせて運用してください。
復旧チェックリスト
| 手順 | 対応 |
|---|---|
| 1 | Magento を最新の 2.4.x に更新し、すべてのセキュリティパッチを適用する |
| 2 | app、vendor、cache、var を走査して難読化または改変されたファイルを探す |
| 3 | 公式パッケージから元のファイルを復元する |
| 4 | pub/media から PHP、php7、phtml、phar ファイルをすべて削除する |
| 5 | 暗号化キーをローテーションし、既存の管理者セッションを無効化する |
| 6 | Cloudflare、Nginx、Apache で脆弱なパスをブロックする |
| 7 | すべてのキャッシュとコンパイル済みコードを削除して再生成する |
まとめ
Magento のセキュリティは一度きりの作業ではなく、継続的なサイクルです。迅速にパッチを適用し、ファイルの整合性を検証し、実行可能コードを media ディレクトリに入れず、不要なパスを遮断してください。ClickFix の挿入を疑った場合は、直ちに顧客へ警告してください。被害を最小化する最短の方法は、誰もターミナルに何も貼り付けないようにすることです。
一緒に取り組みましょう
さらに詳しい情報やプロジェクトのヘルプ、またはアイデアの構築が必要ですか?
簡単な質問でもフルプロジェクトでも、お気軽にどうぞ。お問い合わせいただき、あなたのアイデアを一緒に実現しましょう。
お問い合わせ →