Docker化的Android在不同操作系统上的表现

:::info 作者：

(1) Daniele Capone, SecSI srl, 那不勒斯，意大利 (daniele.capone@secsi.io);

(2) Francesco Caturano, 那不勒斯费德里科二世大学电气工程与信息技术系, 那不勒斯，意大利 (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, 那不勒斯，意大利 (angelo.delicato@secsi.io);

(4) Gaetano Perrone, 那不勒斯费德里科二世大学电气工程与信息技术系，那不勒斯，意大利 (gaetano.perrone@unina.it)

(5) Simon Pietro Romano, 那不勒斯费德里科二世大学电气工程与信息技术系, 那不勒斯，意大利 (spromano@unina.it).

:::

链接目录

摘要和第一章 介绍

第二章 相关工作

第三章 Docker化Android：设计

第四章 Docker化Android架构

第五章 评估

第六章 结论和未来发展，以及参考文献

第五章 评估

本节通过检查几个方面来评估Docker化Android平台。首先，我们强调了模拟器核心和真实设备核心组件在功能方面的差异，并突出了与三种最常用操作系统的兼容性。然后，我们提供Docker化Android的实际使用示例，并讨论第三章中定义的需求覆盖情况。

\

\ A. 模拟器核心与真实设备核心之间的差异

\ 即使我们为创建一个对两种设备具有相同功能的系统付出了很大努力，但在使用模拟时仍存在一些限制：

\ • SMS ADB发送/接收功能：在模拟设备中，可以通过ADB软件自动发送和接收短信。显然，这在真实设备上原生是不可能的。因此，用户必须手动发送和接收短信以实现SMS攻击场景。解决这个问题的方法可能是开发一个自定义Android应用程序，安装在真实设备上并可以被编程自动发送和接收消息。

\ • 网络：模拟器和真实设备版本之间的网络相当不同。在模拟器版本中，AVD是在Docker容器内创建的，因此它共享容器的IP地址。而真实设备则物理连接到运行容器的机器，并保持自己的IP地址。

\ • 硬件虚拟化：对于硬件组件，情况也相当不同：一些硬件设备如GPS和麦克风可以被模拟。特别是，设备的GPS位置可以通过ADB设置，主机的麦克风可以与模拟器共享。还有一些硬件组件目前无法模拟，例如蓝牙。

\ B. 跨平台兼容性的主机评估

\ 非功能性需求NF04（跨平台兼容性）规定，最终系统应该可以从任何主机操作系统中使用。这指的是运行Docker容器的机器的操作系统。表III提供了与Linux、Windows和OS X兼容性的摘要。

\

\ Windows的问题是，目前使用Docker的最佳方式是通过Windows Subsystem for Linux (WSL)框架。不幸的是，WSL尚不支持嵌套虚拟化，而这一功能是在Docker容器内运行Android模拟器所必需的。然而，这一功能将在即将发布的WSL版本中提供。可能可以通过使用虚拟机在Windows上运行模拟器核心版本，但这会失去与容器化相关的所有性能优势。OS X也存在类似问题，目前无法运行模拟器核心。此外，OS X不允许与Docker容器共享USB设备。因此，使用真实设备核心版本的唯一方法是通过Wi-Fi运行ADB或从Docker容器内连接到主机ADB。

\ 在本节的剩余部分，我们将展示Docker化Android在使用模拟器核心和真实设备核心复现安全攻击链方面的有效性。

\ C. 在模拟器上复现安全攻击

\ 我们在此关注与CVE-2018-7661[1]相关的示例漏洞场景。这个CVE与应用程序"Wi-Fi Baby Monitor"的免费版本有关。该应用程序需要安装在两个设备上，以作为所谓的婴儿监视器（一种用于远程监听婴儿发出声音的无线系统）。根据国家漏洞数据库的报告，"2.02.2版本之前的Wi-Fi Baby Monitor Free & Lite允许远程攻击者通过对TCP端口8258和8257的特定请求获取音频数据"。

\

\ 该应用程序的高级版本为用户提供了在配对过程中指定密码的能力。通过监控网络流量，可以观察到：

\ • 初始连接发生在端口8257上；

\ • 始终发送相同的序列来启动配对过程；

\ • 在配对过程结束时，会在端口8258上启动新的连接。该端口用于传输音频数据；

\ • 连接到端口8258后，端口8257上的另一个连接保持打开状态，用作会话的心跳；

\ • 在心跳连接上，客户端定期发送十六进制字节0x01（大约每秒一次）；

\ 允许攻击者获取音频数据的概念验证在[21]中给出。这个概念验证(PoC)可以通过在Docker化Android上实现由三个服务组成的基础设施轻松复现：

\ • core-emulator：预装了Baby Monitor应用程序作为发送方的核心组件实例；

\ • ui：用于控制正在发生的事情的UI组件；

\ • attacker：Kali Linux的定制版本，自动安装执行PoC所需的所有依赖项。

\ 这也是展示用于启用通信的端口转发功能的完美示例。

\ D. 在真实设备上复现安全攻击

\ 使用真实设备，我们研究了另一个称为BlueBorne的漏洞。"BlueBorne"一词指的是与蓝牙实现相关的多个安全漏洞。这些漏洞是由物联网安全公司Armis Security的一组研究人员于2017年9月发现的。根据Armis的说法，在发现时，大约82亿设备可能受到BlueBorne攻击向量的影响，该攻击向量影响了Android、iOS、Microsoft和Linux中的蓝牙实现，因此影响了几乎所有蓝牙设备类型，如智能手机、笔记本电脑和智能手表。BlueBorne在Ben Seri和Gregor Vishnepolsk于2017年9月12日发表的论文中进行了详细分析[22]。攻击向量中可以使用八种不同的漏洞。

\ 关于Android，所有设备和版本（因此比2017年12月发布的Android Oreo更早的版本）都受到上述漏洞的影响，除了支持BLE（蓝牙低能耗）的设备。一般来说，利用该漏洞需要满足两个条件：(i)目标设备必须启用蓝牙；(ii)攻击者必须足够接近目标设备。由于模拟器核心中不提供蓝牙功能，因此相关攻击链只能在真实设备上复现。

\ 1) 在Docker化Android上完整复现BlueBorne：为了展示Docker化Android的有效性，我们开发了一个攻击链，利用了影响Android的两个远程代码执行(RCE)漏洞，即CVE-2017-0781和CVE-2017-0782。这些漏洞属于Armis Security的一组安全研究人员发现的蓝牙漏洞集合"BlueBorne"[23]。

\ 图4中的图表概述了开发的攻击链：

\

1. 攻击者通过Gophish（一种钓鱼生成软件）创建钓鱼邮件。

\ 2) 钓鱼邮件被发送到受害者的邮箱。

\ 3) 受害者阅读钓鱼邮件并错误地点击邮件正文中包含的恶意链接。

\ 4) 恶意链接允许攻击者触发攻击，下载并安装假应用程序到受害者的移动设备上。

\ 5) 恶意信息向攻击者发送相关的移动设备信息。这些信息是利用这两个漏洞所必需的。

\ 6) 攻击者制作恶意负载以利用漏洞。

\ 7) 攻击者通过利用蓝牙组件的漏洞发送攻击，并获得对受害者设备的远程访问权限。

\

\ 这个复杂场景涵盖了表I中定义的几种威胁。表V显示了这些威胁以及允许场景复现的平台功能和组件。

\

\ 该场景需要复杂的网络通信(F07)并涉及蓝牙的使用。因此，我们必须使用物理设备(F10)。在提出的场景中，我们必须模拟用户收到邮件时恶意应用程序的安装。这可以手动完成(F02)或通过实现实用的ADB脚本(F03)。为了复现该场景，需要额外的元素：

\ • Gophish：一个允许制作和发送钓鱼邮件的Web应用程序，已有Docker版本。

\ • Ghidra：由美国国家安全局(NSA)创建的用于逆向工程目的的应用程序。在这种情况下，它用于获取有关目标设备的一些有用信息。该应用程序在主机上使用，不使用Docker。

\ • 假Spotify：一个看似良性的应用程序，假装为用户提供知名的Spotify Premium应用程序的免费版本，但实际上向攻击者的服务器发送被窃取的文件，这些文件在Ghidra上进行逆向工程。此外，这个应用程序是在不使用Docker的情况下创建的。

\

\ 它由五个服务组成，其中两个是Docker化Android的子组件。其余三个简要描述如下：

\ • attacker_phishing：包含Gophish组件，用于制作和发送钓鱼邮件，诱骗用户下载恶意的假Spotify应