Home 技術記事 Credential Stuffing攻撃からOTTサービスを保護する方法
Applications

Credential Stuffing攻撃からOTTサービスを保護する方法

About The Author

Outline

OTTストリーミングサービスに対するCredential Stuffing攻撃による脅威は最近明らかになった。 人気のストリーミングサービスの立ち上げから数時間以内に、ユーザーアカウントがハッキングされ、割引価格で販売された。 この侵害はPRの課題に発展し、何千人もの加入者がロックされたアカウントアクセスとサービスのアクセシビリティの問題に対する不満を発散するためにソーシャルメディアに目を向けた。

この経験が示すように、Credential-Stuffing攻撃はOTTセキュリティチームにとって新たな課題である。 無料トライアル、コードカット、限定コンテンツによって推進されたストリーミングサービスのサブスクリプションは、大量のユーザー情報を生成し、OTTサービスはデータ窃盗のターゲットとしてますます魅力的になっている。 侵害されたアカウントへのアクセスを再販することだけがハッカーの動機ではない。 また、侵害されたユーザーアカウントから、住所、電話、閲覧履歴、クレジットカードデータなどの貴重な個人情報を盗み出すこともできる。 ハッカーはダークウェブ上でこの情報を販売したり、ソーシャルエンジニアリングやフィッシング攻撃を通じてさらなる損害を引き起こす可能性がある。

Credential Stuffing攻撃のダメージゾーンは、ユーザーのプライバシーと財務への影響をはるかに超えている。 Credential Stuffing攻撃では、1時間に数百万件のログイン要求を自動化できるボットネットが使用され、アプリケーションインフラストラクチャに大混乱をもたらす。 成功率が低い場合でも、このような大量のリクエストはストリーミングプラットフォームの運用コストを上昇させる可能性がある。 余分なCPUサイクル、メモリ、およびデータ入力/出力手数料は時間の経過とともに増加する。 アプリケーションのバックエンド、特にクラウドの管理コストが比較的高いため、バックエンドシステムに大きく依存するログイン要求が最もコストのかかる攻撃となる。 最終的には、チェックされていない不正なアクティビティが高レベルで行われると、コンテンツの認証、閲覧、ストリーミングを行おうとする正当なユーザーのサービスが低下する。

ストリーミングサービスは、この増大する脅威をどのように無力化できるか? この技術記事では、今日の世界でボットを管理するために必要なものと、Credential-Stuffing攻撃の影響を最小限に抑え、可能性を減らすためにストリーミングサービスに必要なものについて説明する。

Credential Stuffing攻撃の構造

サイバー犯罪者は、誤った構成のデータベースの発見、フィッシング攻撃、ユーザーのデバイスへのマルウェアの感染、ダークウェブ上でのハッキングされた資格情報の購入など、盗まれた資格情報を取得することで、資格情報の盗み出し攻撃を開始することができる。 次に、攻撃者は無数のログイン要求を分散プロキシサーバ経由でルーティングし、攻撃元を隠し、要求を増幅する。 犯罪者はダークウェブフォーラムのボット遊牧民からプロキシサービスへのアクセスを手頃な時給で購入することができる。 最後に、攻撃者は、侵害された資格情報のリストを使用して認証要求を自動化するスクリプトを作成し、通常は再利用されたパスワードや単純なパスワードを餌食にして、サービスにアクセスする。 攻撃者はCAPTCHAソルバ、ブラウザエミュレータ、指紋なりすましスクリプトなどのツールキットをダークウェブ上で購入し、既存の防御に対抗することもある。

Credential Stuffing攻撃に対する防御

このような攻撃を阻止するには、ボットと人間を区別する能力が必要である。 残念なことに、ボットオペレーターはボット検出方法を回避する新しい方法を絶えず見つけている。 最新世代のボットは人間とほとんど区別がつかない。

ボットがより洗練されたものになるにつれて、ボットのリクエストをブロックするなど、過去に機能していた可能性のある単純な緩和戦略ではもはや十分ではない。 今日の攻撃者は、静的IPからの攻撃ではなく、安価で豊富なローテーション型IPプロキシサービスの1つを使用している可能性が最も高い。これは、レート制限と単純なアクセス制御リスト(ACL)保護を回避するのに役立つ。 さらに、ブロッキングはボットオペレーターにとって有用なフィードバックメカニズムとして機能し、検出方法を無効にするために自動化を進化させるように指示するため、推奨されない。

ボット検出技術は、ボット攻撃の巧妙化に対応するために、より洗練されたものになっている。 今日の最先端のボット検出技術には、サーバー側とクライアント側の両方で3つの分析形式が含まれている。 それらは次のとおりである。

  1. フィンガープリントを要求する
  2. クライアントフィンガープリント
  3. 動作フィンガープリント

巧妙なCredential Stuffing攻撃に対抗するには、これら3つの組み合わせが必要になる。

攻撃の検出方法1:フィンガープリントを要求する

要求フィンガープリントは通常、サーバが要求された情報をすべてクライアントから受け取るとすぐにサーバ側で行われる。 クライアント要求は通常、ネットワーク(IP)、接続、暗号化、および要求フィンガープリントを生成するために分析され使用される他のHTTPメタデータの組み合わせで構成される。 このフィンガープリントには、IPアドレス、TCPハンドシェイク、TLSハンドシェイク(TLSプロトコル、暗号、拡張など)、HTTPヘッダーとヘッダーの順序、およびメタデータから派生したその他の情報(ASNやデバイスタイプなど)が含まれる。 これらの要求特性を組み合わせることで、クライアントごとに固有の署名やフィンガープリントを生成できる。

図1。 一意の要求フィンガープリントを作成するために連携できる要求特性の小さなサンプル。

指紋から異常を探すことができる たとえば、リクエストがChrome UAからのものであると主張する場合、ユーザーエージェントに示されているように、そのバージョンのChromeブラウザで期待される順序でヘッダーが含まれるかどうか。 一般的なHTTPプロトコルとTLSプロトコルを使用しているか。 ClientHelloメッセージには、このChromeバージョンに典型的な優先順位のプロトコルと暗号が含まれているか。 リクエストメタデータの分析に加えて、サーバーはリクエストの数や頻度、リクエストが自動化されているかどうかを判断するのに役立つ閲覧パターンがあるかどうかなど、限られた行動分析も実行できる。

フィンガープリントを要求することは必要な最初のステップであるが、それ自体では不十分である。

攻撃の検出方法2:クライアントフィンガープリント

要求フィンガープリントの課題は、攻撃者が要求フィンガープリントを偽装できることであり、要求フィンガープリントは、実際のクライアントと100%同一に見えることが多い。 攻撃者が間違いを犯した場合、フィンガープリントを要求することでその間違いを特定できるが、定期的に発生することは期待できない。

基本的に、要求のフィンガープリントは話の半分しか伝えられない。 サーバはクライアント側で何が起こっているかを確認し、クライアントフィンガープリントを生成して要求フィンガープリントを補完し、より多くの洞察を得る必要がある。 これにより、ボット検出システムはクライアントの全体像をより完全に把握できるようになり、攻撃者が検出を回避することが困難になる。

クライアントフィンガープリントサーバは、要求されたページに応答してHTMLを書き換えることによって、クライアント側で実行する小さなJavaScript (JS)を注入することができる。 あるいは、サーバーは、クライアントがログインページをロードするときにダウンロードできるリモートJSを指すscriptタグを注入することもできる。 JSはクライアント側でチェックを行い、JSやクッキーが有効になっているかどうかなどのデバイス情報を収集し、OS、キャンバス、レンダラ、ブラウザ、JSエンジンなどを調べて完全なクライアントフィンガープリントを生成する。

通常のブラウザではクッキーのサポートがあり、JSが有効になっていることが期待されている(適切にログインしてストリーミングサービスを使用できるようにするため)。有効にしていないと疑惑を引き起こす可能性がある。 クライアントフィンガープリントは、偽装クライアントの可能性を示す可能性のある広告されたデバイスに典型的ではない他の疑わしい要素を識別することができる。たとえば、Blink(ブラウザエンジン)を搭載したSafariブラウザUAや、SpiderMonkey JSエンジンを搭載したChromeなど。

これらの詳細は収集され、さらなる分析のためのAPI呼び出しとしてリモートサーバーにビーコン送信されるか、暗号化され、後続のクライアント要求で分析のためにサーバーに送信されるクッキーまたはヘッダーとして設定される。 クライアントフィンガープリントを収集し生成する上記の技術は、異なるSDKを介してiPhone/Androidアプリ、Roku、Samsung TVなどの非ブラウザストリーミングアプリケーションにも採用できる。

図2。 一意のクライアントフィンガープリントを作成するために連携できる特性の小さなサンプル。

リクエストとクライアントフィンガープリントの組み合わせは初期世代のボットでは効果的だったが、より高度なボットはChrome、Firefox、Safariなど人間と同じクライアントをベースにしている。 また、ヘッドレスChromeのようなヘッドレスブラウザを採用することもある。 JavaScriptやCookieのサポートなどの機能を欠く可能性のある基本的なボットとは異なり、より高度なボットは適切なブラウザとJSエンジンを利用して、デバイスタイプに応じて適切に形成されたTCPとTLSのハンドシェイクとHTTPリクエストを実行できる。

低速攻撃と低速攻撃は、数千のIPアドレスを介して要求を分散し、レートベースの検出方法を無効にすることで実行できる。 問題をさらに複雑にするために、実際のユーザーデバイスからの実際のブラウザがハイジャックされ、クレデンシャルスタッフィング活動に使用される可能性があり、このような攻撃はこれらのアプローチだけでは見逃されることはほぼ確実である。

攻撃の検出方法3:動作フィンガープリント

Credential Stuffingを真に打つには、インテリジェントな行動フィンガープリントを追加する必要がある。 ユーザーがストリーミングサービスを利用する際には、単にコンテンツのリクエストを行うだけでなく、アプリを移動したり、クリックしたり、タップしたり、ブラウジングしたりしている。 Behavioral Fingerprintingは、クライアント側(通常はJS経由)でユーザーのテレメトリデータを収集することで、これらのアクションを研究する。 これらには、マウスの動きのパターン、キーストローク、アクションのタイミング、さらには携帯電話の加速度計やジャイロスコープなどのデバイスセンサーをタップしてユーザーの動きのパターンや位置を測定することも含まれる。

収集されたデータに基づいて行動フィンガープリントが生成され、リアルタイムまたはオフライン分析のために送信される。 ユーザーがランダムまたは非オーガニックパターンを示しているか。 マウスは直線的なパターンで動いているのか、それともスクロール速度は人間が達成できる速度より速いのか。 ブラウジングセッション全体を通して、電話機は常に固定度の角度になっているか? 1秒あたりのログイン要求の数は人間が可能か?

これはデータサイエンティストと研究者の戦場であり、継続的にデータを分析し、要求が自動化されているかどうかのインテリジェンスを引き出すために機械学習技術を使用しなければならない。 これは、収集された要求、デバイス、および動作属性の組み合わせが指数関数的に増加したことによるものである。 ボットは行動ハイジャックによって人間の行動を模倣する能力を向上させたため、マウスの動きなどの基本的な行動特性に依存することはもはや十分ではなく、偽陽性率を高め、実際のユーザーの体験に影響を与える可能性がある。

これらのタイプのボットは、Credential Stuffingを軽減するための最も難しい課題となっている。 最も洗練されたボットを停止するには、クライアントのインテントを分析し、リクエストが悪意のあるものかどうかを特定するために、セッション全体でのクライアントの閲覧行動など、より多くのデータが必要になる。 例えば、ユーザーがホームページを通さずにストリーミングサービスのログインページに直接アクセスした場合の正常な動作か。 ユーザーがストリーミングサービスにログインした後、すぐにアカウントページに移動し、他のアクションを実行しないのは正常か。 これらのデータポイントは、ボットの意図を正確に識別できる。 セッション全体を通してストリーミングサービスとのユーザーのやり取りやその他の行動データは、より豊かで完全なフィンガープリントを生成し、誤検知の可能性を低くすることができる。

ボットを管理する

ログインリクエストを作成しようとしているボットを正常に検出したら、正しい応答は何か? ボットをブロックして消えることを願うのか? ほとんどの場合、それは間違った行為である。 401 Unauthorized responseのような4xxエラーで応答するとする。 攻撃者は現在の不適切な手法を知っており、自動化ツールを更新して、試行錯誤によって検出メカニズムを克服する。 このケースでは、攻撃者に方法を進化させるように警告するフィードバックループを提供することで、意図せず攻撃者を助けてしまった。

洗練されたボット運用者は、最終的に自分たちが緩和されていることを発見し、手法を進化させることは避けられないが、これらの取り組みを回避または遅らせるための良いプラクティスがいくつかある。 検出されると、ボットリクエストをブロックする代わりに、サーバーはログイン試行が成功したときに200 OKなどの標準的な期待されるレスポンスコードを、機密データを公開しない静的な定型レスポンスと組み合わせて送信できる。

ボットオペレーターは、応答が成功した場合、現在のメソッドが成功したことを示していると仮定しない可能性が高い。 そして、盗まれた資格情報は、そうではないかもしれないが有用であり、攻撃者を暗闇に閉じ込めること。 もう1つの選択肢は、応答を提供せずにBotリクエストをターピット処理し、タイムアウトするまでBotリクエストをハングさせたままにすることである。 これは、コンテンツ・デリバリー・ネットワーク(CDN)のような、サーバー容量が大きい大規模なグローバル分散プラットフォームを使用する場合に可能である。 これらの誤情報の方法は、ボットリクエストを単にブロックするよりも効果的である可能性が高い。

偽陽性が発生した場合のユーザーエクスペリエンスへの影響が少ないボット管理の別の戦略では、疑いのあるボットがCAPTCHAを解決する必要がある。 CAPTCHAが完了した後にのみログインが成功する。 これにより、実際のユーザーがボットと誤認されても継続できる。 また、誤検出を減らすために検出方法を調整するための貴重なフィードバックも提供する。

ストリーミングを安全に保つ

Credential Stuffing攻撃を防ぐことは、OTTストリーミングサービスにとって重要な優先事項である。 これらのサービスが人気を得ると同時に、セキュリティ上のリスクもする。 アプリケーションセキュリティとボット管理に対する多層アプローチは、Credential Stuffing攻撃の強化に使用される最も洗練されたボットでさえも正確に特定し、そのような攻撃が顧客体験や評判に影響を与えるのを防ぐことができる。

Credential Stuffing攻撃、DDoS攻撃などからオンラインプレゼンスを保護するクラウドセキュリティ機能の詳細。