Network - 标签 - 有价值炮灰

Dockerhub 镜像供应链攻击风险研究

Sun, 30 Nov 2025 12:40:00 +0800

一年多前，由于不知名的原因，国内访问 DockerHub（准确来说是 Docker Registry）被拦截，导致广大开发者在拉镜像的时候出现了莫名其妙的错误：

$ docker pull hello-world
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

其实封禁的第一时间我也看到了相关的新闻，只不过当时以为是特殊时期，没想到一转眼就是一年半：

故事由此展开。

Workaround

不能用就不用了吗？当然不可能，程序员还得继续上班。老板才不管你这那的，总之容器还是得起来。于是就有了各种各样的 “教学” 文章。比如：

简单来说，就是两种方法：

使用代理
使用镜像站

这里只做一个简单的总结。

Proxy

首先是使用代理的方式。docker 因为是 C-S 架构，实际负责工作的组件是后台进程 dockerd。我们前台调用的 docker 命令行工具作用仅仅是连接 docker.sock 然后按照协议给后台进程去发起请求并接受返回。因此给前台程序设置 HTTP_PROXY 等环境变量是没用的，同理使用 proxychains 等工具亦然。

因此要挂代理，就必须针对后台进程。对于 docker daemon 而言，设置代理同样只需要设置好环境变量。以 Linux 系统 systemctl 启动的后台进程为例：

直接编辑 /etc/systemd/system/docker.service.d/your-proxy.conf，写入以下内容：

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:8080"
Environment="HTTPS_PROXY=http://127.0.0.1:8080"
Environment="NO_PROXY=localhost,127.0.0.1"

conf 文件的名字不重要，只要在 docker.service.d 目录下即可。上面的配置表示添加三个环境变量，懂的都懂。

配置完后需要重启一下后台进程：

sudo systemctl daemon-reload
sudo systemctl restart docker

然后验证一下修改是否生效：

sudo systemctl show --property=Environment docker

镜像站

另外一种方法，就是使用所谓的镜像站。还是以 Linux systemctl 为例，要给 docker daemon 后台进程指定使用镜像，需要修改配置文件 /etc/docker/daemon.json 写入 registry-mirrors 属性，比如：

{
    "registry-mirrors": [
        "https://docker.1ms.run",
        "https://docker.xuanyuan.me"
    ]
}

保存之后同样重启后台进程即可：

sudo systemctl daemon-reload
sudo systemctl restart docker

热情的中国开发者们创建并分享了各种各样的镜像站，比如:

通常用户会随便选几个站直接粘贴到自己的配置文件中即可正常使用，当然我也是这样。

可每次用镜像站的时候我都在想，这些站点是否安全，如果站长故意作恶的话会不会把我给 RCE 了？也许有点杞人忧天，但是毕竟 “Only the Paranoid Survive”，我觉得深入想想也没什么不好。

攻击面分析

终于来到了本文的正题。其实问题很简单：假如我是一个恶意的镜像站，是否能够给用我的人植入木马，如何操作？

为了回答这个问题，需要先知道 docker pull 的时候发生了什么。根据前面的介绍，先给 docker 后台进程挂个代理进行抓包，看到有以下请求：

首先请求了 auth.docker.io 进行匿名登陆，后续下载镜像的请求都是发往 registry-1.docker.io；这里先验证下这个地址是不是真的被封禁了，不能人云亦云冤枉好人吧。

Oops！美丽的中国红🇨🇳！（叠甲：本人并没有说不红的地方不是中国）

接着，来看看每个请求：

GET registry-1.docker.io/v2/
GET auth.docker.io/token
HEAD registry-1.docker.io/v2/library/hello-world/manifests/latest
GET registry-1.docker.io/v2/library/hello-world/manifests/sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce
GET registry-1.docker.io/v2/library/hello-world/manifests/sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2
GET registry-1.docker.io/v2/library/hello-world/blobs/sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809
1. 302 重定向到 cloudflare (GET docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com/)
GET registry-1.docker.io/v2/library/hello-world/blobs/sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634
1. 302 重定向到 cloudflare (同 6.1)

第 1 步返回的是 401 Unauthorized，估计是用来校验 DockerHub 账户登陆的。因为我们没登陆，所以第 2 步就直接进行了匿名登陆，返回了 2 个 JWT Token，对于本文的主题而言也不是很需要关心。

接着是第 3 步，获取 manifest，这是个 HEAD 请求，照理来说是不返回内容的，但实际上会在返回的 Header 里带上 manifest 的 hash：

200 OK
Date: Sat, 29 Nov 2025 07:42:22 GMT
Content-Type: application/vnd.oci.image.index.v1+json
Content-Length: 12341
Connection: close
docker-content-digest: sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce26
docker-distribution-api-versio  registry/2.0
...

Manifest

因为 latest 只是个 tag 名字，实际拉取文件还是要根据 sha256 来获取。第 4 步真正获取 latest 对应的 manifest。这是一个 JSON 文件：

{
  "manifests": [
    {
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "amd64",
        "org.opencontainers.image.base.name": "scratch",
        "org.opencontainers.image.created": "2025-08-13T22:16:57Z",
        "org.opencontainers.image.revision": "6930d60e10e81283a57be3ee3a2b5ca328a40304",
        "org.opencontainers.image.source": "https://github.com/docker-library/hello-world.git#6930d60e10e81283a57be3ee3a2b5ca328a40304:amd64/hello-world",
        "org.opencontainers.image.url": "https://hub.docker.com/_/hello-world",
        "org.opencontainers.image.version": "linux"
      },
      "digest": "sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      },
      "size": 1035
    },
    {
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "amd64",
        "vnd.docker.reference.digest": "sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df",
        "vnd.docker.reference.type": "attestation-manifest"
      },
      "digest": "sha256:6b75187531c5e9b6a85c8946d5d82e4ef3801e051fbff338f382f3edfa60e3d2",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "platform": {
        "architecture": "unknown",
        "os": "unknown"
      },
      "size": 566
    },
    // ...
    ],
	"mediaType": "application/vnd.oci.image.index.v1+json",
	"schemaVersion": 2
}

整个 JSON 文件是 OCI Image Index（开放容器倡议镜像索引）格式，其中 manifests 是一个数组，数组中的每个对象都描述了一个实际的镜像清单（Image Manifest）。这里只截取了其中两个。

第一个对象描述了 amd64/linux 架构的镜像，包含 cpu 和操作系统信息，以及镜像的摘要；第二个对象则是一个特殊的描述符，它引用了一个证明（Attestation）清单，可以理解为元数据信息。

docker 客户端会根据自身平台在 manifests 数组中找到与其平台匹配的描述符，然后下载对应镜像。

比如，笔者测试的系统是 amd64/linux，那么就对应第一个 Manifest 对象，其 sha256 哈希为 2771e...，在前面的请求分析中正对应第 5 个请求。该请求同样返回一个 JSON：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634",
    "size": 547
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809",
      "size": 2380
    }
  ],
  "annotations": {
    "com.docker.official-images.bashbrew.arch": "amd64",
    "org.opencontainers.image.base.name": "scratch",
    "org.opencontainers.image.created": "2025-08-08T19:05:17Z",
    "org.opencontainers.image.revision": "6930d60e10e81283a57be3ee3a2b5ca328a40304",
    "org.opencontainers.image.source": "https://github.com/docker-library/hello-world.git#6930d60e10e81283a57be3ee3a2b5ca328a40304:amd64/hello-world",
    "org.opencontainers.image.url": "https://hub.docker.com/_/hello-world",
    "org.opencontainers.image.version": "linux"
  }
}

这同样是一个镜像清单，用于描述如何组装一个特定的容器镜像。容器获得了这个 manifest 后，下一步就是根据 sha256 哈希去下载实际的镜像，对应前文中的：

第 6 步（17ee）：下载 layers 第一层内容；
第 7 步（1b44）：下载 config 的内容；

cofig 信息是以下 JSON 内容：

{
  "architecture": "amd64",
  "config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Cmd": [
      "/hello"
    ],
    "WorkingDir": "/"
  },
  "created": "2025-08-08T19:05:17Z",
  "history": [
    {
      "created": "2025-08-08T19:05:17Z",
      "created_by": "COPY hello / # buildkit",
      "comment": "buildkit.dockerfile.v0"
    },
    {
      "created": "2025-08-08T19:05:17Z",
      "created_by": "CMD [\"/hello\"]",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:53d204b3dc5ddbc129df4ce71996b8168711e211274c785de5e0d4eb68ec3851"
    ]
  }
}

而 layer 则是一个压缩包，我们在下节对其进行详细分析。

至此，网络侧的请求流程基本上分析清楚了。当然本文只是涉及了观察到的请求，实际 Pull 流程的完整接口介绍可以参考下面的文档：

Open Container Initiative Distribution Specification - Pull

Layers

查看下载的 layer 内容之前，我们先学习一下 Docker Image 的组成和格式。Docker 镜像是一个增量文件系统，由一个或者多个层级（Layer）构成。现代容器镜像是基于内容可寻址存储（Content-Addressable Storage）的原则设计的。这意味着一旦一个层或配置对象被创建，它的内容就永远不会改变。对镜像的任何修改都会生成一个新的层和/或一个新的配置对象，从而产生一个新的摘要。

每个层文件本质上是一个 差异归档（Diff Archive），它包含了相对于其前一个层的文件系统变化。

当 Docker 或 OCI 运行时（如 containerd）处理一个镜像时，会按顺序执行以下操作：

将第一个层的内容解压并应用到初始的空文件系统（基础镜像是 scratch）。
将每个后续层的内容叠加（Overlay）到前一层之上。
最终整个容器的文件系统是所有层内容自底向上合并的结果。

这就是为什么我们平时在构建 Dockerfile 的时候，前面 RUN apt update && apt install 之后再接着 RUN apt clean 并不会减少容器体积，因为每个 RUN 命令都生成了一个新的 Layer。

准确来说，RUN rm -f file 时，当前层会创建一个特殊的空文件（whiteout 文件），通常以 .wh. 开头（例如 .wh.filename），当文件系统合并时，这个文件会遮盖下面层中同名的文件或目录，对于容器用户而言，下面的文件看起来就像是被删除了。

接着来看我们前面抓包获得的 layer 文件，下载查看后发现是 tar.gz 格式，解压后是一个静态链接的 ELF 文件：

$ file layer.tgz
part.tgz: gzip compressed data, original size modulo 2^32 11776

$ tar -xzvf layer.tgz
hello

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

docker 怎么知道应该把这个文件放到哪里呢？其实很简单，不是根据 config.json，而是根据其在 layer.tgz 中的相对位置确定。

Anatomy of an image

攻击实例

既然每个 Layer 只是文件系统的差异归档，那作为攻击者，是否可以通过修改 Layer 内容，或者新增 Layer 的方式植入恶意代码呢？直觉来看是可以的，本节来进行实际的攻击测试。

首先作为一个恶意的镜像提供商，我需要先写一个镜像站来转发和缓存 docker registry 里的所有镜像，不过这估计需要大量的磁盘空间，我的轻量云估计放不下。回头看一下抓包的内容，既然原始的请求都有 302 重定向，那我直接转发到别的镜像站不就行了？

先用 Flask 整一个简单的中间商镜像站：

@app.route('/')
def catch_all(path):
    target_url = f"https://docker.1ms.run/{path}"
    return redirect(target_url, code=302)

测试替换镜像源并 pull 一下 hello-world，客户端成功拉取了镜像，查看服务器日志也没问题：

127.0.0.1 - - [29/Nov/2025 20:35:47] "GET /v2/ HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:35:47] "HEAD /v2/library/hello-world/manifests/latest HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:08] "GET /v2/library/hello-world/manifests/sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce26 HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/manifests/sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/blobs/sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634 HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/blobs/sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809 HTTP/1.1" 302 -

接下来考虑怎么给他加点料。一个直接的想法是把 Layer 整个替换掉，鉴于这是一个包含 ELF 的 tar.gz 文件，感觉还是比较简单的。

首先静态编译一个简单的 hello-world，然后压缩替换原始的文件：

$ gcc -static main.c -o hello
$ ./hello
You are hacked, bro!
$ tar -czvf layer.tar.gz hello

然后设置 flask 针对 part.tar.gz 返回我们修改后的文件：

if path.startswith('v2/library/hello-world/blobs/sha256:17eec'):
	return send_file('layer.tar.gz')

直接测试一下试试，理论上应该签名校验失败：

$ docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
17eec7bbc9d7: Verifying Checksum
docker: Get "https://registry-1.docker.io/v2/": dial tcp 4.78.139.50:443: connect: connection refused.
See 'docker run --help'.

和预期中的一样，毕竟哈希都对不上。接下来我们看看还要修改哪些文件，从下往上看：

layer.tar.gz 内容变化，导致其 sha256 变化，因此需要修改 digest.json 中的哈希(请求 5)；
digest.json 内容变化，因此需要修改 manifest.json(请求 4)；
manifest.json 内容变化，需要修改 HEAD latest 的返回头(请求 3)；
…

依次把对应的 sha256 修改完后，发现无法启动。调试了半天不得其解，最后发现是 digest.json 中除了 layer 的哈希，还要修改 diff_id。这个 diff_id 是对一个镜像层内容的 未压缩 文件系统差异计算出的唯一标识符，具体计算过程比较复杂，我们直接参考 docker 用 golang 来实现即可：

layer, err := tarball.LayerFromOpener(func() (io.ReadCloser, error) {
return os.Open(filePath)
})
if err != nil {
panic(fmt.Errorf("error creating layer from opener: %w", err))
}
diffID, err := layer.DiffID()

另外这里介绍一下 docker 的调试方法，首先在 /etc/docker/daemon.json 文件中加入 "log-level": "debug" 字段，然后重启后台进程，使用下面的命令就可以查看详细日志了：

sudo journalctl -u docker.service -f

最终实现效果：

$ docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
cf02c551b988: Pull complete
Digest: sha256:6eb1bf5e044ede4cad2267ce2d15d306c5f6e6351e790ac36c7d99ce1418b7e2
Status: Downloaded newer image for hello-world:latest
You are hacked, bro!

这个攻击实验过程中涉及到的代码我都放在了 Github 中，感兴趣的可以参考。

防御方案

对于这类攻击，Docker 官方给出的方案是使用 Docker Content Trust (DCT) ，即在运行前加上 DOCKER_CONTENT_TRUST 环境变量，这样在执行 docker pull 请求后会自动在后台执行验证。

不过这种方案一方面基于过时的 Notary v1 技术，目前已被 Docker 官方弃用和淘汰；另一方面则是不属于默认安全，很少有用户会手动指定。而且，即使你指定了，在国内也可能会遇到网络错误：

$ DOCKER_CONTENT_TRUST=1 docker run --rm hello-world
docker: Error: error contacting notary server: dial tcp 208.43.170.231:443: i/o timeout.
See 'docker run --help'.

作为新的替代验证方案，比如 Sigstore 或者 Notation，使用起来更为繁琐。镜像作者需要配置好公钥，而使用方则需要先验证（如 cosign verify）、后拉取，普及起来依旧任重道远。

Whom To Blame？

假设，不久后的某天，一个别有用心的黑客（比如银狐的大哥），基于这个中间人攻击的原理，部署了一大群恶意的“镜像站”，并且通过 SEO 的方式广泛传播。然后，某萌新运维在运行 docker 失败后上百度搜索了 “docker pull 失败怎么办” 发现第一条正好是设置镜像源的教程，而其中的 10 条镜像源有 8 条都是恶意的。最终通过镜像站下载了一个有后门的 mysql/nginx，导致了入侵事件的发生。那么，这个安全事故主要应该让谁背锅呢？

单选题：

A. 实施攻击的银狐大哥
B. 复制粘贴的萌新运维
C. 分享技术的吃瓜博主
D. 矫枉过正的有关部门
E. 竞价排名的某度搜索

对此，你怎么看？请在评论区留言吧！（逃

参考链接

PoC of docker registry-mirror MITM attack

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

国内开发者的网络超时日常

Tue, 13 Feb 2024 12:40:00 +0800

作为国内的互联网从业者，或许大家多少都经历过一些莫名其妙的网络问题。而笔者经常审计各种语言代码，对于这些问题也就接触得更多。不巧最近刚刚更换电脑，把这些问题又重新踩了一遍，因此决定系统记录下来，以便后来的同僚能少走一些弯路。

注意，根据《中华人民共和国计算机信息网络国际联网管理暂行规定》，任何单位和个人不得自行建立或者使用其他信道进行国际联网，因此本文尽可能在不违反法律的情况下使用镜像站解决上述网络问题。对于依旧解决不了的，可以酌情考虑换个行业。

开源镜像站

所谓开源镜像站，就是在原站点访问太慢或者无法访问时提供一个备用的镜像功能，通常用于企业环境指向内网的私有镜像站制品仓库。当然，在国内个人开发者的使用场景更多是用于网络加速。一些常用的开源镜像站点主页如下:

清华大学开源软件镜像站 (TUNA)
北京外国语大学开源软件镜像站 (TUNA)
USTC open source software mirror - 中科大镜像源，含部分反向代理列表
上海交通大学镜像站
南京大学镜像站
阿里巴巴开源镜像站
腾讯软件源

一般镜像站中除了镜像本身，还附带了比较整洁的文档或者说明，其中 TUNA 镜像站的文档是笔者认为写得最好的，可以参考其文档并根据自身网络环境选择合适的镜像源。

更详细的镜像站汇总，可以参考:

其中各个站点的索引的软件都不太一样，比如山东女子学院开源软件镜像站中还可以下载 java 的二进制文件。因此如果在某个镜像站找不到你所需的软件源，可以换几个镜像站找找，说不定能有所收获。

其他:

包管理器

我们先从简单的说起。在全新安装好操作系统时，第一步要准备的自然是包管理工具。这类工具有很多，只选几个典型作为记录，即 Debian/Ubuntu Linux 系的 apt-get 以及 macOS 下的 Homebrew。

APT-GET

一般我们配置 apt 镜像的时候会上百度随便搜 “ubuntu 国内源”，然后进入到某个 CSDN 的文章，把里面的源复制一下，粘贴到系统的 /etc/apt/sources.list 中。这样确实能解决问题，不过对于新手而言可能会不小心复制错源，比如将 ubuntu 18.04 (bionic) 的源复制到了自己的 ubuntu 22.04 (jammy) 系统中，导致更新出错。因此更好的方法是直接到上面的开源镜像站中查找对应的源。

扯句题外话，apt 源的格式一般如下:

deb [ option1=value1 option2=value2 ] uri suite [component1] [component2] [...]
deb-src [ option1=value1 option2=value2 ] uri suite [component1] [component2] [...]

其中只有 uri 和 suite 是必填的，其他都是可选的，比如我们经常复制下来的形式是:

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse

suite 代表系统的 codename，component 则表示启用的组件，从请求来看，它们一起组合成了完整的 URL 路径 /dists//，例如:

https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/jammy/main

那么我们怎么知道应该使用哪些 component 呢？一般来说，

main 表示发行版官方支持开源软件版；
restricted 表示官方支持但不是完全 License free 的软件包；
universe 表示社区维护的软件，但非官方支持；
multiverse 表示非自由软件，比如 NVIDIA 的驱动；

不过我们无需记住所有的源，只需要把原始 sources.list 中的 URI 替换即可。值得注意的是有的文章中使用 sed 去替换，比如替换成阿里云的源:

sed -ibak "s/archive.ubuntu.com/mirrors.aliyun.com/g" /etc/apt/sources.list

这需要注意 URI 的路径，以及针对安全更新使用的 URI 通常是其他子域名，如: http://security.ubuntu.com/ubuntu/ ，因此更为稳妥的方式还是进行手动替换。

参考:

HomeBrew

如果你用的是 macOS 系统，那么很可能会用到 Homebrew。该包管理工具与 apt 不同，并不是系统自带的，需要手动安装。官网的安装介绍就一句话:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

如果网络不好，很可能会收获一个 curl: (28) SSL connection timeout。此时还是参考 TUNA 中的文档，从镜像源中获取 install.sh 进行安装:

# 从镜像下载安装脚本并安装 Homebrew / Linuxbrew
git clone --depth=1 https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/install.git brew-install
/bin/bash brew-install/install.sh
rm -rf brew-install

对于侥幸网络顺畅已经安装过的朋友，在 brew update/install 时可能也会遇到网络问题，因为 formula/cask 默认是从 github 下载的。此时就需要通过环境变量将其设置为镜像地址:

export HOMEBREW_API_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles/api"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles"
export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git"
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git"
export HOMEBREW_PIP_INDEX_URL="https://pypi.tuna.tsinghua.edu.cn/simple"

参考:

WinGet

Windows 中也有一些包管理工具，比如 chocolatey 或者 scoop。目前 Windows 官方推出了 WinGet，后续随着软件源的丰富会日渐成为主流。但是不幸 WinGet 的软件包元数据也是存放在 github 上的，因此我们也要寻找镜像。

幸运的是部分国内开源镜像也提供了 winget 的源，比如 USTC Mirrors:

winget source remove winget
winget source add winget https://mirrors.ustc.edu.cn/winget-source

但可惜这只是 manifest 的源，实际的安装包还是走的原始下载地址，很多是对应软件官网提供的。由于软件来源不一，因此很难实现统一的镜像。因此对于原始二进制文件下载不了的情况只能开启系统代理，因为 winget 的代理选项还在开发中，见 issue#190。

参考:

Python

准备好包管理器之后我们就可以开始写代码了，首选的自然是简单实用的脚本语言 Python。使用包管理器可以很简单地进行安装，不过如果没有使用包管理器，或者需要的安装最新的 Python 版本没有及时更新到包管理仓库中，那么还是需要手动下载安装的。

下载自然是要到官网下载，不过需要注意的是如果使用某搜索引擎需要仔细辨别哪个是官网，否则不小心安装完发现是个全家桶就得不偿失了。

有时候 Python 的官网 python.org 访问也是会出现网络超时的，此时也可以借助上面说到的镜像源。在校园网联合镜像站中可以搜索哪个镜像站支持下载 Python binary 的镜像，发现北京交通大学镜像站有，因此可以在这里加速下载:

https://mirror.bjtu.edu.cn/python/

安装好 Python 之后还需要安装 pip 并配置好对应的 pypi 源，否则控制台可能会出现一些红红黄黄的错误。

来源: 新闻联播

在 TUNA PyPI 镜像使用帮助中已经比较详细地说明了配置方法，这里简单记录一下:

python3 -m pip install --upgrade pip
python3 -m pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/

这会将镜像源地址写入到 $HOME/.config/pip/pip.conf 文件中，当然自己手动修改该文件也是可以的。很多所谓教程还会额外修改 install.trusted-host，这对于 HTTPS 的源而言已经没必要了。

NodeJS

最为另一个最受欢迎的语言 JavaScript 我们当然也是要支持的，为此就需要先安装 nodejs 环境。不考虑包管理器的话根据官网应该是要到 https://nodejs.org/dist/ 中下载，不过在国内访问仿佛会受到一股无形的阻力:

From: vsping.com

因此，还是再次感谢镜像们救我狗命:

安装完 nodejs 和 npm 后还需要配置 npm 仓库的镜像源，以加速 npm install 等命令:

# 刷新缓存
npm cache clear --force
# 将配置写入 ~/.npmrc
npm config set registry https://registry.npmmirror.com/

注意镜像的地址是 HTTPS 而不是 HTTP，否则可能会会遇到 npm ERR: Cannot read property ‘insert’ of undefined 之类的错误。

很多情况下需要使用 nvm 管理不同的 nodejs 版本，那么也可以直接在包管理器中先任意安装某个版本的 node 和 npm，然后再安装 nvm 去切换版本:

npm install -g n
n lts
export PATH=$HOME/.n/bin:$PATH
node --version

参考:

Golang

Golang 也是一个常用的语言，官网地址: https://go.dev/doc/install

当然，官网速度比较感人，你可以选择国内的镜像站点来安装 go 程序，比如:

golang 的包管理的加速略有不同，不是使用镜像而是使用 GOPROXY 协议，细节就不考究了，简单来说配置如下:

go env -w GO111MODULE=on
go env -w GOPROXY=https://goproxy.cn,direct

其他模块加速代理的地址包括但不限于:

Rust

Rust 是近期用的比较多的静态类型语言，可以作为 C++ 的一个很好补充和替代。 Rust 官网的安装介绍就一句话:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

如果你直接复制粘贴这条命令来安装，很可能也会碰到一些网络问题。在安装阶段使用的工具其实称为 rustup，因此我们可以去查找 rustup 的镜像，其中字节的 rsproxy.cn 看起来就比较符合我们的需求:

export RUSTUP_DIST_SERVER="https://rsproxy.cn"
export RUSTUP_UPDATE_ROOT="https://rsproxy.cn/rustup"
curl --proto '=https' --tlsv1.2 -sSf https://rsproxy.cn/rustup-init.sh | sh

安装完后使用 cargo 拉取包的时候会请求 crates.io，又会出现网络问题，此时可以修改 cargo registry 地址，即修改文件 ~/.cargo/config:

[source.crates-io]
replace-with = 'rsproxy-sparse'
[source.rsproxy]
registry = "https://rsproxy.cn/crates.io-index"
[source.rsproxy-sparse]
registry = "sparse+https://rsproxy.cn/index/"
[registries.rsproxy]
index = "https://rsproxy.cn/crates.io-index"
[net]
git-fetch-with-cli = true

参考:

rsproxy.cn: A high speed crates.io mirror

Java

Java 是笔者比较不喜欢的一门语言，但无奈国内各个大厂都喜欢用 Java，作为安服仔就只能默默接受这个现实并接受它。安装部分就不必说了，重点看一下依赖包下载过程中遇到的网络问题。

在介绍具体的项目管理工具之前，我们先了解一下 Java 基本的代理设置。Java 主要通过 system properties 来设置代理，即通过命令行指定 -D 或者在代码中调用 System.setProperty 实现。

而控制代理的系统属性有下面这些。

针对 HTTP 请求的 HTTP 代理:

http.proxyHost
http.proxyPort
http.nonProxyHosts

针对 HTTPS 请求的 HTTP 代理:

https.proxyHost
https.proxyPort

socks5 代理:

socksProxyHost
socksProxyPort

值得一提的是 Java 会根据请求的协议选择不同的代理，因此如果只设置了 http.ProxyHost，那么就只有纯 HTTP 请求会走代理，HTTPS 请求则会直连。详细的介绍可以参考:

Oracle: Java Networking and Proxies

Maven

maven 算是 Java 中最常用的项目管理工具了，但相信各位 Java 开发者一开始 mvn clean pacakge 编译别人的项目时都遇到过依赖下载缓慢甚至网络错误的问题。一个直接的方法是使用镜像，即修改 maven 默认配置文件，比如 $HOME/.m2/settings.xml，加入下述节点:


  ...
  
    
      aliyunmaven
      Aliyun
      https://maven.aliyun.com/repository/public
      central,jcenter
    
  
  ...

在阿里云的文档中说还可以在 repositories 加入，但 repository 中更多是添加私有仓库地址；另外阿里云的文档还有个问题是将 mirrorOf 设置为了 * 即代理所有仓库，这会导致某些阿里云没有做镜像的仓库下载失败，因此最好还是按需添加镜像。

参考:

Gradle

另外一个常用的 Java 项目管理工具就是 Gradle，比如笔者常用的 Android Studio 就是使用 Gradle 作为 APK 的编译工具。

更准确地说是使用 gradle 的封装脚本 gradlew，其中包含了具体的 gradle 版本，避免不同版本之间的编译脚本兼容性问题。作为国内用户，经常就死在了 gradlew 的第一步，因为其会去下载对应版本的 grandle-bin，比如 https://services.gradle.org/distributions/gradle-8.0-bin.zip 。

解决方法是修改 gradle/wrapper/gradle-wrapper.properties 文件指定 distributionUrl 为国内镜像源的具体地址，例如:

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://mirror.nju.edu.cn/gradle/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

其他的 gralde distribution 镜像地址可以参考:

解决完 gradle-bin 的下载问题后，还会遇到与 maven 类似的中央仓库下载网络问题，但是 gradle 没有类似 maven 的 mirror tag，而只有类似的 repositories tag，用指定私有仓库的方式将其指定到国内的 maven 仓库镜像中。

使用 Groovy DSL 的 gradle 配置文件 build.gradle 可以添加以下配置:

allprojects {
    repositories {
		maven { url 'https://maven.aliyun.com/repository/google' }
        maven { url 'https://maven.aliyun.com/repository/public' }
        mavenLocal()
        mavenCentral()
    }
}

使用 Kotlin 的 gradle 配置文件 build.gradle.kts 可以使用下述配置:

repositories {
    maven { setUrl("https://maven.aliyun.com/repository/google/") }
    maven { setUrl("https://maven.aliyun.com/repository/public/") }
    mavenLocal()
    mavenCentral()
}

Gradle 似乎没有全局的配置方案，网上的教程更多是使用 init.gradle 即初始化脚本，在项目的 gradle 脚本任务执行之前替换掉 repo 地址:

allprojects{
  repositories {
    all { ArtifactRepository repo ->
      if(repo instanceof MavenArtifactRepository){
        def url = repo.url.toString()
        if (url.startsWith('https://repo1.maven.org/maven2')) {
          project.logger.lifecycle "remove ${repo.url}"
          remove repo
        }
        if (url.startsWith('https://jcenter.bintray.com/')) {
          project.logger.lifecycle "remove ${repo.url}"
          remove repo
        }
      }
    }
    maven {
      url 'https://maven.aliyun.com/repository/public/'
    }
  }
}

这种方式着实不太优雅，但也能算是一种不修改原始代码工程文件的镜像方案。

值得一提的是，云厂商的 maven 仓库镜像也只有一部分 repository，像 jitpack.io 这类仓库可能镜像中就无法找到，此时只能另觅他法了。

说句题外话，不管是 maven 还是 gradle，其实本质上都是一个 Java 工具，因此我们可以通过给 Java 应用添加属性的方式设置代理。比如 maven/gradle 可以通过 -D 添加属性；gradle 可以通过在 gradle.properties 中添加属性 (需要添加前缀，如: systemProp.https.proxyHost)。其中 gradle.properties 除了放在项目根目录中，还可以全局使用，在 NIX 系统中路径是 $HOME/.gradle/gradle.properties，Windows 中则是 %userprofile%\.gradle\gradle.properties。

参考:

总结

经过这一番折腾，这些开发工具终于能够流畅使用了，总算是和老外站在了同一起跑线上！除了上面用到的这些工具和语言，其实还有其他常用的如 Ruby、PHP(Composer)、Docker 等无一不是需要镜像才能流畅使用，不得不感慨国内开发者们顽强生长的能力。同时也非常感谢维护镜像站的厂商和高校，要是没有它们，可能很多人就只能铤而走险了。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/02/13/china-mirror/
微信订阅: 『有价值炮灰』
– 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.

Nginx日志分析

Sun, 04 Jun 2017 22:40:00 +0800

最近登录服务又看到一大堆nginx的日志，一般每次看到我就less看一下也就删了。但这两天正好有空，就想能不能用这些日志发现点什么有价值的信息。于是说干就干，马上打包日志下载到本地，然后操起大Python，开始了一场数据分析之旅……

前言

最近把Jekyll搭建的博客翻新了一遍，主要是规范化了文章的永久连接（permlink）和分类标签。好处是用起来更加规范，坏处就是在野的文章链接指过来的时候就404了。所以说重构最难的还是保持前向兼容，不过还好我的访问量不高，可以不用顾忌太多甩开历史包袱。由于Jekyll都是是静态页面，所以对于很多访问的细节难以了解，可以说在此之前我都是对其不管不顾的状态，也没太多时间维护。

由于全部是静态资源，所以一开始也部署了Nginx作为HTTP服务器。日志采用默认的格式产生，一直也没太关注，这次正好藉着博客改版，尝试分析下近期的日志，以对网站状态有个全局的了解。

Nginx

Nginx是个开源的，高性能的HTTP服务器，反向HTTP代理服务器，以及IMAP/POP3代理服务器，功能强大，因为我也只用过其部分子集，所以本文不对其做详细。这里要交待一下的是配置文件/etc/nginx/nginx.conf 的相关配置，因为后面会有相关：

user www-data;
pid /var/run/nginx.pid;
...

http {
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log error;
    server {
        listen 80;
        server_name www.pppan.net;
        location / {
            root /path/to/jekyll/_site;
        }
    }
}

可以看到这里没有指明日志的格式，因此采用默认设置，根据nginx-log-module 文档得知对于access_log，其默认的格式是combined，如下所示：

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

对于错误日志error_log，一共有6个等级，分别是info, notice, warn, error, crit, alert(emerg)，默认的输出等级是error，所以上面配置里error_log xxx.log error中的error不写也是可以的。详情参考nginx core functionality。

总而言之，Nginx的日志分为访问日志access_log和错误日志error_log两大块，前者主要记录用户每次访问的情况，后者则侧重于服务器的具体错误，比如返回403的具体原因是文件不可读还是权限不足之类的。

准备工作

现在有了日志，便可以着手开始处理了，但在此之前还是要先选择好工具。网上有许多日志分析采用的是简单粗暴的bash脚本(awk)来进行处理，好处是分析速度快，但坏处是拓展性不强，如果未来想要做图表或者在网页前端展示就比较麻烦了。

因此我就挑了比较顺手的Python来做这个工作，因为其还能用matplotlib做些可视化的工作，看起来直观一点。不过还是那句老话，语言只是工具，你也可以用php或者易语言，挑最顺手的来就行了。

访问日志

存储

从上面的配置文件可以看到我的访问日志保存在/var/log/nginx/access.log里，日志到了一定大小就会被压缩改名，所以/var/log/nginx里的文件看起来是这样的：

用Python可以很容易将其全部提取出来合并，我将其取出然后存到数据库里，这样可以方便做些查询和聚合的操作，这里为了简单起见因此选用sqlite3作为数据库，省去安装和配置MySQL的麻烦。表access的格式如下：

DROP TABLE IF EXISTS `access`;
CREATE TABLE `access` (
        `ip` VARCHAR(64),
        `user` VARCHAR(64),
        `date` TIMESTAMP,
        `request` VARCHAR(200),
        `refer` VARCHAR(200),
        `ua`    VARCHAR(200),
        `response_code` INTEGER,
        `response_size` INTEGER);

用Python读取每个文件每一行，并用正则表达式取出我们想要的内容，代码片段如下：

from dateutil.parser import parse
from dateutil import tz

TZ_LOCAL = tz.tzlocal()
pattern = re.compile(r'(?P.*) - (?P.*) \[(?P.*)\] "(?P.*)" (?P\d+) (?P\d+) "(?P.*)" "(?P.*)".*')
for line in file:
    match = pattern.match(line)
    if match:
        fmt_date = match.group('date').replace(':', ' ', 1)
        foreign_date = parse(fmt_date)
        local_date = foreign_date.astimezone(TZ_LOCAL)
        cursor.execute("INSERT INTO `access` VALUES (?,?,?,?,?,?,?,?)",
                (   
                    match.group('ip'),
                    match.group('user'),
                    local_date,
                    match.group('req'),
                    match.group('ref'),
                    match.group('ua'),
                    match.group('rcode'),
                    match.group('rsize'),
                )
            )

这里先将时间部分格式化成Python的dateutil可以读取的格式，然后由于我的服务器在美国且用的系统默认时区，因此这里还将时区转换为本地时区。最后将记录插入到刚刚创建的数据库里。

分析

虽然日志清理了很多，只保留几个月的访问情况，但不妨碍我根据现有的字段，提取出一些我所关心的内容。首先用下列命令分别获取总的访问数以及总的访问ip数：

SELECT COUNT(*) FROM `access`;
SELECT COUNT(DISTINCT `ip`) FROM `access`;

结果一共有15325条访问记录，分别来自2101个不同的IP地址。

Top10

可以根据每个所关心的字段读取频率最高的前十看看是否有什么出乎意料的情况，这里以客户端IP，客户端User-Agent，以及返回状态为例。

请求IP

首先获取访问频率最高的10个IP地址：

SELECT COUNT(*),`ip` FROM `access` GROUP BY `ip` ORDER BY COUNT(*) DESC LIMIT 10;

获得数据后画成表格如下：

其中排名第一第二的都是我常用的出口IP，但不要被这个饼图误导了，因为前十加起来的访问量也不过三千左右，占总量（15235）也才20%而已。事实上访问的IP来源是挺分散的，这里仅仅关注访问频率而已。可以看到除了我自己，其他几乎都是爬虫，嗯，挺合理的。

User-Agent

获取访问频率最高的前10个User-Agent:

select COUNT(`ua`),`ua` FROM `access` GROUP BY `ua` ORDER BY COUNT(*) DESC LIMIT 10;

结果如下：

2758|-
1465|Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
770|Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
503|Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36; 360Spider
479|Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
302|Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
290|Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
286|Mozilla/5.0 (Linux; U; Android 5.0.2; zh-CN; Redmi Note 3 Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 OPR/11.2.3.102637 Mobile Safari/537.36
279|Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
257|Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)

其中排名第一的是不带User-Agent的请求，紧随其后的是google的爬虫以及其他搜索引擎的爬虫，中间有几条来自浏览器的UA基本都是我自己乱入了。

状态码

HTTP请求的返回码也是一个值得关注的信息：

SELECT COUNT(*),`response_code` FROM `access` GROUP BY `response_code` ORDER BY COUNT(*) DESC;

结果如下：

除了200和301重定向以外，还有不少异常的请求，以502状态为例，随手拿几条出来看看：

149.202.98.160|-|2017-05-31 18:57:57+08:00|HEAD / HTTP/1.1|-|scan/0.01|502|0
91.230.47.3|-|2017-05-31 19:41:01+08:00|GET / HTTP/1.0|-|-|502|172
31.210.102.114|-|2017-05-31 19:52:39+08:00|GET / HTTP/1.0|-|masscan/1.0 (https://github.com/robertdavidgraham/masscan)|502|172
91.230.47.3|-|2017-05-31 20:45:07+08:00|GET / HTTP/1.0|-|-|502|172
91.247.38.53|-|2017-05-31 22:42:19+08:00|HEAD /categories.html HTTP/1.1|-|Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94|502|0
91.247.38.53|-|2017-05-31 22:42:28+08:00|GET /categories.html HTTP/1.1|-|Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 AskTbSPC2/3.9.1.14019 Firefox/3.6.2|502|172
91.247.38.53|-|2017-05-31 22:42:31+08:00|GET /categories.html?geVG%3D8598%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1|-|Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 AskTbSPC2/3.9.1.14019 Firefox/3.6.2|502|172

可以看到大多数都是出于扫描器，估计是带了错误的HOST头导致Nginx无法正确代理，具体还要配合error_log查看。上面的输出里最后一个请求有点奇怪，url decode如下：

/categories.html?geVG=8598 AND 1=1 UNION ALL SELECT 1,NULL,'', table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#

查了下IP是来自乌克兰，其实不算很惊讶，因为前面IP访问频率里排第三的就是来自俄罗斯的爬虫。这里根据最后三条记录来看，应该是什么测试XSS和SQL注入的脚本，因为间隔比较短。不过能自动选择/categories.html这种可能带搜索的路径也是挺厉害的。扯得有点远了，还是继续分析日志吧。

流量观察

对于一般网站来说流量监控也是比较重要的，所以根据访问时间，可以统计出每天的访问量和一天中平均各个时间段的访问量：

可惜这里只有几个月的访问日志，不过从左图能看到每天的访问量高低起伏很大，其中最高那里是5月31号端午节我在博客园发新博客的时候。右图是24小时中各个时间段的访问频率，可以看到凌晨四点最低，下午三点最高，这里我都已经转换为北京时间了。

错误日志分析

错误日志也叫应用程序日志，主要用于方便开发者或者运维在出问题的时候排查原因。

存储

同样地，我们可以先把日志保存在数据库里：

DROP TABLE IF EXISTS `error`;
CREATE TABLE `error` (
        `date` TIMESTAMP,
        `level` VARCHAR(20),
        `pid`   VARCHAR(20),
        `message` TEXT
        );

具体过程和访问日志的保存类似，就不再赘述了。

分析

错误日志相对于访问日志要少（废话），但从中也能找到对我们有价值的信息。

错误类型

首先看看都有哪些等级的错误：

select level,count(level) from error group by level;

输出为：

error|2335 notice|9

很好，没有严重的错误，notice里的信息基本上就是Nginx重启的记录，error里则记录了许多异常的访问，这也是要重点分析的。

路径错误

前一段时间改版了博客，因此导致文章路径和以前不兼容了

SELECT COUNT(*) FROM `error` WHERE `message` LIKE '%2: No such file or directory%';

发现有1051个日志都是404错误，几乎占了所有错误日志的一半，下面是随便挑的一些日志详情：

4|connect() failed (111: Connection refused) while connecting to upstream, client: 109.169.29.30, server: bbs.pppan.net, request: "GET /robots.txt HTTP/1.1", upstream: "http://127.0.0.1:5000/robots.txt", host: "www.pppan.net"
3|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 125.38.58.212, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/4989406.html"
3|open() "/home/pnz/html/pppan.net/_site/tech/p2p/2015/12/12/p2p-standard-protocol-stun.html" failed (2: No such file or directory), client: 121.35.211.124, server: www.pppan.net, request: "GET /tech/p2p/2015/12/12/p2p-standard-protocol-stun.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/5048965.html"
3|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 220.178.225.121, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net"
2|open() "/home/pnz/html/pppan.net/_site/favicon.ico" failed (2: No such file or directory), client: 175.9.149.46, server: www.pppan.net, request: "GET /favicon.ico HTTP/1.1", host: "www.pppan.net"
2|open() "/home/pnz/html/pppan.net/_site/tech/2015/11/01/mitm-detail-1.html" failed (2: No such file or directory), client: 218.29.102.120, server: www.pppan.net, request: "GET /tech/2015/11/01/mitm-detail-1.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/4989406.html"
2|open() "/home/pnz/html/pppan.net/_site/tech/p2p/2015/12/12/p2p-standard-protocol-stun.html" failed (2: No such file or directory), client: 123.157.208.18, server: www.pppan.net, request: "GET /tech/p2p/2015/12/12/p2p-standard-protocol-stun.html HTTP/1.1", host: "www.pppan.net", referrer: "http://www.cnblogs.com/pannengzhi/p/5048965.html"

可见"重构"这地雷是多么有破坏力啊。其中很多refer都来自博客园，所以我也赶紧把博客园里对应的文章连接都修改了一遍:(

SEO（搜索引擎优化）

我对SEO完全是门外汉，但即便是我也知道，如果每次搜索引擎的爬虫每次来你的网站都吃一鼻子灰，那你在搜索引擎里的结果肯定不怎么好看。当然每个搜索引擎的优化策略也不尽相同，说起来和杀毒软件的查杀策略一样，需要有心人不断去摸索，去exploit。

鉴于google的爬虫访问我的频率最高，那我就尝试着对其友好一点。先在错误日志里找找有没有google相关的日志：

SELECT COUNT(*) FROM `error` WHERE `message` LIKE '%google%';
SELECT `message` FROM `error` WHERE `message` LIKE '%google%';

说多也不多，说少也不少，一共有56条错误日志，其中大多数都是404错误，主要访问了以下内容：

GET /post_google_news.xml
GET /LocalNews.xml
GET /googlenews.xml
GET /googlesitemap.xml
GET /newssitemap.xml
GET /sitemap/news.xml
GET /tncms/sitemap/news.xml
…

这些东西我怎么会有嘛？！经过google得知这是sitemap即网站地图，爬虫根据地图可以更高效地遍历网站而省去许多无谓的跳转。一般来说网站的sitemap存放于根目录/sitemap.xml，和/robots.txt一样，都是作用于爬虫。而上面的一些路径则主要针对google，有的博客系统如wordpress，都提供了生成google news sitemap的插件，与RSS方式一样，Jekyll也可以很容易生成类似的XML，只不过我现在志并不在此，所以就让它继续404吧～

查错示例

刚刚在分析access_log的时候发现一个乌克兰的IP(91.247.38.53)访问返回502错误网关的信息，但具体错误原因还不清楚，通过对比error_log就能看出了：

SELECT * FROM `error` WHERE `message` LIKE '%91.247.38.53%';

2017-05-31 10:42:19|error|14829#0|*6247 connect() failed (111: Connection refused) while connecting to upstream, client: 91.247.38.53, server: bbs.pppan.net, request: "HEAD /categories.html HTTP/1.1", upstream: "http://127.0.0.1:5000/categories.html", host: "23.95.112.93"
2017-05-31 10:42:28|error|14829#0|*6249 connect() failed (111: Connection refused) while connecting to upstream, client: 91.247.38.53, server: bbs.pppan.net, request: "GET /categories.html HTTP/1.1", upstream: "http://127.0.0.1:5000/categories.html", host: "23.95.112.93"

可见是访问了bbs.pppan.net这个我曾经开过的测试域名，当时用完忘记把DNS的A记录删掉了，而且nginx里对应的反向代理还开着，所以就报了网关错误，和我当初预计的原因一样。

总结

通过分析一遍Nginx的日志，也学习了许多新知识，比如数据的可视化，搜索引擎的习惯~~以及一些XSS和SQL注入的方法~~等，算是温故而知新吧。