上週末,發生一起涉及XZ/liblzma的重大駭客攻擊事件,差點讓全球Linux都遭受供應鏈攻擊,幸好有開發人員調查SSH登入失敗及變慢500毫秒的狀況,偶然發現異狀,進而讓後門程式碼被揪出,及早揭露此項攻擊活動,因此目前影響範圍還算侷限,只有部分Liunx版本受影響。否則,一旦該後門程式碼進入穩定、主流的Linux發行版本,後果可是不堪設想。
許多資安專家紛紛指出,這起供應鏈攻擊事件相當不單純。
例如,攻擊者是從XZ Utils資料壓縮程式庫植入後門,利用軟體間的信任與依賴來打入Liunx環境,而該後門將可讓攻擊者繞過SSHD(Secure Shell Daemon)的身分認證機制。
而且,攻擊者將後門植入的整個過程,如同採取間諜潛伏、愛情詐騙的社交工程手法一般,攻擊者自2021年就註冊GitHub帳號,之後參與開放原始碼軟體專案xz的維護,以逐漸獲取其他開發人員的信任,直到2023、2024年才露出真面目,看似參與維護,實際行動卻是想要偷偷將惡意程式碼植入這個開放原始碼軟體。
顯然,如此精心設計的攻擊行動,很有可能是國家級駭客組織發起。如今,我們正持續看到有研究人員,從不同角度切入,或是分析後門程式碼,希望釐清攻擊全貌,以及試圖找出攻擊者的背景。
儘管整起事件的調查還沒結束,但已有許多重要議題正被探討,我們特別聯繫Linux軟體開發與資安方面的專家,請他們解讀目前這項資安威脅的概況,幫助大家掌握3大重要關鍵。
1.這次能及早發現,其實非常偶然且幸運
關於這起供應鏈攻擊的發現,最大功臣自然是微軟PostgreSQL開發人員Andres Freund。因為他在調查SSH登入異常與變慢相關問題時,最初以為發現debian裡面的套件包被入侵,但調查發現是上游的問題,XZ程式庫與XZ的tarball檔案被植入後門。
對於當中一些細節,我們找到Andres Freund在社群網路Mastodon平臺的發文,並與身為Debian官方開發者、現於Bureau Veritas擔任首席資安專家一職的林上智一同探討,以還原發現經過。
具體而言,Andres Freund是在使用Debian開發版本sid(unstable)測試時,發現SSH登入有占用大量CPU資源的情形,進而對SSHD進行分析,發現XZ Utils資料壓縮程式庫的liblzma中有消耗大量CPU時間的情形 , 但是透過Linux上的效能分析工具perf檢視,卻找不到相對應耗費運算的函式或者相關原因。
這樣的狀況,使Andres Freund產生了懷疑,他回想起幾週之前,在軟體包更新後,曾在進行PostgreSQL自動化測試的過程中,發現了一些由Valgrind回報的記憶體異常錯誤結果。林上智認為,看起來是他在執行CI/CD時,發現valgrind錯誤。
後續,Andres Freund回報了這項問題後,才使得這起供應鏈攻擊的面紗被揭開。
為何會去關注SSH登入時的CPU異常?我們找到Andres Freund在社群網路Mastodon平臺的貼文與留言,他表示當時是在做一些微基準測試,需要讓系統靜止以減少噪音,所以才會發現SSHD的處理程序(processes)占用大量CPU資源。同時他也認為,自己並非資安研究人員,能發現這起攻擊事件,確實需要很多巧合。
對於這次事件的偶然發現,使得XZ存在漏洞、被植入後門的問題及早浮現於檯面,不只受到開發圈的關注,還有許多資安研究人員都在關注,因此我們也詢問臺灣資安業者奧義智慧。
奧義資安研究團隊表示:「這次事件算是非常幸運。」因為有了提早的發現,所以目前只影響一小部分的Linux發行版。
因此大家都很感謝Andres Freund,能在測試時發現SSH異常狀況(登入失敗與登入速度變慢)後,進一步往上游追查,發現問題存在於liblzma之中,讓IT界與資安界可以及早發現此漏洞與潛藏的供應鏈攻擊。
綜觀上述說法,我們可以發現,除了有開發人員產生警覺並願意去追查,從另一面向來看,也是因為該惡意活動可能有Bug,導致出現占用大量CPU資源的情形,才讓開發人員有發現的機會。甚至,國際間有資安人員臆測這是否並非個案,其他只是還沒發現。
之所以會進一步調查SSH登入異常,我們找到Andres Freund的說法,他在社群平臺X上的一篇回應中指出,他是在嘗試使用隨機帳密組合的自動化嘗試下,發現SSH登入失敗、佔用大量CPU資源的情形下,開始進一步調查,之後才發現登入速度變慢500毫秒的情況。
2.若是後門進入所有Liunx發行版本,後果不堪設想
這起事件之所以受到極大重視,是因為如果沒有及早發現,後果相當嚴重。幸好發現當下只有一些版本受到影響,尚未進入穩定、主流的Linux發行版本。
究竟影響範圍與具體影響有哪些?畢竟這次事件是鎖定軟體程式庫的供應鏈攻擊,而非直接對OpenSSH伺服器本身進行攻擊,手法相當複雜。
奧義資安研究團隊表示,如果一直都沒有發現的話,將是幾乎所有的Linux發行版都會受到影響。
而且,從這次後門的具體功能來看,主要是透過systemd干擾SSH(Secure Shell)的sshd常駐程式,最終使網路犯罪分子可以繞過SSHD身份驗證,並獲得未經授權的遠端存取系統。
林上智也指出,後果會是在進行OpenSSH身分驗證前,攻擊者可以執行特定封包,進而挾持OpenSSH伺服器,因為OpenSSH使用已遭汙染的liblzma程式庫。
整體而言,駭客攻擊的目標是,將惡意程式碼注入在受害者機器上運行的OpenSSH 伺服器(SSHD),並允許特定的遠端攻擊者(擁有特定私鑰)通過SSH發送任意酬載(Payload),這些酬載將在身份驗證步驟之前執行,從而有效地劫持整個受害者機器。因此,若是後門真的進入主流的Linux發行版本,屆時駭客可能發動相當大規模的劫持行動,進而造成前所未有的重大資安事件。
3.攻擊者竟長期潛伏以取得信任,引入後門的手法也非常隱密
這起事件的另一矚目焦點,是入侵過程相當複雜且難以察覺。
在事件揭露後,已有許多研究人員正追查其入侵手法,以及本次事件提交(Commit)的GitHub帳號。
例如,從涉及此事件提交的GitHub帳號來看,攻擊者似乎是在2021年就註冊一個GitHub帳號用戶,其代號為Jia Tan(JiaT75),該帳號先是在2022年2月6日,首度提交內容至XZ程式庫,後續竟然悄悄將惡意程式碼埋常其中,例如,其中bad-3-corrupt_lzma2.xz與good-large_compressed.lzma這兩個看起來無害的測試用binary,會在特定條件下解析出惡意程式。
因此,在這次供應鏈攻擊中,我們整理出目前最值得注意的3個重點:
(一)駭客鋪陳這起供應鏈攻擊行動,看起來已潛伏長達3年之久
關於攻擊者的入侵過程,宛如間諜行動的社交工程手法一般,從3年前就開始準備,之後積極參與xz項目的維護,逐漸獲取原始項目開發人員的信任,直到近期才開始將軟體加料,而且其手法相當難以察覺。
這也顯現攻擊者有著超乎尋常的耐心,經歷這樣長時間的滲透,花了兩年多時間取得信任,讓自己可以成為合法的維護者。這也讓外界紛紛推測,如此精心設計的攻擊行動,非常有可能是由國家級駭客組織發起。
因此,目前許多研究人員正在追查相關線索,而且攻擊者似乎也在使用的代號上做出混淆,取了一個很像中文拼音的代號,但有研究人員從時區角度切入去追查,猜測攻擊者可能是位於東歐。不過這些都還在調查中,還有像是關於後門程式的逆向分析等,也有待後續有研究人員一一揭露。
(二)加入後門的手法相當隱密,提交的測試資料在特定條件下才會解析出惡意程式
關於攻擊者的入侵過程與方式,奧義智慧資安研究團隊說明了他們的觀察。
首先,攻擊者的確是從2021年就註冊了GitHub帳號,並多次提交測試相關的程式碼,因此逐漸取得XZ Utils主要專案開發者的信任。
但值得注意的是,Jia Tan在每個送出的提交(commit)中,都帶有片段的後門程式,但是,只有特別在XZ要進行打包編譯release出去時,才會加進編譯的過程中。
為什麼會有這樣的情形?為什麼攻擊資料可以成功偽裝成測試資料,並且不受到像是Lanlock等process access control防禦機制作業系統的防禦機制的檢查,並且直接編譯原始碼時還不會加入編譯的過程。
奧義智慧資安研究團隊解釋,這裡有一個特殊的關鍵:攻擊者在一個很隱密的地方,加上了一個看似不小心多打出的句點「.」。但是,就是因為一個普通的句點,造成了解析上的差異。
基本上,例如在使用CMake進行編譯時,為了確認某個編譯器是否可以使用,通常會嘗試編譯一小段程式碼,而攻擊者特意寫出一段有錯誤的程式碼,這就是開頭那個小句點需要出現的原因,編譯器會因為編譯出錯,誤認為此沙盒(Lanlock)的測試是不存在的,所以就會停用。
這個可以跳過沙盒的CMake並推上正式版本,後續即可推後面程式上去,並可以跳過檢查,攻擊者就可以在下一版往(Lanlock)的部分加入任何程式碼,而不會受到檢查。且攻擊者也會挑選快要release的時間提交(commit)他的程式碼上去,盡量減少被人發現的機會。
(三)提交時間點巧妙,避過原始維護者的審查
對於攻擊者事件,凱特納科技創辦人兼CEO曾信田(Newbug)也提供一些重要觀察,他表示,這事件的影響範圍在debian/ubuntu/fedora/opensuse testing 版的x86-64 sshd,攻擊時間鎖定在原始XZ維護者Lasse Collin(Larhzu)處於休息離線(internet breaks)的時間發動攻擊。
他特別指出,這個問題是審查commit時的疏忽,算是一種信任感攻擊,由於原始維護者在這段休息期間無法審查(review)程式碼,而導致惡意程式碼被整合於其中。
因此他認為,在程式碼commit時,或許可以導入AI進行程式碼審查(code review),避免因為人員的疏忽,或是程式碼審查上的疲累,而導致惡意程式碼被接受。他也慶幸,還好惡意酬載(payload)有CPU資源佔用飆升的Bug,而被及早發現,才沒汙染到穩定版。
開源貢獻者需要實名制嗎?
在上述3大焦點之外,由於這次事件是開發人員在使用Debian開發版本sid(unstable)測試時發現異常而調查,加上涉及攻擊者偽裝成正常開發人員潛伏,因此,林上智還提供了另一面向的觀察角度,也就是Debian官方開發者社群對此事的後續探討。
首先,最主要的焦點是,由於Debian開發者需使用unstable進行套件打包上傳至unstable archive,因此,Debian開發者所使用的開發機器需要盡速更新。
不過,還一個衍生討論的議題,是關於Debian開發者社群對於貢獻者的身分驗證,其實早已有嚴格的要求與規範,但這次事件發生後,是否要有更嚴格的機制,像是開源貢獻者的實名制問題,即受到探討。
事實上,由於開源貢獻者來自世界各地,很難去辨別其背後身分,因此過去Debian開發者需要需要層層審核跟檢驗,累積貢獻後才能進行申請。
例如,在成為Debian官方開發者之前,需要申請成為Debian維護者,而申請的第一步就是要做到身分識別(Identification),這方面的要求是需要面對面的情形,至少跟一位Debian官方開發者交換PGP key(keysigning),並在交換key時需核對對方的官方證件,通常是會核對護照,以確保該人員的身分。現在則是則對實名制有更進一步的討論。
林上智解釋,這方面的相關討論還在進行中,因為有的Debian開發者認為,如果是國家級的攻擊,那該國家也可以幫忙製作假ID或者假的身分證明,所以實名制對抵擋國家級的攻擊較沒有意義;不過也有的人認為,攻擊者不太喜歡曝光於外界,或被看到真面目,如果要面對面交換key,這多少可以嚇阻有心人士。
至於從其他開源生態的動向來看,已經有些專案這麼做,例如:GCC專案要求貢獻者一律實名制,以及Linux kernel禁止匿名貢獻的情形。林上智也以自身經驗為例,過去他在送kernel patch時,曾有一度被kernel maintainer退件,後來才知是因為名字有中文,但對方的機器不支援中文編碼,因此顯示不出來,導致對方以為他是匿名貢獻者。
無論如何,這很可能也是所有開源軟體界,都有在面對的挑戰與議題。
熱門新聞
2024-09-29
2024-10-01
2024-10-01
2024-09-29
2024-10-01
2024-09-30
2024-09-30