SSL.com より新年明けましておめでとうございます! SSL.com のセキュリティ ラウンドアップの今号へようこそ。SSL/ における XNUMX 月の開発の一部を紹介します。TLS、デジタル証明書、およびネットワーク セキュリティ。この版では、次の内容について説明します。
SHA-1: 選択されたプレフィックスの衝突
SHA-1 暗号化ハッシュ アルゴリズムに脆弱性があることは最新ニュースではありません。約 XNUMX 年前、Google の研究者は 固定プレフィックスの衝突 アルゴリズムを使用して、重大な暗号用途のためにスローモーションの死を送ります。その結果、脆弱性の低い SHA-2 が採用され、ほとんどが放棄されました。今月、事態はさらに悪化しました。 選択されたプレフィックス 衝突、 によって報告された Ars Technicaの:
新しい衝突により、攻撃者は以前の手法で利用できたものよりも多くのオプションと柔軟性を得ることができます。これにより、SHA1 アルゴリズムを使用してデジタル署名されると、選択したターゲットになりすます PGP 暗号化キーを作成することが現実的になります。より一般的には、攻撃者が選択した 45,000 つ以上の入力のそれぞれにデータを追加することで、同じハッシュを生成します。火曜日に明らかにされた攻撃の実行費用もわずか2017万110,000ドルだ。対照的に、560,000 年に明らかにされた攻撃では、事前に決定された特定の文書プレフィックスに対する偽造は許可されず、攻撃者がどれだけ迅速に実行したいかに応じて、Amazon の Web サービス プラットフォームでの費用は XNUMX 万ドルから XNUMX 万ドルと評価されました。
この攻撃は重要です。多くの人が SHA-1 アルゴリズムを放棄しましたが、まだ完全には非推奨になっていません (たとえば、GnuPG のレガシー 1.4 ブランチで PGP キーを認証するために引き続き使用されています)。そのため、この侵害は深刻な問題となっており、専門家らは証明書や認証にSHA-1を使用することを放棄するよう繰り返し訴えている。
ハードウェア ベンダーが秘密キーを誤って取り扱う
As 発見 Nick Starke と Tom Pohl によって、Shaun Nichols によって報告されました。 登録, Netgear では最近、かなり恥ずかしいセキュリティ侵害がありました。有効な署名付き証明書は秘密キーとともにルーターのファームウェアに組み込まれており、パブリックにダウンロードでき、デバイスに同梱されています。これは、ユーザーのルーターへの HTTPS 接続をハイジャックするために使用される可能性のある情報であり、セキュリティを犠牲にして顧客の作業を容易にする試みだったようです。ショーン・ニコルズ氏は次のように報告しています。
この失敗は、セキュリティとユーザーの利便性に対する Netgear のアプローチの結果です。キットを構成する場合、Netgear 機器の所有者は https://routerlogin.net または https://routerlogin.com にアクセスする必要があります。ネットワークのルーターは、これらのドメイン名がローカル ネットワーク上のデバイスの IP アドレスに解決されることを確認しようとします。HTTPS 接続を確立し、安全でない HTTP や信頼できない証明書の使用に関するブラウザーからの苦情を避けるために、ルーターはルーターログイン用の有効な HTTPS 証明書を生成する必要があります。ブラウザーによって信頼されている .net または routerlogin.com。接続の確立時に証明書が正当であることを暗号的に証明するには、ルーターは証明書の秘密キーを使用する必要があります。このキーはファームウェアに安全に保存されないため、誰でも抽出して悪用できます。
現時点で、同社には自由に使えるソリューションがいくつかあります。 現在ネット上で議論されている.
NSA、Windows 10に重大な暗号化の脆弱性を発見
国家安全保障局は、Windows 10 の暗号化機能に影響を与える「重大な脆弱性」と呼ばれるものを発見しました。具体的には、この脆弱性は HTTPS 接続、署名されたファイルと電子メール、および一部の署名されたコードに影響を与えます。そのため、当局はユーザーに対し、2020 年 XNUMX 月の火曜日のパッチをすべてできるだけ早くインストールすることでこの脆弱性を軽減するようアドバイスしています。 NSA から詳細を読むことができます 彼らのウェブサイト上の.
「広範囲にわたる」と言われているこの脆弱性は研究者らを動揺させている。ダン・グッディンとして Ars Technicaの 説明して、この脆弱性は信頼の連鎖を断ち切る抜け穴を悪用します。
この欠陥は、Windows の新しいバージョンが楕円曲線暗号を使用する証明書の有効性をチェックする方法に関係しています。脆弱な Windows バージョンは XNUMX つの ECC パラメータをチェックしますが、ベース ポイント ジェネレータとして知られ、アルゴリズムでは「G」として表されることが多い XNUMX 番目の重要なパラメータの検証に失敗します。この失敗は、むしろ Microsoft による ECC 実装の結果です。 ECC アルゴリズム自体の欠陥や弱点よりも。
攻撃者は、Windows にデフォルトで付属しているルート証明書の公開キーを抽出することで、この欠陥を悪用する可能性があります。これらの証明書は、独自の証明書を発行する大きな認証局に属しているため、ルートとして説明されます。 TLS 証明書を検証するか、ルート CA に代わって証明書を販売する中間認証局を検証します。 ECC アルゴリズムで署名されている限り、どのルート証明書でも機能します。攻撃者は、ルート証明書の公開キーの生成に使用される特定の ECC アルゴリズムを調べ、そのアルゴリズムのすべての証明書パラメーターをコピーする秘密キーの作成を開始します。ポイントジェネレーター用。脆弱な Windows バージョンはそのパラメータをチェックできないため、秘密キーを有効なものとして受け入れます。これにより、攻撃者は Windows の信頼されたルート証明書を偽装し、Web サイト、ソフトウェア、その他の機密プロパティの認証に使用される個別の証明書を作成するために使用できるようになりました。
つまり、このバグは悪者によって悪用され、悪意のある実行可能ファイルが信頼できる検証済みのソースからのものであるかのように見せかけ、デジタル証明書を偽造する可能性があります。心配した？ テスト用のリンクはこちら 攻撃に対して脆弱な場合。
