核弹级xz-utils 软件包供应链攻击

❝

xz-utils 软件包遭受的供应链攻击，这场攻击历时三年，几乎成功在众多 Linux 发行版中为 sshd 植入后门，这将允许攻击者绕过密钥认证，其后果难以想象。

❞

1. 2021年，一名用户 JiaT75（即 Jia Tan）注册了 GitHub 账户，并开始积极参与 xz 项目的开发，逐步获得了社区的信任，并最终获准直接提交代码。

2. 在最近的几个月里，JiaT75 在一次提交中偷偷添加了两个表面上无害的测试二进制文件：bad-3-corrupt_lzma2.xz 和 good-large_compressed.lzma。但在编译脚本中，这两个文件在特定条件下会被用来修改编译结果，使得编译后的产物与公开的源代码不符。

3. 初步分析表明，被注入的代码利用 glibc 的 IFUNC 功能来挂钩 OpenSSH 的 RSA_public_decrypt 函数，从而允许攻击者通过发送特制的验证数据来绕过 RSA 签名验证。（具体细节仍在进一步分析中）

4. 任何同时使用 liblzma 和 OpenSSH 的软件都可能受到影响，其中最直接的受害者是 sshd，这意味着攻击者可以通过特制的请求绕过密钥验证，远程访问系统。

5. 已经受影响的 xz-utils 包已经进入 Debian testing 阶段进行测试，并且攻击者还试图将其并入 fedora 和 ubuntu。

6. 幸运的是，注入的代码似乎包含了一个 Bug，这导致在特定情况下 sshd 的 CPU 使用率急剧上升。这一异常被一位安全研究员注意到，并追查到了这一阴谋，随后向 oss-security 报告，使得这一攻击行为暴露。 如果不是因为这个 Bug，这个后门很可能会被并入主流发行版的稳定版本中，这将是一次前所未有的重大安全事件。 从一些细节中可以看出，攻击者非常谨慎：

7. 攻击者选择在 ubuntu beta freeze 前几天尝试将新版本并入，希望减少在测试期间被发现的机会。

8. xz-utils 项目的原维护者 Lasse Collin（Larhzu）有定期进行 internet breaks 的习惯，最近他正在进行这样的休息，因此没有机会审查这些更改，甚至到现在也无法联系到他。这可能是攻击者选择 xz-utils 项目的原因之一。 更多细节仍在分析之中，目前 GitHub 已经关闭了 xz 项目的整个仓库。

以下为英文参考资料原文，感兴趣的朋友可以参考阅读。

Everything I Know About the Xz Backdoorstate^[1]unstable^[2]in^[3]blog^[4]date3/29/2024 ^[5]Unstable^[6][7]Updating at the speed of light, blink once and a word could be gone! These nodes are eratic, unstable, dangerous, but that's why they are fun.^[8]Please note: This is being updated in real time. The intent is to make sense of lots of simultaneous discoveries regarding this backdoor. last updated: 10:30 PM ESTUpdate: The GitHub page for xz has been suspended.2021JiaT75 (Jia Tan) creates their GitHub account. The first commits they make are not to xz, but they are deeply suspicious. Specifically, they open a PR in libarchive: Added error text to warning when untaring with bsdtar^[9]. This commit does a little more than it says. It replaces safe_fprint with an unsafe variant, potentially introducing another vulnerability. The code was merged without any discussion, and lives on to this day^[10] (patched^[11]). libarchive should also be considered compromised until proven otherwise.2022In April 2022, Jia Tan submits a patch via a mailing list. The patch is irrelevant, but the events that follow are. A new persona – Jigar Kumar enters, and begins pressuring^[12] for this patch to be merged. Soon after, Jigar Kumar begins^[13] pressuring Lasse Collin to add another maintainer to XZ. In the fallout, we learn a little bit about mental health in open source. Three days after the emails pressuring Lasse Collin to add another maintainer, JiaT75 makes their first commit to xz: Tests: Created tests for hardware functions.^[14]. Since this commit, they become a regular contributor to xz (they are currently the second most active). It’s unclear exactly when they became trusted in this repository.Jigar Kumar is never seen again^[15]. Another account — Dennis Ens^[16] also participates in pressure, with a similar name+number formatted email. This account is also never seen outside of xz discussion, and both do not have any associated accounts that have been discovered.Glyph^[17]@[email protected] I really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.htmlMar 29, 2024, 20:43564 retoots2023JiaT75 merges their first commit on Jan 7 2023^[18]1^[19], which gives us good indication into when they fully gain trust. In March, the primary contact email in Google’s oss-fuzz is updated^[20] to be Jia’s, instead of Lasse Collin. Testing infrastructure that will be used in this exploit is committed. Despite Lasse Collin being attributed as the author for this, Jia Tan committed it, and it was originally written by Hans Jansen in June: • Commit: liblzma: Add ifunc implementation to crc64_fast.c^[21]• PR: Replaced crc64_fast constructor with ifunc by hansjans162^[22]Hans Jansen’s account was seemingly made specifically to create this pull request. There is very little activity before and after. They will later push for the compromised version of XZ to be included in Debian. In July, a PR^[23] was opened in oss-fuzz to disable ifunc for fuzzing builds, due to issues introduced by the changes above. This appears to be deliberate to mask the malicious changes that will be introduced soon. Also, JiaT75 opened an issue^[24] about a warning in clang that, while indeed incorrect, drew attention to ifuncs.2024A pull request for Google’s oss-fuzz is opened^[25] that changes the URL for the project from tukaani.org/xz/^[26] to xz.tukaani.org/xz-utils/^[27]. tukaani.org^[28] is hosted at 5.44.245.25 in Finland, at this^[29] hosting company. The xz subdomain, meanwhile, points to GitHub pages. This furthers the amount of control Jia has over the project. A commit containing the final steps required to execute this backdoor is added to the repository: • Tests: Add a few test files^[30]• Tests: Update two test files^[31]The discoveryAn email is sent to the oss-security mailing list: backdoor in upstream xz/liblzma leading to ssh server compromise^[32], announcing this discovery, and doing it’s best to explain the exploit chain.AndresFreundTec^[33]@[email protected] I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates. Really required a lot of coincidences. Mar 29, 2024, 18:32757 retoots A gist^[34] has been published with a very good high level technical overview and a “what you need to know” In addition to the gist and the email above, a number of analysis attempts have begun emerging: • xz/liblzma: Bash-stage Obfuscation Explained^[35]• “It’s RCE, not auth bypass”^[36]• [WIP] XZ Backdoor Analysis and symbol mapping^[37]A sudden push for inclusionA request for the vulnerable version to be included in Debian is opened by Hans: • #1067708 - xz-utils: New upstream version available^[38]This request was opened the same week^[39] Hans’ Debian GitLab account was created. The account created a few similar “update” requests in various low traffic repositories to build credibility, after asking for this one. A number of other, suspicious, anonymous name+number accounts with little former activity also push for its inclusion, including misoeater91 and krygorin4545. krygorin4545’s PGP key was made 2 days before joining the discussion.Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work.I noticed this last week and almost made a valgrind bug. Glad to see it being fixed. Thanks Hans! The Valgrind bugs mentioned were introduced by this malicious injection, as noted in the email to OSS-Security:Subsequently the injected code (more about that below) caused valgrind errors and crashes in some configurations, due the stack layout differing from what the backdoor was expecting. These issues were attempted to be worked around in 5.6.1: A pull request^[40] to a go library by a 1password employee is opened asking to upgrade the library to the vulnerable version, however, it was all unfortunate timing. 1Password reached out by email referring me to this comment^[41], and everything seems to check out. A fedora contributor states^[42] that Jia was pushing for its inclusion in Fedora as it contains “great new features”Jia Tan also attempted^[43] to get it into Ubuntu days before the beta freeze. A few hours after all this came out, GitHub suspended JiaT75’s account. Thanks? They also banned the repository, meaning people can no longer audit the changes made to it without resorting to mirrors. Immensely helpful, GitHub. They also suspended^[44] Lasse Collin’s account, which is completely disgraceful. Lasse has begun reverting changes introduced by Jia, including^[45] one that added^[46] a sneaky period to disable the sandbox. They also have published a FAQ that begins to explain the situation: XZ Utils backdoor^[47]OSINTVarious people have reached out to me regarding discoveries about the identity of Jia. Some of this has been incorporated in the timeline, but other stuff is “timeless” and so I’m putting it here:IRCI received an email that clarified a few points, and provided new insight into the situation. “Jia Tan” was present on the #tukaani IRC channel on Libera.chat. A /whois revealed their connecting IP and activity on March 29th.[libera] -!- jiatan [[email protected]] [libera] -!-  was      : Jia Tan [libera] -!-  hostname : 185.128.24.163 [libera] -!-  account  : jiatan [libera] -!-  server   : tungsten.libera.chat [Fri Mar 29 14:47:40 2024] [libera] -!- End of WHOWASRunning an nmap on the IP shows a lot of open ports, which probably indicates a proxy, hosting provider, or something of the sort. The IP is from Singapore. Further research shows that this IP belongs to Witopia VPN, so it’s not entirely indicative of a region. Given the timezone, however, I feel like proximity becomes plausible.Important notes on LinkedInI have received a few emails alerting me to a LinkedIn of somebody named Jia Tan2^[48]. Their bio boasts of large-scale vulnerability management. They claim to live in California. Is this our man? The commits on JiaT75’s GitHub are set to +0800, which would not indicate presence in California. UTC-0800 would be California. Most of the commits were made^[49] between UTC 12-17, which is awfully early for California. In my opinion, there is no sufficient evidence that the LinkedIn being discussed is our man. I think identity theft is more likely, but I am of course open to more evidence.Discoveries in the Git logsI received an email from Minhu Wang^[50] who investigated the Git log, and found one instance where Jia’s username was different:$ git shortlog --summary --numbered --email | grep grep [email protected] 273 Jia Tan2 jiat751 Jia Cheong TanThey found this particularly interesting as Cheong is new information. I’ve now learned from another source that Cheong isn’t Mandarin, it’s Cantonese. This source theorizes that Cheong is a variant of the 張 surname, as “eong” matches Jyutping (a Cantonese romanisation standard) and “Cheung” is pretty common in Hong Kong as an official surname romanisation. A third source has alerted me that “Jia” is Mandarin (as Cantonese rarely uses J and especially not Ji). The Tan last name is possible in Mandarin, but is most common for the Hokkien Chinese dialect pronunciation of the character 陳 (Cantonese: Chan, Mandarin: Chen). It’s most likely our actor simply mashed plausible sounding Chinese names together.

❝

欢迎访问我们的网站和关注我们的公众号，获取最新的技术共享内容、创新想法和安全知识。                      
网站：https://hackerchi.top             微信公众号：黑客驰        
互联网信息流：https://hackerchi.top/Feeds.html

❞

参考资料