Android - 标签 - 有价值炮灰

使用 Joern 进行漏洞挖掘

Mon, 16 Sep 2024 12:40:00 +0800

曾几何时，在代码安全审计之道一文中介绍了一些形而上学的代码审计方法论，在该文章提及未来会继续介绍一些具体的漏洞挖掘工具和技巧，即代码安全审计之术。正所谓白驹过隙，光阴荏苒，不知不觉两年多过去了，由于怠惰一直没有动笔。不过我也一直没有忘记这茬，正好最近放假就给自己补上。

本文是使用开源的 Joern 来进行漏洞挖掘的介绍。

Joern 101

Joern 是一个开源的代码分析平台，可以通过多种不同的前端将源代码转换为代码属性图(Code Property Graph)，简称 CPG，然后通过 Joern 内置的查询语法对 CPG 进行查询和分析。如果读者对 CodeQL 比较了解的话，可以将 Joern 理解成开源版的 CodeQL。

Joern 通过不同的前端引擎支持不同的代码，比如使用 CDT 支持 C/C++ 代码的 fuzzing parsing，使用 Ghidra 支持二进制文件的解析，使用 Soot 支持 Java 字节码的解析等等。不同前端的成熟度有所不同，如下表所示：

Name	Built with	Maturity
C/C++	Eclipse CDT	Very High
Java	JavaParser	Very High
JavaScript	GraalVM	High
Python	JavaCC	High
x86/x64	Ghidra	High
JVM Bytecode	Soot	Medium
Kotlin	IntelliJ PSI	Medium
PHP	PHP-Parser	Medium
Go	go.parser	Medium
Ruby	ANTLR	Medium-Low
Swift	SwiftSyntax	Medium
C#	Roslyn	Medium-Low

joern-cli

joern-cli 是我们用来构建代码属性图和进行查找的套件，可以在 github 下载 release 版本的 joern-cli.zip，也可以通过自行编译的方式构建。

后续写复杂规则需要自动补全，以及需要搜索代码查看用例，因此推荐通过源代码方式编译：

git clone https://github.com/joernio/joern
cd joern
sbt stage

安装完成后可以进行实际测试，使用一个简单的 Java 文件 Hello.java 如下：

package demo;

import a.b.c.Foo;

public class Hello {
  static Foo foo = new Foo();

  public static void main(String[] args) {
    String data = foo.bar(args[0]);
    Runtime.exec(data);
  }
}

将该源码文件构建成代码属性图数据库(cpg)可以使用 joern-parse 脚本：

joern-parse --language javasrc Hello.java -o hello.cpg

有几个注意点：

language 选择的是 javasrc 而不是 java，后者是 Soot 的前端；
可以使用 joern-parse --list-languages 列举所有支持的前端(语言)；
Hello.java 中包含外部类 a.b.c.Foo，因此实际无法编译，但是却可以正确生成 cpg；

对该 cpg 进行查询：

joern hello.cpg
joern> cpg
val res0: io.shiftleft.codepropertygraph.generated.Cpg = Cpg[Graph[136 nodes]]
# ...
joern> def source = cpg.method("main").parameter
joern> def sink = cpg.call("exec").argument
joern> sink.reachableByFlows(source).p
val res7: List[String] = List(
  """
┌─────────────────┬──────────────────────────────┬────┬──────┬────┐
│nodeType         │tracked                       │line│method│file│
├─────────────────┼──────────────────────────────┼────┼──────┼────┤
│MethodParameterIn│main(String[] args)           │8   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Identifier       │String data = foo.bar(args[0])│9   │main  │    │
│Identifier       │Runtime.exec(data)            │10  │main  │    │
└─────────────────┴──────────────────────────────┴────┴──────┴────┘"""
)

核心的查询就三行，查找从 main 的参数到 Runtime.exec 的参数中的数据流链路：

def source = cpg.method("main").parameter
def sink = cpg.call("exec").argument
sink.reachableByFlows(source).p

其中 cpg 是我们的代码属性图根对象，针对代码的查找都基于此对象出发进行查询。上面的查询语句实际上是合法的 scala 语句，joern-cli 本身也是一个 scala 解释器。除了 cpg 对象，还定义了一些全局的对象和方法，可以使用 help 进行查看：

joern> help
val res8: Helper = Welcome to the interactive help system. Below you find
a table of all available top-level commands. To get
more detailed help on a specific command, just type

`help.`.

Try `help.importCode` to begin with.
┌────────────────┬────────────────────────────────────────────────┬─────────────────────────┐
│command         │description                                     │example                  │
├────────────────┼────────────────────────────────────────────────┼─────────────────────────┤
│close           │Close project by name                           │close(projectName)       │
│cpg             │CPG of the active project                       │cpg.method.l             │
│delete          │Close and remove project from disk              │delete(projectName)      │
│exit            │Exit the REPL                                   │                         │
│importCode      │Create new project from code                    │importCode("example.jar")│
│importCpg       │Create new project from existing CPG            │importCpg("cpg.bin.zip") │
│open            │Open project by name                            │open("projectName")      │
│openForInputPath│Open project for input path                     │                         │
│project         │Currently active project                        │project                  │
│run             │Run analyzer on active CPG                      │run.securityprofile      │
│save            │Write all changes to disk                       │save                     │
│switchWorkspace │Close current workspace and open a different one│                         │
│workspace       │Access to the workspace directory               │workspace                │
└────────────────┴────────────────────────────────────────────────┴─────────────────────────┘

joern> cpg.help
...

joern-cli 套件除了 joern-parse 和 joern，还包含了 joern-export、joern-scan 等脚本用户导出控制流图以及批量扫描等功能，关于这些工具的使用细节，可以参考官方的 Joern Documentation。

Steps

以 cpg 为根结点，我们可以查找代码属性图中的所有结点类型，比如类、方法、调用、控制流等。这些结点都可以以属性的形式获取，比如：

cpg.method: 表示所有方法结点；
cpg.parameter: 表示所有方法的参数；
cpg.method("main").parameter: 表示所有名称为 main 的方法的参数；
cpg.typeDecl("Foo").method: 表示所有名称为 Foo 的类中的所有方法；

其中以 cpg.method 为例，其返回值是 Iterator[Method] 类型，因此可以调用所有 Scala Iterator 的方法，比如 map、filter、toList、size、head 等，后文介绍 Scala 时会也会提及。

cpg.method.parameter 实际上是拓展了 Iterator，使其支持子查询。另外 Joern 还实现了一些特殊的 Step 比如用于递归查询的 repeat、times 系列和用于数据流分析的 sink.reachableBy(source) 系列。

所有类型的 Step 可以参考文档中的 Node-Type Steps 一节。

Scala 101

前面说过，Joern 使用 Scala 编写，而且其查询语句也是 Scala 语句，因此为了熟悉 Joern 的查询，我们有必要先简单学习一下 Scala。很多同学没用过 Scala，因此一看到就觉得它像 Lisp、Haskell 一样反人类，但其实这是一个很简单的语言。

Scala 是一种基于 JVM 的语言，也就是说 .scala 源码可以像 Java 一样编译为 .class 文件，同时被 JVM 加载运行。其实可以将 Scala 当成是一个 Java 的拓展，可以使用现有的 Java 生态。如果你用过 Kotlin，那么应该会对 Scala 的语法感到熟悉。

HelloWorld

一个简单的 hello.scala 代码如下：

object hello {
  def main(args: Array[String]) = {
    println("Hello, World!")
  }
}

如果是 Scala3，则可以更简单：

@main def hello() = println("Hello, World!")

编译运行：

scalac hello.scala
scala hello

语法速通

本节主要介绍一些 Joern 查询经常用到的语法。

首先是变量定义：

var a = 1
val b = List(1, 2)
val c = 1 to 5 // 表示 1 到 5 的 Iterator

可以看到 Scala 虽然是个强类型语言，但是可以做到智能类型推导，因此在变量赋值的时候通常无需指定类型。

函数定义：

def fn(x: Any) = println(x)
def fn1(x: Int) = { x * x }
def fn2 = 1 to 5

对于函数定义来说，所有的参数还是需要声明类型的，不过返回类型可以自动推导得到。

注意 def a = 1 to 5 和 val a = 1 to 5 的差异，两者都是返回 Iterator 对象，但是前者每次返回都是新的 Iterator，而后者指向同一个 Iterator，因此后者只能遍历一次。

匿名函数和 JavaScript 类似，可以写成箭头函数 (x: R) => x * x，常用于需要传入过滤函数的场景，比如：

def it = 1 to 5
it.map(x => x * 2)
// 对于单个函数参数，可以省略括号
it.map { x =>
  val y = x * 2
  println(y)
  y
}
// 可以使用 `_` 代替单个参数：
it.map(_ * 2)

Scala 中有一些特别的语法糖，比如中缀语法糖：

case class Pair(x: Int, y: Int) {
  def plus(other: Pair): Int = x + other.x + y + other.y
}

val p1 = Pair(1, 2)
val p2 = Pair(3, 4)
val sum = p1 plus p2  // 使用中缀语法
// 等价于
val sum = p1.plus(p2)

因此下面两个表达式也是等价的：

5 + 3
5.+(3)

按照惯例，如果你调用方法是为了利用方法的“副作用”，此时写上空括号，如果方法没有任何副作用（没有修改其它程序状态），你可以省略掉括号。

(1 to 5).toList()
// 一般写成
(1 to 5).toList

类定义方面，普通类和抽象类和 Java 中的定义类似，接口则和 Rust 比较类似，用 trait 定义：

trait MyTrait {
  def method(): Unit = println("This is a trait method.")
}

案例类，用于生成不可变的数据接口，自动生成 apply、unapply、toString、equals 等方法：

case class MyCaseClass(name: String, age: Int)

对象类，也称单例类，只能有一个实例：

object MyObject {
  def method(): Unit = println("yeah.")
}

基本的语法也就这样了，更多 Scala 的语法和使用细节可以通过阅读 Joern 或其他项目的源码去熟悉(使用 Scala 的项目有 Apache Spark、Kafka、Flink 等)。毕竟语言只是一种工具，多看多写才能有所进步。

sbt

和 Java 使用 maven 进行工程管理一样，Scala 一般使用 sbt 进行工程管理。有趣的是 sbt 的管理文件 build.sbt 也是使用 Scala 编写的，一个示例如下：

ThisBuild / scalaVersion := "2.13.12"
ThisBuild / organization := "com.example"

lazy val hello = project
  .in(file("."))
  .settings(
    name := "Hello",
    libraryDependencies += "org.scala-lang" %% "toolkit-test" % "0.1.7" % Test
  )

sbt 可以和 maven 一样通过模版新建工程：

sbt new scala/scala-seed.g8

编译测试运行：

sbt compile
sbt test
sbt clean run

Joern 的工程同样是通过 sbt 进行管理，因此了解 sbt 有助于我们后续理解其架构和阅读源码。更多的 sbt 功能参考官方文档 https://www.scala-sbt.org/ 。

实战分享

学习了 Joern 的基本代码属性图和 Scala 的语法，现在可以开始编写你的第一条代码分析规则了！本节列举一些常用查询示例，以便大家熟悉 Joern 查询的风格。

我们使用两个不同的项目进行测试，分别是一个 Spring 源码应用，以及一个 Android 应用。

joern
joern> importCode("vuln-spring")
joern> importCode("xiaomi.apk")

同一个 joern-cli 可以加载多个项目，通过 workspace 命令查看所有 project，通过 workspace.openProject 打开对应的工程。

在代码图属性数据层来说，具体的查找是语言无关的，不过某些 Step 只有在特定语言才会生效(比如 annotation)，因此具体选择的语言关系并不大，你也可以用 C/C++ 或者 Python 和 JavaScript 项目来进行测试。

Web 漏洞挖掘

vuln-spring 是一个 Spring Web 应用，对于这类项目，可能我们第一个想要找的就是路由：

cpg.annotation.where(_.name(".*Mapping")).method.fullName.l

这个查询应该还算比较直观，有个需要注意的是 where，它和 filter 的主要不同点在于前者过滤函数的返回值为 Iterator 类型，而 filter 的过滤函数需要返回 Boolean 类型。末尾的 .l 实际上是 .toList 的简写(alias)，即将 Iterator 转换为 List 进行输出。

然后是找漏洞点，比如 SQL 注入。这里以 springframework JdbcTemplate 为例，查找其类方法。

根据直觉很容易写入下面的查询：

cpg.typeDecl.fullNameExact("org.springframework.jdbc.core.JdbcTemplate").method.l

其中 fullNameExcat 是一个快捷方法，相当于 typeDecl.filter(_.fullName.equals("xx"))。前面查询用到的 name("xxx") 也是类似的实现。以 name 为例，常用的简写包括：

nameExact("xxx"): 等于；
name("xxx"): 正则表达式匹配；
nameNot("xxx"): 不等于，也是正则匹配；

.filter 和 .where 也包括类似的 filterNot 和 whereNot 快捷取反匹配。

但是，上面的查询实际上会返回空列表，因为 JdbcTemplate 这个类并不是定义在代码中的，而是在 Spring 的 jar 包中外部类。我们构建 CPG 数据库的时候并没有获取依赖，因此自然也就无法得知该类下的所有方法。

这是新手很容易犯的错误，不过只要了解原理就很容易避免，正确查找外部方法的方式是：

cpg.method.fullName("org\\.springframework\\.jdbc.core\\.JdbcTemplate\\..*")
// 或者
cpg.method.filter(_.fullName.startsWith("org.springframework.jdbc.core.JdbcTemplate."))
// 或者更用的，直接找调用
cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).code.l

将 source 和 sink 组合起来，就写出了我们第一条 SQL 注入查询规则：

def source = cpg.annotation.where(_.name(".*Mapping")).method.parameter
def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)
sink.reachableByFlows(source).p

.p 和 .l 一样是一个快捷方法，用于将 Iterator 以格式化文本的方式输出。上面的结果有部分误报，主要是指定了所有路由参数，其中包含一些不可控的 Model 或者 HttpSession 对象，可以进一步优化规则进行约束。

注意这里 sink 指定 argument(1) 表示第一个参数，argument(0) 一般表示方法调用的 this 对象。

sink.reachableBy(source) 返回的则是满足条件的 source，对于我们的查询而言是 Iterator[MethodParameterIn]；reachableByFlows 返回的是 Iterator[Path]，.p 会将其以表格的形式打印，如果你不喜欢默认的表格输出，也可以通过 map 方式转换为自定义的输出。

def prettyPath = (p: Path) => p.elements.map(
	e => String.format("%-20s %s", e.label, e.code)
).mkString("\n")
sink.reachableByFlows(source).map(prettyPath).mkString("\n\n===\n")

mkString 相当于 String.join 方法，将列表组合为字符串。输出示例：

METHOD_PARAMETER_IN  @RequestParam(name = "password", required = true) String password
IDENTIFIER           password          
METHOD_PARAMETER_IN  String password     
IDENTIFIER           password                       
CALL                 "SELECT * FROM users WHERE USERNAME=\"" + username + "\" AND PASSWORD=\"" + password + "\""
IDENTIFIER           query

通过这种方式我们可以结构化漏洞扫描输出，形成报告或者对接其他的后续验证逻辑。

Android 漏洞挖掘

与 Java 源码不同，有的 Jar 包只有字节码，不过 Joern 同样支持使用 Soot 去加载字节码并转换为 IR 从而将代码属性图存入数据库中。既然都是使用 Soot，那 Joern 是否支持 Android 漏洞扫描呢，答案是肯定的：

给 Joern 的第一个 PR

对于小型 APK 可以直接使用 jimple2cpg 或者 importCode 默认参数进行加载，而对于大型应用最好添加 --android 参数指定 android.jar (这是 Soot 的 API 导致的 Bug)。同时对于大型应用需要适当提高 JVM 内存。

jimple2cpg -J-Xmx30g --android $ANDROID_HOME/platforms/android-34/android.jar large.apk -o large.cpg

如果大家想要练手，可以使用一些开源的漏洞靶标应用进行测试，比如：

这里我们以一个实际漏洞为案例进行分析，即小米去年的一个系统应用命令注入漏洞。

漏洞详情可以参考 Oversecured 的博客 20 Security Issues Found in Xiaomi Devices，本节复现的是其中一个 System Tracing 应用的命令注入漏洞。对应的 APK 可以在 apkmirror 下载，见 System Tracing 1.0。

该漏洞原理在于小米动态注册了一个 AppReceiver，并且在其 onReceive 方法中通过接收的参数拼接 shell 命令执行导致命令注入。

对于漏洞挖掘而言，我们自动化挖掘该漏洞的难点在哪呢？首先在 Android 的四大组件中，BroadCastReceiver 比较特殊，它是唯一一个可以不用在 AndroidManifest.xml 中定义也可以使用的组件，即通过动态注册的方式初始化。

那么我们首要的任务就是找到所有代码中的 BroadCastReceiver 找出来，这个需求比较简单：

cpg.typeDecl.fullNameExact("android.content.BroadcastReceiver").derivedTypeDeclTransitive.fullName.l

derivedTypeDecl 及其变种 derivedTypeDeclTransitive 都是用于查找子类的辅助方法，如果自己写的话可以通过递归解析和查找 inheritsFromTypeFullName 属性来查找接口和父类。

这个查询只是找到所有 Receiver，但并不一定都有用到，所以我们进一步通过 Context.registerReceiver 查找实际注册的 Receiver 对象，并定位到实际的类型。

我们可以利用 Joern 数据流分析的能力，查找 BroadcastReceiver 的构造方法调用到 registerReceiver 的数据流，如下所示：

val baseCls = "android.content.BroadcastReceiver"
val receiverCls = cpg.typeDecl.fullNameExact(baseCls).derivedTypeDeclTransitive.fullName.l
def source = cpg.call.nameExact(Operators.alloc).filter(n => receiverCls.contains(n.typeFullName))
def sink = cpg.call.nameExact("registerReceiver").argument(1)

// 查找数据流
sink.reachableBy(source)

这个查询能够找到类似下面这种调用：

BroadcastReceiver r = new FooReceiver();
this.registerReceiver(r, filter);

但是却找不到我们这个漏洞所处于的位置，反编译代码：

public class ApplicationImpl extends Application {  
    private AppReceiver mDumpReceiver = new AppReceiver();  
  
    @Override // android.app.Application  
    public void onCreate() {  
        super.onCreate();  
        IntentFilter intentFilter = new IntentFilter();  
        intentFilter.addAction("com.android.traceur.DumpReceiver");  
        registerReceiver(this.mDumpReceiver, intentFilter);  
    }
}

这里实际上是通过属性的方式进行传递，可以看到 Joern 的数据流分析这里并没有关联上，因为 source 和 sink 分别在两个不相关的函数和 onCreate() 中，静态分析工具并不知道 onCreate 这种生命周期函数什么时候会被调用。

一种方式是修改 Joern 的前端代码，模拟 Runtime 进行生命周期方法调用，在解析代码属性图的时候为这些方法添加自定义的调用，从而补全增强控制流图(CFG)。

当然这种方式可能需要修改 Joern 源码，我们可以通过其他投机取巧的方式，观察到 source 和 sink 的连结断点主要在类属性上，那么可以尝试新建一个中间结点再做一次数据流分析。

def fieldAccess = cpg.fieldAccess.filter(fa => receiverCls.contains(fa.typeFullName) || fa.typeFullName.equals(baseCls))
// 所有 BroadCastReceiver 及其子类类型的属性读取结点
def fieldRead = fieldAccess.filter(fa => fa.argumentIndex == 2)
// 返回的是实际的 BroadCastReceiver 类型的属性
val reads = sink.reachableBy(fieldRead).toList
// 找到所有的属性名称，结果为 List[List[String]]
val fields = reads.map(r => List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head))
// 匹配上述 field 的所有写入
def fieldWrite = fieldAccess
  .filter(fa => fa.argumentIndex == 1)
  .filter{fa =>
    val li = fa.map( r =>
        List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head)
    )
    li.exists(fields.contains)
  }

// 数据流查询
fieldWrite.reachableByFlows(source).p

稍微解释一下：

fieldAccess.argumentIndex 表示属性在上级表达式中的参数位置，1 为写入，类似 r0.field = value，2 为读取，类似 r1 = r0.field；这个指定不是必须的，不过在代码量大的时候可以稍微提升下速度；
fieldAccess 包含所有类型为 BroadCastReceiver 及其子类的属性的访问，注意 receiverCls 中只包含子类，没包含 BroadCastReceiver 父类本身，因此需要加上以匹配多态的情况；
fields 是为了拿到所有的属性字段名称，以 List 的格式存储，包含类名和字段名，用字符串保存也是可以的；
然后在 fieldWrite 匹配对应字段的写入，这里使用了 List.exists 判断列表 li 中是否包含列表 fields 中的元素；

最后使用 reachableByFlows 找到所有原 source 到指定属性写中的链路，返回结果如下：

joern> fieldWrite.reachableByFlows(source).p
val res131: List[String] = List(
  """
┌──────────────────┬──────────────────────────────────────────────────┬────┬────────┬────────────────────────────────┐
│nodeType          │tracked                                           │line│method  │file                            │
├──────────────────┼──────────────────────────────────────────────────┼────┼────────┼────────────────────────────────┤
│Call              │new com.android.traceur.MainFragment$10           │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17 = new com.android.traceur.MainFragment$10    │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│MethodParameterIn │(this, com.android.traceur.MainFragment $r1)│227 │  │com.android.traceur.MainFragment│
│MethodParameterOut│RET                                               │227 │  │com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
│Call              │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
└──────────────────┴──────────────────────────────────────────────────┴────┴────────┴────────────────────────────────┘""",
  """
┌──────────────────┬─────────────────────────────────────────┬────┬──────┬───────────────────────────────────┐
│nodeType          │tracked                                  │line│method│file                               │
├──────────────────┼─────────────────────────────────────────┼────┼──────┼───────────────────────────────────┤
│Call              │new com.android.traceur.AppReceiver      │8   ││com.android.traceur.ApplicationImpl│
│Identifier        │$r1 = new com.android.traceur.AppReceiver│8   ││com.android.traceur.ApplicationImpl│
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   ││com.android.traceur.ApplicationImpl│
│MethodParameterIn │(this)                             │38  ││com.android.traceur.AppReceiver    │
│MethodParameterOut│RET                                      │38  ││com.android.traceur.AppReceiver    │
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   ││com.android.traceur.ApplicationImpl│
│Identifier        │r0.mDumpReceiver = $r1                   │8   ││com.android.traceur.ApplicationImpl│
│Call              │r0.mDumpReceiver = $r1                   │8   ││com.android.traceur.ApplicationImpl│
└──────────────────┴─────────────────────────────────────────┴────┴──────┴───────────────────────────────────┘"""
)

找到了两个匹配，其中第二个即为我们要找的漏洞类，第一个结果匹配的点为：

public class MainFragment extends PreferenceFragment {
	// ...
	private BroadcastReceiver mRefreshReceiver;
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onCreate(Bundle bundle) {
	    // ...
	    this.mRefreshReceiver = new BroadcastReceiver() { // from class: com.android.traceur.MainFragment.10
            @Override // android.content.BroadcastReceiver
            public void onReceive(Context context, Intent intent) {
                MainFragment.this.refreshUi();
            }
        };
    }
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onStart() {
        super.onStart();
        // ...
        getActivity().registerReceiver(this.mRefreshReceiver, new IntentFilter("com.android.traceur.REFRESH_TAGS"), 4);
        Receiver.updateTracing(getContext());
    }
}

可以看到我们这个查询语句同样也找到了基于多态的匿名类赋值，其中动态注册的类名为 com.android.traceur.MainFragment$10。虽然规则写得有点 ugly，不过已经基本能用了。

后续操作就是要继续添加规则，将两种不同的数据流合并，然后将 source 中的构造方法对应类名提取出来，再定位其 onReceive 方法，将该方法的参数作为后续阶段漏洞分析的 source，从而查找到危险函数如 Runtime.exec 等的调用。

进阶操作

从前面的分享中应该已经基本了解了 Joern 的用法和常见查询，同时也知道该工具存在一些局限性。幸运的是 Joern 同时也存在很强的拓展性，本节就来介绍一些比较有用的拓展操作。

数据流语义

在前面介绍 Web 漏洞挖掘时，我们的 SQL 查询实际上有很多误报，其中最为严重的一个误报是明明指定了 sink 是 JdbcTemplate 的方法第一个参数，但实际上参数传入了其他参数也会认为是有效路径：

def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)

这是因为 Joern 对于没有代码的外部方法，为了保持可靠性(soundness)，会将这些方法的传播规则设置为传播到所有参数和返回值，牺牲误报率以减少漏报率。

However, to remain sound, Joern will treat external methods with no semantic definitions as able to propagate taint from all arguments, to all arguments including the return value.

这无疑提高了我们分析误报的成本。那么有没有什么方法可以优化数据流分析，即对指定方法进行语义配置呢？答案是有的。我们可以指定额外的 FlowSemantic 列表，如下所示：

import io.joern.dataflowengineoss.layers.dataflows.{OssDataFlow, OssDataFlowOptions}
import io.shiftleft.semanticcpg.layers.LayerCreatorContext
import io.joern.dataflowengineoss.semanticsloader.FlowSemantic

val extraFlows = List(
    FlowSemantic.from(
        "^path.*\\.sanitizer$", // Method full name
        List((1, 1)), // Flow mappings
        regex = true  // Interpret the method full name as a regex string
    )
)

val context = new LayerCreatorContext(cpg)
val options = new OssDataFlowOptions(extraFlows = extraFlows)
new OssDataFlow(options).run(context)

数据流映射通过数字 Tuple 实现：

1, -1 表示第一个参数数据流会传播给返回值；
1, 2 表示第一个参数数据流会传播给第二个参数；
1, 0 表示第一个参数数据流会传播给示例对象(this)；
1, 1 表示第一个参数数据流会传播给自身，通常用于表示数据流是否中断，即用于指定 sanitizer；

比如如下代码：

x = source()
foo(x) // "foo" 1->1 表示数据流继续向下传播，否则会中断
sink(x)

除了以上面的代码形式指定，Joern 也支持使用 semanticsloader/Parser 加载语义文件，每行表示一条 extraFlows，包含多个 FlowSemantic，以空格分隔，例如：

"foo" 1->-1 2->3

每个参数都需要带有位置标识，不过对于某些语言可以指定命名参数：

"foo" 1 "param1"->2 3 -> 2 "param2"

对于一般的数据流分析，会认为默认参数间不互相污染，并且参数会污染返回值。因为大家写得比较多，所以 Joern 也提供了特殊的规则即 PASSTHROUGH:

"foo" PASSTHROUGH 0 -> 0

使用 scala 代码为：

FlowSemantic("foo", List(PassThroughMapping))

从语义上来说等价于 foo(1, 2) = 1 -> 1, 2 -> 2, 1 -> -1, 2 -> -1，即所有参数会污染自身和函数的返回值，注意没有 0 -> 0，因此 this 对象不会污染自身。

我们可以通过 context.semantics.elements 查看当前默认的 FlowSemantic 列表。前面添加语义使用的 val context = new LayerCreatorContext(cpg) 会覆盖当前的 context 对象。

从实践上来看，创建语义的方式有多种，可以自行选取适合的方式：

import io.joern.dataflowengineoss.semanticsloader.{FlowSemantic, PassThroughMapping, Parser}
// 调用构造方法
val s = FlowSemantic("org\\.springframework.*", List(PassThroughMapping), true)
// 调用静态方法
val s = FlowSemantic.from("org\\.springframework.*", List((1, -1)), true)
// 使用 Parser
val parser = Parser()
// 从字符串加载单条或者多条语义，返回列表
val extraFlows = parser.parse(""" "foo" PASSTHROUGH 0 -> 0 """)
// 从文件中加载
val extraFlows = parser.parseFile("semantics.txt")

更多细节可以查看官方的文档介绍 Dataflow Semantics 或者查看源码。

控制流增强

不同于数据流分析，有时候我们仅仅关注控制流，比如下面的语句可以递归查找调用：

cpg.method.name("exec").repeat(_.caller)(_.emit.dedup).fullName.sorted

对于我们之前 Android 漏洞挖掘的例子，数据流分析在面对 Android 运行时的一些回调函数时无法进行跟踪，本质也是因为控制流没有关联上。由于 Joern 本身是基于 Scala 的查询，而且也把所有数据结构暴露给了用户，那其实也可以像自定义数据流语义一样添加新的控制流规则。

伪代码如下：

val methods = cpg.method
val node1 = methods.next
val node2 = methods.next
node1.addEdge(EdgeTypes.AST, node2)

可基于 joern-cli 的自动补全查看支持的边类型：

joern> EdgeTypes.
ALIAS_OF             AST                  CALL                 CDG                  CONTAINS             IMPORTS              PARAMETER_LINK       REACHING_DEF         SOURCE_FILE
ALL                  BINDS                CAPTURE              CFG                  DOMINATE             INHERITS_FROM        POINTS_TO            RECEIVER             TAGGED_BY
ARGUMENT             BINDS_TO             CAPTURED_BY          CONDITION            EVAL_TYPE            IS_CALL_FOR_IMPORT   POST_DOMINATE        REF

这是旧版本的用法，新版本中使用 diffGraph 对象，类型为 DiffGraphBuilder，使用 diffGraph.addEdge 可以直接新增控制流边。

考虑一个最常见的多线程调用场景：

class ThreadDemo {
  public static void main(String args[]) throws Exception {
    final String cmd = String.format("sh -c \"%s\"", args[0]);
    Thread th = new Thread(new Runnable() {
      @Override
      public void run() {
        System.out.println("Running in a new thread");
        try {
          System.out.println("return: " + Runtime.getRuntime().exec(cmd));
        } catch(Exception ignore) {}
      }
    });
    th.start();
    Thread.sleep(1000);
  }
}

正如前面所说，如果使用正常的静态分析，是无法识别到输入到输出的数据流的：

def source = cpg.method.nameExact("main").parameter
def sink = cpg.call.nameExact("exec").argument
sink.reachableBy(source)

针对这个用例，我们需要让程序知道 Thread.start 会调用到 Runnable.run，因此可以直接添加一条边：

val call = cpg.call("start").head
val target = cpg.method("run").head
diffGraph.addEdge(call, target, EdgeTypes.CALL)
run.commit

然后再运行 sink.reachableBy 就能找到正确的调用链了：

joern> sink.reachableByFlows(source).p
val res4: List[String] = List(
  """                                                                                                                  
┌──────────────────┬────────────────────────────────────────────────────────────────────────────┬────┬──────┬────┐     
│nodeType          │tracked                                                                     │line│method│file│   
├──────────────────┼────────────────────────────────────────────────────────────────────────────┼────┼──────┼────┤
│MethodParameterIn │main(String[] args)                                                         │2   │main  │    │
│Call              │.arrayInitializer                                                 │3   │main  │    │
│Call              │.arrayInitializer                                                 │3   │main  │    │
│Call              │String.format("sh -c \"%s\"", args[0])                                      │3   │main  │    │
│Identifier        │String cmd = String.format("sh -c \"%s\"", args[0])                         │3   │main  │    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│MethodParameterIn │(this, cmd)                                                           │4   ││    │
│Identifier        │this.cmd = cmd                                                              │4   ││    │
│Call              │this.cmd = cmd                                                              │4   ││    │
│MethodParameterOut│RET                                                                         │N/A ││    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│Block             │$obj0                                                                       │4   │main  │    │
│Identifier        │new Thread(new Runnable() { @Override public void run() {                   │4   │main  │    │
│                  │System.out.println("Running in a new thread"); try {                        │    │      │    │
│                  │System.out.println("return: " + Runtime.getRuntime().exec(cmd)); } catch    │    │      │    │
│                  │(Exception ignore) { } } })                                                 │    │      │    │
│Identifier        │th.start()                                                                  │13  │main  │    │
│MethodParameterIn │run(this)                                                                   │5   │run   │    │
│Call              │Runtime.getRuntime().exec(cmd)                                              │9   │run   │    │
└──────────────────┴────────────────────────────────────────────────────────────────────────────┴────┴──────┴────┘""",

注意 diffGraph 只是一个临时的差分图，需要 commit 之后才能将差异提交到 cpg 中。这只是一种简单的示例，代码中还没关联 Thread 对应的具体 Runable 类，这就留给读者进行完善了。

如果需要对代码属性图做复杂的操作，比如针对反射实现数据流跟踪等，可以使用自定义 Pass，参考下一节的介绍。

CpgPass

前面我们提到了 diffGraph，笔者其实是通过搜索代码找到的，发现在 ghidra2cpg 的 JumpPass.scala 中就有类似的操作：

class JumpPass(cpg: Cpg) extends ForkJoinParallelCpgPass[Method](cpg) {

  override def generateParts(): Array[Method] =
    cpg.method.toArray
  override def runOnPart(diffGraph: DiffGraphBuilder, method: Method): Unit = {
    method.ast
      .filter(_.isInstanceOf[Call])
      .map(_.asInstanceOf[Call])
      .nameExact(".goto")
      .where(_.argument.order(1).isLiteral)
      .foreach { sourceCall =>
        sourceCall.argument.order(1).code.l.headOption.flatMap(parseAddress) match {
          case Some(destinationAddress) =>
            method.ast.filter(_.isInstanceOf[Call]).lineNumber(destinationAddress).foreach { destination =>
              diffGraph.addEdge(sourceCall, destination, EdgeTypes.CFG)
            }
          case _ => // Ignore for now
          /* TODO: Ask ghidra to resolve addresses of JMPs */
        }
      }
  }

  private def parseAddress(address: String): Option[Int] = {
    Try(Integer.parseInt(address.replaceFirst("0x", ""), 16)).toOption
  }
}

Pass 是 Joern 中用于后处理 CPG 图数据库的结点，比如生成 CFG(Control Flow Graph) 和 DDG(Data Dependency Graph) 等。

针对上一节提到的控制流增强，笔者写了个简单的 DemoPass：

import io.shiftleft.codepropertygraph.generated.{Cpg, EdgeTypes, PropertyNames}
import io.shiftleft.codepropertygraph.generated.nodes.{Call, Method, StoredNode, Type, TypeDecl}
import io.shiftleft.passes.CpgPass


class DemoPass(cpg: Cpg) extends CpgPass(cpg) {

  override def run(diffGraph: DiffGraphBuilder): Unit = {
    val call = cpg.call("start").head
    val target = cpg.method("run").head
    val targetNode = methodFullNameToNode(target.fullName).get
    diffGraph.addEdge(call, targetNode, EdgeTypes.CALL)
    println(s"Add Edge: $call -> $targetNode")
  }

  private def nodesWithFullName(x: String): Iterator[StoredNode] =
    cpg.graph.nodesWithProperty(PropertyNames.FULL_NAME, x).cast[StoredNode]

  private def methodFullNameToNode(x: String): Option[Method] =
    nodesWithFullName(x).collectFirst { case x: Method => x }
}

通过以下方式加载：

new DemoPass(cpg).createAndApply()
run.commit

和 Pass 对应的是 Overlay，Joern 首次加载 CPG 或者使用 joern-parse 生成数据库的时候会默认执行一部分 pass，按照不同的层次依次执行。我们可以通过 project.appliedOverlays 查看当前生效的 Pass：

joern> project.availableOverlays
joern> project.appliedOverlays
res0: Seq[String] = IndexedSeq("base", "controlflow", "typerel", "callgraph", "dataflowOss")

以负责数据流分析的 dataflowOss 为例，其代码实现在 OssDataFlow.scala，会首先执行 ReachingDefPass，同时加上了 extraFlows 实现自定义的数据流控制。

我们可以参考其代码实现自己的 Overlay 来增强 Joern 的功能，这也是其强拓展性的一个表现。

其他

在编写 Joern 代码查询规则的过程中，一个必备的知识就是需要了解其支持的 API，我们可以通过 joern-cli 的 help 命令查看 cpg 的具体 Step 以及后继支持的 Step 和简单介绍：

cgp.help
cpg.method.help
cpg.typeDecl.help

也可以通过下面的文档进行查阅：

Node Type Steps - Reference Card - 官方的文档；
queries.joern.io - joern-query 的示例查询规则；

但不管是 joern-cli 的 help 命令还是官方文档，都没有完全覆盖所有的 Step，比如我们上面用到查询装饰的 annotation 和用于查询所有子类的 derivedTypeDecl。那么笔者是如何得知这些 API 的呢？一个方法是在社区里看别人的提问和回复，但这显然效率太低。另一个方法就是通过查询源码的方式找到这些信息。

在 Joern 的主仓库 joernio/joern 中有许多单元测试，比如我们查看一些递归搜索的示例，可以搜索 .repeat( 从而查看具体选项例如 .emit、maxDepth 等用法。

另外 Joern 的图数据库基座是 joernio/flatgraph，其前身是 overflowdb，最近 4.0 版本才完成切换。在该仓库中可以找到每个 Step 的实现。从中我们发现递归搜索 .repeat 默认为深度优先，可以通过 .bfs 设置为广度优先，等等诸如此类的 Trick。

从代码中我们能找到一些比较实用的 Step，比如 collectAll 用于返回指定类型的节点。scala 中的 collect 相当于 filter+map 的结合：

.collectAll[Call]
// 相当于
.collect { case x: Call => x }
// 相当于
.filter(_.isInstanceOf[Call]).map(_.asInstanceOf[Call])

自定义 Step

我们之前用到的这些 Step，其实也可以自定义，比如我们想要在 method 中新增一个 fooStep 查询，可以使用以下方法：

implicit class MyMethodTraversals(method: Traversal[Method]) {
  def fooStep = method.fullName(".*org.example.*").isPublic
}

cpg.method.fooStep

这使用了 Scala 的 implicit 隐式类类特性，用于通过隐式转换为现有类型添加新方法。隐式类通常用于增强现有类型的功能，而无需直接修改这些类型的定义。

可视化

有时编写规则的时候对于某些条件不太好判断，但是将全部结点打印出来又不直观，Joern 提供了一系列绘图方法可以打印指定结点的流图：

joern> cpg.method("main").plotDot
plotDotAst     plotDotCdg     plotDotCfg     plotDotCpg14   plotDotDdg     plotDotPdg

各种图的定义如下：

AST: Abstract Syntax Tree，抽象语法树；
CDG: Control Dependence Graph，控制依赖图，主要包含 if/else 等控制结构的依赖关系；
CFG: Control Flow Graph，控制流图，程序执行的所有可能路径；
DDG: Data Dependency Graph，数据依赖图，包含属于依赖关系；
PDG: Program Dependence Graph，程序依赖图，包含控制依赖和数据依赖关系；

plotDotXXX 会直接打开默认的图片预览工具，如果是没有图形界面的环境，可以通过 dotXXX 获取 dot 图片的 digraph 文本格式：

cpg.method("main").dotAst.head #> "/tmp/main.dot"

其中使用了自定义的操作符 #> 来将字符串重定向到文件中，也算是一个比较有用的小特性。还有其他用法就有待大家继续深入挖掘了。

总结

通过上面的分享，相信大家对 Joern 也有了比较直观的了解。先说说使用的缺点，首先是文档不完善，很多接口需要查看源代码或者在社区里找答案；另一个广为诟病的是其数据流引擎，存在很多误报和漏报的情况。上面的代码中看到它名字叫 ossdataflow，只实现了非常简单的数据流，和 CodeQL 等商业软件相比还有差距。这不禁让人想起隔壁村的 radare2，以及一张开源梗图：

不过 Shiftleft(Joern 所属公司) 还有一款商业的代码扫描工具，名为 ocular，其中大部分功能和 joern 一致，只不过其数据流引擎是优化过的，而且增加了许多接口的建模，感兴趣的可以参考 joern-vs-ocular。由此可见不是没有能力做好，只是由于利益关系注定不会在上面投入太多。

虽然有很多缺点，但 Joern 也有其优势。首先是其架构设计比较优雅，可以基于不同的前端加入新的语言支持，除了源码还支持字节码和二进制程序(汇编)；其次是其查询语言基于成熟的编程语言 Scala 来实现，具备很强的灵活性，可以实现各种复杂的查询；最后就是作为开源软件，主打一个 “自主可控”，只要具备一定编码能力那么基本各种需求都能够实现，从而克服前面说到的诸多缺点。

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/09/16/using-joern/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Java 应用安全之 JEB Floating License 绕过

Fri, 03 May 2024 12:40:00 +0800

最近一朋友单位采购了 JEB Pro 用于 Android 逆向，但使用的是 Floating License，因此只能在公司内网中使用。这样一来朋友在节假日就没法卷了，于是找到了我看有没有兴趣研究一下。虽然笔者之前搞过一段时间 Java 逆向，但那主要针对 Android 应用，对于 PC 应用那是大姑娘坐花轿 —— 头一回。本着学习新知识的心态，就接下了这个任务。

前言

以防有朋友不了解，JEB 是一个逆向工程工具，主要用于 Android APK 的逆向分析，针对 smali 字节码反编译的功能类似于 JADX，但是也支持对 SO 等二进制程序的逆向分析。

一般来说 JEB Pro 采用订阅机制，根据使用的机器进行收费，一机一密。但对于企业而言通常采用浮动授权，即 Floating License，允许一个或者多个不固定的机器同时使用。JEB floating controller 是官方用于运行在服务端的私有浮动授权服务器，其本质上是一个 HTTP 服务器，运行后直接访问会显示授权信息。

JEB Floating Controller

客户端则需要在 jeb-client.cfg 中配置 .ControllerInterface 和 .ControllerPort 等信息，或者在启动 JEB Pro 的时候填入服务端地址，从而实现授权。

逆向分析

对于静态分析而言，和 Android 应用中的静态分析流程基本一致，都是拖到 JADX 中然后搜索某些关键字，比如授权失败的提示信息，或者配置的信息。

首先我们将授权服务的地址指定为 127.0.0.1:23477，然后用 NC 监听该地址，启动后很快收到了请求：

Listening on 0.0.0.0 23477
Connection received on localhost 52330
POST /probe HTTP/1.1
User-Agent: PNF Software UP
Content-Type: application/x-www-form-urlencoded
Content-Length: 189
Host: 127.0.0.1:23477
Connection: Keep-Alive
Accept-Encoding: gzip

data=5400000035E5...

可见 JEB Pro 和浮动授权服务器是通过 HTTP 请求进行通讯的。

$ zipgrep /probe bin/app/jeb.jar
grep: (standard input): binary file matches

直接搜索请求的路径 /probe，可以定位到下面的代码：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/ga.class */  
public class ga {  
    private static String nz = cns.nz("1150...");  
    private static String Fj = cns.nz(new byte[]{117, 90, 69, 74, 69}, 2, 120);  
    private Net jU;  
    private String Fx;  
    private int tQ;  
    private String Fh;  
  
    public ga(Net net, String str, int i, int i2) {  
        if (net == null) {  
            throw new IllegalArgumentException();  
        }  
        if (str == null || str.isEmpty()) {  
            throw new IllegalArgumentException("Controller Interface is not set");  
        }  
        if (i <= 0 || i >= 65535) {  
            throw new IllegalArgumentException("Illegal Controller Port value must be between 0 and 65535");  
        }  
        this.jU = net;  
        this.Fx = str;  
        this.tQ = i;  
        Object[] objArr = new Object[3];  
        objArr[0] = i2 == 1 ? "https" : NetProxyInfo.TYPE_HTTP;  
        objArr[1] = str;  
        objArr[2] = Integer.valueOf(i);  
        this.Fh = Strings.ff("%s://%s:%d/probe", objArr);  
    }
    // ...
    public String nz(String str) {  
        return JebNet.post(this.jU, this.Fh, str);  
    }  
  
    public void Fj(String str) {  
        JebNet.post(this.jU, this.Fh, str);  
    }
}

看起来像是通过的 JebNet.post 发送请求的。接下来有两个策略，一是继续静态分析不断查看交叉应用来来定位请求发送点，二是使用动态分析来验证该处是否确实被调用。懒人首选必然是后者。

动态分析

说起动态分析就有点怀念移动端常用的 frida 了。针对 Android 应用可以通过 hook 某些特定函数去检查参数、调用栈，并且对参数和返回值进行修改。理论上 frida 在 PC 端也是可以使用的，但是只支持了一部分版本的 OpenJDK，实测笔者的 JDK 17 支持并不是很好。

由于前一段时间研究过 Java Web 应用，那时用得最多的工具要数 arthas 了。这是一个阿里巴巴开源的线上 Java 诊断利器，基于 JVMTI 注入应用，避免了调试器中断的繁琐流程。该工具使用 ASM 来动态修改 Java 字节码，不同于 frida 基于二进制的注入，ASM 对于 JDK 而言有很高的兼容性。

由于 arthas 使用 OGNL 作为表达式，因此对于 hook 的过滤和修改也具备很强的灵活性。关于其具体的使用方法可以参考官方文档，这里就不再赘述了。

直接使用 as.sh 指定 JEB 的进程 ID，然后 hook JebNet.post 方法，查看调用堆栈：

[arthas@70354]$ stack com.pnfsoftware.jeb.client.JebNet post params.length==3
Press Q or Ctrl+C to abort.
Affect(class count: 1 , method count: 2) cost in 53 ms, listenerId: 4
ts=2024-04-02 13:21:06;thread_name=Thread-9;id=1a;is_daemon=true;priority=5;TCCL=jdk.internal.loader.ClassLoaders$AppClassLoader@531d72ca
    @com.pnfsoftware.jeb.client.JebNet.post()
        at com.pnfsoftware.jebglobal.ga.nz(SourceFile:71)
        at com.pnfsoftware.jebglobal.aW.jU(SourceFile:194)
        at com.pnfsoftware.jebglobal.aW.run(SourceFile:81)
        at java.lang.Thread.run(Thread.java:833)

果然是这里，核心的 jU 方法如下：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/aW.class */  
public class aW implements Runnable {
    private long jU() {  
        Fg Fj2;  
        try {  
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();  
            LEDataOutputStream lEDataOutputStream = new LEDataOutputStream(byteArrayOutputStream);  
            lEDataOutputStream.writeInt(0);  
            lEDataOutputStream.writeLong(this.sM);  
            lEDataOutputStream.writeLong(this.Pm);  
            lEDataOutputStream.close();  
            String nz2 = this.Fh.nz(Fg.nz(Fg.nz(te.Fj(), byteArrayOutputStream.toByteArray(), new int[1])));  
            if (nz2 == null || (Fj2 = Fg.Fj(Fg.nz(nz2.trim()))) == null) {  
                return -1L;  
            }  
            this.fR = Fj2.tQ();  
            LEDataInputStream lEDataInputStream = new LEDataInputStream(new ByteArrayInputStream(Fj2.dv()));  
            if (lEDataInputStream.readInt() != 1) {  
                return -1L;  
            }  
            return lEDataInputStream.readLong();  
        } catch (Exception e) {  
            nz.catching(e);  
            return -1L;  
        }  
    }
    // ...
}

aW 这个类本身是个 Runnable，是使用一个额外的线程进行启动的，这里请求被调用的地方如下：

  
    @Override // java.lang.Runnable  
    public void run() {  
        int i = 0;  
        int i2 = 0;  
        boolean z = false;  
        while (true) {  
            long jU2 = jU();  
            try {  
                if (jU2 == 0 || jU2 == 2) {  
                    if (jU2 == 2 && !z) {  
                        nz.warn(cns.nz(new byte[]{26, 54, 26, 7, 82, 106, 15, 7, 98, 67, 15, 5, 12, 11, 26, 84, 73, 26, 83, 79, 3, 8, 1, 23, 82, 84, 28, 9, 15, 78, 84, 28, 13, 69, 67, 12, 1, 26, 6, 29, 3, 0, 9, 23, 82, 89, 22, 26, 85, 65, 19, 23, 69, 67, 12, 1, 0, 11, 6, 23, 17, 1, 68, 84, 27, 78, 1, 116, 59, 79, 65, 23, 25, 6, 13, 68, 85, 27, 11, 29, 8, 21, 6, 23, 17, 1, 68, 66, 7, 13, 9, 23, 31, 6, 29, 94, 12, 89, 22, 26, 85, 83, 27, 7, 26, 25, 8, 68, 85, 5, 20, 5, 21, 17, 69, 89, 22, 26, 7, 82, 83, 28, 9, 18, 3, 22, 19, 23}, 1, 67), new Object[0]);  
                        z = true;  
                    }  
                    if (i != 0 || i2 != 0) {  
                        nz.warn(...);  
                    }  
                    i = 0;  
                    i2 = 0;  
                } else {  
                    nz.warn(...);  
                    boolean z2 = false;  
                    if (jU2 <= -1) {  
                        i++;  
                        if (i >= 3) {  
                            z2 = true;  
                        }  
                    } else {  
                        z2 = true;  
                    }  
                    if (z2) {  
                        //...
                        nz.info("trycnt=%d", Integer.valueOf(i3));  
                        AbstractContext.terminate();  
                    }  
                }  
                Thread.sleep(10000L);  
            } catch (InterruptedException unused2) {  
                return;  
            }  
        }

简单来说：

这个线程会一直循环执行，且每隔 10 秒执行一次；
当 jU 的返回结果不为 0 时，且到达了最大的重试次数后，会发送失败事件，并关闭 JEB；
弹窗相关的文字以及日志信息是经过加密的，即 cns.nz 方法，猜测主要是为了防止黑客搜索关键字。不过并没有对所有字符串都进行加密，所以我们还是能搜到 HTTP 路径信息；

Patch

这里的 patch 思路就很多了，我们可以直接把线程 nop 掉，也可以只针对请求的地方，这里我们选择后者。

patch 方案也有几种，一是直接修改 class 字节码，不过这个流程相对复杂。我们可以先使用 arthas 生成 Java 代码，然后修改反编译的 Java 代码后重新进行编译、加载，如下所示：

jad --source-only com.pnfsoftware.jebglobal.aW > /tmp/aW.java
# 修改 aW.java jU 方法返回 0
# 重新编译
mc /tmp/aW.java
# 加载
redefine com/pnfsoftware/jebglobal/aW.class

如果想要进行持久化，那么只需要将 jeb.jar 解压并替换掉 aW.class 重新打包即可。

Java Agent

虽然重打包可以修改原始的程序代码逻辑，但却对原始代码进行了修改，jar 包的签名也进行了改变。如果目标程序本身有完整性校验很可能被检测出来。更好的方法就是使用 Java Agent 去对目标代码进行动态修改，即使用 JVM 本身的 -javaagent 参数注入一个 jar 去动态修改原始程序逻辑(或者通过动态 attach 的方式)。arthas 本身和常用的 RASP 都是基于这个原理。

关于 Java Agent 可以参考官方的文档，对于开发者而言只需要关注几个重点：

编译的 agent jar 通过 -javaagent:agent.jar 的方式进行指定，可以在程序启动之前加载；
agent.jar 中需要再 Manifest 指定 Premain-Class，指定的类包含 premain 方法，会在启动时被 JVM 调用；

一个示例 Agent 如下所示：

public class Agent {

    public static void log(String fmt, Object ...args) {
        System.out.printf("[agent] " + fmt + "\n", args);
    }

    public static void premain(String agentArgs, Instrumentation inst) {
        log("premain called.");
        if (!inst.isRetransformClassesSupported()) {
            log("Class retransformation is not supported.");
            return;
        }

        HookTransformer.replace(inst, "com.pnfsoftware.jebglobal.aW", "jU",
        """
        {
            System.out.println("[agent-hook] skip check.");
            return 0;
        }
        """);
    }

}

HookTransformer 是笔者写的一个粗糙的 ClassFileTransformer 实现。主要使用 javassist 动态生成字节码，并覆写 transform 方法替换目标 Class 的字节码，从而修改目标方法的实现。

完整的代码可以参考 HookAgent，为了方便以后每次逆向破解新项目的时候不用频繁编译，将待劫持的类名、方法名和方法体使用参数进行传递，同时将修改后的方法体保存在新文件中。

基于上述 HookAgent.jar，修改 JEB 自带的命令行参数 jvmopt.txt 即可实现注入：

cat jvmopt.txt
-Xmx16G --add-opens java.base/java.lang=ALL-UNNAMED -Xverify:none -javaagent:HookAgent.jar=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js

随后启动 JEB 观察日志可以看到 agent 成功注入，并且 agent 的日志也每隔 10 秒输出一次：

./jeb_linux.sh
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
[agent] premain enter, agentArgs=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Parsing hook options from agentArgs: className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Reading methodImpl from hook.js
[agent] Loaded com.pnfsoftware.jebglobal.aW->jU: {
    System.out.println("[agent-hook] skip check: " + new java.util.Date());
    return 0;
}
...
[agent] CtMethod: javassist.CtMethod@31736c[private jU ()J]
[agent] byteCode size: 5899
[agent] Hooked: com.pnfsoftware.jebglobal.aW->jU
[I] JEB 5.12.xxx (jeb-pro-floating) is starting...
[I] Memory Usage: 44.1M used (475.9M free, 16.0G max)
[agent] transform: com.pnfsoftware.jebglobal.aW->jU
[agent-hook] skip check: Thu May 02 20:15:49 CST 2024
[agent-hook] skip check: Thu May 02 20:15:59 CST 2024

这里是将循环检查的方法返回值固定成了 0，但实际上可以选择的点很多，比如直接 hook 这个 Runnable 的 run 方法也是可以的。

总结

本文主要以 JEB Floating License 的校验过程为例，学习了 Java PC 客户端应用的一般分析方法。在反编译和逆向分析的基础上，配合动态调试或者 Arthas 等动态分析框架，可以快速找到目标执行路径。随后可以使用静态重打包或者 Java Agent 动态注入的方式去实现代码逻辑修改的持久化，从而实现“破解”的效果。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/05/03/java-agent/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Android 反序列化漏洞攻防史话

Sat, 18 Feb 2023 12:40:00 +0800

Java 在历史上出现过许多反序列化的漏洞，但大部分出自 J2EE 的组件。即便是 FastJSON 这种漏洞，似乎也很少看到在 Android 中被实际的触发和利用。本文即为对历史上曾出现过的 Android Java 反序列化漏洞的分析和研究记录。

序列化和反序列化是指将内存数据结构转换为字节流，通过网络传输或者保存到磁盘，然后再将字节流恢复为内存对象的过程。在 Web 安全领域，出现过很多反序列化漏洞，比如 PHP 反序列化、Java 反序列化等。由于在反序列化的过程中触发了非预期的程序逻辑，从而被攻击者用精心构造的字节流触发并利用漏洞从而最终实现任意代码执行等目的。

Android 中除了传统的 Java 序列化机制，还有一个特殊的序列化方法，即 Parcel。根据官方文档的介绍，Parcelable 和 Bundle 对象主要的作用是用于跨进程边界的数据传输(IPC/Binder)，但 Parcel 并不是一个通用的序列化方法，因此不建议开发者将 Parcel 数据保存到磁盘或者通过网络传输。

作为 IPC 传输的数据结构，Parcel 的设计初衷是轻量和高效，因此缺乏完善的安全校验。这就引发了历史上出现过多次的 Android 反序列化漏洞，本文就按照时间线对其进行简单的分析和梳理。

注: 本文中所展现的 AOSP 示例代码，如无特殊说明则都来自文章发表时的 master 分支。

Parcel 101

在介绍漏洞之前，我们还是按照惯例先来了解下基础知识。对于有过 Android 开发或者逆向分析经验的同学应该对 Parcel 都不陌生，但通常也很少直接使用该类去序列化/反序列化数据然后进行 IPC 通信，而是通过 AIDL 等方法去自动生成模版，然后集成实现对应接口。

AIDL

关于 AIDL 开发的示例可以参考 Android 进程间通信与逆向分析一文，简单来说，假设有以下 AIDL 文件:

package com.evilpan;

interface IFooService {
    parcelable Person {
        String name;
        int age;
        boolean gender;
    }
    String foo(int a, String b, in Person c);
}

那么生成的(Java)模版大致结构如下:

public interface IFooService extends android.os.IInterface {

    public java.lang.String foo(int a, java.lang.String b, com.evilpan.IFooService.Person c) throws android.os.RemoteException;
    public static class Person implements android.os.Parcelable { /* ... */ }

    public static abstract class Stub extends android.os.Binder implements com.evilpan.IFooService {
        @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
            data.enforceInterface(descriptor);
            // ...
            switch(code) {
                case TRANSACTION_foo {
                    int _arg0;
                    _arg0 = data.readInt();
                    java.lang.String _arg1;
                    _arg1 = data.readString();
                    com.evilpan.IFooService.Person _arg2;
                    _arg2 = _Parcel.readTypedObject(data, com.evilpan.IFooService.Person.CREATOR);
                    java.lang.String _result = this.foo(_arg0, _arg1, _arg2);
                    reply.writeNoException();
                    reply.writeString(_result);
                    break;
                }
            }
        }
    }

    private static class Proxy implements com.evilpan.IFooService {
        @Override public java.lang.String foo(int a, java.lang.String b, com.evilpan.IFooService.Person c) throws android.os.RemoteException
        {
            android.os.Parcel _data = android.os.Parcel.obtain();
            android.os.Parcel _reply = android.os.Parcel.obtain();
            java.lang.String _result;
            try {
            _data.writeInterfaceToken(DESCRIPTOR);
            _data.writeInt(a);
            _data.writeString(b);
            _Parcel.writeTypedObject(_data, c, 0);
            boolean _status = mRemote.transact(Stub.TRANSACTION_foo, _data, _reply, 0);
            _reply.readException();
            _result = _reply.readString();
            }
            finally {
            _reply.recycle();
            _data.recycle();
            }
            return _result;
        }
    }
    // ...
}

其中 IFooService.Stub 类是本地的 IPC 实现，即服务端代码通过继承至该类并实现其 foo 方法；而 Proxy 则是客户端的的辅助类，客户端可以通过调用 Proxy.foo 方法间接地调用服务端的对应代码。数据传输的过程通过 transact 方法实现，其底层是 Android 的 Binder IPC；而数据的封装过程则通过 Parcel 实现。

可以看到上面模版代码中客户端分别调用了 writeInterfaceToken、writeInt、writeString 和 writeTypedObject 来填充传输的 _data，而 Stub 类的 onTransact 中以同样的顺序分别调用了 enforceInterface、readInt、readString、readTypedObject 来获取 _data 中的数据。

Parcelable

在上面的 AIDL 中，我们还定义了一个数据结构 Person，该结构同样会由 AIDL 生成对应的模版类:

public static class Person implements android.os.Parcelable
{
  public java.lang.String name;
  public int age = 0;
  public boolean gender = false;
  public static final android.os.Parcelable.Creator<Person> CREATOR = new android.os.Parcelable.Creator<Person>() {
    @Override
    public Person createFromParcel(android.os.Parcel _aidl_source) {
      Person _aidl_out = new Person();
      _aidl_out.readFromParcel(_aidl_source);
      return _aidl_out;
    }
    @Override
    public Person[] newArray(int _aidl_size) {
      return new Person[_aidl_size];
    }
  };
  @Override public final void writeToParcel(android.os.Parcel _aidl_parcel, int _aidl_flag)
  {
    int _aidl_start_pos = _aidl_parcel.dataPosition();
    _aidl_parcel.writeInt(0);
    _aidl_parcel.writeString(name);
    _aidl_parcel.writeInt(age);
    _aidl_parcel.writeInt(((gender)?(1):(0)));
    int _aidl_end_pos = _aidl_parcel.dataPosition();
    _aidl_parcel.setDataPosition(_aidl_start_pos);
    _aidl_parcel.writeInt(_aidl_end_pos - _aidl_start_pos);
    _aidl_parcel.setDataPosition(_aidl_end_pos);
  }
  public final void readFromParcel(android.os.Parcel _aidl_parcel)
  {
    int _aidl_start_pos = _aidl_parcel.dataPosition();
    int _aidl_parcelable_size = _aidl_parcel.readInt();
    try {
      if (_aidl_parcelable_size < 4) throw new android.os.BadParcelableException("Parcelable too small");;
      if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
      name = _aidl_parcel.readString();
      if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
      age = _aidl_parcel.readInt();
      if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
      gender = (0!=_aidl_parcel.readInt());
    } finally {
      if (_aidl_start_pos > (Integer.MAX_VALUE - _aidl_parcelable_size)) {
        throw new android.os.BadParcelableException("Overflow in the size of parcelable");
      }
      _aidl_parcel.setDataPosition(_aidl_start_pos + _aidl_parcelable_size);
    }
  }
  @Override
  public int describeContents() {
    int _mask = 0;
    return _mask;
  }
}

其中关键的是 writeToParcel 和 CREATOR.createFromParcel 方法，分别填充了该自定义结构序列化和反序列化的实现，当然我们也可以自己继承 Parcelable 去实现自己的可序列化数据结构。

内存布局

从接口上看，Parcel 可以支持按照一定顺序写入和读取 int、long 等原子数据，也支持 String、IBinder、和 FileDescriptor 这些复杂的数据结构。为了理解后文介绍的漏洞，还需要了解在二进制层面这些数据的存储方式。

Parcel 的代码接口实现在 android/os/Parcel.java 中，但大部分方法最终都会调用到其中的 native 方法，其 JNI 定义在 frameworks/base/core/jni/android_os_Parcel.cpp 文件里，最终的实现则是在 frameworks/native/libs/binder/Parcel.cpp 中。

以 Parcel.writeInt 为例，其 Java 实现很简单，直接转到 native 方法:

private static native int nativeWriteInt(long nativePtr, int val);
public final void writeInt(int val) {
    int err = nativeWriteInt(mNativePtr, val);
    if (err != OK) {
        nativeSignalExceptionForError(err);
    }
}

C++ 中的 JNI 实现则是先将 nativePtr 转换为 Parcel 指针，而后直接调用 writeInt32 方法:

static int android_os_Parcel_writeInt(jlong nativePtr, jint val) {
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    return (parcel != NULL) ? parcel->writeInt32(val) : OK;
}

接下来就是最终实际的实现了:

status_t Parcel::writeInt32(int32_t val)
{
    return writeAligned(val);
}

template<class T>
status_t Parcel::writeAligned(T val) {
    static_assert(PAD_SIZE_UNSAFE(sizeof(T)) == sizeof(T));
    static_assert(std::is_trivially_copyable_v<T>);

    if ((mDataPos+sizeof(val)) <= mDataCapacity) {
restart_write:
        memcpy(mData + mDataPos, &val, sizeof(val));
        return finishWrite(sizeof(val));
    }

    status_t err = growData(sizeof(val));
    if (err == NO_ERROR) goto restart_write;
    return err;
}

writeAligned 是个模版函数，用于写入基础的 C++ 数据类型，即 int、float、double 等，也可以写入指针数据。实现也相对简单，这里面就涉及到了 Parcel 内部的几个重要数据结构:

mData: 序列化数据内存缓冲区的内存起始地址(指针)；
mDataPos: 序列化数据当前解析到的相对位置；
mDataCapacity: 缓冲区的总大小；

还有一个字段 mDataSize 表示当前序列化数据的大小，其实这个字段基本上和 mDataPos 的值是一致的，二者都在 finishWrite 函数中进行更新:

status_t Parcel::finishWrite(size_t len)
{
    if (len > INT32_MAX) {
        // don't accept size_t values which may have come from an
        // inadvertent conversion from a negative int.
        return BAD_VALUE;
    }

    //printf("Finish write of %d\n", len);
    mDataPos += len;
    ALOGV("finishWrite Setting data pos of %p to %zu", this, mDataPos);
    if (mDataPos > mDataSize) {
        mDataSize = mDataPos;
        ALOGV("finishWrite Setting data size of %p to %zu", this, mDataSize);
    }
    //printf("New pos=%d, size=%d\n", mDataPos, mDataSize);
    return NO_ERROR;
}

而如果当前缓冲区的内存不足，则会使用 growData 方法进行更新:

status_t Parcel::growData(size_t len)
{
    if (len > INT32_MAX) {
        // don't accept size_t values which may have come from an
        // inadvertent conversion from a negative int.
        return BAD_VALUE;
    }

    if (len > SIZE_MAX - mDataSize) return NO_MEMORY; // overflow
    if (mDataSize + len > SIZE_MAX / 3) return NO_MEMORY; // overflow
    size_t newSize = ((mDataSize+len)*3)/2;
    return (newSize <= mDataSize)
            ? (status_t) NO_MEMORY
            : continueWrite(std::max(newSize, (size_t) 128));
}

continueWrite 方法的实现比较复杂，因为其中还支持传入小于 mDataSize 的参数去缩小 Parcel 内存，不过在我们这里的上下文中仅用于增长内存，因此实际上最终只是通过 realloc 或者 malloc 去分配更多的内存:

if (desired > mDataCapacity) {
    uint8_t* data = reallocZeroFree(mData, mDataCapacity, desired, mDeallocZero);
    if (data) {
        LOG_ALLOC("Parcel %p: continue from %zu to %zu capacity", this, mDataCapacity,
                desired);
        gParcelGlobalAllocSize += desired;
        gParcelGlobalAllocSize -= mDataCapacity;
        mData = data;
        mDataCapacity = desired;
    } else {
        mError = NO_MEMORY;
        return NO_MEMORY;
    }
}

这部分目前只需要了解即可，我们关注的还是前面写入数据的逻辑，回顾一下是在 writeAligned 方法中，直接通过 memcpy 去写入的数据，因此对于基础数字类型是没有额外开销的，且序列化的字节序就是当前机器的字节序。这也是为什么 Parcel 只适合在同一设备中实现 IPC，如果对于不同设备中可能会出现字节序的问题。

String

说完了 Int 我们接着看常用的 String 类型，JNI 的定义和实现如下:

static void android_os_Parcel_writeString16(JNIEnv *env, jclass clazz, jlong nativePtr,
        jstring val) {
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    if (parcel != nullptr) {
        status_t err = NO_ERROR;
        if (val) {
            // NOTE: Keep this logic in sync with Parcel.cpp
            const size_t len = env->GetStringLength(val);
            const size_t allocLen = len * sizeof(char16_t);
            err = parcel->writeInt32(len);
            char *data = reinterpret_cast<char*>(parcel->writeInplace(allocLen + sizeof(char16_t)));
            if (data != nullptr) {
                env->GetStringRegion(val, 0, len, reinterpret_cast<jchar*>(data));
                *reinterpret_cast<char16_t*>(data + allocLen) = 0;
            } else {
                err = NO_MEMORY;
            }
        } else {
            err = parcel->writeString16(nullptr, 0);
        }
        if (err != NO_ERROR) {
            signalExceptionForError(env, clazz, err);
        }
    }
}

和之前差别不大，值得注意的是 Parcel::writeInplace 返回的是待写入的内存地址，直接用了 JNIEnv::GetStringRegion 去进行写入。如果 Java 传入的字符串是 null，则使用 writeString16(nullptr) 去写入，其内部实现是写入特殊的整数 -1:

GetStringRegion 返回的是 Unicode 字符，因此每个字符占 2 字节；

status_t Parcel::writeString16(const char16_t* str, size_t len)
{
    if (str == nullptr) return writeInt32(-1);
    // ...
}

因此对于字符串结构，Parcel 的序列化也是无开销顺序写入的。

Array

数组也是个常用的数据类型，但不同的数组传输格式有所不同。对于 char/int/long 等原始类型而言，传输数组实际上就是逐个写入每个元素，并且在前面写入数组的大小:

public final void writeIntArray(@Nullable int[] val) {
    if (val != null) {
        int N = val.length;
        writeInt(N);
        for (int i=0; i<N; i++) {
            writeInt(val[i]);
        }
    } else {
        writeInt(-1);
    }
}

但是 wirteByteArray 有所优化:

public final void writeByteArray(@Nullable byte[] b, int offset, int len) {
    if (b == null) {
        writeInt(-1);
        return;
    }
    ArrayUtils.throwsIfOutOfBounds(b.length, offset, len);
    nativeWriteByteArray(mNativePtr, b, offset, len);
}

JNI 中直接使用 memcpy 去写入:

static void android_os_Parcel_writeByteArray(JNIEnv* env, jclass clazz, jlong nativePtr,
                                             jobject data, jint offset, jint length)
{
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    parcel->writeInt32(length);
    void* dest = parcel->writeInplace(length);
    jbyte* ar = (jbyte*)env->GetPrimitiveArrayCritical((jarray)data, 0);
    if (ar) {
        memcpy(dest, ar + offset, length);
        env->ReleasePrimitiveArrayCritical((jarray)data, ar, 0);
    }
}

Parcelable

对于 Parcelable 类型的数据，使用 writeParcelable 方法进行写入:

public final void writeParcelable(@Nullable Parcelable p, int parcelableFlags) {
    if (p == null) {
        writeString(null);
        return;
    }
    writeParcelableCreator(p);
    p.writeToParcel(this, parcelableFlags);
}

public final void writeParcelableCreator(@NonNull Parcelable p) {
    String name = p.getClass().getName();
    writeString(name);
}

其中需要注意的是在调用 Parcelable.writeToParcel 之前，会先获取 Parcelable 实际的类名，并以字符串的方式写入。

FileDescriptor

Andorid IPC 的一个特点是可以支持传输文件句柄，其 JNI 实现如下:

static void android_os_Parcel_writeFileDescriptor(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
{
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    if (parcel != NULL) {
        const status_t err =
                parcel->writeDupFileDescriptor(jniGetFDFromFileDescriptor(env, object));
        if (err != NO_ERROR) {
            signalExceptionForError(env, clazz, err);
        }
    }
}

object 为 FileDescriptor 对象，这里的实现就是获取 FileDescriptor.fd，即 open(2) 返回的，int 格式的文件描述符，进行 fcntl(oldFd, F_DUPFD_CLOEXEC, 0) 复制后进行写入。

Binder 的系统调用本身就支持传输文件类型的数据，因此这里 Parcel 的实现只需要做好上层的封装:

status_t Parcel::writeFileDescriptor(int fd, bool takeOwnership) {
    // ...
    switch (rpcFields->mSession->getFileDescriptorTransportMode()) {
        case RpcSession::FileDescriptorTransportMode::UNIX:
        case RpcSession::FileDescriptorTransportMode::TRUSTY: {
            if (status_t err = writeInt32(RpcFields::TYPE_NATIVE_FILE_DESCRIPTOR); err != OK) {
                return err;
            }
            if (status_t err = writeInt32(rpcFields->mFds->size()); err != OK) {
                return err;
            }
        }
    }
    flat_binder_object obj;
    obj.hdr.type = BINDER_TYPE_FD;
    obj.flags = 0;
    obj.binder = 0; /* Don't pass uninitialized stack data to a remote process */
    obj.handle = fd;
    obj.cookie = takeOwnership ? 1 : 0;
    return writeObject(obj, true);
}

值得一提的是，writeObject 中写入数据除了更新上面提到的 mData 等字段，还需要更新 kernelFields，如 mObjects 字段，作为内核参数的记录。

Binder

在 Android IPC 中一个重要的参数类型就是回调，即客户端发送一个 IBinder 类型的对象给服务端，然后服务端可以调用其 onTransact 方法实现反向异步的数据传输。对于这种类型的数据，主要通过 writeStrongBinder 方法:

public final void writeStrongBinder(IBinder val) {
    nativeWriteStrongBinder(mNativePtr, val);
}

JNI 实现和传输文件类似:

static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
{
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    if (parcel != NULL) {
        const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
        if (err != NO_ERROR) {
            signalExceptionForError(env, clazz, err);
        }
    }
}

主要分为两步，第一步取出 IBinder Java 对象的 Native 指针，即 IBinder.mObject，然后将其转为 C++ 的 IBinder 指针传入:

status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
    return flattenBinder(val);
}

传输 IBinder 类型的数据同样需要更新 mObjects 缓存。

其他

除了上面介绍的这些，Parcel 实现中还有许多值得关注的细节，比如 writeBlob 同样也是写入 byte[]，但对于过大的数据会选择用共享内存的方式去进行传输。但根据上面的简单分析，我们也能大致看出 Parcel 的一些问题，即序列化和反序列化纯属手工操作，并且在某些操作中没有严格的类型检查等，下面我们就来逐一探讨。

Bundle

在 Andorid 中，Bundle 类是一个类似 HashMap 的数据结构，但其是为了在 Parcel 序列化/反序列化的使用中而高度优化的。因此理解 Bundle 本身的序列化过程对我们理解后面的内容也至关重要。

序列化

Bundle 的序列化过程调用链路如下:

Bundle.writeToParcel
BaseBundle.writeToParcelInner
parcel.writeArrayMapInternal

writeToParcelInner 中主要负责写入 Bundle 相关的头部字段:

void writeToParcelInner(Parcel parcel, int flags) {
    // Keep implementation in sync with writeToParcel() in
    // frameworks/native/libs/binder/PersistableBundle.cpp.
    final ArrayMap<String, Object> map;
    synchronized (this) {
        // ...
    }

    // Special case for empty bundles.
    if (map == null || map.size() <= 0) {
        parcel.writeInt(0);
        return;
    }
    int lengthPos = parcel.dataPosition();
    parcel.writeInt(-1); // dummy, will hold length
    parcel.writeInt(BUNDLE_MAGIC);

    int startPos = parcel.dataPosition();
    parcel.writeArrayMapInternal(map);
    int endPos = parcel.dataPosition();

    // Backpatch length
    parcel.setDataPosition(lengthPos);
    int length = endPos - startPos;
    parcel.writeInt(length);
    parcel.setDataPosition(endPos);
}

writeArrayMapInternal 则主要实现 Bundle 内部字典数据的写入:

void writeArrayMapInternal(@Nullable ArrayMap<String, Object> val) {
    if (val == null) {
        writeInt(-1);
        return;
    }
    // Keep the format of this Parcel in sync with writeToParcelInner() in
    // frameworks/native/libs/binder/PersistableBundle.cpp.
    final int N = val.size();
    writeInt(N);
    int startPos;
    for (int i=0; i<N; i++) {
        writeString(val.keyAt(i));
        writeValue(val.valueAt(i));
    }
}

可以看到序列化 Bundle 的过程是和序列化 ArrayMap 一致的，即先写入整型的 size，然后依次写入每个 key 和 value。这里值得注意的是 wirteValue 的实现:

public final void writeValue(@Nullable Object v) {
    if (v == null) {
        writeInt(VAL_NULL);
    } else if (v instanceof String) {
        writeInt(VAL_STRING);
        writeString((String) v);
    } else if (v instanceof Integer) {
        writeInt(VAL_INTEGER);
        writeInt((Integer) v);
    } else if (v instanceof Map) {
        writeInt(VAL_MAP);
        writeMap((Map) v);
    } // .... 
    else {
        Class clazz = v.getClass();
        if (clazz.isArray() && clazz.getComponentType() == Object.class) {
            // Only pure Object[] are written here, Other arrays of non-primitive types are
            // handled by serialization as this does not record the component type.
            writeInt(VAL_OBJECTARRAY);
            writeArray((Object[]) v);
        } else if (v instanceof Serializable) {
            // Must be last
            writeInt(VAL_SERIALIZABLE);
            writeSerializable((Serializable) v);
        } else {
            throw new RuntimeException("Parcel: unable to marshal value " + v);
        }
    }
}

注意，为了便于按照时间线理解历史漏洞，这里代码使用的是 Android 8.0 中的版本。

writeValue 会根据对象类型分别写入一个代表类型的整数以及具体的数据。所支持的类型如下所示:

// Keep in sync with frameworks/native/include/private/binder/ParcelValTypes.h.
private static final int VAL_NULL = -1;
private static final int VAL_STRING = 0;
private static final int VAL_INTEGER = 1;
private static final int VAL_MAP = 2;
private static final int VAL_BUNDLE = 3;
private static final int VAL_PARCELABLE = 4;
private static final int VAL_SHORT = 5;
private static final int VAL_LONG = 6;
private static final int VAL_FLOAT = 7;
private static final int VAL_DOUBLE = 8;
private static final int VAL_BOOLEAN = 9;
private static final int VAL_CHARSEQUENCE = 10;
private static final int VAL_LIST  = 11;
private static final int VAL_SPARSEARRAY = 12;
private static final int VAL_BYTEARRAY = 13;
private static final int VAL_STRINGARRAY = 14;
private static final int VAL_IBINDER = 15;
private static final int VAL_PARCELABLEARRAY = 16;
private static final int VAL_OBJECTARRAY = 17;
private static final int VAL_INTARRAY = 18;
private static final int VAL_LONGARRAY = 19;
private static final int VAL_BYTE = 20;
private static final int VAL_SERIALIZABLE = 21;
private static final int VAL_SPARSEBOOLEANARRAY = 22;
private static final int VAL_BOOLEANARRAY = 23;
private static final int VAL_CHARSEQUENCEARRAY = 24;
private static final int VAL_PERSISTABLEBUNDLE = 25;
private static final int VAL_SIZE = 26;
private static final int VAL_SIZEF = 27;
private static final int VAL_DOUBLEARRAY = 28;

可以看到其中支持大部分基础类型以及 Parcelable、IBinder 等 Parcel 本身所支持的类型。

综上所述，我们可以大致得出 Bundle 的内存布局:

size	type	value
4	Int	length
4	Int	BUNDLE_MAGIC (0x4C444E42)
4	Int	map.size()
xxx	String	key[0]
xxx	Dynamic	val[0]
…	…	…
xxx	String	key[map.size() - 1]
xxx	Dynamic	val[map.size() - 1]

其中 key 因为是 String 类型，因此内部是长度 + String16 的布局，而 value 则根据类型不同使用不同的结构。

key:

length Int32
data String16

value:

VAL_XXX Int32
data writeInt/writeString/…

下面是在一个 Bundle 序列化的示例，原始内容为:

Bundle A = Bundle()
A.putInt("key1", 0x1337)
A.putString("key2", "hello")
A.putLong("key33", 0x0123456789)

使用 Parcel 序列化后的二进制数据如下:

Bundle 序列化

其中有几个需要注意的细节:

length 字段是不包括 length+magic 部分的，因此实际上序列化数据的总大小会比头部的结果大 8 字节即 100；
String 数据是 4 字节对齐的(如 key33)；如果本身已经对齐，也会在后面进行特殊拓展，如(key1/key2)；特殊拓展的值为 Parcel::writeInplace 中的 padMask，对于已经 4 字节对齐的 mask 正好是 0；

存储

Bundle 虽然内部是 ArrayMap 结构，但实际存储的时候还有一点优化。在平时开发中细心的朋友可能会发现，有时候在获取远程的 Bundle 比如 CotentResolver.call 的结果时候，直接打印输出会是 Bundle[mParcelledData.dataSize=xxx] 的结果。但是对于自己构建的 Bundle，却可以打印出完整的 Map 元素。

这其实可以从 Bundle 的源码中看出来:

@Override
public synchronized String toString() {
    if (mParcelledData != null) {
        if (isEmptyParcel()) {
            return "Bundle[EMPTY_PARCEL]";
        } else {
            return "Bundle[mParcelledData.dataSize=" +
                    mParcelledData.dataSize() + "]";
        }
    }
    return "Bundle[" + mMap.toString() + "]";
}

关键就是这个 mParcelledData 字段，该字段定义在父类即 BaseBundle 中，为 Parcel 类型。由于 Bundle 经常在进程间进行传输，因此设计上认为可以不要到对端的时候马上就反序列化出所有的 ArrayMap，而是等需要用到时再进行解析，这也可以认为是一种懒加载的技术。对于一些收到 Bundle 后马上又传输给其他服务的场景，这种设计可以直接传输未解析的 Parcel 数据而不需要来回的序列化。

因此对于 Bundle 而言，对于一些需要获取内部元素的调用时才会进行反序列，比如 size 和 isEmpty 的实现:

public int size() {
    unparcel();
    return mMap.size();
}

public boolean isEmpty() {
    unparcel();
    return mMap.isEmpty();
}

值得注意的是，在 Bundle 内部，ArrayMap(mMap) 和 Parcel(mParcelledData) 同一时间只能存在一个，反序列化后会填充 mMap 把 mParcelledData 回收并置为 null。

反序列化与 Bundle 风水

最早提交 Android 反序列化漏洞的是 @BednarTildeOne 在 2014 年提交的 ParceledListSlice 漏洞，但第一次引起公众关注的应该是 CVE-2017-0806。也是同样的作者，不过给出了详细的分析以及漏洞 POC 代码，这才得以引起关注。

该漏洞的原理已经有很多师傅分析过了，就不再赘述，这里直接给出一个简化的版本。假设有这么一个 Parcelable 数据结构，请问是否存在漏洞？漏洞如何利用？

public class Vulnerable implements Parcelable {
    private long mData;

    protected Vulnerable(Parcel in) {
        mData = m.readInt();
    }

    @Override
    public void writeToParcel(Parcel parcel, int flags) {
        parcel.writeLong(mData)
    }
    // ...
}

问题很明显，可以看到其中序列化使用了 writeLong，但是反序列化过程却用了 readInt，二者不匹配，这可能会导致一些数据错误，但这能算得上一个漏洞吗？

回想 LunchAnywhere 漏洞以及对应的 patch，实际上是用户可控的 Intent 数据中带有 KEY_INTENT extra 导致的启动任意 Activity 的问题。修复过程是判断用户提供的 Intent 是否带有该 extra，如果有则校验调用者的签名。当时的修复可以说没什么问题，但如果配合上述的漏洞，就有可能出现绕过。

这里还是以测试代码举例，假设我们的校验函数如下:

@Override
public void onResult(Bundle result) {
    Intent intent = result.getParcelable(AccountManager.KEY_INTENT)
    if (intent != null) {
        checkCallingSignature()
    }
    // ...
    send(result)
}

public void send(Bundle result); // AIDL

校验时如果 intent 不为空则进行签名校验，随后会调用 AIDL 的客户端方法 send，该方法将 bundle 再次序列化然后发送给服务端，而服务端的实现如下:

class Server extends IServer.Stub {
    @Override
    public void send(Bundle result) {
        Intent intent = bundle.getParcelable(KEY_INTENT);
        if (intent != null) {
            mContext.startActivity(intent)
        }
    }
}

因为客户端进行了校验，所以服务就不需要再次校验而是直接信任该 Bundle 并使用了。这里其实有个经典的漏洞模式即 TOCTOU 问题，一般情况下这个逻辑是没问题的，即 bundle 检查完后不会被再次修改。但在我们的漏洞场景中，就有可能会出现不同的 bundle，即 Self-Changing Bundle。

自修改 Bundle

Bundle 自修改，主要还是针对上面的这种 IPC 场景，一端对 Bundle 进行了校验，发现没问题后使用 IPC 发送给另一端，且对方不加校验就直接使用。即 Bundle 在序列化+反序列化的过程中进行了改变。

假设服务端 B 接收我们的 Bundle 数据进行反序列化后再次序列化发送给服务端 C，而我们的 bundle 中带有一个类型为 Vunerable 的 key，那在 B 接收到数据后再发出去的数据会如下图右边所示，其中本该是 Int 的字段被写成了 Long，导致 C 再次反序列化时候对后续数据的解析出现异常:

From: Android Parcels: The Bad, the Good and the Better - Introducing Android's Safer Parcel

通过精心构造发送给 B 的数据，我们可以令 B 和 C 都能正常序列化出 Bundle 对象，甚至让这两个 Bundle 含有不同的 key！

漏洞利用

该漏洞如何利用呢？前文中我们已知 Bundle 序列化数据的头部后面每个元素都是 key+value 的组合，那利用思路应该就是将多出来的 4 字节进行类型混淆。这种场景类似于二进制的缓冲区溢出，我们需要做的就是布局好数据使得同时满足下述条件:

类型混淆前后，Bundle 的 length 和 items 字段保持一致；
两次反序列化得到的对象都需要是合法对象；
第二次反序列化要能够出现一个前面没有的 Bundle key；

溢出的 4 个字节会作为后面一个 key 的一部分，而 key 的类型是 String，根据前面的介绍，其内存是长度(Int32) + String16。其中 String16 是 unicode，使用 2 字节保存一个字符。因此，如果 map 元素足够的话，这 4 个字节会形成下一个 key 的长度。

在大部分情况下，溢出的部分是 Long 数据的高有效位，因此会是 0，如果此时第二次反序列化处理到这里，会认为这有个 key 长度为 0 的元素，查看读取字符串相关的代码，如下所示:

const char16_t* Parcel::readString16Inplace(size_t* outLen) const
{
    int32_t size = readInt32();
    // watch for potential int overflow from size+1
    if (size >= 0 && size < INT32_MAX) {
        *outLen = size;
        const char16_t* str = (const char16_t*)readInplace((size+1)*sizeof(char16_t));
        if (str != nullptr) {
            if (str[size] == u'\0') {
                return str;
            }
            android_errorWriteLog(0x534e4554, "172655291");
        }
    }
    *outLen = 0;
    return nullptr;
}

考虑到 padding 的存在，即便 size 为 0，还是会读出 (0+1)x2 即 2 字节的 \x00。readInplace 中还会对齐，因此最终读出的是 4 字节数据。因此，后续的反序列化都会在原来的基础上后移 4 字节。

这样一来利用思路就比较清晰了:

构造一个恶意 Bundle，其中包含两个元素 A0 和 A1，其中 A0 为 Vunlerable，在 A1 中布置 payload；
反序列化+序列化后，数据多出 4 字节，且下个元素的解析从 A1 的 key 内容开始；
构造 A1 的 key 和 value，使得第 2 步中解析出新的 key；

还是以前面的 Vulnerable 类为例，POC 代码如下:

val p = Parcel.obtain()

val lengthPos = p.dataPosition()
// header
p.writeInt(-1) // length, back-patch later
p.writeInt(0x4C444E42) // magic
val startPos = p.dataPosition();
p.writeInt(3) // numItem

// A0
p.writeString("A")
p.writeInt(Type.VAL_PARCELABLE.value)
p.writeString("com.evilpan.poc.Vulnerable")
p.writeInt(666) // mData

// A1
p.writeString("\u000d\u0000\u0008") // 0d00 0000 0800
p.writeInt(Type.VAL_BYTEARRAY.value)
p.writeInt(28)
p.writeString("intent")              // 4 + padSize((6 + 1) * 2) = 4+16 = 20
p.writeInt(Type.VAL_INTEGER.value)   // = 4
p.writeInt(0x1337)                   // = 4

// A2
p.writeString("BBB")
p.writeInt(Type.VAL_NULL.value)

// Back-patch length && reset position

val A = unparcel(p)
Log.i("A = " + inspect(A))
Log.i("A.containsKey: " + A.containsKey("intent"))

val B = unparcel(parcel(A))
Log.i("B = " + inspect(B))
Log.i("B.containsKey: " + B.containsKey("intent"))

在上述 POC 中，我们明面上构造了一个含有 3 个元素的 Bundle，分别是:

A0: Parcelable 类型，元素为我们带有漏洞的 Parcelable；
A1: ByteArray 类型，长度为 28 字节，ByteArray 的内容为隐藏的 Intent 元素，即 20+4+4；
A2: NULL 类型；

其中关键的是 A1 的 key，在触发漏洞后，会被解析为第二个元素的元素类型和长度，即解析出来的内容为:

0d000000: 解析为元素类型，等于 VAL_BYTEARRAY(13)；
08000000: 解析为 ByteArray 长度，即 8 字节；注意这里额外的 0 是字符串写入时候 pad 出来的。

之所以是 8 字节，是为了把后面的长度字段吞掉，使得解析下一个元素可以直接到我们隐藏的 intent 中。

第三个元素 A2 只是用于占位，在第一次序列化时候有用，第二次时直接被我们隐藏的 intent 替代了。上述代码的运行结果如下:

[INFO]: A = Bundle(item = 3) length: 144
[INFO]:   => 41000000 = VAL_PARCELABLE:com.evilpan.poc.Vulnerable{mData=666}
[INFO]:   => 0d00000008000000 = VAL_BYTEARRAY:0600000069006e00740065006e007400000000000100000037130000
[INFO]:   => 4200420042000000 = VAL_NULL:null
[INFO]: A.containsKey: false
[INFO]: === writeToParcel ===
[INFO]: B = Bundle(item = 3) length: 148
[INFO]:   => 41000000 = VAL_PARCELABLE:com.evilpan.poc.Vulnerable{mData=666}
[INFO]:   => 03000000 = VAL_BYTEARRAY:0d0000001c000000
[INFO]:   => 69006e00740065006e00740000000000 = VAL_INTEGER:1337
[INFO]: B.containsKey: true

可以看到第一次反序列化出来的 Bundle A 包含三个 key，其中并没有 intent 字段，但经过序列化再反序列化后的 Bundle B 已经修改了，第二个元素的变成了长度为 8 字节的 ByteArray，实际上其 key 长度为；第三个元素则是我们伪造的 intent 元素，值为 0x1337，因此我们成功地绕过了第一次 containsKey 的校验，而在第二次中进行触发！

上述例子在 Android 12 中进行测试，理论上之前的版本也类似。

实际上的漏洞与这个例子大同小异，由于 Android 系统对 IPC 的大量使用，许多操作都会在 system_server、Settings 应用、用户应用中来回穿梭，也就造成了许多上述 TOCTOU 的问题。对其中细节感兴趣的可以参考下面的分析文章:

漏洞修复

上述漏洞的修复似乎很直观，只需要把 Vulnerable 类中不匹配的读写修复就行了。但实际上这类漏洞并不是个例，历史上由于代码编写人员的粗心大意，曾经出现过许多因为读写不匹配导致的提权漏洞，包括但不限于:

CVE-2017-0806 GateKeeperResponse
CVE-2017-0664 AccessibilityNodelnfo
CVE-2017-13288 PeriodicAdvertisingReport
CVE-2017-13289 ParcelableRttResults
CVE-2017-13286 OutputConfiguration
CVE-2017-13287 VerifyCredentialResponse
CVE-2017-13310 ViewPager’s SavedState
CVE-2017-13315 DcParamObject
CVE-2017-13312 ParcelableCasData
CVE-2017-13311 ProcessStats
CVE-2018-9431 OSUInfo
CVE-2018-9471 NanoAppFilter
CVE-2018-9474 MediaPlayerTrackInfo
CVE-2018-9522 StatsLogEventWrapper
CVE-2018-9523 Parcel.wnteMapInternal0
CVE-2021-0748 ParsingPackagelmpl
CVE-2021-0928 OutputConfiguration
CVE-2021-0685 ParsedIntentInfol
CVE-2021-0921 ParsingPackagelmpl
CVE-2021-0970 GpsNavigationMessage
CVE-2021-39676 AndroidFuture
CVE-2022-20135 GateKeeperResponse
…

另一个修复思路是修复 TOCTOU 漏洞本身，即确保检查和使用的反序列化对象是相同的，但这种修复方案也是治标不治本，同样可能会被攻击者找到其他的攻击路径并绕过。

因此，为了彻底解决这类层出不穷的问题，Google 提出了一种简单粗暴的缓释方案，即直接从 Bundle 类中下手。虽然 Bundle 本身是 ArrayMap 结构，但在反序列化时候即便只需要获取其中一个 key，也需要把整个 Bundle 反序列化一遍。这其中的主要原因在于序列化数据中每个元素的大小是不固定的，且由元素的类型决定，如果不解析完前面的所有数据，就不知道目标元素在什么地方。

为此在 21 年左右，AOSP 中针对 Bundle 提交了一个称为 LazyBundle(9ca6a5) 的 patch。其主要思想为针对一些长度不固定的自定义类型，比如 Parcelable、Serializable、List 等结构或容器，会在序列化时将对应数据的大小添加到头部。这样在反序列化时遇到这些类型的数据，可以仅通过检查头部去选择性跳过这些元素的解析，而此时 sMap 中对应元素的值会设置为 LazyValue，在实际用到这些值的时候再去对特定数据进行反序列化。

这个 patch 可以在一定程度上缓释针对 Bundle 风水的攻击，而且在提升系统健壮性也有所助益，因为即便对于损坏的 Parcel 数据，如果接收方没有使用到对应的字段，就可以避免异常的发生。对于之前的 Bundle 解析策略，哪怕只调用了 size 方法，也会触发所有元素的解析从而导致异常。在这个 patch 中 unparcel 还增加了一个 boolean 参数 itemwise，如果为 true 则按照传统方式解析每个元素，否则就会跳过 LazyValue 的解析。

CVE-2021-0928

在前面反序列化的示例中，漏洞主要出在一个自定义的 Vulnerable 类中，即手工编写的 readFromParcel/writeToParcel 不匹配问题。在现实中，这种出现问题的类通常只在进程间使用而几乎不用于跨进程，否则在正常 IPC 调用时候就会出现明显的数据错误。但也还有一种情况，比如在 readFromParcel 方法调用的过程中出现异常，但是上级进行了“优雅”的 try-catch，从而程序并不会报错，但异常发生后 Parcel 中还有剩余数据并未消费，因此会被后续的解析错误使用，比如在 AIDL 调用时候就会被后续的参数用到。

CVE-2021-0928 就是这么一个经典的漏洞。漏洞本身只存在于 Andorid 12 beta3 的短暂时间窗口中，因此我们并不需要太过于关注细节，此外漏洞的作者也已经在 Github 上公开了该漏洞的详细介绍以及 POC 代码。作为历史漏洞研究，笔者这里只做简单的介绍，并重点关注一些值得学习的漏洞利用思路和漏洞模式。完整的漏洞细节分析和 POC 可以参考原作者的分享:

CVE-2021-0928, writeToParcel/createFromParcel serialization mismatch in android.hardware.camera2.params.OutputConfiguration

漏洞介绍

主要出现漏洞的类为 android.hardware.camera2.params.OutputConfiguration，其代码片段如下所示:

package android.hardware.camera2.params;

public final class OutputConfiguration implements Parcelable {
    private OutputConfiguration(@NonNull Parcel source) {
        int rotation = source.readInt();
        int surfaceSetId = source.readInt();
        // ...
        boolean isMultiResolution = source.readInt() == 1; // New in Android 12
        ArrayList<Integer> sensorPixelModesUsed = new ArrayList<Integer>(); // New in Android 12
        source.readList(sensorPixelModesUsed, Integer.class.getClassLoader()); // New in Android 12
        // ...
    }

    public static final @android.annotation.NonNull Parcelable.Creator<OutputConfiguration> CREATOR =
            new Parcelable.Creator<OutputConfiguration>() {
        @Override
        public OutputConfiguration createFromParcel(Parcel source) {
            try {
                OutputConfiguration outputConfiguration = new OutputConfiguration(source);
                return outputConfiguration;
            } catch (Exception e) {
                Log.e(TAG, "Exception creating OutputConfiguration from parcel", e);
                return null;
            }
        }
    };
}

其中在 createFromParcel 中对构造函数进行了异常捕捉，但是对于异常仅仅是打印并返回，这导致 Parcel 数据残留从而影响后续的数据解析。

该漏洞本身并不复杂，是个很常见的 Parcel 序列化/反序列化不匹配问题，关键是这个漏洞如何利用？由于漏洞的本质是序列化数据残留，因此我们可以主要关注一些 AIDL 调用场景的参数，这样解析下一个参数时其内容也就会被我们所污染的数据控制。其中一个漏洞触发链路就是 sendBroadcast。

Android 广播

关于 Android 广播的发送和接收流程应该已经有很多其他博客介绍过了，这里将其简化为下面的阶段，假设广播由应用 A 发送给应用 B；

A 调用 sendBroadcast，这实际上是个 AIDL 接口，接收方即实际实现为 system_server；
system_server 接收到 Intent 后进行一系列处理，判断合法的接收方，然后调用 IApplicationThread.scheduleReceiver 发送广播数据；这同样是一个 AIDL 接口，由各个应用在启动之初通过 IActivityManager.attachApplication() 传递给 system_server；因此这个调用实际上会进入到应用 B 中；
B 触发 ActivityThread.handleMessage，进而调用 handleReceiver；
handleReceiver 中通过传来的数据去实例化应用上下文，获取对应的 receiver，最终调用开发者注册的 onReceive 回调；

第 2 步中 scheduleReceiver 的定义如下:

public final void scheduleReceiver(Intent intent, ActivityInfo info,
    CompatibilityInfo compatInfo, int resultCode, String data, Bundle extras,
    boolean sync, int sendingUser, int processState);

其中第一个 intent 是 A 应用指定的 sendBroadcast 的参数，第二个参数则是 system_server 传递给应用 B 的。漏洞利用思路就是通过 intent 参数的反序列化数据残留，间接地修改 info 参数，因为应用 B 会使用 ActivityInfo 中的数据去实例化代码，具体来说就是:

private void handleReceiver(ReceiverData data) {
    String component = data.intent.getComponent().getClassName();
    LoadedApk packageInfo = getPackageInfoNoCheck(
            data.info.applicationInfo, data.compatInfo);
    app = packageInfo.makeApplicationInner(false, mInstrumentation);
    // ...
}

应用会通过传入的 ActivityInfo 构造 LoadedApk，其中会使用内部的 zipPaths 创建 ClassLoader，攻击者如果可以控制这个字段，就能实现针对应用 B 的任意代码执行。

要实现这个目的，还有亿点细节需要解决，首先我们先来看一个 Java 语言的特性。

Java 类型擦除

Java 类型擦除也称为 Type Erasure，主要产生在 Java 的泛型代码中。Java 虚拟机中并没有泛型类型的概念，因此在编译时实际类型会被替换为其限制对象或者原始对象 Object 类型，这个过程就叫做类型擦除。

例如，下述代码:

public static <E> void printArray(E[] array) {
    for (E element : array) {
        System.out.printf("%s ", element);
    }
}

会在编译时变成:

public static void printArray(Object[] array) {
    for (Object element : array) {
        System.out.printf("%s ", element);
    }
}

即模版类型 E 变成了原始类型 Object。对于有限制类型的模版，比如:

public static <E extends Comparable<E>> void printArray(E[] array) {
    for (E element : array) {
        System.out.printf("%s ", element);
    }
}

会在编译时替换成其限制类型:

public static void printArray(Comparable[] array) {
    for (Comparable element : array) {
        System.out.printf("%s ", element);
    }
}

那么，这个特性对于漏洞的利用有什么帮助呢？回顾 OutputConfiguration 类，其中有个序列化的字段 sensorPixelModesUsed 是 ArrayList 类型，在反序列化该字段时，使用的是 Parcel.readList 方法，其调用链路是:

Parcel.readList
Parcel.readListInternal
Parcel.readValue

最终是使用 readValue 读取 List 中每个元素的值。因此实际上可以读出任何 readValue 支持的类型，比如 Parcelable、IBinder 等，并不局限于 Integer。

仅仅进行反序列化并不会出现任何问题，只不过在使用具体的元素时，如果我们实际读取的类型无法转换为整数，就会出现 ClassCastException 异常。在这个漏洞场景中，我们并不会使用这个数组的元素，因此我们可以指定任意的序列化类。又由于我们需要使目标类在序列化/反序列化过程产生不匹配，那么就需要找到一个类，使得该类可以在 system_server 中成功反序列化，但是在应用 B 中出现异常，比如 ClassNotFoundException。

原作者的利用是使用了 PackageManagerException，这是一个 Serializable 类而不是 Parcelable，因为 readSerializable/ObjectInputStream 不需要指定 ClassLoader。当然肯定还存在其他可用的类，感兴趣的可以自行发掘。

实际利用中由于读取使用了带 classLoader 的 readList，因此到 ObjectInputStream 时 latestUserDefinedLoader 会被影响，解决方案是将 Serializable 再套一层 Parcelable，使用不带 ClassLoader 的 readList 去进行恢复。这里选用的是 WindowContainerTransaction 类。

其他

上面只介绍了漏洞利用的大致流程，完整的利用还有一些细节需要注意，比如:

如何将任意 Parcelable 放到 Intent 中；
精细的内存布局；

对于问题 1，使用 putExtras(Bundle) 并不可行，因为在 Intent 中 Bundle 会作为一个整体进行拷贝，因此 Bundle 中的反序列化错误并不会影响 Intent 本身。作者是用了一个在 Android 12 中加入的 Intent.ClipData 字段去实现的，不过目前已经修复了就不再展开了。

对于问题 2，有几个关键点需要注意。一是在触发异常后，并没有直接跳到第二个参数，而是会继续上级(解析了一半的)容器处理，因此后续 payload 需要维持这部分数据的栈平衡；另外一个问题是在 Andorid 中新增了许多隐藏 API 的限制，使得我们无法通过调用这些方法去构造 ActivityInfo 等数据，这个解决方法是参考源码直接通过 Parcel 去写入数据，只是过程繁琐了一点，当然也可以用其他方式去绕过 Hidden API 的限制。

漏洞修复

这个漏洞本身对终端用户的影响不是很大，毕竟只在 Android 12 Preview 版本中就修复了。但通过这个漏洞，Google 引入了许多修复和缓释方案，直接影响了后续的漏洞挖掘和利用思路。

首先针对漏洞本身，修复方案为:

对上述类去除隐式的异常处理，修复读写不一致的问题；
使用 readIntArray 而不是 readList/readValue 去读取数据，消灭类型擦除的副作用；
防止 ClipData.mActivityInfo 写入 Parcel，除非显式指定。这消除了向 Intent 写入任意 Parcelable 的一个攻击链路；

另外，在 Andorid 13 中，引入了更强的反序列化缓释方案:

新增了一个 readListInternal 方法的重载，增加额外的 Class 参数，显式指定读取列表的元素的类型，并且将原来的方法标记为 @Deprecated；
新增了 Parcel.enforceNoDataAvail 方法，用于确保反序列化结束后，Parcel 中不再存在多余的数据；回想上一节中 Bundle 风水的利用，实际上第三个元素在第二次反序列化中是多出来的，因此这个修改会导致上述 Bundle 风水的失败；当然也有一些绕过的手法，比如通过更复杂的风水使得第二次反序列化能够到 Parcel 的末尾即可；
即上文说过的 LazyBundle patch，在 LazyBundle 实现中，Parcelable、List 等类型会在序列化数据的元素开头单独存储长度信息。不过，这个 patch 并不会影响非 Bundle 造成的反序列化漏洞，比如这个漏洞。

LeakValue

时间来到 2022 年，Google 推出了 Android 13，在其中正式启用了 LazyBundle 的 patch。我们在前面 Bundle 风水中已经简要介绍过大致原理，这里再深入去分析其实现。

深入 LazyValue

由于 LazyValue 是在使用时才进行反序列化的，因此在读取值时，需要预先知道它在 Parcel 中所占的数据区间，读取后还需要修改 Parcel 结构中对应的偏移。这也是为什么 LazyValue 需要在序列化数据中写入其数据长度的原因，因为对于这类数据(如 Parcelable)，无法仅通过类型得知其数据长度。

读取 LazyValue 的代码实现如下所示:

public Object readLazyValue(@Nullable ClassLoader loader) {
    int start = dataPosition();
    int type = readInt();
    if (isLengthPrefixed(type)) {
        int objectLength = readInt();
        if (objectLength < 0) {
            return null;
        }
        int end = MathUtils.addOrThrow(dataPosition(), objectLength);
        int valueLength = end - start;
        setDataPosition(end);
        return new LazyValue(this, start, valueLength, type, loader);
    } else {
        return readValue(type, loader, /* clazz */ null);
    }
}

这里面有几个关键点。首先，LazyValue 中存储的是 Parcel 的引用，以及其在 Parcel 中所占的数据区间，使用其内部属性 mPosition、mLength 表示，mPostion 对应上述代码中的 start，mLength 对应 valueLength。其中 valueLength 是添加到序列化数据头部的长度字段，包括长度和类型所占的空间。

其次，在 Parcel 中构造 LazyValue 之后，会将 dataPostion 设置到对象对应序列化数据的尾部。在需要实际数据时，会调用 LazyValue.apply 方法进行真正的反序列化，如下所示:

@Override
public Object apply(@Nullable Class clazz, @Nullable Class[] itemTypes) {
    Parcel source = mSource;
    if (source != null) {
        synchronized (source) {
            // Check mSource != null guarantees callers won't ever see different objects.
            if (mSource != null) {
                int restore = source.dataPosition();
                try {
                    source.setDataPosition(mPosition);
                    mObject = source.readValue(mLoader, clazz, itemTypes);
                } finally {
                    source.setDataPosition(restore);
                }
                mSource = null;
            }
        }
    }
    return mObject;
}

可以看到在反序列化时候会将原始 Parcel 的 dataPostion 保存，并设置指向到 LazyValue 中的位置，然后调用 readValue 去进行反序列化，完成后再次恢复 Parcel 调用前的 dataPostion。

这可能会涉及到一些安全问题，比如多线程之间的条件竞争，在修改 dataPostion 之后被其他线程使用，当然这通过 synchronized 同步块防御住了。另一个问题是，在 LazyValue 未使用之前，其所对应的 Parcel 是不能被释放的，否则就会出现类似 UAF 的内存问题。考虑到对于 Parcel 的内存分配策略而言，大多数是使用手工管理的 obtain/recycle 方式，这个问题是有可能存在的。

Parcel 内存管理

由于 Parcel 本身是为了频繁的 IPC 传输而设计的，因此对于其分配和释放通常使用手工管理的方式，以避免 Java 堆分配或者 GC 带来的性能损耗。在阅读系统源码或者 AIDL 生成的模版代码时都能发现，Parcel 使用 obtain 进行分配，使用 recycle 进行释放。

分配的代码实现如下:

public static Parcel obtain() {
    Parcel res = null;
    synchronized (sPoolSync) {
        if (sOwnedPool != null) {
            res = sOwnedPool;
            sOwnedPool = res.mPoolNext;
            res.mPoolNext = null;
            sOwnedPoolSize--;
        }
    }
    if (res == null) {
        res = new Parcel(0);
    } else {
        res.mRecycled = false;
        res.mReadWriteHelper = ReadWriteHelper.DEFAULT;
    }
    return res;
}

其中 sOwnedPool 是静态属性，mPoolNext 是成员属性，二者都是 Parcel 类型。因此内存池中的 Parcel 可以看做是一个表头为 sOwnedPool 的单链表结构。obtain 本质上是从链表中取出表头的数据。

对于 IPC 接收到的 Parcel 数据分配方式略有不同，因为这些 Parcel 在 C++ 层由系统创建，因此使用不同的链表，表头为 sHolderPool 静态属性。这些 Parcel 通过构造函数 Parcel(long nativePtr) 去构建，生命周期由系统管理(mOwnsNativeParcelObject 为 false)，因此需要区分开来。这类 Parcel 的分配通过重载的 obtain(long) 方法去创建，与上述实现大同小异。

在释放过程会将这两种情况区分开来:

public final void recycle() {
    if (mRecycled) {
        Log.wtf(TAG, "Recycle called on unowned Parcel. (recycle twice?) Here: "
                + Log.getStackTraceString(new Throwable())
                + " Original recycle call (if DEBUG_RECYCLE): ", mStack);

        return;
    }
    mRecycled = true;

    // We try to reset the entire object here, but in order to be
    // able to print a stack when a Parcel is recycled twice, that
    // is cleared in obtain instead.

    mClassCookies = null;
    freeBuffer();

    if (mOwnsNativeParcelObject) {
        synchronized (sPoolSync) {
            if (sOwnedPoolSize < POOL_SIZE) {
                mPoolNext = sOwnedPool;
                sOwnedPool = this;
                sOwnedPoolSize++;
            }
        }
    } else {
        mNativePtr = 0;
        synchronized (sPoolSync) {
            if (sHolderPoolSize < POOL_SIZE) {
                mPoolNext = sHolderPool;
                sHolderPool = this;
                sHolderPoolSize++;
            }
        }
    }
}

释放操作相当于单链表的插入，即将释放的 Parcel 放入 sOwnPool/sHolderPool 链表的头部。从上述代码可以看出，Parcel 的分配和释放过程是后进先出(LIFO)的，即 Parcel obtain 会分配出最近一次释放的对象。

Parcel UAF

通过 LazyValue 的实现以及 Parcel 内存管理的策略，我们似乎可以找到一个攻击场景: 在 Parcel 读取 LazyValue 之后，将 Parcel 进行释放，而后再读取对应的 LazyValue，此时如果 Parcel 被分配并填充了敏感数据，那么我们的 LazyValue 就可以读取出这些敏感内容造成数据泄露。如果泄露的数据来自其他进程，且数据中包含特权的 IBinder 等结构，那么还可能造成提权或者 RCE 的危害！

为此，我们首先需要找到一个 recycle 后再次使用 LazyValue 的场景。接下来，就是漏洞上场的时间了，出现上述问题的漏洞编号是 CVE-2022-20452，其 patch 代码为:

diff --git a/core/java/android/os/BaseBundle.java b/core/java/android/os/BaseBundle.java
index 0418a4b..b599028 100644
--- a/core/java/android/os/BaseBundle.java
+++ b/core/java/android/os/BaseBundle.java
@@ -438,8 +438,11 @@
             map.ensureCapacity(count);
         }
         try {
+            // recycleParcel being false implies that we do not own the parcel. In this case, do
+            // not use lazy values to be safe, as the parcel could be recycled outside of our
+            // control.
             recycleParcel &= parcelledData.readArrayMap(map, count, !parcelledByNative,
-                    /* lazy */ true, mClassLoader);
+                    /* lazy */ recycleParcel, mClassLoader);
         } catch (BadParcelableException e) {
             if (sShouldDefuse) {
                 Log.w(TAG, "Failed to parse Bundle, but defusing quietly", e);
@@ -1845,7 +1848,6 @@
             // bundle immediately; neither of which is obvious.
             synchronized (this) {
                 initializeFromParcelLocked(parcel, /*recycleParcel=*/ false, isNativeBundle);
-                unparcel(/* itemwise */ true);
             }
             return;
         }

问题还是出现在 Bundle 反序列化的过程中，之前说过 Bundle 通过 readFromParcelInner 去进行反序列化，其实现如下:

private void readFromParcelInner(Parcel parcel, int length) {
    final int magic = parcel.readInt();
    final boolean isJavaBundle = magic == BUNDLE_MAGIC;
    final boolean isNativeBundle = magic == BUNDLE_MAGIC_NATIVE;
    if (!isJavaBundle && !isNativeBundle) {
        throw new IllegalStateException("Bad magic number for Bundle: 0x"
                + Integer.toHexString(magic));
    }

    if (parcel.hasReadWriteHelper()) {
        // If the parcel has a read-write helper, it's better to deserialize immediately
        // otherwise the helper would have to either maintain valid state long after the bundle
        // had been constructed with parcel or to make sure they trigger deserialization of the
        // bundle immediately; neither of which is obvious.
        synchronized (this) {
            initializeFromParcelLocked(parcel, /*recycleParcel=*/ false, isNativeBundle);
            unparcel(/* itemwise */ true);
        }
        return;
    }
    // 直接使用 Parcel.appendFrom 拷贝原 Parcel 的数据
    Parcel p = Parcel.obtain();
    p.appendFrom(parcel, offset, length);
    mParcelledData = p;

注意 if 分支外部，这是大部分 Bundle 反序列化的流程，即通过新分配一个 parcel 去拷贝原始数据并保存到 mParcelledData 中。因为开发者知道 parcel 参数的生命周期不由自身控制。

而在 if 内部，调用了 initializeFromParcelLocked，其中会使用 readArrayMap 对 parcel 数据进行反序列化，这其中是带有 LazyValue 的。由于开发者知道 parcel 生命周期不可控，因此在后续调用了 unparcel(true) 去强制对每个 LazyValue 进行反序列化以去除对 parcel 数据的依赖。

如果 unparcel 内部某些 LazyValue 能够被攻击者绕过解析，那么这里就存在一个 UAF 漏洞，后续读取 LazyValue 时就能泄露出复用的 Parcel 中的数据。当然，要触发这个漏洞需要有几个前提:

hasReadWriteHelper 返回 true；
unparcel 能被绕过；

对于问题 1，我们可以在 AOSP 代码中搜索符合条件的 Parcel 类，比如 RemoteViews；

对于问题 2，我们可以尝试使其中某个 LazyValue 解析失败，比如 Parcelable 的类不存在时，代码会抛出 ClassNotFoundException，被捕捉后再次抛出 BadParcelableException。有趣的是这个异常会在 getValueAt 中被捕捉，如下所示:

@Nullable
final <T> T getValueAt(int i, @Nullable Class<T> clazz, @Nullable Class... itemTypes) {
    Object object = mMap.valueAt(i);
    if (object instanceof BiFunction, ?, ?>) {
        try {
            object = ((BiFunction<Class, Class[], ?>) object).apply(clazz, itemTypes);
        } catch (BadParcelableException e) {
            if (sShouldDefuse) {
                Log.w(TAG, "Failed to parse item " + mMap.keyAt(i) + ", returning null.", e);
                return null;
            } else {
                throw e;
            }
        }
        mMap.setValueAt(i, object);
    }
    return (clazz != null) ? clazz.cast(object) : (T) object;
}

如果 sShouldDefuse 为 true，那么异常不会被再次抛出，而只是打印异常并返回 null。对于 system_server 而言该条件是满足的，因为其目的就是为了防止系统重要服务频繁崩溃。因此，我们可以将 Bundle 的某个值设置为另外一个容器，比如 List，然后在容器中存储一个不存在的 Parcelable，那么 List 中后续的 LazyValue 将不会被递归解析到，我们也就获得了一个 UAF 对象。

漏洞利用

该漏洞的利用过程比较曲折，由于漏洞已经修复，因此笔者对于复现的兴趣缺缺。此外原作者也公开了详细利用思路和漏洞利用代码，感兴趣的可以自行参考:

Exploit for CVE-2022-20452, privilege escalation on Android from installed app to system app (or another app) via LazyValue using Parcel after recycle()

这里提炼一下其中值得学习的点:

UAF 漏洞的核心利用目标是获取目标应用的 IApplicationThread 句柄，这通常是应用启动初期使用 attachApplication() 传递给 system_server 的，主要用于让后者给应用发送四大组件的生命周期回调。通过滥用这个 Binder 句柄可以实现 RCE，参考前面的 CVE-2021-0928 (scheduleReceiver)；
为了能从 system_server 中泄露任意应用的 IApplicationThread 句柄，需要两个条件。首先是有一个接口可以发送 Parcelable 数据并将其取回，AppWidgetHost、Notification.contentView、Mediasession 都可以满足，作者选用的是 MediaSession.get/setQueue 接口；
其次，要使得 UAF 对象能被包含 IApplicationThread 的 Parcel 复用，需要准确的时机。但是 attachApplication 只在应用启动时一个很小的时间窗口中被调用，因此作者寻找其中可能存在的锁去拓展这个窗口；
ParceledListSlice 是一个在 IPC 间传输的特殊数据结构，在其数据量小时可以同步传输，而对于大量的数据，会将其转换为 binder 发送给对方然后进行异步传输；
ActivityManager.moveTaskToFront() 调用时可以提供 ActivityOptions 参数，以 Bundle 形式进行封装，并在 system_server 端进行反序列化。因此攻击者可以在 Bundle 中加入 ParceledListSlice 类型的数据，从而在反序列化时回调到自身进行阻塞。该函数调用时候持有 mGlobalLock 锁，因此可以阻塞 attachApplication 的执行，从而更好地构造 UAF 风水；
由于调用了 moveTaskToFront，种种原因导致无法使用 startActivity 来启动目标应用，因此作者使用 ContentProvider 来启动目标应用。
在我们的 UAF LazyValue Parcel 被成功占位后，对应的 IApplicationThread 实际上在比较靠前的位置，但我们的 LazyValue 所在位置比较靠后因此无法读取到对应 binder。解决方案是可以找其他占位对象，不过作者这里利用了一个新的漏洞 CVE-2022-20474，即 readLazyValue 方法中 objectLenth 只检查了证书溢出，却没检查负数的情况，因此设置负数的 prefixLength 实际上可以读取 Parcel 前方的数据，从而绕过该限制。

其他还有亿点细节，就需要动手复现才能真正理解了。理论上该漏洞可以影响安全补丁在 2022-11 之前的 Android 13 设备。攻击的目标应用可以是任意应用，因此可以选择 Settings.apk，其 UID=system，攻击成功后就相当于获取到了 system 权限。这在 Goole VRP 中应该是 10 万刀乐的标准。

总结

本文算是笔者学习 Android 反序列化漏洞的一个笔记，按照时间线记录了几个公开的经典反序列化漏洞，并且介绍相关的修复策略以及绕过方法。从中我们可以看到，Parcel 作为轻量级的序列化方案，许多操作都需要手动管理，这导致了许多读写不匹配的问题，虽然后续引进了 LazyBundle 优化，但又引发了新的内存管理问题，使得传统二进制的 UAF 甚至 Double Free 类漏洞可以在 Java 世界重现。

漏洞本身只是一个引子，指导我们未来的研究方向。从这些漏洞中，我们也可以发现 Security By Default 的重要性，比如序列化 Java 容器导致的类型擦除问题和 Bundle 的序列化问题。在后期虽然尝试进行了缓释，但由于历史负担，很多不安全的设计只能缝缝补补延续下去，这也是后续挖掘和审计其他产品漏洞的一个重要着手点。

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/02/18/parcel-bugs/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

iptables 在 Android 抓包中的妙用

Mon, 30 Jan 2023 12:40:00 +0800

本文介绍一种在 Andorid 中实现单应用、全局、优雅的抓包方法。

此文于去年端午节编写，由于种种原因，当时藏拙并未发布。现删除一些敏感信息后分享出来，希望对各位有所启发。

背景

昨天在测试一个 Android APK 的时候发现使用 WiFi 的 HTTP 代理无法抓到包，在代理的日志中没有发现任何 SSL Alert，因此可以判断不是证书问题；另外 APP 本身仍可以正常收发数据，这说明代理设置被应用绕过了。

根据我们前一篇文章(终端应用安全之网络流量分析)中所介绍的，遇到这种情况时就可以使用路由抓包方法，确保接管所有流量。但是因为端午放假被封印在家，且用于抓包的树莓派放在了公司，因此只有另谋他路。

本来接着考虑装个 DroidProxy 去试一下，但突然间灵光一闪，为什么不直接用 iptables 去修改流量呢？于是，就有了这篇小记。

iptables 101

iptables 应该大家都不会陌生，说起来这也是我入门 “黑客” 时就接触的命令，因为我的网络安全入门第一战就是使用 aircrack 去破解邻居的 WiFi 密码。多年以前还写过一篇Linux内核转发技术，介绍 iptables 的常用操作，但当时年幼无知，很多概念自己并没有完全理解。其实介绍 iptables 最好的资料就是官方的 man-pages，因此这里也就不做一个无情的翻译机器人了，只简单介绍一些关键的概念。

basic

首先是我们作为系统管理员最为关心的命令行参数，在坊间流传的各类防火墙、WiFi 热点、流控 shell 脚本中，充斥着各种混乱而难以理解的 iptables 命令，但实际上其命令行参数非常优雅，可以概况为以下表述:

iptables [-t table] {-A|-C|-D} chain rule-specification

rule-specification = [matches...] [target]
match = -m matchname [per-match-options]
target = -j targetname [per-target-options]

一个 table 中有多个 chain，除了内置的 chain，用户也可以自己新建(比如 DOCKER 链)。常用的 table 及其包含的 chain 有以下这些:

filter
- INPUT
- FORWARD
- OUTPUT
nat
- PREROUTING
- INPUT
- OUTPUT
- POSTROUTING
mangle
- PREROUTING
- OUTPUT
- INPUT
- FORWARD
- POSTROUTING
raw
- PREROUTING
- OUTPUT

其中有的表比其他表包含更多的 chain，这是其定位决定的。正如其名字而言，filter 主要用于流量过滤，nat 表主要用于网络地址转换，mangle 表用于数据包修改，而 raw 表则用于网络包更早期的配置。除此之外还有 security 表用于权限控制，不过用得不多。

虽然看起来各个表各司其职，但实际中也没有强制的差异。比如 mangle 表虽然用来修改流量，但也可以用来做网络地址转换，filter 表也是同理。在日常中设置 iptables 规则的时候主要考虑的是数据包的时序，而这和 chain 的关系更大一些。

上面提到的这些常见 chain，不管在哪个表中，其含义都是类似的:

INPUT: 表示数据包从远端发送到本地；
OUTPUT: 表示数据包在本地生成，并准备发送到远端；
PREROUTING: 接收到数据包的第一时间，在内核进行路由之前；
POSTROUTNG: 表示数据包准备离开的前一刻；
FOWARD: 本机作为路由时正要准备转发的时刻；

table 结合对应的 chain，网络数据包在 iptables 中的移动路径如下图所示:

Iptables packet flow - from rakhesh.com

extensions

对于 iptables 而言重点无疑是其中的规则定义，上文提到的参数无非就是将自定义的规则加入到对应 CHAIN 之中，比如 -A 是将规则插入到链的末尾(append)，-I 是插入到链的头部(insert)，-D 是删除对应规则(delete)，等等。

而规则又分为两个部分，即数据包匹配以及匹配之后的操作，分别通过 -m 和 -j 来指定。这其中就引入了成百的命令行参数，以至于社区还就此产生了不少段子:

Overheard: “In any team you need a tank, a healer, a damage dealer, someone with crowd control abilities and another one who knows iptables”

— Jérome Petazzoni (@jpetazzo) June 27, 2015

不过实际上社区对 iptables 的抱怨更多是在多用户系统中规则配置冲突以及由此引发的艰难调试之旅，在没有冲突的情况下，配置规则也是比较简单的。定义 iptables 规则的参考主要是 iptables-extensions(8)，其中定义了一系列 匹配拓展(MATCH EXTENSIONS) 以及 目标拓展(TARGET EXTENSIONS)。

match

先看匹配拓展，一般我们使用 iptables 都是根据 ip 或者端口进行匹配，比如 -m tcp --dport 22。但其中也有一些比较有趣的匹配规则，比如上一篇文章中介绍过的 Android 单应用抓包方法:

$ iptables -A OUTPUT -m owner --uid-owner 1000 -j CONNMARK --set-mark 1
$ iptables -A INPUT -m connmark --mark 1 -j NFLOG --nflog-group 30 
$ iptables -A OUTPUT -m connmark --mark 1 -j NFLOG --nflog-group 30 
$ dumpcap -i nflog:30 -w uid-1000.pcap

用到了两个匹配拓展，一个是 owner 拓展，使用 --uid-owner 参数表示创建当前数据包的应用 UID。但是这样只能抓到外发的包，而服务器返回的包由于并不是本地进程创建的，因此没有对应的 UID 信息，因此 owner 拓展只能应用于 OUTPUT 或者 POSTROUTING 链上。为了解决这个问题，上面使用了另一个拓展 connmark，用来匹配 tcp 连接的标志，这个标志是在第一条命令中的外发数据中进行设置的。

还有个值得一提的匹配拓展是 bpf，支持两个参数，可以使用 --object-pinned 直接加载编译后的 eBPF 代码，也可以通过 --bytecode 直接指定字节码。直接指定的字节码格式类似于 tcpdump -ddd 的输出结果，第一条是总指令数目。

例如以下 bpf 指令 (ip proto 6):

4               # number of instructions
48 0 0 9        # load byte  ip->proto
21 0 1 6        # jump equal IPPROTO_TCP
6 0 0 1         # return     pass (non-zero)
6 0 0 0         # return     fail (zero)

实际调用时候需用用逗号分隔每条指令，且不支持注释等其他符号:

iptables -A OUTPUT -m bpf --bytecode '4,48 0 0 9,21 0 1 6,6 0 0 1,6 0 0 0' -j ACCEPT

对于其他遇到的匹配拓展，可以在官方文档中查看其详细用法。

target

target 表示数据包匹配之后要执行的操作，一般使用大写表示。标准操作有 ACCEPT/DROP/RETURN 这三个，其他都定义在 target extensions 即目标拓展中。

比如我们前面提到的 CONNMARK 就是其中一个拓展，其作用是对当前链接进行打标，这样 TCP 请求的返回数据也会带上我们的标记。类似的还有 MARK 拓展，表示对当前数据包设置标志，主要用于后续 table/chain 的识别。

前面用到的另一个拓展是 NFLOG，表示 netfilter logging，规则匹配后内核会将其使用对应的日志后端进行保存，通常与 nfnetlink_log 一起使用，通过多播的方式将获取到的数据包发送到 netlink 套接字中，从而可以让用户态的抓包程序获取并进行进一步分析。

其他常用的拓展还有 SNAT/DNAT 用于修改数据包的源地址和目的地址，LOG 可以使内核 dmesg 打印匹配的数据包信息，TRACE 可以使内核打印规则信息用于调试分析等。

Android Proxy

复习完 iptables 的基础后，我们继续回到文章开头的问题，有什么办法可以在不设置代理的基础上代理所有流量呢？

这个问题可以从两方面去考虑，即:

如何匹配目标数据包；
匹配之后如何转发到代理地址；

第一个问题比较简单，我们需要匹配从本地发出的，目的端口是 80/443 的 tcp 流量，因此匹配规则可以写为:

-p tcp -m tcp --dport 443

在不确定目标 web 服务器端口的情况下，可以将 dport 指定为 0:65535，对所有端口都进行劫持转发；当然也可以直接不写 match，默认就是匹配所有 tcp 包。不过可以稍微过滤一下目的地址，比如 ! -d 127.0.0.1，以免本地的 RPC 请求也被误拦截。

或者，更优雅的方案是使用 multiport 来一次性指定多个端口:

-m multiport --dports 80,443

第二个问题，既然我们需要将流量转发到代理工具，那么可以选择透明代理模式，上篇文章也有提到过。因此一个最简单的方法是使用 DNAT 修改目的地址。查阅文档可知，DNAT 只能用在 nat 表中的 PREROUTING 和 OUTPUT 链。再根据上文中的流程图，如果代理地址在本地，那只能使用 OUTPUT、如果是远程地址，那么两个链任选一个即可。

综上所述，假设 HTTP 透明代理监听在 127.0.0.1:8080，那么可以直接用以下方法设置代理并进行抓包:

iptables -t nat -A OUTPUT -p tcp ! -d 127.0.0.1 -m multiport --dports 80,443 -j DNAT --to-destination 127.0.0.1:8080

更进一步

通过这么一条 iptables 命令，配合上透明代理就可以实现全局的 HTTPS 抓包了。所以就这样了吗？回忆一下之前我们其实是可以通过 owner target 去进行 UID 匹配的，只不过之前是使用 NFLOG 配合 tcpdump 进行抓包。因此我们其实也可以通过类似的方式实现基于 UID 的透明代理。

转发规则并没有太大变化，只需要在匹配规则上新增一个约束。

iptables -t nat -A OUTPUT -p tcp ! -d 127.0.0.1 -m owner --uid-owner 2000 -m multiport --dports 80,443 -j DNAT --to-destination 127.0.0.1:8080

这样，不需要额外的路由抓包设备，甚至不需要引入 VPN Service 等其他应用，只需要一行命令即可实现针对单个 Android 应用的全局 HTTP/HTTPS 抓包。

总结

本文主要介绍了 iptables 规则的配置方法，并且实现了一种在 Android 中全局 HTTP(S) 抓包的方案，同时借助 owner 拓展实现应用维度的进一步过滤，从而避免手机中其他应用的干扰。

相比于传统的 HTTP 代理抓包方案，该方法的优势是可以实现全局抓包，应用无法通过禁用代理等方法绕过；而相比于 Wireshark 等抓包方案，该方法基于透明代理，因此可以使用 BurpSuite、MITMProxy 等成熟的 HTTP/HTTPS 网络分析工具来对流量进行快速的可视化、拦截/重放，以及脚本分析等操作，这些优势是传统抓包方案所无法比拟的。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/01/30/android-iptables/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Android 组件逻辑漏洞漫谈

Sun, 13 Nov 2022 17:40:00 +0800

随着社会越来越重视安全性，各种防御性编程或者漏洞缓解措施逐渐被加到了操作系统中，比如代码签名、指针签名、地址随机化、隔离堆等等，许多常见的内存破坏漏洞在这些缓解措施之下往往很难进行稳定的利用。因此，攻击者们的目光也逐渐更多地投入到逻辑漏洞上。逻辑漏洞通常具有很好的稳定性，不用受到风水的影响；但同时也隐藏得较深、混迹在大量业务代码中难以发现。而且由于形式各异，不太具有通用性，从投入产出比的角度来看可能不是一个高优先级的研究方向。但无论如何，这都始终是一个值得关注的攻击面。因此，本文就以 Android 平台为目标介绍一些常见的逻辑漏洞。

四大组件

接触过 Android 的人应该都听说过 “四大组件”，开发应用首先需要学习的就是各个组件的生命周期。所谓四大组件，分别是指 Activity、Service、Broadcast Receiver 和 Content Provider，关于这些组件的实现细节可以参考官方的文档: Application Fundamentals。

在安全研究中，四大组件值得我们特别关注，因为这是应用与外界沟通的重要桥梁，甚至在应用内部也是通过这些组件构建起了相互间松耦合的联系。比如应用本身可以不申请相机权限，但可以通过组件间的相互通信让（系统）相机应用打开摄像头并取得拍到的照片，仿佛是自身进行拍照的一样。

而在组件交互的过程中，最为核心的数据结构就是 Intent，这是大部分组件之间进行通信的载体。

Intent 101

根据官方的说法，Intent 是 “对某种要执行的操作的抽象描述”，直译过来也可以叫做 “意图”，比如说想要打开摄像机拍照、想要打开浏览器访问网址，想要打开设置界面，……都可以用 Intent 来描述。

Intent 的主要形式有两种，分别是显式 Intent 和隐式 Intent；二者的差别主要在于前者显式指定了 Component，后者没有指定 Component，但是会通过足够的信息去帮助系统去理解意图，比如 ACTION、CATAGORY 等。

Intent 的最主要功能是用来启动 Activity，因此我们以这个场景为例，从源码中分析一下 Intent 的具体实现。启动 Activity 的常规代码片段如下：

Intent intent = new Intent(context, SomeActivity.class);
startActivity(intent);

这里用的是显式 Intent，但不是重点。一般在某个 Activity 中调用，因此调用的是 Activity.startActivity，代码在 frameworks/base/core/java/android/app/Activity.java 中，这里不复制粘贴了，总而言之调用链路如下：

Activity.startActivity()
Activity.startActivityForResult()
Instrumentation.execStartActivity()
ActivityTaskManager.getService().startActivity()
IActivityTaskManager.startActivity()

最后一条调用是个接口，这是个很常见的 pattern 了，下一步应该去找其实现，不出意外的话这个实现应该在另一个进程中。事实上也正是在 system_server 中：

ActivityTaskManagerService.startActivity()
ActivityTaskManagerService.startActivityAsUser()
ActivityStarter.execute()

最后一个方法通过前面传入的信息去准备启动 Activity，包括 caller、userId、flags，callingPackage 以及最重要的 intent 信息，如下：

private int startActivityAsUser(...) {
    // ...
    return getActivityStartController()
            .obtainStarter(
                intent, "startActivityAsUser")
            .setCaller(caller)
            .setCallingPackage(callingPackage)
            .setCallingFeatureId(callingFeatureId)
            .setResolvedType(resolvedType)
            .setResultTo(resultTo)
            .setResultWho(resultWho)
            .setRequestCode(requestCode)
            .setStartFlags(startFlags)
            .setProfilerInfo(profilerInfo)
            .setActivityOptions(bOptions)
            .setUserId(userId)
            .execute();
}

ActivityStarter.execute() 主要的逻辑如下:

int execute() {
    // ...
    if (mRequest.activityInfo == null) {
        mRequest.resolveActivity(mSupervisor);
    }
    res = resolveToHeavyWeightSwitcherIfNeeded();
    res = executeRequest(mRequest);

}

其中，resolveActivity 用于获取要启动的 Activity 信息，例如在隐式启动的情况下，可能有多个符合要求的目标，也会弹出菜单询问用户选用哪个应用打开。executeRequest 中则主要进行相关权限检查，在所有权限满足条件后再调用 startActivityUnchecked 去执行真正的调用。

其中大部分流程我在 Android12 应用启动流程分析中已经介绍过了，这里更多是关注 Intent 本身的作用。从上面的分析中发现，可以将其看作是多进程通信中的消息载体，而其源码定义也能看出 Intent 本身是可以可以序列化并在进程间传递的结构。

public class Intent implements Parcelable, Cloneable { ... }

Intent 本身有很多方法和属性，这里暂时先不展开，后面介绍具体漏洞的时候再进行针对性的分析。后文主要以四大组件为着手点，分别介绍一些常见的漏洞模式和设计陷阱。

Activity

Activity 也称为活动窗口，是与用户直接交互的图形界面。APP 主要开发工作之一就是设计各个 activity，并规划他们之间的跳转和连结。通常一个 activity 表示一个全屏的活动窗口，但也可以有其他的存在形式，比如浮动窗口、多窗口等。作为 UI 窗口，一般使用 XML 文件进行布局，并继承 Activity 类实现其生命周期函数 onCreate 和 onPause 等生命周期方法。

如果开发者定义的 Activity 想通过 Context.startActivity 启动的话，就必须将其声明到 APP 的 manifest 文件中，即 AndroidManifest.xml。应用被安装时，PackageManager 会解析其 manifest 文件中的相关信息并将其注册到系统中，以便在 resolve 时进行搜索。

在 adb shell 中可以通过 am start-activity 去打开指定的 Activity，通过指定 Intent 去进行启动：

am start-activity [-D] [-N] [-W] [-P ] [--start-profiler ]
        [--sampling INTERVAL] [--streaming] [-R COUNT] [-S]
        [--track-allocation] [--user  | current]

作为用户界面的载体，Activity 承载了许多用户输入/处理、以及外部数据接收/展示等工作，因此是应用对外的一个主要攻击面。下面就介绍几种较为常见的攻击场景。

生命周期

Activity 经典的生命周期图示如下：

通常开发者只需要实现 onCreate 方法，但是对于一些复杂的业务场景，正确理解其生命周期也是很必要的。以笔者在内测中遇到的某应用为例，其中某个 Activity 中执行了一些敏感的操作，比如开启摄像头推流，或者开启了录音，但只在 onDestroy 中进行了推流/录音的关闭。这样会导致在 APP 进入后台时候，这些操作依然在后台运行，攻击者可以构造任务栈使得受害者在面对恶意应用的钓鱼界面时候仍然执行目标应用的后台功能，从而形成特殊的钓鱼场景。正确的做法应该是在 onPaused 回调中对敏感操作进行关闭。

攻击者实际可以通过连续发送不同的 Intent 去精确控制目标 Activity 生命周期回调函数的触发时机，如果开发时没有注意也会造成应用功能的状态机异常甚至是安全问题。

Implicit Exported

前面说过，开发者定义的 Activity 要想使用 startActivity 去启动，就必须在 AndroidManifest.xml 中使用进行声明，一个声明的示例如下：

 xmlns:android="http://schemas.android.com/apk/res/android" android:theme="@android:01030055" android:name="com.evilpan.RouterActivity">
  
     android:name="android.intent.action.VIEW"/>
     android:name="android.intent.category.DEFAULT"/>
     android:name="android.intent.category.BROWSABLE"/>
     android:scheme="demo" android:host="router"/>

activity 中支持许多属性。其中一个重要的属性就是 android:exported，表示当前 Activity 是否可以被其他应用的组件启动。该属性有几个特点：

属性可以缺省，缺省值默认为 false；
如果 Activity 没有显式设置该属性，且该 Activity 中定义了，那么缺省值就默认为 true；

也就是说，开发者可能没有显式指定 Activity 导出，但由于指定了 intent-filter，因此实际上也是导出的，即可以被其他应用唤起对应的 Activity。这种情况在早期很常见，比如 APP 设计了一组更换密码的界面，需要先输入旧密码然后再跳转到输入新密码的界面，如果后者是导出的，攻击者就可以直接唤起输入新密码的界面，从而绕过了旧密码的校验逻辑。

Google 已经深刻意识到了这个问题，因此规定在 Android 12 之后，如果应用的 Activity 中包含 intent-filter，就必须要显式指定 android:exported 为 true 或者 false，不允许缺省。在 Android 12 中未显式指定 exported 属性且带有 intent-filter 的 Activity 的应用在安装时候会直接被 PackageManager 拒绝。

Fragment Injection

Activity 作为 UI 核心组件，同时也支持模块化的开发，比如在同一个界面中展示若干个可复用的子界面。随着这种设计思路诞生的就是 Fragments 组件，即 “片段”。使用 FragmentActivity 可以在一个 Activity 中组合一个或者多个片段，方便进行代码复用，片段的生命周期受到宿主 Activity 的影响。

Fragment Injection 漏洞最早在 2013 年爆出，这里只介绍其原理，本节末尾附有原始的文章以及论文。漏洞的核心是系统提供的 PreferenceActivity 类，开发者可以对其进行继承实现方便的设置功能，该类的 onCreate 函数有下面的功能：

protected void onCreate() {
    // ...
    String initialFragment = getIntent().getStringExtra(EXTRA_SHOW_FRAGMENT);
    Bundle initialArguments = getIntent().getBundleExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS);
    // ...
    if (initialFragment != null) {
        switchToHeader(initialFragment, initialArguments);
    }
}

private void switchToHeaderInner(String fragmentName, Bundle args) {
    getFragmentManager().popBackStack(BACK_STACK_PREFS,
            FragmentManager.POP_BACK_STACK_INCLUSIVE);
    if (!isValidFragment(fragmentName)) {
        throw new IllegalArgumentException("Invalid fragment for this activity: "
                + fragmentName);
    }

    Fragment f = Fragment.instantiate(this, fragmentName, args);
}

可以看到从 Intent 中获取了一个字符串和一个 Bundle 参数，并最终传入 switchToHeaderInner 中，用于实例化具体的 Fragment。实例化的过程如下：

public static Fragment instantiate(Context context, String fname, Bundle args) {
    // ...
    Class clazz = sClassMap.get(fname);
    if (clazz == null) {
            // Class not found in the cache, see if it's real, and try to add it
            clazz = context.getClassLoader().loadClass(fname);
            sClassMap.put(fname, clazz);
    }
    Fragment f = (Fragment)clazz.newInstance();
    if (args != null) {
            args.setClassLoader(f.getClass().getClassLoader());
            f.mArguments = args;
    }
    return f;
}

经典的反射调用，将传入的字符串实例化为 Java 类，并设置其参数。这是什么，这就是反序列化啊！而实际的漏洞也正是出自这里，由于传入的参数攻击者可控，那么攻击者可以将其设置为某个内部类，从而触及开发者预期之外的功能。在原始的报告中，作者使用了 Settings 应用中的某个设置 PIN 密码的 Fragment 作为目标传入，这是个私有片段，从而导致了越权修改 PIN 码的功能。在当时的其他用户应用中，还有许多也使用了 PreferenceActivity，因此漏洞影响广泛，而且造成的利用根据应用本身的功能而异（也就是看有没有好用的 Gadget）。

注意上面的代码摘自最新的 Android 13，其中 switchToHeaderInner 方法加入了 isValidFragment 的判断，这正是 Android 当初的修复方案之一，即强制要求 PreferenceActivity 的子类实现该方法，不然就在运行时抛出异常。不过即便如此，还是有很多开发者为了图方便直接继承然后返回 true 的。

Fragment Injection 看似是 PreferenceActivity 的问题，但其核心还是对于不可信输入的校验不完善，在后文的例子中我们会多次看到类似的漏洞模式。

参考文章：

点击劫持

Activity 既然作为 UI 的主要载体，那么与用户的交互也是其中关键的一项功能。在传统 Web 安全中就已经有过点击劫持的方法，即将目标网站想要让受害者点击的案件放在指定位置（如iframe），并在宿主中使用相关组件对目标进行覆盖和引导，令受害者在不知不觉中执行了敏感操作，比如点赞投币收藏一键离职等。

Android 中也出现过类似的攻击手段，比如在系统的敏感弹窗前面覆盖攻击者自定义的 TextView，引导受害者确认某些有害操作。当然这需要攻击者的应用拥有浮窗权限（SYSTEM_ALERT_WINDOW），在较新的 Android 系统中，该权限的申请需要用户多次的确认。

近两年中在 AOSP 中也出现过一些点击劫持漏洞，包括但不限于：

CVE-2020-0306：蓝牙发现请求确认框覆盖
CVE-2020-0394：蓝牙配对对话框覆盖
CVE-2020-0015：证书安装对话框覆盖
CVE-2021-0314：卸载确认对话框覆盖
CVE-2021-0487：日历调试对话框覆盖
…

对于系统应用而言，防御点击劫持的方法一般是通过使用 android.permission.HIDE_NON_SYSTEM_OVERLAY_WINDOWS 权限并在布局参数中指定 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS 来防止 UI 被覆盖。

而对于普通应用，没法申请 HIDE_NON_SYSTEM_OVERLAY_WINDOWS 权限，防御措施一般有两种，一是通过将布局的 filterTouchesWhenObscured 设置为 true 来禁止窗体被覆盖后的输入事件；二是重载 View.onFilterTouchEventForSecurity 方法，并在其中检测其他应用的覆盖情况。在 Android 12 中系统已经默认开启了 filterTouchesWhenObscured 属性，这也是 security by default 的一种经典实现。

关于点击劫持的操作细节和缓解方案，可以参考 OPPO 安全实验室的这篇文章：《不可忽视的威胁：Android中的点击劫持攻击》

另外一个与点击劫持类似的漏洞称为 StrandHogg，细节可以参考下述的原始文章。其关键点是使用了 Activity 的 allowTaskReparenting 和 taskAffinity 属性，将其任务栈伪装成目标应用，这样在打开目标应用时由于 TaskStack 后进先出的特性会导致用户看到的是攻击者的应用，从而造成应用的钓鱼场景。

后来还是同一个安全团队有提出了 StrandHogg 2.0 版本，主要利用了 ActivityStarter 中的 AUTOMERGE 特性。假设有 A、B 两个应用，在 A1 中调用 startActivites(B1, A2, B2) 之后，任务栈会从 (A1, B1) 以及 (A2, B2) 合并为 (A1, B1, A2, B2)，也就是在同一个任务栈中覆盖了其他应用的 Activity，从而导致钓鱼场景。不过这个漏洞比较特化，因此谷歌很早就已经修复了，详情可以阅读下面的参考文章：

Intent Redirection

Intent Redirection，顾名思义就是将用户传入的不可信输入进行了转发，类似于服务端的 SSRF 漏洞。一个典型漏洞例子如下：

protected void onCreate (Bundle savedInstanceState) {
   Intent target = (Intent) getIntent().getParcelableExtra("target");
   startActivity(target);
}

将用户传入的 target Parcelable 直接转换成了 Intent 对象，并将这个对象作为 startActivity 的参数进行调用。就这个例子而言，可能造成的危害就是攻击者可以用任意构造的 Intent 数据去启动目标 APP 中的任意应用，哪怕是未导出的私有应用。而目标未导出的应用中可能进一步解析了攻击者提供的 Intent 中的参数，去造成进一步的危害，比如在内置 Webview 中执行任意 Javascript 代码，或者下载保存文件等。

实际上 Intent Redirection 除了可能用来启动私有 Activity 组件，还可以用于其他的的接口，包括：

注：每种方法可能还有若干衍生方法，比如 startActivityForResult

前面三个可能比较好理解，分别是启动界面、启动服务和发送广播。最后一个 setResult 可能会在排查的时候忽略，这主要用来给当前 Activity 的调用者返回额外数据，主要用于 startActivityForResult 的场景，这同样也可能将用户的不可信数据污染到调用者处。

从防御的角度上来说，建议不要直接把外部传入的 Intent 作为参数发送到上述四个接口中，如果一定要这么做的话，需要事先进行充分的过滤和安全校验，比如：

将组件本身的 android:exported 设置为 false，但这只是防止了用户主动发送的数据，无法拦截通过 setResult 返回的数据；
确保获取到的 Intent 来自于可信的应用，比如在组件上下文中调用 getCallingActivity().getPackageName().equals("trust.app")，但注意恶意的应用可以通过构造数据令 getCallingActivity 返回 null；
确保待转发的 Intent 没有有害行为，比如 component 不指向自身的非导出组件，不带有 FLAG_GRANT_READ_URI_PERMISSION 等（详见后文 ContentProvider 漏洞）；
…

但事实证明，即便是 Google 自己，也未必能够确保完善的校验。无恒实验室近期提交的高危漏洞 CVE-2022-20223 就是个很典型的例子：

private void assertSafeToStartCustomActivity(Intent intent) {
    // Activity can be started if it belongs to the same app
    if (intent.getPackage() != null && intent.getPackage().equals(packageName)) {
        return;
    }
    // Activity can be started if intent resolves to multiple activities
    List<ResolveInfo> resolveInfos = AppRestrictionsFragment.this.mPackageManager
            .queryIntentActivities(intent, 0 /* no flags */);
    if (resolveInfos.size() != 1) {
        return;
    }
    // Prevent potential privilege escalation
    ActivityInfo activityInfo = resolveInfos.get(0).activityInfo;
    if (!packageName.equals(activityInfo.packageName)) {
        throw new SecurityException("Application " + packageName
                + " is not allowed to start activity " + intent);
    }
}

其中使用了 ActivityInfo.packageName 来判断启动目标的包名是否与当前 caller 的包名一致，可事实上显式 Intent 是通过 componentName 去指定启动目标，优先级高于 Intent.packageName 且后者可以被伪造，这就造成了检查的绕过。上述短短几行代码中其实还有另外一个漏洞，感兴趣的可以参考下面的参考链接。

因此，遇到潜在的 Intent 重定向问题时，可以多花点时间仔细审查，说不定就能够找到一个可利用的场景。

Service

Service 的主要功能有两个，一是给 APP 提供一个后台的长时间运行环境，二是对外提供自身的服务。与 Activity 的定义类似，Service 必须要在 manifest 中进行声明才能使用。注意 Service 中的代码也是和 Activity 一样运行在主线程的，并且默认和应用处于进程。

根据 Service 的两大主要功能区分，启动 Service 也有对应的两种形式：

Context.startService()：启动后台服务并让系统进行调度；
Context.bindService()：让（外部）应用绑定服务，并使用其提供的接口，可以理解为 RPC 的服务端；

两种方式启动服务的生命周期图示如下：

蓝色部分都是在客户端去进行调用，系统收到请求后会启动对应的服务，如果对应的进程没有启动也会通知 zygote 去启动。不管是哪种方法创建服务，系统都会为其调用 onCreate 和 onDestroy 方法。整体流程和 Activity 的启动流程类似，这里不再赘述。

shell 中同样提供了 start-activity 命令来方便启动服务：

am start-service [--user  | current]

下面来介绍一些 Service 组件相关的漏洞。

生命周期

前面介绍了 Service 启动的生命周期，总体和 Activity 流程差不多，但需要注意有几点不同：

与 Activity 生命周期回调方法不同，不需要调用 Serivce 回调方法的超类实现，比如 onCreate、onDestory 等；
Service 类的直接子类运行在主线程中，同时处理多个阻塞的请求时候一般需要在新建线程中执行；
IntentService 是 Service 的子类，被设计用于运行在 Worker 线程中，可以串行处理多个阻塞的 Intent 请求；API-30 以后被标记为废弃接口，建议使用 WorkManager 或者 JobIntentService 去实现；
客户端通过 stopSelf 或者 stopService 来停止绑定服务，但服务端并没有对应的 onStop 回调，只有在销毁前收到 onDestory；
前台服务必须为状态栏提供通知，让用于意识到服务正在运行；

对于绑定服务而言，Android 系统会根据绑定的客户端引用计数来自动销毁服务，但如果服务实现了 onStartCommand() 回调，就必须显式地停止服务，因为系统会将其视为已启动的状态。此外，如果服务允许客户端再次绑定，就需要实现 onUnbind 方法并返回 true，这样客户端在下次绑定时候会接收到同样的 IBinder，示例图如下所示：

服务的声明周期相比于 Activity 更加复杂，因为涉及到进程间的绑定关系，因此也就更可能在不了解的情况下编写出不健壮甚至有问题的代码。

Implicit Export

和 Activity 一样，Service 也要在 manifest 中使用 service 去声明，也有 android:exported 属性。甚至关于该属性的默认值定义也是一样的，即默认是 false，但包含 intent-filter 时，默认就是 true。同样，在 Android 12 及以后也强制性要求必须显式指定服务的导出属性。

服务劫持

与 Activity 不同的是，Android 不建议使用隐式 Intent 去启动服务。因为服务在后台运行，没有可见的图形界面，因此用户看不到隐式 Intent 启动了哪个服务，且发送者也不知道 Intent 会被谁接收。

服务劫持是一个典型的漏洞，攻击者可以为自己的 Service 声明与目标相同的 intent-filter 并设定更高的优先级，这样可以截获到本应发往目标服务的 Intent，如果带有敏感信息的话还会造成数据泄露。

而在 bindService 中这种情况的危害则更加严重，攻击者可以伪装成目标 IPC 服务去返回错误甚至是有害的数据。因此，在 Android 5.0 （API-21）开始，使用隐式 Intent 去调用 bindService 会直接抛出异常。

如果待审计的目标应用在 Service 中提供了 intent-filter，那么就需要对其进行重点排查。

AIDL

绑定服务可以被用来用作 IPC 服务端，如果服务端绑定的时候返回了 AIDL 接口的实例，那么就意味着客户端可以调用该接口的任意方法。一个实际案例是 Tiktok 的 IndependentProcessDownloadService，在 DownloadService 的 onBind 中返回了上述 AIDL 接口的实例：

com/ss/android/socialbase/downloader/downloader/DownloadService.java:

if (this.downloadServiceHandler != null) {
    return this.downloadServiceHandler.onBind(intent);
}

而其中有个 tryDownload 方法可以指定 url 和文件路径将文件下载并保存到本地。虽然攻击者没有 AIDL 文件，但还是可以通过反射去构造出合法的请求去进行调用，PoC 中关键的代码如下：

private ServiceConnection mServiceConnection = new ServiceConnection() {
    public void onServiceConnected(ComponentName cName, IBinder service) {
        processBinder(service);
    }

    public void onServiceDisconnected(ComponentName cName) { }
};

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    Intent intent = new Intent("com.ss.android.socialbase.downloader.remote");
    intent.setClassName(
        "com.zhiliaoapp.musically",
        "com.ss.android.socialbase.downloader.downloader.IndependentProcessDownloadService");
    bindService(intent, mServiceConnection, BIND_AUTO_CREATE);
}

private void processBinder(IBinder binder) {
    ClassLoader cl = getForeignClassLoader(this, "com.zhiliaoapp.musically");
    Object handler = cl.loadClass("com.ss.android.socialbase.downloader.downloader.i$a")
            .getMethod("asInterface", IBinder.class)
            .invoke(null, binder);

    Object payload = getBinder(cl);

    cl.loadClass("com.ss.android.socialbase.downloader.downloader.i")
            .getMethod("tryDownload", cl.loadClass("com.ss.android.socialbase.downloader.model.a"))
            .invoke(handler, payload);
}

private Object getBinder(ClassLoader cl) throws Throwable {
    Class utilsClass = cl.loadClass("com.ss.android.socialbase.downloader.utils.g");
    Class taskClass = cl.loadClass("com.ss.android.socialbase.downloader.model.DownloadTask");
    return utilsClass.getDeclaredMethod("convertDownloadTaskToAidl", taskClass)
            .invoke(null, getDownloadTask(taskClass, cl));
}

关键在于使用 Context.getForeignClassLoader 获取其他应用的 ClassLoader。

漏洞细节参考： vulnerabilities in the TikTok Android app

Intent Redirect

这个其实和 Activity 中的对应漏洞类似，客户端启动/绑定 Service 的时候也指定了隐式或者显式的 Intent，其中的不可信数据如果被服务端用来作为启动其他组件的参数，就有可能造成一样的 Intent 重定向问题。注意除了 getIntent() 之外还有其他数据来源，比如服务中实现的 onHandleIntent 的参数。

其实最早提出 Intent 重定向危害的 “LaunchAnywhere” 漏洞就是出自系统服务，准确来说是 AccountManagerService 的漏洞。AccountManager 正常的执行流程为：

普通应用（记为 A）去请求添加某类账户，调用 AccountManager.addAccount；
AccountManager 会去查找提供账号的应用（记为 B）的 Authenticator 类；
AccountManager 调用 B 的 Authenticator.addAccount 方法；
AccountManager 根据 B 返回的 Intent 去调起 B 的账户登录界面（AccountManagerResponse.getParcelable）；

在第 4 步时，系统认为 B 返回的数据是指向 B 的登陆界面的，但实际上 B 可以令其指向其他组件，甚至是系统组件，就造成了一个 Intent 重定向的漏洞。这里 Intent 的来源比较曲折，但本质还是攻击者可控的。

关于该漏洞的细节和利用过程可参考：launchAnyWhere: Activity组件权限绕过漏洞解析(Google Bug 7699048 )

Receiver

Broadcast Receiver，简称 receiver，即广播接收器。前面介绍的 Activity 和 Service 之间的联动都是一对一的，而很多情况下我们可能想要一对多或者多对多的通信方案，广播就承担了这个功能。比如，Android 系统本身就会在发生各种事件的时候发送广播通知所有感兴趣的应用，比如开启飞行模式、网络状态变化、电量不足等等。这是一种典型的发布/订阅的设计模式，广播数据的载体也同样是 Intent。

与前面 Activity 与 Service 不同的是，Receiver 可以在 manifest 中进行声明注册，称为静态注册；也可以在应用运行过程中进行动态注册。但无论如何，定义的广播接收器都要继承自 BroadcastReceiver 并实现其声明周期方法 onReceive(context, intent)。

注意 BroadcastReceiver 的父类是 Object，不像 Activity 与 Service 是 Context，因此 onReceive 还会额外传入一个 context 对象。

shell 中发送广播的命令如下：

am broadcast [--user  | all | current]

下面还是按顺序介绍一些常见的问题。

Implicit Export

使用静态注册的 receiver 倒没什么特殊，示例如下：

 android:name=".MyBroadcastReceiver"  android:exported="true">
    
         android:name="android.intent.action.BOOT_COMPLETED"/>
         android:name="android.intent.action.INPUT_METHOD_CHANGED" />

同样存在和之前一样的默认 export 问题，相信大家已经看腻了，就不再啰嗦了。接着看动态注册的情况，比如：

BroadcastReceiver br = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
filter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED);
this.registerReceiver(br, filter);

与清单中的定义相比，动态注册的方式可能更容易忽略导出权限的问题。上述代码片段动态注册了一个广播，但没有显式声明 exported 属性，因此默认是导出的。事实上使用 registerReceiver 似乎没有简单的方法去设置 exported=false，而 Google 官方的建议是对于不需要导出的广播接收器使用 LocalBroadcastManager.registerReceiver 进行注册，或者在注册的时候指定 permission 权限。

对于指定 permission 权限的情况，如果是自定义权限，需要在应用清单中声明，比如：

 android:name="com.evilpan.MY_PERMISSION"
    android:protectionLevel="signature"/>
 android:name="com.evilpan.MY_PERMISSION" />

signature 表示只有在请求授权的应用使用与声明权限的应用相同的证书进行签名时系统才会授予的权限。如果证书匹配，则系统会在不通知用户或征得用户明确许可的情况下自动授予权限。详见 protectionLevel。

最后在动态注册时指定该权限即可：

this.registerReceiver(br, filter, "com.evilpan.MY_PERMISSION", null);

注册未带有权限限制的导出广播接收器会导致接收到攻击者伪造的恶意数据，如果在 onReceive 时校验不当，可能会出现越权或者 Intent 重定向等漏洞，造成进一步的安全危害。

这类安全问题很多，比较典型的就有 Pwn2Own 上用于攻破三星 Galaxy S8 的 PpmtReceiver 漏洞。

信息泄露

上面主要是从限制广播发送方的角度去设置权限，但其实这个权限也能限制广播的接收方，只不过发送消息的时候要进行额外的指定，比如要想只让拥有上述权限的接收方受到广播，则发送代码如下：

Intent it = new Intent(this, ...);
it.putExtra("secret", "chicken2beautiful")
sendBroadcast(it, "com.evilpan.MY_PERMISSION");

如果不带第二个参数的话，默认是所有满足条件的接受方都能受到广播信息的。此时若是发送的 Intent 中带有敏感数据，就可能会造成信息泄露问题。

一个实际案例就是 CVE-2018-9581，系统在广播 android.net.wifi.RSSI_CHANGED 时携带了敏感数据 RSSI，此广播能被所有应用接收，从而间接导致物理位置信息泄露。（搞笑？）

可见对于 Broadcast Receiver 而言，permission 标签的作用尤其明显。对于系统广播而言，比如 BOOT_COMPLETED，通常只有系统应用才有权限发送。这都是在 framework 的 AndroidManifest.xml 中进行定义的。

而对于应用的自定义广播，通常是使用上述自定义权限，那么也就自然想到一个问题，如果多个应用定义了同一个权限会怎么样？其实这是正是一个历史漏洞，在早期 Android 的策略是优先采用第一个定义的权限，但在 Andorid 5 之后就已经明确定义了两个应用不同定义相同的权限（除非他们的签名相同），否则后安装的应用会出现 INSTALL_FAILED_DUPLICATE_PERMISSION 错误警告。感兴趣的考古爱好者可以参考下面的相关文章：

Intent Redirection

原理不多说了，直接看案例吧。漏洞出在 Tiktok 的 NotificationBroadcastReceiver 中，定义了 intent-filter 导致组件默认被设置为导出，因此可以接收到外部应用的广播，而且又将广播中的不可信数据直接拿来启动 Activity，如下：

漏洞细节可参考：Oversecured detects dangerous vulnerabilities in the TikTok Android app

ContentProvider

Content Provider，即内容提供程序，简称为 Provider。Android 应用通常实现为 MVC 结构（Model-View-Controller），Model 部分即为数据来源，供自身的 View 即图形界面进行展示。但有时候应用会想要将自身的数据提供给其他数据使用，或者从其他应用中获取数据。

定义一个 ContentProvider 的方式，只需要继承自 ContentProvider 类并实现六个方法： query，insert， update， delete， getType 以及 onCreate。其中除了 onCreate 是系统在主线程调用的，其他方法都由客户端程序进行主动调用。自定义的 provider 必须在程序清单中进行声明，后文会详细介绍。

可以看到 Provider 主要实现了类似数据库的增删改查接口，从客户端来看，查询过程也和查询传统数据库类似，例如，下面是查询系统短信的代码片段：

Cursor cursor = getContentResolver().query(
    Telephony.Sms.Inbox.CONTENT_URI,           // 指定要查询的表名
    new String[] { Telephony.Sms.Inbox.BODY }, // projection 指定索要查询的列名
    selectionClause,                           // 查询的过滤条件
    selectionArgs,                             // 查询过滤的参数 
    Telephony.Sms.Inbox.DEFAULT_SORT_ORDER);   // 返回结果的排序
while (cursor.moveToNext()) {
    Log.i(TAG, "msg: " + cursor.getString(0));
}

其中 ContentResolver 是 ContentInterface 子类，后者是 ContentProvider 的客户端远程接口，可以实现其透明的远程代理调用。 content_uri 可以看作是查询的表名，projection 可以看作是列名，返回的 cursor 是查询结果行的迭代器。

与前面三个组件不同，在 shell 中访问 provider 组件的工具是 content。

下面来介绍 Provider 中常见的问题。

Permissions

鉴于 provider 作为数据载体，那么安全访问与权限控制自然是重中之重。例如上面代码示例中访问短信的接口，如果所有人都能随意访问，那就明显会带来信息泄露问题。前面简单提到过，应用中定义的 Provider 必须要在其程序清单文件中进行声明，使用的是 provider 标签。其中有我们常见的 exported 属性，表示是否可被外部访问，permission 属性则表示访问所需的权限，当然也可以分别对读写使用不同的权限，比如 readPermission/writePermission 属性。

比如，前文提到的短信数据库声明如下：

 android:name="SmsProvider"
    android:authorities="sms"
    android:multiprocess="false"
    android:exported="true"
    android:singleUser="true"
    android:readPermission="android.permission.READ_SMS" />

其他应用若想访问，则需在清单文件中声明请求对应权限。

 android:name="android.permission.READ_SMS" />

这都很好理解，其他组件也有类似的特性。除此之外，Provider 本身还提供了更为细粒度的权限控制，即 grantUriPermissions。这是一个布尔值，表示是否允许临时为客户端授予该 provider 的访问权限。临时授予权限的运行流程一般如下：

客户端给 Provider 所在应用发送一个 Intent，指定想要访问的 Content URI，比如使用 startActivityForResult 发送；
应用收到 Intent 后，判断是否授权，如果确认则准备一个 Intent，并设置好 flags 标志位 FLAG_GRANT_[READ|WRITE]_URL_PERMISSION，表示允许读/写对应的 Content URI（可以不和请求的 URI 一致），最后使用 setResult(code, intent) 返回给客户端；
客户端的 onActivityResult 收到返回的 Intent，使用其中的 URI 来临时对目标 Provider 进行访问；

以读为例，Intent.flags 中如果包含 FLAG_GRANT_READ_URI_PERMISSION，那么该 Intent 的接收方（即客户端）会被授予 Intent.data 部分 URI 的临时读取权限，直至接收方的生命周期结束。另外，Provider 应用也可以主动调用 Context.grantUriPermission 方法来授予目标应用对应权限：

public abstract void grantUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)
public abstract void revokeUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)

grantUriPermissions 属性可以在 URI 粒度对权限进行读写控制，但有一个需要注意的点：通过 grantUriPermissions 临时授予的权限，会无视 readPermission、writePermission、permission 和 exported 属性施加的限制。也就是说，即便 exported=false，客户端也没有申请对应的 uses-permission，可一旦被授予权限，依然可以访问对应的 Content Provider！

另外，还有一个子标签 grant-uri-permission，即便 grantUriPermissions 被设置为 false，通过临时获取权限依然可以访问该标签下定义的 URI 子集，该子集可以用前缀或者通配符去指定 URI 的可授权路径范围。

Provider 权限设置不当可能会导致应用数据被预期之外的恶意程序访问，轻则导致信息泄露，重则会使得自身沙盒数据被覆盖而导致 RCE，后文会看到多个这样的案例。

FileProvider

前面说过自定义 Provider 需要实现六个方法，但 Android 中已经针对某些常用场景的 Provider 编写好了对应的子类，用户可根据需要继承这些子类并实现少部分子类方法即可。其中一个常用场景就是用 ContentProvider 分享应用的文件，系统提供了 FileProvider 来方便应用自定义文件分享和访问，但是使用不当的话很可能会出现任意文件读写的问题。

FileProvider 提供了使用 XML 去指定文件访问控制的功能，一般 Provider 应用只需继承 FileProvider 类：

public class MyFileProvider extends FileProvider {
   public MyFileProvider() {
       super(R.xml.file_paths)
   }
}

file_paths 是用户自定义的 XML，也可以在清单文件中使用 meta-data 去指定：

 xmlns:android="http://schemas.android.com/apk/res/android" android:name="com.evilpan.MyFileProvider" android:exported="false" android:authorities="com.evilpan.fileprovider" android:grantUriPermissions="true">
   android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@7F15000E"/>

resource 指向 res/xml/file_paths.xml。该文件中定义了可供访问的文件路径，FileProvider 只会对提前指定的文件生成 Content URI。一个文件路径配置示例如下：


   name="root" path=""/>
   name="internal_files" path="."/>
   name="cache" path=""/>
   name="external_files" path="images"/>

paths 标签支持多种类型的子标签，分别对应不同目录的子路径：

files-path: Context.getFilesDir()
cache-path: Context.getCacheDir()
external-path: Environment.getExternalStorageDirectory()
external-files-path: Context.getExternalFilesDir()
external-cache-path: Context.getExternalCacheDir()
external-media-path: Context.getExternalMediaDirs()[0]

比较特殊的是 root-path，表示系统的根目录 /。FileProvider 生成的 URI 格式一般是 content://authority/{name}/{path}，比如对于上述 Provider，可用 content://com.evilpan.fileprovider/root/proc/self/maps 来访问 /proc/self/maps 文件。

由此可见，FileProvider 指定 root-path 是一个危险的标志，一旦攻击者获得了临时权限，就可以读取所有应用的私有数据。

比如，TikTok 历史上就有过这么一个真实的漏洞：

 android:name="android.support.v4.content.FileProvider" android:exported="false" android:authorities="com.zhiliaoapp.musically.fileprovider" android:grantUriPermissions="true">
         android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/k86"/>

这里直接使用了 FileProvider，甚至都不需要继承。xml/k86.xml 文件内容如下：


 xmlns:amazon="http://schemas.amazon.com/apk/res/android" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto">
     name="name" path=""/>
     name="share_path0" path="share/"/>
     name="download_path2" path="Download/"/>
     name="gif" path="gif/"/>
    ...

获取临时权限之后就可以实现应用的任意文件读写。

The Hidden …

在 ContentProvider 类中，除了前面说过的 6 个必须实现的方法，还有一些其他隐藏的方法，一般使用默认实现，也可以被子类覆盖实现，比如

openFile
openFileHelper
call
…

这些隐藏的方法可能在不经意间造成安全问题，本节会通过一些案例去分析其中的原因。

openFile

如果 ContentProvider 想要实现共享文件读写的功能，还可以通过覆盖 openFile 方法去实现，该方法的默认实现会抛出 FileNotFoundException 异常。

虽然开发者实现上不太会直接就返回打开的本地文件，而是有选择地返回某些子目录文件。但是如果代码写得不严谨，就可能会出现路径穿越等问题，一个经典的漏洞实现如下：

 @Override
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
    File file = new File(getContext().getFilesDir(), uri.getPath());
    if(file.exists()){
        return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY);
    }
    throw new FileNotFoundException(uri.getPath());
}

另外一个同族的类似方法是 openAssetFile，其默认实现是调用 openFile：

public @Nullable AssetFileDescriptor openAssetFile(@NonNull Uri uri, @NonNull String mode)
        throws FileNotFoundException {
    ParcelFileDescriptor fd = openFile(uri, mode);
    return fd != null ? new AssetFileDescriptor(fd, 0, -1) : null;
}

有时候开发者虽然知道要要防御路径穿越，但防御的姿势不对，也存在被绕过的可能，比如：

public ParcelFileDescriptor openFile(Uri uri, String mode) {
    File f = new File(DIR, uri.getLastPathSegment());
    return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

这里想用 getLastPathSegment 去只获取最后一级的文件名，但实际上可以被 URL encode 的路径绕过，比如 %2F..%2F..path%2Fto%2Fsecret.txt 会返回 /../../path/to/secret.txt。

还有一种错误的防御是使用 UriMatcher.match 方法去查找 ../，这也会被 URL 编码绕过。正确的防御和过滤方式如下：

public ParcelFileDescriptor openFile (Uri uri, String mode) throws FileNotFoundException {
  File f = new File(DIR, uri.getLastPathSegment());
  if (!f.getCanonicalPath().startsWith(DIR)) {
    throw new IllegalArgumentException();
  }
  return ParcelFileDescriptor.open(f, ParcelFileDescriptor.MODE_READ_ONLY);
}

详见：Path Traversal Vulnerability

openFileHelper

ContentProvider 中还有一个鲜为人知的 openFileHelper 方法，其默认实现是使用当前 Provider 中的 _data 列数据去打开文件，源码如下：

protected final @NonNull ParcelFileDescriptor openFileHelper(@NonNull Uri uri,
        @NonNull String mode) throws FileNotFoundException {
    Cursor c = query(uri, new String[]{"_data"}, null, null, null);
    int count = (c != null) ? c.getCount() : 0;
    if (count != 1) {
        // If there is not exactly one result, throw an appropriate
        // exception.
        if (c != null) {
            c.close();
        }
        if (count == 0) {
            throw new FileNotFoundException("No entry for " + uri);
        }
        throw new FileNotFoundException("Multiple items at " + uri);
    }

    c.moveToFirst();
    int i = c.getColumnIndex("_data");
    String path = (i >= 0 ? c.getString(i) : null);
    c.close();
    if (path == null) {
        throw new FileNotFoundException("Column _data not found.");
    }

    int modeBits = ParcelFileDescriptor.parseMode(mode);
    return ParcelFileDescriptor.open(new File(path), modeBits);
}

这个方法的主要作用是方便子类用于快速实现 openFile 方法，通常不会直接在子类去覆盖。不过由于其中基于 _data 列去打开文件的特性可能会攻击者插入恶意数据后间接地实现任意文件读写。

一个经典案例就是三星手机的 SemClipboardProvider，在插入时未校验用户数据：

public Uri insert(Uri uri, ContentValues values) {
    long row = this.database.insert(TABLE_NAME, "", values);
    if (row > 0) {
        Uri newUri = ContentUris.withAppendedId(CONTENT_URI, row);
        getContext().getContentResolver().notifyChange(newUri, null);
        return newUri;
    }
    throw new SQLException("Fail to add a new record into " + uri);
}

而该 Provider 又在 system_server 进程中，拥有极高的运行权限，攻击者通过利用这个漏洞去就能实现系统层面的任意文件读写，其 PoC 如下：

ContentValues vals = new ContentValues();
vals.put("_data", "/data/system/users/0/newFile.bin");
URI semclipboard_uri = URI.parse("content://com.sec.android.semclipboardprovider")
ContentResolver resolver = getContentResolver();
URI newFile_uri = resolver.insert(semclipboard_uri, vals);
return resolver.openFileDescriptor(newFile_uri, "w").getFd();

该漏洞与其他漏洞一起曾被用于在野攻击中，由 Google TAG 团队捕获，对这一条 Fullchain 的分析可以参考 Project Zero 近期的文章：A Very Powerful Clipboard: Analysis of a Samsung in-the-wild exploit chain

call

ContentProvider 中提供了 call 方法，用于实现调用服务端定义方法，其函数签名如下：

public Bundle call (String authority, 
                String method, 
                String arg, 
                Bundle extras)
public Bundle call (String method, 
                String arg, 
                Bundle extras)

默认的实现是个空函数直接返回 null，开发者可以通过覆盖该函数去实现一些动态方法，返回值也会传回到调用者中。

看起来和常规的 RPC 调用类似，但这里有个小陷阱，开发者文档中也特别标注了：Android 系统并没有对 call 函数进行权限检查，因为系统不知道在 call 之中对数据进行了读还是写，因此也就无法根据 Manifest 中定义的权限约束进行判断。因此要求开发者自己对 call 中的逻辑进行权限校验。

如果开发者实现了该方法，但是又未进行校验或者校验不充分，就可能出现越权调用的情况。一个案例是 CVE-2021-23243， OPPO 某系统应用中 HostContentProviderBase 的 call 方法实现中，直接用 DexClassLoader 去加载了传入 dex 文件，直接导致攻击者的代码在特权进程中运行，所有继承该基类的 Provider 都会受到影响。

另外在某些系统 Provider 中，可以通过 call 方法去获取某些远程对象实例，例如在文章 Android 中的特殊攻击面（三）—— 隐蔽的 call 函数中，作者就通过 SliceProvider 与 KeyguardSliceProvider 获取到了系统应用内部的 PendingIntent 对象，进一步利用实现了伪造任意广播的功能。

其他

除了上述和四大组件直接相关的漏洞，Android 系统中还有许多不太好分类的漏洞，本节主要挑选其中几个最为常见的漏洞进行简单介绍。

PendingIntent

PendingIntent 是对 Intent 的表示，本身并不是 Intent 对象，但是是一个 Parcelable 对象。将该对象传递给其他应用后，其他应用就可以以发送方的身份去执行所指向的 Intent 指定的操作。 PendingIntent 使用下述静态方法之一进行创建：

getActivity(Context, int, Intent, int);
getActivities(Context, int, Intent[], int);
getBroadcast(Context, int, Intent, int);
getService(Context, int, Intent, int);

PendingIntent 本身只是系统对原始数据描述符的一个引用，可以大致将其理解为 Intent 的指针。也因为如此，即便创建 PendingIntent 的应用关闭后，其他应用仍然可以使用该数据。如果原始应用后来进行了重启并以同样的参数创建了一个 PendingIntent，那么实际上返回 PendingIntent 与之前创建的会指向同样的 token。注意判断 Intent 是否相同是使用 filterEquals 方法，其中会判断 action，data， type，identity，class，categories 是否相同，注意 extra 并不在此列，因此仅有 extra 不同的 Intent 也会被认为是相等的。

由于 PendingIntent 可代表其他应用的特性，在某些场景下可能被用于滥用。例如，如果开发者创建了这样一个默认的 PendingIntent 并传递给其他应用：

pi = PendingIntent.getActivity(this, 0, new Intent(), 0);
bundle.putParcelable("pi", pi)
// send bundle

恶意的应用在收到此 PendingIntent 后，可以获取到原始的 intent，并使用 Intent.fillin 去填充空字段，如果原始 Intent 是上述空 Intent，那么攻击者就可以将其修改为特定的 Intent，从而以目标的身份去启动应用，包括未导出的私有应用。一个经典的案例就是早期的 broadAnywhere 漏洞，Android Settings 应用中的 addAccount 方法内创建了一个 PendingIntent 广播，但 intent 内容为空，这导致收到 intent 的的恶意应用可以 fillin 填充广播的 action，从而实现越权发送系统广播，实现伪造短信、回复出厂设置等功能。

为了缓解这类问题，Andorid 中对 Intent.fillin 的改写做了诸多限制，比如已有的字段不能修改，component 和 selector 字段不能修改（除非额外设置 FILL_IN_COMPONENT/SELECTOR），隐式 Intent 的 action 不能修改等。

不过有研究者提出了针对隐式 Intent 的利用方法，即通过修改 flag 添加 FLAG_GRANT_WRITE_URI_PERMISSION，并修改 data 的 URI 指向受害者私有的 Provider，将 package 改为攻击者；同时攻击者在自身的 Activity 中声明相同的 intent filter，这样在转发 intent 时会启动攻击者应用，同时也获取了目标私有 Provider 的访问权限，从而实现私有文件窃取或者覆盖。关于该攻击思路详情可以阅读下面的参考文章。

在 Android 12+ 之后，PendingIntent 在创建时候要求显式指定 FLAG_MUTABLE 或者 FLAG_IMMUTABLE，表示是否可以修改。

DeepLink

在大部分操作系统中都有 deeplink 的概念，即通过自定义 schema 打开特定的应用。比如通过点击 https://evilpan.com/ 可以唤起默认浏览器打开目标网页，点击 tel://10086 会唤起拨号界面，点击 weixin://qr/xxx 会唤起微信，等等。其他系统暂且不论，在 Android 中这主要是通过隐式 Intent 去实现的。

应用要想注册类似的自定义协议，需要在应用清单文件中进行声明：


   android:name="android.intent.action.VIEW"/>
   android:name="android.intent.category.DEFAULT"/>
   android:name="android.intent.category.BROWSABLE"/>
 android:scheme="weixin" android:host="qr"/>

由于这类隐式 Intent 可以直接通过点击链接去触发，因此更受攻击者喜爱。如果处理对应 Intent 的组件没有过滤好用户传入的内容，很可能会造成 1-click 的漏洞。相关案例可以参考文章：Android 中的特殊攻击面（二）——危险的deeplink

Webview

在 Andorid 系统中，Webview 主要用于应用在自身的 Activty 中展示网页内容，并提供了一些额外的接口来给开发者实现自定义的控制。更高的拓展性也就意味着更多出错的可能，尤其是如今 Android 客户端开发式微，Java 开发也朝着 “大前端” 的方向发展。原本许多使用原生应用实现的逻辑逐渐转移到了 web 页面中，比如 h5、小程序等，这样一来，webview 的攻击面也就扩宽了不少。

常规的 Webview 安全问题主要是在与一些配置的不安全，比如覆盖 onReceivedSslError 忽略 SSL 错误导致中间人攻击，setAllowFileAccessFromFileURLs 导致本地私有文件泄露等。但现在的漏洞更多出在 JSBridge 上，这是 Java 代码与网页中的 JavaScript 代码沟通的桥梁。

由于 Webview 或者说 JS 引擎的沙箱特性，网页中的 Javascript 代码本身无法执行许多原生应用才能执行的操作，比如无法从 Javascript 中发送广播，无法访问应用文件等。而由于业务的复杂性，很多逻辑又必须在 Java 层甚至是 Native 层才能实现，因此这就需要用到 JSBridage。传统的 JSBridge 通过 Webview.addJavascriptInterface 实现，一个简单示例如下：

class JsObject {
    @JavascriptInterface
    public String toString() { return "injectedObject"; }
}
webview.getSettings().setJavaScriptEnabled(true);
webView.addJavascriptInterface(new JsObject(), "injectedObject");
webView.loadData("", "text/html", null);
webView.loadUrl("javascript:alert(injectedObject.toString())");

Java 层返回数据给 Javascript 一般是通过直接使用 loadUrl 执行 JS 代码实现。当然除了这种方式注册 Bridge，还有很多应用特异的实现，比如使用 console.log 传输数据并在 Java 层使用 onConsoleMessage 回调去接收。但无论如何，这都导致攻击面的增加，大型应用甚至注册了上百个 jsapi 来供网页调用。

从历史漏洞来看，Webview 漏洞的成因主要是 jsapi 域名校验问题和 Bridge 代码本身的漏洞，由于篇幅原因就不展开了。

后记

本文中主要通过 Android 中的四大组件介绍了一系列相关的逻辑问题，尽可能地囊括了笔者所了解的历史漏洞。由于个人认知水平有限，总是难免挂一漏万，但即便如此，文章的篇幅还是比预想中的超出了亿点点。从温故知新的角度看，挖掘这类逻辑漏洞最好的策略还是使用静态分析工具，搜集更多 Sink 模式并编写有效的规则去进行扫描，实在没有条件的话用 (rip)grep 也是可以的。

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/11/13/android-bugs/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

终端应用安全之网络流量分析

Sun, 22 May 2022 10:40:00 +0800

在日常对客户端应用进行安全审计或者漏洞挖掘的时候，或多或少都会涉及到网络协议的分析。而对于业务风控安全而言，APP 的网络请求往往也代表着终端安全防御水平的上限，因为客户端是掌控在攻击者手中的，服务端的业务逻辑才是安全的核心兜底保障。

本文是笔者在分析众多 Android 应用协议的过程中所尝试总结的一些经验，大部分情况下也可以适用于其他平台的终端应用，如 iOS、macOS、Windows 等，尽管各个操作系统中会存在一些特有的小技巧。

网络流量分析

在介绍具体的流量分析方法之前，我们需要先明确流量分析的目的。对于笔者而言，流量分析的目的通常是为了搞清楚应用某个操作背后实际的行为。比如对于 IM 聊天软件而言，需要了解发送文本消息、图片消息、多媒体消息等背后实际的请求是什么，以梳理其中潜在的攻击面；对于社交类应用，可能黑灰产最关心的是账号创建、登录以及点赞等操作背后的协议，以用于水军的构建；而对于病毒分析师，可能更关注样本与 CC 服务器之间命令协议，以尝试溯源木马背后的僵尸网络。……

其中木马病毒的场景相对特殊，本文更多是针对商业应用的网络流量分析。在分析流量的时候，我们显然需要能够观测到目标流量的明文。这看似是一个简单的需求，却并不容易实现。

首先考虑网络协议的类型，既然是商业应用，那么大部分情况下使用的也是较为通用的网络协议，即 HTTP。但由于面临运营商劫持等原因，目前以 HTTP 请求进行明文传输的仅是少数了，TLS 已经成为目前网络加密的主流。

其次在应用层，目标请求也有不少是经过自行加密的，可以是一个简化版的 ECDH，也可以是随机 AES 秘钥 + 内置公钥加密的方式。这对于第三方而言，并没有一个很好的方式进行通用解密，只能根据不同应用进行 case by case 的逆向分析并进行还原。

因此，对于应用层加密的情况姑且先不考虑，在面对常规 TLS 加密的流量时，我们最好能够有一种方法能够对其进行解密还原。在 TLS 之下并非只有 HTTP，也有部分使用了 MQTT、Websocket 等协议的请求，必要时也需要考虑在内。

因此，我们的应用网络流量分析目标，又可以分解成两个小目标:

目标应用流量截取(捕获)；
目标应用流量解密(TLS 解密)；

当然，实际的流量分析并不一定需要两个目标同时达成。在某些场景下，可以仅仅通过解密观察到目标的请求数据，并通过日志打印等方式展示出来。

流量抓取

首先看应用流量截取的方案，也即通常我们所说的“抓包”。

系统代理

这是最为简单也是最为常用的一种抓包方案。在 Android、iOS、macOS 这些操作系统中连接 WiFi 时可以指定我们自定义的 HTTP 代理地址。如果应用使用了是系统提供的网络库或者遵循这个代理配置，那么就会将 HTTP(S) 请求通过该代理进行发送。

因此，这种方式有个很明显的缺点: 应用可能不按规矩来。不管是设置的系统代理，还是通过 HTTP_PROXY 环境变量指定代理，都只是一种约定俗成的规则而已。应用完全可以在自身代码中通过 socket、connect、write 三连去直接发送网络请求，这样我们的代理就无法收到任何数据。即便是对于系统提供的 HTTP 网络库，一般也会有额外的配置选项，让调用者指定或者忽略任何系统代理。

设置系统代理进行抓包的方法也是有优点的。这种方式配置起来比较简单，而且对应的配套工具也相对成熟，Burpsuite、Fiddle 之类的工具可以很方便的对代理到的流量进行格式化和重放分析。当然，对于非 HTTP 的其他协议支持可能就不是很完善了。

除了直接设置系统代理，对于桌面应用其实还有一些其他方式去对目标应用进行代理，比如使用 proxychains 工具去加载动态库从而重定向目标网络请求。虽然原理不同，但其实际效果比较类似，因此也统一归类为系统代理方法。

路由抓包

既然系统代理模式抓包容易被应用绕过导致流量缺失，那么一个直观的想法就是回归流量分析的本身，直接在网络层进行抓包。其中比较常用的方式就是路由抓包，即在网关层进行抓包。

具体实现也不难，大家应该都知道在近源渗透中的 evilTwin AP, 即假热点的攻击方法。攻击者通过可以完全控制的机器创建一个假热点，待目标连入后进行网络劫持，从而获取敏感信息，或者替换关键流量实现代码执行。从这个角度上看，该方法也可以看做是一种 “网络临侦”。

对于我们的抓包方案来说，可以构建一个真热点，一般使用开源的 hostapd 可以实现；而热点网络所需要的 DHCP 服务器或者 DNS 服务器可以通过 dnsmasq 去实现。

路由抓包方案通常与透明代理进行结合使用，以实现 HTTP 请求分析、劫持与重放的功能。透明代理对于客户端而言是一个真实的 HTTP 服务器，通常通过 DNS 劫持或者路由劫持去实现。Nginx 中一个重要的功能就是透明代理，在同一个公网地址进行监听，并通过不同的域名分发到实际的后端服务器中。

前文提到的许多 HTTP 代理工具也支持透明代理，比如 BurpSuite 就支持 invisible proxy，mitmproxy 中称为 Transparent proxy ，通过 -m transparent 指定。

路由抓包和系统代理相比具有很多优点，比如可以保证抓到所有的 HTTP/HTTPS 流量，并且对于目标应用透明。这里有个潜在的好处，由于对被抓包目标透明，因此路由抓包可以用于一些 IoT 设备的流量分析，比如车机设备、智能家居等等。

缺点也很明显，即路由抓包需要额外的自定义路由设备。如果是运行在 PC 端且驱动支持完善的话还好，可以在个人电脑上作为临时热点；如果电脑(系统)不支持可能还需要在虚拟机里跑个 Ubuntu 去运行，或者使用额外的硬件如树莓派去执行代码，相比于前面的方法复杂度上升不少。另外使用路由抓包方法捕获到的流量是整个系统的流量，而不仅限于目标应用，因此我们还需要对这些流量进行额外的过滤。

虚拟网卡

路由抓包方案的目标是为了完全捕捉到目标应用流量，确保没有遗漏，另外还可以使用透明代理去实现 HTTP 请求的解析。这种方法的本质是在目标应用的路由中间节点进行网络劫持，其实要实现这个目标可以直接在应用端实现。

实现原理就是在本地运行一个虚拟专用网络，构建一个虚拟网卡设备，并将路由规则修改为优先通过我们虚拟的网卡进行请求。比如，Android 上可以通过实现 VPNService 去构建自己的 VPN 服务，ProxyDroid 就是其中的一个实现；在 macOS 或者 iOS 中可以使用 Surge 等工具去实现类似的功能。

将路由抓包在客户端上实现的一大好处是可以通过系统信息将网络请求与实际的进程相关联，同时省去了对额外设备的依赖；缺点则是比较依赖代理工具的工程实现，据我所知实现效果较好的工具其价格也不菲。当然这种抓包方式笔者使用得不多，如果有其他好的类似工具也欢迎留言分享一下。

libpcap

那位说了，既然都在端上抓包了，为什么不更直接一点，使用 tcpdump 或者 Wireshark 这类工具进行抓包？别急，这正是这一节要介绍的最后一种抓包方法。tcpdump 这类工具本质上是基于 libpcap 的，相信大家都比较熟悉了。

其实在前文中路由(网关)抓包和虚拟网卡抓包的方式中，都可以使用 tcpdump 进行抓包，前者需要指定网卡为热点网卡(AP)，后者指定为虚拟网卡(TUN)即可。这样抓包出来的结果是一个 pcap 文件，一般直接丢到 Wireshark 里面去进行分析。与前面的方法相比，这种方法对于 HTTP 的可视化解析可能相对简陋，但是对于协议类型的支持却非常广泛，基本上你能叫出名字的标准协议都可以进行解析。

因此，pcap 分析往往作为一种兜底的网络分析方式。而之所以很多情况下使用前面的方法而不是此法，是因为商业应用的大部分是 HTTP/HTTPS 流量，前面那些代理工具可以帮我们解决以很大部分的解密和可视化工作，即与下一节中提到的 TLS 解密方法相互权衡后所采用的决策。

这里分享一个 libpcap 的抓包技巧。笔者平时分析 Android 应用比较多，而在抓包时会发现有很多不相关的后台流量扰乱视听。实际上可以在 UID 为维度进行抓包，这样就可以只抓取对应应用的流量了。

这个功能称为 NFLOG，即 NetFilter Log。libpcap 在 1.2.1 版本之后支持抓取 nflog 的数据，而 iptables 又支持支持 uid 的过滤，二者相结合，比如要抓取 uid 为 1000 的应用数据，可以这样实现:

$ iptables -A OUTPUT -m owner --uid-owner 1000 -j CONNMARK --set-mark 1
$ iptables -A INPUT -m connmark --mark 1 -j NFLOG --nflog-group 30 
$ iptables -A OUTPUT -m connmark --mark 1 -j NFLOG --nflog-group 30 
$ tcpdump -i nflog:30 -w uid-1000.pcap

由于 uid 信息只关联在发送包上，因此只能添加到 OUTPUT 链上，但可以通过 connmark 去关联返回的数据，这样即可实现单个指定应用(uid)的的抓包了。

流量解密

上节中介绍了流量抓取的一些方案，对于常规 HTTP 流量而言没有太大争议，但是对于当今日趋普遍的 HTTPS 却有一些悬而未决的问题。如果我们抓到的所有 HTTPS 流量都是通过 TLS 进行加密的，那对于分析而言就几乎毫无价值了。

因此，为了能够对目标应用进行网络分析，应用层的私有加密姑且不论，至少要解决标准的 TLS 的解密问题。解密是为了中间人攻击，获取明文流量，那么就需要知道 TLS 中常规的中间人防御方案，一般来说，有下面几种:

客户端验证服务端的证书链可信，基本操作；
服务端验证客户端的证书可信(Certificate Request)，又称为双向证书绑定；
客户端验证服务端的证书 HASH 是否在白名单中，即 SSL Pinning；
……

在介绍后文的具体解密方案中也会围绕这几点去进行分析。

根证书

添加自定义的根证书应该是 HTTPS 流量分析的标准答案了。前文中提到的 Burpsuite、mitmproxy 等工具的文档中肯定都有介绍如何添加自定义根证书，根证书的存放对于不同的操作系统甚至不同的应用都有不同路径。比如在 Android 中，根证书存放在 /system/etc/security/cacerts 目录之下；在 iOS/macOS 中，根证书存放在 Keychain 中；对于 Firefox 浏览器，其应用中打包了证书链，不使用系统的证书。……

至于如何添加根证书，上过学的话应该都能在搜索引擎中找到方法，这里就不再啰嗦了。虽然添加自定义根证书可以让我们很方便地使用代理工具进行 HTTPS 流量分析，但其实际上只解决了第一个问题，因此对于某些做了额外校验的应用而言 TLS 握手还是无法成功的。

如果目标应用服务器在 TLS 握手中校验了客户端证书，那么我们还需要在代理工具中添加对应私钥才能顺利完成握手。该证书一般以 p12 格式存放，包含了客户端的证书及其私钥，通常还有一个额外的密码。通过逆向分析目标应用的的加载代码往往不难发现客户端证书的踪迹，甚至有时可以直接在资源文件中找到。

如果目标应用使用了 SSL Pinning 加固，那么通常是将服务器的证书 HASH 保存在代码中，并在握手之后进行额外校验。由于相关数据(证书HASH)和逻辑都在代码中，因此这种情况下往往只能通过侵入式的方式去绕过 Pinning 校验，比如 Patch 代码或者使用 hook 等方法实现。由于这是一个较为常见的功能，因此网上有很多相关脚本可以实现常规的 SSL Pinning bypass，但需要注意的是这并不意味着可以 100% 绕过，对于一些特殊实现仍然需要进行特殊分析。

SSL keylog

除了在端侧添加自定义根证书，还有一种方式可以解密 SSL/TLS 的流量，即在握手过程中想办法获取到 TLS 会话的 Master Key，根据协商的加密套件，就可以对整个 TLS stream 进行解密。关于 TLS 握手的原理介绍，可以参考笔者上一篇文章 —— 深入浅出 SSL/TLS 协议。

知名的抓包和网络协议分析工具 Wireshark 就支持通过添加 keylog 文件去辅助 TLS 流量的解密。这里的 keylog 就是 TLS 会话秘钥，文件格式为 NSS Key Log Format。对于不同版本的 TLS 内容略有不同，在 TLS 1.2 中只需要一个会话的 MasterKey，使用 CLIENT_RANDOM 去区分不同会话；而在 TLS 1.3 中每个会话包含 5 个秘钥，分别用于解密握手、数据阶段的不同数据。

那么，这个 keylog 文件我们应该如何获取呢？对于大部分 SSL 库而言，比如 OpenSSL、BoringSSL、libreSSL 等，都可以通过 SSL_CTX_set_keylog_callback 这个 API 去设置获取的回调，令 SSL 库在握手成功后调用对应的回调函数从而获取 keylog。因此我们就需要通过静态 patch 或者动态 hook 的方式去为 TLS 添加该回调。

这看似很简单，但实际操作起来会遇到一些问题。比如，很多大型商业应用都封装了自己的 SSL 库，甚至同一个应用中不同组件中又间接包含了有多个 SSL 库，为了每一个 TLS 会话都能成功解密，需要确保每个 SSL 库都要被正确 patch 或者 hook；

其次，对于某些组件而言，实际是通过静态编译的方式引入 SSL 库，比如 webview、libflutter、libffmpeg 等。在去除掉符号后，我们可能需要通过一些方法去搜索定位所需的符号地址。这个任务的难度可大可小，简单的可以通过 yara、Bindiff 去进行定位，复杂的话也可以通过一些深度学习算法去进行相似度分析，比如科恩的 BinaryAI 或者阿里云的 Finger 等。感兴趣的也可以去进一步阅读相关的综述文章:

USENIX Security 2022 - How Machine Learning Is Solving the Binary Function Similarity Problem

另外还有一个问题，SSL_CTX_set_keylog_callback 这个 API 并不是最初就存在于 SSL 库中的。以 openssl 为例，keylog 文件的支持实际上是在 commit 4bf73e 中才被引入。因此，如果遇到了某些应用中依赖于旧版本的 SSL 库，那么可能就不支持 keylog。我们要想强行支持就要进行二进制级别的 cherry-pick，这个工作量还是挺大的。

虽然有这些那些难点，但这种解密方法的一大优点是可以一次性解决本节开头所提及的三个问题，即服务端证书校验、客户端证书校验和 SSL Pinning。因为该方法并没有对流量进行网络层面的中间人，而是在应用的运行过程中泄露会话秘钥，因此不会影响上层的证书校验。

SSL read/write

既然设置 keylog 如此麻烦，为什么不找一些相对简单且通用的 API 去进行解密呢？一个直接的思路就是通过挂钩 SSL_read、SSL_write 来获取 SSL 读写的明文数据。基于这个思路目前网上有许多工程化的实现，比如 eCapture 是基于 eBPF/uprobes 的 TLS 抓包方案；r0capture 则是基于 frida 注入的 TLS 抓包方案。

使用该方法进行解密的一大优点，或者说特点，是这种方式可以在解密的同时直接输出明文信息，因此可以完全略过流量抓取这一步。虽然许多开源工具是将结果保存为 pcap 文件进行进一步分析的，但实际上也可以直接在标准输出或者日志文件中打印出来进行分析。

由于这些抓包工具本质上都是在获取 SSL read/write 明文的基础上再以 pcap 格式进行转储，因此同样会面临 keylog 方案所面临的问题，即依赖 SSL 库的符号。但不同的是其所依赖的是较为通用的符号，因此不太会受到 SSL 库版本的限制。唯一需要考虑的难题是如何解析无符号的 SSL 库中相关函数的偏移地址，这在上节中有些简单介绍，展开的话又是另一篇论文了。

小结

上述介绍的每一种流量抓取方法都可以和任意一种流量解密方法相结合，组成一种网络流量分析方案。实践上使用较多的是下面几种组合:

系统 HTTP 代理 + 根证书
路由抓包/透明代理 + 根证书
tcpdump + keylog
SSL_read/SSL_write hook

每种方案都有其优点和缺点:

抓包方案	优点	缺点
系统代理	配置简单，工具成熟	可被忽略，流量不全，证书问题
路由抓包	流量完整，应用透明	配置复杂，协议受限，证书问题
tcpdump + keylog	流量完整，无需证书协议丰富，应用过滤	TLS 解密需要 hook 应用且依赖于 SSL 库的版本和符号
SSL read/write	劫持简单，无需证书	需要(某些)符号，依赖 hook，流量不全

那么实际安全分析中要如何选择呢？正如那句老话所说: 网络安全没有银弹，实际情况也无法一概而论，通常是根据具体的目标去进行分析。

例如，对于操作系统比较封闭的 IoT 设备，通过路由抓包是唯一选择；对于移动应用或者桌面应用而言，可以先尝试传统的系统代理方式，添加对应根证书，如果不能抓到包，可以通过流量分析可能的问题:

流量日志中服务端有 Certificate Request 则表示进行了客户端证书校验；
流量日志中握手成功但很快断开，则客户端中可能使用了 SSL Pinning 加固；
流量日志中客户端握手失败，Alert 提示证书不可信，则说明客户端使用了自定义的 keystore 而不是系统的根证书；
……

此时如果发现客户端使用了多种方法防止 HTTP 代理进行中间人抓包，那么就可以尝试使用 keylog 或者 SSL read/write hook 的方式进行分析。总而言之，流量层的分析可以确保数据的完备性，即应用发送的请求都能够确保抓到；而 HTTP 代理和部分解密方法对于 Web 流量则更具针对性，在不同的场景中可以对不同分析方案进行灵活切换。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/05/22/network-analysis/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

深入浅出 SSL/TLS 协议

Sun, 15 May 2022 12:40:00 +0800

有没有那么一个人，几乎每天都在你身边，但某天发生一些事情后你会突然发现，自己完全不了解对方。对于笔者而言，这个人就是 TLS，虽然每天都会用到，却并不十分清楚其中的猫腻。因此在碰壁多次后，终于决定认真学习一下 TLS，同时还是奉行 Learning by Teaching 的原则，因此也就有了这篇稍显啰嗦的文章。

前言

关于 SSL/TLS 和 HTTPS 这些基本概念也就不多废话了，相信看笔者文章的朋友都有一定基础，因此本文的重点主要放在其中的握手流程。下文分别以目前最为常用的 TLS1.2 和 TLS1.3 协议分别进行分析，涉及到对称加密和椭圆曲线加密的相关介绍可以参考之前的一些文章，比如:

对称加密与攻击案例分析
椭圆曲线加密与NSA后门考古
Elliptic Curve Cryptography: a gentle introduction (强烈推荐这篇)

TLS 1.2

在深入握手细节之前我们可以先抓一个 HTTPS 的包去对整个握手流程有个大致感受，如下所示:

其中绿色部分是为了便于理解已经解密了的 http-over-tls 明文。从上面的数据包中我们可以得到一些初步印象:

从握手开始，到发送第一个数据包之前，客户端与服务端之间经历了 5 次传输；
每次传输中带有一个或者多个数据包；

这里的数据包称为 TLS Record，每个 Record 都是典型的 TLV (Type-Length-Value) 结构，而其中 Value 的具体类型又与 Record 的类型有关。

Record 的结构如下:

struct {
    uint8 major;
    uint8 minor;
} ProtocolVersion;

enum {
    change_cipher_spec(20), alert(21), handshake(22),
    application_data(23), (255)
} ContentType;

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

在实际的网络传输中，一个 Record 可以分割为多个 Fragment，每个 Fragment 的大小最多不超过 2^14 = 16384，而 Record 的 length 字段为 uint16，最大可以到 65535 字节。之所以这么设计是因为对于加密的数据，解密方需要收到整个 Record 才能开始解密，太大会影响解密性能，从而增加交互延时。

从上述定义可以看到 Record 的前两字节是用于定义协议版本，但是从上图我们发现 TLS 1.2 对应的版本为 0303，这乍看起来有点别扭，但其实是历史发展的结果。历史上 TLS 由 SSL 进化而来，通常也统称为 SSL/TLS，因此版本对应关系分别是:

SSL 3.0 -> 0300
TLS 1.0 -> 0301
TLS 1.1 -> 0302
TLS 1.2 -> 0303
TLS 1.3 -> 0304
…

只需要记住这个版本号即可，并不是很重要。后文也会将 SSL、TLS、SSL/TLS 混用，如无特殊说明，都是指代当前分析的 TLS 协议。

另外值得一提的是 Record 类型，在 TLS 1.2 中主要有 4 个，基本上都出现在上述 Wireshark 截图里了。其中在实际传输明文(HTTP)数据之前的大部分 Record 都是 handshake 类型的子类型，但 change_cipher_spec 却是一个单独的 Record 类型，并不属于 handshake，这点后面也会提到。

下面，我们就来开始分析 TLS 握手的具体实现。

注: 下文中所使用到的公、私钥以及相关工具都来源于以下的仓库，并且相关介绍也参考了其中的流程，因此感兴趣的可以直接通过原文去进行学习:

Client Hello

在 TLS 握手中，总是以客户端的 ClientHello 为起始，就像 TCP 握手总是以 SYN 为起始一样，告诉服务器我们想建立一个 TLS 链接。在 ClientHello 请求的结构如下:

struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-2>;
    CompressionMethod compression_methods<1..2^8-1>;
    select (extensions_present) {
        case false:
            struct {};
        case true:
            Extension extensions<0..2^16-1>;
    };
} ClientHello;

client_version 指客户端版本，值为 0x0303，表示 TLS 1.2，前面已经说过。值得一提的是该值与 Record 中的版本不一定一致，后者由于兼容性的原因通常会设置为一个较旧的版本(比如 TLS 1.0)，服务端应当以 ClientHello 中指定的版本为准。

random 是客户端本地生成的 32 字节 随机数，在 RFC5246 中提到随机数的前四字节应该是客户端的本地时间戳，但后来发现这样会存在针对客户端或者服务端的设备指纹标记，因此已经不建议使用时间戳了。为方便后续计算，这里将该随机数固定为:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

session_id 主要用于恢复加密链接，需要客户端和服务端同时支持。由于秘钥协商的过程中涉及到很多费时的操作，对于短链接而言将之前协商好的加密通道恢复可以大大减少运算资源。如果服务器支持恢复会话，那么后续可以直接进入加密通信，否则还是需要进行完整的握手协商。该字段的长度是可变的，占 1 字节，也就是说数据部分最多可以长达 255 字节。

cipher_suites 表示客户端所支持的加密套件，带有 2 字节长度字段，每个加密套件用 2 字节表示，且优先级高的排在前面。使用 openssl 可以查看实现的加密套件列表，如下所示:

$ openssl ciphers -V | column -t
0x13,0x02  -  TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any       Au=any    Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any       Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0x13,0x01  -  TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any       Au=any    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH      Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH      Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH        Au=RSA    Enc=AESGCM(256)             Mac=AEAD
...

每个加密套件包含一个秘钥交换算法、一个认证算法、一个对称加密算法和一个用于完整性校验的 MAC 算法。例如后文中协商出的加密套件 0xC0,0x13 表示 ECDHE-RSA-AES128-SHA。

compression_methods 表示客户端所支持的一系列压缩算法。数据需要先压缩后加密，因为加密后的数据通常很难压缩。但是压缩的数据在加密中会受到类似 CRIME 攻击的影响，所以当前几乎所有的实现都默认禁用了压缩，而且在新版本的 TLS 中也将压缩的特性移除了。

extensions 是 TLS 具备拓展性的一个功能，用于告知服务端一些额外的信息或者启用某些新的特性。比如客户端所支持的 TLS 版本列表，支持的椭圆曲线种类，支持的签名算法等。其中一个常用的拓展为 SNI(Server Name Indication)，包含了服务器的明文域名，主要用于后端服务器的反向代理。

Server Hello

服务器在收到 ClientHello 后必须回应 ServerHello 进行下一步握手协商，否则就需要回复 Alert 类型的 Record 告诉客户端中断握手并关闭连接。

ServerHello 的类型和 ClientHello 基本一致，差别在于回应的 cipher_suite 和 compression_method 是选择后的固定值，而不是列表。另外需要注意的是服务端返回的 ServerHello 中的拓展必须是客户端中所提供的拓展。假设服务端返回的 cipher_suite 为 0x0c13 (ECDHE-RSA-AES128-SHA)，返回的随机数为:

70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f

Server Certificate

随后服务端接着返回自身的证书信息，X509 格式，使用 ASN.1 DER 编码。通常服务器会返回多个证书，因为当前域名往往不是由根证书直接签名的，而是使用由于根证书所签名的次级证书去签发具体域名的证书。

如果使用了多级证书，那么返回的证书列表中第一个必须是对应域名的证书，而后每个证书都是前一个证书的 issuer，且最后一个证书是由系统中某个根证书签发的，注意根证书本身并不会一起返回。

以 baidu.com 为例，实际返回的证书列表如下:

$ openssl s_client -connect baidu.com:443
CONNECTED(00000006)
...
---
Certificate chain
 0 s:/C=CN/ST=Beijing/O=BeiJing Baidu Netcom Science Technology Co., Ltd/CN=www.baidu.cn
   i:/C=US/O=DigiCert Inc/CN=DigiCert Secure Site Pro CN CA G3
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Secure Site Pro CN CA G3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---

实际返回了两个证书，最后一个证书由 DigiCert Global Root CA 签发。如果服务端需要校验客户端证书的话，随后会发送一个 Certificate Request 请求，然后客户端返回对应的 Client Certificate 进行一轮额外的信息交换，当然这一步是可选的。

Server Key Exchange

服务器会在 server Certificate 消息之后发送 Server Key Exchange 消息，提供用于 ECDH 秘钥交换的信息。

关于 ECDH 的原理可以阅读文章开头的参考文章，简单来说，ECDH 可以在通信媒介不可信的情况下安全地完成秘钥交换。假设 A、B 双方的公私钥分别是 PA、SA，PB、SB，那么有:

PA * SB == PB * SA

双方只需要知道对方的公钥，可以在不暴露私钥的情况下实现信息的交换，防止中间人攻击，所交换的信息就是后续使用的对称加密秘钥。

更进一步，为了避免未来私钥泄露导致以前的通信被解密，通常交换时并不直接使用原始公私钥，而是一个随机生成的新公私钥对，只需要用原始私钥进行认证。这种交换方式也称为 ECDHE，其中 E 表示 Ephemeral，而这种做法所带来的称为 Forward Security，即前向安全。

令服务端端选择的椭圆曲线为 x25519，那么首先需要生成一个临时私钥，长度为 32 字节，只要随机生成即可，这里假设为:

909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

那么对应的公钥则是:

9fd7ad6dcff4298dd3f96d5b1b2af910a0535b1488d7f8fabb349a982880b615

可以通过 openssl 计算得出:

$ openssl pkey -noout -text < server-ephemeral-private.key

X25519 Private-Key:
priv:
    90:91:92:93:94:95:96:97:98:99:9a:9b:9c:9d:9e:
    9f:a0:a1:a2:a3:a4:a5:a6:a7:a8:a9:aa:ab:ac:ad:
    ae:af
pub:
    9f:d7:ad:6d:cf:f4:29:8d:d3:f9:6d:5b:1b:2a:f9:
    10:a0:53:5b:14:88:d7:f8:fa:bb:34:9a:98:28:80:
    b6:15

Server Key Exchange 的消息格式如下所示:

struct {
select (KeyExchangeAlgorithm) {
    case dh_anon:
        ServerDHParams params;
    case dhe_dss:
    case dhe_rsa:
        ServerDHParams params;
        digitally-signed struct {
            opaque client_random[32];
            opaque server_random[32];
            ServerDHParams params;
        } signed_params;
    case rsa:
    case dh_dss:
    case dh_rsa:
        struct {} ;
        /* message is omitted for rsa, dh_dss, and dh_rsa */
    /* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;

不同的加密套件有不同的格式，由于我们的是 dhe_rsa，因此在消息中应当包含椭圆曲线参数，以及 ClientRandom+ServerRandom+参数 的签名信息。使用原始私钥来计算最终的签名信息:

$ cat client_random >> /tmp/compute
$ cat server_random >> /tmp/compute
# 03 -> named_curve; 001d -> curve x25519
$ echo -en '\x03\x00\x1d' >> /tmp/compute
$ echo -en '\x20' >> /tmp/compute # 临时私钥长度 32 字节
$ cat server-ephemeral-public.key >> /tmp/compute # 上述生成的临时公钥
$ openssl dgst -sign server.key -sha256 /tmp/compute | hexdump
0000000 04 02 b6 61 f7 c1 91 ee 59 be 45 37 66 39 bd c3
... snip ...
00000f0 7d 87 dc 33 18 64 35 71 22 6c 4d d2 c2 ac 41 fb

Server Hello Done

服务端表示自己这一边的握手已经完成，接下来就等待客户端计算相关握手信息了。

Client Key Exchange

客户端收到 ClientKeyExchange 后，得知服务器选择了 x25519 曲线，那么也类似的生成响应临时秘钥。随机生成 32 字节私钥:

202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

对应的公钥计算方法与 Server Key Exchange 中介绍的一样:

358072d6365880d1aeea329adf9121383851ed21a28e3b75e965d0d2cd166254

Client Key Exchange 的数据格式如下:

struct {
    select (KeyExchangeAlgorithm) {
        case rsa:
            EncryptedPreMasterSecret;
        case dhe_dss:
        case dhe_rsa:
        case dh_dss:
        case dh_rsa:
        case dh_anon:
            ClientDiffieHellmanPublic;
    } exchange_keys;
} ClientKeyExchange;

其格式相对简单，对于我们选择的加密套件而言只需要包含临时生成的 ECDH 公钥。注意此处与 Server Key Exchange 不同，并没有对客户端的公钥进行签名，也就是说可以被中间人进行替换。不过协议设计的时候已经考虑到了这一点，因为此时双方已经有足够的信息去协商秘钥并且进行验证了，通过后文的计算过程也可以确认这一点。

Client Change Cipher Spec

该数据包告诉服务器客户端已经计算好了共享秘钥，并且后续客户端发送给服务器的数据都将使用共享秘钥进行加密。在下一个版本的 TLS 中该数据包类型将会被移除，因为加密数据是可以通过数据类型推断的。

那么，客户端是如何计算出共享秘钥的呢？目前客户端所已知的数据为:

client_random
server_random
server-ephemeral-public.key
client-ephemeral-private.key

首先根据前文对 ECDH 的介绍，通过对方的公钥和自己的私钥，可以计算出一个共同秘钥，这里称之为 PMS(Pre-Master-Secret)，具体计算方法可以参考curve25519-mult.c:

$ gcc -o curve25519-mult curve25519-mult.c
$ ./curve25519-mult client-ephemeral-private.key \
                    server-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

实际上服务端计算出的共享秘钥也是一样的:

$ ./curve25519-mult server-ephemeral-private.key \
                    client-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

该共享秘钥计算过程只涉及自身私钥和对方的公钥，为了进一步将共享秘钥关联当当前会话中，需要为其加入双方的随机数，当然不能直接相加，需要增加随机性，因此使用到了一个伪随机函数，称为 PRF(pseudorandom function)。其计算方式如下:

seed = "master secret" + client_random + server_random
a0 = seed
a1 = HMAC-SHA256(key=PreMasterSecret, data=a0)
a2 = HMAC-SHA256(key=PreMasterSecret, data=a1)
p1 = HMAC-SHA256(key=PreMasterSecret, data=a1 + seed)
p2 = HMAC-SHA256(key=PreMasterSecret, data=a2 + seed)
MasterSecret = p1[all 32 bytes] + p2[first 16 bytes]

所得到的的 48 字节拓展秘钥称为主密钥(Master Secret)，其值为:

916abf9da55973e13614ae0a3f5d3f37b023ba129aee02cc9134338127cd7049781c8e19fc1eb2a7387ac06ae237344c

最后，我们需要将该主密钥进行拓展(至任意长度)，并将结果的不同部分分别用作不同秘钥，如下所示:

seed = "key expansion" + server_random + client_random
a0 = seed
a1 = HMAC-SHA256(key=MasterSecret, data=a0)
a2 = HMAC-SHA256(key=MasterSecret, data=a1)
a3 = HMAC-SHA256(key=MasterSecret, data=a2)
a4 = ...
p1 = HMAC-SHA256(key=MasterSecret, data=a1 + seed)
p2 = HMAC-SHA256(key=MasterSecret, data=a2 + seed)
p3 = HMAC-SHA256(key=MasterSecret, data=a3 + seed)
p4 = ...
p = p1 + p2 + p3 + p4 ...
client write mac key = [first 20 bytes of p]
server write mac key = [next 20 bytes of p]
client write key = [next 16 bytes of p]
server write key = [next 16 bytes of p]
client write IV = [next 16 bytes of p]
server write IV = [next 16 bytes of p]

最终秘钥分成了 6 个部分，分别是客户端和服务端的 MAC 秘钥、数据加密秘钥和初始向量。这里涉及到几个有趣的问题，比如:

为什么客户端和服务端要使用不同的数据加密秘钥？
为什么客户端和服务端要使用不同的 MAC 秘钥？
为什么要单独指定 IV？

根据 RFC5246 中的介绍，使用不同的 MAC 秘钥是为了防止来自一方的数据被注入到另一方中；对于使用流密钥加密的情况，客户端和服务端使用不同的秘钥也能防止秘钥重用攻击。

在 TLS 1.0 中的 CBC 使用了前一部分 Record 的数据作为 IV 导致了选择明文攻击 (chosen plaintext attack)，因此这在新版本中的 TLS 协议明确指定了 IV 的生成方法。注意这个 IV 只有部分需要额外指定 IV 的 AEAD 算法会用到。

总而言之，通过 ECDHE 秘钥交换，客户端计算出了下述秘钥:

client MAC key: 1b7d117c7d5f690bc263cae8ef60af0f1878acc2
server MAC key: 2ad8bdd8c601a617126f63540eb20906f781fad2
client write key: f656d037b173ef3e11169f27231a84b6
server write key: 752a18e7a9fcb7cbcdd8f98dd8f769eb
client write IV: a0d2550c9238eebfef5c32251abb67d6
server write IV: 434528db4937d540d393135e06a11bb8

PS: ChangeCipherSpec 消息并不是 Handshake(22) 消息的子结构，而是一个单独的消息，与 Handshake 并列，类型为 20。这是为了解决握手期间管道阻塞的问题。

Client Handshake Finished

该数据包告诉服务器，客户端的握手流程也已经完成。同时，还携带了一部分加密数据，所加密的内容称为 Verify Data，用以验证握手成功且没有被中间人修改过。

Verify Data 的内容是该消息之前的所有握手包的 HASH 经过 HMAC 计算出来的一个 12 字节数据，其计算方法为:

seed = "client finished" + SHA256(all handshake messages)
a0 = seed
a1 = HMAC-SHA256(key=MasterSecret, data=a0)
p1 = HMAC-SHA256(key=MasterSecret, data=a1 + seed)
verify_data = p1[first 12 bytes]

在示例数据包中，verify_data 值为 cf919626f1360c536aaad73a，使用 client_write_key 进行加密，服务端收到后使用对应的秘钥进行解密，所使用加解密算法由之前协商的加密套件决定，这里是 aes-128-cbc。

Server Change Cipher Spec

服务端收到上述加密后的数据为(Record Body):

404142434445464748494a4b4c4d4e4f
227bc9ba81ef30f2a8a78ff1df50844d
5804b7eeb2e214c32b6892aca3db7b78
077fdd90067c516bacb3ba90dedf720f

为了进行验证，服务端使用相同的方式计算出共享秘钥 Pre Master Secret，由 ECDH 的特性以及前文的计算可以看到，服务端和客户端计算出的 PMS 是相同的，因衍生出来的对称加密秘钥、IV、MAC 秘钥也是相同的。

故，服务端收到加密数据后，可以使用协商出来的 client_write_key 对其进行解密:

hexdata=227bc9ba81ef30f2a8a78ff1df50844d5804b7eeb2e214c32b6892aca3db7b78077fdd90067c516bacb3ba90dedf720f
# client write key
hexkey=f656d037b173ef3e11169f27231a84b6
# record iv，保存在加密数据之前
hexiv=404142434445464748494a4b4c4d4e4f

$ echo -n $hexdata | xxd -r -p | openssl enc -d -nopad -aes-128-cbc -K $hexkey -iv $hexiv | rax2 -S
1400000ccf919626f1360c536aaad73a
a5a03d233056e4ac6eba7fd9e5317fac
2db5b70e0b0b0b0b0b0b0b0b0b0b0b0b

值得注意的是这里使用的 key 是协商的 client_write_key，但 IV 并不是 client_write_iv，而是一个随机生成的针对当前 Record 的 IV，并且附加到加密数据的前方。

在解密后的数据中， 1400000c 是 Record 的子协议头部，对应 Handshake/Finish，长度 0x0c 即 12 字节，数据正好是前面计算出的 verify_data 的值，即 cf919626f1360c536aaad73a。

末尾还有 32 字节的数据，是使用 client mac key 计算的签名，用于确保所接收数据的完整性，计算方法为:

### from https://tools.ietf.org/html/rfc2246#section-6.2.3.1
$ sequence='0000000000000000'
$ rechdr='16 03 03'
$ datalen='00 10'
$ data='14 00 00 0c cf 91 96 26 f1 36 0c 53 6a aa d7 3a'
### client MAC key
$ mackey=1b7d117c7d5f690bc263cae8ef60af0f1878acc2
$ echo $sequence $rechdr $datalen $data | xxd -r -p \
  | openssl dgst -sha1 -mac HMAC -macopt hexkey:$mackey

a5a03d233056e4ac6eba7fd9e5317fac2db5b70e

再使用 PKCS#5 填充至 32 字节即为末尾添加的数据。服务端通过将客户端发送的 verify_data 与自身计算的值进行比对，可确保整个握手流程的完整性；使用 HMAC 校验当前数据可以保证消息没有被中间人篡改。

在这些校验都完成后，服务端给客户端返回 Change Cipher Spec 消息，告知客户端接下来发送的数据都将经过协商秘钥进行加密。当然，和前文一样，其实这条消息是多余的，在 TLS 1.3 中已经被移除了。

Server Handshake Finished

此时，服务端已经完成了握手的所有流程，并且也确认这个握手流程没有被中间人篡改，但是客户端还不知道啊！因此，类似于 Client Handshake Finished，服务端也要发送一个加密并验签的数据给客户端，让客户端进行验证并确认整个握手流程的正确性。

发送的数据格式和 Client Finished 几乎一样，只有几点小差异。比如数据使用 server_write_key 进行加密(而不是 client_write_key)，HMAC key 也是类似。另外计算 verify_data 与前者相比还多了一个 Client Finished 消息，毕竟协议中说的是用于验证 “当前消息前的所有握手消息”。

客户端收到 Server Finished 后，同样进行解密并校验 HMAC，如果确认无误就可以开始发送应用数据了。

注: ChangeCipherSpec、Alert 以及其他非 Handshake 的消息都不参与 verify_data 的计算，另外根据 RFC 的规定，HelloRequest 请求也不参与哈希计算。

Application Data

Application Data 是一个单独类型的 Record (type=23)，准确来说已经不属于握手阶段了，不过这里还是提一下。

该消息格式中主要是使用协商秘钥加密的应用数据，客户端发送的数据使用 client write key 进行加密，服务端返回的数据使用 server write key 进行加密，并且明文数据末尾还加了 HMAC 校验数据，使用对应的 MAC key 进行签名，加解密和签名过程和 Client/Server Finished 消息的过程一致。因此每条应用数据都可以保证机密性和完整性。

在新版本的 Wireshark 中，TLS 流量可以通过指定 keylog 文件进行解密，许多应用如 curl、Chrome 都可以通过指定 SSLKEYLOGFILE 环境变量指定 keylog 的位置，例如:

$ SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt curl https://example.com
$ cat ~/SSLKEYLOGFILE.txt
CLIENT_RANDOM 54BA544490B18D32B4725E40493A0839CA64AACE14A3E119C0658C49E12A998C EA6B59F06F9E2C219535A02C31FEDBE60053E235A91FC36701B2871477C18E99CE6F2F33144EB6FC28031BB7D51BEF00

keylog 文件的格式为 NSS Key Log Format，上述输出是针对 TLS 1.2 的会话秘钥，第一部分为客户端随机数，用于与具体的 TLS 流进行对应；第二部分则是 48 字节的 Pre Master Secret 值。根据我们前面的分析，通过该秘钥可以获取到双方的对称加密秘钥，因此就可以解密对应的 TLS 数据了。

TLS 1.3

由于 TLS 1.3 是在 TLS 1.2 的基础上优化而来的，因此对于与上节实现相同的部分就不再详细介绍了，而只关注其中不同的部分。

总体来看，TLS 1.3 与 TLS 1.2 相比，较大的差异有下面这些:

去除了一大堆过时的对称加密算法，只留下较为安全的 AEAD (Authenticated Encryption with Associated Data) 算法；加密套件(cipher suite) 的概念被修改为单独的认证、秘钥交换算法以及秘钥拓展和 MAC 用到的哈希算法；
去除了静态 RSA 和秘钥交换算法套件，使目前所有基于公钥的交换算法都能保证前向安全；
引入了 0-RTT(round-trip time) 的模式，减少握手的消息往返次数；
ServerHello 之后所有的握手消息都进行了加密；
修改了秘钥拓展算法，称为 HKDF (HMAC-based Extract-and-Expand Key Derivation Function)；
废弃了 TLS 1.2 中的协议版本协商方法，改为使用 Extension 实现；
TLS 1.2 中的会话恢复功能现在采用了新的 PSK 交换实现；
……

下面就以一个完整的握手流程去分析这之中的差异，所使用的秘钥和数据包可以在下面的链接中找到:

Client Hello

与 TLS 1.2 一样，握手总是以 Client 发送 Hello 请求开始。但正如本节开头所说，TLS 握手时的协议协商不再使用 Handshake/Hello 中的 version 字段，虽然是 1.3 版本，但请求中 version 还是指定 1.2 版本，这是因为有许多 web 中间件在设计时候会忽略不认识的 TLS 版本号，因此为了兼容性，版本号依旧保持不变。实际协商 TLS 版本是使用的是 Supported Versions 拓展实现的。

client_random 是客户端生成的随机数，这里是:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

session_id 字段在此前的版本中该字段被用于恢复 TLS 会话，不过在 TLS 1.3 中会话恢复使用了一种更为灵活的 PSK 秘钥交换方式，因此这个字段在 TLS 1.3 中是没有实际作用的。

在 Client Hello 消息中，有一个重要的拓展，即 Key Share，用于与服务器交换秘钥。前文说到在 TLS 1.3 中，Server Hello 之后的所有消息都是加密的，为了双方能够正确加解密数据，因此在 Client Hello 中通过该拓展告诉服务端自己的公钥以及秘钥交换算法。

这里客户端还是指定了 x25519 椭圆曲线加密，并且生成一个临时私钥:

202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

对应的公钥计算方法前文已经说过，这里再重复一遍:

$ openssl pkey -noout -text < client-ephemeral-private.key

X25519 Private-Key:
priv:
    20:21:22:23:24:25:26:27:28:29:2a:2b:2c:2d:2e:
    2f:30:31:32:33:34:35:36:37:38:39:3a:3b:3c:3d:
    3e:3f
pub:
    35:80:72:d6:36:58:80:d1:ae:ea:32:9a:df:91:21:
    38:38:51:ed:21:a2:8e:3b:75:e9:65:d0:d2:cd:16:
    62:54

随后，该公钥就随着 Client Hello 发送给了服务端。

Server Hello

服务端根据客户端提供的选项，选择一个好自己支持的 TLS 版本以及加密套件，这里选的是 TLS_AES_256_GCM_SHA384，返回的 server_random 为:

70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f

由于涉及到了秘钥交换，服务端在收到请求后也需要先生成一对临时公私钥，所生成的私钥为:

909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

对应的公钥是:

9fd7ad6dcff4298dd3f96d5b1b2af910a0535b1488d7f8fabb349a982880b615

Key Share Extension 中返回的即为上述公钥。如果还记得上文的 ECDH 秘钥交换方法，这里就可以很容易计算出两端的共享秘钥:

$ ./curve25519-mult server-ephemeral-private.key \
                    client-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

该秘钥用于生成后续握手包所需的秘钥，使用 HKDF 函数进行生成，如下所示:

early_secret = HKDF-Extract(salt: 00, key: 00...)
empty_hash = SHA384("")
derived_secret = HKDF-Expand-Label(key: early_secret, label: "derived", ctx: empty_hash, len: 48)
handshake_secret = HKDF-Extract(salt: derived_secret, key: shared_secret)
client_secret = HKDF-Expand-Label(key: handshake_secret, label: "c hs traffic", ctx: hello_hash, len: 48)
server_secret = HKDF-Expand-Label(key: handshake_secret, label: "s hs traffic", ctx: hello_hash, len: 48)
client_handshake_key = HKDF-Expand-Label(key: client_secret, label: "key", ctx: "", len: 32)
server_handshake_key = HKDF-Expand-Label(key: server_secret, label: "key", ctx: "", len: 32)
client_handshake_iv = HKDF-Expand-Label(key: client_secret, label: "iv", ctx: "", len: 12)
server_handshake_iv = HKDF-Expand-Label(key: server_secret, label: "iv", ctx: "", len: 12)

得到以下秘钥:

handshake secret: bdbbe8757494bef20de932598294ea65b5e6bf6dc5c02a960a2de2eaa9b07c929078d2caa0936231c38d1725f179d299
server handshake traffic secret: 23323da031634b241dd37d61032b62a4f450584d1f7f47983ba2f7cc0cdcc39a68f481f2b019f9403a3051908a5d1622.
client handshake traffic secret: db89d2d6df0e84fed74a2288f8fd4d0959f790ff23946cdf4c26d85e51bebd42ae184501972f8d30c4a3e4a3693d0ef0.
server handshake key: 9f13575ce3f8cfc1df64a77ceaffe89700b492ad31b4fab01c4792be1b266b7f
server handshake IV: 9563bc8b590f671f488d2da3
client handshake key: 1135b4826a9a70257e5a391ad93093dfd7c4214812f493b3e3daae1eb2b1ac69
client handshake IV: 4256d2e0e88babdd05eb2f27

客户端也可以计算出同样的秘钥值。

Server Encrypted Extensions

在计算完共享秘钥后，后续的流量将使用上述秘钥进行加密，因此对于 TLS 1.2 的情况服务端会先返回一个 ChangeCipherSpec，在 TLS 1.3 中可不必多此一举，不过在兼容模式下为了防止某些中间件抽风还是会多这么一步。

我们这里直接看加密的数据，服务端一般会先返回一个 Encrypted Extensions 类型的 Record 消息，该消息加密后存放在 Record(type=0x17)，即 Application Data 的 Body 部分，同时(加密后数据的)末尾还添加了 16 字节的 Auth Tag，这是 AEAD 算法用来校验加密消息完整性的数据。

数据使用 AES-256-GCM 进行加密和校验，解密代码可以参考 aes_256_gcm_decrypt.c，使用 server hanshake key/iv 进行解密的示例如下所示:

# server handshake key
$ key=9f13575ce3f8cfc1df64a77ceaffe89700b492ad31b4fab01c4792be1b266b7f
# server handshake iv
$ iv=9563bc8b590f671f488d2da3
### from this record
$ recdata=1703030017
$ authtag=9ddef56f2468b90adfa25101ab0344ae
$ recordnum=0
### may need to add -I and -L flags for include and lib dirs
$ cc -o aes_256_gcm_decrypt aes_256_gcm_decrypt.c -lssl -lcrypto
$ echo "6b e0 2f 9d a7 c2 dc" | xxd -r -p > /tmp/msg1
$ cat /tmp/msg1 \
  | ./aes_256_gcm_decrypt $iv $recordnum $key $recdata $authtag \
  | hexdump -C

00000000  08 00 00 02 00 00 16                              |.......|

这里解密后的拓展长度为空。一般与握手无关的额外拓展都会放在这里返回，这是为了能够尽可能地减少握手阶段的明文传输。

注: 如无特殊说明，后续的握手包都是使用相同方法进行加密的，并且只针对解密后的原数据进行分析。

Server Certificate

使用 server handshake key/iv 进行加密。解密后的数据与 TLS 1.2 的证书响应相同，因此不再赘述。

Server Certificate Verify

前文 Hello 阶段进行 ECDHE 秘钥交换的时候其实有个问题，即双方只交换了公钥，却没有认证这个秘钥，因此如果存在网络劫持，就可能被中间人进行攻击，那加密似乎也只是加了个寂寞。

但无需担心，这点早已在计划之中。虽然之前没有进行认证，但可以后面补上。Server Certificate Verify 就是这个作用。该消息将服务端证书的私钥与之前生成的临时公钥进行绑定，准确来说是使用证书的私钥对其进行签名，并将签名算法与结果返回给客户端。由于客户端可以认证证书的有消息，就间接地证实了之前所交换的秘钥的真实性。

struct {
    SignatureScheme algorithm;
    opaque signature<0..2^16-1>;
} CertificateVerify;

同理，如果服务端需要验证客户端的真实性，那么在提供客户端证书后也同样发送一个 Certificate Verify 消息即可。

Server Handshake Finished

至此服务端所需要发送的握手包已经发送完毕了，因此最后发送一个 Finished 数据给客户端并等待对方的握手完成。在 Finished 数据中，消息体的内容和 TLS 1.2 类似，是通过此前所有的握手数据计算得到的 verify_data，并使用 HMAC 进行认证，进一步确保此前的消息没有经过中间人修改。

计算方法如下:

finished_key = HKDF-Expand-Label(key: server_secret, label: "finished", ctx: "", len: 32)
finished_hash = SHA384(Client Hello ... Server Cert Verify)
verify_data = HMAC-SHA384(key: finished_key, msg: finished_hash)

server_secret 是指前文中协商得到的 server handshake traffic secret。

同时，服务端使用前面协商得到的 handshake secret 加上前面所有握手包的哈希重新计算出一个应用秘钥，用于加密实际的应用数据。计算方法如下:

empty_hash = SHA384("")
derived_secret = HKDF-Expand-Label(key: handshake_secret, label: "derived", ctx: empty_hash, len: 48)
master_secret = HKDF-Extract(salt: derived_secret, key: 00...)
client_secret = HKDF-Expand-Label(key: master_secret, label: "c ap traffic", ctx: handshake_hash, len: 48)
server_secret = HKDF-Expand-Label(key: master_secret, label: "s ap traffic", ctx: handshake_hash, len: 48)
client_application_key = HKDF-Expand-Label(key: client_secret, label: "key", ctx: "", len: 32)
server_application_key = HKDF-Expand-Label(key: server_secret, label: "key", ctx: "", len: 32)
client_application_iv = HKDF-Expand-Label(key: client_secret, label: "iv", ctx: "", len: 12)
server_application_iv = HKDF-Expand-Label(key: server_secret, label: "iv", ctx: "", len: 12)

之所以重新计算而不是使用 handshake key 是为了防止针对某些加密套件可能存在的选择密文攻击。最终得到:

server application key: 01f78623f17e3edcc09e944027ba3218d57c8e0db93cd3ac419309274700ac27
server application IV: 196a750b0c5049c0cc51a541
client application key: de2f4c7672723a692319873e5c227606691a32d1c59d8b9f51dbb9352e9ca9cc
client application IV: bb007956f474b25de902432f

相当于 TLS 1.2 中的 client/server write key/IV。

Client Handshake Finished

由于双方的 handshake secret 相同，那么由此派生出来的 application key/iv 必然也是相同的。

客户端在收到 Server Finished 之后会使用对应服务器证书对数据进行校验，确认无误后进行可选的 ChangeCipherSpec 将加密并签名的 verify_data 在 Finished 请求中发送给服务器。

# client handshake traffic secret
finished_key = HKDF-Expand-Label(key: client_secret, label: "finished", ctx: "", len: 32)
finished_hash = SHA384(Client Hello ... Server Finished)
verify_data = HMAC-SHA384(key: finished_key, msg: finished_hash)

可以这么理解，Server Finished 用来让客户端确认服务端没有被中间人攻击，而 Client Finished 则用来让服务端确认客户端没有被中间人攻击。双向认证之后则可以保证 TLS 握手的真实性和完整性，成功建立加密信道。

Server Session Ticket

这一步通常是可选的。服务端在握手完成后会发送若干个 ticket 给客户端，可以理解为 web 中的 cookie。客户端在后续如果需要重新发起握手，可以带上这个 ticket，用于恢复当前的 TLS 会话。从上面的握手流程可见 TLS 握手需要涉及许多计算和网络请求，如果能够恢复会话，将极大地降低云服务器资源和网络延时。

ticket 消息的格式如下:

struct {
    uint32 ticket_lifetime;
    uint32 ticket_age_add;
    opaque ticket_nonce<0..255>;
    opaque ticket<1..2^16-1>;
    Extension extensions<0..2^16-2>;
} NewSessionTicket;

包含有效期、随机数等信息。其中 ticket 字段对于客户端是透明的，但对于服务端而言需要是有效的会话凭据，可通过该数据恢复之前的 TLS 会话。

由于 ticket 是一次性的，综合考虑时间和空间成本，一般服务端都会返回两个 ticket 给客户端。由于是服务端返回的数据，因此使用 server application key/iv 进行加密。

Application Data

随后客户端发送的数据加密方式与 handshake 过程的加密类似，区别仅在于应用数据的加密使用的是 client application key/iv，服务端发送给客户端的数据使用 server application key/iv。

前文说到 Wireshark 支持导入 keylog 解密 TLS 1.2 流量，其实对于 TLS 1.3 也可以，但由于后者在 Server Hello 之后的握手包都经过了加密，因此要解密 TLS 1.3 数据流还分别需要握手阶段的秘钥。

以本节所涉及到的握手包为例，其 keylog 内容如下:

$ openssl s_client -keylogfile keylog.txt -connect example.com:443
$ cat keylog.txt
SERVER_HANDSHAKE_TRAFFIC_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 23323da031634b241dd37d61032b62a4f450584d1f7f47983ba2f7cc0cdcc39a68f481f2b019f9403a3051908a5d1622
CLIENT_HANDSHAKE_TRAFFIC_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f db89d2d6df0e84fed74a2288f8fd4d0959f790ff23946cdf4c26d85e51bebd42ae184501972f8d30c4a3e4a3693d0ef0
EXPORTER_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 5da16dd8325dd8279e4535363384d9ad0dbe370538fc3ad74e53d533b77ac35ee072d56c90871344e6857ccb2efc9e14
SERVER_TRAFFIC_SECRET_0 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 86c967fd7747a36a0685b4ed8d0e6b4c02b4ddaf3cd294aa44e9f6b0183bf911e89a189ba5dfd71fccffb5cc164901f8
CLIENT_TRAFFIC_SECRET_0 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 9e47af27cb60d818a9ea7d233cb5ed4cc525fcd74614fb24b0ee59acb8e5aa7ff8d88b89792114208fec291a6fa96bad

同一个 TLS 流中的 RANDOM 值相同，且都是 client_random，使用 Label 来区分不同阶段的秘钥。值得一提的是 macOS 中的 LibreSSL 还不支持 -keylogfile 选项，因此上面的命令是在 Linux 中进行测试的。

至此，TLS 1.2 和 TLS 1.3 的常规握手流程基本上也分析完了，当然在这其中还存在一些减少 RTT 的优化，篇幅原因就留到以后分析 mmtls 的时候再说了。

Android 证书 hash

还记得前文中介绍 Server Certificate 的时候，服务端返回一直到除了根证书以外的的证书链，那么从最后一个证书是如何定位到根证书的呢？一般认为是通过 issuer 字段，但 issuer 字段只是一段文字(ASN.1)，很可能会重复，这样岂不是有歧义？。其实分析 Android 的验证流程就可以知道。

了解 Android 应用安全的朋友应该都知道系统的根证书存放在 /system/etc/security/cacerts/ 之中，里面的证书都是 xxxx.0 格式，这是个传统的 PEM 格式证书，但名字比较特殊，使用 openssl x509 -subject_hash_old 生成。

通过阅读 AOSP 相关代码会发现，这个文件名的前半部分也正是证书的 subject 字段的 MD5，后半部分的 .0 则是为了防止哈希碰撞预留的计数字段，如果有重复就加一，相关代码如下:

// frameworks/base/core/java/android/security/net/config/DirectoryCertificateSource.java
private Set<X509Certificate> findCerts(X500Principal subj, CertSelector selector) {
    String hash = getHash(subj);
    Set<X509Certificate> certs = null;
    for (int index = 0; index >= 0; index++) {
        String fileName = hash + "." + index;
        if (!new File(mDir, fileName).exists()) {
            break;
        }
        if (isCertMarkedAsRemoved(fileName)) {
            continue;
        }
        X509Certificate cert = readCertificate(fileName);
        if (cert == null) {
            continue;
        }
        if (!subj.equals(cert.getSubjectX500Principal())) {
            continue;
        }
        if (selector.match(cert)) {
            if (certs == null) {
                certs = new ArraySet<X509Certificate>();
            }
            certs.add(cert);
        }
    }
    return certs != null ? certs : Collections.<X509Certificate>emptySet();
}

我们也可以通过以下 Python 脚本去进行手动计算:

from cryptography import x509
import hashlib
import struct

with open("01419da9.0", "rb") as f:
    pem = f.read()
cert = x509.load_pem_x509_certificate(pem)
d = hashlib.md5(cert.subject.public_bytes()).digest()
out = struct.unpack(", d[:4])[0]
print("hash: %08x" % out)
assert(out == 0x01419da9)

SSL Pinning

SSL Pinning 又称为 Certificate Pinning，通常翻译为证书绑定。但个人感觉这个翻译其实不太准确，因为绑定关系通常是双向的，而 Pinning 操作实质上只是客户端应用限制了本身所信任的 CA 范围，类似于图钉将某个证书固定到对应域名上。

在 Android 应用中可以通过 NSC(Network Security Config) 来设置证书绑定规则，例如:

res/xml/network_security_config.xml:



    
         includeSubdomains="true">evilpan.com
         expiration="2022-01-01">
             digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=
            
             digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=

由于证书有效期的问题，客户端应用如果无法及时升级，可能会导致服务端证书更新后无法正常进行 HTTPS 通信，因此 Google 是不推荐应用使用证书绑定的。如果一定要用的话，最好提供一个备用的可控 pin(比如自签名的证书)，用以保障通信的可用性。

当然不使用 NSC 也是可以实现证书绑定。因为本质上只是对服务端证书的单独比对，将 TLS 握手过程中获取的服务端证书或者其中的公钥与本地保存的值进行额外的校验。这个校验过程可以放在 Java 层，比如 okhttp 的 CertificatePinner，也可以放在 native 层，比如抖音的 libttboringssl.so，但这都是具体实现问题了。

值得一提的是在 TLS 的文档里并没有证书绑定这一概念，倒是有一个独立的 RFC7469 介绍针对 HTTP 协议的公钥拓展(Public Key Pinning)，使用约定的 HTTP 头来提供 TLS 证书公钥的 HASH，不过目前使用并不是很广泛。

后记

本文主要介绍了 TLS 1.2 和 TLS 1.3 的常规握手过程，分别参考了 RFC5246 和 RFC8446。虽然有很多细节还没有涉及到，但总的来说对 TLS 的理解又加深了一点，也算没浪费这个周末。后续有时间的话会总结一些在客户端安全研究时的网络分析方法，以及一些关于 TLS 的有趣特性，Stay Tune!

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/05/15/tls-basics/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.