クレデンシャルスタッフィング：ログインは正常に見えるのに漏れている理由

この攻撃と、それがブルートフォースでない理由

クレデンシャルスタッフィングはパスワードを推測しません。再生します。無関係な他サービスの漏洩から得たユーザー名とパスワードの組を、あなたのログインに対して 1 組につき 1 回だけ試し、少なからぬ割合の人が認証情報を使い回している事実に賭けます。

このたった 1 つの違いが、あなたが配備してきたものの大半を無力にします。ブルートフォースは騒がしく、1 つのアカウントに対する多数の試行なので、レート制限もロックアウトも容易です。スタッフィングは何千ものアカウントに対して各 1 回、数時間に散らし、アドレスを回しながら行われます。

成功率は低く——よく引かれる数字は 0.1% から数パーセントです——そしてそれで十分すぎます。100 万組のリストに対して 0.1% なら、使えるアカウントが 1,000 個です。

しかもその成功したログインは、あなたのアプリケーションが取れるあらゆる技術的な尺度において正しいのです。パスワードは合っていました。拒否すべきものが何もありません。

ログにどう現れるか

これが何週間も気づかれない理由は、単独のシグナルがどれも不穏に見えないからです。そのパターンは総量の中にしか存在しません。

• 失敗の件数ではなく、失敗率。失敗ログインの絶対数はほとんど動かないかもしれませんが、失敗と成功の比が動きます。試行が、たいていは存在しないか一致しないアカウントに散らばっているからです。
• 1 アカウントにつき 1 回。アカウントをキーにしたレート制限は決して発火しません。アドレスをキーにした制限も、攻撃者がローテーションを忘れたときだけ発火します。
• アドレスの分布。試行は住宅用プロキシのプールから届きます。つまり、データセンターではなく普通の顧客のように見えるアドレスです。
• 均一すぎるタイミング。人間のログイン traffic は顧客の一日のリズムに従います。スタッフィングの一巡りは、夜通し平坦です。
• 見慣れないアドレスからの、静かな成功の増加。これが最も重要で、そして誰もアラートを張っていないものです。ログイン成功はエラーではないからです。

なぜ通常の対策が取り逃すのか

以下はどれも持つ価値がありますが、単独でこの攻撃を止めるものはありません。

レート制限はキーの取り方を間違えています。アカウント単位の制限は、1 アカウント 1 回では決して発火しません。アドレス単位の制限は、住宅用プロキシのプールを回されれば破られます。それはもはや日用品のようなサービスです。

アカウントロックアウトはここでは無用を通り越して、積極的に危険です。1 回の試行では発火できず、公開されたログイン画面では、誰でも好きなときに顧客のアカウントを停止できるようにしてしまいます。

CAPTCHA は、攻撃者がすでに予算化している試行あたりの費用です。解答代行サービスは千件単位で値付けしており、成功率 0.1% でも採算は余裕で合います。

パスワードの複雑さの規則は何もしません。再生されているパスワードはすでに有効で、他サービスが課した規則を満たしており、おそらくあなたの規則も満たしています。

多要素認証は、この攻撃を本当に断ち切る唯一の対策であり、導入にはあらゆる努力を払う価値があります。ただし未設定のアカウントには効きません。消費者向けの製品では、それが大多数です。

実際に何が捕まえるのか

この攻撃は単独のリクエストの中では不可視なので、検知はセッションとアドレスの水準で働く必要があります。

セッション水準のシグナル。スタッフィングの一巡りはフォームを自動化します。フィールドはタイピングのタイミングなしに埋まり、フォーカスは人間の手が生まない動き方をし、送信は人が入力し終えられたとは考えにくい速さで届きます。これはあらゆるインビジブル検知が読むのと同じ行動の層であり、ごく最初の試行から見えています。

トランスポートのフィンガープリント。ツールは TLS 接続を張らねばならず、そのスタックは表に出ます。セッションが名乗るブラウザと合わない JA3/JA3N のフィンガープリントは強いシグナルであり、攻撃者はヘッダーを書き換えて直すことができません。

試行をまたいだレピュテーション。1 アカウント 1 回では、アカウント単位では何も得られません。しかし同じアドレスが 400 の異なるアカウントに 1 回ずつ試していれば、それは紛れもありません。この総量は、リクエストを数えるのではなくアドレスを採点する何かがあって初めて存在します。

テナント横断のレピュテーション。スタッフィングのリストは、同じキャンペーンの中で多数のサイトに対して再生されます。昨夜どこか他社のログインでリストを走らせたアドレスは、あなたのところで始める前に止める価値があります——それはこの知識が共有されて初めて可能になります。

擁護できる構成

各ステップが結果をどれだけ左右するか、その順に並べます。

MFA を導入し、設定率を押し上げること。このリストの他のどれも、単独でこの攻撃を断ち切りません。新規アカウントでは既定にし、既存のアカウントには新しいアドレスからのログイン成功のあとに促してください。

見慣れないアドレスからのログイン成功にアラートを張ること。安上がりで、すでに持っているデータを使い、そしてスタッフィングが効き始めたことを示すシグナルです。

リクエストではなくセッションを採点すること。行動とトランスポートのシグナルは、総量のパターンが形になる前、最初の試行で自動化を捕まえます。

ゲートウェイで遮断すること。ページの JavaScript で適用される判断は、攻撃者のツールが決して実行しない判断です。

設定時とログイン時の両方で、既知の漏洩に対して認証情報を照合すること。再生されているパスワードがすでに公開のコーパスにあるなら、誰かの問題になる前に拒否できます。

許可リストを最新に保つこと。自社の QA 自動化や負荷試験は、この攻撃とまったく同じに見えます。リリース当日にそれを遮断するのは、また別の種類の障害です。

Karma の立ち位置

Karma は 3 番目と 4 番目を担います。行動とトランスポートのシグナルから各セッションを採点し、テナント別のレピュテーション基盤を保って多数のアカウントにまたがる 1 つのアドレスを 1 つの主体として可視化し、任意参加の共有ブロックリストを提供して、業界横断で再生されているリストがあなたのログインへ届く前に既知となるようにします。

判定はゲートウェイへ渡り、ゲートウェイはあなたのアプリケーションがパスワードを評価する前にリクエストを止めます。その試行はあなたに何の費用も生まず、調査すべきログイン成功として現れることもありません。

これは MFA の代わりではありませんし、このページもそう示唆してはいません。MFA は再生されたパスワードを無価値にする対策であり、ここに書いたことはすべて、どのパスワードがまだ通用するかを試しているトラフィックを止める話です。