【网络安全研究进展系列】Android 智能电视盒漏洞 / 缺陷挖掘

近些年，越来越多的物联网（IoT）设备投入使用，为人们营造更加智能的生活。其中，智能电视因其可接入互联网提供定制的娱乐体验，受到广大用户欢迎。据分析预测，智能电视的全球市值在2023年将达到2500亿美元。IoT设备在给用户带来方便体验的同时，也成为热门的攻击目标。一种较为常见的攻击方式是通过在设备上安装恶意应用，利用设备提供的含漏洞或缺陷的功能代码进行攻击。

为了主动防御攻击，我们需要对智能电视系统的安全性进行综合评估。所面临的挑战包括以下3个方面：一是识别出潜在的攻击目标，主要是Java层和Native层的与智能电视功能相关的API；二是有效生成使得潜在的攻击目标得以执行的测试用例，这需要从Java层和Native层的代码实现中推断输入规范；三是感知测试用例在网络空间和物理世界的执行结果。

面对上述挑战，我们提出了一个将静态分析和动态测试相结合的方案。通过静态分析识别出需要进行检测的目标，主要关注设备厂商定制的与智能电视功能相关的API。动态测试则采用模糊测试技术，通过运行时的日志分析推断目标API的输入规范，并通过特定装置收集测试用例在网络空间和物理世界的执行结果。

在智能电视的测试场景中，大部分API主要由本地代码实现，缺乏必要的符号信息，较难通过分析代码实现的方式获得输入规范。因此，我们通过解析API输出日志中与输入格式验证相关的信息，来推断输入规范（如关键字、格式和值域等）。具体而言，使用静态分析从Java层抽取大量与日志相关的语句，通过字符串分析重构日志信息，并自动标注其是否与输入验证有关和属于哪个类型的输入验证。我们使用自然语言处理的词嵌入技术，训练出一系列分类器，用于预测Native层的日志属于哪种输入验证。

在进行模糊测试时，我们引入了一个外部监控器，用于观测测试用例在物理世界的执行结果。物理世界的执行结果无法从设备的系统状态中获得。我们通过将HDMI声音、图像信号重定向到外部监控器，使用声音、图像比对技术来检测可能的异常。

我们使用提出的检测方案，对11台流行的智能电视设备进行系统化的安全性评估，总共发现了37个安全漏洞/缺陷。其中在网络空间中能够造成内存破坏、隐私威胁等危害的有21个安全漏洞，以及在物理世界中能够影响视听效果的安全缺陷有16个。我们的研究表明，智能电视上的漏洞/缺陷较为普遍，每台设备上有1~9个安全漏洞/缺陷，包括知名厂商的荣誉产品，例如英伟达的Shield和小米的MIBOX3等。我们向相关厂商报告了检测出的漏洞/缺陷，均已得到回复确认，并在新发行的设备中进行了修复。

此外，我们还进行了攻击实验，以验证检测出的漏洞/缺陷的可利用性。在网络空间层面，利用这些漏洞/缺陷可以在无须特定权限和用户知晓的情况下，访问敏感数据、覆盖系统文件、删除目录、在系统路径下创建隐藏文件，甚至破坏关键的启动参数，造成设备永久无法启动。在物理世界层面，利用这些漏洞/缺陷可以造成显示异常、静音等设备故障，甚至造成难以察觉的频闪损害用户视力健康，或者使设备处于“假关机”模式对用户隐私造成威胁。

Android智能电视通常在标准Android开源项目基础上进行个性定制，添加额外的系统组件支持电视功能。为了了解Android电视的个性定制程度，我们提取了多款Android智能电视的固件，发现自定义的API数目相当大，在H96 Pro设备上的自定义API甚至多达101个。由于这些系统组件运行在高特权进程中，如果缺乏恰当的保护而被利用进行攻击将导致较为严重的危害。例如，在小米MIBOX3中，SystemControl.XYZ(int x, int y, int w, int h) 这个API用于设置HDMI屏幕以宽w高h的尺寸显示在坐标（x,y）的位置上。通过分析，我们发现这个API没有实施任何保护，允许任何应用使用任意参数值调用这个API，这将破坏屏幕显示。图1展示了MIBOX3的首页屏幕在以参数值（1000,1000,1000,1000）调用这个API前后的显示情况。调用后，显示位置被移到了屏幕的右下方，显示内容变得混乱。并且，这个API对显示参数的设置是永久的，无法通过重启设备的方式恢复，只能进行硬件重置。这个漏洞可以被进一步用于恶意攻击：通过与其他的侧信道技术相结合，可以针对特定应用发起拒绝服务攻击。例如，当检测到Netflix应用在前台运行时，可以利用这个API的漏洞使得屏幕内容显示失败，勒索用户付费。

图1

检测智能电视的定制系统组件中的漏洞/缺陷是十分有必要的。然而，由于设备厂商的定制系统组件通常不开源，这些组件大多使用多个语言（C、C++和Java）混合实现，因此难以直接采用现有的代码静态分析工具进行漏洞检测。为此，我们提出了一个基于模糊测试技术的检测方案。在智能电视漏洞/缺陷检测的场景下，设计一个有效、高效的模糊测试工具需要解决的关键技术挑战如下。

1.通过逆向工程获得API信息

对参数复杂的API而言，其测试用例的搜索空间巨大，盲目的随机测试只能覆盖有限的浅层路径。现有的研究工作通过源代码插桩或者模拟器监控执行的方式，收集运行时状态信息用以推断测试用例的有效性。然而，智能电视设备厂商一般不提供定制系统组件的源代码，现有的模拟器也无法运行大部分智能电视设备固件。一个可行的替代方案是从API执行的输出日志中推断参数信息。日志往往包含与输入验证相关的数据，例如指出合法的输入数值或者适当的值域。

图2展示了以随机参数值（20,21,20.2）调用XYZ(int,int,float)这个Native API的输出日志。从第2行日志可以看到由于两个参数值大于16，这个输入被拒绝。虽然对分析人员来说，这个日志的输出非常容易理解，但对自动化程序来说则不然。首先，这条输出日志不是标准的异常格式，而是自然语言的形式；其次，自动化程序难以直接推断x和y代表哪个参数；最后，自动化推断日志中的输入验证语义也比较困难。

此外，从所有的输出日志中识别出与目标API执行结果相关的日志也是一个不小的挑战。一方面，目标API的执行过程可能涉及多个系统组件，输出日志没有统一标识符。另一方面，目标API的输出日志经常被淹没在大量无关的其他日志中，难以判断某条输出日志与目标API执行的关联性。

图2

2. 获得执行结果反馈

模糊测试工具的监控器需要观测网络空间中的状态反馈以判断是否有潜在的安全漏洞/缺陷。除此之外，由于智能电视的功能需要额外的物理组件，因此监控器也需要关注物理世界的反馈信息。值得强调的是，由于物理世界的异常可能并不会在设备内部的状态上有所体现，不会产生任何错误或失败的信息，因此无法被现有的基于系统状态的监控器捕获。例如，使用恶意构造的参数值执行SystemControl.XYZ()这个有漏洞的API，在系统内部不会抛出任何错误信息，然而屏幕显示已经发生了异常。

版权声明：本书由网络安全研究国际学术论坛（InForSec）汇编，人民邮电出版社出版，版权属于双方共有，并受法律保护。转载、摘编或利用其它方式使用本研究报告文字或者观点的，应注明来源。