讓全世界手忙腳亂的Log4Shell漏洞,是怎麼成為噩夢的?

最近幾天,世超在各家網際網路大廠的程式設計師朋友們,都快被一個叫 Log4Shell 的史詩級漏洞給折磨瘋了!

這個漏洞源於一個叫 Log4J2 ( Log For Java 2 )的 Java 開源日誌框架,它在用 Java 敲程式碼的碼農群體裡可以說是無人不知,無人不曉。

它就好像早年間打《 魔獸世界 》一定要裝的大腳外掛一樣,屬於真正意義上的「咖啡伴侶」,很少有 Java 程式不用這個元件。

就是這麼一個要命的底層日誌框架,被發現透了一個洞。。。

最先發現漏洞的,是阿里雲安全團隊中,一位叫 Chen Zhaojun 的大佬。

據他的說法,這個漏洞很早就被國外的安全程式碼掃描平臺掃出來了,圈內的程式設計師大佬們也都在等待官方的修復,沒有聲張。

「上百萬刀的安全架構,在 Log4J2 漏洞面前一文不值。。。」 ▼

很快啊,一眾國內外的網際網路大廠紛紛中槍,都被圈在了受影響的範圍之內。

不僅僅是大廠的服務系統,耳機、電腦、車機等硬體系統等也無一倖免。。。

不誇張的說,這個漏洞要是不及時修補,下場就是被如飢似渴的駭客們捅爛,進一步威脅網路安全。

他們會有效利用 「 零日漏洞 」 ( 指的是發現後立即被惡意利用的安全漏洞 )發動零時差攻擊,搶在安全補丁出來之前,對伺服器造成殺傷。

就連我們日常使用的手機、電腦軟體( 大部分都是拿 Java 寫的 ),也都將暴露在駭客的的攻擊範圍內,想捅哪裡捅哪裡,把你的電腦挾持過來挖礦也不是沒可能。

就和打遊戲偷家似的, so easy 。。。

說回這次的漏洞,最可怕的地方在於實現起來沒什麼門檻,只要用一串簡單的字符,就能輕易攻破伺服器,並在上面運行各種程式碼。。。

這別說是竊取個人資訊了,駭客想要遠端挾持、癱瘓企業級的伺服器,那也是毫無阻礙。

那駭客到底是怎麼樣利用漏洞,用幾串字符就輕鬆攻破伺服器的呢?

要整明白這個問題,我們得先搞清楚啥是日誌

要整明白這個問題,我們得先搞清楚啥是日誌。

眾所周知啊,程式設計師在敲完一段程式碼之後,肯定不可能馬上拿來用,而要通過反覆的測試來驗證程式碼的可行性。

但程式碼本身在跑的時候,處於一個黑箱狀態,如果放任它瞎跑的話,跑到一半卡住,根本不知道是錯在哪一步上。

這就好像是做數學題時候如果沒草稿紙,在心裡算總是沒個底。

這時候,日誌的作用就體現出來了,它就好像是一大張草稿紙,能在上面做任何你自己看的懂得步驟和標記,方便隨時隨地驗算。

本質上日誌是程式設計師們經常使用的一個工具,它把程式碼在測試過程中的每一步都給記錄下來,跑完再回頭 Debug 的時候,就很有針對性,效率也高。

而 Log4J2 ,就是這麼一個開源的日誌框架,它裡面整合了不少在修改程式碼時會用到的常用功能,比如日誌管理、輸出變數等實用功能。

這次的高危漏洞就是源於 Log4J2 中一個叫 Lookups 的功能。

從字面上理解,這個功能就是一個用來搜尋內容的接口,想要搜些啥,那就要靠程式碼去實現了。

Log4J2 也在 Lookups 的功能下,提供了不少實現的途徑,問題就出在這個叫 JNDI 的途徑上。

JNDI 被 Java 允許通過遠端連接的方式來載入檔案,這個遠端地址可以是開發者自己的伺服器,也可以是外界的伺服器。

壞就壞在這個遠端下載上了。。

壞就壞在這個遠端下載上了。。。

駭客只要通過 JNDI 的方法連接上自己的惡意伺服器,就可以堂而皇之從這個接口進來,繼而攻破整棟固若金湯的大廈。

這裡世超用盡可能簡單的說法解釋了一下這個漏洞,如果差友們對具體的實現方式有興趣,可以看下知乎上軒轅之風大佬寫的這篇文章,介紹的很詳盡了。

https : //zhuanlan.zhihu.com/p/444103520

那麼問題來了,為什麼這個漏洞在被發現之後過了這麼久,才被重視起來?

外行看熱鬧,內行看門道,有些事兒還真得問問業內人士。

於是世超諮詢了國內知名的白帽網站——火線安全平臺的小火子同學,聊了一通之後,大致了解了專業人士對這件事兒的看法。

實際上 Log4J2 漏洞產生的原因,是因為部分程式設計師想要開發者保留在 Lookups 中 JNDI 的實現方式的舊功能而引起的。

根據 Log4J2 的維護者 Volkan Yazıcı 的說法,他們早就想把這個有風險的功能給去了,但為了保證向後的兼容性,照顧到想要用這個功能的程式設計師,所以還是保留了下來。

好嘛,小洞不補、大洞吃苦,這個高危漏洞被發現之後, Log4J2 實際的管理機構 Apache 軟體基金會並沒能引起足夠的重視,披露漏洞的流程也沒有按流程來走。

他們直接把問題往開源平臺 Github 的 issue 裡一貼,期待能有好心人給出解決問題得方案。

但這是個開放平臺啊,有程式設計師同樣也有駭客。。。

這波操作等於告訴了全世界的駭客: 「 咱這軟體有高危漏洞哈,歡迎來捅! 」

甚至在漏洞全面爆發之前,就已經有白客們在 issue 中公開討論過具體的修復細節。

可惜的是,等到所有用到使用 Log4J2 的業務系統反應過來有這個漏洞,已經過去了很長一段時間了。

因為使用 Log4J2 元件的軟體實在太多,所以網際網路公司的安全部門要一個個軟體做修復和升級,這裡頭的工作量也可想而知。

目前最快的臨時處理方案,是在 Log4J2 做一個觸發式的攔截程序,類似於給系統先打上疫苗,把與漏洞相關內容,提前進行阻攔,和防火牆的原理差不多。

話說回來,世超覺得引發這次漏洞問題的鍋,也不應該全由 Log4J2 的維護者來背。

說出來你可能不信,像 Log4J2 這麼大一個開源項目,實際只靠幾個程式設計師在業餘時間來管理和維護,他們本身也是用愛發電,沒有任何報酬的。

來自 Volkan Yazıcı 推特下網友們的評論

與之相反的是,包括像蘋果、谷歌、亞馬遜、特斯拉在內的這些大公司,都一定程度上在開心的 「 白嫖 」 Log4J2 ,畢竟開源嘛,能省一點人力維護就省一點,反正總會有人維護的。。。

對於大廠開發者來說,這個來自十幾年前僅有數人在維護的工具,只要能夠完成產品,那湊合用就湊合用了,絕不重複造輪子。

並且爭取在出現問題之前,成功跳槽。。。

可想而知,人人對於這類程序安全漏洞始終都是 「 碰到了才明白出了問題 」,誰知道整個行業都翻了車。

儘管事兒已經是告一段落了,但這樣大型的漏洞翻車事件,並不是第一次,也不會是最後一次發生,此類的 「 黑天鵝事件 」 ,往往是不可預估且偶發性的。

而這一場場在網路世界中燃起的大火,唯有依靠程式設計師們的挑燈夜戰,才得以熄滅。

相關文章

詳解同軸線的射頻參數

詳解同軸線的射頻參數

在《為什麼是50歐姆》文章中,我們引入了同軸傳輸線這個例子,同軸傳輸線是射頻設計和測試中應用最為廣泛一種射頻傳輸線,同軸線到底怎麼計算?今天...

日誌VS網路資料,誰能做好全鏈路監控?

日誌VS網路資料,誰能做好全鏈路監控?

對系統的運行狀態進行監控,是IT工程師的一項重要工作。 如果不能確保整個系統及其鏈路處於穩定運行的狀態,那麼,企業的業務穩定發展就無從談起。...