OS X 上的动态链接库劫持 (下)

翻译水平有限,如有问题欢迎指出,谢谢。

OS X 上的动态链接库劫持 (上)


OS X 上的动态链接库劫持 (下)


Patrick Wardle, Synack, USA.

翻译 i_82 <i.82@me.com>

译者注:该论文发表于 CanSecWest 2015,乌云知识库上同样有此篇文章的另一翻译,这篇翻译并非基于前者,特此声明。


攻击

现在读者应该对 OS X 上 dylib 劫持攻击有了一个坚实理解 (a solid understanding),现在我们将采用一些真实生活中的攻击场景提供例证,并且提供一些切合实际的防御手段。

我们的对手 (adversaries),资深黑客们知道,在一次攻击中,尽可能多地使用自动化组件是多么重要。这些自动化组件提升了攻击的规模与效率,将攻击者从中解放出来,以更多地关注需求以及攻击中更为复杂的层面。

此类劫持攻击的第一个自动化的组件,被用于易受威胁应用程序的挖掘。我们创建了一个 Python 脚本,dylibHijackScanner.py (可在这里下载 [15]),用于完成这一项任务。在收集文件系统中所有可执行文件及运行进程的列表后,脚本能够智能解析二进制 Mach-O 文件头以及装载指令。为了检测二进制文件,是否能够通过 weak dylib 劫持,脚本将会检查 LC_LOAD_WEAK_DYLIB 装载指令,并检查其是否引用了一个不存在的 dylib。自动地检测二进制文件,是否会因为一个不存在的,以 @rpath 开头的导入项而被劫持,这就稍微地更复杂一些。首先,脚本会搜索那些,至少有一个 LC_LOAD*_DYLIB 装载指令引用了 run-path dylib 的二进制文件。如果二进制文件存在这样一个装载指令,脚本将会继续解析二进制而装载指令,寻找多条 LC_RPATHS。如果这两个先决条件 (prerequisites) 都满足 (hold true),脚本将检查 run-path 依赖库导入能否在主 run-path 搜索路径被找到。如果库不存在,脚本将会警告用户,该二进制文件是易受威胁的。执行该搜索脚本发现了惊人数量的、存在漏洞的应用程序,包括我们的漏洞测试应用,rPathApp.app。

图 33 - 自动检测易受影响的应用程序

正如图 33 中能够看到的,检测脚本,仅在作者的工作笔记本上就找到了近 150 个易受威胁的应用程序!有趣的是,大多数易受威胁的应用程序都属于更加复杂的 (从是否满足先决条件的角度来看),“multiple rpath” 这类。由于篇幅限制,无法列出这些存在漏洞应用程序的完整列表。但是,表 1 列出了几个广泛使用,或广为人知的应用,被扫描脚本发现,存在 dylib 劫持漏洞。

表 1 - 常见的易受威胁的应用程序

有了自动挖掘存在漏洞应用程序的能力,下一步理所应当地,是让创建兼容的劫持者恶意 dylib 这一过程,变得自动化。回顾一下之前,成功地执行一次劫持,劫持者 dylib 必需人工定义的两个要素。首先,劫持者 dylib 的版本号必需与合法的 dylib 保持兼容。其次 (在 rpath 劫持的情况下),劫持者 dylib 也必须包含重导出的装载指令 (LC_REEXPORT_DYLIB),指向合法的 dylib,确保所有的必需符号都能够被解析。

将自定义的通用 dylib 修改,使之自动化,满足这两个先决条件,是相当直接的。我们创建了第二个 Python 脚本,createHijacker.py (也可在这里下载 [15]),以执行此次自定义。首先,脚本寻找并解析目标 dylib (存在漏洞应用程序所加载的合法 dylib) 中相关联的 LC_ID_DYLIB 装载指令。这使得必要的兼容性信息被取出。有了这些信息,类似地,劫持者 dylib 也被解析,直到找到它的 LC_ID_DYLIB 装载指令。然后脚本用取出的兼容性信息,更新劫持者 dylib 的 LC_ID_DYLIB 装载指令,这样,精确地确保了兼容性版本的匹配。接下来,解决重导出的问题,只需更新劫持者 dylib 的 LC_REEXPORT_DYLIB 装载指令,使其指向目标 dylib。虽然可以手工完成 LC_REEXPORT_DYLIB 装载指令的修改,但是简单地执行 install_name_tool 显然会更加的容易。

图 34 展示了该 Python 脚本自动配置、处理一个通用的劫持者脚本,以利用 (exploit) 易受威胁的样本应用,rPathApp.app。

图 34 - 自动化创建劫持者的过程

Dylib 劫持能够被用来实现大范围的恶意行为 (nefatious actions)。这篇论文涵盖了一些,包括隐蔽驻留,加载时进程注入,安全组件规避,与防火墙绕过。这些攻击,虽然极具危险性,但是仅仅通过简单地植入一个恶意 dylib,在滥用了操作系统装载起的合法功能的条件下,就都能够实现。正因此,它们看上去微不足道,所以不大可能被修补,或是,甚至被个人安全产品检测到。

利用这种 dylib 劫持,来实现隐蔽驻留,是该攻击最主要的一种形式。如果存在漏洞的应用程序无论是在系统重启还是用户登入都能够自动运行,本地攻击者就能够执行驻留 dylib 劫持,以获得恶意代码的自动执行机会。除了能够实现一种与众不同的驻留机制,这种攻击方式还能够为攻击者提供了一种高度的隐蔽性。首先,它只需要简单地植入单个文件 —— 不需要修改操作系统组件 (即启动配置文件或经过签名的系统二进制文件)。这很重要,因为这些组件常常被安全软件所监视,并且很容易验证出是否被篡改。其次,攻击者的 dylib 会被寄存在现有可信进程的运行上下文中,这使得它很难被检测到,因为进程不会表现出很明显的不同 (amiss)。

当然,要实现这样隐蔽和优雅的驻留,需要一个随操作系统自动启动的、包含漏洞的应用程序。Apple 的 iCloud 照片流代理 (/Applications/iPhoto.app/Contents/Library/LoginItems/PhotoStreamAgent.app) 就会在用户登录时自动启动,为了与云端同步本地内容。幸运的是 (As luck would have it),该应用程序包含了多个 run-path 搜索目录和一些在主 run-path 搜索目录中搜寻不到的 @rpath 导入项。换句话说,它很容易受到 dylib 劫持攻击的威胁。

图 35 - Apple 的易受威胁的照片流代理

使用 createHijacker.py 脚本,可以轻而易举地将恶意劫持者 dylib 配置成与目标 dylib 和应用程序兼容的版本。在这个例子中需要注意的是,因为存在漏洞的导入项 (PhotoFoundation),是在一个框架组件包 (Framework Bundle) 当中,所以同样的组件包结构 (bundle structure) 在主 run-path 搜索目录 (/Applications/iPhoto.app/Contents/Library/LoginItems) 中将被重新创建。当正确的组件包布局与恶意劫持者 dylib (被重命名为 ‘PhotoFoundation’) 放置在主 run-path 搜索目录中后,装载器就会在 iCloud 照片流代理启动的时候发现并装载恶意的 dylib。因为该应用程序是由操作系统执行的,所以劫持者 dylib 能够在不断地重启之间偷偷地、不知不觉地 (stealthily and surreptitiously) 驻留着。

图 36 - 劫持 Apple 的照片流代理以确保驻留

关于驻留的、最后一个需要注意的地方是,如果没有发现随系统自动启动的、存在漏洞的应用程序时,任何可以被用户手动启动的、存在漏洞的应用程序 (如浏览器或邮件客户端等) 都可能会成为目标。换句话说,任何合法的、存在漏洞的程序都能很简单地以各种方式进行持久化 (即自启动,比如将其注册为 Login Item 等),然后再进行持久化的利用。虽然后者这种情形提高了攻击行为被发现的可能性,攻击者 dylib 当然也不会显示任何界面。因为,绝大多数用户好像都不会注意一个合法的 (Apple) 可执行文件自动在后台运行 (并被利用)。

进程注入,或者强制外部进程装载一个动态库,是另外一种有效的、dylib 劫持的攻击情境。在本文当中,“注入”指的是装载时注入 (即应用程序启动的时候),而不是 (opposed to) 运行时注入 (run-time injection)。尽管后者经过论证更加具有威力,但是前者远比它简单,并且大多数时候能够造成同样层次的破坏。

利用 dylib 劫持,来强制外部进程持久地装载恶意 dylib 是一项隐蔽而又有威力的技术。因为,同其它 dylib 劫持攻击的情况相似,它不需要对操作系统组件或二进制文件进行任何修改 (即给目标进程的、在磁盘上的二进制映像文件打补丁)。此外,因为植入的 dylib 将会反复地、自动地,在每一次目标进程启动的时候,被装载到目标进程空间当中,攻击者不再需要单独的监视器组件 (以检测目标进程何时启动,恶意 dylib 被装载)。而且,因为攻击者只需要简单地植入一个恶意的劫持者 dylib,它完整而巧妙地避免了 (neatly side-steps),运行时进程注入的复杂性。最后,因为这种注入技术利用了操作系统装载器的合法的功能,所以它似乎不会被个人安全产品所检测到 (安全产品一般通过监视“进程间通讯 (inter-process)”接口来组织远程进程注入)。

XcodeApple 的“集成开发环境 (Integrated Development Environment, IDE)” 应用程序。开发者用它来开发 OS X 和 iOS 应用程序。因此,它是高级黑客喜欢的目标 (juicy target),他们希望通过注入代码到 Xcode 的地址空间中,偷偷地感染开发者开发出的产品 (即作为一种新型自动化恶意软件传播机制 (a creative autonomous malware propagation mechanism)) Xcode 和它的各个辅助工具和实用工具,都容易受到 dylib 劫持攻击的威胁。特别地,run-path 依赖库,比如 DVTFoundationXcode 的主 run-path 搜索目录都无法被找到 (如图 37)。

图 37 - Apple 的易受威胁的 IDE,Xcode

Xcode 的进程注入能够相当直截了当地完成。首先,配置好一个劫持 dylib,使得它的版本号信息是兼容的,并且重导出了合法的 DVTFoundation 框架的所有符号。然后,将配置好的劫持者 dylib 拷贝到 /Applications/Xcode.app/Contents/Frameworks/DVTFoundation.framework/Versions/A/ 目录当中 (Frameworks/ 是主 run-path 搜索目录)。现在,一旦 Xcode 启动,恶意代码也会自动被装载。接下来,就可以自由地执行操作了,比如,拦截并中断编译请求,并且偷偷地植入恶意源代码或二进制代码到最终产品中。

正如 Ken Thompson 在他的开创性的工作 Reflections on Trusting Trust 中写到的一样,当你不能信任你的构建进程或编译器的时候,你甚至不能信任你自己编写的代码。

图 38 - 通过 dylib 劫持进行的进程注入

除了隐蔽驻留和加载时进程注入,dylib 劫持还可以用于绕过个人安全产品。具体是,通过巧妙地利用 (leveraging) dylib 劫持攻击,攻击者可以强制一个受信任的进程自动加载恶意代码,然后在执行一些之前被阻止或警告的行为,现在就不会被检测到了。

个人安全产品 (Personal security products, PSPs) 通过特征码,启发式行为分析来检测恶意代码,或者,简单地,在发生任何可疑事件时都警告用户。因为 dylib 劫持攻击是一项利用了系统合法功能的新技术,无论是基于特征码还是启发式的产品都能改被轻而易举地完全绕过。但是,像防火墙一类的安全产品,从未知进程发起的传出链接都会警告用户,给攻击者造成一些挑战。Dylib 劫持攻击也能够轻易地阻挠 (thwart) 这些产品。

个人防火墙在 OS X 平台的用户间很流行。它们通常使用一些二进制方式,完全信任从已知程序发出的出口网络连接,对由未知和不信任进程发起的的网络活动向用户给出警告。尽管这确实,对监测一般的恶意软件很有效,但是高级黑客们能够轻易地找到它们的弱点,绕过这些产品:信任。正如之前提到的,通常情况下,这类产品都拥有一个默认的配置规则,允许用户创建新的规则给已知的、受信的进程(例如,“允许任何来自进程 X 的传出连接”)。尽管这保证了,合法的通讯功能不会被阻碍,但是如果攻击者能够将恶意代码植入到可信进程的上下文中,这些代码就继承了进程的信任属性,因此防火墙将允许它的传出连接。

GPG Tools [17] 是 OS X 平台下的一个消息加密工具集,它提供了密钥管理、发送加密邮件,或者,通过插件向任意程序提供加密服务 (cryptographic services)。不幸的是,它的产品也容易 dylib 劫持攻击的影响。

图 39 - GPG Tools 易受威胁的钥匙串应用

因为 GPG Keychain 需要各种 Internet 功能 (比如,从密钥服务器上寻找密钥),所以基本上它都有着一条“允许所有传出链接”的防火墙规则,如图 40 所示。

图 40 - GPG 钥匙串的访问规则

采用 dylib 劫持,攻击者能够针对 GPG Keychain 应用程序,将恶意的 dylib 装载到它的地址空间中去。接下来,恶意的 dylib 将会继承和进程同样的信任等级,因此就应该能够发起任何传出连接而不引发警报。测试结果表明,劫持者 dylib 能够以一种无限制的方式访问 Internet (如图 41 所示)。

图 41 - 通过 dylib 劫持绕过一款个人防火墙 (LittleSnitch)

一些有着防御意识的人会准确的指出,在这种情况下,可以让防火墙针对 GPG Keychain 的规则更加严格,通过只允许到特定的访问点 (比如已知的密钥服务器) 的传出连接,来抵御此类攻击。然而,还存在其它无数的,易受威胁的程序,它们可以被劫持,然后类似地,获得同样无限制的网络访问权限。或者,在本例中,Little Snitch 防火墙,包含了无法删除的系统级的防火墙规则,默认允许任意进程连接到 iCloud.com 的端口。只需这一条来进行防火墙的绕过,就已经相当足够了 (比如,用一个远程的 iCloud iDrive 作为一个 C & C 服务器)。

到目前位置,dylib 劫持的情境都是在本地进行的。尽管它们是如此的强大,优雅,并且隐蔽,但是它们都需要接触到用户的计算机。然而,dylib 劫持技术同样可以被远程攻击者利用,用来协助,获取一台远程计算机的初始访问权限。

有许多办法来感染一台 Mac 电脑,但是最简单、最可靠的是,直接发送恶意内容到最终目标。这种比较“低端”的方式让用户主动下载,并安装恶意内容。攻击者可以创造性的利用多种技术来达到该目的,比如提供需要的插件 (以浏览内容),虚假升级包或补丁,虚假安全工具 (rouge Anti-Virus 产品),或者是一个被感染的种子文件。

图 42 - 伪装过的恶意内容

如果用户被欺骗,下载并运行了任何恶意内容,他们的计算机就会受到感染。尽管这是一种“低端”技术,其成功率却不可小觑 (underestimate)。事实上,当一款欺诈性质的安全程序 (Mac Defender) 以这种方式发布的时候,成百上千的 OS X 用户被感染了这款恶意软件,有超过 60,000 人联系 Apple Care 以解决这个问题 [18]。

依赖一些小骗术 (trickery) 来感染远程目标,对于有电脑安全知识的人群来说,就显得没有那么有效了。一个更可靠 (尽管更加先进) 的技术是,当用户下载合法软件时,对用户的连接进行中间人攻击 (man-in-the-middling)。由于苹果应用程序商店 (App Store) 的限制 (constraints),大多数软件依然是通过开发者或公司的网站来下载。如果这样的软件通过不安全的连接 (比如:http) 来下载,能够访问传输网络必需层级的攻击者,可以在传输过程中感染下载的文件。当用户运行了被感染的软件,他们的电脑就会被感染,如图 43 所示。

图 43 - 存在中间人的一次软件下载

读者可能会想,“嗨,现在是2015年了,大多数软件应该都是通过安全渠道下载的,不是吗?”不幸的是,即使是今天,绝大多数的第三方 OS X 软件都是通过不安全的渠道分发的。举个例子,在笔者的电脑上,66% 的软件都是从不安全的渠道下载的。

图 44 - 笔者的 Dock 栏中通过 HTTP 下载的软件

此外,更多研究显示,几乎所有的、主要的第三方 OS X 安全产品都类似,通过不安全的渠道进行分发 (见图 45)。

图 45 - 主要 OS X 安全产品的不安全下载

Apple 相当重视这类攻击,并且,从版本 OS X Lion (10.7.5) 开始,Mac 电脑都内置了一款安全产品 GateKeeper,用来直接抵御这些攻击向量。

Gatekeeper 的概念简单但有效:阻止任何不受信任的软件执行。在它的背后,实现起来有些复杂,但是从本文的角度来说,一个概括性的解释就足够了。当任何可执行内容被下载后,会被标记上“隔离 (quarantined)”属性。这些内容第一次被执行时,Gatekeeper 会验证这些软件。是否执行取决于用户的设置,如果这些软件没有用已知的 Apple 开发者 ID 签名 (默认),或者不是来自 Mac App StoreGatekeeper 将会阻止应用程序执行。

图 46 - Gatekeeper 的实际工作情况

随着新的版本的 OS X 内置并启用 Gatekeeper,欺骗用户安装恶意软件或是感染后的、不安全的下载内容 (这将破坏数字签名) 的情况,从大体上得以减轻。 (当然,攻击者可能试图获得一个有效的 Apple 开发者证书,然后签署他们的恶意软件。然而,Apple 对分发此类证书相当谨慎,此外,还有一个有效的证书撤销程序,如果发现任何证书滥用就可以阻止证书。此外,如果被设置为只允许运行从苹果应用程序商店的软件,这种滥用的情况就更不可能了。)

不幸的是,利用 dylib 劫持技术,攻击者能够绕过 Gatekeeper 来执行未签名的恶意代码,就算用户设置为仅允许来自 Mac App Store 并经过 Apple 签名的代码。这重新打开之前讨论的攻击方式的大门,将 OS X 用户又置于危险之中。

理论上,通过 dylib 劫持绕过 Gatekeeper 是合乎逻辑的。虽然 Gatekeeper 完全验证正在执行的软件包的内容 (例如,应用程序包中的每一个文件),但是它不验证“外部”组件。

图 47 - 假设能绕过 Gatekeeper 的 dmg/zip

因为 Gatekeeper 只验证内部内容,如果一个经过 Apple 签名的,或来自 Mac App Store 的应用程序包含一个相对的、外部的可以劫持的 dylib,攻击者就可以绕过 Gatekeeper。具体的,攻击者可以生成 (或者在传输途中感染) 一个 .dmg 或 .zip 文件,该文件中包含必要的目录结构,以满足在外部、引用相对的位置来包含恶意的 dylib。当合法程序被可信用户执行时,Gatekeeper 将会验证程序包,然后允许它执行。在进程加载阶段,dylib 劫持将会被触发,所引用的外部恶意 dylib 会被加载 —— 即使 Gatekeeper 被设置为只允许执行来自 Mac App Store 的代码!

找到一个满足需要的先决条件的漏洞程序相当简单。Instruments.app 是一个经过 Apple 签名的、“Gatekeeper” 认可的程序,一般情况下安装在 Xcode.app 的子目录中。因此,它包含了对其应用程序包外部 dylib 的相对引用,这些 dylib 就可以被劫持。

图 48 - Apple 的含有漏洞的 Instruments 应用

通过一个含有漏洞的可信程序,一个恶意的 .dmg 文件可以不触发并绕过 Gatekeeper

首先,Instruments.app 被打包进该映像。然后,建立一个外部目录结构,包含恶意的 dylib (CoreSimulator.framework/Versions/A/CoreSimulator)。

图 49 - 恶意的 .dmg 映像

为了使恶意的 .dmg 文件更加“可信”,外部文件可以设置为隐藏,在最上层的别名 (与自定义的图标) 指向 Instruments.app。背景也更换掉 (译者注:NSA 强力背锅),整个映像文件被设为只读 (所以双击的时候会自动显示)。最后的成果见图 50。

图 50 - 最终的恶意 .dmg 映像

将恶意 .dmg (虽然看起来是无害的 (benign)) 文件 “部署 (deploy)” 到一个公共的URL地址来进行测试。当通过 Safari 下载后执行,一条 Gatekeeper 标准的 ‘This is downloaded from the Internet’ 消息窗口弹了出来。值得注意的是,该消息对于任何的下载内容都会弹出,这并不是出现了什么异常。

一旦这个消息窗口被取消,恶意代码就会悄悄的同合法程序一起加载。当然,这本是不应该被执行的,因为 Gatekeeper 的设置是最严苛的 (只允许执行来自 Mac App Store 的程序)。见图 51。

图 51 - 通过 dylib 劫持绕过 Gatekeeper

因为恶意 dylib 会在程序的 main 方法之前被加载和执行,所以可以确保与正常情况无异。在本例中,恶意的 .dmg 文件伪装 (masquerades) 成一个 Flash 安装器,该恶意 dylib 可以阻止 Instuments.app 程序的界面弹出。取而代之的是一个合法的 Flash 安装器。

有了绕过 Gatekeeper 和加载未签名的恶意代码的能力,攻击者可以重新使用他们的老伎俩,让用户安装虚假的补丁,更新包或者安装包,虚假的反病毒产品,或者执行被感染的盗版程序。更糟糕的是,拥有网络级攻击技术的高级黑客 (可以截断不安全的连接的黑客) 现在可以任意地感染合法软件下载。再也不用担心 Gatekeeper 的拦截了。

防御

Dylib 劫持对于 OS X 平台来说是一种新型的、有威力的攻击技术,提供给本地和远程攻击者广泛的恶意攻击场景。不幸的是,尽管和 Apple 联系多次,他们也没有对此论文中描述的问题表示出任何兴趣。就算 (Granted) 没有简单的办法来解决防范 dylib 劫持的核心问题,因为它利用的操作系统的合法功能。无论如何,Gatekeeper 的作者也应该修补一下它,来防止未签名的恶意代码执行。

用户也许想知道,他们能做些什么来保护自己。第一,直到 Gatekeeper 得到修复之前,不推荐下载不可信软件或者来自不安全渠道 (比如在 Internet 上通过 HTTP 下载) 的合法软件。如果你一再重复并且按照遵守上面这句话,远程攻击者是不能获得通过本文中描述的方法获得一台电脑的初始控制权的。由于 OS X 平台上 dylib 劫持技术还不成熟,攻击者或者 OS X 恶意软件目前还只能在本地利用它,但是,这并不确定以后没有人会利用它做一些更具威胁性的事情!

为了探测本地劫持,同时发现存在漏洞的应用程序,作者开发了一款新应用 Dynamic Hijack Scanner (简称 DHS)。DHS 通过扫描整个文件系统所有的运行进程来尝试发现劫持攻击和漏洞。该程序可以在 objective-see.com 网站下载。

图 52 - Objective-seeDHS 扫描器

结论

DLL 劫持是影响 Windows 操作系统的、广为人知的攻击手段。直到现在,人们还以为,OS X 平台对此类攻击免疫。但本文推翻了这个假设。举例说明了 OS X 上也存在相似的 dylib 劫持攻击,并重现了这种攻击。通过利用弱依赖或 run-path 依赖导入项,找到了大量 Apple 和第三方程序中存在的漏洞,这类攻击可以巧妙适应多种攻击场景,包括本地,和远程攻击。从本地隐蔽驻留技术到给远程攻击提供捷径的 Gatekeeper 绕过技术,dylib 劫持正变为 OS X 平台黑客手中的强力武器。并且因为 Apple 对此类攻击表现漠不关心 (apathetic),OS X 用户目前只能下载安全软件和 DHS 一类的工具来确保自己是安全的……但这只能保证一时。

参考

1 Secure loading of libraries to prevent DLL preloading attacks. http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Components-PostAttachments/00-03-35-14-21/Secure-loading-of-libraries-to-prevent-DLL-Preloading.docx.

[2] DLL hijacking. http://en.wikipedia.org/wiki/Dynamic-link_library#DLL_hijacking.

[3] Dynamic-Link Library Hijacking. http://www.exploit-db.com/wp-content/themes/exploit/docs/31687.pdf.

[4] Windows NT Security Guidelines. http://www.autistici.org/loa/pasky/NSAGuideV2.PDF.

[5] What the fxsst? https://www.mandiant.com/blog/fxsst/.

[6] Leaked Carberp source code. https://github.com/hzeroo/Carberp.

[7] Windows 7 UAC whitelist: Proof-of-concept source code. http://www.pretentiousname.com/misc/W7E_Source/win7_uac_poc_details.html.

[8] Microsoft Security Advisory 2269637; Insecure Library Loading Could Allow Remote Code Execution. https://technet.microsoft.com/en-us/library/security/2269637.aspx.

[9] What is dll hijacking? http://stackoverflow.com/a/3623571/3854841.

[10] OS X loader (dyld) source code. http://www.opensource.apple.com/source/dyld.

[11] MachOView. http://sourceforge.net/projects/machoview/.

[12] Run-Path Dependent Libraries. https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html.

[13] Using @rpath: Why and How. http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/.

[14] Friday Q & A 2012-11-09: dyld: Dynamic Linking On OS X. https://www.mikeash.com/pyblog/friday-qa-2012-11-09-dyld-dynamic-linking-on-os-x.html.

[15] dylibHijackScanner.py & createHijacker.py. https://github.com/synack/.

[16] Reflections on Trusting Trust. http://cm.bell-labs.com/who/ken/trust.html.

[17] GPG Tools. https://gpgtools.org/.

[18] Apple support to infected Mac users: ‘You cannot show the customer how to stop the process’. https://nakedsecurity.sophos.com/2011/05/24/apple-support-to-infected-mac-users-you-cannot-show-the-customer-how-to-stop-the-process.

版权信息

Editor: Martijn Grooten

Chief of Operations: John Hawes

Security Test Engineers: Scott James, Tony Oliveira, Adrian Luca Sales

Executive: Allison Sketchley

Editorial Assistant: Helen Martin

Consultant Technical Editors: Dr Morton Swimmer, Ian Whalley

© 2015 Virus Bulletin Ltd, The Pentagon, Abingdon Science Park, Abingdon, Oxfordshire OX14 3YP, England.

Tel: +44 (0)1235 555139. Fax: +44 (0)1865 543153

Email: editorial@virusbtn.com

Web: http://www.virusbtn.com/