一次技术沙龙

0x00 前言

和 Nop N7 师傅一起去参加了一场技术沙龙, 涵盖了 移动端 芯片 快应用 红队 热更新等等方向, 虽然绝大多数都是第一次听到的新概念, 但是还是很享受这种没有压力的知识分享活动, 故作记录 咀嚼一下大佬们的分享 (总有一天会有用吧~)

tag 是随笔 , 休息休息

0x01 Android 可信应用分析

1.1 一些概念

  1. TEE
    可信执行环境

提供安全隔离的执行环境
TEE 运行独立、隔离的 TrustZone 操作系统，与 Android 并行
保证在 Android 系统沦陷的情况下用户核心敏感数据或者手机的核心安全策略仍然安全

  1. REE
    常规执行环境，提供高度可扩展和多功能的操作环境，Android 系统就运行在该层面

  2. CA
    Client Application，运行在 Android 系统中的应用程序，通过特定 API 调用 TEE 中的可信应用程序

  3. TA
    Trusted Application，运行在 TEE 中的可信应用程序，由 OEM 厂商定制，用于完成一些高度敏感的操作，比如人脸指纹识别、支付、加密等

  4. SMC
    Secure Monitor Call，从 Normal world EL1 发起调用，进入 EL3，然后跳转到 Secure 模式

1.2 信息搜集

1.2.1 TA 来源

通过

1
2
3
4
应用一框架服务-Native-TA
框架服务-Native-TA
独立进程文件-TA
...

最终都能够调用到 TA

1.2.2 CA-TA 调用

OEM 厂商
ROM 升级包提取
只需要能够执行待分析 TA 的设备即可
Bootloader 设备? No! Bootloader 漏洞或提权漏洞均可

在不同品牌的终端上，TEE 的实现各有不同的调用流程，但是大都提供了 API 调用驱动的共享库文件

1
2
3
高通  		/vendor/lib64/libQSEEComAPI.so
MediaTek  	/vendor/lib64/libMcClient.so
其他机型		/vendor/lib/ibTEECommon.so，或选定一个TA进行跟踪分析

如果并不清楚分析的目标具体位置，则需要收集整机的 CA-TA 调用

  1. 获取手机中所有的 ELF 文件 for node in find {path} -type f, do echo -n "$node: ";ddif=Snode bs=1 count=4 2>/dev/nul grep -g 'ELF'; echo $?; done
  2. 找到所有依赖于之前获取到的 API 库文件的 ELF 文件 ( 利用 Dynamic Section Table 中所有 DT_NEEDED 条目定位 )
  3. 识别内部依赖关系 ( 检查 ELF 文件中 dlopen 或 hw_get_module 符号 )
  4. 获取 impl 实现

TA 获取 >> TA 格式还原

1.3 安全分析

CA 分析调用的方式 参数等信息
TA 逆向分析 参数还原

1.4 安全案例

  1. 攻击面 > 执行效果可以通过 log 日志文件分析得到
  2. 类型混淆造成未校验类型漏洞
  3. 越权调用
  4. 信息泄露导致 log 泄露敏感信息 TA 算法不绝对安全\
  5. 内存问题 (溢出被多次提及)

从挖掘角度

  • 暴露的高敏感接口居多
  • 自动化扫描依赖与调用，分析应用侧是否存在缺陷
  • 通过解包获取 TA 并自动化 Fuzz

0x02 快应用广告行为检测

静态分析框架

  1. 源码处理
  2. 广告行为图生成
  3. 广告行为分析

这部分的 “恶意开发者行为” 确实好笑

见图



绷不住…
从这里也能看出 红蓝对抗 确是人的对抗

0x03 解析 iOS 远程攻击链

其实是深入解析 iOS 远程攻击链 但是我无法理解

但是通过举例 确实 iOS 系统近几年都爆了严重漏洞
尤以信息泄露 恶意安装 NSO 间谍软件为多

甚至还有一个 PDF 内藏有完备图灵机的攻击方法 秀
参考 CVE-2023-41990
通过 iMessage 发送恶意 PDF, payload 是其中的 TrueType 字体

神秘指令 (笑)

进一步的 主讲人按绕过用户态防御 PAC SANDBOX 再到绕过 内核态防御 (CVE-2023-38606) 速通了一遍 , 实在是刺激 也从中窥看了 GeekPwn 的冰山一角, 很有意思

0x04 热更新技术违规分析

热更新(Hot Fix)，通过动态下发和加载代码，使 App 或 SDK 在不重新下载和安装的情况下，改变其原有代码逻辑或资源文件

使得应用能够绕过应用分发恶台的安全检测，从而进行意的攻击行为

喵喵 水群去了没听多少( , emm 其实也不太感兴趣来着

检测主要是根据 ArtMethod Hook 检测和 so 热更新

0x05 芯片安全

主讲人是来自小米智能终端安全实验室+小米车联网安全专家的 尹小元先生, 触发 iov 关键词了 , 此处留图

软硬兼施 确实强呀

总的来说是分享了几个硬件安全的案例, 但是确实不好复述

之后分享了关于故障注入的方法
故障注入是一种在正常操作范围之外执行 CPU 的一种方法。攻击者利用电压毛刺时钟毛刺、电磁脉冲等方式干扰芯片的正常运行，诱导其执行错误的逻辑或产生错误的输出

有人能送我一个 Riscure -lnspector 侧信道故障注入设备吗 ?

最后分享了绕过串口编程的思路
原理可参考: https://icanhack.nl/blog/rh850-glitch

0x06 红队攻击

是来自深信服 深蓝攻防实验室的负责人
不敢乱说( , 但是从之前的小蓝经历来说, 渗透和内网横移过程中的无感确实重要, 毕竟蓝队乱杀 ip 好像也不扣分的
反思作为渗透的学习来说, 确实没注意到日常的信息积累, 以后多多记录资产 弱口令等内容了
最后提到 “大集权成为攻防赛事中的分水岭 , 但更应将关注点转移到客户端侧, 如运维 Agent 监控 Agent , 通过 Agent 漏洞挖掘, 完成内网横向渗透以及权限获取”
( 想到有小蓝的监控被黑就觉得难崩 )

强者的思路确实强
bda30af6638b4878010fadc987da64f.jpg

结束! 明天把作业极限写写就能去肝 ezcalc 了(悲)