2022年01月11日 10:00
【科學快訊】
想象一下，如果有個建築工程師突然發現，我們蓋樓用的釘子隨時都會斷裂，而幾乎每棟樓都使用了這樣的釘子時，會是怎樣的場面？在過去的一個月裡，軟體行業就經歷了一場這樣的危機。
撰文|索菲·布什威克（Sophie Bushwick）
編譯|鄭昱虹
審校|王昱
2021年11月24日，Apache軟體基金會收到了一封郵件，發件人是阿里雲安全團隊的程式設計師Chen Zhaojun。他在郵件中指出，由Apache維護的一個軟體存在重大的安全漏洞，駭客可以利用這個漏洞，對他人的電腦進行遠端操控。
這個軟體是Log4J，它是一個用於記錄日誌的JAVA庫。因為其開源的性質，Log4J遍佈整個軟體行業，被廣泛用於記錄使用者名稱、密碼和信用卡交易等細節。所以蘋果iCloud、亞馬遜雲服務、Minecraft（我的世界）遊戲、推特等商業公司，以及一些政府機構，全部受到了這個之後被命名為「Log4Shell」的漏洞的影響。
因此，12月9日Log4Shell面向社會公佈時，整個軟體行業都為之震動。由於危害大且波及範圍廣，Apache對這個漏洞給出了10分的CVSS（通用漏洞評分系統）評分，而10分是表示「嚴重」的最高分。
自發現該漏洞以來，網路安全工程師爭分奪秒地保護應用程式、服務、基礎設施和物聯網裝置，但犯罪分子已經在利用這個漏洞了。部分Minecraft使用者受到了勒索軟體攻擊，微軟檢測到了下載和執行「挖礦」軟體、竊取身份資訊等行為，比利時國防部因受到攻擊而關閉了部分計算機網路……
「對網路罪犯來說，這就像是提前到來的聖誕節禮物。他們沒有底線，限制他們的只有他們自己的技術水平。」前白宮資訊長、網路安全諮詢公司Fortalice Solutions的執行長特蕾莎·佩頓（Theresa Payton）說。
在Log4J 維護者團隊幾乎無償的緊急工作下，Apache於2021年12月6日針對Log4Shell進行了修復，但沒能完全解決問題，又在12月13日、17日和27日分別針對新發現的問題釋出了新版本。但是，這場風波造成的影響很可能仍未平息。
Log4J作為網際網路基礎設施的一個關鍵組成部分，一些數百萬乃至數十億體量的公司依賴它獲利，然而它只是一個志願者建立的，並且很大程度上是免費執行的專案。如果進展順利，開源就是合作的勝利；而一旦出了問題，就會產生深遠的危險。這次的危機揭示了開源軟體的困境，暴露了整個網際網路行業的供應鏈安全問題。
去年12月15日，《科學美國人》釋出了對佩頓的採訪，她談到了Log4J的功能、駭客將如何利用漏洞Log4Shell、以及如何修復這個漏洞。以下是經過編輯的採訪文字記錄。
Log4J是什麼？它被用在什麼地方？
技術和網路安全團隊需要「日誌」功能。日誌可以用於審計追蹤（audit trails），比如出於監管考慮，在發生勒索軟體事件時進行取證。而Log4J就是一個用於記錄日誌的Java程式。它可以記錄任何數量的、任何型別的事件，比如某人使用某種型別的信用卡，或某人今天登入了，等等。
但是，Log4J存在一個嚴重的安全漏洞。
這個漏洞的存在，使得有人可以向日志中新增指令，讓日誌執行任何操作。研究人員在12月初發現了這個漏洞（Apache得知這個漏洞的時間是11月24日，但是向公眾公開在12月9日），謝天謝地。大體來說，這個漏洞允許攻擊者在未經身份驗證的情況下，透過遠端程式碼訪問伺服器。他們可以傳送指令、執行指令，並且可能完全不被發現。
已經有攻擊者利用Log4J的漏洞，在機器的主人不知情的情況下，給一些機器安裝了挖掘加密貨幣的惡意軟體。回想一下物聯網被Mirai殭屍網路佔領的經歷，Mirai殭屍網路看起來也在試圖利用物聯網。
網路罪犯還可以利用這個漏洞做什麼？
網路罪犯可以在日誌中新增一條指令：「當記錄使用者的登入憑據時，也將它們傳送到我這裡。」這樣一來他們就能獲取使用者的登入憑據。他們可以建立個性化的指令，對日誌進行操控。
日誌記錄著幾乎所有的內容，比如登入資訊、信用卡資訊、支付資訊。所以就看開發人員決定如何利用日誌的特性和功能了——日誌中有什麼型別的資料，以及這些資料是否被加密。
問題是，對日誌有沒有保護？是否有任何方式監控日誌本身是否有異常行為？如果一個組織不去主動尋找異常行為，他們就不會注意到使用者名稱和密碼不僅被記錄在日誌中，也被髮送到了其他地方。
在安全團隊爭分奪秒地尋找漏洞、打補丁、修復、觀察、記錄並試圖解決問題的時候，網路罪犯則利用這些漏洞，分享資訊並製造不同的攻擊。很有可能會出現一種犯罪軟體服務，供網路罪犯和非技術人員使用。
對於不從事網路安全工作，但日常使用應用程式和服務的普通人來說，這意味著什麼？
普通人的身份可能會被盜竊。你嘗試登入某個網站的時候，可能會發現他們暫停服務了，那他們可能正在處理這個問題。比如你可能無法聯絡政府機構核實退款或繳稅，因為有人透過Log4J的漏洞損害了這些功能。
現在還很難說事態會如何發展，因為我們尚未完全理解這個問題。這個漏洞可能會影響很長時間，並不是說「週末打好所有補丁，然後我們就可以回家過聖誕節了」。
如何化解這次的危機？
類比一下，房屋、大廈、橋樑等建築物上都用到了某種釘子。如果有人說：「我們剛剛意識到，這種釘子存在弱點，它們可能會隨時失效」，不過建築使用的釘子有很多種，我們必須弄清楚「這種」釘子都用在了哪裡，並要求建築公司在釘子失效之前找到並更換它們。
大公司和大量網際網路基礎設施現在必須在他們的系統中排查Log4J。由於程式碼通常沒有一幅詳細的藍圖，所以要想準確地知道其中都在哪裡用到了某個日誌功能，無異於大海撈針。
通常，當我們發現安全漏洞時，網路安全工程師可以全權負責修復，但這次的漏洞不同，它是整個供應鏈的問題：很多人在程式碼中使用了開源的、第三方提供的和離岸開發的系統，而所有的系統都有可能使用了Log4J。
以某種物聯網裝置為例（如Alexa或Google Home），它的供應鏈可能涉及10到50至60家不同的公司，分別負責韌體、作業系統和應用程式的開發。所以僅僅為一款產品修復漏洞，就可能是一項極其艱鉅的任務。
我們能從這次的漏洞中學到什麼？
2020年末我們遭遇了SolarWinds的供應鏈事故，那時很多人覺得自己不使用SolarWinds就沒事。但事實上，只要處在一個使用了SolarWinds的生態中就存在風險，你需要向內部、離岸、近岸和外包的開發者瞭解他們是否使用了SolarWinds的軟體生成的清單。
我們透過慘痛的教訓明白了，編譯軟體和對軟體進行質量保證，是非常複雜和困難的事情，並且我們並非每次都能跟進其中的重要細節。
我們可以從這些事故中學到的是，我們的供應鏈存在、並且會繼續存在弱點，所以這不會是最後一次出問題。當問題出現時，你需要知道該把哪些人召集到一起，評估這個問題對你們來說是非同小可的，還是無足輕重的。
從業者還需要思考的是，你們建立了哪些自動防故障裝置？例如，如果攻擊者在你打補丁之前就利用了你的日誌和日誌中的資訊，你能發現他們的蹤跡嗎？
這些都是我學到的教訓，而且都是艱難的教訓。我是說，如果這些問題容易解決，企業和政府早就解決了，不過紙上談兵容易，在實際操作中卻很難。
參考連結：
