0x00 简介

在上一篇文章中，我们介绍了传统包管理器、新型包管理器的工作方式，其中用了大篇幅介绍 APT 包管理器，但是没有对安全人员比较关心的软件包校验问题进行介绍

这篇文章主要介绍 APT 是如何杜绝软件包篡改的

0x01 大众疑问环节

这部分主要是从常规 Linux 使用者的视角，提出一些平时工作过程中的疑问，通过文章内容，最后解决这些疑问

1. 更新源被黑客攻击，软件包被替换，使用这个更新源的 Linux 电脑会中招吗？

2. 官方以及第三方更新源好多都是 http 协议的，这会不会被劫持篡改？

3. 全世界各个更新源的软件包都是一样的吗？ 还是各自维护的

4. 如何确定安装后的软件包是否被篡改？

0x02 APT 软件包校验机制

以 Ubuntu 为例

软件包校验本质上就是验证下载的软件包是来自官方的

验证有没有被修改过。这很简单啊，只要官方计算每一个软件包的 hash ，之后公布在网站上就好了。如果软件包被修改过，那么 hash 就会变，不就可以了吗？

但是这里存在一个问题，如果网站被入侵了，攻击者修改软件包后，又篡改了 hash 公示文件怎么办？即使将软件包和 hash 公示文件分别放在不同的网站还是存在同时被入侵的可能

所以此时就需要一个具有唯一性的标志来证明“我是没有被篡改过的我”，此时签名就出现了，官方做一个签名，之后将其赋给每一个官方发布的软件包，这样用户就可以通过签名来判断软件是否被篡改过

签名也不是没有风险的，自古以来就有临摹，伪造签名也是很常见，既然设计了签名，就要保证签名后的软件即使被挨个字节分析，也不能伪造出官方签名

这个时候就要用到  GnuPG 了，GPG 是一个密码学软件，用于加密、签名通信内容及管理非对称密码学的密钥。使用 GPG 就可以让用户验证该文件（软件包）是否为官方原版

1）非对称加密

先说对称加密，对称加密就是通信的两端使用约定好的“密码”将通信信息进行加密

对称加密只要有一方被攻破，整个通信内容就被解密泄漏了，同时中间人还可以通过这个“密码”伪造通信内容

非对称加密则采用密钥对儿的方式，一对儿密钥分为公钥和私钥

公钥发给所有要与你通信的人，公钥用来加密通信内容，只能用私钥来解密，这样只要私钥不泄漏，这个过程就是相对安全的

上面的两个例子都是单向的，如果是双向的通信，可以参考 https 的通信模式

2）GPG

GPG 是加密工具，上面介绍了非对称加密，GPG 就是实际使用非对称加密算法对文件等进行签名、加密的工具

现在的需求是 Ubuntu 官方需要证明软件包是官方发布的，所以就需要使用密钥对软件包进行签名，公钥是要发布给用户的，所以使用私钥签名，使用公钥验证签名

这里就和上面非对称加密通信相反了。也就是说公钥和私钥都可以用来保密，公钥发布给用户，发布方式可以以文件的形式，也可以使用公共的密钥服务器

引用知乎上某个匿名用户的一个回答

RSA的公钥和私钥到底哪个才是用来加密和哪个用来解密？- 知乎 https://www.zhihu.com/question/25912483/answer/46649199

不要去硬记。

你只要想：既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

3）APT 软件包校验机制

a. 设置更新源

软件更新源情况

b. 更新软件包索引

sudo apt update

我这里更换了一个软件源，记录第一次执行 sudo apt update 情况下的通信情况

主要是以下 URL 地址

host：mirrors.aliyun.com
/ubuntu/dists/jammy-security/InRelease
/ubuntu/dists/jammy/InRelease
/ubuntu/dists/jammy-updates/InRelease
/ubuntu/dists/jammy-backports/InRelease
/ubuntu/dists/jammy-updates/main/binary-amd64/Packages.xz
/ubuntu/dists/jammy-updates/universe/binary-amd64/Packages.xz
/ubuntu/dists/jammy-updates/universe/binary-i386/Packages.xz

此时我们观察一下软件源目录结构

这里以 /ubuntu/dists/jammy/InRelease 为例解释一下这个文件的含义

• Release

     该文件记录了当前目录以及子目录各个文件的hash值

• InRelease

     该文件是 GPG 签名后的 Release 文件的 ASCII 可读文件

• Release.gpg

     这个文件就只是 Release 文件的签名，也被称为“分离的GPG签名”

目前 APT 主要使用的就是 InRelease 文件

Release

InRelease

Release.gpg

通过检查  InRelease  文件，可以确定该文件是否为官方签名文件，并且获取各个Packages.xz 的 hash 值

由于本次下载的都是 jammy-updates 目录下的 Packages.xz，所以我们先获取  jammy-updates 目录下的 InRelease 文件

之后下载对应支持的CPU架构的 Packages.xz 文件，这里以 /ubuntu/dists/jammy-updates/main/binary-amd64/Packages.xz 为例

我们查看一下 Packages.xz 中的内容

Package: accountsservice
Architecture: amd64
Version: 0.6.45-1ubuntu1.3
Priority: standard
Section: gnome
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Debian freedesktop.org maintainers <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 440
Depends: dbus, libaccountsservice0 (= 0.6.45-1ubuntu1.3), libc6 (>= 2.4), libglib2.0-0 (>= 2.37.3), libpolkit-gobject-1-0 (>= 0.99)
Suggests: gnome-control-center
Filename: pool/main/a/accountsservice/accountsservice_0.6.45-1ubuntu1.3_amd64.deb
Size: 62420
MD5sum: ae68808224b8386f0ee66aefa3e27103
SHA1: a3df4c138960ad2547b4aa8e3f3f1e58fb27ef92
SHA256: 3d76bac7ae425b8eff2599da2b02b2874ad2df6603d0b7b645cf8cc1f830c9a1
SHA512: e8db8f52ee6b04475d2de596179d5a2c64645a134f0426937bfd2771880b9b739cdd126617043b48933e80ff4fa11db3934e8a8d2a574692e753fc5f9c21edb3
Homepage: https://www.freedesktop.org/wiki/Software/AccountsService/
Description: query and manipulate user account information
Task: standard
Description-md5: 8aeed0a03c7cd494f0c4b8d977483d7e
Supported: 5y

Packages 文件中标记了该分类目录下软件包的元信息，其中包括依赖信息、软件包位置、大小、hash信息等

c. 安装软件包

以 nmap 为例

sudo apt install nmap 

/ubuntu/pool/main/l/lapack/libblas3_3.10.0-2ubuntu1_amd64.deb
/ubuntu/pool/universe/libl/liblinear/liblinear4_2.3.0+dfsg-5_amd64.deb
/ubuntu/pool/universe/l/lua-lpeg/lua-lpeg_1.0.2-1_amd64.deb
/ubuntu/pool/universe/n/nmap/nmap-common_7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1_all.deb
/ubuntu/pool/universe/n/nmap/nmap_7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1_amd64.deb

这一步就直接下载并安装软件包以及其依赖了

d. Ubuntu 默认公钥位置

sudo apt-key list

0x03 答疑环节

现在我们回顾最开始的问题

1. 更新源被黑客攻击，软件包被替换，使用这个更新源的 Linux 电脑会中招吗？

按照当前的 GPG 验证来说，即使更新源被黑客控制，默认情况下篡改的软件包也安装不上。但是可能有大聪明设置什么忽略提醒、忽略安全问题之类的，导致中招

2. 官方以及第三方更新源好多都是 http 协议的，这会不会被劫持篡改？

不会，http篡改后的软件包hash值校验不过去，篡改后的软件包无法通过验证，那为什么很多更新源还是默认使用了 https 呢？这里引用中科大软件源的一个说法

https://mirrors.ustc.edu.cn/help/ubuntu.html#

3. 全世界各个更新源的软件包都是一样的吗？ 还是各自维护的

全世界各地的更新源都是从官方源同步的，但是同步的进度不一样，所以会导致有部分延迟，这里还是要引用中科大的帮助说明文档

https://mirrors.ustc.edu.cn/help/ubuntu.html#

可以通过各个更新源的官方站点的同步状态处获取当前同步情况，以清华更新源为例

https://mirrors.tuna.tsinghua.edu.cn/status/#syncing-status

4. 如何确定安装后的软件包是否被篡改？

这个内容在 《Linux 应急响应手册》中可以查到，位于 小技巧 -> 0x04 系统完整性检查 章节

> sudo apt install debsums 
> debsums --all --changed

根据具体结果进行分析

参考资料

https://zh.wikipedia.org/zh-hans/GnuPG

https://juejin.cn/post/7114260471733534727

https://cloud.google.com/kms/docs/asymmetric-encryption?hl=zh-cn

https://www.ruanyifeng.com/blog/2013/07/gpg.html

https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Reading_OpenPGP_E-mail

https://www.rmnof.com/article/openpgp-gnupg-introduction/

https://www.zhihu.com/question/25912483

https://www.zhihu.com/question/538446534

https://mirrors.ustc.edu.cn/help/ubuntu.html#

往期文章

包管理器到底管理了什么？

Linux 应急响应手册 v1.6

如何带走一个“鲜活”的进程 ｜ Linux 应急响应