クレジットカード情報盗み出しの手口をまとめた

はじめに

先日の日記「ECサイトからクレジットカード情報を盗み出す新たな手口」は多くの方に読んでいただき、ありがとうございました。この記事では、「新たな手口」ではなく、従来からある手口についてまとめてみました。

1.SQLインジェクション

古典的な手法としてはSQLインジェクションがあります。下図のように、SQLインジェクション攻撃により、DBに保存されたクレジットカード情報を盗み出します。

攻撃が成立する条件は下記のとおりです。

• DBにクレジットカード情報が保存されている
• ウェブサイトにSQLインジェクション脆弱性がある

いずれも、現在の観点では論外の状況と言えますのでさすがに頻度は減っています。今年6月1日から施行されたカード情報非保持化により、今後はほとんど見られなくなると予想されます。過去の代表的な事例には以下があります。

• エクスコムグローバル、SQLインジェクションで約11万件のクレカ情報流出
• SQLインジェクション対策もれの責任を開発会社に問う判決

2.バックドアを設置し、ログファイル等からカード情報を盗む

次は、ログファイルなどにカード情報が記録されているウェブサイトに対して、攻撃者がバックドアプログラムを設置して、バックドア経由でログファイルをダウンロードする攻撃です。

攻撃が成立する条件は下記の通りです。

• ログファイル等にカード情報が保存されている
• ウェブサイトに外部から任意コード実行（RCE; Remote Code Execution）可能な脆弱性（OSコマンドインジェクション等）がある

ログファイルにカード情報を記録することがあるのかという疑問がありますが、例えば、決済代事業者から提供される決済APIをデバッグモードのまま動作させていると、カード番号等がログに記録され、それが漏洩するケースがあります。イプサ事件等が該当します。

【セキュリティ ニュース】イプサ、不正アクセスの調査結果を公表 - デバッグモードによりカード情報残存

また、OSコマンドインジェクションが今どきでもあるのかという疑問が生じますが、イプサ事件はSSI(Server Side Include)の不適切な利用が原因でしたし、またStruts2の脆弱性により複数のカード情報漏洩事件が発生しています。
この手口もカード情報非保持化により対策できるので、今後はほとんど見られなくなると予想されます。

3.バックドアを設置しDBからカード情報を盗む

2の変形ですが、バックドアからファイルを盗むのではなくDBアクセスして情報を盗む手口も見られます。下図はエイベックス・グループ・ホールディングス株式会社の「個人情報不正アクセスに関する調査報告書」P8から「図表2」を引用したものです。

バックドアプログラムを設置後に、「DB管理ソフトウェア」を設置され、バックドアにより窃取したDBのIDとパスワードを用いて外部からDBにアクセスしたとされます。
DB管理ソフトウェアとは、phpMyAdminのようなものを想像いただければよいと思いますが、現実に使われたものはAdminerではないかと推測します。AdminerはPHPファイル1個だけからなるDB管理ソフトウェアであり、設置が容易なので、元々汎用のソフトウェアではありますが、この種の攻撃には便利に使えてしまうという側面があります。

エイベックスの事件ではカード情報は窃取されていませんが、有名なサウンドハウス事件は実際にバックドアが設置され、そこからDBアクセスしてカード情報が盗まれたと報告されています。参照している報告書では、SQLインジェクション攻撃によりバックドアを作成したと推測しています。

攻撃が成立する条件は下記の通りです。

• DBにクレジットカード情報が保存されている
• ウェブサイトに外部から任意コード実行（RCE; Remote Code Execution）可能な脆弱性（OSコマンドインジェクション等）がある

この手口もカード情報非保持化により対策できるので、今後はほとんど見られなくなると予想されます。

4.カード情報入力フォームを改ざんして入力中のカード情報を盗む

最近の主流の方法と筆者が考えている方法です。カード情報入力フォームを改ざんして、カード情報を外部に流出させるというものです。下図は、攻撃者がECサイトを攻撃して、JavaScriptによる仕掛けを設置している様子です。

この「仕掛け」がある状態で利用者がクレジットカード情報をフォーム入力すると、確認ボタン押下などのタイミングで、入力フォーム上のデータを攻撃者が管理するサーバーに送信します。

この方法だと、「仕掛け」の設置後に入力されたカード情報のみが得られるわけですが、現実には100件もカード情報が得られれば、悪用には十分でしょう。
このパターンが日本で最初に報告されたのは、2013年3月に発生したJINSオンラインショップからのカード情報漏洩で、最大2,059件のカード情報が漏洩し、そのうち20件が悪用（未遂含む）されたとあります。

• 不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）
• よくあるご質問 | JINS - 眼鏡（メガネ・めがね）

この攻撃が成立する条件は以下のとおりです

• カード情報入力画面が改ざんできる脆弱性がある

現実には、RCE可能な脆弱性が多く用いられているようです。JINSオンラインショップ事件の場合は、Struts2のS2-016が悪用されました。
最近の主流の手口と筆者が推測する根拠としては以下のブログ記事を参照ください。

• 決済代行を使っていてもクレジットカード情報が漏洩するフォーム改ざんに注意

この手口は、カード情報非保持化の実装の中で、リダイレクト型では対策できる（決済代行事業者のサイトは安全と想定）ものの、JavaScript型（トークン決済）では対策できません。決済代行事業者の多くがJavaScript型決済をさかんに宣伝していることと、リダイレクト型がECサイト事業者に忌避される傾向があることから、今後もこの手口は残ると予想します。

5.カード情報入力フォームの画面遷移中に偽の入力フォームを挟む

最近、SOKAオンラインストア事件に初めて報告された手口です。概要の図のみ掲載しますが、詳しくは先日のブログ記事「ECサイトからクレジットカード情報を盗み出す新たな手口」を参照ください。

この手口はクレジットカード情報非保持では対策できないため、先のブログ記事でも言及したように、今後のカード情報窃取手口の主流となる可能性が高いと筆者は予想しています。

対策

いずれの手口も、ECサイトの脆弱性が原因ですので、まずはECサイトの脆弱性を解消することで対策になります。主なものには以下があります。

• ECサイトアプリケーションの脆弱性解消
• ECサイトアプリケーションが利用しているソフトウェア部品（フレームワーク等）の脆弱性解消
• ミドルウェアやOSの脆弱性解消

しかし、カスタムアプリケーションの脆弱性をゼロにすることも困難であるということと、Struts2の脆弱性にみるように脆弱性情報発表から攻撃開始に至る期間が極めて短いケースが増えていることから、以下に示す保険的な対策をあわせて推奨します。

• WAF(Web Application Firewall)の導入
• ファイルパーミッションとファイルオーナーの適切な設定
• 改ざん検知システムの導入

詳しくは、先日のブログ記事から「対策」の項をお読みください。

まとめ

クレジットカード情報の盗み出しの手口について紹介しました。
純粋なSQLインジェクション攻撃によるものが減少しつつある一方、SQLインジェクション以外の手口には、外部からのファイル設置やファイル改ざんが伴うことがわかります。まずは脆弱性解消が対策の基本ではありますが、ファイル改ざんを防ぐことでも被害の防止ないし緩和の効果が大きいことが理解いただけるかと思います。

PR

EGセキュアソリューションズはECサイトのセキュリティ強化のお手伝いをしています。お気軽にご相談ください。サービスメニューはこちら

ECサイトからクレジットカード情報を盗み出す新たな手口

エグゼクティブサマリ

聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。

はじめに

今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。

「ＳＯＫＡオンラインストア」の件
このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い
たしました。

https://www.trans-cosmos.co.jp/company/news/pdf/2018/180904.pdf より引用

今年の6月1日に改正割賦販売法が施行された後に起きたカード情報漏えい事件なので手口に注目しておりましたが、比較的詳細の手口が10月9日に公表されました。以下はトランスコスモス社からの続報です。

2. 調査結果と原因
調査報告書によると、聖教新聞社様より当該サイトの運営を委託されている弊社が契約しているサーバーに対して、7 月 30 日に不正ファイルを混入され、プログラムが改ざんされました。そのためお客様が商品を購入する際に、偽のカード決済画面に遷移する仕組みとなっており、カード情報を不正に取得された可能性があることが発覚しました。
また、偽のカード決済画面にてカード情報を入力して送信ボタンを押すとエラーが表示され、本来の当該サイトの画面に転送されるという非常に巧妙な仕組みになっておりました。併せて、データベースに不正にアクセスされ、個人情報を不正に取得された可能性があることも発覚しました。

https://www.trans-cosmos.co.jp/company/news/pdf/2018/181009.pdf より引用

これはとても興味深い手口です。以下、図を用いて、クレジットカード情報を抜き取る手口を説明します。

どのような手口か

筆者はSOKAオンラインストアの決済時の画面遷移は把握していないのですが、本年6月1日に改正割賦販売法が施行され、経産省の説明によると、『クレジット取引セキュリティ協議会の「実行計画」は、割賦販売法に規定するセキュリティ対策の実務上の指針と位置付けられて』いることから、最新の実行計画2018に示されている以下の二種類の方法のいずれかであったと推測します。

• リダイレクト（リンク）型
• JavaScript型 ※トークン型

以下に示す方法は上記のいずれにも攻撃可能ですが、ここでは、一般的にはより安全とされているリダイレクト型を想定して説明します。
下図は、リダイレクト型決済の画面遷移です。リダイレクト型の場合、カード情報の入力画面はECサイトにはなく、決済代行事業者が運営する画面に遷移した後にカード情報を入力することになります。リダイレクト型決済は、ECサイト側にカード情報入力画面がないことから、他の方法（トークン型等も含め）にくらべて相対的に安全であると考えられてきました。

次に、SOKAオンラインストアに対する攻撃の様子を下図に示します。リリースによると、「偽のカード決済画面に遷移する仕組み」を攻撃者に作れられたとしています。偽のカード決済画面がどのサイトにあったかは明らかにされていませんが、プログラムの改ざんが行われたとリリースされていることから、偽のカード決済画面をECサイト上に作成することも技術的には可能であったはずです。下図はその前提で作成したもので、偽のカード決済画面は赤い枠で示しています。

そして、決済画面への遷移を偽画面の方に誘導します。偽画面は攻撃者が作成したものなので、利用者が入力したカード情報は、図の右下に示すように、攻撃者の元に送信されます。
しかし、このままでは正常な決済が行われないため、利用者が不審に思い、問い合わせなどから比較的短期間に「仕掛け」が露呈するはずです。この攻撃が巧妙なのは、いったん「決済エラー」を表示した上で、正常系の決済画面に誘導するところです。利用者は2度カード情報を入力することにはなりますが、カード番号の入力は16桁数字を正確に入力する必要があり間違いが入りやすいので、それほどは不審に思われなかっただろうと推測されます。
この仕組みにより、リリースによると、「2018年7月30日～2018年8月24日に、カード情報を入力して商品をご注文されたお客様 2,481 名」のカード情報が漏洩した可能性があるとのことです。

従来の手口との比較

ECサイトからのカード情報漏洩として古典的なものには、SQLインジェクション攻撃によるものや、ログファイルからの窃取などがあります。これらは、カード情報をECサイト側で「非保持」とすることで防ぐことができます。
しかし、近年は（非保持化の要求以前から）カード情報をECサイト側で保存することが少なくなってきたので、入力フォームを改ざんしてユーザが入力したカード情報を盗むという方法が増えています。その詳細が公開されているわけではありませんが、筆者はJavaScriptを入力フォームに注入することで、カード情報を外部に送信しているのではないかと推測します。この手口は、日本では2013年3月のJINS事件以降発生しており、その状況をブログ記事にまとめたことがあります（下記）。

• 決済代行を使っていてもクレジットカード情報が漏洩するフォーム改ざんに注意

そして、この手口に対しては、前述の「非保持化」対応のうち、リダイレクト型であれば対策でき、JavaScript型では対応できないことから、「リダイレクト型の方が相対的に安全」という見方をしておりました。
しかしながら、リダイレクト型・JavaScript型の双方に対応した今回の攻撃により、結局経産省その他が推進している「非保持化」のソリューションは五十歩百歩の効果しかない状態になったなという感想を持っています。

対策

この手口に対するECサイト側の対策ですが、まずは基本的な以下の対策をとる必要があります。

• ウェブアプリケーションやソフトウェアライブラリ、プラットフォームの脆弱性対策（パッチ適用など）
• 管理者等のパスワードを強固にする（可能ならばインターネットからは管理者ログインできないよう設定する）

加えて、以下の対策を推奨します。

• Web Application Firewall(WAF)の導入
• ファイルパーミッションとファイルオーナーの適切な設定
• 改ざん検知システムの導入

最近のECサイトからのクレジットカード情報漏洩は、サイトの改ざんを伴うものが大半であることを考えると、ファイルパーミッションの設定と改ざん検知システムの導入は非常に効果があると考えられます。

とくに、ドキュメントルート下のディレクトリ（フォルダ）とファイルに対して、ウェブアプリケーションの権限で更新できないように設定すると、本稿で紹介した攻撃はできなくなります。この場合、単にファイルなどをリードオンリーに設定するだけでは不十分です。ウェブアプリケーションが動作するユーザがファイル等のオーナーになっている場合は、仮にリードオンリーの設定がされていても、攻撃者がまずchmodコマンドなどで書き込み権限を付与できるからです。
このため、ドキュメントルート下のファイル等は、ウェブアプリケーションが動作するユーザとは別のユーザをオーナーにしておくことが好ましいでしょう。一般的なレンタルサーバーではこの設定は難しい（ユーザを1種類しか使えない）ので、レンタルサーバーでECサイトを運営する場合は、脆弱性対処などに特に注意する必要があります。レンタルサーバーでは改ざん検知システムの導入は難しそうですが、最近はWAFが追加費用なしで使えるレンタルサーバーが増えているので、WAFをうまく利用できれば効果的だと考えます。

「非保持化」に対する思い

前述のように、今年の6月1日に改正割賦販売法が施行され、クレジットカード情報を扱うECサイト事業者にもカード情報保護が求められるようになりました。以下は割賦販売法の第三十五条の十六から括弧内の但し書きを抜いて引用したものです。

第三十五条の十六　クレジットカード番号等取扱業者は、経済産業省令で定める基準に従い、その取り扱うクレジットカード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必要な措置を講じなければならない。

割賦販売法 | e-gov より引用

そして、「必要な処置」のガイドラインになるのが、『クレジット取引セキュリティ協議会の「実行計画」』であり、経産省から以下のように「お墨付き」が与えられています。

クレジット取引セキュリティ協議会の「実行計画」は、割賦販売法に規定するセキュリティ対策の実務上の指針と位置付けられており、「実行計画」に掲げる措置又はそれと同等以上の措置を講じている場合には、セキュリティ対策に係る法的基準を満たしていると認められます。

クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2018（「実行計画2018」）を取りまとめました～国際水準のクレジットカード決済環境の整備を進めます～（METI/経済産業省） より引用

この「実行計画」の柱は「クレジットカード情報の非保持化」であり、実行計画2018には以下のような記述さえ見られます。

２．加盟店におけるカード情報の非保持化の推進について
本協議会は、加盟店におけるカード情報保護のための第一の対策として非保持化を基本とした取組を推進する。
非保持化は PCI DSS 準拠とイコールではないものの、カード情報保護という観点では同等の効果があるものと認められるため、実行計画においては、PCI DSS 準拠に並ぶ措置として整理する。

クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画－２０１８－【公表版】 より引用

そんなわけねーだろ、と心の中で突っ込んでいたわけですが、あまりに心配なので、ツテをたどって関係者に連絡を試みて不発に終ったりしておりました。なので、今回の事件を見て、「それ見たことか」という気持ちがないわけではありません。
しかしながら、同時に以下のような思いも芽生えました。ECサイト事業者の大半は中小零細企業であり、いきなりPCI DSS準拠を求めるような施策も現実的ではありません。非保持化という施策は、現状でなんとか実行可能で、対策としての効果も見込める（ただし十分とは言えない）ラインをひねり出したものかもしれません（私の妄想ですが）。前述の対策の際に、「レンタルサーバーは使うな」と書かなかったのですが、その理由は「零細なECサイト事業者がレンタルサーバーからVPSに移っても別の問題が生じるしな」という思いがあったからです。
いずれにせよ、今回のような手口が広がれば、今後の「実行計画」の改版の際には、より実効的な内容が求められることになると思います。

まとめ

SOKAオンラインストアからのクレジットカード情報漏洩手段について紹介しました。紹介した手口は、クレジットカード情報「非保持化」では対策できないものであり、今後のクレジットカード情報漏洩事件の主流となる可能性があります。事業者側の施策としては、基本をおろそかにしない一方で、サイト改ざんには特に重点的な施策が望ましいと考えます。具体的にはファイルパーミッションやファイルオーナーの設定、および改ざん検知システムの導入です。

【PR】

【10月24日（水）・11月7日（水）】
『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』基礎講座・応用講座　～徳丸本によるホワイトハッカー入門～ 申し込み受付中