400+ Arch Linux AUR包被劫持:Rust木马+ eBPF Rootkit供应链攻击分析

导语:本周,攻击者成功劫持超过400个Arch Linux用户仓库(AUR)软件包,通过篡改构建脚本植入Rust窃密木马及eBPF Rootkit,瞄准开发者的SSH密钥、GitHub令牌、浏览器会话等敏感凭据。官方仓库未受影响,但AUR作为社区包管理渠道,受影响面正在扩大。

来源:本文编译自《The Hacker News》2026年6月15日报道《Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit》,原文链接:thehackernews.com


一、事件概述

1.1 攻击规模与时间线

2026年6月11日起,攻击者开始大规模劫持Arch Linux AUR中的软件包。初期安全公司Sonatype识别出超过20个被劫持包,而社区通过检索AUR git镜像,很快将范围扩大至约408个,并仍在持续增长。此外,第二波攻击另辟蹊径,使用bun install js-digest方式推送另一独立恶意ELF文件。

受影响包名包括alvr、premake-git等已知案例。由于AUR允许任何用户”领养”长期无维护者的孤儿包(orphaned packages),攻击者正是利用了这一信任传递机制。

1.2 攻击手法:信任模型的滥用

本次攻击的核心并非软件漏洞,而是对AUR信任模型的系统性滥用。攻击者采取以下步骤:

  • 占领孤儿包:认领长期无维护者的软件包,保留原包名、历史记录和用户信任
  • 伪造Git提交元数据:伪装成原有维护者提交,令社区难以察觉异常
  • 篡改PKGBUILD:在构建脚本中插入恶意命令,触发恶意负载执行
  • npm管道投毒:通过npm install atomic-lockfile@1.4.2携带的preinstall钩子,在构建过程中自动运行恶意ELF文件

官方Arch仓库未受影响,但AUR的开放性使其成为理想的供应链攻击入口。

攻击流程示意图

二、恶意软件技术分析

2.1 Rust窃密木马 payload

独立安全研究员Whanos对该木马进行了逆向分析,确认其为一个针对开发者工作站和构建系统的Rust窃密木马,主要窃取以下凭证:

浏览器相关

  • Chromium系浏览器(Chrome、Edge、Brave等)的Cookie、令牌和本地存储
  • Electron应用会话数据,包括Slack、Discord、Microsoft Teams

开发工具相关

  • GitHub、npm和HashiCorp Vault令牌
  • OpenAI/ChatGPT Bearer凭证及账户元数据

系统凭据

  • SSH密钥、known_hosts和Shell历史记录
  • Docker和Podman凭证及VPN配置文件

窃取的数据通过HTTP外传至temp.sh,命令控制(C2)通信则通过Tor洋葱服务经本地回环代理实现。

2.2 持久化机制

该木马实现了两层持久化机制:

  • Root权限路径:复制自身至/var/lib/目录,写入系统级systemd单元(/etc/systemd/system/),设置Restart=always
  • 普通用户路径:利用家目录和用户级systemd单元(~/.config/systemd/user/)实现持久化

2.3 eBPF Rootkit(可选模块)

该木马的eBPF Rootkit并非用于提权,而是当二进制已拥有root权限且具备相应能力时才会激活。其功能包括:

  • 使用BPF映射(hidden_pidshidden_nameshidden_inodes)隐藏自身进程、进程名和网络Socket inode
  • 阻止调试器附加(anti-debugging)

这一设计意味着:仅卸载AUR包不足以保证系统清洁——具备rootkit能力的payload一旦执行,package manager无法感知并清除所有隐藏组件。

此外,安全社区还在该二进制中发现了与monero-wallet-gui关联的第二阶段文件,疑似加密货币挖矿程序,但尚未完成分析。


三、蓝队检测与响应指南

3.1 紧急排查步骤

根据MITRE ATT&CK框架(T1195 供应链攻陷、T1552 未托管凭证盗窃、T1055 进程注入),建议按以下优先级执行排查:

第一步:识别受影响主机

如果在2026年6月11日当天或之后安装、构建过AUR包,立即执行以下命令排查:

# 检查是否使用了恶意npm包
grep -r "atomic-lockfile" ~/.cache/yay/*/ 2>/dev/null
grep -r "js-digest" ~/.cache/yay/*/ 2>/dev/null

# 检查构建日志中是否存在恶意调用
grep "npm install atomic-lockfile" /var/log/yay.log 2>/dev/null
grep "bun install js-digest" /var/log/yay.log 2>/dev/null

# 对比本地已安装的AUR包与社区汇总的恶意包名单
pacman -Qm > foreign_packages.txt
# 将foreign_packages.txt与社区名单交叉比对

第二步:检测凭证失陷指标

若确认构建过受影响包,假设主机已失陷,立即轮换以下所有凭据:

  • 浏览器会话(Chrome、Edge、Brave等)
  • SSH密钥(~/.ssh/
  • GitHub、npm令牌
  • Slack、Discord、Teams会话
  • HashiCorp Vault令牌
  • Docker、Podman凭证
  • VPN配置文件
  • OpenAI/ChatGPT API密钥

第三步:检测持久化与Rootkit

# 检查异常systemd服务(系统级)
systemctl list-unit-files | grep -v "^systemd|^dbus"
ls -la /etc/systemd/system/ | grep -v "^d"

# 检查异常systemd服务(用户级)
ls -la ~/.config/systemd/user/

# 检查/var/lib/目录下的异常文件
find /var/lib/ -type f -newer /var/log/pacman.log 2>/dev/null

# 检测eBPF Rootkit特征(BPF映射名)
ls /sys/fs/bpf/ | grep -E "hidden_pids|hidden_names|hidden_inodes"

# 检查Tor C2通信(异常出站连接)
ss -tunap | grep -E "9050|9051|9052"  # Tor常用端口
netstat -tunap | grep -E "temp.sh"     # 数据外传目的地址

3.2 恶意样本特征

主流payload SHA-256:

6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

完整指标集(含Tor C2洋葱服务地址)可参考Whanos的分析报告(ioctl.fail)。

3.3 恢复建议

若AUR包以root权限运行过,假设系统已被Rootkit渗透,建议:

  • 立即断网并从可信介质重装系统:这是唯一可信的恢复路径,Rootkit级别的payload已深入内核BPF层,无法通过常规清理证明系统无后门
  • 重新生成所有SSH密钥对:使用ssh-keygen -t ed25519 -C "重新生成于2026-06-15"生成新密钥
  • 撤销并重新生成所有外部API令牌:包括GitHub Personal Access Token、npm token等

3.4 预防措施

  • 构建AUR包前必读PKGBUILD:这是最有效的防御手段。任何不理解内容的包,都不应构建
  • 警惕孤儿包:近期被认领或长期沉寂后突然活跃的包,值得高度怀疑
  • 关注构建过程中的异常npm/bun调用:AUR包的构建逻辑不应引入未声明的npm依赖
  • 使用AUR辅助工具的安全审核功能:yay、paru等工具均支持只读模式查看PKGBUILD
安全运营中心检测界面

四、总结

此次”Atomic Arch”供应链攻击事件(Sonatype追踪编号:Sonatype-2026-003775,CVSS 8.7)揭示了一个深层次问题:AUR的信任传递机制建立在”包名+历史”之上,而忽视了当前维护者的实际身份。攻击者正是通过认养孤儿包,不费一兵一卒地继承了大量历史信任。

对于蓝队而言,本次事件的启示是:供应链安全不能只关注上游官方仓库,社区包仓库的开放性同样需要审视。构建前的代码审查(PKGBUILD + .install钩子)和构建后的异常行为监控,是两道不可或缺的安全闸门。


参考资料

版权声明:本文由华盟网原创发布,保留所有权利。配图由华盟网授权使用。

© 版权声明
THE END
喜欢就支持一下吧
点赞12 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容