決済代行会社のメタップスペイメント社から、ここ数年で最大のカード漏洩（国内）が発表されました。発表された内容を読むと下記の記事にある様に”やられ放題”と書かれても仕方が無い、基本セキュリティ対策の不備が含まれています。この不正アクセス事件について専門家の立場で考えてみます。
www.itmedia.co.jp
公式発表
・不正アクセスによる情報流出に関するご報告とお詫び（2/28）[魚拓] ※第2報
・不正アクセスに関するご報告とお詫び（1/25）[魚拓] ※第1報
２. 不正アクセスおよび流出情報について
今回は決済情報等が格納されている3つのデータベースに対し不正アクセスがあり、それぞれから情報が流出いたしました。
① トークン方式クレジットカード決済情報データベース
2021年10月14日から2022年1月25日に利用されたクレジットカード番号数（括弧内は流出情報）：460,395件（カード番号、有効期限、セキュリティコード）
第三者調査において、本データベースから断続的に情報の流出があったことは確認されていますが、弊社にて実際に流出した情報を特定することはできず、また、第三者調査機関からも特定は困難との見解を得たため、流出した可能性としては最大で上記全件数となります。
② 決済情報データベース
2021年5月6日から2022年1月25日に利用されたお客様のデータ保有件数
クレジットカード決済 (※1) 2,415,750件（カード番号、有効期限）(※2)
コンビニ決済 824,483件（氏名、電話番号、メールアドレス)
ペイジー決済 170,435件（氏名、郵便番号、住所、電話番号）
電子マネー決済 980,490件（メールアドレス）
(※1) 2,415,750件には上記①の460,395件を含みます。
(※2) 保有データの一部に氏名・電話番号・住所・メールアドレスが含まれる場合があります。
弊社における調査の結果、上記②の中から判明した情報流出件数は以下の通りです。(※3)
クレジットカード決済1 434件（カード番号、有効期限）(※2)
コンビニ決済 109件（氏名、電話番号、メールアドレス）
ペイジー決済 17件（氏名、郵便番号、住所、電話番号）
電子マネー決済 33件（メールアドレス）
合計 593件
(※3) 調査方法
不正ファイルへのアクセスログ日時を抽出
抽出したログに該当するパケットデータを取得
取得したパケットデータの要求、応答を確認
応答値から窃取されたデータより件数を確認
③ 加盟店情報データベース
38件（加盟店名、加盟店コード）
（第2報より引用）
キタきつねの所感
※お断り：私自身はPCI DSSに関する専門家（有資格者）の1人ですが、メタップスペイメント社の審査やフォレンジック調査、コンサル業務等には一切携わっておりません。本記事に記載の内容は、メタップスペイメント社が公開した情報や関連報道等を元に、第三者の立場として推測した内容となります。今後のマスコミ等の報道内容や、メタップスペイメント社が4月以降に発表する可能性がある最終報告内容と合致しない可能性もありますので、その旨ご了承下さい。
カード関係者が最も恐れる事態の１つが、カード情報を大量に取り扱うサービスプロバイダーからの情報漏えいであり、サービスプロバイダーはPCI DSS準拠（オンサイト審査）が必須となっています。
不正アクセス被害を受けたメタップスペイメント社もISMSやPCI DSS、Ｐマークといった外部審査を受け、セキュリティ体制に関して第三者のお墨付きを得ています。メタップスペイメント社のHPには、以下の様な記載があります。
普通に考えれば、第三者の不正アクセスに関して十分な耐性があったはずですが、非常に残念な事に「SQLインジェクション」の脆弱性が突かれた事も発表しています。
複数回の攻撃、及び攻撃が組み合わされた（※高度な攻撃・・とまでは言えない気がします）事が第2報では書かれていますが、PCI DSSの視点でこの事件を考えていきます。
まず漏えいしたカード情報という観点では、３つのデータベースから漏えいがあったと発表されていますが、個人情報漏えいの観点はさておき、PCI DSSの保護対象であるカード情報だけに絞って考えると、問題となるのは①と②です。
① トークン方式クレジットカード決済情報データベース（カード番号、有効期限、セキュリティコード）
② 決済情報データベース（カード番号、有効期限）
③ 加盟店情報データベース
①が約46万件、①が約240万件ですが詳細調査の結果、漏えいした可能性があると判断されたのが434件となります。両カード（①②）データ共に、カード情報の悪用の可能性がありますが、②に関しては①に比べて悪用の可能性は少ない（情報が足りない）と言えます。①との最大の違いは「セキュリティコード」があるか無いかという点だけなのですが、①にセキュリティコードがある部分については、PCI DSS基準違反だった可能性を強く感じます。
PCI DSSv4が3月末（~4月）にリリースされますが、現行バージョンのv3.2.1ではカード情報の取扱い（保存可否）について、以下の様な記載がされています。
記載が少し分かりにくいかと思いますが、機密認証データの１つであるセキュリティコード（CAV2/CVC2/CVV2/CID ※注：カードブランドによってセキュリティコードの呼び方が違う）は、カード決済承認後には保存（保有）してはいけない、というのが原則ルールです。
この規定はPCI DSS要件3.2に記載があり、まず原則セキュリティコードが保存不可である事と、例外条件が定められている事が分かります。
3.2 承認後に機密認証データを保存しない（暗号化されている場合でも）。機密認証データを受け取った場合、認証プロセスが完了し次第すべてのデータを復元不可能にする。
以下の場合に、イシュアとイシュイングサービスをサポートする企業は機密認証データを保存することが可能である。
・業務上の正当な理由がある
・ データが安全に保存されている
メタップスペイメント社は、カード情報非保持サービスである「決済トークン」を提供していた決済代行会社ですので、当然の事ながら上記例外条件の「イシュイングサービスをサポートする企業」だったかと思います。
しかし、メタップスペイメント社は「業務上の正当な理由」を開示していませんので、この保存行為が妥当だったのかどうかは外部からは知る由もありませんが、何らかの正当な理由があり、機密認証データ（セキュリティコード）を保存していた可能性が無いとは言い切れません。
尚、同様に疑問に思ったのか、セキュリティコードに関してITmediaさんが突っ込んで聞いており、ここでも”正当な理由”の説明はされていませんが、機密認証データを一定期間保存していたとのコメントがメタップスペイメント側から出ています。
www.itmedia.co.jp
メタップスペイメントでは「承認処理の際、データベースにセキュリティコードを短期間保持していた」という。攻撃者は、システム侵入時の直前に決済で使われた暗号化されたセキュリティコードを取得できる状態にあったとみられる。メタップスペイメントによれば、保持期間は非公開だが「長期間保存していた事実はない」としている。
（ITmedia記事より引用）
※この回答部分だけで判断は出来ませんが、「正当な理由は無かった」様な内容に思えます
しかし、仮に正当な理由があったとしても、機密認証データ（≒セキュリティコード）が「漏えいした」事によって、図らずも例外条件の2つ目が満たされていなかった事が分かります。
・ データが安全に保存されている
要件3.2.1のテスト手順側には、正当な理由があって機密認証データを保存している場合のPCI DSS審査でのテスト（確認事項）について、以下の様に書かれています。
3.2.b
イシュアまたはイシュイングサービスをサポートし、機密認証データを保存する会社について、データストアとシステム構成を調べて、機密認証データがセキュアに保存されていることを確認する。
PCI DSSの規定で機密認証情報について、ここまで厳しい書き方がされているのは、当然の事ながら、これらのデータが漏洩するとカード不正利用に直接的につながりやすいからであって、そのため、保存するにしても他の情報以上に”安全に”保管する事が求められています。
上記の『セキュア（安全）に』という部分は、いくつかの実装方法があるかと思いますが、最も代表的な実装としては、データベースに格納されたセキュリティコードの入ったレコード（又はDB自体）を暗号化する事だと思います。
暗号方式が古すぎました・・・や、暗号（復号）鍵が「その辺に落ちていました・・・」といった実装ミスを犯さなければ、仮にセキュリティコードを含むカード情報が漏洩してしまったとしても、暗号化されたデータが漏洩しただけという状態になります。
こうした場合、他に存在した脆弱性、あるいはゼロディ攻撃があったのか・・といったフォレンジック調査の結果次第ではありますが、暗号化によって、公式発表においては、”カード情報が漏えいした可能性はありますが、暗号化されていたので不正利用される可能性は極めて低いものと判断しています”といった補記がされる事が一般的です。
今回の発表では、補記も無く「流出した」と断定されていますので、当該データベースに平文に近い状態でセキュリティコードが保存されていたと推測されます。
決済情報等が格納されているデータベースにまで達し、個人情報を含む情報が外部に流出したことが判明いたしました。
（第2報より引用）
セキュリティコードがどの程度の期間保存されていたのかについて、メタップスペイメント社はITmediaの取材に対して「非公開」とし、「長期間保存していた事実はない」と回答していますが、仮にセキュリティコード保存期間が1日だと想定した場合、攻撃者は毎日カード情報を窃取する攻撃をする必要が出てきます。
そう考えると、メタップスペイメント社は、結構長くセキュリティコードを保管していた可能性が高いかと思います。仮にこの推測が合っているとしたら、こうした危ない状態（リスク）をカード情報を取扱うプロである決済代行会社のメタップスペイメント自身が、そして、PCI DSS審査会社（QSAC）も気づけなかったのが、残念な所です。
※秘密裏にカード情報を窃取してバックログに書き込んで、それをまとめて取得するという攻撃も考えられなくもありませんが、第2報では「決済情報等が格納されているデータベースにまで達し・・・」との表現がさているのと、原因の１つが「SQLインジェクション」と公表されています。例えば1か月という単位でセキュリティコードが（平文で）データベースに存在しないと、頻繁にSQLインジェクション攻撃をしていた事になってしまい、流石にメタップスペイメント側も”攻撃検知”出来たはずなので、保存期間は数日という単位では無く、数十日（1か月程度）はあったと考えるのが妥当かと思います。
※セキュリティコードの保存期間が例えば1日で、（SQLインジェクション）攻撃が1週間毎だったとした場合、第2報での①トークンDBからの情報流出期間が（2021年10月14日から2022年1月25日）と継続期間として書く事ができなくなり、10月14日、10月21日、10月28日・・・と細切れに流出期間を発表するのが本来正しいはずです。
※長くなりそうなので何回かに分けて投稿する予定です
※関連記事
メタップスペイメントへの不正アクセス事件を考えてみた その１（セキュリティコード）
メタップスペイメントへの不正アクセス事件を考えてみた その２（侵害検知）
【限定】メタップスペイメントへの不正アクセス事件を考えてみた その３（ASVスキャン）
【限定】メタップスペイメントへの不正アクセス事件を考えてみた その４（時系列）
メタップスペイメントへの不正アクセス事件を考えてみた その５（インシデント対応）
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
