Cloudbleed:対処方法

GoogleのProject ZeroのTavis Ormandy(Tavis Ormandy)は、Cloudflareインターネットインフラストラクチャサービスの主要な脆弱性を発見しました。基本的に、Cloudflare-backedサイトへのWebリクエストは、他のCloudflare-backedサイトからのランダムな情報を含む回答を受け取りました!この情報には、機密情報(出会い系サイトのプライベートメッセージ、電子メール)、ユーザーID情報(個人識別情報(PII)、および潜在的に医療コンテキスト、保護された健康情報(PHI)、またはユーザー、アプリケーション、またはデバイスの資格情報が含まれる可能性があります(パスワード、APIキー、認証トークンなど)

Project ZeroとCloudflareの両方がすぐに行動しました。バグは2017–02–17に報告され、1時間以内に緩和されました。公開通知は2017–02–23に行われました。

公開される情報の期間(2016–09–22から2017–02–20)と膨大な情報の可能性は膨大です— Cloudflareはネットワーク上に200万以上のWebサイトを持ち、これらのデータは潜在的に公開されます。 Cloudflareは、実際の影響は比較的小さいと言っているため、実際に広まったのは限られた量の情報だけだと思います。基本的に、広範囲のデータが潜在的にリスクにさらされていましたが、個々のデータに対するリスクは非常に低かったです。とにかく、データが侵害されていないことが最終的に示されない限り、データが侵害された可能性を考慮することは賢明です。

Cloudflareのサービスはこのバグを排除するために迅速にパッチが適用されましたが、データはこのポイントの前に数か月間絶えず漏れていました。このデータの一部は、Googleなどの検索エンジンで一般にキャッシュされており、削除されています。他のデータは、インターネット全体の他のキャッシュとサービスに存在する可能性があり、これらすべての場所で削除を調整することは明らかに不可能です。悪意のある誰かがこの脆弱性をTavisの前に単独で発見し、積極的に悪用している可能性が常にありますが、この理論を支持する証拠はありません。残念ながら、最終的に反証することも困難です。

漏洩する最も機密情報は、認証情報と資格情報です。このデータの侵害は、資格情報が取り消され置き換えられるまで、永続的かつ継続的な結果をもたらす可能性があります。

個々の観点から、これは簡単です。最も効果的な軽減策は、パスワードを変更することです。これはおそらく必要ではありませんが(このインシデントでパスワードが公開された可能性は低いです)、この潜在的な侵害と他の多くの、より可能性の高いセキュリティ問題の両方からセキュリティを完全に改善します。 Cloudflareは多くの最大規模の消費者Webサービス(Uber、Fitbit、OKCupidなど)の背後にあるため、Cloudflareにあるサービスを特定するのではなく、すべてのサイトですべてのパスワードをローテーションする機会としてこれを使用する。これによりセキュリティが向上しますが、主な利点はこのインシデントとは無関係の脅威から得られます。

(ベストプラクティスは、各サイトに固有の長いパスワードに長いランダム文字列を使用し、1Password、LastPass、または最新のWebブラウザーの組み込みのパスワードマネージャーなどの「パスワードマネージャー」を使用してそのコレクションを管理することです。また、この更新後にモバイルアプリケーションにログアウトしてログインする必要があります。その間、重要と思われるサイトで2FAまたは2SVを使用できる場合(TOTP / Google AuthenticatorまたはU2Fなどを使用)、それは意味のあることですセキュリティのアップグレードも。)

Cloudflareを使用するサイトオペレーターの場合:混乱を招く可能性がありますが、ユーザーへの影響を真剣に検討する必要があります。インシデント処理プロセスを実行する機会としてこのインシデントを使用します—アプリケーションへの具体的な影響と、最も意味のある応答について話し合います(サイトまたはアプリケーションごとに異なる可能性があります)。 。その他の費用。それらを「怖がらせない」ように注意してください。しかし、行動を起こすことは賢明かもしれません。少なくとも、このインシデントに関するサポートのための「ストックアンサー」を準備し、企業またはb2bのコンテキストで、インシデントの範囲とアプリケーションおよびデータへの影響について顧客と積極的にコミュニケーションを取ります。 Cloudflareの大部分のサイトでは、それだけで十分である可能性があります。

ユーザーパスワードの変更を強制するには非常に現実的なコストがかかります。ユーザーはサービスに対する信頼を失う可能性があり、不便です。多数の資格情報が侵害されているようには見えないため、侵害されたアカウントに対するリスクが限られている消費者サービスの場合、パスワードを大量に無効化して変更を強制する価値はありません。管理者の資格情報、またはCloudflareを介して非常に機密性の高い情報を処理するサイトの場合、定量化可能な最大露出の欠如は、おそらくパスワードの更新を強制する価値があることを意味します。パスワードの更新をすべてのユーザーにプッシュする理由が他にある場合、これはもちろん決定の追加要因になります。

サイトでは、モバイルアプリケーションやその他のマシン間通信(IoTデバイスなど)の認証資格情報を無効にして、ユーザーがインフラストラクチャプロバイダーとしてCloudflareを使用している場合、ユーザーにアプリとデバイスの再登録を強制する必要があります。パスワードの変更を強制したくない場合、実行可能な中間ステップは、認証トークンを無効にし、ユーザーに既存のパスワードで再度ログインさせることです。認証トークンはブラウザとサーバーの間でより頻繁に渡されるため、生のパスワードよりもサーバーからのランダムメモリのリークに存在する可能性がはるかに高く、ユーザーへの新しいログインの強制は最小限の影響であり、特定のメッセージングを必要としない場合がありますまたは通知。

さらに、Cloudflareにないが、Cloudflareがホストするサイト(本質的にはインターネット上の大規模サイトまたは消費者サイト)を使用するユーザーが多いサイトは、ユーザーが各サイトで同じパスワードを再使用した場合にユーザーパスワードの変更を強制することを検討する必要があります。これはおそらく大部分のサイトでは保証されていません(セキュリティニーズが非常に高いため、ユーザーパスワードよりもはるかに強力な認証インフラストラクチャを使用することをお勧めします。それ以外の場合、ほぼ確実なユーザーは、侵害されたサイトでパスワードを再利用します)が、可能性があります。個人的には、急いではなく、2FA(理想的にはU2F以上、またはSMSではなくユーザーが選択可能なTOTP / HOTP)を展開するような場合に、認証インフラストラクチャ全体をアップグレードする機会として使用します。パスワードを無効にするような変更。インターネット上のスタンドアロンパスワードは、ユーザー認証のベストプラクティスではなくなりました。

アプリケーションまたはWebサイトがCloudflare上にあり、業界または国の規制の対象である場合、これは報告可能なインシデントである可能性があります。 (例は、HIPAAを使用した医療/医療プライバシーの懸念です)。セキュリティおよびコンプライアンスチームが評価する必要があります。明らかに、適用される規制への完全な準拠は、セキュリティの重要な部分です。

主観的に、これは深刻なセキュリティ問題であり、Cloudflareを使用する主要なサービスで評価する必要があると思います。悪意のある悪用が協調していない限り、脆弱なデータはおそらくインターネット全体にかなりランダムに分散されるため、深刻度は「世界の終わり」ではない可能性がありますが、検索可能なキャッシュにデータが存在すると、小規模な悪用が可能になる可能性があります。エンドユーザーに対する緩和策は、一般的に適切なアドバイスであるため(パスワードマネージャーを使用し、サイトごとに一意のランダムパスワードを使用し、妥協を繰り返します)、セキュリティを重視するほとんどのエンドユーザーにとって「簡単」です。サイト運営者にとって、決定は実際に特定のユーザーベースと、セキュリティの洗練度とリスク許容度にかかっています。 GoogleのProject Zero(特にTavis)による進行中の作業と、この問題に対するCloudflareの迅速な対応の両方に深く感謝しています。