随记体验 · 2023年8月12日 0

Blackhat 2023 Asia 所见所得

前言:

第一次参加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(厂商展厅)。

file

会场平面示意图

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

file

Business Hall入口

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

file

Lockpicking Lab

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

file

实操:控制工控系统

file

实操:“黑掉”酒店房卡

根据事先计划安排,骨哥根据个人兴趣点分享对于部分“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); 手段实现绕过;

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

file

来实现;

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

file

来实现;

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

file

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

file

亦或是,获取IMSI/ICCID/电话号码等:

file

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

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

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

file

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

file

分享的最后也进行了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年开始出现的重放攻击,然后简单介绍了一下无线门锁系统的构成:

file

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

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

每条传输信息都不同

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

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

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

file

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

file
RollJam设备

file
Roll Jam Attack 原理

Roll Jam Attack原理大致如下:

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

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

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

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

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

file
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 成功利用一次后,它还可以根据需要再重新利用多次,而无需从头开始重做任何事情,简单说来,一次捕获两个信号,就可以无限期地访问该车辆

file
Loop Playback Attack原理

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

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

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

file
密钥生成缺陷

file
基于 LUT 密钥生成的缺陷

file
评估结果

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

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

file
工具制作概述

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

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

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

file
两种开锁类型

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

另1种是类似穷举攻击:

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

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

file

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

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

file

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的翻译和模拟模块。

file
针对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 目标文件被写入存储。该文件类似于可执行的映像文件,但也会被标注,证明其是另一个映像的翻译产品。

file
快速了解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呢?继续通过逆向分析。

file
逆向分析AOT lookup hash计算过程

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

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

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

changed(inode数据修改)

crtime:文件创建时间

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

file
代码注入流程

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() 更改文件内容,同时保持时间戳不变!

file
利用mmap()写入文件

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

file
AOT文件投毒步骤

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

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

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

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

file

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

file

file

相应建议

A new attack interface in Java(一种新的 Java 攻击接口):

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

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

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

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

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

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

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

file

利用字符编码通过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。成功实现远程代码执行。

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

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

file
Apache Calcite Avatica SSRF漏洞利用

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

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

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

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

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

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

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

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

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

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

对于JDBC 驱动开发者:

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

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

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

花絮/插曲:

CTF for Girls:

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

file

Synk:

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

file

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