3 ポイント 投稿者 GN⁺ 2023-08-03 | 1件のコメント | WhatsAppで共有
  • ある SaaS サービスがカード承認拒否率の急増を追跡する中で、自動生成された名前と不審なメールドメインを使うカードテスティング攻撃を発見
  • 攻撃は大規模なボットトラフィックというより、最大でも毎分4枚程度の手動・軽量自動化に近く、カードには同じ銀行・資金源・米国発行という共通点があった
  • 公開 Telegram チャンネルやオンラインツールでは、BIN、CVC、有効期限、特定の Web サイトで通過しやすいカード番号の生成方法、Stripe Checkout 自動実行ツールが共有されていた
  • 成功した不正決済のうち15%がチャージバックにつながり、異議申し立ての受け入れ・返金・サブスクリプション解約・検証には ChatGPT で作った Python スクリプトが使われた
  • Stripe Radar のデフォルトのリスクスコアは大半が0〜5と低く、実際の防御では時間単位の失敗回数を制限するカスタム Radar ルールが最も有用だった

カードテスティング攻撃の発見と初期対応

  • 数週間前、カード承認拒否率が通常より高いというアラートが発生した
  • Stripe ダッシュボードで、自動生成のように見える名前と不審なメールドメインを持つユーザーの失敗した決済が多数確認された
  • サービス側はこれを典型的なカードテスティング攻撃と見なし、Stripe Radarを有効化し、チェックアウトに CAPTCHA を入れる作業をバックログに追加した
  • 同じ時期に Pieter Levels と Danny Postma も Twitter で類似の攻撃を共有していた
    • Pieter Levels は、Philippines から来た Jake Smith という名前の顧客240人を返金・解約し、カードテスティング決済の金額が $7,000 だったと書いていた
    • Danny Postma は、jack smith という名前で不正決済が発生しており、Stripe による迅速な解決策が必要だと書いていた

手動に近かった攻撃パターン

  • 数週間後、承認拒否率のアラートが再び発生し、暫定的な Stripe Radar ルールを追加しながら対応を始めた
  • トラフィックを詳しく見ると、攻撃者は最大で毎分4枚のカードをテストしており、ほとんどの時間帯では攻撃の強度と一貫性はさらに低かった
  • Stripe のカードテスティング防止資料を基準にすると、このサービスの実装は比較的よく保護された状態だった
    • ユーザーはチェックアウトを開く前にログインする必要があった
    • Payment Element を使用し、一部のシグナルも活用していた
    • Stripe のドキュメント基準では、カードテスティング保護レベルは excellent に近いはずだった
  • 追加調査と同僚によるレビューの後、このトラフィックは手動攻撃または非常に軽い自動化に近いものだと判断した

公開チャンネルで流通するカードパラメータとツール

  • 攻撃に使われたカードの大半には同じ特徴があった
    • すべて同じ銀行から発行されていた
    • 同じ資金源を持っていた
    • すべて米国で発行されていた
  • カードパラメータがあまりに似ていたため、本当に銀行から流出したカードなのか疑問が生じた
  • 公開アクセス可能なチャンネルで、クレジットカードのBIN、CVC、有効期限、これらの入力値から有効なカード番号を生成するツールへのリンクが見つかった
    • BIN はカード番号の先頭6〜8桁である Bank Identification Number を意味する
    • 資金源は、そのカードが debit、credit、prepaid のどれであるかを示す
  • 公開 Telegram チャンネルには、Spotify Premium や YouTube Premium を不正に入手する方法を案内するメッセージもあった
  • 特定の Web サイト、多くは SaaS で承認される可能性が高いカードパラメータを共有する公開された地下エコシステムが存在していた
  • このサービスへの攻撃も、特定の private Discord サーバーや Telegram チャンネルから始まった手動攻撃である可能性が高かったが、具体的な出どころは見つけられなかった
  • 公開チャンネルには、数日後に非公開へ移行するというメッセージが頻繁に見られ、活動の相当部分はアクセスできない場所で行われているように見えた
  • 自動生成されたカードリストを受け取り、任意の Stripe Checkout セッションに対して自動実行するオンラインツールも多数存在していた
    • Stripe がエンドツーエンドで所有する Stripe Checkout も自動化に脆弱になり得る点は予想外だった
    • ツールコードの一部は、Gmail のランダムな invalid メールアドレスを生成していた

異議申し立て、返金、サブスクリプション解約まで続いた事後処理

  • 一部の攻撃者は決済に成功し、実際に製品を購入していたため、事後処理のコストが大きくなった
  • 規模を把握するため、5月1日以降に失敗した決済が5回を超える顧客をデータストアで照会した
  • ChatGPT で Python スクリプトを作り、それらの顧客のメールドメインを抽出した
  • ドメイン一覧をもとにデータベースを照会し、同じドメインのメールアドレスを持つ顧客が作成した成功決済の一覧を取得した
  • 別の ChatGPT 生成スクリプトで、どの決済がすでに異議申し立て状態になっているかを確認した
  • 成功した不正決済のうち15%がチャージバックにつながった
    • チャージバック率: {p:15}
  • すべての異議申し立てを受け入れ、各件につき Stripe の £20 手数料を負担することにした
  • Stripe で最小権限の restricted key を作成し、ChatGPT でチャージバック受け入れスクリプトを生成した
  • その後、スクリプトで一覧内の決済を取得し、異議申し立てではない決済を返金し、その決済を作成した顧客のアクティブなサブスクリプションを解約した
  • 返金された決済についても、成功決済と返金処理の過程で Stripe およびネットワーク手数料の損失が発生し得た
  • 最後の検証スクリプトで、すべての決済が異議申し立て受け入れまたは返金状態であること、該当顧客にアクティブなサブスクリプションが残っていないことを確認した
  • ChatGPT はスクリプト実行時の注意と小さなサンプルでのテストを推奨し、スクリプトは自分でレビューし、顧客データ・ID・API キーは共有しなかった

米国銀行の承認慣行が残す負担

  • オンライン決済の世界は、事業者にとって不公平な面が大きいと見ている
    • 異議申し立てに勝てる可能性が低い
    • Stripe 基準では異議申し立て活動を0.75%未満に維持する必要がある
    • 事業者が勝っても負けても、異議申し立てごとに £20を支払う必要がある
  • 同時に銀行、特に米国の銀行は、次の条件でも決済を承認することがある
    • 氏名全体が間違っている
    • CVV/CVC が有効でない
    • 有効期限が間違っている
    • 請求先住所が一部しか提供されず、ZIP code も間違っている
  • こうした条件でも 3D Secure 認証が必ずトリガーされるわけではなかった
  • カード番号だけが正しい決済について、なぜ事業者が責任を負わなければならないのかという疑問が残る
  • prepaid card ではこうした検査の可能性が制限される場合があるが、改善の余地はあると見ている

実際に効果があった Stripe Radar ルール

  • 初期対応は Stripe Radar の有効化だった
  • Stripe Radar は決済ごとにスコアを付け、一部の指標が合わない場合に自動ブロックするよう設計された機械学習ベースのソリューションである
  • 今回の事例では、デフォルトの Radar 判断は大きな助けにならなかった
    • 不正決済のリスクスコアの大半が0〜5と低く出た
    • 逆に、一部の正常な顧客は 3D Secure チャレンジに2回失敗した後にブロックされた
    • この経験により、顧客の運命を機械学習に委ねることへの懸念が生じた
  • より有用だった機能は Stripe Radar カスタムルールだった
    • 3D Secure チャレンジの要求
    • 手動レビューへの送信
    • 完全ブロック
  • Radar ルールは疑似コードのように見えるが、悪意ある決済試行を絞り込むかなり複雑なロジックを表現できる
  • 最も有用だった対応は、顧客ごとに1時間、1日、1週間の間に可能な決済失敗回数へ妥当な制限をかける方法だった
  • CAPTCHA の追加、失敗率の監視、カスタム Radar ルールの共有が、銀行の承認責任が大きくなるまで取り得る現実的な対応として残る

コストは結局、事業者と顧客に転嫁される

  • 決済プロセッサ手数料、チャージバック罰金、エンジニアリングコスト、プラットフォームからの排除リスクまで、不正活動のコストは世界中の事業者が負担する
  • Stripe が事業者に £20 のチャージバック手数料を課すことも、不公平な扱いの一例と見ている
  • こうしたコストは結局、より高い価格という形で顧客に転嫁される
  • 毎日依存している決済ネットワークは悪用されやすく、カードに請求できるかどうかの最終判断は発行銀行の裁量に委ねられている
  • 銀行が承認に対してより多くの責任を負わない限り、事業者にできることは、承認失敗率を綿密に監視し、CAPTCHA を追加し、Stripe Radar ルールを改善することに近い

1件のコメント

 
GN⁺ 2023-08-03
Hacker News のコメント
  • いちばん驚くのは、Stripe 決済を悪用する集団がいるという事実より、筆者が ChatGPT に支払い処理の自動化スクリプトを作らせたという点だ。
    とくにチャージバック処理用だったのが問題で、文脈からすると筆者にはそのスクリプトを自分で書いたり検証したりする技術的能力が不足しているように見えた。
    Stripe が不正防止を担ってくれると信じて裏切られたと憤りながら、今度は自分が理解していない別の技術をまた盲信しているわけだ。
    問題は Stripe だけではなく、信頼をどこかに丸投げして、うまくいくことを願う態度にある。

    • これは少し誤った描写のように感じる。
      筆者は決済処理を任せたのではなく、それらのアカウントのチャージバックをざっと確認して、実質的に「承認」ボタンを押すスクリプトを作った、というのに近い。
      技術力が不足しているという判断もどこから来たのかよく分からないし、記事でも「スクリプトはすべて注意深くレビューし、顧客データ、ID、API キーは共有しなかった」と述べていた。
    • この人は収益の出る事業を運営し、顧客に価値を生み、機能をリリースし、自分が軽減した脅威と学んだことを公開している。
      その過程で ChatGPT でスクリプトを作って時間を節約しただけだ。
      非技術者なのか、単に時間を節約しようとしているだけなのかは分からないが、正直こういう実行力は称賛されるべきだと思う。
      これらのスクリプトは生死を分けたり事業の中核的判断を下したりしたものではなく、大量データをふるいにかけて、手動確認できる結果を素早く作るための道具だった。
      むしろ ChatGPT が最も役に立つ事例に見える。時間の足りない創業者が特定の目的を持ち、一時的に必要な専門知識を得てスクリプトを作るという、能力増幅ツールだということだ。
      以前なら同じ結果を出すために、外注先を探し、雇い、説明するのに数週間かかったようなことを、今ではほぼ無料で即座に作れる。
      こういうものを反射的に「驚きだ」とか無責任だと見るのは理解できるが、かなり「最近の若いものは」的な反応に感じる。
      これが未来なら、開発者は非技術者の自己充足性が高まることを支持し、創業者が ChatGPT にスクリプトをうまく依頼する過程をどう改善するか考えるほうがよいと思う。
    • 記事を書いた本人です。実行する前に ChatGPT のスクリプトを入念にレビューし、テストしました。
      この分野の技術的専門性が不足しているとは言いにくく、単に時間をできるだけ効率的に使おうとしているだけです。
    • こういう根拠のない憶測を、なぜこんなに頻繁に見るのか分からない。
      筆者はすでにスクリプトをレビューし、機密データはアップロードしていないと答えているので、その点について付け加えることはない。
      多くの人は ChatGPT を効果的に使っているが、結果を盲信しているわけではない。私にとって ChatGPT は出発点であって、最終成果物ではない。
      幻覚で作られた判例引用を検証せずに法律書面へ貼り付けたあの弁護士のように、誰もが愚かなわけではない。
    • ChatGPT がなぜ言及されたのか少し変に思った。ほとんど広告のように感じた。
      似たような記事をたくさん読んできたが、内容がコーディングやデバッグ自体についてのメタな話ではないのに、筆者が突然 Stack Overflow に頼ってコーディングしたと言うケースはあまり記憶にない。
  • 米国で決済を受ける外国企業なら、こういうものは単なる営業コストとして見込むべきだ。
    米国のクレジットカード詐欺は社会化されている。最終消費者は責任を負わないので、チップと PIN、二要素認証、3D Secure のようなものをあえて使わない。
    疑わしい取引を見つけたら、銀行アプリでボタンを一つ押せば数分以内に決済が取り消される。
    銀行や決済処理業者にも、人々にもっと使わせるため、取引をできるだけ速く簡単に通す方向のインセンティブがある。
    筆者が述べたように、有効期限、請求先住所、郵便番号が一致しなくても、たいてい決済は通る。
    欠点は、すべての責任が事業者に押し付けられ、事業者はそれを補うために全員に対して価格を上げるしかないことだ。

    • その因果関係にはあまり納得できない。
      デンマークにも同じ消費者保護、チャージバックの可能性、銀行口座が侵害されても消費者が損をしないようにする政府保証がある。
      それでも購入時には必須のチップと PINや 3D Secure のような強い保護がある。
      米国により良いカードセキュリティがないことに合理的な理由があるとは思えない。単に望んでいないように見える。
    • ここにカード会社が加盟店に課す、とんでもない手数料も加わる。
      米国では通常、取引額のおよそ 2% で、EU では最大 0.3% に制限されている。
      それでも移動する金額の規模を考えると、なお大きく見える。
      この費用も結局は社会化されて消費者に転嫁され、現金で支払う人もより高い価格として負担することになる。
      ちなみに 3D Secure では、一部の銀行の約款上、カード所有者が不正決済の責任を負う場合がある。
      携帯電話での二要素認証なら、携帯電話と財布を一緒に盗まれるだけで十分で、実際に数千ドルを失った事例をニュースで見た。
    • 米国人とカナダ人は、ひとつの取引を処理するために裏で起きている混乱から遮断されている。
      彼らは 1 ドルあたり 1〜2 セント、多くても 5 セント程度の還元を「ポイント」という形で見るだけで、1 セントが 100 ポイントのように表示されるのでそれらしく見える。
      見えていないのは、商品価格全般への3〜5%以上の上乗せ、チャージバックと処理コスト、不正決済、脆弱なセキュリティ、いまだに磁気ストライプを受け付ける店、そして多数の中間業者だ。
      銀行手数料、カード発行会社手数料、ネットワーク手数料、プレミアムカード手数料が次々に乗る。
      完全な混沌で、本当に嫌になる。
      FedNow で変わることを期待している。人々のお金を吸い上げる中間業者をなくし、寄生虫と無駄をなくすべきだ。
    • 米国の銀行に焦点が当たっていたのはおかしかった。Telegram の画像の一つには、フランス・パリの住所を使えと書かれていたからだ。
      私が属する二つの組織をこの 2 年間運営してきたが、どちらもフランスの銀行カードを使う自動クレジットカード確認ボットにやられ、多くのカードが通った。
      もちろん両組織とも、決済サイトを強化せよという私の以前の警告を無視していた経緯があり、そのうち一つはまだ Magento 1 を使っていた。
      逸話にすぎないが、本当の問題は、クレジットカードが ACH と同じくらい場当たり的につぎはぎされた遺物で、誰も意味のある形で直そうとしていないことにある。
    • 何よりも経路依存的な古い慣行のためである可能性が高い。
      クレジットカードは米国で発明されたので、技術が古く、アップグレードに時間がかかる。
      手動決済の分野では、インドの UPI はかなり良さそうに見える。決済が処理される前に、顧客が携帯電話上で各決済を承認する方式だと聞いた。
  • チャージバック手数料に関して、Visaは数年前にVerifiという会社を買収した
    新製品としてRapid Dispute ResolutionとOrder Insightがある
    RDRは取引がチャージバックになる前に自動返金できるようにし、Visaが4ドルの手数料を受け取る。MCCコードが高リスクでないことが前提
    Order Insightは、異議が申し立てられた決済について特定のデータを即時に提供できるようにし、顧客に過去3回の決済履歴がある場合はチャージバックを発行できなくなる
    私たちの事業では、勝訴率、平均注文額、チャージバック手数料を基準にすると非常に簡単な判断だった
    これでVisaや加盟店銀行の1%チャージバック規則も常に心配しなくて済む
    Visa決済にしか適用されないが、全取引量の約50%を占めていた
    最後に、Visaは処理業者の巨大な収益源を事実上奪っている。処理業者がTSYSなら、RDR手数料として10ドルを取ろうとするだろう

    • 記事の筆者です。Mastercardについてはどのように対応していますか?
      Ethocaは聞いたことがありますが、SEOが本当にうまいですね。Verifiとかなり似ているように見えます
  • 米国はなぜ銀行まわりでこれほど遅れて見えるのか分からない
    英国は2004年からチップとPINを導入し、2006年から義務化したのに、米国はそれより10年ほど遅れて追随した
    Faster Paymentsは、ほとんどの銀行口座間で即時送金を無料で提供している。米国の顧客から送金を受けるのは、米国のWise口座があってもいつも悪夢だった
    EUが強力な顧客認証を導入してからは、ほとんどの新規決済がモバイルバンキングアプリや別の二要素認証手段で承認される必要がある
    それ以前でも、少なくとも郵便番号とCVVは一致していなければならなかった
    こうした措置は、銀行が不正の責任を顧客に押しつけるやり方のようにも見えるが、どちらにせよ損をするのは顧客だ
    カード不正が広く受け入れられている文化では、その費用を相殺するために価格が上がる

    • カナダ人の立場からすると、米国のレストランで支払うときはタイムトラベルしたような気分になる
      テーブルで端末に直接支払うのではなく、店員にカードを渡し、どこかで手作業で処理されるのを待たなければならない
      ここ数年で改善しているかもしれないが、カナダでは2000年代初頭以降、そのような方法は使っていない
    • カード不正が総決済額のX%を占めるなら、企業はそれに対処しようと努力することもできるし、対処しないまま取引を流し続けてコストを負担することもできる
      その結果、Y%多くの顧客を処理でき、YがXより大きければ長期的にはより多くの利益を出せる
      米国では、巨大な規模のおかげで多くの事業でこのやり方が通用する
      たとえばMcDonald'sは、昼のピーク時に不正がないか確認するのに1秒使うより、素早く決済を処理するほうが利益率の面で得な可能性が高い
      欧州では通用しないかもしれないが、実際のコストを分析する際に取引速度と規模という次元を見落としていると思う
      不正と利益のバランスが企業に不利になった瞬間、米国でも主要な不正防止策がほぼ即座に有効になるだろう
    • 米国には非常に多様で規制の緩い銀行部門がある
      50州にわたって何千もの小規模な地域銀行があり、各州もかなり独立している
      この環境で大型の新技術を展開するのは、はるかに難しい
    • ここのコメントの大半は、原文とはあまり関係がないように見える。原文は具体的にカード非提示不正についてのものだ
      チップとPINはインターネット決済では機能しない
      銀行送金は国際的にはうまく合わない
      住所確認とCVVは有効化しやすいが、正当な取引までより多く拒否してしまう可能性がある。場合によっては、そのコストが検出できる不正リスクを上回る
      不正の責任は顧客ではなく加盟店に押しつけられる
      もちろん、加盟店の不正コストは最終的に価格に反映され、顧客がより多く支払うことになるが、すべての不正コストが結局は消費者に転嫁されるという意味でのみそうだ
    • 「進んでいる」「遅れている」という発想は思考を止めてしまい、テーマ全体を数直線上の位置のように変えてしまう
      実際にはそうではなく、複雑な問題であり、大西洋の両側の主体が変化を悪用しようとする不誠実なゲームをしている
      また、関係する役割も無視している
      安定した仕事を持つ20代半ばの人々は、さまざまな理由で実際のシステムの中でますます小さな部分になっている
      EUやその他の地域でも、働く20代が搾取され、権利を失っていると見る人もいる
  • 以前勤めていた会社のサーバーがハッキングされ、APIキーを盗まれて、そのサーバーでカーディングをされた
    PayPalは、私たちに手数料10万ドルを支払う必要があると言ってきた
    私たちは講座の登録料として、1日最大5件、1件あたり4,500ドル程度しか処理していない会社だった
    ハッカーはランダムなクレジットカード番号に対して、毎秒1ドルのオーソリ要求を回していた
    カーディング手数料は結局支払わずに済んだが、彼らは気にしていない
    不正からお金を稼いでいるので、気にしないのだ
    設定上、注文金額は2,500〜6,000ドルの間だけ許可するようにしていたが、オーソリ要求は確認していなかった
    本当にめちゃくちゃな話だ
    2010年ごろのことで、当時Stripeはカナダでは使えなかった

  • Stripeの不正防止はひどく、意図的だ
    彼らはリスク管理コストを露骨に顧客へ押しつけている。わいせつなほどだ
    クレジットカード不正防止の分野で働いているが、私自身がその仕事をものすごく得意というわけでもない。それでも私たち3.5人のチームは、この種のカーディング攻撃を防ぐシステムを簡単に作り、維持できた
    事業者がカーディング攻撃を防ぐ主な方法は、次の標的より少しだけ面倒にすることだ
    私には、Stripeは苦痛とコストをユーザーに転嫁できるので、最も攻撃しやすい大規模ネットワークのままでいても構わないと考えているように見える
    Stripeはごくわずかなコストでも、このような被害を簡単に防げる
    数セントを節約するために、ユーザーが苦しむままにしておく選択をしている

    • Stripeは些細なものにまで課金しようとし、Radarの費用を払わせたがっている
      Stripe Taxesとひどい為替換算もまったく同じ戦略だ
      最初はサービスをまともに提供せず、最終的にStripeの取引コストが全体価格の二桁パーセントにまで上がることに気づかされる
  • StripeのEdwinです。この記事は1か月前の古い記事(https://piotrmierzejewski.com/p/card-networks-exploitation)をコピーしたものだ、という点を付け加えておきたいです
    その後、この問題の大半は修正しました。この種のカードテストは減っており、現在はRadarがこうした攻撃を検知するはずです
    チャージバックについては、私たちもチャージバックを嫌っており、可能な限り減らしたいと考えています
    実際、これに役立ついくつかのことに取り組んでいます
    銀行はチャージバック手数料をさまざまな金額で課しており、その平均が20ドルの手数料という形で表示されています
    Stripe専用の手数料ではなく、私たちはチャージバックで利益を得ていません
    今年残りの会社計画をちょうどまとめたところで、この種の不正を減らすことが最優先事項です
    同じようなことを経験していると思うなら、edwin@stripe.com までメールしてください

    • 「Radarが今はこうした攻撃を検知するはず」ではなく、標準搭載の機能が検知すべきです
      本気で、あなたたちの顧客として言っています
  • 昨年、あるEC企業でシステム、CI、インフラ、ソフトウェアをすべて担当する役割で働いていました
    こうしたことは本当によくあり、毎週少なくとも1日は新しいパターンを把握してブロックするのに費やしていました
    攻撃者たちは私たちのシステムでクレジットカードを検証していました
    最終的にカートと決済周りへの攻撃はほぼすべて防ぎましたが、リクエストは入り続けていました
    その後、無関係なPHPの問題でログを調べていたとき、あるソフトウェアエンジニアが、後から決済手段を保存するページにものすごいトラフィックが来ていると言いました
    そのプラットフォームはカードが本物か確認するために1ドル決済を投げており、攻撃者たちはそれを利用してカードを回し続けていました
    クレジットカード泥棒は本当に抜け目がありません

  • Stripeで不正を検知するには、本気で減らしたくて取引量が十分にあるなら、独自の不正検知モデルを学習させるのがよい、という助言を受けたことがあります
    単純なロジスティック分類器のようなものでも通用することがあります
    Stripe Radarは各事業の細かな特性に合わせ込まれているわけではなく、どの商品を買うのか、サイトを開いてから購入までどれくらいかかるのか、といった追加シグナルを反映できます
    カスタムRadarルールもある程度は機能します
    多くのインディー事業者に、こうしたことをするリソースや意思がないのは理解しています
    購入できるソリューションもありますが高価で、概して大量取引の加盟店向けです
    いつかStripeが微調整可能なRadar製品を出すかもしれません

  • クレジットカード業界がなくなるべき、もう一つの理由です
    セキュリティプロトコルは存在しないか、21世紀初頭以降アップグレードされておらず、仲介業者による濫用も数え切れないほどあります
    こうした厄介事を処理するコストは、より高い取引手数料やチャージバック手数料という形で加盟店に転嫁され、最終的には消費者に渡ります
    クレジットカード業界が消費者に最悪の消費習慣を助長し、終わりのない債務奴隷の循環を持続させている点も忘れてはいけません