Arch Linux供应链危机升级:1500+ 软件包受影响

Arch Linux 是一款面向进阶用户和开发者的 Linux 发行版，以“简洁、轻量、滚动更新”著称。与许多传统发行版不同，Arch 更强调用户对系统的自主控制，因此在软件安装和依赖管理上有更高的灵活性。AUR（Arch User Repository）则是 Arch 生态中的社区软件仓库，用户可以通过它获取大量官方仓库之外的软件构建脚本。也正因为 AUR 的开放性和高活跃度，它在提供便利的同时，也成为供应链攻击更容易渗透的环节之一。

近日，Arch Linux 社区披露一起针对 AUR（Arch User Repository）的供应链攻击事件。根据公开通报与社区研究者分析，攻击者自 6 月 12 日起大规模污染 AUR 软件包，首轮受影响包数量超过1500个。维护团队完成初步清理后不足24 小时，攻击者再次尝试入侵，并引入更复杂的代码混淆与执行流伪装技术，以提高恶意代码的隐蔽性和持久性。

AUR 是 Arch Linux 生态中的社区维护仓库，主要用于提供官方仓库之外的软件构建脚本PKGBUILD。由于其开放性较强、维护者分布广且依赖社区协作，AUR 具备较高的供应链暴露面。本次事件再次表明，社区仓库在账户保护、提交审查、依赖链审计与异常行为检测方面仍存在明显风险。

公开信息显示，本次攻击主要通过篡改 PKGBUILD的方式，将恶意逻辑嵌入软件安装流程。攻击者在部分受影响包中加入预安装或后安装脚本，使安装过程在本地执行额外命令，从而下载并运行恶意载荷。

首轮样本中，恶意安装链主要表现为拉取并执行名为 atomic-lockfile的恶意 npm 包。后续分析指出，该包释放了一个 Linux ELF 可执行文件 deps，其功能特征与窃密器一致，并带有可选的root-only eBPF rootkit组件痕迹。该组件若在具备足够权限的环境中启用，可能提供进程隐藏、文件隐藏及网络接口隐匿能力，从而增加系统取证与响应难度。

第二轮样本在投放方式上进一步复杂化。研究者发现，恶意逻辑被穿插在Bun命令执行流中，通过混淆与流程伪装将恶意行为嵌入正常构建路径。开发者a821最早识别出一批被污染的软件包，覆盖多个 Node.js 工具、Plasma 6 组件、Firefox 相关包、Aura 浏览器及 NeoVim 插件。随后，研究者Nicolas Boichat借助本地部署的 Gemma E2B模型进行辅助分析，进一步发现更隐蔽的恶意样本。

从功能视角看，相关载荷具备明确的信息窃取与外传能力。其目标数据主要包括：

•  浏览器 Cookie 与会话数据库

•  SSH 凭据与密钥材料

•  GitHub 访问令牌

•  HashiCorp Vault token

•  Slack、Discord、Microsoft Teams、Telegram 数据

•  npm、Docker/Podman、VPN 与 shell 历史记录

此外，样本具备归档、多部分文件处理及HTTP上传能力，说明其设计目的不仅是本地收集，还包括将敏感信息打包并外传。结合 eBPF rootkit 相关特征判断，此类载荷对开发工作站、CI/CD 节点、构建服务器和高权限开发环境的风险尤为突出。

本次事件的影响主要体现在以下几个方面。

首先，AUR 作为 Arch Linux 用户广泛使用的社区仓库，其受污染范围较大，影响面较广。对于依赖 yay、paru 等辅助工具执行一键安装的用户而言，恶意脚本可能在安装阶段自动执行，导致用户在无明显交互感知的情况下完成感染。

其次，受影响目标多集中于开发与协作场景，包括浏览器凭据、代码托管令牌、密钥管理系统、即时通信工具和终端历史记录等。这意味着攻击者更可能面向开发者工作站和企业开发环境实施二次利用，而非单纯的通用终端窃密。

第三，若 rootkit 组件在高权限环境中实际启用，受影响主机可能面临持久化控制、取证难度上升和常规查杀失效等问题。对于已执行受污染包的系统，仅依赖常规清理手段未必足以消除潜在风险。

最后，从供应链安全角度看，本次事件再次暴露出社区仓库在账户治理、变更审查、依赖链审计与恶意行为检测方面的系统性薄弱环节。攻击者已经不再局限于简单脚本投放，而是开始针对构建流程、包管理器调用与技术栈特征进行深度伪装。

以下为根据公开分析整理的可关注 IOC 与排查线索，建议结合实际环境进行比对验证。

• 恶意 npm 包名：atomic-lockfile

• 相关 Linux 可执行文件名：deps

• 可疑安装链路：PKGBUILD 中新增预安装或后安装脚本

• 可疑执行特征：安装过程中调用 npm、bun、curl、wget 等外联命令

• 可疑行为特征：下载后立即执行、混淆脚本、base64 解码执行、异常 HTTP 上传

• 重点排查数据目录：

    -浏览器 Cookie / profile 目录

    -SSH ~/.ssh•~/.git-credentials-

    -Vault 配置与 token 文件

    -Slack、Discord、Teams、Telegram 本地数据目录

    -npm、Docker/Podman、VPN 配置与历史记录

    -如存在 root 权限执行迹象，需进一步排查 eBPF 相关异常加载行为及内核层隐藏痕迹

缓解建议

1.用户侧处置

  - 暂缓非必要的 AUR 更新与安装操作

  - 对已安装的 AUR 包进行清单核查，确认是否包含已知受影响项目

  - 如怀疑受感染，应立即更换 GitHub、SSH、Vault、VPN、IM 工具等关键凭据

  - 对高敏感主机执行完整排查，必要时考虑重装系统

2. 安装前审查

  - 在安装前人工审查 PKGBUILD、补丁文件及安装脚本

  - 重点关注curl、wget、npm、bun、bash 远程执行、解码后执行等高风险行为

  - 对涉及自动下载、动态执行、二次拉取依赖的包保持审慎

3. 环境与工具链防护

  - 对开发机和 CI/CD 节点实施终端检测与响应（EDR）监控

  - 将 AUR 辅助工具纳入软件资产管理与终端审计范围

  - 对外部仓库来源建立白名单策略，限制非必要的软件来源

4. 仓库治理建议

  - 强化 AUR 提交前审查与自动化检测机制

  - 提升维护者账户保护强度，推广强认证和异常登录告警

  - 引入基于行为特征的自动分析能力，对构建脚本进行沙箱化检查

  - 对高风险提交建立延迟发布或观察窗口，降低快速扩散风险

本次 AUR 投毒事件显示，开源供应链攻击正从批量污染转向流程嵌入、技术栈适配与混淆对抗。攻击者不仅利用社区仓库的开放机制扩大传播范围，也在持续提高恶意样本的隐蔽性与分析门槛。对于 Arch 用户、开发团队以及社区维护者而言，单纯依赖事后清理已不足以应对这类风险，必须在提交审查、账户保护、动态检测和用户操作规范等方面建立更稳健的防线。