iOS/Malware（六）XCodeGhost分析
（原文2015年09月20日发在Antiy官网，Xcode非官方版本恶意代码污染事件（XcodeGhost）的分析与综述，pdf版本，其实事件响应还是很及时的，微博上曝光当天就已经完成了分析，但整体报告一直达不到seak要求，反复修改最后成了总结文章了。事件前因后续不再赘述，仅贴上个人分析部分）
1、样本信息
- 样本名：CoreService
- 位于XCode位置：（iOS、iOS模拟器、MacOSX三个平台）
./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
./Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- 样本形态：库文件（iOS、iOS模拟器、MacOSX三个平台）
- 样本信息：
| 文件名 | 平台 | 要求系统版本 | md5 | 上传域名 | 关键信息形式 | 读取剪贴板 | 弹框 | openURL | 文件平台结构 | 说明 |
|---|---|---|---|---|---|---|---|---|---|---|
| CoreService | iOS/iOS模拟器 | 6.0 | 4fa1b08fd7331cd36a8fc3302e85e2bc | init.icloud-analysis.com | 字符串 | 无 | 有 | 有 |  |
iOS模拟器与iOS平台使用同一库文件
CoreService库里面同时包含iOS的ARM版本和模拟器的X86版本
|
| 7.0 |
40e4342b04a3cedcb4eaa01a1b68f40e
5e5425b47df510b0cacb9665db8aeed5
| 字符拼接 | 有 | 有 | 有 | |||||
| MacOSX | － |
8a4be8036fa874a664d9299cf2b3ea74
6881744ee3ccd9e3f625b02141b55c20
5240c964c9efad9f2c6ed4ac9968cb7e
| － | － | － | － | － |  |
该部分文件实际无完整有效的恶意代码
由于捕获受感染XCode版本不全，不排除存在其他含有效代码版本
即可能存在感染MacOSX应用的方式（未证实），至少此处代码能佐证攻击者据有潜在对MacOSX的攻击意图
|
2、感染方式
2.1 攻击机理
这次攻击本质上是通过攻击xcode间接攻击了自动化构建和编译环境，目前开发者不论使用xcode server还是基于第三方工具或自研发工具都是需要基于xcode
而这次如此大面积的国内产品中招，则只能反映大量产品研发团队的产品开发和构建环境的维护以及安全意识都呈现比较大的问题
图 基于XCode的开发流程
2.1.1 恶意插件植入XCode方式
也许出于对XCode稳定性和植入方便考虑，恶意代码实际并没有对XCode工具进行太多修改
主要是添加了如下文件：
- 针对 iOS
- Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework
- 针对 iOS 模拟器
- Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework
- 针对 Mac OS X
- Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/CoreService
- Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/Library/PrivateFrameworks/IDEBundleInjection.framework
以及修改了配置文件：
- Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec
2.1.2 恶意插件植入App方式
- 被攻击的开发环节：编译App项目部分
- 恶意代码植入机理：通过修改Xcode配置文件，导致编译Linking时程序强制加载恶意库文件
- 修改的配置文件：Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec
- 添加的语句：“-force_load $(PLATFORM_DEVELOPER_SDK_DIR)/Library/Frameworks/CoreServices.framework/CoreService”
与官方版本配置文件对比
2.2 恶意代码运行时间
- 恶意代码植入位置：UIWindow (didFinishLaunchingWithOptions)
- 恶意代码启动时间：App启动后开启准备展示第一个页面时恶意代码已经执行了
- iOS应用启动流程：从代码执行流程来看，下图中每一步都是可以作为恶意代码植入点的，且其框架基本都是由模版自动生成，而UIWindow为iOS App启动后展示页面时执行
图 iOS应用启动流程（图出自http://oleb.net/blog/2012/02/app-launch-sequence-ios-revisited/）
- UIWindow生成方式
通常通过模板建立工程的时候，xcode会自动生成一个window，然后让它变成keyWindow并显示出来；
由于是模版自动生成，所以很多时候都容易被开发人员忽略掉这个UIWindow对象，也是这次被植入恶意代码位置的原因之一
- 恶意代码启动时机分析：
恶意代码植入于UIWindow (didFinishLaunchingWithOptions)中，其入口点为： __UIWindow_didFinishLaunchingWithOptions__makeKeyAndVisible_；
UIWindow是作为包含了其他所有View的一个容器，每一个程序里面都会有一个UIWindow；
而didFinishLaunchingWithOptions里面的代码会在UIWindow启动时执行，也就是说，被感染app在启动时候开始准备展示界面就已经在执行被植入的恶意代码了；
图 恶意插件植入的代码入口点
3、危害分析
3.1 上传隐私
- init.crash-analytics.com
- init.icloud-diagnostics.com
其中6.0版本URL为字符串形式，而到7.0版本URL则进化到字符拼接
而7.0版本中还可以获取应用剪贴板信息
图 获取上传的信息
3.2 任意弹窗
恶意代码可以远程设置任意的弹窗信息，包括弹框标题、内容、推广应用id、取消按钮、确认按钮；
需要注意的是该部分代码并没有使用输入框控件，同时也并无进一步的数据回传的代码，因此是不能直接高仿伪造系统弹窗钓鱼获取Apple ID输入和密码输入的（这点在诸多已公开分析报告中均有一定误导性）
3.3 远控模块
一、openURL远控
恶意代码包含了一个使用openURL的远控模块，该模块可以用来执行从服务器获取到的URL scheme
其使用canOpenURL获取设备上可以定义了的URL scheme信息，并从服务器获取URL scheme通过openURL执行
二、URL scheme能力
URL scheme功能强大，通过openURL可用实现很多功能；
但需要注意的是，URL scheme所能达到的功能与目标app权限有关，如拨打电话、发送短信需要被感染应用具有相应权限
但如果其他app或系统组件有URL scheme 解析漏洞、webview漏洞等，则能相应执行更多行为
由于服务器已经关闭，同时该样本也没有明显证据表明具体使用了哪些URL scheme
以下为恶意代码所能做到的行为分析：
- 调用App
- 结合弹窗推广应用，App Store&企业证书应用皆可
3.4 中间人利用
虽然恶意代码使用的域名已经被封，但由于其通信数据只是采用了DES简单加密，很容易中间人重定向接管所有控制
当使用中间人攻击、DNS污染时，攻击者只需要将样本中服务器域名解析到自己的服务器，即可接管利用所有被感染设备，进而获取隐私、弹窗欺诈、远程控制等
其中恶意代码使用的DES密钥生成比较巧妙，先定义一个字符串”stringWithFormat“，再截取最大密钥长度，即前八个字符”stringWi“
DES标准密钥长度为56位，加上8个奇偶校验位，共64bit即8个字节
图 DES密钥生成方式
所以即便恶意代码服务器已经失活，依然建议用户及时更新被感染App版本，若仍未更新版本的App建议立即卸载或尽量不要在公共WIFI环境下使用，请等待新版本发布
4、校验Mac&iOS app方式
本次事件导致大量原厂发布的APP遭到污染的重要原因是，其开发发布团队未坚持原厂下载，也并未验证所下载的开发工具的数字签名。
同时我们发现有很多分析团队向开发者提供了完整的官方Xcode文件的Hash，但我们认为直接对应用进行数字签名验证可能是更高效的方法。
4.1 Mac&iOS app签名方式
OS X和iOS应用使用相同的签名方式，即：
1、在程序包中新建 _CodeSignature/CodeResources 文件，存储了被签名的程序包中所有文件的摘要信息
2、使用私钥 Private Key 对摘要进行加密，完成代码签名
4.2 Mac上官方签名工具codesign验证App方式
Mac上可以使用官方codesign工具用来对Mac&iOS app进行签名验证；
codesign工具属于XCode Command Line Tools套件之一，可以使用如下方式获取安装，推荐使用1、2方式：
- Terminal里执行：xcode-select --install
- Mac App Store里安装
- 安装 brew 后执行 brew doctor 自动安装
- 在Developer Apple网站下载安装：https://developer.apple.com/downloads/
图 Developer Apple上的Command Line Tools工具
4.2.1 获取app签名证书信息
使用codesign -vv -d xxx.app 指令可以获取app的签名信息
如验证官方XCode7.0，方框内Authority信息即该应用的证书信息，其中：
Authority=Apple Root CA，表示发布证书的CA机构，又称为证书授权中心
Authority=Apple Worldwide Developer Relations Certification Authority，表示证书的颁发中心，为Apple的认证部门
Authority=Apple Mac OS Application Signing，表示证书所有者，即该应用属于Mac App Store签名发布
而验证含XCodeGhost恶意插件的XCode6.4应用，其所有者为“Software Signing”，说明非Mac App Store官方渠道发布
4.2.2 验证app的合法性
为了达到为所有文件设置签名的目的，签名的过程中会在程序包（即Example.app）中新建一个叫做
_CodeSignatue/CodeResources 的文件，这个文件中存储了被签名的程序包中所有文件的签名。
使用codesign --verify xxx.app 指令可以根据_CodeSignatue/CodeResources文件验证app的合法性
校验官方XCode应用，验证通过，没有任何提示
校验含XCodeGhost恶意插件的XCode应用，验证失败，出现提示，说明应用在签名之后被修改过
图 官方推荐使用spctl工具校验XCode合法性
如下图，上面为正版XCode验证信息，表明来源为Mac App Store；
而下面为恶意XCode工具验证信息，没有任何来源信息；
0 评论:
发表评论