Fatal编程技术网
  • windows/
  • Windows DLL预加载攻击。kernel32.dll从应用程序目录加载系统库

Windows DLL预加载攻击。kernel32.dll从应用程序目录加载系统库

windows security dll

Windows DLL预加载攻击。kernel32.dll从应用程序目录加载系统库,windows,security,dll,kernel32,Windows,Security,Dll,Kernel32,似乎kernel32.dll没有使用它加载的某些dll的完全限定路径，这就是为什么可以从应用程序目录（加载应用程序的目录）加载它们。例如，这些dll是：fltlib.dll、version.dll、dbghelp.dll 这真的很危险，这是一个安全问题，因为应用程序无法控制此加载。不支持延迟加载Kernel32.dll，因此我们不能使用SetDefaultDllDirectories（加载\库\搜索\系统32），因为所有操作都发生在用户代码之前！SetDllDirectory（“”）也没用，而且

似乎kernel32.dll没有使用它加载的某些dll的完全限定路径，这就是为什么可以从应用程序目录（加载应用程序的目录）加载它们。例如，这些dll是：fltlib.dll、version.dll、dbghelp.dll

这真的很危险，这是一个安全问题，因为应用程序无法控制此加载。不支持延迟加载Kernel32.dll，因此我们不能使用SetDefaultDllDirectories（加载\库\搜索\系统32），因为所有操作都发生在用户代码之前！SetDllDirectory（“”）也没用，而且它只排除当前目录而不排除应用程序目录。CWDILLOgaindlSearch没有帮助，因为它也只排除当前目录，而不排除应用程序目录

因此，以下信息：

    • 没用！它没有给出如何保护应用程序免受此DLL预加载攻击的任何实践答案

    当然，您可以说所有程序都在“程序文件”目录中，只有管理员才能写入这些目录。但并非所有应用都在“程序文件”目录中。除此之外，我们都知道，用户通常拥有管理员帐户，这就是为什么将其中一个恶意软件DLL静默地安装到某个应用程序的目录并获得对任何应用程序的静默控制非常简单的原因，因为此恶意软件DLL可以模拟（从真实DLL读取使用真实函数）所有系统API函数从真实的DLL到应用程序，所以应用程序永远不会知道它使用了恶意软件DLL！此外，通过这种方式恶意软件DLL可以绕过防火墙！例如，如果您将某些恶意软件DLL复制到浏览器目录（可以是任何内容：Internet Explorer、FireFox、Chrome或任何其他），则某些恶意软件代码将充当浏览器，其在防火墙设置中已具有允许规则，通常是到端口80443,53的传出连接。这真是一个潜在的漏洞

    当然，也可以进行加载后检查，如果发现此类恶意软件DLL，则卸载并删除它们。但这是一个错误的决定，因为如果恶意软件DLL已经加载到应用程序地址空间，它可以做任何它想做的事情，这就是为什么在加载后卸载和删除它可能是无用的

    这些DLL在此不存在：HKEY\U LOCAL\U MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnowNLS 但对于最终用户来说，建议将它们添加到此注册表项不是一个好主意。此外，他们中有多少人可以？我不知道

    决策： 只需禁用从系统路径（前缀为%windir%）以外的其他路径加载系统DLL即可。因此，只需启用从路径加载系统DLL即可，路径位于（%windir%\system32，%windir%\syswow64，%windir%\winsxs等等）。 这真的很奇怪，为什么主系统库（比如kernel32.dll）从应用程序目录加载它所使用的系统库，而应用程序目录是无法定义的！所有系统DLL只能从前缀为%windir%的路径或某些其他系统路径加载，但不能从应用程序目录路径加载，不能从当前目录路径加载，甚至不能从path环境变量中列出的路径加载

    复制步骤： 第一种方法（很简单，只是看看加载的DLL的路径是什么）。 1.将以下dll中的任意dll:fltlib.dll、version.dll、dbghelp.dll放入任何应用程序（Internet Explorer或Windows Live Mail或任何其他应用程序）的应用程序目录 2.查看加载了这些DLL的路径

    第二条路。 1.使用以下名称创建自己的dll：fltlib.dll、version.dll、dbghelp.dll 并将您自己的代码添加到DLL\u进程\u附件中，这非常简单。 若应用程序将从这些DLL调用一些函数，那个么您可以模拟真实的API函数并执行一些代码！ 2.将这些DLL中的任何内容放入任何应用程序（Internet Explorer或Windows Live Mail或任何其他应用程序）的应用程序目录 3.看看会发生什么

    我可以给你一个这样的DLL的例子。这是工作！我只是简单地显示一些消息，而不是一些恶意代码

    如何让Microsoft解决此问题？

    我在这里尝试过：Сconnect.microsoft.com/VisualStudio/feedback/details/1139089
    但是沉默

    如果他们可以写入您的应用程序目录，那么他们已经拥有您的系统。为什么要担心他们会编写dbghelp.dll的恶意版本，而他们只会覆盖主应用程序的恶意版本

    换句话说，如果你给了某人这样的控制级别，他们就有更容易的方法来做恶意的事情。

    我在这里尝试过：但沉默……你的问题是什么？@harryj如何让Microsoft解决这个问题？好的，这不是这里的主题。投票结束。（您可以尝试Microsoft的论坛，但实际上您永远不会让Microsoft相信这确实是一个安全漏洞。）请注意，如果攻击者是管理员，他们有很多其他方法可以将错误代码注入到您的应用程序中-例如，他们可以安装兼容性修复程序，指示Windows在应用程序运行时加载其DLL。或安装系统服务。或用户模式设备驱动程序。或者几十种其他方式中的任何一种。在这种情况下，可能的攻击实在太多，无法将其全部消除。此外，如果您的应用程序不在程序文件中，则您（或系统管理员）有责任确保该目录具有适当的权限。>他们只会覆盖主应用程序的恶意版本。即使它将被数字签名？：））对于应用程序和用户来说，关键词是“静默”，并且“容易”利用此漏洞。您没有看到的主要问题是：为什么主系统库（如kernel32.dll）从应用程序目录加载它所使用的系统库，而应用程序目录根据定义是不能加载的？Windows不要求对可执行文件进行数字签名