いまだに発生するIDパスワードリスト型攻撃について思うこと

IDパスワードリスト型攻撃(クレデンシャルスタッフィング)とは？

IDパスワードリスト型攻撃はかなり以前からあった不正アクセスの手法で、すでに対策がなされているサイトが多いかと思っていました。しかしながらここ最近になりこの手法を利用した不正アクセスの報告がありました。改めてこの不正アクセスの手法、対策について考えてみることにしましょう。

 

www.yomiuri.co.jp

IDパスワードリスト型攻撃について再度確認してみます。英語ではクレデンシャルスタッフィング(資格情報の詰め込み)と呼ばれ、ダークウエブ上やWebサーバへの脆弱性を突いた攻撃により漏洩し不正取得されたユーザーログインIDとパスワードの組み合わせをログインリクエストを自動化することで大量に送信し、正しいIDパスワードの組み合わせを確認したり、正しい組み合わせが見つかればそのサービスになりすましログインを行う不正アクセスのことです。なりすましログインを行なった後は登録されている名前、住所、電話番号などの個人情報を不正取得したり、不正に商品を購入するなどの被害が発生します。個人情報は不正取得すると他のサイトでアカウント作成時に不正利用され、なりすましで他人の個人情報を利用して本人になりすましてアカウントを作成されるケースもあります。

IDパスワードリスト型攻撃(クレデンシャルスタッフィング)の概要

Automation Request(自動化されたリクエスト)のリスク

IDパスワードリスト型攻撃を人の手により行うことは実際には可能ですが非効率です。大量にあるIDとパスワードの組み合わせをログインで「試行」する必要があるからです。人の手で実施する場合にはかなりの時間と労力を必要としてしまい攻撃者からすると効率が悪いからです(全く、人の手によるIDパスワードリスト型攻撃が無い訳ではなく「可能な範囲」で実施する攻撃者もいたり、海外では複数人を集めて人海戦術でIDパスワードリスト型攻撃を行うケースもある)。したがって攻撃者は大量のIDとパスワードの組み合わせを試行するためにログインリクエストを自動化して送信しようとします。この自動化されたリクエスト(Botからのリクエストとも呼ばれます)からログインなどのアプリケーションを保護していくことが重要です。

適切ではないAutomation Request(自動化されたリクエスト)を検出する方法

送信元IPアドレスや送信元の国からのアクセスをブロックしても意味はない

IDパスワードリスト型攻撃の送信元であるIPアドレスや送信元の国からのリクエストをアクセスコントロールでブロックする手法を取られるケースがあります。これは適切ではありません。実際にAutomation Request(自動化されたリクエスト)の脅威分析を行なった経験から言えることとしては、これらのアクセスコントロールは簡単に回避できる手法を攻撃者が取ってくるため有効では無いということです。IPアドレスはOpenプロキシなどの仕組みを利用することでIPをローテーションして送信することもできます。実際の攻撃では同一のデバイスでも数百のソースIPアドレスを利用していることがありました。従いまして特定のIPアドレスを指定してアクセスをブロックしても意味がありません。また、攻撃者はホスティングサービスを利用しているケースが多いです。AWSやAzureなどのサービスを利用して自由に利用するサービスのリージョンも選択できるため送信元の国を指定したフィルタもあまり有効ではありません。

キャプチャ認証は技術的にバイパスできる

自動化されたリクエストからアプリケーションを保護するための目的としてキャプチャ認証があります。パズルなど人が認識して「処理」しないと進めない仕組みです。有名なものとして一定のリクエスト数まで無償で利用できるGoogleのreCAPTCHA(リキャプチャ)があります。いくつかのバージョンがあり人でないリクエストと判定した場合はパズルを表示したり、 チェックボックスに「人」にチェックさせることで人が操作して送信したものか？自動化されたリクエストかを判別します。

developers.google.com

reCAPTCHAの問題点は1) reCAPTCHA v3は自動化ルーツでも正確に検出できないケースがある、2) パズルなどのチャレンジを返す場合はCAPTCHA Solverというサービスを利用することで回避することができる、ということがあります。つまり、Automation RequestはreCAPTCHAでは完全に防ぐことができないということです。

例えば2captchaはCAPTCHA Solverとして有名でキャプチャのパズルなどの解決をサービスに登録した人が人力で解決していく有償サービスです。

2captcha.com

(CAPTCHA Solverにご興味があれば次の記事が詳しいです。仕組みなど詳細が書かれています。: I Was a Human CAPTCHA Solver | F5 Labs )

reCAPTCHAをバイパスするために一定の「工数」は攻撃者に必要となるため、全く何も対策をしていない場合と比較してある程度の「ハードル」となることは確かです。IDパスワードリスト型攻撃のケースでアカウント乗っ取り後の金銭が目的である場合などでモチベーションを持った攻撃者がそのサイトを攻撃対象とする場合、先ほど紹介したツールやサービスを利用してreCAPTCHAをバイパスしようとするため対策とはなり得ませんが、さほど、Automation RequestのターゲットとならないサイトであればreCAPTCHAなどのキャプチャ認証は有効かもしれません(ただし技術的にはキャプチャ認証はバイパスできることは認識すべきでしょう)。

reCAPTCHAなどのキャプチャ認証の導入で注意する点としてはユーザーに煩わしさをもたらしてしまうことです。パズルが複雑なキャプチャ認証を見たことはないでしょうか？人でも「真剣」に考えないといけないキャプチャ認証はユーザのログインからの「離脱」を助長する可能性があります。

 

Automation Request(自動化されたリクエスト)を検出する「正しい」方法

では、Automation Requestを検出するための最適な方法とはどんなものでしょうか？一般的にはいわゆるBot対策専用ソリューションの導入が有効です。Automation Requestが人の操作に似せてリクエストを送信してくるため、Bot対策専用ソリューションではクライアントブラウザやモバイルデバイス上の「シグナル」と呼ばれる情報を取得して、そのシグナルとルールから自動化されて送信されたリクエストなのか？人の操作により送信されたものなのか？を判別します。例えばわかりやすいシグナルの例としてBot対策ソリューションではブラウザの場合、マウスや画面タッチの操作の情報を取得します。Automation Requestの場合はこのようなマウスや画面タッチの操作が全くなかったり、マウスの動線が記録されていない場合があり、明らかに人の操作でないリクエストであることが判別できます。
人に似せてリクエストを自動化して送信しているためログの分析だけでは人の操作により送信されたリクエストなのか自動化され送信されたリクエストなのか？わからないケースが多いです。IDパスワードリスト型攻撃もそのような自動化されて送信されたリクエストで人の操作によるリクエストに紛れて送信されるため管理者がその攻撃に気づくまで時間がかかるケースがあります。Bot対策ソリューションでは人か自動化され送信されたリクエストかの可視化ができるダッシュボードやレポート機能を実装しており、トラフィックの分析では非常に有益です。

WAAP (Web Application & API Security)

自動化してリクエストを大量に送信する手法やツールも進化しており、より人が操作したように見せかけたリクエストを自動で送信できることが簡単になっています。その結果、リクエストが人に似せているため既存のDDoS対策ソリューションやWAFで検出が難しくなっているのが現状です。そのため、最近ではWAAP(Web Application and API protection)という新しいWebアプリケーション保護の考え方がガートナーより提唱されており、その中でDDoS対策、WAF, API保護にさらにBot対策、つまり自動化されたリクエストからの保護も必要とされています。

継続したルールチューニング必要

Bot対策ソリューションを利用するとAutomation Requestは検出可能ですが、攻撃者は「どうもリクエストが検出されているのではないか？」と理解するようになります。金銭目的などAutomation Requestを送信するモチベーションがある攻撃者は、どうしてもその目的を達成しようとします。すると試行錯誤の結果「この方法で少しリクエストの送信の方法を変えると検出されない」ことを発見し、再度、攻撃を仕掛けてきます。これをRetooling(リツーリング)と呼んでいます。Web Applicationのセキュリティー管理者はRetoolingに全く気づかないか？気付いたとしてそのリクエストの特徴を分析してあたらしいルールを作成して検出させる必要があります。このようなRetoolingと対応のサイクルが永遠と続くこととなります。攻撃者がAutomation Requestリクエストを送信して目的を達成したいサイトであれば継続したルールチューニングが必要となることは覚悟しておいたほうが良いでしょう。ルールを強めに設定すると誤検知が発生し、正規のユーザがブロックされますし、ルールが弱ければAutomation Requestが検出できません。トラフィックの特徴をシグナルから把握しながら「絶妙」なルールチューニングがBot対策では必要です。Bot対策サービスには継続的なルールチューニング作業が含まれるものもあるためそういったサービスを検討すると良いでしょう。

二要素認証とリスクベース認証

リスクベース認証と組み合わせた二要素認証の導入でIDパスワードリスト型攻撃への防御とすることも検討できるかもしれません。しかしながら全てのログイン操作に二要素認証を強制するのは現実的ではありません。なぜかというと二要素認証のログイン操作がユーザーにとっては面倒な操作であるからです。特に「面倒な操作」はECサイトでは問題です。ユーザーがログインが面倒でログインを諦めてしまってはECサイトからの売上に影響を与えてしまいます。したがって通常はリスクベース認証を併用し例えば「いつも利用しているデバイスとは違うデバイスでログインしようとした」場合などリスクがある場合にのみ二要素認証を実施(チャレンジ)させます。ただ導入には注意が必要な点があります。

  • ログインの成功後にリスクベース認証でリスク判定を行い、２段階認証として別の要素で認証するような場合、ログインはできない可能性はあるが、IDとパスワードが合っているかどうかのチェックは実行できます。そのためそのサイトを踏み台として、他社のサイトで確認済みのIDとパスワードが不正利用される可能性があります。
  • リスクベース認証と二要素認証の導入にコストがかかる。
  • リスクベース認証の結果、二要素認証が実行(チャレンジ)された場合、そのクレデンシャルを入力できずログインできないユーザーが一定程度発生する。例えば秘密の質問などを要求する場合、秘密の質問を覚えていないユーザーが多いケースがあります。

先ほども述べましたが、ECサイトなどの場合、ユーザーにいかに簡単に商品やサービスを購入してもらうかが売上を向上させるための施策の一つとなりますが、二要素認証を導入した場合、ログインできないユーザーが発生するケースがあります。これはECサイトの目的と相反するところであり、私の経験から特に海外、主に北米ではログインの簡潔さを優先させて二要素認証の導入を進めないケースが多いです。その場合、対策としてはBot対策ソリューションがユーザーのログイン操作性を損なわないため最適であり導入されるケースが多いと思います。

 

また不正アクセス者自身のIDでログイン後に不正な行為を自動化されて生成されたリクエストで行う場合、リスクベース認証と二要素認証では防ぐことはできません。あくまでリスクベース認証と二要素認証はアカウント乗っ取りを防ぐためであり、自動化されたリクエストを検出するためのソリューションではないので注意が必要です。

ログインだけがターゲットではないAutomation Requestを利用した不正行為

IDパスワードリスト型攻撃はあくまでもログインアプリケーションを攻撃対象としますが、自動化され送信されたリクエストはログイン以外にも送信されます。ECサイトで確認されるケースが多いですがログイン後に限定商品の買い占めのために「カート追加」の操作を自動化したり、不正に取得したクレジットカード番号とセキュリティーコードの組み合わせをクレジットカード登録アプリに自動化してリクエストを送信して利用できる組み合わせを確認するなどの行為があります。ログイン後にも自動化されたリクエストを利用した不正な行為が行われていることに注意が必要です。

まとめ

  • IDパスワードリスト型攻撃は攻撃者が不正取得したリクエストを自動化して大量のIDとパスワードの組み合わせを試行する攻撃のこと。その目的はアカウント乗っ取りにより個人情報の取得、不正購買、不正送金などがある。
  • IDパスワードリクエスト攻撃は大量の自動化されたリクエストにより実行されるため自動化されて生成されたリクエスト(Botからのリクエスト)を検出することで防御できる。
  • 自動化されて送信されるリクエストから防御するためにはIPアドレスや送信元の国を指定した方法は適切ではない。IPアドレスはOpenプロキシなどの方法により簡単に複数のIPをローテーションさせて送信できる。またAWS, Azureを始めとしたクラウドサービスやホスティングサービスを利用して送信してくるため送信元の国を指定したフィルタも適切ではない。
  • Google reCAPTCHAなどに代表されるキャプチャ認証は一定の抑止効果はあるが技術的にバイパスできるため、高度にスキルがあり金銭的なモチベーションのある攻撃者には通用しない。また複雑なキャプチャ認証はユーザーに煩わしさを感じさせてしまいログインからの離脱を助長するため注意か必要です。
  • 自動化され送信されたリクエストへの対策はBot対策サービスの利用が推奨される。クライアント上でのユーザの操作シグナルから人かBotかの判定が正確に行える。
  • WAAP(Web Application and API protection)という新しいWebアプリケーション保護の考え方がガートナーより提唱されており、その中でBot対策の必要性も説明されている。
  • Bot対策サービスを導入してもRetooling(リツーリング)により設定済みのルールで検知できない場合がある。その場合は継続的にルールのチューニングを覚悟するか、継続的なルールチューニングも提供されるBot対策サービスの利用を検討する。
  • 二要素認証とリスクベース認証の導入によるIDパスワードリスト型攻撃の検出は検討できる対策となり得るかもしれない。ただ導入によりユーザーにはログインに煩わしさを発生させるため注意が必要。また、不正アクセス者自身のIDを利用してログイン後に自動化されたリクエストで不正行為を行う場合は防御できない。
  • 自動化されて送信される不正なリクエストはログインだけがターゲットではなくECサイトなどではログイン後のカート追加アプリやクレジットカード登録アプリなどがターゲットとなる。

IDパスワードリスト型攻撃について振り返りましたが、Automation Requestは不正な行為を行うための方法として広く利用されています。これから新規にWebアプリケーションやMobileのAPIエンドポイントを開発、公開する場合も、既に運用されている場合もAutomation Request(Botからのリクエスト)を可視化・検出できるソリューションの導入は検討すべき必須のセキュリティー対策・不正行為対策と思います。