2026年5月、Metin氏が自身のブログで「Credit Cards Are Vulnerable To Brute Force Kind Attacks」という記事を公開し、Hacker Newsで話題になりました。著者は実際に不正利用の被害に遭っています。ECサイトに登録していたカードについて、PCI DSSに沿ってマスク表示された情報を出発点に、攻撃者が総当たりでカード情報を割り出していたと記事は説明しています。業界標準に従っていても、それだけで十分とは言えない。この記事が投げかけているのはその問題です。
発表内容
経緯はこうです。著者は利用限度額を設定し、3Dセキュアも有効にしたバーチャルカードを、有名なマーチャントにだけ登録して使っていました。ところが、昔パスワードを使い回していたECアカウントが乗っ取られます。攻撃者はそのアカウントで購入を試み、銀行の3Dセキュア画面が出たところで注文をキャンセルして離脱しました。
この数分で攻撃者が手にしたのは、次の情報だったと著者は分析しています。
- カードがまだ有効であること
- 銀行名（3Dセキュア画面から判明）
- マスクされたカード番号（先頭6桁と末尾4桁）
- 有効期限（月と年）
侵入から約6時間後、著者のもとに複数の別マーチャントから3Dセキュア認証のSMSが届きました。これらは失敗に終わっています。しかしその後、3Dセキュアを要求しないマーチャントで複数回の決済が通り、限度額いっぱいまで引き出されました。お金はマーケットの電子ウォレットに移され、そこから現金で引き出せる仕組みだったといいます。最終的にはチャージバックで返金されています。
核心は計算の部分です。16桁のうち先頭6桁と末尾4桁はわかっており、Luhnアルゴリズムのチェックディジットで候補はさらに絞られます。著者はこれで候補が約99,999通りになると述べています。そして問題を大きくしたのが、決済ゲートウェイのエラーの返し方でした。
My bank rejects the payments without these required values, but you know what, it also tells you which part of the data was faulty. （中略）It literally helps you to brute force it.
応答が「有効なカード番号ではない」「期限切れ」「CVVだけが違う」のようにどの項目が間違っているかを区別して返すため、カード番号とCVVを段階的に特定できてしまう、という指摘です。著者によれば、攻撃者は無関係なECアプリの会員登録フローからカード検証用のAPIを抜き出し、複数のエンドポイントを使って、全体で毎秒約6リクエスト（APIあたり約2リクエスト）という低いレートで試行していました。プロキシで送信元IPを変えていたこともあり、マーチャント側からは検知しにくかったとされています。
なぜ重要か
元記事によると、PCI DSS 4ではPANのBIN（先頭6桁）と末尾4桁、カード名義、サービスコード、有効期限の表示が認められています。表示が禁止されているのは、全トラックデータ、カード検証コード、PIN/PINブロックです。著者が強調しているのは、標準はあくまで「最低限の要件」なのに、認証を取るための実装がその最低限で止まってしまうという構造です。
被害を受けて著者はECサイトに報告しましたが、PCI DSS 3および4に合わせて意図的にそう設計しているとして、脆弱性とは認められなかったといいます。現金化に使われたマーチャントも、銀行に連絡するよう言うだけでした。また、3Dセキュアの対象外とされたマーチャントの一覧が存在することにも触れています。こうしたマーチャントは3Dセキュアなしで決済を受け付ける代わりに、チャージバックの責任を負う立場です。
影響はECに限りません。PCI DSSは紙のレシートに印字する情報も定めています。著者は、レシートを処分せずにそのまま捨てることでも同じリスクがあると注意を促しています。
現時点での未確定事項
- 関係した銀行、ECサイト、決済ゲートウェイの具体名は元記事に書かれていない
- 項目ごとに異なるエラーを返すゲートウェイがどれくらいあるのか、規模は示されていない
- カード番号の特定にかかった時間と、CVVの特定にかかった時間の内訳は明示されていない
- カードブランド側や業界団体がこの問題にどう対応するのかは書かれていない
- 公開されている本文は途中で終わっており、その後の経過の全容は確認できていない
まとめ
PCI DSSで表示が許された情報だけでも、カード番号の候補は約99,999通りまで絞り込める。
項目ごとに異なるエラー応答と、検知しにくい低レートの分散試行が組み合わさると、総当たりが現実に成立してしまう。
「標準に準拠しているから安全」とは限らないことを示した、実際の被害報告です。
実装家視点で言うと、この記事は決済まわりに限った話ではなく、「エラーメッセージを親切に書くと、攻撃者にとってのヒントになる」という古くからの教訓を思い出させます。カード登録フォームや検証APIを自分で作るなら、項目ごとの詳しい失敗理由をクライアントにそのまま返していないか確認すべきです。会員登録フローの検証エンドポイントが外部から抜き出されて使われる前提で、レート制限や異常検知も考えておく必要があります。利用者としては、パスワードの使い回しをやめることとレシートの扱いを見直すことが、まずできる対策です。
コメント