Xcode非官方版本恶意代码污染事件(XcodeGhost)的分析与综述 - APT防御产品

Xcode非官方版本恶意代码污染事件(XcodeGhost)的分析与综述

1. 背景

Xcode 是由苹果公司开发的运行在操作系统Mac OS X上的集成开发工具(IDE),是开发OS X 和 iOS 应用程序的最快捷的方式,其具有统一的用户界面设计,同时编码、测试、调试都在一个简单的窗口内完成。[1]
自2015年9月14日起,一例Xcode非官方供应链污染事件在国家互联网应急中心发布预警后,被广泛关注,多数分析者将这一事件称之为 “XcodeGhost”。攻击者通过对Xcode进行篡改,加入恶意模块,进行各种传播活动,使大量开发者获取到相关上述版本,建立开发环境,此时经过 被污染过的Xcode版本编译出的App程序,将被植入恶意逻辑,其中包括向攻击者注册的域名回传若干信息,并可能导致弹窗攻击和被远程控制的风险。
截止到2015年9月20日,各方已经累计发现共692种(如按版本号计算为858个)App确认受到感染。同时,有分析团队认为,相同的攻击者或团队可 能已经对安卓开发平台采用同样的思路进行了攻击尝试。从其感染面积、感染数量和可能带来的衍生风险来看,其可能是移动安全史上最为严重的恶意代码感染事件 之一,从影响范围上来看能与之比肩的仅有此前臭名昭著的Carrier IQ[2]。
目前,Unity 3D也被发现由同一作者采取攻击Xcode手法类似的思路进行了地下供应链污染。

鉴于此事态的严重性,安天安全研究与应急处理中心(Antiy CERT)与安天移动安全公司(AVL Team)组成联合分析小组,结合自身分析进展与兄弟安全团队的分析成果,形成此报告。

2. 作用机理与危害

安天根据Xcode非官方供应链污染事件的相关信息形成了图2-1,其整体污染路径为官方Xcode被攻击者植入恶意代码后,由攻击者上传到百度云 网盘等网络位置,再通过论坛传播等方式广播下载地址,导致被App开发者获取,同时对于攻击者是否利用下载工具通过下载重定向方式扩大散布,也有较多猜 测。有多个互联网公司采用被污染过的Xcode开发编译出了被污染的App,并将其提交至苹果App Store,且通过了苹果的安全审核,在用户获取相关App进行安装后,相关应用会被感染并回传信息至攻击者指定域名。


图 2-1 Xcode非官方供应链污染事件示意图

2.1 作用机理

2.1.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库里面同时包含iOSARM版本和模拟器的X86版本。

7.0

40e4342b04a3cedcb4eaa01a1b68f40e

5e5425b47df510b0cacb9665db8aeed5

init.crash-analytics.com

init.icloud-diagnostics.com

字符

拼接

MacOSX

8a4be8036fa874a664d9299cf2b3ea74

6881744ee3ccd9e3f625b02141b55c20

5240c964c9efad9f2c6ed4ac9968cb7e

该部分文件实际无完整有效的恶意代码;

由于捕获受感染Xcode版本不全,不排除存在其他含有效代码版本;

即可能存在感染MacOSX应用的方式(未证实),至少此处代码能佐证攻击者具有潜在对MacOSX的攻击意图。

2.1.2 感染方式

2.1.2.1 攻击机理

这次攻击本质上是通过攻击Xcode间接攻击了自动化构建和编译环境,目前开发者不论是使用Xcode Server还是基于第三方工具或自研发工具都需要基于Xcode。而这次如此大面积的国内产品中招,则只能反映大量产品研发团队在产品开发和构建环境的 维护以及安全意识上都呈现出比较大的问题。


图 2-2基于Xcode的开发流程(第三方图片)[4]

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. 恶意插件植入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-3受感染Xcode与官方版本配置文件对比

2.1.2.2 恶意代码运行时间

  • 恶意代码植入位置:UIWindow (didFinishLaunchingWithOptions);
  • 恶意代码启动时间:App启动后,开启准备展示第一个页面时恶意代码已经执行了;
  • iOS应用启动流程:从代码执行流程来看,图2-4中每一步都可以作为恶意代码植入点,且其框架基本都是由模板自动生成,而UIWindow为iOS App启动后展示页面时执行。

图 2-4 iOS应用启动流程(第三方图片)[5]

  • UIWindow生成方式:

通常通过模板建立工程时,Xcode会自动生成一个Window,然后让它变成keyWindow并显示出来;由于是模板自动生成,所以很多时候开发人员都容易忽略这个UIWindow对象,这也是此次Xcode被植入恶意代码位置的原因之一。

  • 恶意代码启动时机分析:

恶意代码植入于UIWindow (didFinishLaunchingWithOptions)中,其入口点 为: __UIWindow_didFinishLaunchingWithOptions__makeKeyAndVisible_;UIWindow 是作为包含了其他所有View的一个容器,每一个程序里面都会有一个UIWindow;而didFinishLaunchingWithOptions里 面的代码会在UIWindow启动时执行,即被感染App在启动时的开始准备展示界面就已经在执行被植入的恶意代码了。

图 2-5恶意插件植入的代码入口点

2.1.3 危害分析

2.1.3.1 上传隐私

恶意代码上传的信息主要有:时间戳、应用名、包名、系统版本、语言、国家、网络信息等;同时还有被感染App的运行状态:launch、runing、suspend、terminate、resignActive、AlertView。
所有信息通过DES加密后POST上传到服务器:

  • init.icloud-analysis.com
  • init.crash-analytics.com
  • init.icloud-diagnostics.com

其中6.0版本URL为字符串形式,而到7.0版本URL则进化到字符拼接,7.0版本中还可以获取应用剪贴板信息。

图 2-6获取上传的信息


图 2-7 6.0版本中URL为字符串形式


图 2-8 7.0版本中URL字符拼接形式


图 2-9 7.0版本获取应用剪贴板信息

2.1.3.2 任意弹窗

恶意代码可以远程设置任意应用的弹窗信息,包括弹框标题、内容、推广应用ID、取消按钮、确认按钮;需要注意的是该部分代码并没有使用输入框控件, 同时也并无进一步的数据回传代码,因此是不能直接高仿伪造系统弹窗,钓鱼获取Apple ID输入和密码输入的(这点在诸多已公开分析报告中均有一定误导性)。


图 2-10远程设置弹窗信息
但是由于弹窗内容可以任意设定,攻击者完全可以使用弹窗进行欺诈通知。

2.1.3.2 远控模块

  • OpenURL远控
  • 恶意代码包含了一个使用OpenURL的远控模块,该模块可以用来执行从服务器获取到的URL scheme,其使用canOpenURL获取设备上定义的URL scheme信息,并从服务器获取URL scheme通过OpenURL执行。


    图 2-11 canOpenURL获取信息,执行从服务器获取的URL scheme

  • URL scheme能力
  • URL scheme功能强大,通过OpenURL可用实现很多功能;但需要注意的是,URL scheme所能达到的功能与目标App权限有关, 如拨打电话、发送短信需要被感染应用具有相应权限。但如果其他App或系统组件有URL scheme 解析漏洞、Webview漏洞等,则能相应执行更 多行为。

    由于服务器已经关闭,同时该样本也没有明显证据表明具体使用了哪些URL scheme,以下为我们分析的恶意代码所能做到的行为:
    • 调用App
    • 拨打电话
    • 发送短信
    • 发送邮件
    • 获取剪贴板信息
    • 打开网页,如打开高仿Apple的钓鱼网站
    • 结合弹窗推广应用,App Store&企业证书应用皆可


    图 2-12设置推广应用appID和对应URL scheme

    另外推广应用时候,由于弹窗所有信息皆可远程设置,当把"取消"按钮显示为"安装","安装"按钮显示为"取消",极易误导用户安装推广的应用。

    2.1.4 中间人利用

    虽然恶意代码使用的域名已经被封,但由于其通信数据只是采用了DES简单加密,很容易被中间人重定向接管所有控制。当使用中间人攻击、DNS污染时,攻击者只需要将样本中服务器域名解析到自己的服务器,即可接管利用所有被感染设备,进而获取隐私、弹窗欺诈、远程控制等。
    其中恶意代码使用的DES密钥生成比较巧妙,是先定义一个字符串”stringWithFormat“,再截取最大密钥长度,即前八个字符“stringWi”。

    DES标准密钥长度为56位,加上8个奇偶校验位,共64bit即8个字节。

    图 2-13 DES密钥生成方式

    所以即便恶意代码服务器已经失活,依然建议用户及时更新被感染App版本,若仍未更新版本的App,建议立即卸载或尽量不要在公共WiFi环境下使用,请等待新版本发布。

    2.2 影响面分析

    截止到2015年9月22日凌晨3时,通过各安全厂商累计发现的数据显示,当前已确认共692种(按照版本号计算858个)App受到感染,其中影 响较大的包括微信、高德地图、滴滴出行(打车)、58同城、豆瓣阅读、凯立德导航、平安证券、网易云音乐、优酷、天涯社区、百度音乐等应用的多个版本。 (详情请参见附录三。)
    注:需要说明的是,根据相关消息,这一事件是腾讯在自查中发现并上报给CNCERT的。

    安天依托国内一份2014年度iOS TOP 200排行的信息[3]进行了App检测,共发现有6款App受到影响,在表2-1中已用红色字体突出显示。

    表 2-2 App Store Top200中受影响App统计,红色为受到影响软件

    TOP 200排行

    1 微信

    2 百度

    3 淘宝

    4 QQ

    5 高德导航

    6 搜狗输入法

    7 百度视频

    8 滴滴打

    9 爱奇艺PPS影音

    10 易新闻

    … …

    21 我叫MTOnline

    22 优酷视频

    … …

    52 铃声大全

    53 百度音乐

    54 美团团购

    … …

    59 查违章

    60 爱奇艺视频

    61 限时免费大全

    … …

    101 芒果TV

    102 易云音乐

    103 今日头条

    … …

    200 冰川时代:村庄

    目前,已有其他分析团队示警著名手机游戏开发平台Unity 3D也被同一作者植入了恶意代码,与攻击Xcode手法一样,但安天分析小组没有跟进分析。

    3 扩散、组织分析

    3.1 传播分析

    攻击者使用了多个账号,在多个不同网站或论坛进行传播被植入恶意代码的Xcode,以下是我们对其传播账号及传播信息的脑图化整理:

    图 3-1传播马甲关联分析图

    被植入恶意代码的Xcode由攻击者上传至百度云网盘,然后通过国内几个知名论坛发布传播,传播的论坛包括:51CTO技术论坛、威锋网论坛 、unity圣典、9ria论坛和swiftmi。我们通过跟踪发现其最早发布是在“unity圣典”,进行传播的时间为2015年3月16日,攻击者在 每个论坛的ID及所发的百度云盘下载地址都不相同,详情参见表3-1。

    表 3-1传播论坛情况

    站点名称

    站点说明

    帖时间

    标题

    网址

    发帖ID

    威锋网

    国内知名iPhone社区

    2012-12-29 13:17

    最后编辑时间

    2015-6-15 09:41

    Xcode最全版本下载,Xcode7以及Xcode6全系列

    http://bbs.feng.com/read-htm-tid-5711821.html

    lmznet

    unity圣典

    Unity3D中文技术交流社区

    2015-03-16 11:49

    最后编辑时间

    2015-3-23 18:12

    最全Xcode版本网盘超快下载!!【求加精】

    http://game.ceeger.com/forum/read.php?tid=204961-1-1.html

    coderfun

    9ria论坛

    游戏开发者社区

    2015-03-24 16:55

    Xcode最全版本下载

    http://bbs.9ria.com/thread-43267

    linuxFans

    51CTO论坛(百度快照地址)

    中国领先的IT技术网站

    2015-04-09 18:56

    最后编辑时间

    2015-7-1 14:07

    Xcode 6 Xcode 7全系列,百度网盘下载地址

    http://bbs.51cto.com/thread-1149738-1.html

    jrl568

    威锋网

    国内知名iPhone社区

    2015-06-15 09:43

    Xcode最全版本下载,Xcode 7 以及Xcode 6 系列等

    http://bbs.feng.com/read-htm-tid-9581633.html

    coderfun

    图 3-2作者百度云网盘

    以威锋论坛传播为例,这个帖子本身是一个旧帖,首次发布于2012年,并在2015年6月15日进行最后编辑,作者用旧帖“占坑”的目的,是为了增加下载者对此帖信任度,如图3-3。

    图 3-3通过威锋网传播

    此外,微博上有网友说Xcode传播是通过迅雷下载重定向传播,会导致输入官方下载地址下载到错误版本,但后来同一网友又澄清是自己看错了导致,并删除了原帖。有关截图参见图3-4、图3-5:


    图 3-4 证明截图1微博发贴以删

    图 3-5证明截图2微博发贴以删
    2015年9月19日该网友公开澄清是自己记错了,误把百度云盘链接直接拷贝到迅雷下载地址里了,以下是网友的公开声明。

    图 3-6网友澄清证明但在地下社区中,确实一直存在针对迅雷污染,使迅雷下载到重定向恶意代码的方法讨论,而且由于类似感染可能获得巨大的经济利益,我们并不能完全排除这种下 载污染,有可能通过流量劫持等方式来配合。同时亦有网友反馈迅雷存在直接下载和离线下载所得到的文件大小不同的情况。受时间所限,安天分析小组未对这些传 言进行进一步验证。

    3.2 攻击者情况猜测

    此前根据相关安全团队的信息检索,认为攻击者可能是X工业大学的一名学生。从攻击者具备污染了多个平台的开发能力,并已经确定对iOS用户产生了严 重影响,开发能力覆盖前台、后台,掌握社工技巧,具备SEO优化的意识。从其综合能力来看,有可能不是个体作业,而是一个小的团伙、或者存在其他方式协同 的可能性。同时,根据相对可信的消息,相关云资源使用者每月向数据汇聚点亚马逊支付数千美元,其应该有较高的获益。
    但此前关于攻击者的亚马逊资费每月数十万美元的猜测,我们认为有误,因为亚马逊从计费上是单向收费的,而相关猜测是双向计算的。

    3.3 开发环节的安全问题分析

    导致大量原厂发布的App遭到污染的重要原因是,开发团队未坚持原厂下载,也并未验证所下载的开发工具的数字签名。
    我们发现有很多分析团队向开发者提供了完整的官方Xcode文件的Hash,但显然直接对应用进行数字签名验证可能是更高效的方法。

    3.3.1 Mac&iOS app签名方式

    OS X和iOS应用使用相同的签名方式,即:

    1. 在程序包中新建 _CodeSignature/CodeResources 文件,存储了被签名的程序包中所有文件的摘要信息;
    2. 使用私钥 Private Key 对摘要进行加密,完成代码签名。

    3.3.2 Mac上官方签名工具codesign验证App方式

    Mac上可以使用官方codesign工具对Mac&iOS App进行签名验证。
    codesign工具属于Xcode Command Line Tools套件之一,可以使用如下方式获取安装,推荐使用1、2方式:
    1.    Terminal里执行:Xcode-select –install;
    2.    Mac App Store里安装;
    3.    安装 brew 后执行 brew doctor 自动安装;
    4.    在Developer Apple网站下载安装:https://developer.apple.com/downloads/

    图 3-7 Developer Apple上的Command Line Tools工具


    3.3.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签名发布。

    图 3-8官方Xcode7.0签名信息


    而验证含XcodeGhost恶意插件的Xcode6.4应用,其所有者为“Software Signing”,说明非Mac App Store官方渠道发布。

    图 3-9恶意Xcode签名信息

    3.3.2.2 验证app的合法性

    为了达到给所有文件设置签名的目的,签名的过程中会在程序包(即Example.app)中新建一个叫做 _CodeSignatue/CodeResources 的文件,这个文件中存储了被签名的程序包中所有文件的签名。
    使用codesign --verify xxx.app 指令可以根据_CodeSignatue/CodeResources文件验证App的合法性
    校验官方Xcode应用,验证通过,将没有任何提示。


    图 3-10官方Xcode签名校验合法
    校验含XcodeGhost恶意插件的Xcode应用,验证失败,会出现提示,说明该应用在签名之后被修改过。

    图 3-11恶意Xcode签名校验失败

    鉴于此事件影响重大,苹果官方于2015年9月22日发布文章[6]推荐使用spclt工具校验Xcode合法性。



    图 3-12官方推荐使用spctl工具校验Xcode合法性

    如图3-13,上面为正版Xcode验证信息,表明来源为Mac App Store;而下面为恶意Xcode工具验证信息,没有任何来源信息;

    图 3-13使用spctl工具校验Xcode来源
    关于此前Xcode加载较慢的问题一直被诟病,其存在国内网络设施方面的问题,但苹果未投入足够CDN资源也是一个因素。我们注意到苹果在申明中提及会改善国内相关下载体验,但无论体验如何,原厂获取、本地可信分发建立与维护,都应该是开发者需要建立的规则。

    4. Android风险预警

    4.1 预警背景

    在XcodeGhost事件发生后,安天分析人员尝试进行了其他平台的非官方通道开发工具审查,但由于我们的资源获取能力等因素所限,尽管检查了大 量包和镜像,却并未在其他开发平台发现更多问题。但正如兄弟团队发现Unity 3D被同样污染的问题一样,这并不意味着其他开发平台不存在其他问题。
    由于Android的开发环境在国内获取较为困难,使得部分开发者会选择从在线网盘等渠道下载离线更新包的方式来取代在线更新,因此我们将Android开发生产环境作为重点预警对象。

    目前Android下的开发生产环境如图4-1所示,其可以分成开发流程、自动化构建和发布三部分。

    图 4-1 Xcode安卓开发生产环境示意图

    通过分析,无论开发者是否使用IDE环境进行开发或者自动化构建,都会使用到Android SDK和Android NDK,并且默认官网下载的zip中只包含有SDK Manager,不同API版本的构建工具和lib库均需要开发者在线下载,并且在在线云盘中有大量的离线包分享。


    图 4-2通过搜索引擎可以看到在百度网盘资源中有多份Android开发工具包

    下文我们将分别说明JAVA代码和Native代码的开发生产环境面临的污染风险,为避免我们的分析被攻击者利用,分析小组对公开版本报告中的本部分做了大篇幅删减,相关论述是希望兄弟团队共同对污染的可能性进行排查,以降低风险。

    4.2 JAVA代码开发生产环境的风险


    在Android开发中,JAVA代码开发和编译主要由Android SDK提供,其中除了编译工具和Ant编译脚本外,还提供了系统jar库,用于版本兼容的support库,以及一些官方其他支持库。
    JAVA开发生产环境被污染的风险,可能存在如下情况:
    1. 污染代码在编译过程中被植入,或者随apk打包的jar库植入;
    2. 污染代码需要被主动调用,如在一个类被加载的时候去调用。
    Android SDK中最大的风险是jar库没有普遍采用签名验证机制,存在被篡改风险。

    图 4-3验证部分.jar的数字签名

    4.3 Native代码开发生产环境的风险


    同样,Native代码开发生产环境被污染的风险,可能存在如下情况:
    1. 污染代码跟随编译过程进入构建的模块, Native代码开发生产环境存在如下污染问题:
    1) 污染头文件被污染;
    2) ndk-build编译脚本被污染;
    3) crt运行的.o库被污染。
    2. 污染代码必须能够自动执行,污染代码可能被编译到.init_proc或者.init_array节;
    3. 存在某处主动调用静态库的extern方法。

    5 全景的安全视野才能减少盲点

    如果对这一事件进行定性,我们将其称之为一系列严重的“地下供应链”(工具链)污染事件,在当前移动互联网研发过度追求效率、安全意识低下的现状 下,连锁形成了重大后果。从目前分析来看其污染源可能是地下黑产,并穿透了若干道应有的安全篱笆。同时值得深思的是,在今年3月份的时候斯诺登曝光的一份 文档显示:美国情报机构曾考虑通过对Xcode(4.1)SDK进行污染,从而绕过苹果App Store的安全审查机制,最终将带毒App放到正规的苹果应用商店里。长期起来,国内安全的焦虑过多地集中围绕着CPU和操作系统等少数环节的的自主化 展开,但有其他几方面问题没有得到足够关注。

    1. 从供应链上看:供应链上的各个环节,都有可能影响到最终产品和最终使用场景的安全性。在这个维度上,开发 工具、固件、外设等“非核心环节”的安全风险,并不低于操作系统,而利用其攻击的难度可能更低。因此仅关注供应链的基础和核心环节是不够的。而同时,在实 际应用场景中,往往存在着因盗版、汉化、破解等问题带来的地下供应链,以及下载重定向、第三方分发源等带来的不确定性,这些因素,在过去已经给信息系统制 造了大量隐患。
    2. 从场景和时域关联上看:开发商、分销商、配送通道的安全性与使用场景的安全同样重要,因此只关注最终场景 的安全是不够的。苹果在中国缺少足够的CDN资源投入,尽管因其产品的强势,让中国的开发者和用户都能容忍,但无疑也助动了地下工具链的成长。而国内的网 络速度和效率问题,看似一个体验问题,但其最终也同样可以转化为安全问题。
    3. 从权限上看:在数据读取能力上,居于底层的操作系统和居于上层的应用程序可能是一致的,即使操作系统做出 种种分层访问、沙箱隔离等限制,一旦受到污染程序进入系统,其攻击难度就瞬间从远程利用降低为提权,因此只关注操作系统的“底层”安全是不够的,追求系统 数据安全和持续运维才是目的。而同时,在移动平台上,无论是安卓提供的安全产品与应用平权的策略,还是苹果彻底将反病毒产品逐出App Store的方法,最终都导致安全厂商难以给予其更多的支持、防护和协同。从而使这些互联网霸王龙陷于与寄生虫们不可能取胜的战争当中。
    4. 从信息链上看:互联网模式不是传统的信息流转,而是基于用户的方便性追求而进行的信息采集、聚合与分析, 用户需要用主动提供信息来置换对应服务,因此,仅用传统的控制思维是不够的。而从这一恶意代码所表现出的信息采集和提交的特性来看,其似乎与常态的互联网 客户端十分接近,这或许也是其未能被更早发现的原因。

    从被现行发现的Xcode到之后被关注到的U3D,以及我们预警的安卓开发平台的可能性,一系列非官方版本污染事件涉及到了上述每个问题的层面,其 正是通过工具链污染绕过了多个开发厂商的自我安全审核,与号称非常严格的苹果应用商店的上架审核(也许对苹果来说,这个“多余”的模块就像一个新增的广告 联盟的插件)。而一批开发者不坚持原厂获取开发工具,不审查工具的数字签名,这些都暴露了App开发领域的野蛮生长,忽视安全的现状。而这种被污染的 App到达用户终端后,并不需要依赖获取更高权限,依然可以获取大量有价值的信息,但一旦与漏洞利用结合,就有可能形成巨大的威力。而同时,其也采用了与 互联网客户端类似的信息采集聚合方式,而数据的聚合点,则位于境外的云服务平台上。从而使事件变成的多边、多角的复杂关系。
    对于苹果公司在此事中的表现,我们除了期待苹果在中国有更多的CDN投入来改善下载体验外,我们想引用我们的同事在2012年所写的两段文字:“作为一个 选择全封闭、不兼容产业模式的商业帝国,苹果公司取得的巨大成就在于其对体验极致的追求和近乎完美的产业定位设计。但如果把第三方安全支撑能力完全摒弃在 外,一个自身已经成为复杂巨系统的体系,怎么可能具备独善其身的能力呢”、 “对安全厂商高度排斥,如果不求变革,这些都将导致其陷入漫长的一个人的战斗。”
    这一问题再度提醒我们,要跳出单点迷思,从完整供应链、信息链角度,形成全景的安全视野、安全建模与评价、感知能力。同时,我们也要再度提醒,我们需要警 惕“建立一个完全自闭合的供应链与自循环的信息链方能安全自保”的小农安全观的卷土重来,在互联网和社会生活场景下,这本身就不可能实现。而中国政企网络 的市场空间,完全不足以保证一个健康的闭环供应链的有效生存,更谈不上还需要支撑这个闭环供应链安全性的持续改进。

    同时,我们也需要看到,网络地下黑产的泛滥与无孔不入,其不仅将危害网民的安全,也会带来更多纵深的安全风险,其让国家安全的防护边界变得模糊。因此在这一问题上投入更多的资源,进行更为强力、有效的综合治理,于国于民都非常必要。

    外一篇:我们的检讨

    我们一直在追求“一小时启动、同时打赢两场战争”的分析对抗能力,但针对这次XcodeGhost事件,一周的时间过去了,我们却未能及时交卷。尽 管我们有分布在四个城市的传统、网络、移动、追溯的四个分析团队,但当在同一个领域的两个事件接踵到达时,我们出现了严重的指挥和衔接问题,我们的局部兵 力和能力也暴露出了不足。但也许,这种密集到达的挑战正是安全威胁的常态。
    带着惭愧,分析小组还想多做一段检讨,安天作为追求先进检测能力的安全厂商,在重大恶意代码疫情发生时的沉默,就是一种没有充分履行社会责任的体现。当我 们的研判组未能在第一时间把事件提升到A级响应,当安天安全研究与应急处理中心(Antiy CERT)的同事们想当然的认为移动安全公司的分析组(AVL Team)一定会响应此事,当AVL Team的分析组因跟进某事件分析,决定推迟分析启动48小时,却没有进行互通汇报…..这种防守失位就已经达成。我们突然联想到,传说中某国火箭在发射 过程中的一个愚蠢的失败教训——因整流罩未能打开,卫星未能成功入轨,而原因是卫星方认为火箭方会下达这个指令,而火箭方认为卫星方会下达这个指令,最终 两方都没有下达指令。而我们自己这次就是如此地愚蠢,这一切同样表明,对于安全厂商自身来说,一个全面、贯通的决策链和能力链多么重要。
    而我们在报告中编写中遇到的另一问题,也值得我们自己警醒和反思。本报告昨晚被安天总工办叫停的一个原因,是因为Android风险预警一节写得过于详 细,且完全是站在攻方视角的审视。为此,分析小组的同事们再次受到如下团队基本立场的教育:以保障用户价值为最终目的;以形成工程能力为基本方法;具备推 导攻方手段的逆向思维;坚持改善防御水平的正义立场。
    同时值得欣慰的是针对XcodeGhost事件,从官方应急机构的提前预警,到多个厂商的接力分析,网络安全界展示了集体的力量,在此安天分析团队向最早 发现事件、并做了大量分析的腾讯安全团队、向本次最早发出公开预警的国家互联网应急中心、向本次在大洋彼岸最先做出细腻分析工作的、我们曾经的同事 ClaudXiao、向及时跟进做出大量分析、应急和解读工作的360、阿里安全、盘古、百度等团队表示敬意。

    最后,还是要做个广告,在AV-C移动安全下半年的测试中,安天移动安全团队(AVL Team)出品的AVL SDK for Android引擎,再次获得100%恶意代码检出率,从而成为唯一一款在上下半年的测试中均取得100%检出率的安全产品。我们想用这一成绩告诉我们的 用户,以及使用我们引擎的合作伙伴用户——我们有能力保护你们!

     


    转载请注明出处 APT防御产品 » Xcode非官方版本恶意代码污染事件(XcodeGhost)的分析与综述

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址

    网友评论(14)

    1. #14

      不错的文章,内容十全十美.禁止此消息:nolinkok@163.com

      胶管 2017-02-23 12:27 回复
    2. #13

      不错的文章,内容气贯长虹.禁止此消息:nolinkok@163.com

      防风抑尘网 2017-02-23 12:26 回复
    3. #12

      不错的文章,内容龙飞凤舞.禁止此消息:nolinkok@163.com

      钢格板 2017-02-22 04:51 回复
    4. #11

      好文章,内容惟妙惟肖.禁止此消息:nolinkok@163.com

      雷诺护垫 2017-02-22 04:50 回复
    5. #10

      好文章,内容妙趣横生.禁止此消息:nolinkok@163.com

      果冻胶 2017-02-18 10:03 回复
    6. #9

      不错的文章,内容笔下生辉.禁止此消息:nolinkok@163.com

      工业明胶 2017-02-18 10:03 回复
    7. #8

      不错的文章,内容笔下生辉.禁止此消息:nolinkok@163.com

      压滤机 2017-02-17 05:04 回复
    8. #7

      好文章,内容气贯长虹.禁止此消息:nolinkok@163.com

      勾花网 2017-02-17 05:04 回复
    9. #6

      不错的文章,内容见缝插针.禁止此消息:nolinkok@163.com

      格宾网 2017-02-15 20:53 回复
    10. #5

      好文章,内容无懈可击.禁止此消息:nolinkok@163.com

      勾花网 2017-02-15 20:53 回复