利用Firefox 0day传播的macOS恶意软件（Part 1）

栏目: 编程工具 · 发布时间: 5年前

内容简介：大概在一星期之前，我收到了某个用户发出的一封邮件：上周三，攻击者通过尚未公开的一个Firefox 0day攻击了我，不知道用什么方法将一个程序释放到我的mac主机上（10.14.5）然后执行。

利用Firefox 0day传播的macOS恶意软件（Part 1）

0x00 前言

大概在一星期之前，我收到了某个用户发出的一封邮件：

上周三，攻击者通过尚未公开的一个Firefox 0day攻击了我，不知道用什么方法将一个程序释放到我的mac主机上（10.14.5）然后执行。

我觉得你可能对这个文件比较感兴趣，这可能是绕过gatekeeper的一种有趣方法，值得研究一下。

我当然很感兴趣，但当时我正在写另一篇文章（大家可以点击 此处 阅读该文章），有点腾不出手来。

现在尘埃落定，我想借此机会深入研究这次攻击行为，分析其中涉及到的持久化恶意软件。

0x01 Firefox 0day

用户联系我时，我还没有太多掌握此次攻击中使用的Firefox 0day，然而现在我已经拿到了足够多信息。

一开始用户提供的邮件内容如下（翻译版）：

XXX：

您好，我叫Neil Morris，是亚当斯奖（Adams Prize）组委会的一名成员。

每年我们都会更新独立专家团队成员，这些专家需要评审参选项目（ http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize）的质量。

我的同事推荐您加入这一领域的专家团队中。

我们需要您参评竞争亚当斯奖的几个项目。

期待您的回复。

祝好，

Neil Morris

这里提一下，即便攻击者拥有浏览器0day利用技术，他们仍需要找到方法将攻击payload投递给目标用户。

选定目标后，攻击者通常会选择电子邮件作为投递方式，邮件中包含指向恶意网站的链接（当用户访问该网站时可以投递漏洞利用payload）。

不幸的是，当时该链接（ people.ds.cam.ac.uk/nm603/awards/Adams_Prize ）已失效，返回 404 Not Found 错误： 

$ curl http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /nm603/awards/Adams_Prize was not found on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at people.ds.cam.ac.uk Port 80</address>
</body></html>

当然有可能该站点只为该攻击活动提供服务，只有当用户通过存在漏洞的Firefox浏览器、或者通过特定IP地址等来访问时，才会触发攻击过程。也有可能攻击过程已经结束，攻击者关闭了该站点。

虽然我无法获得利用代码，但用户依然向我提供了攻击过程中安装在他系统中的恶意软件（名为 Finder.app ）。

本文将对这款恶意软件进行详细分析（哈希： 23017a55b3d25a2597b7148214fd8fb2372591a5 ）。 

$ shasum -a 1 ~/Attack/Finder.app/Contents/MacOS/Finder 
23017a55b3d25a2597b7148214fd8fb2372591a5  Finder

有趣的是，来自Coinbase的一名安全研究者（ Philip Martin ）在今天发表了一则比较有趣的 推文 ：

利用Firefox 0day传播的macOS恶意软件（Part 1）

Phil提供的哈希值（ 23017a55b3d25a2597b7148214fd8fb2372591a5 ）刚好与用户发给我的恶意文件相匹配。此外用户还提到一个信息，最近他“参与了加密货币交易事宜”。综合这些信息，很有可能我和Phil讨论的都是同一个Firefox 0day。

这个0day现在对应的编号为CVE-2019-11707，已经被修复，其他文章中也提到了这个漏洞：

然而，关于攻击中使用的后门恶意软件资料较少（或者没有），因此我们可以深入分析一下。

0x02 Mac后门分析（OSX.NetWire.A）

前面提到过，受害者向我提供了攻击者（通过Firefox 0day）安装在系统上的恶意后门（ Finder.app ）。

利用Firefox 0day传播的macOS恶意软件（Part 1）

在VirusTotal上搜索对应的哈希后（ 23017A55B3D25A2597B7148214FD8FB2372591A5 ），我找到了一个匹配结果，显示这个文件已于2019-06-06提交，但目前只有一个反病毒引擎能够检测到：

利用Firefox 0day传播的macOS恶意软件（Part 1）

备注：完整的应用程序包 Finder.app 今天才被提交到VirusTotal上，同样只有一个AV引擎能够检测。

有趣的是，这个反病毒引擎将其标记为 OSX.Netwire 。

OSX.Netwire （或者 OSX.Wirenet ）最早于2012年被Dr Web发现。在这篇 研究文章 中，Dr Web表示这是“历史上第一款能够窃取 Linux 及MacOS X密码的后门”。

恶意软件通过键盘记录器以及/或者直接通过磁盘上的文件（比如已保存的浏览器登录信息）来窃取密码：

$ strings malware/2012/OSX.Netwire

%s/Library/Opera/wand.dat
%s/.Library/Opera/wand.dat

SeaMonkey
Thunderbird

%s/Library/Application Support/Firefox

%s/signons.sqlite

NSS_Init
PK11_GetInternalKeySlot
PK11_Authenticate
NSSBase64_DecodeBuffer

select *  from moz_logins

但这是2012年时的 OSX.Netwire ，现在这款恶意软件是否还是 OSX.Netwire ？我个人从2012年后再也没听到过关于 OSX.Netwire 的任何信息，因此决定研究一下。

首先，我们可以通过简单的字符串匹配方法，确认2012年的样本与2019年的样本有所关联。

比如，2012年样本中包含 \x03\x04\x15\x1A\r\nexit\r\n\r\nexit\n\n 字符串： 

esi = "/bin/sh";
if(access(esi) != 0x0) {
   esi = "/bin/bash";
}

...

eax = write$UNIX2003(*0x140d0, "x03x04x15x1Arnexitrnrnexitnn", 0x15);

同样，2019年样本中也包含该特征：

if(stat("/bin/sh", edi) != 0x0) {
   ebp = "/bin/bash";
}

...

write$UNIX2003(ebx, "x03x04x15x1Arnexitrnrnexitnn", 0x15)

此外还有一些特殊的字符串也能在两个样本中找到。

在与小伙伴（安全研究员）交流时，他注意到XProtect已经能够检测到这个新样本。

XProtect是Apple在macOS中内置的反恶意软件系统，大家可以参考 此处 了解更多信息。

我对此有所怀疑（因为我记得XProtect最近并没有关于 OSX.Netwire 的任何更新），然而事实证明小伙伴是正确的。

2016年，Apple添加了一个Yara特征，用来检测 OSX.Netwire.A 。这个特征（参考 /System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara ）如下所示： 

rule NetwireA
{
    meta:
        description = "OSX.Netwire.A"
    strings:
        $a = "exitexit"
        $b = "User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like GeckoAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
    condition:
        all of them
}

我们可以使用Digita的 UXProtect 工具以图形界面显示该特征：

利用Firefox 0day传播的macOS恶意软件（Part 1）

还可以利用 UXProtect 确认（2016年推出的）这个特征依然可以检测此次Firefox 0day攻击中使用的恶意软件：

利用Firefox 0day传播的macOS恶意软件（Part 1）

Apple之前提供的特征竟然还能检测这个“新的”威胁！

有趣的是Apple的特征并不能检测2012年的样本（因为该样本不包含 User-Agent: Mozilla... ）字符串，这表明虽然这两个样本有所关联，但也存在不同之处。

目前我还找不到有关于这个新样本的（公开）资料。

有趣的是，Intego在2016年曾发表过关于Apple XProtect的一篇小文章： Apple Updates XProtect Malware Definitions for NetWeirdRC 。

然而，他们（以及其他人）引用的都是2012年的样本，而该样本并不能被Apple的 OSX.Netwire.A YARA特征检测到。

通常情况下，这表明Apple已经知道一些信息，但不愿与大家分享，或者也有可能不愿意与我分享：

利用Firefox 0day传播的macOS恶意软件（Part 1）

虽然2012年和2019年的样本明显有关联，但也有很多不同点。我们会在Part 2中透露更多细节，深入分析（新版）恶意软件样本的功能。简而言之，2012年及2019年样本的目标完全不同。我猜测这两款恶意软件都由同一个开发者（或者团队）编写，但服务于不同的目的（比如2012年的样本只关心密码窃取）。

在总结Part 1之前，我们来看一下新版 OSX.NetWire.A 如何实现本地驻留。

快速查看恶意软件的反汇编代码后，我们可以找到其中内置的一个启动代理plist：

memcpy(esi, "<?xml version="1.0" encoding="UTF-8"?>n<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//ENnt"http://www.apple.com/DTDs/PropertyList-1.0.dtd">n<plist version="1.0">n<dict>n    <key>Label</key>n    <string>%s</string>n    <key>ProgramArguments</key>n<array>n        <string>%s</string>n    </array>n    <key>RunAtLoad</key>n    <true/>n    <key>KeepAlive</key>n    <%s/>n</dict>n</plist>");

...        
eax = getenv("HOME");
eax = __snprintf_chk(&var_6014, 0x400, 0x0, 0x400, "%s/Library/LaunchAgents/", eax);

...
eax = __snprintf_chk(edi, 0x400, 0x0, 0x400, "%s%s.plist", &var_6014, 0xe5d6);

因此有理由推测该恶意软件会以启动代理方式实现驻留。

然而，恶意软件中还包含以登录项实现驻留的代码逻辑（注意其中调用了 LSSharedFileListInsertItemURL API）: 

eax = __snprintf_chk(&var_6014, 0x400, 0x0, 0x400, "%s%s.app", &var_748C, &var_788C);
eax = CFURLCreateFromFileSystemRepresentation(0x0, &var_6014, eax, 0x1);
...

eax = LSSharedFileListCreate(0x0, **_kLSSharedFileListSessionLoginItems, 0x0);

...
eax = LSSharedFileListInsertItemURL(eax, **_kLSSharedFileListItemLast, 0x0, 0x0, edi, 0x0, 0x0);

在虚拟机中运行恶意软件后，我们发现恶意软件同时采用了这两种方法。首先是作为启动代理（ com.mac.host.plist ），然后是作为登录项： 

$ cat ~/Library/LaunchAgents/com.mac.host.plist
{
    KeepAlive = 0;
    Label = "com.mac.host";
    ProgramArguments =     (
        "/Users/user/.defaults/Finder.app/Contents/MacOS/Finder"
    );
    RunAtLoad = 1;
}

由于这个启动代理（ com.mac.host.plist ）设置了 RunAtLoad 键（值为 1 ），因此每次用户登录时，系统会自动运行指定的程序（ .defaults/Finder.app/Contents/MacOS/Finder ）。

登录项也可以确保恶意软件能被运行。然而登录项会显示在UI界面中，这显然不利于恶意软件实现隐蔽驻留：

利用Firefox 0day传播的macOS恶意软件（Part 1）

采用两种驻留机制是不是比一种机制更好？不一定，如果大家使用了Objective-See提供的 BlockBlock 工具，就能轻松检测到这两种驻留机制：

利用Firefox 0day传播的macOS恶意软件（Part 1）

关于以登录项（以及 backgroundTaskManagementAgent 角色）实现驻留，大家可以参考我最近的一篇 文章 了解更多细节。

我们也可以使用 KnockKnock ，通过探测恶意软件的驻留方式来检测系统是否已被感染。

可能恶意软件开发者需要确保自己能万无一失实现驻留，才采用这种攻击方式。

0x03 总结

在本文中，我们讨论了针对加密货币交易的一种较为复杂的持久化payload。攻击者利用Firefox 0day将恶意软件部署到目标macOS中。

有趣的是，这个恶意软件为 OSX.NetWire.A ，与2012年同名的样本有一定联系，并且Apple于2016年部署的检测特征能成功发现这款恶意软件，但其实事情没那么简单。

在受害者的原始邮件中，曾提到这款恶意软件可以绕过Gatekeeper。这一点其实很正常，因为恶意软件采用的是远程0day漏洞进行投递。Gatekeeper只会扫描带有隔离属性集的应用程序，而只有当应用程序通过常见方式进行下载时（比如通过用户点击），浏览器等应用或者操作系统才会在下载的程序中添加这些属性集。通过漏洞利用代码下载的payload（比如恶意应用）并不会设置隔离属性（或者可以移除这些属性），因此就不会触发Gatekeeper。

我曾经在2016年的一次 演讲 中提到过这一点。

利用Firefox 0day传播的macOS恶意软件（Part 1）

同样，XProtect只会对设置了隔离属性的文件进行操作。然而，macOS 10.15（Catalina）可能会 修改 这种机制。

由于攻击者采用的特殊感染方式（通过Firefox 0day），Gatekeeper以及XProtect都无法保护用户。因此，单纯依赖系统提供的安全保护机制永远都不是明智之举。


以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍
Effective JavaScript

Effective JavaScript

David Herman / Addison-Wesley Professional / 2012-12-6 / USD 39.99

"It's uncommon to have a programming language wonk who can speak in such comfortable and friendly language as David does. His walk through the syntax and semantics of JavaScript is both charming and h......一起来看看 《Effective JavaScript》 这本书的介绍吧!

码农工具
图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具

  • New
  • 文章
  • 话题
  • 教程
    • 关注 码农网 公众号
    版权所有，保留一切权利！© 2018-2024 码农网 粤ICP备17054400号-3