次世代 WAF でリクエストをエンリッチ化し、漏洩したユーザー情報を特定する方法

残念なことに、ユーザー名やパスワードを含むデータ漏洩はますます一般的になっています。攻撃者は、多くのユーザーが異なるサイトで同じパスワードを使用していることを知っています。盗んだリストを相互参照して、ログイン情報を照合することで、攻撃者はデータ流出元の Web サイトを含む広範囲のサービスでアカウント乗っ取り (ATO) 攻撃を成功させています。今月、過去最大のパスワードリストが流出され、膨大な数のユーザーアカウントが危険にさらされました。しかし、Fastly を経由したエンリッチ化されたリクエストを使用することで、漏洩が確認されている認証情報がユーザーログインに使用されていないかどうかを監視することが可能です。

最近公開したエンリッチメントに関する Developer Hub のチュートリアルでは、Fastly を通過するリクエストにサードパーティの API からデータを追加する方法を紹介しています。このチュートリアルでは、例として Have I Been Pwned の API を使用しています。Have I Been Pwned は、指定したユーザー名やパスワードが過去に漏洩したものかどうか、データベースをチェックできるオープンソースのサイトです。リクエストに `fastly-password-status` ヘッダーを追加することで、オリジンサーバーはリクエストの内容に対する HIBP の判定を判断します。

Fastly のエッジクラウドは、その情報をどう扱うかはお客様のオリジンに委ねていますが、もしお客様がオリジンで次世代 WAF (旧 Signal Sciences) を運用しているとしたら、何ができると思いますか？お客様はリクエストに追加されたデータを WAF のシグナルとして使用することが可能です。なぜそれが可能なのか、今日はこれらを関連付ける方法について説明します。

Fastly の設定

ログインエンドポイントへのリクエスト

まず、次世代 WAF の管理コンソールにログインし、Compute サービス経由でルーティングされるリクエストに対して、既知の漏洩パスワードのチェックが行われているか確認します。以下のルールは、`fastly-password-status` のヘッダーがリクエストに存在するかどうかをチェックします。このヘッダーは、パスワードが漏洩していることがわかっている場合はもちろん、そうでない場合でも、すべてのリクエストに追加する必要があります。`fastly-password-status` のヘッダーが存在する場合にシグナルを追加すると、パスワードチェックが行われたことを把握できます。

既知の漏洩パスワードが使用されたリクエスト

Developer Hub のチュートリアルで説明されているように、`fastly-password-status` のヘッダーが存在し、値が `compromised-credential` であるかどうかをチェックする追加のルールを作成することで、リクエストヘッダーのキー/値のペアに基づいて、パスワードが漏洩しているものかどうかを確認できます。このヘッダーのキー/値のペアが存在する場合、設定された Wasm サービスが漏洩したパスワードを識別したということになります。

シナリオを見てみる

この設定を行うことで、潜在的な攻撃についてより多くの情報を得ることができます。例えば特定の時系列にて受信されたリクエストにおいて、ログイン試行回数、ログイン失敗回数、認証情報漏洩のシグナル数が増加した場合、ブルートフォースによるアカウント乗っ取り試行が発生している可能性があります。

このデータを利用することで、より多くの情報に基づいた判断ができるようになります。今回のデモでは、「checked-pw」と「compromised-pw」というシグナルを持つ「Compromised Passwords (漏洩パスワード)」カードを作成しました。時系列データとログインカードを組み合わせてみると、ログインの試行と失敗の回数が多いことを確認できましたが、ログインの成功はありませんでした。この期間のログイン試行の大半には、既知の漏洩パスワードが使用されていたのです。

この情報から、ログインエンドポイントがブルートフォースログイン攻撃を受けている可能性が高いことがわかります。

より多くの情報に基づいた対策

Fastly の次世代 WAF を使用することで、しきい値ベースのアプローチで不正行為を低減させる対策を取ることができます。以下は、特定の IP からの「All Requests」というシグナルを持つリクエストによって漏洩パスワードを使用したログインが一定の回数試行されると、そのリクエストをブロックするレート制限ルールです。

このような対策を取ることで、セキュリティチームや不正防止チームはユーザーの挙動を調査し、標的となっているユーザーは1人または少人数なのか、それとも多くのユーザーを対象とした大規模なパスワードスプレー攻撃が行われているのかを判断することができます。

攻撃が小規模のユーザーグループに対するものであれば、標的となっているユーザーが漏洩していない強固なパスワードと2段階認証を使用していることを確認することが、セキュリティチームの対応例です。もしそれらの IP からのログインが成功している場合は、そのユーザーセッションを終了させ、強制的にパスワードをリセットします。

まとめ

Have I Been Pwned API からのデータを Fastly の次世代 WAF に取り込むことで、お客様のサイト上で既知の漏洩パスワードを使用したログイン試行の規模を可視化することができます。この情報を使用することで、アカウント乗っ取り攻撃の対策を取り、顧客アカウントのセキュリティを高めることができます。今回の例は、Fastly とエンリッチ化されたリクエストの活用方法のほんの一例に過ぎません。他にも使用例がありましたら、ぜひ Twitter で教えてください！