Android本地服务漏洞挖掘技术-下篇

见贤思齐

Android本地服务漏洞挖掘技术 - 下篇 OPPO安珀实验室 OPPO安珀实验室 OPPO安珀实验室 OPPO广东移动通信有限公司 以用户数据安全和隐私保护为核心，开展系列研究工作并向开发者开放技术能力，致力为合作伙伴及用户打造信息安全堡垒，为OPPO终端安全保驾护航 43篇内容 2024年01月19日 16:00 四川 引言在之前的系列文章中，我们介绍了Android本地服务中Socket服务和Origin Binder服务的漏洞挖掘相关内容。在本篇中，我们会详细阐述余下三类Binder服务的漏洞挖掘相关知识。与传统Binder服务相比，最大的区别是开发者无需实现onTransact代码，而是通过定义AIDL/HIDL接口文件，再借助于编译系统即可自动化生成相关代码，开发者仅需要实现服务端实际业务代码。从安全的角度来讲，由于在过往的Origin Binder服务中，大部分漏洞都是由于在onTransact函数中，缺少对Parcel数据的合法性校验，从而导致各类内存破坏漏洞（越界读写，未初始化内存，类型混淆等）。而AIDL/HIDL的引入，使得此类场景的漏洞几乎不复存在，我们需要将重点放在服务端实际业务代码中来。收集信息AIDLAIDL service同样是由Service Manager管理，因此我们也可以使用service list命令来得到所有服务列表，示例如下：不过这其中还包含了大量纯JAVA代码实现的服务，由于当前我们仅关注内存破坏类型的漏洞，因此我们需要过滤。根据多年的经验，大部分JAVA服务均为框架层服务或者供应商应用层服务，也就是其所处进程一般为system_server或者为供应商app。基于这个原理，过滤方法如下：1.利用service list获取所有服务列表；2.使用dumpsys命令获取某个服务的进程号；3. 根据进程号得到应用名；为了自动化，我们可以将前面步骤封装为工具，最终可以得到如下结果：HIDL在默认环境下，Android并没有提供现场的工具可以列出所有服务，幸运的是HIDL的管理器IServiceManager对外提供了list接口，部分核心代码如下：运行结果示例如下：按照HIDL开发经验，进程名通常与服务名一致，因此可尝试使用以下命令以确定所处的进程：当未查找到时，可以通过遍历所有进程的内存布局，查找是否存在对应的接口动态库文件，如：如果以上两种方法均未找到（概率极低），那么此时需要使用关键字符串查找，或者编写客户端来进行枚举排查了。常见漏洞类型内存破坏漏洞往往发生在对传入参数的处理上，因此我们先看一下所支持的参数类型有哪些。上面只列出了部分需要关注的参数类型，更多参数请参考以下链接：AIDL：https://source.android.com/docs/core/architecture/aidl/aidl-backendshl=zh-cn；HIDL：https://source.android.com/docs/core/architecture/hidl-cpp/typeshl=zh-cn；回到漏洞类型本身，介于文章篇幅，我们略过分析过程，直接给出我们多年攻防经验下来，这些类型常见的漏洞类型，具体如下：1.基础类型1）基础运算或类型转换过程中，是否存在整数溢出的可能；2）对于有符号数来说，边界校验是否可能被绕过；2.不定长类型1）是否有对不定长输入进行长度校验，导致越界读写；2）字符串类型是否有存在非NULL结尾字符串，导致越界读写；3.接口类型1）接口的类型转换是否合理，导致类型混淆；2）hidl_handle类型是否包含足够的数据，导致越界读；3）hidl_handle类型的共享内存数据是否有合法性校验；4）MQDescriptorSync类型数据在读写过程中是否有合法性校验；5）如果其为一个IBinder接口，需要注意该接口的函数接口是否会有漏洞；4.联合体类型1）是否有对类型做强校验，导致类型混淆；5.枚举类型1）是否有做最小值和最大值校验，导致越界读写；6.自定义类型1）结构体内部是否包含危险类型成员，是否有做完备的安全校验，导致各类内存破坏。代码审计接下来，我们会通过两个CVE例子来演示在有源码和无源码的情况下如何进行代码审计。CVE-2023-21008在pixel设备中，存在一个名为android.hardware.wifi.supplicant.ISupplicant/default的AIDL服务，其接口定义如下：其中addP2pInterface接口会返回一个ISupplicantP2pIface对象，其存在一个名为setWpsDeviceType的函数接口：其中参数type为一个不定长的byte数组，setWpsDeviceType的服务端实现如下。代码没有校验type的大小，直接使用std::copy_n函数从其拷贝了8个字节数据到type_arr，因此当type的长度小于8字节时，即会导致越界读漏洞。CVE-2023-20766在使用MTK平台的Android设备中，存在一个名为vendor.mediatek.hardware.lbs@1.0::ILbs/AgpsInterface的HIDL服务。由于该服务为闭源组件，在没有源码的情况下，我们需要通过一些逆向手段来获得其接口信息。不过，正如我们前文所提到的，所有接口目标库均是由Android编译系统自动生成的，因此其存在一定的规律性，这使得我们不用耗太多时间就可以完成逆向信息提取。该服务的可执行程序名为lbs_hidl_service，我们使用readelf命令查看其依赖库。根据命名规则，vendor.mediatek.hardware.lbs@1.0.so为其自动化生成的接口库，lbs_hidl_service-impl.so为具体的业务代码实现库。我们使用逆向工具对vendor.mediatek.hardware.lbs@1.0.so进行反编译，过滤出所有BpHwLbs::_hidl_的函数，即为接口函数：反编译其中的sendToServerWithCallback接口，核心函数如下：这代表该接口的参数共两个，其一为IBinder对象，其二为hidl_vec数组，因此根据前文的漏洞类型分析，这里我们需要关注业务代码是否有对二参数进行长度校验。我们对lbs_hidl_service-impl.so进行反编译，由于反编译后的代码较为复杂，我们以伪代码的形式展示：可以明显看到，代码没有校验data的大小，直接将其数据拷贝到固定大小为0x4000字节的buff中，因此如果data.size()大于0x4000，那么这里会导致越界写漏洞。总结AIDL/HIDL服务当前广泛存在于各个Android设备中，并且即使是同一功能模块，由于硬件的差异性，各大芯片供应商和OEM厂商也会自行实现相关服务。这使得其中存在大量的未被关注的服务，再加上底层开发人员通常缺少安全编码经验，因此存在较多的安全漏洞。不过从另一方面看，由于AIDL/HIDL服务通常配置较为严格的Selinux规则，普通APP应用或者SHELL应用均无法访问相关接口，因此漏洞的危害一般较低，评级基本不会超过中危。不过，如果能够找到一条完整从上到下的攻击链（APP -> HAL APP -> AIDL -> HIDL），那么在实际场景中，仍然能够造成严重的后果。END往期推荐·Android本地服务漏洞挖掘技术 - 中篇·Android本地服务漏洞挖掘技术 - 上篇·Android前台服务恶意进程防杀技术解析·浅谈Android BLE蓝牙安全隐私问题·手把手系列之——syzkaller原理及实现分析