整個周末，開源軟件xz被植入后門事件，引發(fā)了安全界的軒然大波。

研究人員驚恐地發(fā)現(xiàn)，在包括Red Hat和Debian在內(nèi)的多個廣泛使用的Linux版本中，一款壓縮工具被悄悄植入了惡意代碼！

微軟的安全研究員Andres Freund首次報告了這件事。

他發(fā)現(xiàn)，在這款名為xz Utils的工具的5.6.0和5.6.1版本中，都含有惡意代碼。

而且，這段惡意代碼極其復雜難解。

扒著扒著人們發(fā)現(xiàn)，這段代碼是由一位名為Jia Tan的用戶（JiaT75），通過四次代碼變更（也即在GitHub上「提交」）的方式，植入到了Tukaani項目中。

這樣，攻擊者即使沒有有效賬號，也可以直接從SSHD訪問系統(tǒng)了。

（SSHD是一個關(guān)鍵的二進制文件，負責SSH連接的工作。）

目前，GitHub已經(jīng)禁用XZ Utils代碼庫，且還未收到漏洞被利用的報告

好在，這個后門已經(jīng)及時被發(fā)現(xiàn)了。目前GitHub已經(jīng)以違反服務條款為由，禁用了Tukaani項目維護的XZ Utils代碼庫。

然而可怕的是，如果這個后門的漏洞很巧妙，技術(shù)很高超，那么xz被廣泛引入各Linux發(fā)行版后，這些Linux系統(tǒng)就會輕易被入侵！

這件事情可能導致的可怕后果，讓安全社區(qū)對此掀起了經(jīng)久不息的討論。

一場災難被避免了

好在證據(jù)顯示，這些軟件包只存在于Fedora 41和Fedora Rawhide中，并不影響Red Hat Enterprise Linux (RHEL)、Debian Stable、Amazon Linux以及SUSE Linux Enterprise和Leap等主流Linux版本。

但Red Hat和Debian已經(jīng)報告稱，最近發(fā)布的測試版中的確使用了這些被植入后門的版本，特別是在Fedora Rawhide和Debian的測試、不穩(wěn)定及實驗版本中。

同樣，Arch Linux的一個穩(wěn)定版本也受到了影響，不過，該版本也并未應用于實際生產(chǎn)系統(tǒng)中。

另外還有一些讀者報告稱，macOS的HomeBrew包管理器中包含的多個應用，都依賴于被植入后門的5.6.1版本xz Utils。目前，HomeBrew已經(jīng)將該工具回滾至5.4.6版本。

安全公司Analygence的高級漏洞分析師Will Dormann表示，「這個問題實際上并沒有對現(xiàn)實世界造成影響」。

但這主要是因為惡意行為者疏忽了，導致問題被發(fā)現(xiàn)的時機很早。就如同上文所提，如果后門沒被及時發(fā)現(xiàn)，后果將是災難性的。

Jia Tan是誰？

既然事情解決了，那么問題的焦點就集中在了——Jia Tan究竟是誰？

這位Jia Tan，是xz Utils項目的兩位主要開發(fā)者之一，對該項目貢獻良多。

Freund其報告中指出，「考慮到這幾周內(nèi)的活動情況，這位提交者要么是直接涉及，要么其系統(tǒng)遭受了嚴重的安全威脅?！?/span>

不幸的是，種種跡象表明，后一種可能性似乎并不大。

所以，這次xz被植入后門事件，很可能就是Jia Tan的主觀惡意行為。

上周四，有人冒用了這位開發(fā)者的名字，在Ubuntu的開發(fā)者社區(qū)中請求將含后門的5.6.1版本納入正式發(fā)布，理由是它修復了一個導致Valgrind工具出錯的問題。

還有人發(fā)現(xiàn)，近幾周這位開發(fā)者也向他們提出了類似的請求，希望在Fedora 40的測試版本中使用這個帶有后門的工具版本。

「我們甚至還幫助他解決了Valgrind的問題（而現(xiàn)在看來，這個問題正是由他加入的后門引起的），」Ubuntu的維護人員說。

「他已經(jīng)在xz項目中工作了兩年，添加了各種各樣的測試文件，鑒于這種復雜的操作，我們對xz的早期版本也持懷疑態(tài)度，直到后來，它們被證明是安全的?！?/span>

后門技術(shù)分析

簡單來說，CVE-2024-3094引入的這個后門，是為了在受害者的OpenSSH服務器（SSHD）中注入惡意代碼，從而讓遠程攻擊者（持有特定私鑰）能夠通過SSH發(fā)送任意代碼，并在認證步驟之前執(zhí)行，進而有效控制受害者的整臺機器。

盡管具體的內(nèi)容仍在分析當中，但初步分析表明，它的設計相當復雜：

• 后門代碼被注入到OpenSSH服務器（sshd進程），因為liblzma（含有惡意代碼）是某些OpenSSH版本的依賴項。
• 后門劫持了RSA_public_decrypt函數(shù)，這個函數(shù)原本用于驗證RSA簽名。
• 惡意代碼會檢查RSA結(jié)構(gòu)中傳入的公共模數(shù)（「N」值），這個模數(shù)完全受到攻擊者控制。
• 惡意代碼使用硬編碼的密鑰（采用ChaCha20對稱加密算法）對「N」值進行解密。
• 解密后的數(shù)據(jù)通過Ed448橢圓曲線簽名算法進行有效性驗證。由于這是一種非對稱簽名算法，后門只包含了公鑰，這意味著只有攻擊者能夠為后門生成有效載荷。此外，這個簽名與主機的公鑰綁定，因此一個主機上的有效簽名不能在其他主機上使用。
• 如果數(shù)據(jù)有效，該有效載荷將以shell命令的形式被執(zhí)行。
• 如果數(shù)據(jù)無效（有效載荷格式不正確或簽名無效），則會透明地恢復到RSA_public_decrypt的原始實現(xiàn)。這意味著，除了攻擊者之外，是無法通過網(wǎng)絡發(fā)現(xiàn)易受攻擊的機器的。

「臥薪嘗膽」三年

這次最令人印象深刻的，是攻擊者超乎尋常的耐心和決心。

攻擊者花費了兩年多的時間，通過參與各種開源軟件項目并提交代碼，逐步建立起作為一個可信任維護者的形象，以此來避免被發(fā)現(xiàn)。

2021年，一個名為Jia Tan（GitHub用戶名：JiaT75）的用戶創(chuàng)建了GitHub賬戶，并開始為多個項目做出貢獻。

在那一年，Jia Tan共提交了546次代碼，其中對libarchive項目的一次提交尤其引起了人們的關(guān)注。

2022年2月6日，Jia Tan在XZ項目中做出了他的第一次正式提交，這次提交增加了對LZMA和LZMA2編碼器的參數(shù)驗證功能。

2023年6月27日至28日，Jia Tan對XZ Utils項目進行了一系列關(guān)鍵的更改，從而為后續(xù)的攻擊做好了準備。

特別是，項目中的一個文件crc64_fast.c，新增了對一種名為ifunc的技術(shù)的支持。

根據(jù)安全研究員Andres Freund的分析，引入的這種ifunc技術(shù)可能是潛在后門功能的一部分，顯示了攻擊者可能利用的一種手段。

此外，值得注意的是，這個重要更新是由項目的原始維護人Lasse Collin引入的，并且他特別提到了另一位貢獻者Hans Jansen對這一更新的貢獻。

2023年7月8日，JiaT75在oss-fuzz項目中提交了一個請求，該項目負責對XZ等多個開源軟件項目進行自動錯誤檢測。這個請求實際上關(guān)閉了一種特定的錯誤檢測方式，從而防止oss-fuzz發(fā)現(xiàn)XZ項目中潛藏的惡意代碼。

2024年2月15日，JiaT75通過修改XZ項目的配置文件，加入了一個規(guī)則來忽略特定的腳本文件build-to-host.m4。

很快，這個腳本就被包含在了項目的正式發(fā)布版本中——它會在構(gòu)建過程中執(zhí)行，并植入一段負責在受害者電腦上安裝后門的惡意代碼。

2024年2月23日，JiaT75在XZ項目的測試文件夾中加入了兩個含有隱藏后門的測試文件。

2024年2月24日，JiaT75發(fā)布了包含惡意腳本文件的新版本5.6.0，也就是說任何使用了這個版本及以后版本的XZ都存在安全風險。

2024年2月27日，這個帶有安全隱患的版本被Fedora采納。

2024年3月9日，JiaT75更新了后門程序，發(fā)布了版本5.6.1，F(xiàn)edora同樣更新了這個版本。

2024年3月29日，安全研究員Andres Freund在oss-security郵件列表上公布了他對XZ項目中發(fā)現(xiàn)的惡意行為的詳細分析。

還有更多受害者

雖然惡意代碼僅在XZ項目中被檢測到，但攻擊者賬戶的其他代碼貢獻目前也在調(diào)查中。

截至今日，一些項目已經(jīng)被發(fā)現(xiàn)添加了可疑代碼：

libarchive

2021年，JiaT75向libarchive代碼庫提交了一個名為「在使用bsdtar解壓時添加錯誤提示文本」的合并請求，乍看之下似乎沒什么問題。

但仔細一看，這個合并請求中的代碼把原本安全的函數(shù)safe_fprintf()換成了更危險的fprintf()函數(shù)，這一改動可能會導致字符逃逸的安全漏洞。

oss-fuzz

2023年初，JiaT75把XZ項目在Google的oss-fuzz工具上注冊的主郵箱改為了他個人的Gmail郵箱。

這一行為似乎暗示，他們想要第一時間接收到XZ項目中發(fā)現(xiàn)的漏洞報告，以此來及時知曉自己的惡意操作被揭露的情況。

2023年末，他們提交了一個新的合并請求（Pull Request），目的是在XZ項目的fuzzer配置中禁用「間接函數(shù)支持（Indirect function support）」。

這一操作似乎可以防止被fuzzer探測到，從而為在XZ項目中植入的后門做好鋪墊。