3年間、何も起きなかった。だから気づかなかった

ECサイトが改ざんされ、カード情報が抜かれていた。

ところが、サイトは止まらない。

注文できる。決済できる。商品も届く。

運営会社から見れば、何も起きていないように見える。

そして数年後、警察から連絡が来る。

「あなたのサイトからカード情報が漏えいしている可能性があります」

そこで初めて侵害に気づく。

2024年に公表されたカード情報流出事案について、発覚経緯に「警察からの連絡・指摘」が明記されたものを追うと、13件あった。

年次レポートでも、2024年に公表されたカード情報流出37件のうち、警察の指摘による発覚は13件、35.1%とされている。

3件に1件以上だ。

警察から言われて初めて気づいた13サイト

確認できた事例を並べる。

この表には、警察から発覚したこと以上に気になる点がある。

侵害の始まりが、2021年2月から7月に集中している。

サッカー用品。

水産品。

醤油。

コーヒー。

楽譜。

家具。

ランドセル。

売っているものはまるで違う。

それなのに、カード情報の漏えいが始まった時期は、わずか半年ほどの範囲に固まっている。

年次レポートでも、警察指摘の13件はいずれも2021年に始まった改ざんで、EC-CUBEの脆弱性を突いた攻撃が多かったと分析されている。

全13件が同じCMS、同じ脆弱性だったとまでは言えない。

しかし、少なくとも一社だけを狙い撃ちした攻撃には見えない。

条件に合うサイトを探し、面で攻撃した痕跡に見える。

後で述べる「攻撃者は面で攻撃する」は抽象論ではない。

この表自体が、その非対称を示している。

そして約3年間、気づかなかった

さらに異様なのは、その長さだ。

多くのサイトで、2021年から2024年までカード情報の漏えいが続いている。

数週間でも数か月でもない。

約3年間だ。

その間もECサイトは営業していた。

注文は入る。

決済できる。

商品も届く。

障害が起きるわけでもない。

だから気づきにくい。

ランサムウェアなら分かりやすい。

サーバーが止まる。ファイルが暗号化される。業務ができなくなる。

しかし、カード情報を盗む攻撃者にとって、サイトを壊す理由はない。

むしろ正常に営業してもらった方が都合がいい。

購入者が増える。

入力される情報も増える。

長く居続けられる。

壊さないから、発覚しない。

ここが、この攻撃の厄介なところだ。

警察は、犯罪者側から逆にたどる

では、なぜ警察がEC事業者より先に気づくのか。

警察がすべてのECサイトを監視しているわけではない。

犯罪者側から逆方向にたどってくる。

盗まれたカード。

不正利用。

買い子。

攻撃者のサーバー。

不正プログラム。

そうした捜査の中から、

「このカード情報はどこから盗まれたのか」

を逆に調べる。

その先に、被害ECサイトが見つかる。

つまり、

EC事業者が攻撃者を見つけたのではない。 警察が犯罪者を追った結果、被害者であるECサイトが見つかった。

ここには怖い裏返しがある。

警察が犯罪者を見つけたから、被害サイトも見つかった。

では、

まだ犯罪者が見つかっていなければどうなるのか。

今も同じように侵害されながら、まだ外部から指摘されていないサイトが存在する可能性は否定できない。

「カード情報は一切保有していない。それでも漏れた」

この13件の中で、Kemari87 KISHISPOの公表は象徴的だ。

同社は、

顧客のクレジットカード情報は一切保有していない

と説明している。

それでも、カード情報が漏えいした可能性が生じた。

これは矛盾ではない。

攻撃者が狙うのは、カード番号を保存しているデータベースだけではないからだ。

狙うのは、カード番号が入力される瞬間でもある。

決済画面や、その手前のページを改ざんする。

不正なJavaScriptを仕込む。

あるいはサーバー側のPHPやテンプレートを書き換え、偽の入力画面を見せる。

利用者がカード番号を入力する。

正規の決済処理を妨げず、情報だけを別の場所へ送る。

すると決済は成功する。

商品も届く。

EC事業者のデータベースにはカード番号が残らない。

それでも、入力された瞬間に盗まれている。

だから、

「カード情報を保存していない」ことと、「カード情報を盗まれない」ことは同じではない。

「決済会社に任せています」も同じだ。

重要なのは、どの決済会社を使っているかだけではない。

利用者がカード番号を入力してから決済会社へ渡るまでに、自社が制御するページやコードがどこまで存在するか。

そこを見る必要がある。

では、どこを見ればいいのか

まずサーバーだ。

購入画面や決済画面に関係するHTML、JavaScript、PHP、テンプレート。

変わらないはずのものが変わったら分かるようにする。

ファイルのハッシュ。

更新日時。

デプロイ履歴。

管理者による変更履歴。

ここは基本になる。

ただし、サーバー上のファイルだけ見て終わってはいけない。

現在のECサイトは、サーバー上の静的ファイルだけで完成しているわけではない。

CMSのDB。

タグマネージャー。

外部JavaScript。

CDN。

広告。

アクセス解析。

チャット。

決済サービス。

いろいろな場所から部品を集め、最後に利用者のブラウザ上で一つのページになる。

CMSのDBにコードを埋め込まれれば、ファイルハッシュだけでは分からない。

タグマネージャーの設定を変更されても同じだ。

自社サーバーのHTMLが一文字も変わっていなくても、外部から読み込んでいるJavaScriptが改ざんされれば、利用者が受け取るページは変わる。

だから、

サーバーを見る。DBを見る。外部から読み込むコードを見る。そして最後に、利用者へ実際に届いている完成形を見る。

この順番になる。

外部JavaScriptは「どこから何を読むか」を管理する

購入画面で何本のJavaScriptが実行されているのか。

それぞれ誰が管理しているのか。

どのドメインから読み込んでいるのか。

不要なものはないか。

ここを一覧化する。

固定した外部JavaScriptなら、SRI（Subresource Integrity）を利用する方法もある。

期待するファイルのハッシュをintegrity属性で指定し、取得した内容が変わっていればブラウザに実行させない。

外部CDN上のファイルが想定外に書き換わった場合には有効だ。

ただし、SRIだけですべて解決するわけではない。

タグマネージャーのように内容が動的に変化するものには向かないし、自社側で正規に設定を書き換えられてしまえば別の問題になる。

だから最終的には、

何が読み込まれ、どこへ通信し、それが昨日からどう変わったか

を見る必要がある。

「昨日と違うもの」を検知する

監視する対象は、派手な障害だけではない。

購入画面で動くJavaScript。

外部通信先。

決済関連のHTML。

CSPなどのセキュリティヘッダー。

管理者アカウント。

ファイル更新。

Web、SSH、FTP、管理画面へのアクセス。

大事なのは、

「サイトが正常に動いているか」

ではなく、

「昨日と違うものが加わっていないか」

だ。

変わらないはずのものが変わった。

知らないJavaScriptが増えた。

知らないドメインへ通信するようになった。

誰も作業していない時間にファイルが書き換わった。

そこを拾う。

そして、もう一つの盲点がブラウザにある

ここでブラウザも考えなければならない。

ただし、二つに分ける必要がある。

一つはECサイトを運営する側のブラウザ。

もう一つは商品を購入する側のブラウザだ。

運営側は管理できる

CMS。

EC管理画面。

タグマネージャー。

クラウド管理画面。

決済管理画面。

ここへアクセスする端末については、少なくともブラウザのバージョンは管理したい。

自動更新を有効にする。

サポート対象外の古いバージョンを残さない。

拡張機能も自由に入れさせず、必要なものだけを許可する。

サーバーを最新にしても、管理者が古いブラウザを使い、出所の分からない拡張機能を大量に入れていれば、別の入口を作ることになる。

運営側のブラウザは、自社の管理対象だ。

ここは逃げられない。

購入者のブラウザは管理できない

難しいのはこちらだ。

購入者が何を使っているかは、EC事業者には管理できない。

最新のChromeかもしれない。

古いSafariかもしれない。

何年も更新されていないブラウザかもしれない。

どんな拡張機能が入っているかも分からない。

拡張機能は権限によっては、表示しているページの内容を読んだり、書き換えたりできる。

つまりサーバーから完全に正常なHTMLとJavaScriptを返していても、その後の利用者側の環境までEC事業者が完全に保証することはできない。

決済の最後の実行環境だけは、自社の管理境界の外にある。

しかしECには「カゴ落ち」がある

ならば、

「古いブラウザは全部切ればいい」

となる。

セキュリティだけ考えれば、安全側に倒せる。

しかしECには別の圧力がある。

カゴ落ちだ。

商品を選んだ。

カートに入れた。

住所も入力した。

最後に、

「お使いのブラウザでは購入できません」

と表示される。

その人がブラウザを更新して戻ってくる保証はない。

別の店へ行くかもしれない。

EC担当者にとって、これはセキュリティ設定ではない。

売上の問題だ。

だから、

「まだ表示できる」

「決済も動いている」

「なら通そう」

となりやすい。

セキュリティ担当は、古い環境を切りたい。

EC担当は、一人でも多く購入まで通したい。

どちらも間違ってはいない。

だからこそ、ここが盲点になる。

切る前に、まず知る

すべての古いブラウザを一律に遮断する必要はない。

まず測る。

購入者がどのブラウザを使っているのか。

どのバージョンが残っているのか。

古い環境が何％あるのか。

決済エラーやカゴ落ち率と関係しているのか。

どのバージョンまで切ると、どれだけ影響が出るのか。

その上で、極端に古いものだけを遮断する。

更新を促す。

重要な機能だけ制限する。

より安全な決済方式へ寄せる。

セキュリティとコンバージョンは、どちらか一方を諦める話ではない。測って境界を決める話だ。

攻撃者は面で攻撃する

13件の表に戻る。

会社の規模も違う。

売っているものも違う。

それでも、侵害開始時期は2021年2月から7月に集中している。

攻撃者から見れば、

「醤油屋」

「楽譜屋」

「ランドセル屋」

として見えていたとは限らない。

見ているのは、

特定のCMS。

特定のバージョン。

特定のプラグイン。

特定の脆弱性。

特定の設定。

条件に一致するインターネット上のサイト群だ。

攻撃者は面で探す。

一方、防御側は、

「うちは小さい会社だから」

「カード情報は保存していないから」

「決済会社に任せているから」

「サイトは普通に動いているから」

と、自分の一点だけを見てしまう。

ここに大きな非対称がある。

攻撃側はインターネット全体を見る。

防御側は自社だけを見る。

3年間、何も起きなかった

13件を並べて改めて感じる。

これは派手な攻撃ではない。

3年間、サイトは動いた。

注文も入った。

決済もできた。

商品も届いた。

だから気づかなかった。

そして最後は、

警察から言われて初めて気づいた。

サイトが止まっていないことは、安全の証明ではない。

カード番号を保存していないことも、安全の証明ではない。

決済会社に任せていることも、それだけでは安全の証明にならない。

見るべきなのは、

「サイトが動いているか」

だけではない。

昨日と違うものが、どこかに加わっていないか。

サーバー。

DB。

外部JavaScript。

タグ。

通信先。

管理端末。

ブラウザ。

そして利用者に最後に届く画面。

攻撃者は面で探している。

防御側も、自分の一点だけを見て安心するところから変わらなければならない。

何も起きていない。

この種の攻撃では、それこそが一番怖い。