最近、OTTストリーミングサービスに対するCredential Stuffing攻撃による脅威が 明らかになりました。 人気のあるストリーミングサービスの立ち上げから数時間のうちに、ユーザーアカウントがハッキングされ、割引価格で販売された。 この侵害はPRの課題へと変化し、何千もの加入者がソーシャルメディアを利用して、ロックされたアカウントアクセスやサービスのアクセシビリティの問題に対する不満を解消しました。
この経験が示すように、Credential-Stuffing攻撃はOTTセキュリティチームにとって新たな課題です。 無料トライアル、コードカット、独占コンテンツによって推進されるストリーミングサービスのサブスクリプションは、ユーザー情報の大規模なコレクションを生み出し、OTTサービスはデータ窃盗のターゲットとしてますます魅力的になっています。 侵害されたアカウントへのアクセスを再販することが、ハッカーの動機ではありません。 また、アドレス、電話、閲覧履歴、クレジットカードデータなど、侵害されたユーザーアカウントから貴重な個人情報を収集することもできます。 ハッカーはこの情報をダークウェブ全体で販売したり、ソーシャルエンジニアリングやフィッシング攻撃によってさらなる損害を与えたりする可能性があります。
Credential Stuffing攻撃のダメージゾーンは、ユーザーのプライバシーと財務への影響をはるかに超えています。 Credential Stuffing攻撃では、1時間あたり数百万件のログイン要求を自動化できるボットネットが使用され、アプリケーションインフラストラクチャに大損害を与えます。 成功率が低い場合でも、このような大量の要求はストリーミングプラットフォームの運用コストを押し上げる可能性があります。 CPUサイクル、メモリ、およびデータ入出力の追加料金は、時間の経過とともに増加します。 アプリケーションのバックエンド、特にクラウドでの管理コストが比較的高いことを考えると、バックエンドシステムに大きく依存するログイン要求が最も高価な攻撃となります。 最終的に、チェックされていない悪質なアクティビティが高レベルであると、コンテンツの認証、閲覧、ストリーミングを試みる正規ユーザーのサービスが低下します。
ストリーミングサービスは、この増大する脅威をどのように無力化できるのでしょうか。 この技術記事では、今日の世界でボットを管理するために必要なことと、Credential-Stuffing攻撃の影響を最小限に抑え、その可能性を低減するためにストリーミングサービスに必要なことについて説明します。
Credential Stuffing攻撃の構造
サイバー犯罪者は、不正な構成のデータベースの検出、フィッシング攻撃、マルウェアによるユーザーのデバイスへの感染、ダークウェブ上でのハッキングされた資格情報の購入など、盗まれた資格情報を取得することで、資格情報の盗み取り攻撃を開始できます。 次に、攻撃者は分散プロキシサーバーを介して無数のログイン要求をルーティングし、攻撃元を隠し、要求を増幅します。 犯罪者は、ダークウェブフォーラムのボット飼い主から、手ごろな時間料金でプロキシサービスへのアクセスを購入できます。 最後に、攻撃者は、侵害された資格情報のリストを使用して認証要求を自動化するスクリプトを作成します。通常、再利用されたパスワードや単純なパスワードを利用して、サービスにアクセスします。 攻撃者は、既存の防御策を打ち消すために、CAPTCHAソルバ、ブラウザエミュレータ、指紋なりすましスクリプトなどのダークウェブ上のツールキットを購入することもあります。
Credential Stuffing攻撃に対する防御
このような攻撃を阻止するには、ボットと人間を区別する能力が必要です。 残念ながら、ボットオペレーターは、ボット検出方法を回避するための新しい方法を絶えず見つけています。 最新世代のボットは、人間とほとんど区別がつきません。
ボットが高度化するにつれて、ボットのリクエスト、IPアドレス、ユーザーエージェント(UA)をブロックするなど、過去に機能していた可能性のある単純な緩和戦略では、もはや十分ではありません。 今日の攻撃者は、静的IPから攻撃する代わりに、安価で豊富なローテーションIPプロキシサービスを使用している可能性が高く、レート制限と単純なアクセスコントロールリスト(ACL)保護を回避するのに役立ちます。 さらに、ブロッキングはボットオペレーターにとって有用なフィードバックメカニズムとして機能し、自動化を進化させて検出方法を無効にするように指示するため、お勧めできません。
ボット攻撃の巧妙化に対応するために、ボット検出技術はさらに高度化する必要がありました。 今日の最先端のボット検出技術には、サーバー側とクライアント側の両方で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をポイントするスクリプトタグを挿入することもできます。 JSは、クライアント側でチェックを実行し、JSまたはCookieが有効になっているかどうかなどのデバイス情報を収集し、OS、キャンバス、レンダラー、ブラウザ、JSエンジン、 完全なクライアントフィンガープリントを生成するには、さらに多くの機能があります。
通常のブラウザは、Cookieをサポートし、JSを有効にしていることが期待されます(これにより、正しくログインしてストリーミングサービスを使用できます)。有効にしていないと疑念が生じる可能性があります。 クライアントフィンガープリントでは、SafariブラウザUA with Blink(ブラウザエンジン)やChrome with SpiderMonkey JSエンジンなど、広告されたデバイスには典型的ではない疑わしい要素を特定できます。
これらの詳細は収集され、API呼び出しとしてリモートサーバーにビーコンで送信してさらに分析したり、暗号化してCookieまたはヘッダーとして設定し、後続のクライアントリクエストで分析することができます。 クライアントフィンガープリントを収集および生成するための上記のテクニックは、異なるSDKを介してiPhone/Androidアプリ、Roku、Samsung TVなどの非ブラウザーストリーミングアプリケーションにも採用できます。
図2. 一意のクライアントフィンガープリントを作成するために連携できる特性の小さなサンプル。
初期世代のボットでは、リクエストとクライアントフィンガープリントの組み合わせが効果的でしたが、より高度なボットはChrome、Firefox、Safariなど、人間と同じクライアントに基づいています。 また、ヘッドレスChromeのようなヘッドレスブラウザを採用することもあります。 JavaScriptやCookieのサポートなどの機能を欠いている可能性のある基本的なボットとは異なり、より高度なボットは適切なブラウザとJSエンジンを使用して、デバイスタイプに合わせて適切に形成されたTCPおよびTLSハンドシェイクおよびHTTPリクエストを実行できます。
数千のIPアドレスを介して要求を分散させることで、低攻撃と低速攻撃を実行でき、レートベースの検出方法を無効にできます。 問題をさらに複雑にするために、実際のユーザーデバイスからの実際のブラウザが乗っ取られ、資格情報の盗み取りアクティビティに使用される可能性があります。このような攻撃は、これらのアプローチだけでは見逃されることはほぼ確実です。
攻撃検出方法3:行動フィンガープリント
Credential Stuffingに真に対抗するには、インテリジェントな行動フィンガープリントを追加する必要があります。 ユーザーがストリーミングサービスを操作するとき、ユーザーはコンテンツのリクエストを行うだけでなく、アプリ内を移動、クリック、タップ、ブラウズしています。 ビヘイビアフィンガープリントは、クライアント側(通常はJS経由)でユーザーテレメトリーデータを収集することで、これらのアクションを調査します。 これには、マウスの動きパターン、キーストローク、アクションのタイミング、さらには携帯電話の加速度計やジャイロスコープなどのデバイスセンサーをタップしてユーザーの移動パターンと位置を測定することも含まれます。
収集されたデータに基づいて、行動フィンガープリントが生成され、リアルタイムまたはオフライン分析のために送信されます。 ユーザーはランダムなパターンまたは非有機的なパターンを示していますか? マウスは直線的なパターンで移動していますか、それとも人間よりもスクロール速度が速いですか? ブラウジングセッション全体を通して、電話機は常に固定角度になっていますか? 1秒あたりのログイン要求数は人間的に可能ですか?
これは、機械学習技術を使用してデータを継続的に分析し、要求が自動化されているかどうかに関するインテリジェンスを導き出す必要があるデータサイエンティストや研究者の戦場です。 これは、収集された要求、デバイス、および動作属性の組み合わせが指数関数的に増加したことによるものです。 ボットは行動ハイジャックによって人間の行動を模倣する能力を向上させたため、マウスの動きなどの基本的な行動特性に依存することはもはや適切ではなく、偽陽性率を高め、実際のユーザーの体験に影響を与える可能性があります。
これらのタイプのボットは、Credential Stuffingを軽減するための最も困難な課題です。 最も洗練されたボットを停止するには、クライアントの意図を分析し、リクエストが悪意のあるものであるかどうかを特定するために、セッション中のクライアントの閲覧行動など、より多くのデータが必要です。 たとえば、ユーザーがホームページを通過せずにストリーミングサービスのログインページに直接アクセスした場合、通常の動作ですか? ユーザーがストリーミングサービスにログインした後すぐにアカウントページに移動し、他の操作を実行しないのは正常ですか? これらのデータポイントは、ボットの意図を正確に特定することができます。 セッション全体を通じてストリーミングサービスとユーザーがやり取りすることで、より豊かで完全なフィンガープリントが生成され、誤検出の可能性が低くなります。
ボットの管理
ボットがログインリクエストを作成しようとしていることを正常に検出したら、正しい応答は何ですか? ロボットをブロックして消えることを期待するのでしょうか? ほとんどの場合、それは間違った行動です。 たとえば、401 Unauthorized Responseなどの4xxエラーで応答するとします。 攻撃者は現在の不適切なテクニックを知っており、自動化ツールを更新して、試行錯誤を繰り返して検出メカニズムを克服します。 この場合、誤ってフィードバックループを提供して攻撃者に手法を進化させるよう警告し、攻撃者を助けてきました。
洗練されたボットオペレーターは、最終的に緩和されていることを検出し、メソッドを進化させることは避けられませんが、これらの取り組みを回避または遅らせるための優れたプラクティスがいくつかあります。 検出されると、ボットリクエストをブロックする代わりに、サーバーはログイン試行が成功したときに、機密データを公開しない静的定型定型応答と組み合わせて、200 OKなどの標準の予想される応答コードを送信できます。
ボットオペレーターは、応答が成功した場合、現在のメソッドが成功したことを示していると想定していない可能性が高くなります。 そして、盗まれた資格情報は、そうではないかもしれないにもかかわらず、攻撃者を暗闇に閉じ込めるのに役立ちます。 もう1つのオプションは、応答を提供せず、ボットリクエストをタイムアウトするまでハングしたままにして、ボットリクエストを停止することです。 これは、コンテンツ・デリバリー・ネットワーク(CDN)など、サーバー容量が多く、グローバルに分散された大規模なプラットフォームを使用している場合に実行できます。 これらの誤った情報の方法は、単にボットリクエストをブロックするよりも効果的です。
ボットを管理するためのもう1つの戦略は、誤検知が発生した場合のユーザー体験への影響が少ないため、ボットの疑いがある場合にCAPTCHAを解決する必要があります。 CAPTCHAを完了した後にのみ、ログインが成功します。 これにより、実際のユーザーはボットと誤認されても継続できます。 また、検出方法を調整して誤検出を減らすための貴重なフィードバックも提供します。
ストリーミングを安全に保つ
Credential Stuffing攻撃の防止は、OTTストリーミングサービスにとって重要な優先事項です。 これらのサービスが普及するにつれて、セキュリティリスクも高まります。 アプリケーションのセキュリティとボット管理に対するマルチレイヤーアプローチにより、 Credential Stuffing攻撃に使用される最も高度なボットでさえ正確に特定し、そのような攻撃がカスタマーエクスペリエンスや評判に影響を与えるのを防ぐことができます。
Akamaiのクラウドセキュリティ機能が、Credential-Stuffing攻撃やDDoS攻撃などからオンラインプレゼンスを保護する方法について詳しく説明します。