警惕XZ Utils后门事件再现！OpenJS发现类似社会工程学渗透攻击

前不久，开源软件项目XZ Utils被曝植入后门，攻击者通过一系列社会工程学手段取得信任，并接管项目。近日，OpenSSF和OpenJS 基金会发现又一起针对开源生态的社工攻击，成功阻止了攻击者的接管尝试，并联合发布警告，同时给开源生态参与者提供了识别这类攻击和保护项目的建议。

经过调查发现，XZ后门事件背后的攻击者Jia Tan 于2021年创建GitHub账户，之后积极参与 XZ Utils 项目的维护。同时，Jigar Kumar开始向XZ库的维护者Lasse Collin施压，要求增加另一位维护者。另一个账户Dennis Ens，也参与了施压，这两个账户似乎只为XZ讨论而存在。

Jia Tan在2023年1月7日合并了他们的第一次提交，表明其完全获得信任。3月份，Google的oss-fuzz的主要联系邮箱更新为Jia的邮箱。2024年2月，Jia tan向 liblzma / xz项目中提交恶意文件。

2024年3月28日，Ubuntu注意到一个上游的漏洞影响了xz-utils源代码包。2024年3月29日，微软PostgreSQL开发人员Andres Freund在调试SSH性能问题时，在开源安全邮件列表中称，他在xz软件包中发现了一个涉及混淆恶意代码的供应链攻击。目前 GitHub 已经关停了整个xz项目。

以下内容为GTP4.0翻译后经人工整理校对的报告全文。

此次OpenJS 基金会截获的类似开源可信项目接管未遂事件证明，近期发生的 XZ Utils（CVE-2024-3094）供应链攻击事件可能并非孤立事件。开放源代码安全（OpenSSF）和 OpenJS 基金会呼吁所有开放源代码维护者警惕社交工程接管企图，尽早识别前期威胁同时采取措施保护其开源项目。

OpenJS 基金会跨项目委员会收到了一系列可疑电子邮件，这些邮件信息相似，名称不同，且与 GitHub 相关的电子邮件重叠。这些邮件恳求 OpenJS 采取行动，更新其一个流行的 JavaScript 项目，以 "解决任何关键漏洞"，但未列举具体内容。邮件作者希望 OpenJS 指定没有被授予访问 OpenJS 托管项目（该项目制定了安全政策，包括基金会安全工作组概述的政策）特权的这些人为该项目的新维护者。这种做法与 "Jia Tan "在 XZ/liblzma 后门中为自己定位的方式极为相似。

开放源代码项目总是欢迎任何人、任何地方的贡献，然而，授予某人作为维护者对源代码的管理权限，需要赢得更高层次的信任，而且这并不是 "快速解决 "任何问题的方法。

• 新的或不知名的人要求提升为维护者。

• 来自社区其他未知成员的认可，这些成员可能也使用虚假身份，也被称为"傀儡"。

• 社区中相对陌生的成员对维护者或其托管的实体（基金会或公司）进行友好且积极、持久的追求。

• PR 包含作为人工制品的 Blobs。例如，XZ 后门是作为测试套件一部分，是一个巧妙制作的文件，与源代码不同，它不是人类可读的。

• 有意混淆或难以理解的源代码。

• 逐步升级的安全问题。例如，XZ 里的问题一开始只是将 safe_fprintf() 替换为 fprintf()，很难会注意到这一相对无害的替换。

• 偏离典型的项目编译、构建和部署实践，导致在 blob、zip 或其他二进制工件中插入外部恶意有效载荷。

• 营造虚假的紧迫感，尤其是当隐含的紧迫感驱使维护者降低审查的彻底性。

这些社交工程攻击利用维护者对项目和社区的责任感来进行操纵。会让项目维护者产生自我怀疑、觉得自己做得不够好、觉得自己对项目做得不够好等感觉的互动可能是社交工程攻击的一部分。这些类型的攻击很难通过编程来检测或防范，因为它们是通过社会工程学来破坏信任。

在短期内，明确、透明地分享类似上述的可疑活动将有助于其他社区保持警惕。确保项目维护者得到良好的支持是抵御这些社会工程攻击的主要威慑力量。

除了上述建议，还有些安全实践可以提高项目的安全性能。虽然这些建议无法阻止持续的社会工程学攻击，但可能会有助于改善项目的整体安全态势。

• 考虑遵循行业标准安全最佳实践，如 本文中的OpenSSF 指南。

• 使用强大的身份验证。例如启用双因素身份验证 (2FA) 或多因素身份验证 (MFA)。

• 使用安全的密码管理器，并将恢复密码保存在安全、最好是离线的地方。不要在不同的服务中重复使用凭证/密码。

• 制定安全政策，包括报告的 "协调披露 "流程。

• 使用最佳实践合并新代码。

• 启用分支保护和签名提交。

• 如果可能，在合并前让第二名开发人员进行代码审查，即使 PR 来自维护者。

• 执行可读性要求，确保新 PR 不被混淆，并尽量减少不透明二进制文件的使用。

• 限制拥有 npm 发布权限的人员。

• 了解项目提交者和维护者并进行定期审查。

• 如果您运行一个开源软件包仓库，请考虑采用《软件包仓库安全原则》。

[2].https://www.openwall.com/lists/oss-security/2024/03/29/10

[3].https://repology.org/project/xz/versions

[4].https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094

[5].https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-backdoor-in-xz-utils/

[6].https://github.com/byinarie/CVE-2024-3094-in

[7].https://boehs.org/node/everything-i-know-about-the-xz-backdoor

[8].https://openjsf.org/blog/openssf-openjs-alert-social-engineering-takeovers