上週末，發生一起涉及XZ/liblzma的重大駭客攻擊事件，差點讓全球Linux都遭受供應鏈攻擊，幸好有開發人員調查SSH登入失敗及變慢500毫秒的狀況，偶然發現異狀，進而讓後門程式碼被揪出，及早揭露此項攻擊活動，因此目前影響範圍還算侷限，只有部分Liunx版本受影響。否則，一旦該後門程式碼進入穩定、主流的Linux發行版本，後果可是不堪設想。
許多資安專家紛紛指出，這起供應鏈攻擊事件相當不單純。
例如，攻擊者是從XZ Utils資料壓縮程式庫植入後門，利用軟體間的信任與依賴來打入Liunx環境，而該後門將可讓攻擊者繞過SSHD（Secure Shell Daemon）的身分認證機制。
而且，攻擊者將後門植入的整個過程，如同採取間諜潛伏、愛情詐騙的社交工程手法一般，攻擊者自2021年就註冊GitHub帳號，之後參與開放原始碼軟體專案xz的維護，以逐漸獲取其他開發人員的信任，直到2023、2024年才露出真面目，看似參與維護，實際行動卻是想要偷偷將惡意程式碼植入這個開放原始碼軟體。
顯然，如此精心設計的攻擊行動，很有可能是國家級駭客組織發起。如今，我們正持續看到有研究人員，從不同角度切入，或是分析後門程式碼，希望釐清攻擊全貌，以及試圖找出攻擊者的背景。
儘管整起事件的調查還沒結束，但已有許多重要議題正被探討，我們特別聯繫Linux軟體開發與資安方面的專家，請他們解讀目前這項資安威脅的概況，幫助大家掌握3大重要關鍵。
１.這次能及早發現，其實非常偶然且幸運
關於這起供應鏈攻擊的發現，最大功臣自然是微軟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毫秒的情況。
２.若是後門進入所有Liunx發行版本，後果不堪設想
這起事件之所以受到極大重視，是因為如果沒有及早發現，後果相當嚴重。幸好發現當下只有一些版本受到影響，尚未進入穩定、主流的Linux發行版本。
究竟影響範圍與具體影響有哪些？畢竟這次事件是鎖定軟體程式庫的供應鏈攻擊，而非直接對OpenSSH伺服器本身進行攻擊，手法相當複雜。
奧義資安研究團隊表示，如果一直都沒有發現的話，將是幾乎所有的Linux發行版都會受到影響。
而且，從這次後門的具體功能來看，主要是透過systemd干擾SSH（Secure Shell）的sshd常駐程式，最終使網路犯罪分子可以繞過SSHD身份驗證，並獲得未經授權的遠端存取系統。
林上智也指出，後果會是在進行OpenSSH身分驗證前，攻擊者可以執行特定封包，進而挾持OpenSSH伺服器，因為OpenSSH使用已遭汙染的liblzma程式庫。
整體而言，駭客攻擊的目標是，將惡意程式碼注入在受害者機器上運行的OpenSSH 伺服器（SSHD），並允許特定的遠端攻擊者（擁有特定私鑰）通過SSH發送任意酬載（Payload），這些酬載將在身份驗證步驟之前執行，從而有效地劫持整個受害者機器。因此，若是後門真的進入主流的Linux發行版本，屆時駭客可能發動相當大規模的劫持行動，進而造成前所未有的重大資安事件。
３.攻擊者竟長期潛伏以取得信任，引入後門的手法也非常隱密
這起事件的另一矚目焦點，是入侵過程相當複雜且難以察覺。
在事件揭露後，已有許多研究人員正追查其入侵手法，以及本次事件提交（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-12-29
2024-12-28
2024-12-28
2024-12-30
2024-12-28
2024-12-27
2024-12-30
2024-12-30