為何會去關注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出去時，才會加進編譯的過程中。

為什麼會有這樣的情形？使得攻擊資料可以成功偽裝成測試資料，並且直接編譯原始碼時還不會加入編譯的過程。

奧義智慧資安研究團隊解釋，這裡有一個特殊的關鍵：攻擊者在一個很隱密的地方，加上了一個看似不小心多打出的句點「.」。但是，就是因為一個普通的句點，造成了解析上的差異。

基本上，例如在使用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，而被及早發現，才沒汙染到穩定版。

Debian社群有實名制等衍生性討論

在上述3大焦點之外，對於Debian官方開發者社群而言，林上智表示，在這次事件後，也引發了一些衍生性的討論。

例如，最主要的焦點是，由於Debian開發者需使用unstable進行套件打包上傳至unstable archive，因此，Debian開發者所使用的開發機器需要盡速更新。

還有一些衍生的安全議題，像是開源貢獻者的實名制問題探討。

事實上，由於開源貢獻者來自世界各地，很難去辨別其背後身分，因此過去Debian開發者需要需要層層審核跟檢驗，累積貢獻後才能進行申請。

例如，在成為Debian官方開發者之前，需要申請成為Debian維護者，而申請的第一步就是要做到身分識別（Identification），這方面的要求是需要面對面的情形，至少跟一位Debian官方開發者交換PGP key（keysigning），並在交換key時需核對對方的官方證件，通常是會核對護照，以確保該人員的身分。現在則是則對實名制有更進一步的討論。

林上智解釋，這方面的相關討論還在進行中，因為有的Debian開發者認為，如果是國家級的攻擊，那該國家也可以幫忙製作假ID或者假的身分證明，所以實名制對抵擋國家級的攻擊較沒有意義；不過也有的人認為，攻擊者不太喜歡曝光於外界，或被看到真面目，如果要面對面交換key，這多少可以嚇阻有心人士。

至於從其他開源生態的動向來看，已經有些專案這麼做，例如：GCC專案要求貢獻者一律實名制，以及Linux kernel禁止匿名貢獻的情形。林上智也以自身經驗為例，過去他在送kernel patch時，曾有一度被kernel maintainer退件，後來才知是因為名字有中文，但對方的機器不支援中文編碼，因此顯示不出來，導致對方以為他是匿名貢獻者。