移动之中的那 CSDN, 会不停地持继为您精心挑选移动开发里头的精粹内容, 一块儿去探讨有关移动开发的技术方面的热点话题, 它所涉及的范围包括像移动应用、开发工具、移动游戏以及引擎、智能硬件、物联网等各个不同的方面方面。要是您想要进行投稿, 或者是寻求获得《近匠》那的报道, 那么就请发送邮件到 tangxy#csdn.net（要把#改成@）这儿来。
今年9月, 苹果XcodeGhost事件引起全社会广泛关注, 这堪称App Store自2008年上线后所遭受的规模最大那一波攻击, 涉及应用范围之广远超想象, 反映出当下互联网软件安全领域存在严峻挑战。在MDCC 2015移动开发者大会的平台与技术-iOS专场, 阿里巴巴资深安全工程师郑旻（蒸米）复盘了这个过程, 还讨论了可行的预防措施以及事后深入思考。
然而, 有一家来自美国的移动应用开发商, 名为Possible Mobile, 最近碰到了一个问题, 他们所递交的新版应用, 遭到了苹果的拒绝, 而拒绝的理由是XcodeGhost。这家公司感到大惑不解, 原因在于他们遵循了严格制定的安全准则, 使用的是官方所提供的下载的Xcode编译器, 并且启用了GateKeeper。在经历多次试错之后, 他们最终发现XcodeGhost隐藏在第三方框架当中。
以下为译文：
不久前, 一则新闻爆出Xcode感染了XcodeGhost病毒, 致使诸多iOS应用被恶意代码所植入, 此新闻一经爆出, 立刻引发了轰动, 基于此, 苹果将受感染的应用从App Store中撤出, 并且发布了一份FAQ, 也就是常见问题汇总。因该事件大多在中国发生, 鉴于我们公司出于保险考量, 始终秉持从苹果官方渠道下载Xcode, 且启用GateKeeper, 故而没受太大影响, 然而直至最近出现了状况: 在我们向App Store提交应用更新后的短短几分钟内, 收到了这样一封拒绝邮件。
人们绞尽脑汁, 抓耳又挠腮, 处于绝境之时, 最终发觉, XcodeGhost恶意代码, 是借由第三方框架, 进入到我们的应用之中的。
在更早的9月的时候, 有安全方面的研究员发现, 那种感染了XcodeGhost的Xcode恶意软件把恶意代码植入到了应用当中。然而这封邮件好像在进行暗示, 我们的应用已经被感染了, 可是我们的开发者都是经由App Store或者Apple Developer这个门户网站去下载Xcode的, 这情况根本就完全没法说得通呀。
实际上, 就在不久之前, 我们也曾碰到类似这种状况, 那次乃因向Apple Store提交之际, 所使用的那台机器安装的是OS X测试版本, 此次会不会也是相同的缘由呢? 我们尝试着于不同的机器之上重建应用, 其中有一台完全是纯净的build服务器环境, 然而每次提交都会出现一样的错误。
这样子可真是黔驴技穷咯。为了能百分之百确切地确定问题的关键所在, 我们紧紧跟随着苹果所给出的操作指南, 去对所有版本的Xcode进行验证, 以此来保证XcodeGhost没有侵入到机器之中。所显示出来的结果全部都是:
应用软件文件夹里的Xcode应用程序, 被认可了。
source=Mac App Store
随后, 我们试着在好多机器上再度进行Xcode的安装, 并且对GateKeeper的设置做了调节, 然而依旧遭到了拒绝。鉴于所提交的应用版本跟以往相比的不一样的地方主要是针对某些第三方框架, 所以我们心里琢磨, 是不是因为第三方借助XcodeGhost把框架编好了, 之后发给了我们呢?
起初, 我们并不晓得如何去检查二进制文件。进而才能够寻觅到XcodeGhost的点滴线索。于是便直接选用简单且粗暴的办法。将第三方框架撤离。再一次进行编译以及提交。首先找出那个罪魁祸首的关键嫌疑对象。从那一处着手去切入。没花费太多的工夫。第三方框架从应用里移除了。我们又再次进行提交。（提交的版本肯定不可能正式发布。因为应用的主要功能依旧离不开第三方框架）。没过多几分钟, 那一刻, 我们瞧见iTunes Connect上面“正在处理…”字迹不见了, 这意味着应用能够提交。把第三方框架移除掉, 结果顺利通过；而添加第三方框架, 却遭到了拒绝。
我们想要确定问题究竟出在何种地方, 故而对XcodeGhost加以细致研究, 经研究发觉XcodeGhost C2（指挥 - 控制）服务器所运用的URL兴许是关键点 , 所以在第三方框架里头寻觅相近似的URL。虽说如同摸着石头过河一般 , 然而第一次便很幸运——在第三方框架的一个二进制文件里所寻得的URL字符串经确认是携带有XcodeGhost病毒的。
网址好像和句子改写没啥关系, 你是不是发错内容, 请提供正确的句子。
此外, 我们于设备之上安装了build版, 代理了流量, 且应用发布后不久。
在http://init.icloud-analysis.com这个网址上, 出现过请求。幸运的是, 在9月的时候, 与XcodeGhost关联的C2服务器, 被发现之后迅速地被移除了, 也可以说是不见了, 因此所有针对该URL的请求都是没效果的, 设备里面的信息没有发送给任何一个人。
至今, 我们满怀十足信心向第三方供应商表明: 问题源自他们那。经由清晰阐述了前因后果这般操作进而要求其供应经正版Xcode编译的全新框架。在接收更新版本之际, 再度开展一次查询以及流量代理事宜, 直至确凿认定再无XcodeGhost的丝毫踪迹结束。
对于特定问题, 我们所采用的特定方案是, 针对项目里头所有跟XcodeGhost相关联的URL以及方法名称展开递归查询, 而此操作将会借助一个文本文件, 该文本文件涵盖了全部目标搜索字符串。
用来在所有报告里运行的查询指令是, grep, -R, -f, filewithstrings.txt, * ，这几个部分组合而成的。
有的时候, 病毒出现新变体, 或者恶意软件出现新字符串, 会被添加到文件里, 以此进一步完善查询环节。还有的时候, 会考虑添加“http://init”, 或者“http://init.icloud-”。当然了, 这么做可能会致使未感染的对象被错当成感染对象, 不过, 只有通过这种办法, 才能够尽早寻觅到那些或许已经感染或者即将感染XcodeGhost的URL。当查询变成build服务器必须经历的一个步骤后, 一旦察觉到病毒感染, build就会停止运行。
我们行得, 可以去把控以及检查开发者的工作环境, 相信他们并未从第三方那儿下载过被修改了的Xcode版本, 然而对于第三方库还有框架而言, 就没办法了。我们绝大多数的项目涵盖着编译好了的第三方代码, 而这些第三方代码并不处于我们的掌控范围之内, 并且没办法控制第三方供应商去编译代码的环境。
处于不能把控第三方库的状况下, 我们依旧需要承担最终的代码整合以及排错之类的工作, 然而现在却碰到了新的问题, 这既是一种警示, 同时也阐述了产业定期的变化会带来新的挑战, 还会持续催生新的求解办法。
后续有更新: 在撰写这篇文章的时候, 又出现了XcodeGhost的新变体。这个版本是通过连接多个运行中的URL字符串来组成完整的URL, 从而使得C2服务器URL逃过了静态分析。像上面的这种检测方法依旧能够查出旧的XcodeGhost变体, 不过目前尚不清楚它是否能够在新变体上使用, 要是新变体以类似的方式混淆了自己的方法名称, 那么这个检测方法可能就派不上用场了。针对这一点, 蒸米表明, 实际上在事件爆发之前它就已经存在, 只是最近才遭遇这种情况罢了。
（翻译/张新慧 审校/唐小引）
作者介绍如下 , Nick Arnott 何人也 , 乃Possible Mobile公司QA （产品质量评价）部门之负责人 , 此人精于分析 , 拥有6年专业QA经验 , 且具备独立安全研究背景。
要第一时间把控好超新移动开发相关消息以及技术就得去留意以mobilehub作为名称建立的公众微信号, 其给定的ID为: mobilehub。
