苹果操作系统上的DLL劫持

2015-3-20 19:05| 发布者: 随便、先森。| 查看: 1254| 评论: 0|来自: 360安全播报

摘要: 背景相关背景请见播报平台之前报道的研究人员发现MAC上的DLL劫持技术Window上的DLL劫持：一个应用会自动下载DLL（动态链接库），但是下载时并没有特定的完整路径名称，Windows系统就会把DLL放到它认为合适的目录下。 ...

背景

相关背景请见播报平台之前报道的 研究人员发现MAC上的DLL劫持技术

Window上的DLL劫持：

一个应用会自动下载DLL（动态链接库），但是下载时并没有特定的完整路径名称，Windows系统就会把DLL放到它认为合适的目录下。如果攻击者控制了其中一个这样的目录，这个目录就会强迫应用下载带有病毒或者不安全的DLL而不是应用所期待的DLL。

需要注意的是，Windows加载器会默认搜索当前工作目录或者该应用的目录而不是系统目录。如果应用程序试图在没有充分限定的路径下加载系统库（通过其他路径名），可能会出现一些问题。在这种情况下，攻击者可能在主搜索目录中植入一个恶意的DLL（它的路径名可以跟合法的DLL匹配）。Windows加载器会在加载合法DLL之前就找到攻击者提供的库并且盲目的把它加载到程序中。

DLL劫持在2010年迅速吸引了媒体和恶意攻击者的注意。有一些众所周知的DLL劫持事件：”binary planting”, “insecure library loading”, “DLL preloading”等待，这些都是由 H.D. Moore 发现的。然而，美国国安局实际上在1998年就发现了这个漏洞的，比Moore早了12年。美国国安局发布的Windows NT安全指南中就警告了DLL劫持。

“入侵者无法在系统搜索到同意名称的合法的DLL之前就在这些目录中植入假的DLL，这是非常重要的。”

对于一个攻击者来说，DLL能提供很多有用的场景。比如，这样的攻击允许恶意库被悄然劫持（注册表和OS其他部件不被修改），升级权限，并且可以进行远程感染。

攻击者们很快意识到了DLL劫持的好处。一篇名叫”What the fxsst?”的博客，Mandiant的研究人员描述了他们是如何发现不相关的恶意软件的，这些样本全部被命名为”fxsst.dll”。经过仔细检查，他们发现这些样品都利用了Windows的壳，为DLL劫持提供了持久的隐身方法。具体而言，如Explorer.exe被安装在C：\Windows中，fxsst.dll植入到同意目录中，导致在系统加载合法DLL库之前就加载恶意DLL库。

OS X上的DLL劫持

这些研究开始于分析OS X的动态链接器和加载器等。同过二进制分析，发现/usr/bin中提供了标准的加载器和链接器功能，包括发现、加载和链接动态库。

由于苹果dyld开源了，分析变的非常简单。通过阅读源码，下文简要概括了dyld过程：

1、开始是让内核设置用户模式切入点 __dyld_start (dyldStartup.s)。这个功能只需要设置用户模式然后跳转到 dyldbootstrap::start()，调用the loader's _main()。

2、Dyld’s _main() function (dyld.cpp) 调用 link()，然后调用ImageLoader object’s link() 方式为主要可执行文件获取链接

3、The ImageLoader class (ImageLoader.cpp)暴露了很多可以执行二进制图像装载功能的dyld。例如，这个类包含了link()方法。在调用时，该调用ecursiveLoadLibraries（）方法这个对象来执行所有相关的动态库加载。

4、ImageLoader’的 recursiveLoadLibraries()方法决定了所有需要的库，并调用context.loadLibrary()函数。上下文仅仅是一个结构函数指针，这些指针被方法和函数传递。这个结构的loadLibrary成员在libraryLocator()函数（dyld.cpp）初始化，简单的调用load()函数。

5、这个load()函数（dyld.cpp）调用大量的叫做loadPhase0()到loadPhase5()的帮助函数。每个函数控制不同的加载过程的的特定功能，例如，解析加载过程中的环境变量的路径。

6、在loadPhase5()之后，loadPhase6()函数最后加载（映射）从文件系统到存储器所需的dylib。然后，它调用ImageLoaderMachO类实例，实现执行Mach O特定的加载和链接。

通过了解dyld初始的加载逻辑，研究寻找可以执行dylib劫持的逻辑。具体来说，研究对一些代码很感兴趣，比如，如果没有发现dylib，加载器会怎么做；如何寻找加载位置等。如果这些场景实在程序内实现的，OS X dylib劫持就可以实现。

有人推测说，如果加载器可以在没发现dylib的情况下进行处理，攻击者就可以把这个恶意dylib放在这个位置。装载器就能发现攻击者种植的dylib，盲目加载恶意代码。

加载器调用 ImageLoader class 类的recursiveLoadLibraries() 方法来查找并加载所需的库。下面的图中，加载代码被封装在try/catch块中来检测无法加载的dylibs。

不出所料，如果一个库加载失败抛出一个异常。但有趣的是，如果”required”被设置为true。此外，源码显示加载”weak”库失败。这似乎表明，一些情况下，其中装载器是可以没有库的。

通过更深入的挖掘装载器中设置”required”的源码，mageLoaderMacho类的doGetDependentLibraries()方法分析该负载指令该负载指令并设置基于加载LC_LOAD_WEAK_DYLIB类型描述的变量。

装载命令是Mach-O的文件格式（OS X的本机二进制文件格式）的一个组成部分。立即嵌入Mach-O的头，他们提供各种装载器命令。例如，用负载命令来指定二进制的存储器布局，主线程的初始执行状态和有关二进制动态库的信息。可以使用一些如MachOView工具或/ usr/ bin中/ otool（带-l命令行标志），来查看编译的二进制文件的加载命令。

图五中的代码显示加载器遍历所有负载指令，寻找那些指定dylib进口。这样的负载命令（例如LC_LOAD_DYLIB，LC_LOAD_WEAK_DYLIB等）的格式可以在的Mach-O/ loader.h文件中找到。

对于每个dylib来说，一个可执行文件针对动态链接，它将包含一个 LC_LOAD_* (LC_LOAD_DYLIB, LC_LOAD_WEAK_DYLIB, etc.) 加载指令。如图4和图5的代码解释了LC_LOAD_DYLIB加载指令对应的特定dylib，而经过LC_LOAD_WEAK_DYLIB导入的库是可选的。LC_LOAD_DYLIB这个情况，如果没有找到需要的dylib会抛出异常，使装载器终止进程。但是对于后者LC_LOAD_WEAK_DYLIB来说，如果没有找到dylib不会产生任何训还，主程序仍可以执行。