漏洞利用简析——如何用11个exp攻破三星S8

Author:  Sniperhg@Vulpecker Team 、MissCoconut@Vulpecker Team

前言

在去年Mobile Pwn2Own上MWR Labs成功攻破了三星S8，据官方报道整个攻击链总共由11个exp构成，是目前Pwn2Own历史上最长利用链。上周MWR Labs公开了他们的Slide，在本次攻击中，其高深之处并不在于使用了多少个0day，而是使用的都是系统自带App层面的逻辑漏洞甚至是App特性的一连串的精巧组合而形成的攻击链。本文根据这个slide来对其攻击思路和步骤进行简要分析。

初探

纵观整个利用链，攻击者的代码得以成功执行以及敏感信息得以成功获取，其中最关键的漏洞出现在三星手机自带的应用商店Galaxy Apps中。

由于开发者疏忽，release版本的Galaxy Apps中存在如下遗留的调试代码：

这段代码的作用是为了调试Galaxy Apps与升级服务器之间的连通性而去加载SD卡上的配置文件（/sdcard/saconfig.ini），为方便本地调试，配置文件中可以手动指定升级服务器地址，配置文件格式如下所示：

攻击者通过指定升级服务器地址，再加上中间人转发请求，可以让Galaxy Apps安装攻击者指定的任意App。一般我们在平时的审计中，可以写一个App去释放这个配置文件或是直接adb push配置文件到/sdcard中，但在Pwn2Own比赛环境下，是无法连接USB进行adb install的，有限的物理接触也仅能进行点击浏览器，打开url等操作。那么这里是如何生成或是释放这个关键的saconfig.ini文件的，以及如何通过浏览器发动这个远程攻击的，笔者就来根据slide大胆猜测一下攻击思路，一步步进行逆向探究。

在探究之前我们先要明确一点：起点入口是三星自带的浏览器SBrowser，最终目标是在Galaxy S8上执行攻击者的代码并窃取隐私文件。我们从整个利用链的最后一环入手来倒序分析，假定此时Galaxy Apps已经等着配置文件来进行下一步攻击了。

Step 1 如何释放saconfig.ini配置文件？

由于代码中硬编码了配置文件路径（/sdcard/saconfig.ini），我们必须在指定目录下生成配置文件，那么该如何生成到指定目录？通过浏览器强制下载？显然不可，下载的文件位于Download目录内。这里利用了Samsung Notes中的一处Zip解压缩目录穿越漏洞。Samsung Notes中存在一处导出组件，可加载memo类型的文件，memo类型文件本质上是个zip压缩包，在Samsung Notes加载memo文件时会调用一个方法去解压这个memo文件，通过解压恶意构造的memo文件来准确释放文件到/sdcard下：

存在漏洞的组件：com.samsung.android.app.notes.composer.ConvertToSdocActivity

这里我们可以猜想memo文件的构成，其中有个文件的路径应该是这样的：”../../../../../../sdcard/saconfig.ini”，组合上面代码会产生路径“/data/data/com.samsung.android.app.notes/cache/unzip_1529565489/../../../../../../sdcard/saconfig.ini”，这样最终的路径就变成“/sdcard/saconfig.ini”了。

Step 2 如何让Samsung Notes打开memo文件？

如何打开特定App的特定activity？我们知道平时开发过程中直接使用Context.startActivity()即可，但在比赛环境下，并不能这样方便的执行代码，而且Samsumg Nots中存在问题的组件，并没有响应“android.intent.category.BROWSABLE”action，也无法通过浏览器打开。

所以安全人员这里找了一个跳板——Android Vending，也就是Google Play应用商店。在这个App中存在一个导出的Activity——LaunchUrlHandlerActivity，可接收外部传入的参数，并打开指定的应用，具体代码如下所示：

并且这个Activity是响应“android.intent.category.BROWSABLE”的，意味着我们能通过浏览器利用其自定义协议进行调用。安全人员随后测试了http协议、file协议以及content协议，发现这里只能使用content协议，随后尝试了Chrome的Content Provider和系统Media Provider，最终确定了可行的URI：market://details?url=content://media/external/file/350&id=com.samsung.android.app.notes

这样Android Vending会唤起com.samsung.android.app.notes并把content://media/external/file/{file_id}作为data传递给Samsung Notes。

Step 3 如何确定file_id？

Step 2中，我们看到URI中有一个content://media/external/file/{file_id}，这个file_id是不确定的数字，代表的是memo文件在系统 Media Provider里对应的ID，至于如何确定，下面是MWR给出的一段JS代码：

这段JS的意思是从id=300开始向下枚举Meida Provider中的文件，如果文件不存在的话就一直递减，直到出现一个存在的文件正确显示在页面上。

如下图示是上一个下载的文件payload.html： 

先取得memo文件将占位的ID（这个时候memo文件还没下载呢），然后保证这个时候手机的外部储存里不会多出任何文件，因为任何文件的出现都会让ID变化。如果发现i=100的时候出现了payload.html页面，那么101就是memo文件将会存在的ID值。

Step 4 这段JS由谁执行？

MWR Labs安全人员指出：

由于三星自带的浏览器不支持content协议，所以这里需要用Chrome来加载payload.html，那么如何唤起Chrome？这里利用Chrome的特性即可：

googlechrome://navigate?url=content://com.android.chrome.FileProvider/downloads/payload.html

Step 5 payload.html从何而来？

三星浏览器SBrowser支持Content-Type: application/force-download; ，通过配置攻击者的Web服务器使其强制下载payload.html：

经过强制下载后，payload.html是保存在/sdcard/Download下的。巧合的是Chrome中的一个Content Provider指向路径即为/sdcard/Download，所以这里通过传入：googlechrome://navigate?url=content://com.android.chrome.FileProvider/downloads/payload.html即可引导Chrome打开payload.html。

小结

到这里暂时休息整理一下，我们从后往前看，就是从浏览器访问一个页面到释放配置文件的过程了。

结合官方给出的图示：

顺序就是：

1. SBrowser访问index.html，index.html页面里也许使用<iframe>嵌入了一个payload.html，这个时候利用force-download特性将payload.html下载到手机里再利用googlechrome://navigate?url=content://com.android.chrome.FileProvider/downloads/payload.html唤起Chrome并加载payload.html；
2. 在payload.html中我们枚举出memo文件占位ID，接着请求下载了memo文件，再跳转market://details?url=content://media/external/file/350&id=com.samsung.android.app.notes唤起了Android Vending；
3. Android Vending被唤起后发送Intent继而唤醒Samsung Notes访问memo文件进行解压缩释放了配置文件saconfig.ini。

进一步利用

Step 6 如何突破比赛时间限制？

进行到这里我们已经有了这个配置文件，虽然配置文件能控制Galaxy Apps的行为去劫持下载，但是由于其使用的是Android Job Scheduler，Scheduler的执行间隔是15分钟，而比赛的规则是每次尝试只有5分钟时间，所以这里碰到了一个限制需要突破：如何让Scheduler快速执行？

由于Galaxy Apps在启动时会去加载这个配置文件，这里想到了让Galaxy Apps重启。由于Galaxy Apps是系统应用，会在系统启动时自启动，那么这里面临着两个选择，是选择crash掉一个App还是crash system引起手机重启？MWR Labs选择了后者。

Step 7 如何重启系统？

在这一步的攻击中，利用了系统进程“com.android.server.telecom”中的组件“com.android.server.telecom.components.UserCallActivity”中存在一处隐藏的空指针异常未捕获的问题：

如果外部直接启动这个Activity不带任何data进来，URI将会为null，null传给getScheme()方法时就会产生空指针异常，系统进程的崩溃意味着系统的崩溃，这个时候手机就会重启，由于Galaxy Apps会在系统启动时自启动，那么重启手机之后，Galaxy App也会重新启动并加载我们的配置文件。

Step 8 如何发送特定Intent？

如何能发送这样一个Intent呢，一个只带包名和组件名，不会填充data数据的Intent？这里利用了另外一个跳板——Samsung Members：

Samsung Members中的导出组件LauncherActivity可在浏览器中使用其自定义协议voc://唤起，并且可传入特定的包名和组件名。

Step 9 如何唤醒Samsung Members？

在这一步中，依旧利用Chrome来进行跳转，“voc://activity/general?packageName=com.android.server.telecom&className=com.android.server.telecom.components.UserCallActivity”，这个URI会被Samsung Members所接收到。所以Chrome在整个攻击链中要执行2次打开其他应用的任务，一次是为了唤起Android Vending跳板，另外一次是为了唤醒Samsung Members跳板。这里我们能注意到被当作跳板的组件的一个共同点：都响应了“android.intent.category.browsable”Action，导致攻击者可以通过浏览器打开进行远程利用，这里对我们来说算是一个小Tips吧，今后的漏洞挖掘工作中，对可通过浏览器打开的组件需要格外关注。

后续利用

Step 10 中间人劫持App更新

Galaxy Apps启动后加载配置文件，这个时候就会去请求这个攻击者的中间地址，攻击者再将所有的请求转发给真正的升级服务器https://uk-odc.samsungapps.com/，同时也会将服务器的响应返回给手机。

Galaxy Apps进行更新请求时会与服务器产生三次交互：

1. 客户端发送当前所有的App列表给服务器/服务端做出响应告知客户端所有App的最新版本
2. 客户端如果发现版本比自己高的App则请求这个App的最新信息/服务端返回App的包名版本等信息
3. 客户端请求最新App的下载地址等/服务器返回下载地址以及App大小签名等信息

中间人在这里修改了1次请求和3次返回的包，让Galaxy Apps误以为自己手机上的某个App是旧版本的，然后下载了攻击者执行的App进行了安装。

Step 11 如何绕过权限申请弹窗？

在Android 6.0及后续版本中，App申请危险权限时，系统会弹出对话框询问用户是否授予其特定权限，这里绕过的方式也很简单，编译apk时将targetSdkVersion设置为18及以下即可。

Step 12 如何启动恶意App？

根据slide中的描述，MWR的研究人员也以为到这里就够了，恶意App已经成功安装，还有什么不能做的呢？但是ZDI却要求现场就能运行App并进行敏感数据的窃取等操作。所以这里就涉及到一个问题：Android 3.1以后，新安装的App默认都是停止状态的。

接着研究人员发现，三星对Android Contacts Provider进行了重度修改，在一个App的状态发生改变时，会有一个方法去做一次query查询：

所以在恶意App里创建一个provider，meta-data中写上android.content.ContactDirectory属性为true，则可以在安装上之后，执行provider中的query方法。

到此为止，恶意App成功安装并启动。

总结

经过对整个攻击链的分析，将这么多“不起眼”的逻辑漏洞（或bug）利用起来，居然能从浏览器到代码执行做远程攻击。在这个攻击链中，总共涉及到了6个App、3个系统组件以及系统的总共11个逻辑漏洞（或bug甚至只是特性），我们再来回顾一下：

参考链接

1. https://labs.mwrinfosecurity.com/publications/chainspotting-building-exploit-chains-with-logic-bugs/
2. https://www.zerodayinitiative.com/advisories/ZDI-18-562/
3. https://www.zerodayinitiative.com/advisories/ZDI-18-561/
4. https://www.zerodayinitiative.com/advisories/ZDI-18-560/

关于Vulpecker Team

360威派克团队（Vulpecker Team）隶属于360信息安全部，负责集团内部移动APP和OS类产品安全攻防， 制定了公司内部安卓产品安全开发规范，自主开发并维护了在线安卓应用安全审计系统-360显危镜。同时团队高度活跃在谷歌、三星、华为等各大手机厂商的致谢名单中，截止2018年，累计获得近百个CVE编号和官方致谢，多次在国内外各大安全会议上分享研究成果。