34 lines
3.1 KiB
Markdown
34 lines
3.1 KiB
Markdown
### 如果多进程下，A 进程的 Source 触发到了 B 进程的 sink 点，如何溯源
|
||
|
||
**1. 识别并关联进程间通信（IPC）**
|
||
|
||
首先，你需要将进程 A 的 `source` 和进程 B 的 `sink` 关联起来
|
||
|
||
- **监控 IPC 调用**：在两个进程中，同时监控所有 IPC 相关的系统调用。在 Linux 上，这可能包括 `pipe()`, `socket()`, `shmget()`, `msgget()` 等。在 Windows 上，这可能是命名管道、共享内存的 API 调用
|
||
- **记录数据流**：不仅要记录 IPC 调用，还要记录通过 IPC 传递的**数据内容**。这是将 `source` 和 `sink` 联系起来的关键。例如，如果进程 A 通过管道写入了一个特定的恶意数据，你需要记录下这个数据，然后追踪它是否被进程 B 从管道中读出
|
||
- **使用动态分析工具**：利用动态分析工具来自动化这个过程
|
||
- **Frida/Ptrace**：你可以编写脚本，利用 Frida 或 Ptrace 这样的动态插桩框架，在两个进程中同时 Hook 所有 IPC 相关的函数
|
||
- **eBPF**：在 Linux 上，eBPF 是一个强大的工具。你可以编写 eBPF 程序，在内核层面监控所有进程间的通信，并记录下通信的数据和进程 ID。这比用户态 Hooking 更稳定、更难以被绕过
|
||
|
||
**2. 构建跨进程的控制流图**
|
||
|
||
传统的控制流图只在单个进程内工作。要解决多进程溯源问题，你需要构建一个**跨进程的、依赖于 IPC 事件的控制流图**
|
||
|
||
- **进程内 CFG**：首先，分别构建进程 A 和进程 B 的独立控制流图
|
||
- **跨进程边（Inter-Process Edges）**：在两个 CFG 之间，根据 IPC 事件添加“边”
|
||
- 当进程 A 执行 `write()` 系统调用时，在 CFG 中添加一条从该 `write()` 指令到进程 B 的 `read()` 系统调用的边。这条边代表了数据的流动
|
||
- 这条边需要包含**时间戳**和**数据内容**，以确保因果关系的正确性。
|
||
|
||
通过这种方式，你可以将 A 进程的 `source` 点和 B 进程的 `sink` 点在同一个图中连接起来，从而实现完整的溯源
|
||
|
||
**3. 自动化与工具支持**
|
||
|
||
手动进行上述分析几乎是不可能的。你需要依赖强大的自动化工具
|
||
|
||
- **进程监控工具**：
|
||
- **Linux**：`strace` 可以追踪系统调用。`ltrace` 可以追踪库函数调用。但它们只对单个进程有效，你需要同时对两个进程使用
|
||
- **Windows**：Sysinternals 的 `Procmon` 是一个强大的工具，可以记录所有进程的系统调用和文件/注册表操作
|
||
- **动态污点分析**：
|
||
- **Taint Analysis** 是一种强大的技术，它可以标记“不干净”（untainted）的数据，并追踪其在程序中的传播
|
||
- 你可以将进程 A 的 `source` 数据标记为“污点”。然后，追踪这个污点数据在进程 A 内的传播。当它通过 IPC 传递给进程 B 时，这个污点也会被传递过去。最终，如果污点数据到达了进程 B 的 `sink` 点，你就可以得到完整的溯源路径
|
||
- 这通常需要修改虚拟机监视器（VMM）或使用专门的动态分析框架来实现 |