Group of Software Security In Progress

Android SmartTVs Vulnerability Discovery via Log-Guided Fuzzing

作者:Yousra Aafer; Wei You; Yi Sun, Yu Shi, and Xiangyu Zhang; Heng Yin

单位:University of Waterloo; Renmin University of China; Purdue University; UC Riverside

会议:Usenix Security 2021

链接:https://www.usenix.org/conference/usenixsecurity21/presentation/aafer

0 Abstract

随着智能电视的广泛普及,对其的攻击也越来越多,然而目前针对智能电视安全性和相关风险的评估却很少。因此,本文提出了一种新的针对Android smartTVs安全的评估方法,该方法基于电视系统日志来提取输入约束,利用动态模糊测试的方式对智能电视进行漏洞检测。作者使用该方法分析了11个Android TV Boxes,发现了37个漏洞,包括敏感数据访问、内存破坏以及视觉/听觉干扰。

1 Introduction

Android SmartTV基于AOSP (Android Open Source Project)开发,并利用额外的组件来实现TV的功能。电视盒子与智能电视类似,用户通过操控电视盒子来进行操作内容,电视盒子通过HDMI线连接到电视(显示设备)并将内容投放到屏幕上。

目前针对智能电视的分析存在一系列的挑战:

  • 智能电视的主要功能在Java层和native层实现,尤其是native层,因此相关分析工具需要能够从native层推测并生成有效的输入来触发智能电视的相关功能。
    • 由于大部分功能实现在native层,并缺乏符号表,传统的静态分析会受到限制。
  • Fuzzing的结果不仅存在于网络层面,还可能存在物理层面(例如显示错误、声音干扰等)。

由此,作者设计了一种静态分析与动态fuzzing相结合的智能电视安全评估方法。本文的主要贡献:

  • 作者开发了一种基于日志的动态fuzzing技术来检测智能电视系统中存在的漏洞。
  • 利用该技术,作者发现了11台电视中的37个漏洞。

2 Design Overview

如图2所示,系统主要包含四部分,给定一个smart TV ROM:

  1. 首先,Fuzzing Target Locator识别要提供给模糊测试器的相关功能API
  2. 然后利用Dynamic Fuzzer为每个API生成测试用例,其中测试用例的生成过程中通过Log Analyzer来推断有效的输入规范并对Fuzzing输入进行反馈
  3. 最后,利用电视日志和External Observer观察电视的网络状态和物理状态,来检测fuzzing造成的异常。

2.1 Fuzzing Target Locator

这一步是用来识别要提供给fuzzer的相关功能API,这里作者重点关注由供应商定制或添加的系统服务上(与AOSP相比)。

Binder IPC

Android服务可以通过Binder IPC机制来实现调用,Binder IPC允许应用跨进程调用系统服务中的公开代码。

图3显示了Binder IPC主要流程:

  • 在系统启动时,系统服务进程提供服务名称和服务句柄并在Service Manager注册。
  • 客户端应用进程向Service Manager查询相关服务信息,并绑定到该服务,通过binder transactions来调用系统服务中的相关方法,其中transactions调用信息包含要执行的方法id、方法参数和响应数据。
  • 在接收到transaction之后,服务端获得参数数据并调用实际的系统服务函数。执行之后封装响应并将其返回给客户端;客户端代理之后接收响应并返回调用。

获取系统服务API

  • 为获得可用的Java和Native层的服务API,作者首先通过ServiceManager查询已注册的服务并检索相关的服务接口描述符。
  • 确定了接口名称之后,需要在Java层和Native层中定位相关接口实现
    • Java层:利用名称和描述符等信息分析定位
    • Native层:从binder IPC native函数接口入手,恢复transaction ID、参数、类型等,利用这些信息来调用相关API。

提取Native函数接口

作者认为尽管大部分二进制文件的符号信息都会被stripped,但是一些特定的基本符号信息仍然会保留,之后可以根据这些特定的信息来识别native方法。

  • 识别native binder transactions的函数体
    • 通过遍历系统服务接口描述符,定位到相应proxy和stub实现的二进制文件。
    • 作者依赖proxy和stub的命名惯例(BpInterfaceClassName、BnInterfaceClassName),基于所发现的接口描述符来推测出proxy和stub的类名。
    • 之后,从相应的VFT查找函数入口点。
  • 重构binder函数接口
    • 反编译binary,并为每个函数构建控制流图
    • 作者遍历控制流图,收集parcel read相关函数参数(例如,writeInterfaceToken、writeStrongBinder和writeInt32)和binder transaction Id。

2.2 Input Generation Through Log-Guidance

在定位到相关功能API之后,需要生成相应的输入来触发目标API。这一步,作者利用Android执行日志来提取相关输入规范并生成输入。

识别特定API的日志消息

由于Android日志包含大量的信息(其他进程消息等),首先需要筛选出与特定功能API相关的日志信息。

  • 利用进程PID:一个API的执行可能涉及多个进程。
  • 利用TAG字符串:TAG字符串可能并不是唯一的(例如,DEBUG)
  • 日志差异分析
    • 首先,比较执行特定API之前和执行时收集的日志,从执行日志中去除之前收集的相关日志。这是因为目标API日志消息应该出现在执行时/后获取的日志中,而不会出现在调用之前的日志中。
    • 之后,作者通过概率计算来继续筛选特定API的日志信息(target log中出现概率高而baseline log出现概率低)。

识别日志信息中的输入验证消息

在筛选出特定API产生的日志消息之后,还需要进一步识别与输入验证相关的信息,以提取目标API的输入规范来生成有效的fuzzing输入。

  • 白名单方法:通过依赖特定关键字来进行筛选(误差大)。
  • 利用分类器的识别方法:Java层和Native层的日志消息具有相似的语法和语义,因此可以利用机器学习技术,通过对Java层日志消息学习来识别Native层的日志信息。
    • 静态提取日志语句,通过字符串分析重构日志消息模板,并通过污点分析来标记这些消息是否与输入验证相关。
    • 之后使用标记的日志消息模板并通过有监督学习的方法来训练分类器
    • 最后对日志消息进行识别并提取输入规范,来指导后续的输入生成。

2.3 Dynamic Fuzzer

Dynamic Fuzzer用于为每个API生成测试用例,并对相应的智能电视执行。作者利用执行日志来迭代地学习以及生成有效的输入,并对执行输出进行评估。对于检测测试用例触发的异常,作者采用了两种方式: - 通过检查执行日志来发现表示网络异常的消息 - 新的日志消息表示fuzzer达到了新的执行状态 - 一些关键字能够反映异常状态 - 使用Exteranl Observer来检测智能电视的显示和音频异常 - 外部观察器通过捕获执行测试用例之前和之后的状态,并使用标准的图像和声音波形比较算法来观察存在的差异,以识别异常。

3 Implementation

作者实现了上述智能电视安全评估方案。

  • Java分析:WALA
  • 二进制分析:Radare2
  • 分类模型:Keras
  • Fuzzer:Randoop

4 Evaluation

作者在11台Android智能电视盒子上应用了该方案,测试设备如表1所示。

4.1 Recovered Native Functions Interfaces and Evaluation of Log Analysis

平均一台智能电视大约包含6项供应商定制的系统服务,这些服务共引入了603个新的API,其中Java API仅占13%,而native API占44%。

表2显示了特定API日志消息识别的结果。

  • API平均触发7条日志消息,其中一些API没有触发日志消息,而其他API最多触发139条。
  • 作者手工检查了150个API的日志消息,其中有16%被错误标记为目标API的日志消息,有5%日志消息被漏报。

4.2 Testing Evaluation

作者在4-cores计算机 (Intel®CoreTM i7-2600 CPU @ 3.40GHz) 进行了模糊测试实验,利用HDMI捕获设备视频和音频来实现Exteranl Observer。每个测试用例平均用时16s。

Availability of Logs

  • 测试结果显示,平均每台设备87%的API至少会触发一条日志消息,46%的API至少触发一次输入输入验证,而有54%的API没有任何输入验证。
    • 可能的原因:1)开发人员没有记录报错的原因;2)某些API使用void参数。
  • 6.5%的API触发无用的输入验证日志
    • 日志没有包含输入规范相关信息,例如,”invalid value”和”illegal input”

漏洞检测

  • 测试一共发现37个漏洞,如表5所示,不同的缺陷会造成不同级别的安全威胁(网络威胁CT、内存破坏MC、物理干扰PD)。
  • 这些漏洞覆盖11种服务,某些API根据提供的参数不同会造成不同的攻击威胁。
  • 17个缺陷(46%)是由native API造成的。

基于日志的模糊测试

  • 有22种情况(59%)触发了至少一个输入验证消息,有20种情况能够从日志消息中获得新的状态信息,侧面说明了利用日志分析的可行性。
  • 第8-9列显示了两种方式检测测试用例的异常情况的结果。大多数网络威胁和内存破坏都能够通过监视日志来检测到异常,而外部观察器更适用于检测物理干扰异常情况。
  • 此外,作者进一步比较使用基于日志的模糊测试与一般的随机模糊测试所发现漏洞的时间,结果显示基于日志的模糊测试明显优于随机模糊测试。

5 Discussion & Conclusion

方案存在的不足之处:

  • 测试设备集均为低成本设备且数量有限,并不能代表其他高端的Android智能电视。
  • 测试结果高度依赖于日志信息以及对日志信息识别的准确性,如果日志信息不能很好的反应输入约束或者状态,那这种方式就并不适用。

本文主要提出了一种新的针对智能电视的安全评估方案,尽管所使用的具体的技术并不新,但针对智能电视分析的困难之处提供了一些巧妙的思路,主要解决了三点问题:

  1. 对于Native层的功能服务定位(调用)问题,作者利用Binder IPC机制的相关特性来间接分析与调用
  2. 对于测试用例的有效生成,作者利用电视执行日志来提取相应的输入规范
  3. 对于模糊测试产生的异常情况,作者利用日志来监视网络异常,并提供了外部观察器来监视电视的物理异常