HTTPS に対する潜在的な攻撃とそれに対する防御方法

半分のサイト HTTPSを使用します、その数は着実に増加しています。 このプロトコルはトラフィック傍受のリスクを軽減しますが、攻撃の試み自体を排除するものではありません。 プードル、ビースト、ドロウンなど、それらのいくつかと保護方法については、資料の中で説明します。

/フリッカー/ スヴェン・グレアム / CC BY-SA

プードル

初めて攻撃について プードル 2014年に知られるようになりました。 SSL 3.0 プロトコルの脆弱性は、情報セキュリティの専門家である Bodo Möller 氏と Google の同僚によって発見されました。

その本質は次のとおりです。ハッカーは、接続の切断をエミュレートして、クライアントに SSL 3.0 経由で接続するよう強制します。 次に、暗号化されたファイル内を検索します CBC-traffic モードの特別なタグ メッセージ。 攻撃者は、一連の偽造リクエストを使用して、Cookie などの目的のデータの内容を再構築できます。

SSL 3.0 は時代遅れのプロトコルです。 しかし、彼の安全の問題は依然として重要だ。 クライアントは、サーバーとの互換性の問題を回避するためにこれを使用します。 いくつかのデータによると、最も人気のある 7 万サイトのうち、ほぼ 100% が 引き続きSSL 3.0をサポートします。 また 存在する より最新の TLS 1.0 および TLS 1.1 をターゲットとする POODLE への変更。 今年 出現した TLS 1.2 保護をバイパスする新しい Zombie POODLE および GOLDENDOODLE 攻撃 (これらは依然として CBC 暗号化に関連付けられています)。

自分自身を守る方法。 オリジナルの POODLE の場合、SSL 3.0 サポートを無効にする必要があります。 ただし、この場合、互換性の問題が発生するリスクがあります。 代替ソリューションとしては、TLS_FALLBACK_SCSV メカニズムが考えられます。これにより、SSL 3.0 を介したデータ交換が古いシステムでのみ実行されることが保証されます。 攻撃者はプロトコルのダウングレードを開始できなくなります。 Zombie POODLE および GOLDENDOODLE から保護する方法は、TLS 1.2 ベースのアプリケーションで CBC サポートを無効にすることです。 根本的な解決策は、TLS 1.3 への移行です。新しいバージョンのプロトコルでは CBC 暗号化が使用されません。 代わりに、より耐久性の高い AES と ChaCha20 が使用されます。

BEAST

1.0 年に発見された、SSL および TLS 2011 に対する最初の攻撃の XNUMX つ。 プードル、ビーストのように 使用する CBC暗号化の特徴。 攻撃者は、JavaScript エージェントまたは Java アプレットをクライアント マシンにインストールし、TLS または SSL 経由でデータを送信するときにメッセージを置き換えます。 攻撃者は「ダミー」パケットの内容を知っているため、それを使用して初期化ベクトルを復号化し、認証 Cookie などの他のメッセージをサーバーに読み取ることができます。

現在のところ、BEAST の脆弱性は残っています 多くのネットワーク ツールが影響を受けます: ローカル インターネット ゲートウェイを保護するためのプロキシ サーバーとアプリケーション。

自分自身を守る方法。 攻撃者はデータを復号化するために定期的なリクエストを送信する必要があります。 VMware の場合 推奨する SSLSessionCacheTimeout の期間を 30 分から (デフォルトの推奨) 2020 秒に短縮します。 このアプローチは、パフォーマンスに多少の悪影響を及ぼしますが、攻撃者が計画を実行することをより困難にします。 さらに、BEAST の脆弱性自体が間もなく過去のものになる可能性があることを理解しておく必要があります。XNUMX 年以降、最大手のブラウザーは 停止 TLS 1.0 および 1.1 のサポート。 いずれにしても、これらのプロトコルを使用しているブラウザ ユーザーは全体の 1,5% 未満です。

溺れる

これは、2 ビット RSA キーを使用した SSLv40 実装のバグを悪用するクロスプロトコル攻撃です。 攻撃者はターゲットの何百もの TLS 接続をリッスンし、同じ秘密キーを使用して特別なパケットを SSLv2 サーバーに送信します。 使用する ブライヘンバッハーの攻撃、ハッカーは約 XNUMX のクライアント TLS セッションのうちの XNUMX つを復号化できます。

DROWN は 2016 年に初めて知られましたが、その後、 サーバーの XNUMX 分の XNUMX が影響を受ける 世界で。 今日でもその関連性は失われていません。 最も人気のある 150 万のサイトのうち、2% が依然として 支える SSLv2 と脆弱な暗号化メカニズム。

自分自身を守る方法。 暗号化ライブラリの開発者が提案する、SSLv2 サポートを無効にするパッチをインストールする必要があります。 たとえば、OpenSSL に対してそのようなパッチが 2016 つ提供されました (XNUMX 年) これらは更新でした 1.0.1s および 1.0.2g)。 また、脆弱なプロトコルを無効にするためのアップデートと手順は、 レッドハット, アパッチ, Debianの.

「メール サーバーなど、SSLv2 を使用するサードパーティ サーバーでリソースのキーが使用されている場合、リソースは DROWN に対して脆弱になる可能性があります」と開発部門の責任者は述べています。 IaaS プロバイダー 1cloud.ru セルゲイ・ベルキン。 — この状況は、複数のサーバーが共通の SSL 証明書を使用している場合に発生します。 この場合、すべてのマシンで SSLv2 サポートを無効にする必要があります。」

特別なツールを使用して、システムを更新する必要があるかどうかを確認できます。 ユーティリティ — DROWN を発見した情報セキュリティの専門家によって開発されました。 このタイプの攻撃に対する保護に関する推奨事項の詳細については、次の記事を参照してください。 OpenSSL Web サイトに投稿する.

ハートブリード

ソフトウェアにおける最大の脆弱性の XNUMX つは、 ハートブリード。 これは 2014 年に OpenSSL ライブラリで発見されました。 バグ発表時点での脆弱な Web サイトの数 XNUMX万と見積もられた - これは、ネットワーク上の保護されたリソースの約 17% に相当します。

この攻撃は、小さな Heartbeat TLS 拡張モジュールを通じて実装されます。 TLS プロトコルでは、データが継続的に送信されることが必要です。 ダウンタイムが長引くと、切断が発生し、接続を再確立する必要があります。 この問題に対処するために、サーバーとクライアントはチャネルに人為的に「ノイズ」を与えます (RFC 6520、5 ページ)、ランダムな長さのパケットを送信します。 それがパケット全体より大きい場合、OpenSSL の脆弱なバージョンは、割り当てられたバッファを超えてメモリを読み取ります。 この領域には、秘密暗号化キーや他の接続に関する情報など、あらゆるデータが含まれる可能性があります。

この脆弱性は、1.0.1 から 1.0.1f までのライブラリのすべてのバージョンに存在し、また、12.04.4 までの Ubuntu、6.5 より古い CentOS、OpenBSD 5.3 などの多くのオペレーティング システムにも存在しました。 完全なリストがあります Heartbleed 専用の Web サイトで。 この脆弱性に対するパッチは発見直後にリリースされましたが、この問題は現在でも関連性を持っています。 2017 年に遡ります 約200万サイトが稼働、ハートブリードの影響を受けやすい。

自分自身を守る方法。 必要 OpenSSLを更新する バージョン 1.0.1g 以降まで。 DOPENSSL_NO_HEARTBEATS オプションを使用して、ハートビート リクエストを手動で無効にすることもできます。 アップデート後は、情報セキュリティ専門家が 推奨する SSL証明書を再発行します。 暗号化キーのデータがハッカーの手に渡った場合に備えて、交換が必要です。

証明書の代替

正規の SSL 証明書を持つ管理対象ノードがユーザーとサーバーの間にインストールされ、トラフィックをアクティブに傍受します。 このノードは有効な証明書を提示することで正規のサーバーになりすまし、MITM 攻撃を実行することが可能になります。

による 探査 Mozilla、Google、および多くの大学のチームにより、ネットワーク上の安全な接続の約 11% が盗聴されています。 これは、ユーザーのコンピュータに疑わしいルート証明書がインストールされた結果です。

自分自身を守る方法。 信頼できるサービスを利用する SSLプロバイダー。 サービスを利用して証明書の「品質」を確認できます 証明書の透明性 (CT)。 クラウド プロバイダーも盗聴の検出に役立ちます。一部の大企業は、TLS 接続を監視するための専用ツールをすでに提供しています。

別の保護方法が新たに登場します。 стандарт ACME: SSL 証明書の受信を自動化します。 同時に、サイトの所有者を確認するためのメカニズムが追加されます。 さらに詳しく 以前の資料に書きました.

/フリッカー/ ユーリ・サモイロフ / CC BY

HTTPS の展望

多数の脆弱性にもかかわらず、IT 大手と情報セキュリティの専門家は、このプロトコルの将来性に自信を持っています。 HTTPS の積極的な実装のために 支持者 WWW クリエイターのティム・バーナーズ＝リー氏。 同氏によると、時間の経過とともに TLS の安全性が高まり、接続のセキュリティが大幅に向上するという。 バーナーズ＝リーはこうも示唆した 将来的に現れるでしょう ID 認証用のクライアント証明書。 これらは、攻撃者からのサーバー保護を強化するのに役立ちます。

機械学習を使用した SSL/TLS テクノロジーの開発も計画されており、スマート アルゴリズムが悪意のあるトラフィックのフィルタリングを担当します。 HTTPS 接続では、管理者はマルウェアからのリクエストの検出など、暗号化されたメッセージの内容を知る方法がありません。 すでに今日、ニューラル ネットワークは潜在的に危険なパケットを 90% の精度でフィルタリングすることができます。 (プレゼンテーション スライド 23).

所見

HTTPS に対する攻撃のほとんどは、プロトコル自体の問題ではなく、時代遅れの暗号化メカニズムのサポートに関連しています。 IT 業界は徐々に前世代のプロトコルを放棄し、脆弱性を検索するための新しいツールを提供し始めています。 将来的には、これらのツールはますますインテリジェントになるでしょう。

このトピックに関する追加リンク:

• クラウドでの開発、情報セキュリティ、個人データ: 1cloud のダイジェスト
• SSL ダイジェスト: ハブレなどに関する最高の実用的な資料
• VPN ダイジェスト: Habré の紹介記事など

出所： habr.com