*本文翻译自火眼FireEye官网报告,这份报告对于研究苹果OS X系统的安全以及PC上的rootkit编写提供了非常好的思路。

FireEye实验室最近发现一款变种APT后门 - OSX.XSLCmd。这是一款针对苹果OS X系统的后门,其代码中有一部分和2009年出现的Windows后门XSLCmd几乎一致。

 

 

随着OS X系统的用户比例越来越多,这一研究也恰好印证了APT攻击的魔爪开始逐渐伸向了OS X系统平台。随着形势的发展,一些后门代码逐渐出现在苹果的OS平台上,例如从Windows上移植的一些清理历史记录的后门代码。

在2012年,AlienVault就发现一个利用Microsoft Word古老漏洞的文本文档,在OS X系统上运行就会被安装一个名为“MacControl”的后门程序。这个攻击曾被用来针对NGOs(非政府组织)团体。

在2013年,卡巴斯基通报了一个针对南韩和日本的军事、科技、公众媒体的APT渗透团队“IceFog”,这个团队就开发了针对Windows和Mac OS系统的后门。在今年卡巴斯基又通报了一个名为“Careto/Mask”的团队,针对OS X系统做了一个“sbd”的项目,类似于netcat这种通用于Windows和*nix的开源的东西。

根据以往的经验我们有理由相信XSLCmd是一个名为“GREF”的团队进行APT渗透的产物,这是一个非常具有威胁的团队,后面我们的分析会发现其擅长使用Google进行猎杀。

追踪“GREF”团队的活动踪迹我们最早追溯到了2009年,但是他们在这之前肯定还进行过入侵活动。

在我们的追踪历史上,GREF广泛的针对包括美国国防基础在内的各种组织,世界范围的电子和工程公司,非政府的基金组织登也是其目标,后者更偏向于亚洲范围的。

 

OS X上的XSLCmd分析

OS X上的XSLCmd是2014年8月14日提交到VirusTotal的(MD5: 60242ad3e1b6c4d417d4dfeb8fb464a1),样品程序是一个通用于x86,x86-64的CPU框架下的Mach-O可执行程序。

其代码中存在一个安装程序并会在第一次执行时安装,这是为了确保后续的父进程launchd的OS X初始用户模式以及守护进程等能够正常运转。

在过去的几年里,该后门程序的代码从Windows移植到OS X后被用来发起了多起有针对性的攻击行为,从这些攻击行为中看到后门的代码也被多次更新过。

这个后门的功能包括:

反弹shell命令行;
文件读取和传输;
下载安装其他的后门;
更新配置信息。

在捕获的XSLCmd后门的变种中我们还发现了两个额外的功能:

屏幕截取和键盘记录。

 

安装过程

XSLCmd安装的时候首先会确认CPU使用NXGetLocalArchInfo的字节顺序,并且会通过比较0和执行getuid()的返回值来确认是否为超级用户。而且程序会判断CPU字节顺序自然也包含函数来处理不同字节顺序的函数。也就是在使用PowerPC做处理器的旧的苹果电脑上以高字节在前的方式处理文件和网路数据。

这个过程会将Mach-O从当前位置拷贝到$HOME/Library/LaunchAgents/clipboardd,然后在同目录创建一个名为“com.apple.service.clipboardd.plist”的plist文件。这个文件的作用就是确保后门在开机时以用户的shell启动。

操作完成后,使用launchctl的load选项载入运行,而后门执行时,读取的配置文件就是前面提到的plist文件,而launchd就会作为其父进程。launchctl运行后,会将Mach-O从原来的位置删除,之后后门会等待并根据客户端发送来的命令完成实际的后门功能,如反弹shell、截屏等。

前面说后门程序除了会判断字节顺序,还会判断和处理getuid()是否为0的情况。如果安装时取得getuid为0,即超级管理员权限运行时,后门会将自身复制到/Library/Logs/clipboardd这个位置。

更有意思的是(其实美国人文章中的有意思跟中国人打字说呵呵是一个意思),后门安装过程中还会降Korn shell的可执行文件/bin/ksh拷贝到/bin/ssh,这样做的目的是,一旦用户执行了初始化反弹shell的命令,后门程序可以使用ksh的拷贝来代替/bin/bash。

所以后门的反弹shell在系统中不会那么刺眼,当用户察觉到一些异常时,反而可能会觉得这是SSH的一个网络套接,而不是bash的进程。当然了,真正的SSH的位置是/usr/bin/ssh而不是后门拷贝的/bin/ssh。

*XSLCmd可能创建的文件列表将附在本文末尾。

 

配置文件

XSLCmd附带的加密的配置文件,如果配置文件不存在或者配置更新则向硬盘写入新的配置文件。检查配置更新和客户端指令是一个循环函数,如果收到新的配置文件,后门将以Base64编码方式写入$HOME/.fontset/pxupdate.ini。

下面是我们捕获的XSLCmd样品中的配置文件:

[ListenMode]
0
[MServer]
61.128.110.38:8000
[BServer]
61.128.110.38
[Day]
1,2,3,4,5,6,7
[Start Time]
00:00:00
[End Time]
23:59:00
[Interval]
60
[MWeb]
http://1234/config.htm
[BWeb]
http://1234/config.htm
[MWebTrans]
0
[BWebTrans]
0
[FakeDomain]
www.appleupdate.biz
[Proxy]
0
[Connect]
1
[Update]
0
[UpdateWeb]
not use


[Mserver]是Main Server的意思,[BServer]是backup server的意思,明显上线地址的意思,这里可以是域名可以是ip地址,不过[Mserver]这里需要指定端口;

[day]标签指定了后门进行循环更新配置文件和指令的日期,1代表周一,以此类推;

[Start Time]和[End Time]指定了上面执行的开始时间和结束时间;

[Interval]表示两次循环执行的间隔时间;

[MWeb]和[BWeb]可以参见前面[MServer]和[Bserver],如果不配置则默认值为http://1234/config.htm

*其他几项非关键标签的解释也会附在末尾。

 

客户端协议

XSLCmd使用拟HTTP协议进行通讯。程序会根据[Listen Mode]的设置来套用预制模板进行HTTP请求和响应头,如果[Listen Mode]的设置为1,则后门使用socket进行通讯并且使用如下响应头模板的HTTP请求来建立连接:

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Server: Apache/2.0.54 (Unix)
Content-Encoding: gzip
Content-Length: %d


无论监听模式设置是什么,响应头之后都会包含特定的通讯数据。这些通讯数据时是加密的,加密方式取自一个名为“My Destiny Team”团队开发的游戏引擎,响应头部中俄Host和Referer部分都是会使用[FakeDomain]标签中设置的值,其实这个值就算随意写,也不会建立网络连接造成影响。请求中的URL参数当然也是随机生成的,所有除了Content-Length的参数外,都是预制的值。

 

 

如果[MWebTrans]或[BWebTrans]配置为1,程序的配置更新函数会使用Yahoo的Babelfish代理服务,如果失败则会退回到Google的翻译服务。

 

 

如图所示,URL中的turl参数会使用[MWeb]/[BWeb]标签中预制的值。响应头中的User-Agent信息是计算机的信息,括号中还包含了计算机名。

我们在分析过程中发现有SSL传输数据,但是没有可供参照的证书明文,不过好在之前有一个旧的数据证书参照,我们使用WireShark从PCAP当中提取执行程序。

 

 

这些SSL数据包似乎是会话头,但是呵呵的是会话包服务端中几乎包含了需要的所有数据包,这个旧的证书是用于login.live.com上面的,但是在2010年6月16日就到期了。

使用这些数据创建会话并等待连接,客户端与SSL建立会话后会丢弃所有收到的数据包,这些代码不会直接通过其他代码被引用,但有可能代替[Listen Mode]的代码,很可能这些SSL数据是一些陈旧不用的功能,或者可能是没有完成的功能,要不然就是一些特定情况下才用的功能。

 

评测

我们注意到整个代码中混杂着一些其他的代码引用,有的排列在同一个函数中,感觉应该是基于原始代码的二次修改,加入了新的风格和元素。

 

 

另外,如果XSLCmd以超级用户身份执行,则不会有执行时候的key日志,这样很成问题,因为执行key记录的API是CGEventTapCreate,当它使用参数调用时要求应用程序必须启用root权限的进程或“辅助驱动”的功能。

而初始安装时,如果不是OX X 10.8的话就有一个常规的编程方式启用辅助驱动,在10.9中应用程序实现辅助驱动权限不需要API就可完成。

侧面反映什么呢,编写者没有考虑10.8以上系统的情况可能是因为编写程序时的系统版本也就是10.8,当然,也不排除当时最普及的是10.8版本的系统。虽然系统有支持PowerPC的转换函数,但是作者可能并没有在10.9的系统版本上进行测试,变种后门使用私有Admin框架的API在10.9系统中不再支持导致其程序崩溃。

基于对代码的比较、版本的测试等评测,该后门符合编程向旧版本兼容的习惯。另外苹果第一款放弃PowerPC的系统10.6发布于2009年,而OS X 10.9发布于2013年9月。

 

历史背景

GREF是已知的不依赖网络邮件钓鱼的APT团队,非常具有威胁性,但实际上他们是最早一批采用Web入侵挂马,通过恶意附件、链接等渗透个人的团队之一。

2010年是GREF最活跃的一年,并且提前获得了一些0day信息,例如CVE-2010-0806(IE 6-7漏洞),CVE-2010-1297 (Adobe Flash漏洞)和CVE-2010-2884 (Adobe Flash漏洞)等,并将其用于网络钓鱼和Web入侵。

一些国防工业的站点信息例如cdi.org,工业协会ndia.org,部队行业培训,教育业iitsec.org和卫星公司millennium-space.com等都曾留下过他们的足迹。

大部分攻击其实都是向网页中嵌入恶意代码,当然GREF不像一些杂牌军一样直接在页面末尾追写挂马代码,而是尿性的使用Google Analytics的正常代码将恶意代码掩盖。

例如:

<!— Google Tracking Code —>
<script type=”text/javascript”>
var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://”);
[removed](unescape(“[removed][removed]”));
</script>


和大部分团队一样,利用漏洞搞到Web服务器多是为了搞更多的平台用来入侵或者是为了进入组织或公司内网,毫无遮掩的攻击通常会产生甚至GB的数据流量,而且会使用一些开源的工具进行入侵。例如SQLmap进行注入,WVS扫漏洞,还经常利用ColdFusion,Tomcat,JBoss,FCKEditor和一些其他应用的漏洞,拿到Web权限之后,大家都懂得。。

另外一些已知的信息是,早期GREF频繁的使用210.211.31.x(香港),180.149.252.x(香港),120.50.47.x(新加坡)这几个ip进行攻击,还会使用Google的hk域名进行以关键字为filetype和inurl的搜索。

 

客户端域名

比较操蛋的是,GREF通常配置上线地址都是直接用的ip而不是域名,但是我们还是努力不懈的搞到了他们注册的几个用来上线的域名。

 

 

总结

后面杂七杂八的所谓的犯罪证据监测报告之类的就不copy了,GREF差不多应该都洗白了吧,FireEye追踪这么久也难为你们了。

//silic.wiki

最后附XSLCmd创建的文件列表: