ハロウィーンが10月に行われるのは偶然ではありません。 私たち人間は、この時期になると恐怖感を強く感じます。これは、日が短くなることに対する一種の痕跡的な反応です。 ウォール街で原因不明の市場暴落が最も多かった月は何月ですか? 10月。 もしハロウィンがもともと10月でなかったら、もっと自然に感じられる場所に移動していたでしょう。 10 月はサイバーセキュリティ啓発月間でもあります。
つまり、今週は「OMG、インターネットが壊れている!」という恐ろしいプロトコル脆弱性が 1 つではなく、「OMG、インターネットが壊れている!」という脆弱性が 2 つ発生したというのは、二重に完璧です。 なんと10月16日月曜日、同日にリリースされました。
さらに悪いことに、後でわかるように、脆弱性が互いに悪影響を及ぼし合う可能性も考えられます。
ベルギーのセキュリティ研究者 Mathy Vanhoef 氏は、WPA2 認証プロトコルを使用する WiFi クライアントに対する攻撃を公開しました。 ターゲット クライアントは、重複した WiFi ネットワークに参加するように騙され、ヌル (空白) の暗号化キーをインストールするよう強制され、攻撃者が中間者攻撃の立場をとることが可能になります。
Vanhoef 氏は、ブランドロゴ付きの脆弱性サイトkrackattacks.comで、KRACK 攻撃について簡潔に説明しています。 Vanhoef 氏が作成した、攻撃を実演する短いビデオをぜひご覧ください。
攻撃者がクライアントとアクセス ポイントの間に中間者ポジションを確立すると、古き良き sslstrip ツールを使用してクライアント ブラウザーを騙し、パスワードを暗号化せずに送信させることができます。 この例では、match.com の認証情報を(楽しみのために)使用しているため、Vanhoef は元恋人のデート習慣をスパイするために必要なすべての情報を提供したことになります。 ハロウィンに間に合いました![冗談です、そんなことはしないでください。]
賢明な読者は、「安全でないネットワークのために SSL 保護があるんだ!」と考えるでしょう。 だから僕たちはまだ安全だよね?」
さて、偶然にも KRACK と同じ日に公開されたもう 1 つの恐ろしい脆弱性は、高度に安全な暗号デバイスから生成される弱いキーに関係しています。 うわっ!
最新の SSL/TLS 脆弱性は ROCA (Return of Coppersmith's Attack) です。 Ars Technica は、ROCA の範囲と影響について、これまで見た中で最も優れた記事を掲載しています。 ROCA は、Infineon ソフトウェアが 2 つの大きな素数を近似するために「高速素数」と呼ばれる近道を試みる時間制限のある状況で実行される公開/秘密 RSA キー生成に影響します。
ROCA は、スマート カードや組み込みの高セキュリティ (信頼できるコンピューティング) 環境でよく使用される Infineon チップセットに関連するソフトウェアに影響します。 今年は 10 月なので、もちろんこれらのチップセットは FIPS 140-2 および CC EAL 5+ 認定ハードウェアに搭載されています。どちらも、秘密鍵を秘密に保つために数万ドルを支払うソリューションです。 Infineon のバグにより、攻撃者が公開鍵 (公開されており、証明書などに埋め込まれているため、ほとんどの場合) を知ると、秘密鍵は事実上因数分解可能になります。
攻撃者が 2048 ビットの秘密鍵を解読するには、CPU 時間で 20,000 ~ 40,000 ドルかかります。 しかし、攻撃者が国家である場合、それは彼らにとって大きな抑止力にはなりません。 1024 ビットのキーを因数分解するコストはわずか約 50 ドルで、これはヤンキースの試合でビール 2 杯を飲むのと同じくらいのコストです。 F5 Labs の独自の調査によると、インターネット上でまだこれほど小さいキーを使用しているのはわずか 7% です。 ROCA のような攻撃こそが、私たち全員が 2048 ビットにアップグレードした理由ですよね? それは私たちにとって良いことだ。 ECC キーは脆弱ではありません。
これまでのところ、脆弱なキーの大部分はスマートカードに関連付けられていますが、研究者は少数の脆弱な TLS キーと Github キーを発見しています。 脆弱な 1024 ビット DNSSEC キーについてはまだ何も発表されていませんが、攻撃者が独自の悪意のあるゾーン データに署名できるため、これは恐ろしいことです。
興味深いことに、キーが ROCA に対して脆弱であるかどうかを確認するのは基本的に無料で即時に行えます。 公開鍵の係数が特定の方法で 38 個の小さな素数に適合する場合、脆弱である可能性があります。 ROCA の研究者は、SSL/TLS、IPSec、SSH キーを確認するためのオンラインツールとオフライン ツールの両方を提供しています。
脆弱性をチェックするのは非常に簡単なので、ROCA に対して脆弱なキーを使用してサイトにアクセスすると、ブラウザがすぐに警告を出すようになると予想されます。 最初に私たちからそれを聞いたのです。
これはハロウィーン映画の脚本を書くようなものです。 あなたが高セキュリティ環境(スパイ管理オフィス)にいると想像してください。 あなたの敵は世界最悪の敵です。S.P.E.C.T.R.E. かそれに似たものを想像してください。
工作員の 1 人が Windows 10 ラップトップをイスタンブール オフィスのワイヤレス ネットワークに接続します。 彼は、S.P.E.C.T.R.E. のカウンターエージェントが Wi-Fi を偽装し、CSA チャネルビーコンを彼のラップトップに送信していることを知りません。 数秒以内に、工作員のラップトップは、対抗エージェントのアクセス ポイントを経由してルーティングされます。 工作員は SSL/VPN (残念ながら F5 ではありません) を有効にして、本社にある極秘の企業データにアクセスします。
カウンターエージェントはすでに国家レベルの能力を利用して、ROCA の脆弱性から SSL/VPN の秘密鍵を抽出しています。 彼は、エージェントが極秘サーバーからダウンロードするすべてのものを復号化できます。 また、カウンターエージェントはあなたのエージェントのmatch.comパスワードを入手します。
この最悪のシナリオは起こり得ないと思いますか? もっと奇妙なことが起きています。[咳、<stuxnet>、咳、<eternal blue>]。
F5 Networks のハードウェアとソフトウェア: 脆弱ではありません。 F5 はワイヤレス事業には携わっていません。 理論的には当社の TMOS プラットフォームをアクセス ポイントとして使用することは可能ですが、ありがたいことにこれを実行する人はいません。 KRACK については、F5 Networks SIRT の公式 KRACK 声明を参照してください。
F5 Networks は間違いなく SSL/TLS キーのビジネスに携わっています。 ここでも、F5 の機器とソフトウェアは脆弱ではありません。 当社では、いくつかのアプライアンスで Infineon チップセットを使用していますが、そのキー生成は使用していません。 F5 Networks SIRT からの公式 ROCA 声明をご覧ください。
あなたの装備(KRACK): 脆弱ですが…KRACK は WiFi 接続のクライアント側を攻撃します。 したがって、ある意味では、アクセス ポイントにパッチが適用されているかどうかは、実際には重要ではありません。 いずれにせよ、アクセス ポイントにパッチを適用する必要がある (優れたセキュリティ プラクティス) ことに同意しますが、それだけではユーザーを KRACK から保護することはできません。 WPA2 WiFi パスワードを変更する必要はありません。パスワードは問題の原因にはならず、変更しても何も影響はありません。
あなたの装備(ROCA): 理想的には、企業に関連付けられているすべての SSL/TLS 証明書を把握しておく必要があります。 「理想的」と言うのは、これが当てはまることはほとんどないからです。現在では、事業部門は常に独自の証明書を持ち込んでいます。 堅牢で包括的な証明書管理ソリューションを導入している場合は、おそらくすでにこの問題を解決しているでしょう。 そうでない場合は、F5 のパートナーであるVenafi がネットワークをスキャンして SSL/TLS キーを検索できます。 証明書をすばやくスキャンする必要がある場合は、証明書の透明性プロジェクトのデータベース ( crt.sh ) にアクセスし、組織の証明書を検索します。 次に、ROCA テスト ツールを使用して、それらの公開キーが脆弱かどうかを確認します。
あなたの従業員。 Apple は数バージョン前のステルスパッチで iOS と MacOS を修正しました (まだどのバージョンかは明らかにされていません)。 Android および Linux クライアントが最も脆弱であるようです。 Microsoft クライアントも脆弱です。 KRACK にとって最優先事項は従業員です。
F5 のお客様には、KRACK と ROCA に対する 2 つの適切なセキュリティ ソリューションがあります。 1 つ目は、SSL/TLS の復号化と負荷分散を行う主要モジュールである F5 の BIG-IP Local Traffic Manager (LTM) を介したものです。 LTM キーは通常、ROCA に対して脆弱ではありません (他の場所で生成されて LTM にインポートされた場合を除きます。テスト情報については以下を参照してください)。
LTM は HTTP Strict Transport Security (HSTS) を強制することができ、これによりすべてのブラウザはアプリケーションに接続するときに常に SSL/TLS を使用するように指示されます。 チェックボックスです。 確認してください。 HSTS だけで KRACK の最悪の側面を軽減できます。
2 番目のより階層化された防御は、BIG-IP Access Policy Manager (APM) とそれに関連するエンドポイント製品である BIG-IP Edge Client です。 これらを組み合わせることで、エンドポイント保護と高度なポリシー エンジンを備えた安全な SSL/TLS VPN が作成され、従業員が企業リソースに安全に接続できるようになります。 Android、Windows、iOS、MacOS など、すべての一般的なプラットフォームをサポートしています。 APM にはフェデレーション機能も備わっているため、SSO を無料で利用できます。
特定の高セキュリティ環境のユーザーは、F5 製品の WebSafe および MobileSafe を使用している可能性があります。 WebSafe はサーバーの前でトランザクションを保護します。 後者は、前者に接続するより安全なアプリケーションを作成するためのモバイル ツールキット API です。 これら 2 つが提供できる最も適切な保護は、アプリケーション層暗号化 (ALE) です。 ALE は、一時的な RSA キーを使用して、ユーザー パスワードをネットワーク経由で送信する前に非対称的に暗号化します。 MobileSafe は DNS スプーフィング保護機能も提供しており、KRACK による中間者攻撃の阻止に役立ちます。
ハロウィーンの衣装を選ぶこと(提案:今年はクラーケンがぴったりかもしれません)以外にも、KRACK と ROCA の TODO リストに追加する項目がいくつかあります。
当社の脅威インテリジェンス サイトであるF5 Labsと開発者コミュニティであるDevCentral では、引き続きこれらのトピックを調査しており、必要に応じて追加の資料を公開する予定です。 2 つの脆弱性、または上記で説明した解決策についてさらに質問がある場合は、遠慮なくF5 の担当者にお問い合わせください。
関連して、F5 の DevCentral チームは KRACK の脆弱性についてさらに詳しく説明したビデオを投稿しており、追加の解説は次の F5 Labs の投稿でご覧いただけます。 BYOD ポリシーの KRACK をすり抜ける新たな脅威