クレジットカードはブルートフォース型攻撃に脆弱
(metin.nextc.org)- PCI DSS はカードデータの保存・表示を制限するが、BIN と下4桁、有効期限のような許可された情報だけでも、別の加盟店で追加の決済試行を続けられる
- 侵害されたアカウントで、攻撃者は銀行の 3D Secure ページを通じてカードの利用可否、銀行名、マスクされたカード番号、完全な有効期限を取得し、約6時間後に複数の加盟店で認証試行を発生させた
- 決済カード番号(PAN) は IIN、アカウント識別子、Luhn チェックディジットの構造を持ち、決済ゲートウェイの応答がどの値が間違っているかを区別してくれると、PAN・有効期限・CVV の推測が容易になる
- 実際のテスト速度は毎秒6回、API ごとに約毎秒2回程度で、プロキシで IP が変わり、カード番号も継続的に変わるため、加盟店側では ブルートフォース の検知が難しい
- 攻撃者は 3D Secure 例外 加盟店を利用して引き下げられていた限度額の全額を電子ウォレットに移し、チャージバックで資金は返還されたが、銀行の CVC2 レート制限は数分のブロックにとどまっていた
PCI DSS が防ぐものと残すもの
- PCI DSS は、クレジットカードのような機密性の高い銀行データを扱う際に必要な最小限のセキュリティ対策を定義する業界標準であり、アカウントが侵害されたりカードデータが第三者に渡ったりしても、全情報が露出しないよう保存と表示を制限する
- PCI DSS 4 の基準で画面や領収書に表示可能な情報は、マスクされた PAN、カード名義人名、サービスコード、有効期限であり、PAN は BIN と下4桁まで表示できる
- 表示してはならない情報は、完全なトラックデータ、カード検証コード、PIN/PIN ブロックに制限される
- EC サイトと紙の領収書の両方が同じ問題の影響を受けうるうえ、アカウント侵害だけでなく、破棄されていない領収書からも一部のカード情報が露出しうる
事故の流れ
- 被害者は利用限度額のある バーチャルクレジットカード を使っており、二要素認証である 3D Secure を有効化し、よく知られた加盟店でのみカードを保存して使用していた
- かなり前に作成したアカウントが侵害された後、カードが保存された Web サイトから購入試行の SMS が届き、すぐにログインしてパスワードを変更し、購入の有無を確認したうえで、バーチャルカードの限度額を大きく引き下げた
- カードを完全に無効化しなかった理由は、カードの全情報までは侵害されていないと判断したためだった
- 最初の侵害から約6時間後、使用していない複数の加盟店から 3D Secure SMS の試行が3〜4件発生し、すべて失敗したが、その後の攻撃手法を把握するうえで重要な手がかりになった
- 数分後に銀行へ電話してカードを完全に無効化している間に、攻撃者は 3D Secure のない別の加盟店を利用し、引き下げられていた限度額の全額を複数回の決済で引き出した
- 資金は現金引き出しが可能なマーケットの電子ウォレットへ移され、被害者はチャージバックを申請した後、銀行から資金の返還を受けた
攻撃者が得た情報
- 攻撃者は侵害したアカウントで決済を試み、銀行の 3D Secure ページを見た後、注文をキャンセルして離脱した
- この過程で、カードがまだ利用可能であること、銀行名、マスクされたカード番号、完全な有効期限を得た
- 一般にカード決済を正常に完了するには、PAN 16桁すべて、有効期限、CVC2 番号、3D Secure に使われる携帯電話などの情報が必要だと考えられる
- 実際の攻撃では、一部の情報だけでも別の加盟店で追加の試行を続けることができた
PAN の構造と推測可能性
- 決済カード番号(PAN) は、クレジットカード、デビットカード、ストアドバリューカード、ギフトカードなどに使われるカード識別子である
- PAN は ISO/IEC 7812 に基づく共通の番号体系を持ち、内部構造は次のとおり
- 6桁または8桁の Issuer Identification Number(IIN)
- 最大12桁の個別アカウント識別子
- Luhn アルゴリズムで計算される1桁のチェックディジット
- 被害者の銀行はカード番号だけでは決済を許可せず、PAN、有効期限、CVV をあわせて要求していた
- 一部の銀行と決済ゲートウェイはカード番号だけでも決済を処理でき、これは被害者が特に信じがたいと感じた部分だった
決済ゲートウェイの応答が作ったブルートフォース条件
- 被害者の銀行は必要な値がない、または誤っている決済を拒否したが、どの部分が間違っているかを応答コードで知らせていた
- 応答例は次のとおり
- 「有効なクレジットカードではない」
- 「カードの有効期限切れ」
- 「他の情報はすべて正しいが CVV が誤っている」
- このような応答は、攻撃者がカード番号、有効期限、CVV のどの値が正しいか誤っているかを判別するのに使える
- 実際の攻撃者は毎秒6回、API ごとに約毎秒2回の水準でテストしていた
- この速度は加盟店側で検知しにくい。プロキシによって送信元 IP が変わり、ブルートフォースの性質上カード番号も同一ではなく、リクエスト頻度も非常に低いためである
3D Secure 例外加盟店の役割
- 銀行には 3D Secure 例外 加盟店の一覧があり、これらの加盟店は銀行が信頼する相手とみなされ、3D Secure なしで決済やサブスクリプションを受け付けられる
- こうした加盟店はチャージバックが発生した場合に責任を負う
- 攻撃者は 3D Secure のない加盟店を利用して、カード限度額内の金額を電子ウォレットへ移した
その後の対応と残る問題
- チャージバックにより資金はすみやかに返還された
- カード決済を現金化する仕組みが不正引き出しに使われた点を該当加盟店に伝えたが、加盟店は銀行に問い合わせるよう回答した
- EC サイトには、有効期限とあわせてカード番号10桁を露出すると攻撃が容易になると伝えたが、そのサイトはこれを脆弱性と認めず、PCI DSS 3 と 4 の標準に合わせて意図的に設計したものだと回答した
- 決済 API を作っている人や決済業界で働く人々は驚かず、一部の加盟店は有効期限なしでも取引できると答えた
- 事件後、クレジットカード決済を現金化していた当事者は、もはや 3D Secure なしではこれを処理しなくなった
- 被害者の銀行は現在も CVC2 ブルートフォースに対して比較的緩いレート制限を設けており、制限に達すると当該カードを数分程度一時的に停止する水準にとどまっている
1件のコメント
Hacker News の意見
関連事例を見ると、元の投稿者は見当違いの原因を追っていた可能性もある。最近、自分のクレジットカードに FB/Meta 関連の少額な未承認決済が載り、誰かがカードが有効かどうか試していたようだった
カード会社に電話して決済を取り消し、カードを解約したあと、新しいカード番号・新しい有効期限・新しい CVV のカードを受け取ったが、一度も使っていない新しいカードでも再び FB/Meta の不正決済が始まった。原因はデジタルウォレットで、カードを解約してもカード番号などがデジタルウォレット経由で引き継がれることがあった
再度カード会社に電話してデジタルウォレットをすべて無効化してほしいと頼んだところ、99件もあり、オンラインでは処理できずコールセンター担当者と話す必要があった。継続課金がすべて初期化されるという説明を受けたうえで、カードとすべてのデジタルウォレットを解約してほしいと頼まなければならず、20分も待たされた。カードを解約するということが思っているのとは違う場合があり、継続課金はカード会社にとって非常に収益性が高いため、解約は大きな売上損失につながるようだ
Stripe ブログ: https://stripe.com/resources/more/what-is-a-card-account-upd...
もし別の場所から漏れていたなら、わざわざ無関係な EC アカウントにログインしようとはしなかったはずだ
この記事は最も重要な部分を扱っていない。銀行が自分の口座から加盟店へ資金を移すことに同意する清算は、承認とは完全に別物だ
承認とは、現代的な EMV、つまり「チップと PIN」認証、オンラインでの CVV、銀行が自分自身を詐欺から守り、副次的に加盟店も守るための各種仕組みを指す
ネットワークは Amazon が「ここにカード番号があり、この人が私たちに400ドル払うと言っている」と言うのを受け入れられる。それは単に清算であり、請求書に載る。高度な暗号化も、4桁の PIN 程度の仕組みも、母親の旧姓を覚えているかのような確認もなく、「よし、信じよう」となる。だから消費者はクレジットカードの明細を読み、見覚えのない請求に異議を申し立てなければ、そのまま支払うことになる
ネットワークには、消費者が被害に遭うことを気にする動機がほとんどない。異議申し立てがなければ全員が満足し、異議申し立てがあれば加盟店から回収すればよいので、自分たちの問題ではない
決済処理業者は、カード番号全体を総当たりするカード列挙やカードテストを許容せず、カードネットワークもそれを防がない加盟店や決済処理業者に強い罰則を科す
単一の PAN に対して CVC2 を列挙するのは別の話だ
不正防止インフラが実際に保護してくれた証拠だ。銀行が不正損失を負担し、資金も返してくれた
結局、銀行システムは不正損失を気にしており、不正検知にも非常に長けている。カード決済システムは規模が大きすぎて変更が極めて難しいため、特定の変更が実際に不正率を下げるという強い根拠がない限り、銀行は変更しないほうを選ぶ
発行銀行はすべての取引で加盟店手数料を得るため、不正の責任がなければ、できるだけ多く承認して後でチャージバックで処理しようとする誘因がデフォルトになる。ただし 3DS はこの計算をかなり変え、対面決済も通常は発行銀行の責任だ
結局、すべての消費者がすべての不正コストを共同で負担している。請求書に別項目として見えないだけで、私たちが買うあらゆるものに少しずつ上乗せされている
eBay で盗難クレジットカード絡みの件を経験したときは、最初は順調に進んでいたが、eBay が書類の山を銀行に送りつけるとチャージバックが覆り、そのほどなくして自分の銀行口座まで閉鎖された
チャージバックでお金が戻ったからといって終わりではない。最初は相手に返答の時間を与える間の暫定処理のようで、eBay が書類で自分を埋め尽くし、チャージバックが再び取り消されるまで30日ほどかかった。彼らの説明があまりに効果的だったため、銀行はむしろ自分を詐欺師扱いした
銀行が不正損失を負担するというのも100%正しいのか分からない。チャージバックを受けた側が争うのは、結局その損失を受けた側か起こした側のどちらかが負担するからだ。もし銀行がその損失を負担する仕組みなら、eBay がわざわざ専門人員を使って調査し、自分のチャージバックに対応する理由がない
3D Secure がどこでも義務なら、かなり役立つはずだが、米国ではほとんど使われていないと理解している。米国市場があまりにも大きいため、カード発行会社は 3D Secure なしのリクエストを許可せざるを得ず、そうでなければ顧客がカードを使えない場所が多すぎることになる
非常に強力な不正防止策が大きく制約されているわけで、世界のその他の地域から見ると歯がゆい
米国の消費者は、少し不便に見えるものより不正被害に遭うほうを好むのか理解できない。被害者でなくても、加盟店は不正コストと保険コストを商品価格に織り込むので、結局は全員が負担している
ただし業界全体で見ると典型的な調整問題だ。より簡単な代替手段が残っているからコンバージョン率が下がるのであって、すべての加盟店と銀行が同時に 3DS を強制すれば、移れるもっと楽な選択肢はなくなる。良くも悪くも、ユーザーはより安全な新方式に慣れ、コンバージョン率も再び上がる
EU が多くの決済で 3DS を義務化したのはこのやり方で、そこでも規制当局は100%適用が逆効果だと認めており、適切な落としどころはその中間にある
同じ原理の別の証拠として、米国のクレジットカードには PIN がない。個別の銀行が PIN を導入すると、顧客は PIN のない競合カードに乗り換え、利用率が大きく落ちるからだ。他の市場では、規制介入やカードネットワークのインセンティブのおかげで全カードに PIN があり、人々はただ慣れただけだ
クレジットカードが初めて登場した時期、つまり米国で始まった当時、議会は1974年 Fair Credit Billing Actを可決し、不正請求サイクル終了後60日以内に紛失カードを報告すれば、消費者責任を50ドルに制限した。当時の決済は「カチャン」という音を立ててカードのカーボンコピーを取る機械で紙に処理される完全オフライン方式だった
この法律は変わっておらず、実際にはほとんどの銀行がその50ドルも免除し、報告された案件についてカード保有者に一切責任を負わせない。50ドルのために顧客をいら立たせる価値が銀行にはないからだ
インターネットのおかげでカードは突然、はるかに盗みやすく悪用しやすくなったが、銀行は依然として請求サイクル終了後60日以内に報告された損失をすべて負担しなければならない。だから米国の銀行はクレジットカード取引のリアルタイム監視に莫大な投資をしており、最終的に自分たちが責任を負うので非常に真剣に監視している。一方で消費者はあまり気にしない。消費者視点で米国のカードがヨーロッパのカードよりずっと緩く見えるのは、消費者が免責される構造のため、銀行がバックエンドにずっと多く投資しているからだ
別件として EU はカード会社が課せる加盟店手数料を規制したが、米国には上限がない。その結果、米国のカード保有者はカード利用に対してかなりのリワードを得られ、特に上位10%の富裕層で顕著で、加盟店手数料が制限された EU の発行カードでは事実上不可能だ
現在、加盟店が低手数料カードだけを受け付けられるようにしようという大きな訴訟が進行中だ。標準的な VISA/MC/AMEX 契約はすべてのカードを同一に扱うよう求めており、そのためカード会社には人々をより高い加盟店手数料のカードへ誘導するインセンティブがある。その訴訟の結果次第ではあるが、それまでは米国の高額消費者のカードリワードははるかに大きくなり得て、これもカード利用を増やし、EU 型カードより摩擦を減らす方向に働く
不正被害を好んでいるわけではなく、これはカード発行会社と加盟店の間の交渉問題だ
昔、自分の会社で採用された人が、ギフトカードに保存価値を追加する方法を見つけたと自慢し始めたことがあった。後で分かったのは、その人が FBI の捜査を受けていたということだ
しかも政府契約業者だったのだが、最終的に自分が見た中で最も大きい警備員が来て、その人を連れ出していった
バーチャルクレジットカードはずっと前からあった。15年以上前に Bank of America や Citi が提供していた記憶があり、Java アプリだったかスタンドアロン実行ファイルだったかもしれない。なぜもっと広まらなかったのか不思議だ
Robinhood はこれを本当にうまく実装している。自分が使った中で最高のバーチャルクレジットカードシステムで、とてもスムーズだ。ワンタイム、24時間、あるいはキャンセルするまで無期限でカードを有効にでき、UI/UX も素晴らしい
今のように何もかもがサブスクリプションの世界で、なぜこうした機能が広まらなかったのか理解できない。解約をめぐって厄介なやり取りをしなくて済むよう、有効期限と利用上限を設定できる機能が本当に良かった
最近、妻のカードで海外から不審な取引があったという銀行の SMS を受け取ったが、金額が文字通り0ドルで、しかも妻がスマートフォンやコンピュータを使っていない時間帯だった
最初は SMS 自体がフィッシングだと思ったが、オンラインで確認すると文面形式は一致しており、銀行のウェブページもフィードバック過程でいかなる情報も求めないと保証していたので、決済していないと回答した
銀行はすぐにカードを停止し、新しいカードを発送した
当初は銀行のセキュリティシステムが過敏に反応したのかと思ったが、実際には誰かがこの記事で説明されていることをやっており、銀行がより早く検知したようだ
オンライン決済用のカードを別にして、決済に必要な分だけ入金しておくのがよい
ナイーブな考えだとは分かっている
記事に戻ると、脆弱性はパスワードで、それが 3D Secure を使わない別の加盟店へとつながっていた
記事を見る限り、攻撃者には完全自動化されたシステムがあるようなので、大手加盟店は同じ IP アドレスから異なるアカウントへの自動ログイン試行に対処すべきだ。自分たちの Wordfence ログを見ても IP のローテーションはそこまで速くないので、恒久的な IP ブロックである程度対応できそうだ
パスワード漏えいがクレジットカード全体のデータ漏えいにつながるべきではないと思う。同じデータは店舗で印刷される紙のレシートにも載っており、あるときは4桁、あるときは10桁だ。店に放置された紙のレシートでも、総当たりは依然として可能だ
付け加えると、加盟店はクレジットカード処理業者に対して望むセキュリティレベルを選べない。たとえば authorize.net では住所が一致しなくても決済を受け付けられる
本当の疑問は、どうやって金を抜き出したのかという点だ。セキュリティの甘い加盟店でギフトカードを買ったのだろうか？
番号を当てることと、システムの外へ資金を持ち出すことはまったく別の話だ
処理業者市場にはやや二極化がある。一方は顧客にシンプルさを提供して負担を減らす方向、もう一方はすべての複雑さを露出させて細かな制御権を与える方向だ。前者はセキュリティ要件を指定させず、後者は何百もの選択肢を与える。もちろんその中間に位置する処理業者もあり、この二つの軸は通常、異なる顧客を狙っている