3

我正在使用 AppLocker 来防止标准用户执行除我们签名的应用程序和一些必要的 Windows 文件之外的任何内容。

exe 和 dll 文件使用我们的证书进行签名signtool.exe，然后在 AppLocker 中我有发布者规则，阻止用户运行任何未经我们签名的内容。

这行得通，但它不会阻止已签名的可执行文件加载未签名的 dll 文件，这似乎存在安全风险。我通过用未签名版本替换所有 dll 进行测试，只留下签名的 exe，打开阻止任何未经我们签名的内容的 dll 规则，并且应用程序运行得很好。EventLog 没有显示任何潜在的块（我在审核模式下打开了 dll 规则）。

我做了一些阅读，据我了解，其原因可能是这些不是“正常”（Win32）dll，而是在 CLR 中编译和执行的程序集，它绕过了 AppLocker dll 规则？

如果是这种情况，似乎确保 dll 不被篡改的唯一方法是进行程序集签名，给每个程序集一个强名称，这将确保 exe 仅获取并运行这些特定的 dll。这个对吗？

有没有办法让 AppLocker dll 规则阻止由 CLR 编译和运行的 dll（程序集）？如果没有，那么甚至签署程序集 dll 有什么意义吗？

更新：

感谢Maurizio找到了这个问题的原因，因为微软很可能刚刚破坏了 .NET 4.0 的 AppLocker，因为 dll 规则在 .NET 3.5 上运行良好。他联系了微软，后者只是建议使用 WDAC而不是 AppLocker... 微软如此不负责任地悄悄破坏人们的安全策略。

4

1 回答 1

2

我们也看到了这种行为。根据我的测试，只有在加载 DLL 的 EXE 使用 .NET 3.5 编译时，它才能按预期工作。

这是我的测试：

  1. 我写了一个简单的 C# 应用程序，它动态加载一个 C# 库/dll，它只计算两个数字之间的和。
  2. 针对 .NET 3.5 和 .NET 4.0+编译此应用程序 ( LoadDLL.exe )，并通过添加新的 AppLocker 规则来允许它。
  3. Adder.dll（执行添加的库）未添加到applocker 规则中，因此我希望它在被LoadDLL.exe加载时被阻止

结果是使用 .NET3.5 编译的 LoadDLL.exe 按预期工作 - 即阻止加载 Adder.dll 而使用 .NET4.0+ 编译的 LoadDLL.exe 就像一个魅力。

我认为在引入 .NET4.0 时发生了一些变化，这使得 DLL 集合变得无用

于 2021-08-11T10:40:27.880 回答