🛵 💀 📂 HTTPSに対する潜在的な攻撃とそれらに対する防御方法 🏭 👩🏻‍🌾 🗃️

サイトの半分はHTTPSを使用しており、その数は着実に増加しています。このプロトコルは、トラフィック傍受のリスクを軽減しますが、試行された攻撃自体を排除するものではありません。それらのいくつか-POODLE、BEAST、DROWNなど-および保護方法については、資料で説明します。

/ Flickr / Sven Graeme / CC BY-SA

プードル

2014年にPOODLE攻撃が初めて知られるようになりました。 SSL 3.0プロトコルの脆弱性は、セキュリティ専門家のBodoMöllerとGoogleの同僚によって発見されました。

その本質は次のとおりです。ハッカーはクライアントに強制的にSSL 3.0接続を確立させ、切断された通信をエミュレートします。次に、 CBC暗号化トラフィックモードで特別なメッセージタグを検索します。攻撃者は、一連の偽のクエリを使用して、Cookieなどの関心のあるデータのコンテンツを再構築できます。

SSL 3.0は廃止されたプロトコルです。しかし、そのセキュリティの問題は依然として関連しています。クライアントはこれを使用して、サーバーの互換性の問題を回避します。一部のレポートによると、最も人気のある10万のサイトのほぼ7％がまだSSL 3.0をサポートしています。 POODLEの変更もあります。その目的は、より現代的なTLS 1.0およびTLS 1.1です。今年、 TLS 1.2保護をバイパスする新しいゾンビPOODLEおよびGOLDENDOODLE攻撃が登場しました（これらはまだCBC暗号化に関連付けられています）。

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

ビースト

2011年に発見された、SSLおよびTLS 1.0に対する最初の攻撃の1つ。 POODLEと同様に、BEAST は CBC暗号化機能を使用します。攻撃者は、TLSまたはSSLを介してデータを送信するときにメッセージを置き換えるJavaScriptエージェントまたはJavaアプレットをクライアントマシンにデプロイします。攻撃者は「偽の」パケットの内容を知っているため、それらを使用して初期化ベクトルを解読し、認証用のCookieなどのその他のメッセージをサーバーに読み取ることができます。

現在まで、多くのネットワークツールは、BEASTの脆弱性（ローカルインターネットゲートウェイを保護するプロキシとアプリケーション）に対して依然として脆弱です。

自分を守る方法。 攻撃者は、データを復号化するために定期的にリクエストを送信する必要があります。 SSLSessionCacheTimeoutの期間を5分（デフォルトの推奨値）から30秒に短縮することをお勧めします。このアプローチは、生産性にいくつかの悪影響を及ぼしますが、攻撃者向けの計画の実装を複雑にします。さらに、すぐにBEASTの脆弱性が独自のものになる可能性があることを理解する必要があります-2020年以来、最大のブラウザーはTLS 1.0および1.1のサポートを停止しています。いずれにせよ、これらのプロトコルを使用するブラウザユーザーは全体の1.5％未満です。

ownれる

これは、40ビットRSAキーを使用したSSLv2の実装でエラーを使用するクロスプロトコル攻撃です。攻撃者は、ターゲットの何百ものTLS接続をリッスンし、同じ秘密キーを使用してSSLv2でサーバーに特別なパケットを送信します。ハッカーはBleichenbacher攻撃を使用して、約1,000のTLSクライアントセッションの1つを解読できます。

DROWNは2016年に初めて知られるようになり、世界のサーバーの3分の 1がそれにさらされました。現在まで、関連性は失われていません。最も人気のある150,000のサイトのうち、2％がまだSSLv2と脆弱な暗号化メカニズムをサポートしています。

自分を守る方法。 SSLv2サポートを無効にする暗号化ライブラリの開発者が提案したパッチをインストールする必要があります。たとえば、このような2つのパッチがOpenSSLに導入されました（2016年にはこれらはアップデート 1.0.1sおよび1.0.2gでした）。また、脆弱なプロトコルを無効にするための更新と手順がRed Hat 、 Apache 、 Debianで公開されました。

IaaSプロバイダー1cloud.ruの開発部門の責任者であるSergey Belkin氏は、次のように述べています。 -この状況は、複数のサーバーが共通のSSL証明書を使用している場合に発生します。 この場合、すべてのマシンでSSLv2サポートを無効にします。」

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

ハートブリード

ソフトウェアの最大の脆弱性の1つはHeartbleedです。 2014年にOpenSSLライブラリで発見されました。エラーが発表された時点で、脆弱なWebサイトの数は50万と推定されました。これは、ネットワーク上の保護されたリソースの約17％です。

この攻撃は、小さなハートビートTLS拡張モジュールを通じて実装されます。 TLSプロトコルでは、データを継続的に送信する必要があります。長時間のダウンタイムの場合、中断が発生し、接続を再確立する必要があります。この問題に対処するために、サーバーとクライアントは人為的にチャネルを「ノイズ」（ RFC 6520、p。5 ）し、ランダムな長さのパケットを送信します。最も多くのパッケージであることが判明した場合、OpenSSLの脆弱なバージョンは、割り当てられたバッファ外のメモリを読み取ります。プライベート暗号化キーや他の接続に関する情報など、あらゆるデータがこの領域に存在する可能性があります。

この脆弱性は、1.0.1から1.0.1fまでのライブラリのすべてのバージョン、および多くのオペレーティングシステム（12.04.4までのUbuntu、6.5より古いCentOS、OpenBSD 5.3など）に存在していました。完全なリストは、Heartbleed Webサイトにあります。この脆弱性に対するパッチは、発見後すぐにリリースされましたが、問題はこれまでと同様に関連しています。 2017年には、約20万のサイトがHeartbleedの影響を受けていました。

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

証明書のなりすまし

管理対象ノードは、トラフィックを積極的に傍受する正当なSSL証明書を使用して、ユーザーとサーバーの間にインストールされます。このノードは正当なサーバーのふりをして、有効な証明書を提示し、MITM攻撃を行うことが可能になります。

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

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

もう1つの保護方法は、SSL証明書の受信を自動化する新しいACME 標準です。同時に、彼はサイト所有者をチェックするための追加のメカニズムを追加します。以前の資料で彼についてもっと書いた。

/ Flickr / ユーリサモイロフ / CC BY

HTTPSの見通し

多くの脆弱性にもかかわらず、ITの巨人と情報セキュリティの専門家はプロトコルの将来に自信を持っています。 HTTPSの積極的な実装については、WWWの作成者であるTim Berners-Leeを支持しています。彼によると、時間の経過とともにTLSはより安全になり、接続のセキュリティが大幅に向上します。 Berners-Leeは、将来、認証用のクライアント証明書があることを提案しました。これらは、侵入者からのサーバー保護の改善に役立ちます。

また、機械学習の助けを借りてSSL / TLSテクノロジーを開発する予定です。スマートアルゴリズムが悪意のあるトラフィックのフィルタリングを担当します。 HTTPS接続では、管理者はマルウェアからのリクエストの検出を含め、暗号化されたメッセージの内容を見つける方法がありません。すでに、ニューラルネットワークは潜在的に危険なパケットを90％の精度でフィルタリングできます。（スライド23のプレゼンテーション）。

結論

HTTPSへの攻撃の大部分は、プロトコル自体の問題ではなく、古い暗号化メカニズムをサポートするためのものです。 IT業界は、前世代のプロトコルを段階的に廃止し、脆弱性を発見するための新しいツールを提供しています。将来、これらのツールはよりインテリジェントになります。

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