Log4j事件突顯開源窘境:財富500強企業想“白嫖”技術支持

cURL 創造者 Daniel Stenberg 近日收到了一封來自《財富》美國 500 強企業的電子郵件,被要求回答很多關於 cURL
是否受到 Log4Shell 漏洞影響以及如何處理的問題。
該公司(或其客戶)可能正在使用 cURL,於是提出了包括 cURL 是否依賴
log4j 等問題。

0pjmb27j.webp

隨後他將這封郵件截圖分享到社交媒體上,他在推文中調侃的寫道:

如果你是一家價值數十億美元的公司,並且你關注 log4j,為什麼你不直接給那些你從未支付過任何費用的 OSS 作者發一封電子郵件,並要求在 24 小時內回復來免費提供大量信息?

12 月 9 日,Apache log4j 日誌庫中發現一個漏洞。這個庫被廣泛用於 Java/J2EE 應用開發項目和基於 Java/J2EE 的現成軟件解決方案的供應商。

Log4j 包括一個搜索機制,可用於通過格式字符串中的特殊語法進行查詢。例如,它可以用來查詢各種參數,如通過${java:version}查詢Java環境的版本,等等。然後,通過在字符串中指定jndi鍵,搜索機制使用JNDI API。

默認情況下,所有的查詢都是使用 java:comp/env/* 前綴進行的;但是,作者已經實現了通過在鍵中使用冒號的方式來使用自定義前綴的選項。這就是漏洞所在:如果 jndi:ldap:// 被用作密鑰,請求就會轉到指定的LDAP服務器。其他通信協議,如LDAPS、DNS和RMI,也可以被使用。

因此,由攻擊者控制的遠程服務器可以將一個對象發回給有漏洞的服務器,有可能導致系統中的任意代碼被執行或機密數據被泄露。攻擊者需要做的就是通過機制發送一個特殊的字符串,將這個字符串寫入日誌文件,因此由Log4j庫處理。這可以通過簡單的HTTP請求來實現,例如,通過網絡表格、數據字段等發送的請求,或使用服務器端日誌的任何其他類型的互動。

該漏洞被 Tenable 描述為“過去十年中影響範圍最廣、影響程度最嚴重的漏洞”

cURL(client URL 請求庫的簡稱)是一個命令行接口,用於檢索可通過計算機網絡訪問的資源的內容。該資源是用一個 URL 指定的,而且必須是軟件支持的類型。該軟件允許創建或修改資源(與wget不同),因此它可以作為一個REST客戶端使用。

cURL 程序實現了用戶界面,它是基於libcurl軟件庫,用C語言開發。這使得那些希望在其程序中擁有網絡訪問功能的開發者可以使用它。許多語言(C++、Java、.NET、Perl、PHP、Ruby…)都創建了接口。

該庫支持 DICT、文件、FTP、FTPS、Gopher、HTTP、HTTPS、IMAP、IMAPS、LDAP、LDAPS、POP3、POP3S、RTSP、SCP、SFTP、SMB、SMBS、SMTP、SMTPS、Telnet 和 TFTP。

Screenshot 2022-01-26 at 10-55-29 LogJ4 Security Inquiry – Response Required daniel haxx se.webp

在一篇博文中,cURL 開發者 Daniel Stenberg 收到了一家市值進入財富 500 強的公司。他寫道

2022 年 1 月 21 日星期五,我收到這封電子郵件。我在Twitter上說了這件事,然後它就上了熱搜。

這封郵件來自一家價值數十億美元的財富 500 強公司,該公司或者他們的客戶正在使用我的代碼構建產品。

我想他們這樣做是出於合規性的考慮,並“忘記”了他們的開源組件並不是由“合作夥伴”自動提供的,他們只需向其索取這些信息即可。

我非常簡短地回復了這封電子郵件,並說一旦我們簽署了支持合同,我將很樂意回復細節。

我認為這也許是開源金字塔的一個很好的例子,處於最上層的用戶完全沒有考慮到下層的維護方式。建造房子而不關心地基。

在他的推文和博文中,他刪除了該公司的名稱,並給出了理由:“我很可能有權告訴你他們是誰,但我寧願不說。(特別是如果我能夠與他們達成有利可圖的商業交易。)我認為我們可以在許多公司中找到這種程度的權利”。

他繼續說:

這一封郵件中所表現出的無知和無能程度令人震驚。

雖然他們甚至沒有具體說他們使用的是什麼產品,但我所參與的或有版權的代碼都沒有使用 log4j,任何初學者或更好的工程師都可以輕易地驗證這一點。

在電子郵件的圖片版本中,我修改了姓名欄,以更好地匿名發件人,在下面的文本中,我用 NNNN 替換了它們。(是的,他們現在在 log4j 上發送請求,顯然是非常晚了,這是非常奇怪的)。

QQ截圖20220126105716.webp

在電子郵件中,該公司要求 Daniel Stenberg 回答如下問題

1. 如果你的任何應用程序使用 Java 日誌庫,那麼運行的 Log4j 是什麼版本?

2. 你的公司是否發生過任何經證實的安全事件?

3. 如果是這樣,哪些應用程序、產品、服務和相關版本受到影響?

4. 是否有任何 NNNN 產品和服務受到影響?

5. NNNN 的非公開信息或個人信息是否受到了影響?

6. 如果是,請立即提供受影響的 NNNN 信息的細節。

7. 完成更正的時間框架是什麼(MM/DD/YYY)?列出步驟 NNNN,包括每個步驟的日期。

8. NNNN 需要採取什麼行動來完成這一更正?

從這件事情可以看出,目前確實存在大型企業根本不關心底層項目,甚至不了解底層項目如何運轉的情況,這些企業在自己不怎麼在意的底層項目基礎上構建自己的商業項目,並以此賺取了非常可觀的利潤。

不光如此,Log4j 安全漏洞事件已發酵近兩個月時間,郵件中列出的不少問題都是公開可查詢到的信息,企業安全部門只需隨手在搜索引擎里一搜就能獲得答案。