ASP.NET 漏洞 CVE-2008-5100（程序集签名绕过）：有修复吗？

信息安全 已知漏洞 网
2021-09-11 09:43:09

这个问题的简短版本是：是否有针对 ASP.NET 漏洞 CVE-2008-5100的修复或缓解措施，它允许攻击者绕过程序集数字签名检查？

我会介绍一些背景。我提前为篇幅道歉；这似乎是一个复杂的主题。

我们对运行 ASP.NET 应用程序的 Windows 2008R2 网站运行了安全扫描程序，扫描程序声称我们容易受到 CVE-2008-5100 的攻击。正如 mitre.org 和许多其他网站所述，该漏洞于 2008 年首次报告，包括：

Microsoft .NET Framework 2.0.50727 中的强名称（SN）实现依赖于嵌入在 DLL 文件路径名中的数字签名 Public Key Token，而不是该文件本身的数字签名，这使得攻击者更容易绕过 Global程序集缓存 (GAC) 和代码访问安全 (CAS) 保护机制，即 MSRC 票证 MSRC8566gs。

这似乎是 .NET Framework 实现中的一个令人尴尬的设计缺陷，允许有权访问目标系统文件系统的攻击者替换恶意 DLL，该恶意 DLL 将被不恰当地验证为受害者的原始 DLL。 

该漏洞的 CVSS 评分为 10.0，相当于有史以来遇到的最严重的漏洞。

安全扫描软件提示：“更新 ASP.NET 版本”。但是，在我对该主题的广泛谷歌搜索中，没有证据表明任何其他版本的 ASP.NET 更容易受到攻击。事实上，考虑到这个缺陷的严重程度，令人惊讶的是，自 2009 年 1 月以来，跟踪该缺陷的网站都没有更新。我能找到的唯一一个相对较新的关于此类缺陷的提及是在 Ian Picknell 的博客中，其中他描述了 .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。如果我们使用 .NET Framework 4 的目标重新编译应用程序，我们会得到标题“X-AspNet-Version: 4.0.30319” . 我们可能可以通过使用这个编译版本让扫描器停止抱怨，但这真的改变了 .NET 在运行时检查程序集的方式吗？我持怀疑态度，但我无法以一种或另一种方式找到任何证据。

我不太关心实际被利用的应用程序，因为它需要对系统目录的写访问权。我和我的管理层一样关注遵循最佳实践。

谢谢。

2个回答

据我了解，这个 CVE 是一个哑弹。强名称基本上是 DLL 上的签名，公钥由“公钥令牌”标识，它是截断为 64 位的密钥的 SHA-1 哈希。“强名称”的核心功能是避免多个彼此不认识的开发人员发布同名的不同 DLL 时发生冲突。

强名称也应该支持代码完整性框架：给定的应用程序将通过名称、版本和公钥令牌引用 DLL；将在全局程序集缓存中找到匹配的 DLL 。邪恶的攻击者可能会尝试将与真正的 DLL 同名的恶意 DLL 加载到 GAC 中，希望另一个应用程序（由另一个用户启动）加载他的DLL 而不是正确的。要做到这一点，由于应用程序包含“公钥令牌”，攻击者必须使用与公钥令牌匹配的密钥签署他的 Evil DLL - 而公钥令牌是加密哈希，他不能。

CVE-2008-5100 主要是关于有人注意到 DLL 上的签名实际上是在 DLL 安装在 GAC 中时验证的，而不是在从 GAC 加载它时。这是有道理的：GAC 受到保护，不会被操作系统任意更改。因此，如果 DLL 在进入时很好，那么之后它仍然很好。或者，更准确地说，要修改已安装到 GAC 中的 DLL，您需要广泛的管理权限，这使得所有这些都没有实际意义：如果您拥有该权限，那么您已经以所有可能的方式拥有该机器。这解释了 Web 对这个 CVE 的震耳欲聋的沉默：这不是问题。就像声称可以从里面打开的锁一样房子是一个安全漏洞，因为已经在房子里的窃贼可以打开门，让......窃贼进来？看，当我使用没有技术术语面纱的类比时，整个事情变得荒谬。

所以来自扫描仪的报告是不合适的。你的问题是找到正确的方法来关闭它。我的建议是不要使用会做出如此愚蠢报告的“安全扫描仪”。

现在，如果我们看细节，这个“强名”业务存在一些“次优”；即，哈希被截断为 64 位。这意味着对原像的抵抗力是2 64，这是很高的，但在技术上仍然可以达到（这种规模的努力已经公开完成了至少一次)（显然，几所大学已经开始进行第二次类似的尝试，以解决 128 位椭圆曲线中的离散对数问题——预计将在十年内完成）。攻击者可能会尝试生成与用于特定 DLL 的公钥令牌匹配的公钥；如果他成功了，那么他可以制作一个将被应用程序接受的假 DLL，为此他只需要对 GAC 的“正常”访问（如果没有潜在的攻击者可以在您的计算机上打开正常的用户会话，仍然不用担心）。

生成 2 64 个RSA 密钥对是昂贵的（不像你想象的那样昂贵，因为攻击者可以制作一些无效的密钥，但仍然很昂贵）所以我怀疑这种攻击是否非常实用，但安全边际相当低。

只是想补充：

该漏洞的 CVSS 评分为 10.0，相当于有史以来遇到的最严重的漏洞。

你绝对不能总是这样假设。并非所有 CVSS 10 漏洞都是平等的……有些比其他漏洞严重得多。老实说，很难为漏洞分配一个平坦的数值。

其它你可能感兴趣的问题
上一篇HTTPS 是否加密 PHP 参数？ 下一篇SSH：重用公钥和已知的中间人