ASP.NETの脆弱性CVE-2008-5100（アセンブリ署名バイパス）：修正はありますか？
この質問の短いバージョンは次のとおりです。ASP.NETの脆弱性 CVE-2008-51 に対する修正または緩和策はありますか？これにより、攻撃者はアセンブリのデジタル署名チェックを回避できますか？
背景を説明します。しばらくの間、お詫び申し上げます。これは複雑なテーマのようです。
私たちは、ASP.NETアプリケーションを実行しているWindows 2008R2 Webサイトに対してセキュリティスキャナーを実行しました。スキャナーは、CVE-2008-5100に対して脆弱であると主張しました。 mitre.orgおよび他の多くのWebサイトで述べられているように、この欠陥は2008年に最初に報告され、次のもので構成されています。
Microsoft .NET Framework 2.0.50727の厳密な名前（SN）の実装は、このファイル自体のデジタル署名ではなく、DLLファイルのパス名に埋め込まれたデジタル署名公開鍵トークンに依存しています。これにより、攻撃者がグローバルアセンブリキャッシュ（GAC）およびコードアクセスセキュリティ（CAS）保護メカニズム（別名MSRCチケットMSRC8566gs）をバイパスしやすくなります。
これは、.NET Frameworkの実装における厄介な設計上の欠陥のようであり、ターゲットシステムのファイルシステムにアクセスできる攻撃者が、悪意のあるDLLを悪用して、被害者の妥当性を検証される可能性があります。元のDLL。
この脆弱性のCVSSスコアは10.0であり、これまでに発生した最悪の脆弱性と同等です。
セキュリティスキャンソフトウェアのアドバイス：「ASP.NETのバージョンを更新してください」。ただし、このトピックについての広範なグーグル検索では、他のバージョンのASP.NETの脆弱性が低いという証拠はありません。実際、この欠陥がどれほど深刻であるかを考えると、この欠陥を追跡しているWebサイトが2009年1月以降更新されていないことは驚くべきことです。このような欠陥について私が見つけた比較的最近の唯一の言及は Ian Picknell's blog 、彼は.NET Framework 3.5 SP1の非常によく似た修正されていない欠陥について説明しています（2010年2月現在）。また、セキュリティベンダーが2013年1月にスキャナーにこの欠陥を追加しただけであるという事実も、多少憂慮すべきです。
簡潔にするために、ASP.NETバージョンの意味についての長い議論は避けます。ただし、スキャナーがHTTPヘッダー「X-AspNet-Version：2.0.50727」をキーオフしているようです。 .NET Framework 3.0を対象とするビルドフラグを使用してコンパイルされているため、アプリケーションはこのヘッダーを発行します。実際、アプリケーションは、Windows Server 2012上で実行されている場合でも、このバージョンのASP.NETを報告します。NETFramework 4のターゲットを使用してアプリを再コンパイルすると、ヘッダー「X-AspNet-Version：4.0.30319」が取得されます。 。おそらく、このコンパイルされたバージョンを使用することでスキャナーが文句を言うのを止めることができますが、それは.NETが実行時にアセンブリをチェックする方法を本当に変えているのでしょうか？私は懐疑的ですが、何らかの方法で証拠を見つけることはできません。
システムディレクトリへの書き込みアクセスが必要なため、実際に悪用されるアプリケーションについてはそれほど心配していません。私の経営陣と同様、私はベストプラクティスに従うことを懸念しています。
ありがとう。
私が理解している限り、このCVEはおかしいです。 strong name は基本的にDLLの署名であり、公開鍵は「公開鍵トークン」によって識別されます。これは、64ビットに切り捨てられた鍵の SHA-1ハッシュです） 。 「強力な名前」のコア機能は、お互いを知らない複数の開発者が同じ名前で異なるDLLを発行する場合に、衝突を回避することです。
厳密な名前もコード整合性フレームワークをサポートすることになっています。特定のアプリケーションはDLL名前、バージョン、および公開キートークンで参照します。一致するDLLは Global Assembly Cache にあります。悪意のある攻撃者は、本物のDLLと同じ名前の悪意のあるDLLをGACにロードし、別のアプリケーションを期待する可能性があります（ （別のユーザーによって起動された）をロードするhisDLL正しいものの代わりに。これを行うには、アプリケーションに「公開鍵トークン」が含まれているため、攻撃者は自分の悪に署名する必要がありますDLL公開キートークンと一致するキーを使用し、公開キートークンは 暗号化ハッシュ ですが、署名できません。
CVE-2008-5100は、主にDLLの署名が、DLLが読み込まれたときではなく、GACにインストールされたときに実際に検証されることを示しています。 GACから。これは理にかなっています。GACはオペレーティングシステムによる任意の変更から保護されています。したがって、DLLがエントリ時に良好であった場合、その後も良好です。より正確には、 GACにインストールされているDLLを変更するには、このすべてを無効にする広範な管理者権限が必要です。その権限がある場合、可能な限りすべての方法でマシンを所有しています。これは、このCVEに関するWebの耳をつんざくような沈黙を説明します：それは問題ではありません。それは、 家の中はセキュリティの脆弱性です。すでに家にいる強盗がドアを開けて、侵入者を侵入させてしまう可能性があるためです...専門用語のベールがないアナロジーで、すべてがばかげています。
そのため、スキャナーからのレポートは適切ではありません。あなたの問題は、それをシャットダウンする正しい方法を見つけることです。私の推奨は、そのような愚かなレポートを作成する「セキュリティスキャナー」を使用しないことです。
詳細を見ると、この「Strong Name」ビジネスには「次善の」何かがあります。つまり、ハッシュは64ビットに切り捨てられます。これは、preimagesに対する耐性が2であることを意味します64、それは高いですが、技術的に到達可能です（その規模の努力は公に行われました 少なくとも1回 ）（どうやら、その種の2番目の努力がいくつかの大学で始まっており、 128ビットの楕円曲線-推定10年以内に完了する）。攻撃者は、特定のDLLに使用されている公開鍵トークンと一致する公開鍵を生成しようとする可能性があります。彼が成功した場合、アプリケーションで受け入れられる偽のDLLを作成できます。これには、GACへの「通常の」アクセスのみが必要です（潜在的な攻撃者がいない場合でも心配はありません）マシン上で通常のユーザーセッションを開くことができます）。
プロデュース264 RSAキーペアは高価です（攻撃者が無効なキーを作成する可能性があるため、信じられているほどではありませんが、それでも高価です）。この攻撃が非常に実用的であるとは思えませんが、セキュリティマージンはかなり低いです。
追加したかっただけです：
この脆弱性のCVSSスコアは10.0であり、これまでに発生した最悪の脆弱性と同等です。
あなたは間違いなく常にそれを想定することはできません。すべてのCVSS 10の脆弱性が同じであるとは限りません...他の脆弱性よりはるかに深刻なものもあります。正直なところ、脆弱性にフラットな数値を割り当てるのは本当に難しいです。