【问题标题】:Validating .NET Framework Assemblies验证 .NET Framework 程序集
【发布时间】:2013-01-24 15:55:59
【问题描述】:

我刚刚浏览了我们的german VB.NET forums,有一些有趣的事情让我有些头疼。

实际上可以使用 ReflexIL 或其他一些 IL 编辑器编辑 .NET Framework 程序集。您唯一需要绕过的是程序集的强名称签名。更改程序集 IL 后,您必须运行 sn.exe -Vr [assemblyname] 以略过强名称验证。之后,您必须清除缓存的本机图像。只需浏览C:\Windows\assembly 目录并删除与您的程序集相关的每个图像。然后重新启动。登录后,运行ngen install [assemblyname]。现在生成了新的原生图像。

这行得通。我在我的虚拟环境(Windows XP x86)中验证了这个过程。现在最让我担心的是,您可以轻松绕过RSACryptoServiceProvider 的.NET VerifyHashVerifyData 方法。这实际上也有效。我和我的一个朋友经过测试可以验证这个问题(see screenshots)。这很容易。

例如,如果我要创建一个基于 .NET Framework 加密类的许可系统,则可以为 每个 .NET 应用程序绕过系统范围使用框架的系统。此外,每个人都可以记录更改我通过挂钩方法调用的函数的输入。

现在我的问题是: 既然这可能是一个大问题,我该怎么做呢?当然,恶意用户可以只编辑 my 应用程序,但这不会像在系统范围内那样糟糕。 我在考虑一些框架校验和验证,但由于 .NET Framework 有很多不同的更新,这似乎是不可能的。

有什么解决方案或建议吗? Microsoft 是否以某种方式解决了这个问题?

【问题讨论】:

  • 您需要再次完成整个练习,但这次没有管理员用户名和密码。这是威胁分析中的一个常见谬误,当入侵者有钥匙时,锁门是没有意义的。
  • 另外,许可系统通常是徒劳的。

标签: .net security .net-assembly cil ngen


【解决方案1】:

如果攻击者对您的计算机具有管理员访问权限(您所描述的攻击需要此权限),那么您几乎已经失败了。你能做的任何事情都可能被攻击者规避。

因此,我认为试图防御这种类型的攻击是完全没有意义的。如果您必须处理不受信任的、可能受到威胁的计算机,那么您根本无法相信它们会做任何敏感的事情,而您必须在自己的服务器上进行,或类似的事情。

【讨论】:

  • 我知道这样做是没有意义的。我只是对为什么微软让它变得如此简单感兴趣。这不是我要找的答案,但没关系。
  • 我不明白你的推理方式。你说阻止这种攻击没有意义,但你仍然认为微软应该在上面花费资源?
  • 由于 MS 可以访问内核、.NET Framework 和 CLR,它们至少可以让它变得更难一些。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-02-20
  • 1970-01-01
  • 2021-02-24
  • 2017-07-31
  • 1970-01-01
  • 2012-03-12
相关资源
最近更新 更多