CosmicSting対策の方法〜CVE2024-34102による被害を防ぐには

2024年6月11日（太平洋標準時）にAdobeがリリースしたAdobe Commerce / Magento Open Source向けのセキュリティアップデートでは、CVE2024-34102という脆弱性が修正されました。
この脆弱性については、別記事で紹介している通り、セキュリティ企業SanSecが「CosmicSting」と命名してより詳細な情報提供を行っています。
今回はこの脆弱性に対する対策方法について解説していきたいと思います。

CosmicSting（CVE2024-34102）とは

CosmicStingとは、CVE2024-34102として採番されているAdobe Commerce / Magento Open Sourceの脆弱性です。
Adobe Security Bulletinでは、「Improper Restriction of XML External Entity Reference（不正な外部XMLエンティティ参照）」と記載があるもので、XMLファイル・データの取扱いに関する不具合が原因で発生するものです。
この脆弱性を悪用することで、Adobe Commerce / Magento Open Sourceの持つ環境固有の設定ファイルである「env.php」の中身を盗み出すことができ、このファイルに含まれるあらゆる情報が漏洩してしまうことになります。

env.phpが漏洩することによって起きる問題

env.phpには様々な情報が含まれますが、特に重要なものとしては以下のものがあります。

データベース接続情報
暗号化キー

特に今回CosmicStingで問題視されているのは後者の「暗号化キー」のほうです。
この情報が漏洩してしまうと、Adobe Commerce / Magento Open Sourceが用意している各種Web API（RESTやGraphQLなどすべて）のうち、管理者用のものを自由に利用できてしまいます。

すでにこの脆弱性を悪用されて、何らかの被害にあっているサイトが世界各地で報告されています。
早急な対処・対応が必要な事案ではありますが、CosmicStingの対応はかなり面倒であることも同時に判明しています。

対策方法

CosmicStingに対しては、すでに対策手順が公開されています。
当初はSanSecから暫定パッチがリリースされていましたが、現在はAdobe公式から緊急パッチがリリースされています。
基本的には公式のパッチを利用するようにしましょう。

Adobe公式パッチ

2024年6月27日時点でAdobeが緊急パッチをリリースしています。このパッチは

2.4.4系
2.4.5系
2.4.6系
2.4.7系（実際は2.4.7のみ）

に対して適用可能なものとなっています。
適用対象のバージョンを間違えないように注意してパッチのアーカイブをダウンロードし、適用ガイドに沿って適用作業を行いましょう。

まずはこれで1段階目の作業は完了です。

パッチ適用と合わせて行うと良いこと

パッチ適用に加えて、以下の対応を行うことでより安全性が高まります。

Content Security Policy（CSP）の有効化とホワイトリストの最新化
glibcに含まれるiconvライブラリとPHPの更新

合わせて実施されるとよいでしょう。
CMSページやブロックを改ざんされ、不正なスクリプトを埋め込まれたとしても、CSPが有効であればブラウザ側が読み込みを止めてくれるはずです。

適用後に実施する必要がある作業

さて、パッチ適用だけで今回の問題は終わりません。以下の作業が残っています。

暗号化キーの更新
暗号化済みデータの再暗号化
リサイズ後画像ディレクトリの更新

それなりに手間のかかる作業なので、どのようにすればよいか解説していきましょう。

暗号化キーの更新

まず最初は暗号化キーの更新です。
env.phpが丸ごと漏洩したと想定して対処を行う必要があります。この場合、暗号化キーを新しいものに置き換えないと、いつまで経ってもAPIの不正利用がなくなりません。
暗号化キーの更新機能自体は、Adobe Commerce / Magento Open Sourceの管理画面に標準で用意されています。

システム＞暗号化キー管理

にアクセスし、自動生成の選択か手動生成したキーの入力を行い、変更ボタンをクリックします。
適切に実装されているAdobe Commerce / Magento Open Sourceであれば、本来これだけで作業は終了です。

ただ・・・おそらく殆どの環境でこれだけでは済まないのが現状であるようです。

暗号化済みデータの再暗号化

暗号化キーの更新後には、暗号化キーを使用して暗号化されたパスワードや認証情報の更新が必要になります。
（暗号化に使用したキーが変わったのですから当然ですね）

この処理自体は、先程の「暗号化キーの更新」のあとに自動的に実施してくれます。
ただし対象が以下のデータに限定されています。

core_config_dataテーブルに記録されている情報で、backend_modelが\Magento\Config\Model\Config\Backend\Encryptedであるもの
sales_order_paymentテーブルのcc_number_enc列

それ以外のデータについては、自力で再暗号化を行う必要があります。
特に注意が必要なものとしては、

core_config_dataテーブルに記録されていて、暗号化もされているが、backend_modelが\Magento\Config\Model\Config\Backend\Encryptedでないもの
config.xmlとsystem.xmlのパスの定義が一致していないもの

です。
まずは検証用の環境を用意し、どのデータが正しく更新されないかを確認する必要があります。
更新されないものについては

実装や定義の修正を行い、正しく再暗号化が行われることを確認する
手作業でパスワードや認証情報をセットし直す

必要があります。
少なくとも顧客や管理者パスワードでこれらの作業は必要ありません。

リサイズ後画像ディレクトリの更新

もう1つ、サイトの規模によっては大変な作業があります。それは「リサイズ後画像を配置するディレクトリの更新」です。
CDN側でリサイズを行っている場合には不要な作業ですが、おそらく大半のAdobe Commerce / Magento Open Sourceベースの環境では必要な作業です。

標準の仕様としては、「Magentoのリサイズ後商品画像のパスはどのように決まるか」で触れた通り、以下のパラメータと暗号化キーを用いてハッシュ値を算出し、リサイズ後の画像を配置するディレクトリ名に使用しています。

画像の高さ
画像の幅
画像の品質
角度
アスペクト比の維持フラグ
枠線の有無
背景透明の有無
元サイズより大きくなるリサイズの可不可
背景色の指定

もとのパラメータが同じだったとしても、暗号化キーが変わってしまうので、生成されるハッシュ値も変わります。
そのため、暗号化キーを変更したあとは

画像の再リサイズを実施する
ディレクトリ名の変更を実施する

のいずれかが必要になります。
このハッシュ値はあらかじめ計算しておけるものなので、暗号化キーの更新前に新しいディレクトリ名のリストを用意しておくとよいでしょう。

作業を支援してくれるツール

Adobe Commerce / Magento Open Sourceの強みはオープンソースコミュニティです。
すでにコミュニティからこれらの作業を支援するためのツールがリリースされています。
今回はそのなかでも「genecommerce/module-encryption-key-manager」を紹介します。

このエクステンションには以下の機能が用意されています。

新しいキーの生成時に、古いJWT（Json Web Token）を自動で無効化する
リサイズ後画像ディレクトリを暗号化キー更新後でも変わらないように調整する
古い暗号化キーの無効化
標準の再暗号化処理で正しく処理されないデータの暗号化

上手く使えば暗号化キーの切り替えに伴う様々な作業負荷を軽減することができるでしょう。
ただし、Readmeにも書かれている通り「よく試験をしてから」本番投入するようにしてください。（弊社では責任を負いかねます）

まとめ

今回のまとめです。

CosmicSting（CVE2024-34102）を狙った攻撃がAdobe Commerce / Magento Open Source向けに多発していて、すでに被害が報告されている。
Adobe公式パッチの適用と、暗号化キーの更新が急務。
暗号化キーの更新に伴う諸作業が発生する可能性があるので、必ず検証環境でよく試験をしてから暗号化キーの切り替えを実施。
コミュニティが提供する支援ツールを利用することで、作業負荷とリスクの軽減が可能。

弊社ではこれらの作業に関しまして、テクニカルサポートを行う用意がございます。ご関心のある事業者様はお問合せフォームよりご連絡ください。
お使いの環境を調査したうえで、対処費用などの提案をいたします。