前言：

第一次参加Blackhat 2023 Asia会议，不得不说这是一次难忘的经历，毕竟Blackhat对于网络安全从业者来说，就好比教徒们的朝圣地 –“耶路撒冷”，全球的安全专家聚集于此讨论安全领域的最新趋势、威胁和解决方案。以下内容是骨哥在现场参会后整理的随笔。

会场：

今年的亚洲分会地点设在新加坡的滨海湾金沙会议中心（Marina Bay Sands Convention Center）4楼 ，会议时间是2023年5 月 9 日至 12 日，其中5月9日-10日为现场培训，5月11日-12日为现场会议，会议日程一般在09:00-17:00，17:00之后通常为各个厂商举办的答谢酒会。

9:00-10:00的开场白和主题演讲都在Roselle Junior Ballroom（洛神花厅）举行，10点之后就是分散在各个其它房间的Briefings（简报）时间，当然在4700房间为厂商专门设立了Business Hall（厂商展厅）。

会场平面示意图

在听取简报的茶歇时间，可以在Business Hall中参观各大安全厂商的摊位（跟国内各类安全大会类似）。

Business Hall入口

在大厅的中央本次大会还与HackHouse合作，设立了“Lockpicking Lab”–以开锁实验室形式提供对物理安全领域的体验和学习，帮助与会者更好地了解与物理安全漏洞相关的风险。

Lockpicking Lab

大厅的尽头，还设立了Arsenal（兵工厂/军火库）、会有各种安全开源工具的宣传以及现场手把手实操模拟授课。

实操：控制工控系统

实操：“黑掉”酒店房卡

根据事先计划安排，骨哥根据个人兴趣点分享对于部分“Briefings”（简报）的感受与心得：

Stealthy Sensitive Information Collection from Android Apps（从 Android 应用中收集隐秘的敏感信息）：

该分享内容大致分为3部分：背景介绍、主要工作和摘要。

在背景介绍部分，从目前全世界对于隐私信息的关注度切入，先是概览了Android6-Android13这6个版本以来的隐私安全的变化，比如Android 10开始限制了对IMEI和其他设备唯一标识符的访问，这些标识符包括IMEI、MEID、序列号和Android ID等；然后是Android12对于GAID（Google AdvertisingID）的限制；

安全研究员的主要工作部分为分享的“核心内容”，主要从Andorid的WebView入手，尝试通过使用 Webview 来不受限制地访问隐私信息，于是他们从6个步骤入手来实现隐私信息的获取：

a) AOSP 提供的官方渠道

b) Java 反射机制

c) 动态代码调用

d) 直接利用Binder调用

e) 利用漏洞调用

f) 利用隐藏频道

在 AOSP提供的官方渠道中，大多数可以通过各种 Manager API 实现的，比如: TelephonyManager.getImei/getDeviceID等；

在Java反射机制中，则可以通过静态分析，然后利用类似telephonyMgr.getClass().getMethod("getImei", int.class).invoke(telephonyMgr, slotId); 手段实现绕过；

动态代码调用，相对来说较为困难，可以利用类似：

来实现；

直接通过Binder调用同样较为困难，可以利用类似：

来实现；

而利用漏洞实现的话，由于很多 OEM 商添加了自己的 API，因此容易产生漏洞。而且 API 也更容易受到攻击，从而成为攻击者可利用的漏洞，但是此类漏洞一般都在特定的 OEM，所以检测出来也较为困难。比如CVE-2021-25344：

最后一个利用隐藏频道，有多种方式，比如获取CPU的SN：

亦或是，获取IMSI/ICCID/电话号码等：

当然，这个方法需要sdk<30才可以，但是很多第三方的APP Store往往并没有强制要求，这就给利用提供了机会。

于是安全研究员就可以利用hook技术来实现敏感信息的获取：

比如：hook String 构造函数以检测敏感数据

当然从 Android 10开始，第三方应用程序不再被允许获得该设备的唯一标识符，但还是可以利用第三方厂商的漏洞获取到其它敏感信息（有些甚至都无需任何权限）：

分享的最后也进行了4点总结：

(1)系统级保护：从Android 10开始，第三方应用无法获取系统唯一标识符，如果要利用则APP必须利用某些0-day 或 n-day的漏洞

(2)应用级保护：如果应用的Webview没有正确处理权限，就被任意URL获取用户数据

(3)碎片化灾难：一些OEM厂商没有严格遵守AOSP权限策略，很多自定义的API可以用于获取设备唯一标识

(4)新的挑战：AD ID在某种程度上变成了持久化ID，从第一次开机到手机恢复出厂设置之前，都可以持续不断地跟踪用户

Grand Theft House：RF Lock Pick Tools to Unlock Smart Door Lock（侠盗猎车：解锁智能门锁的射频开锁工具）：

该分享共分5个部分：背景介绍、Rolling Code（滚动码）与重放、加密与认证、Gadget 准备以及开锁的艺术，这个分享是物联网安全主题，我本人对物联网安全只知一些皮毛，有精通物联网安全尤其是车联网安全的，应该会对这个分享很感兴趣，下面是我对该分享的一点心得和理解，有不正确的地方，还望多多指正。

背景介绍里主要介绍了随着科技的发展，越来越的门锁采用了智能门锁，以及2019年开始出现的重放攻击，然后简单介绍了一下无线门锁系统的构成：

然后是第二部分的Rolling Code（滚动码） 与可变重放攻击中，详细介绍了Rolling Code、Roll Jam Attack、RollBack Attack以及Loop Playback Attack：

众所周知，现在的智能门锁为了确保安全的代码传输，并且为了保证不被重放攻击，采取了一些安全手段进行保护，如：

每条传输信息都不同

接收器可以忽略已发送的消息

跟踪上次使用的代码，永不接受之前使用的计数器

关于滚动码（Rolling Code），也称为跳跃码，是一种特殊类型的加密系统，用于无线无钥匙进入装置。过去，车主只需按一下按钮，遥控器就会将解锁码传送到汽车接收器上，这种方法有一个明显的缺陷，即任何人都可以在信号传输时接收到信号，然后在未经其允许的情况下使用该代码解锁车主的汽车。为此，滚动码技术出现了，它确保了每次传输的代码都是唯一的、不规则的、且不重复。滚动码的工作流程大致如下图所示：

而由 [Samy Kamkar] 创造的著名RollJam Attack，样子是下面这样：

RollJam设备

Roll Jam Attack 原理

Roll Jam Attack原理大致如下：

当受害者首次按下钥匙按钮时，RollJam拦截信号Unlock1使其不能被车辆接收，与此同时保存截获到钥匙发出的Unlock1信号。

当首个钥匙信号遭到拦截，且未能解锁车门时，车主极大概率会再次尝试。在第二次按下钥匙按钮时，RollJam会再次拦截信号Unlock2，不过也会在同时传送第一次的信号Unlock1，这次车门被解锁了，通常用户会忽视之前的解锁失败。但是RollJam却获取了第二个有效的信号。如果RollJam安装在汽车上或藏在车库附近，它就可以重复拦截信号，不管车主进行了多少次解锁，它都始终传送上一个信号，然后储存下一个信号。RollJam的安装者不管何时取回这一装置，他都会得到一个未使用且有效的滚动码信号。

不过从此过程可看出RollJam存在两个主要缺点：

1)攻击者必须非常精确的掌握时机。如果其未能及时利用获取到的滚动码信号，一旦车主再次解锁了车辆，就需要重复之前的过程再次获取新信号

2)当攻击者想再次打开同一辆车时，必须从头开始重做所有事情

Rollback Attack 原理

Rollback Attack原理大致如下：

Rollback 攻击比Roll Jam攻击主要是多了两个步骤。当受害者首次按下钥匙按钮时，RollBack设备发送噪声拦截信号Unlock1，与此同时截获该信号。

当首个信号遭到拦截未能解锁车门时，受害者极大概率会再次尝试。在第二次按下钥匙按钮时，RollBack不会拦截信号Unlock2，只会捕获它，因为车辆顺利接收到了Unlock2，车门被解锁了。

接下来，车主如往常一样使用车钥匙开锁、关锁，可能会重复 n 次。

接下来攻击者控制 RollBack设备重放之前捕获的两个连续“解锁”信号 Unlock1和 Unlock2，当重放Unlock1时，车门还是处于锁定状态，但是重放Unlock2 之后，车门被打开了。

可以发现在攻击者重放了连续的两个滚动码之后，车辆中的滚动码计数器重新同步到了之前的滚动码n，因此会响应 n+1 次发送的命令。

可以看出，RollBack 与时间无关，它的两个明显特点是：

1)一旦攻击者捕获到信号，无论车主使用钥匙解锁关锁汽车多少次，都可以在未来的任何时间启动 RollBack

2)RollBack 成功利用一次后，它还可以根据需要再重新利用多次，而无需从头开始重做任何事情，简单说来，一次捕获两个信号，就可以无限期地访问该车辆

Loop Playback Attack原理

Loop Playback Attack原理主要是捕获三次开锁信号，然后三个信号的重复重播，以达到开锁目的，就是比Loopback Attack 多了一次信号捕获和重放。

然后就是针对智能门锁在Rolling Code（滚动码）上的AES加密与认证进行了逆向分析，并评估它们的安全性：

基于AES的智能门锁RF加密方式

密钥生成缺陷

基于 LUT 密钥生成的缺陷

评估结果

评估的结果不容乐观，所有型号都容易被嗅探并进行射频开锁。

然后就是第三部分，研究人员针对这些漏洞制作相应开锁工具的所做准备，包括RF捕获、解码以及射频传输。

工具制作概述

通过分析RF信号与RF基带信号，然后配合特定的时间同步训练序列，再经过特殊的编码，形成基于代码捕获器和破碎器的SDR设备：

基于代码捕获器和破碎器SDR

代码捕获器和破碎器迷你版

两种开锁类型

1种是攻击者通过提取“ID”和“同步计数器”并生成新代码（攻击者知道“当前同步计数器”的值，并期望知道下一个值）

另1种是类似穷举攻击：

攻击者仅通过更改 ID (= Serial Number)值生成新代码（攻击者不知道“当前同步计数器”的值）

最后就是“开锁”的攻击艺术了。攻击场景的话，这套设备一般可以放于不被人们发现的隐秘角落，如通风管道。

安全研究人员一共分析了10个不同厂商的20多个模型，发现了全面的关键攻击方法，这也就意味着攻击者走进一所房子，就可以打开针对这些厂商同型号的所有智能门锁！

最后研究人员也将要点进行了整理和分享：

1、变体重放攻击：

如果没有时间戳，“RolllJam”是不可避免的，“RollBack”在门锁系统中也是可行的

“Loop Play Back”的新变体攻击也被证实在门锁系统中是可行的

至少在门锁系统中，确认了这些攻击的根本原因

2、Lock Picking攻击：

通过嗅探一个信号开锁很容易被利用

如果是已知信号原型，则可以一次性恢复下一个代码

在不使用嗅探的情况下，仍然容易打开任何相同型号的门锁根据 ID(=Serial#) 的属性，执行此类攻击可能更实用

重新同步过程也是暴力攻击的关键因素

Dirty Bin Cache A New Code Injection Poisoning Binary Translation Cache（Dirty Bin Cache 一种新型代码注入投毒二进制翻译缓存）：

这个“简报”是骨哥认为最棒的一个分享，干货满满且诚意十足。这个分享来自FFRI安全公司的一位日本籍安全研究员，名叫Koh M.Nakagawa。

这位安全研究员主要从事基于 ARM 的Windows系统安全研究，最近也开始转向macOS，并且成功发现了macOS中多个漏洞，同时也在 BlackhatEurope 2020简报会及 CODE BLUE 2021举办过讲座，实力还是相当可以的。

分享内容主要分为六部分，首先是简单地介绍了一下目前Windows、macOS中基于ARM芯片的笔记本越来越流行，然后切入正题，引入针对x86/x64的翻译和模拟模块。

针对x86/x64的翻译/模拟技术

然后简单的介绍了一下他先前在Blackhat Europe 2020上针对基于ARM芯片的Windows操作系统的一些研究，由此联想到，会不会macOS上也存在类似的漏洞呢？

于是开始从macOS的安全模型入手，然后介绍Rosetta2，在M芯片的 Mac电脑中能够使用 Rosetta 2 的翻译机制从而运行 x86_64 的指令集编译代码，在介绍Rosetta2时，提到了一项Ahead-of-time Translation的功能（简称AOT），x86_64 二进制文件在系统认为合适的时机会从存储中读取，翻译后的内容也会作为一种特殊类型的 Mach 目标文件被写入存储。该文件类似于可执行的映像文件，但也会被标注，证明其是另一个映像的翻译产品。

快速了解Rosetta2

接着开始深入了解AOT文件，并且AOT文件受到SIP（System Integrity Protection）保护，即使我们拥有root权限，也无法修改这些文件。

Rosetta2 有几个主要组件构成：

translate_tool – 用于翻译 x64 可执行文件而不执行它的 CLI 工具

runtime – 注入到翻译过程中的运行时库

oahd – AOT 文件的管理守护进程

oahd-helper – x64 可执行文件的翻译器

然后介绍了Rosseta2的执行流程，通过逆向分析，AOT文件会被缓存以便再次使用，那么Rosetta 2如何判断x64 可执行文件之前被翻译过呢？oahd 会计算专用哈希以用于检查，作者将其命名为“AOT lookup hash”，如果目录中有对应于 AOT lookup hash，那么oahd 就会重用该目录中的 AOT 文件。但是 oahd 又是如何从 x64 可执行文件计算 AOT lookup hash呢？继续通过逆向分析。

逆向分析AOT lookup hash计算过程

SHA-256的计算结果主要由几部分（完整路径、Mach-O头、uid、gid、mtime、ctime、crtime以及文件大小）组成：

mtime：文件数据最后修改的时间

ctime：文件状态最后一次的时间

changed（inode数据修改）

crtime：文件创建时间

假如我们可以在保持 AOT lookup hash不变的情况下修改代码部分，那么就可以导致哈希碰撞！于是代码注入攻击就可以实现了。

代码注入流程

1、注入shellcode到一个‘良性’的APP

2、由translate_tool建立AOT文件

3、恢复‘良性’APP，同时保持 AOT lookup hash不变

4、AOT 文件被重用是因为AOT lookup hash是相同的

5、被投毒的AOT文件被成功执行

但是步骤3中一旦对文件进行了修改，时间戳就会更新。

根据mmap()的UNIX旧规范，在没有 msync() 的情况下通过 mmap() 写入文件会是否会更新 macOS 上的 ctime 和 mtime 呢？于是作者进行了实验。

结论得出如果不调用 msync()，我们可以通过 mmap() 更改文件内容，同时保持时间戳不变！

利用mmap()写入文件

于是AOT文件的投毒就可以顺利执行了：

AOT文件投毒步骤

当然，这种投毒方法也会受到一些限制，比如已签名的x64可执行文件就无法被修改等。

然后苹果公司很快就对这个漏洞进行了修复，于是作者继续逆向分析，发现苹果只是对APFS格式的文件进行了修复，这种修复其实并不完美。

ctime 并没有针对 FAT32的文件格式进行定义，因此还是可以实现的。

另外对于已签名可执行文件的直接修改会导致运行时崩溃，oahd 也不接受具有无效代码签名的 x64可执行文件，因此针对这两个问题，可以利用oahd 接受带有临时签名的可执行文件进行绕过。同时作者还为此开发了一个新工具，在保持 Mach-O 头不变的前提下来使用临时签名进行签名。

接着作者通过对TCC（Transparency, Consent, and Control）的绕过，实现了恶意代码与漏洞的双结合，以便发挥出更强大的攻击能力，另外作者还针对Windows系统也进行了相似的攻击实验，作者从红队、安全研究、OS开发者以及所有人的角度，最后也贴心的给出了相应建议。

相应建议

A new attack interface in Java（一种新的 Java 攻击接口）：

这篇分享也比较有意思，为今后对于JAVA源代码的安全审计提供了一些思路。分别从危险的连接池、任意Log文件写入、语法兼容性、未选中的初始化类、错误的响应处理和JDBC攻击保护6个方向提出攻击思路。

危险的连接池：首先从利用 JNDI 连接 JDBC 数据源说起，以IBM Informix JDBC 驱动程序通过 JNDI 注入远程执行代码为例，讲述了漏洞形成的具体原因。

IBM Informix JDBC 驱动程序通过 JNDI 注入远程执行代码触发链

任意Log文件写入：以IBM DB2 JCC 驱动程序通过Logger注入远程执行代码为例，从漏洞分析到实现内存无痕Webshell注入Weblogic Server。

IBM DB2 JCC 驱动程序通过Logger注入远程执行代码流程

使用当前线程获取 Weblogic Server 请求对象 -> 利用恶意类实现新的过滤寄存器 -> 使用 BCEL 注入恶意类字节码

语法兼容性：以通过setBlob方法对MySQL JDBC驱动程序实现SQL注入为例，利用字符编码的JPG图片从而实现SQL注入

利用字符编码通过setBlob方法对MySQL JDBC驱动程序实现SQL注入

未选中的初始化类：以通过未选中的类实现IBM DB2 JCC驱动程序远程代码执行为例，从Getter 和 Setter 两个方法入手，利用无参数构造函数，实现远程代码执行。而后作者尝试在现实场景中找到无参数的构造函数，首先从JNI入手，尝试劫持 Java 库 jaas _ unix (JAAS)，以jdk1.8.0_181为例，Linux系统为com.sun.security.auth.module.UnixSystem，Windows系统则是com.sun.security.auth.module.NTSystem。成功实现远程代码执行。

通过未选中的类实现IBM DB2 JCC驱动程序远程代码执行

根据上面的手法，作者又在Google Cloud Spanner 、Apache Calcite Avatica中发现了同样可以实现远程代码执行的漏洞利用点，Apache的漏洞利用被分配CVE-2022-36364漏洞编号。而根据Apache的这个漏洞，又可以延伸出SSRF漏洞利用，作者利用动态分析，成功在sun.security.provider. PolicyFile找到漏洞利用点。

Apache Calcite Avatica SSRF漏洞利用

错误的响应处理：以Snowflake通过 SSO 流响应执行远程代码为例，分析脆弱点，从而在Google Cloud Spanner中实现SSRF攻击，在Teradata中利用SSO命令注入实现远程代码执行，并且通过Teradata JDBC驱动程序可以绕过高版本Java反射限制。

通过Teradata JDBC驱动程序绕过高版本Java反射限制

最后针对JDBC的攻击保护，也同样分享了一些建议：

如果在软件服务中向用户公开 JDBC 配置：

使用 JDBC 属性的允许列表，其中包含满足业务服务需求的最小可行集

仅使用经过审查的 JDBC 驱动程序并且不允许用户上传

特别注意影响文件写入和网络/操作系统命令的配置属性——默认情况下都应Deny

沙盒用户在专用 VM 或云功能中发起的 JDBC 活动时 – 假设环境将受到损害，应将破坏的影响程度最小化

定期检查 JDBC 配置和使用情况是否存在恶意或意外配置

JDBC 驱动程序应该是组件版本生命周期策略的一部分（持续保持更新）

对于JDBC 驱动开发者：

不要相信用户提供的属性，尤其是当这些属性被用于通过反射调用网络、操作系统命令或代码时

提防恶意服务器并考虑使用校验和或其他可验证的数据交换机制

如果正在使用的 JDBC 驱动程序是forking的，请确保与上游驱动程序保持同步并确保对重大安全问题进行修复

花絮/插曲：

CTF for Girls：

第一天快结束时，在Arsenal 听了来自Elastic公司一位日本女性安全工程师，她创办了一个“女性CTF”组织，倡导全世界女性安全同胞可以加入的这个组织，来共同提升女性在CTF赛场的技术能力：

Synk：

第一天午餐时，阴差阳错的进入了Synk举办的邀请午宴，于是就在午餐中听了Synk产品的介绍，Synk产品是一款源代码安全审计工具，目前还和GPT进行了集成，因此它不但可以发现代码中的漏洞，还能够自动修复这些漏洞。

另外，目前Synk 还增加对了Docker的支持，当然，Synk目前只能针对已知漏洞进行检测和修复，对于未知的0day/Nday是无法检测的，但是它目前支持的语言很丰富，并且可以作为插件集成在IDE中，配合GPT的强大支持，不仅可以快速的检测到漏洞点，还可以实现自动化的漏洞修复。