大土豆安全笔记 | 私密数据保护机制或许有更有趣的攻击面

2021 Black Hat Asia的Slides现在是全都公开了

这周仔细看了一个关于私密数据保护机制安全研究的议题,来自腾讯玄武实验室

《A Mirage of Safety: Bug Finding and Exploit Techniques of Top Android Vendor’s Privacy Protection Apps》

  • https://www.blackhat.com/asia-21/briefings/schedule/#a-mirage-of-safety-bug-finding-and-exploit-techniques-of-top-android-vendors-privacy-protection-apps-22336
  • https://i.blackhat.com/asia-21/Friday-Handouts/as-21-Zhang-A-Mirage-Of-Safety-Bug-Finding-And-Exploit-Techniques-Of-Top-Android-Vendors-Privacy-Protection-Apps.pdf

这个私密数据保护跟最近一段时间很火的隐私协议不太一样,它指的是手机系统提供安全机制来保护用户的私密数据能够安全存储,哪怕手机丢了也不会泄露出去,最常见的就是加密相册之类的软件

一共提到了四个漏洞模型,我觉得第一个漏洞中规中矩,第三个漏洞比较有意思,其它两个漏洞不评价

漏洞一

这个应该是Samsung的软件,提供了一个可以加密存储文件的功能

IMAGE

加密存储的文件路径,这里没有显示权限,从后续的分析来看,这里应该是全局可读写的

IMAGE

解密逻辑如下,传入加密后的文件数据和秘钥进行处理,解密过程问题不大

IMAGE

生成秘钥的过程就有点意思了,都是可以计算出来的值

IMAGE

生成规则总结如下

IMEI not NULL: Key = md5(packagename + imei) + 10
MAC not NULL: Key = md5(packagename + mac) + 01
IMEI/MAC NULL: Key = md5(packagename + "0000000000") + 00

如果有条件,想要自己分析这个漏洞的同学,打开这个应用,看一下TopActivity就知道是哪个软件,我没有条件,所以也就不知道是哪个应用了

漏洞二

理想情况,用户传入密码到TEE,运行在TEE里的TA使用TEE生成的秘钥对密码进行校验,秘钥不离开TEE,只返回校验结果,校验正确,再对文件进行解密操作

IMAGE

实际情况下,在校验用户密码的部分,直接从TEE获取了秘钥在用户层进行校验,这里的攻击形式我不过多描述了,大概就是这么个意思

IMAGE

下面这篇相关的Paper我还没看完

《Open-TEE - An Open Virtual Trusted Execution Environment》

  • https://arxiv.org/pdf/1506.07367.pdf

漏洞三

攻击场景是攻击者物理接触手机且知道锁屏密码,攻击者可以添加新的指纹,而私密数据保护应用并没有判断当前验证指纹是否是新增加的

IMAGE

漏洞四

按理来说,一个Android手机可以有多个用户,每个用户的空间数据是独立不接触的,比如不能向另一个用户的空间安装应用,不能控制另一个用户空间的应用,不能从另一个用户空间获取数据等等

IMAGE

通过ADB命令即可打破上面的约束

IMAGE

我跟着分析的时候,手头并没有其中任意一台能够进行测试的手机,想要知道某个功能是干什么的,需要先上网搜一下这个功能,看看别人的测评

我想了想,如果实在是搜不到,我就去线下体验店去摸一摸,把Slides中提到的功能都给玩一遍,回来继续分析

我还是觉得F-Secure Lab挖的那个小米Second Space的密码绕过漏洞有趣 https://labs.f-secure.com/advisories/xiaomi-second-space/

之前我也写过一篇分析《REDMI 5 Plus Second Space Password Bypass》

统计了近几年Mobile Pwn2Own公开的逻辑漏洞相关利用,发现F-Secure还真是老赛棍

IMAGE

Path Finder重新处理了搜索逻辑,原先是Map键值对,用唯一方法名作为键,该方法调用的所有方法存入Callee数组作为键值,现在将键值替换为DexMethod结构体,Callee数组作为结构体成员存在,这样DexMethod就可以添加其它成员来描述该方法,比如当前类,继承的父类,扩展的接口,是否是抽象方法

子类父类来回跳的问题也很好解决,记录一个this上下文变量,模拟我们分析的思维

举个例子,非抽象类SecondActivity继承抽象类FirstActivity,抽象类FirstActivity继承Activity

按理来说我们调用SecondActivity.onCreate()的时候会先super.onCreate()调用回FirstActivity.onCreate()FirstActivity定义了一个抽象方法,FirstActivity.onCreate()调用了这个抽象方法,这个抽象方法由继承的子类实现,我们需要跳回子类去找到实现的抽象方法,问题来了,可能有多个子类继承FirstActivity,这个时候就不能单纯的去找子类父类关系来确定

所以当我们搜索入口为SecondActivity.onCreate(),记录thisSecondActivity,当跳到父类后又需要跳回当前上下文的时候,就可以利用this来定位

剩下的当然是遇到什么错误就修一修,补一补

科恩真的是一如既往的硬核!太强了!

《腾讯科恩实验室:梅赛德斯-奔驰汽车信息安全研究综述报告》

  • https://keenlab.tencent.com/zh/2021/05/12/Tencent-Security-Keen-Lab-Experimental-Security-Assessment-on-Mercedes-Benz-Cars/
  • https://keenlab.tencent.com/en/whitepapers/Mercedes_Benz_Security_Research_Report_Final.pdf

最近瓜真多,老周太惨了,以后Alpha Lab的大佬们就是扛把子!