作者：p4nda
原文鏈接：https://mp.weixin.qq.com/s/ckRnClp6a7LDQgCaSPR0qQ
寫在前面
昨晚推特上一條博文引起了圈內的大量關注
夭壽啦！log4j 2.17.0 可以RCE 啦！！
然鵝：
噓……
圈內人士噓聲一片……
修改配置文件 RCE？？就這就這？？？
那么修改配置文件來RCE到底是怎么“流行”起來的呢？
因
這件事還要從 Log4j 2 的 RCE 說起
在log4j2 的 GitHub項目有個 Pull：
https://github.com/apache/logging-log4j2/pull/608
一位叫“TopStreamsNet”的老外提到：
如果您查看 jndi 在 1.x 中的工作方式，您會發現有兩個地方可以完成查找 - 即 JMSAppender.java:207 和 JMSAppender.java:222 - 如果您將 TopicBindingName 或 TopicConnectionFactoryBindingName 設置為 JNDI 可以處理的內容 - 例如“ldap://host:port/a”JNDI 將做與 2.x 完全相同的事情 - 所以 1.x 是易受攻擊的，只是攻擊向量“更安全”，因為它取決于配置而不是用戶 輸入
然后通過配置文件 RCE 的這件事就開始討論起來了
特別是 Log4j2 的作者回復到：
如果攻擊者可以修改某個系統 S 上的配置文件，那么可以假設 S 已經被很大程度地滲透了。 如果攻擊者可以修改 log4j.properties (log4j 1.x)，她就不需要下載惡意代碼，她可以輕松地將惡意類文件放在類路徑中并讓它們執行。 因此，在非常嚴格的意義上，log4j 1.x 中存在漏洞，但與日志參數引起的 RCE 沒有任何關系。
實際上可以看得出來，Log4j2 的作者一開始并不認同這個老外的觀點，但有意思的來了
就在大家認為這個“漏洞”不是漏洞的時候，RadHat 出來作妖了：
https://access.redhat.com/security/cve/CVE-2021-4104
他們把這個由配置文件引起的 RCE 定義為漏洞，并且給了cvss v3 7.5的中危評分！
然后有人又在 log4j2 那個 pull 下面回復了：
路人：看，你看，RedHat 發了一個 CVE，而且還是7.5的評分！（實際上一開始給了 8.0）
當然，也有人回復到：
路人：TMD，ReaHat 你不懂規矩，不講武德，人家 log4j 官方都沒發話呢，你出來搞什么事情
后來迫于壓力下，log4j 認了這個 CVE
我們決定保留 Red Hat 分配的 CVE，以節省創建另一個并拒絕他們的 CVE。
log4j 官方：行了行了，我認，我認還不行嗎
至此，由log4j 在 pull 上討論出的第一個 由配置文件引發 RCE的 CVE 被 RedHat折騰出來了
果
在log4j1 這個 CVE 發布前，實際上我就對“TopStreamsNet”這位老外提出的看法進行了研究：
TOP log4j 1.x 與 logback 的雞肋RCE討論：
https://www.cnpanda.net/sec/1131.html
并且我發現實際上log4j 1.x 的配置文件 RCE 并不能立刻生效，因為修改 log4j 1.x 的配置文件需要重新加載后才可以生效，在生產環境下誰閑著沒事主動重啟或者重新加載配置文件？
但 logback 不太一樣，因為 logback 有個 scan 屬性，可以自動掃描配置文件是否發生了改變，如果發生了改變，那么就會自動更新配置文件。所以研究的時候寫了一個 SpringBoot 的演示Demo 發到了 GitHub 上。
湊巧的是，在 logback 的官方 issue 上看到一個提問，大意是 logback 中是否存在RedHat 發布的那個漏洞，然后我回復了之前那個SpringBoot 演示 Demo 的地址，后來 logback的作者也給分配了CVE-2021-42550，還發郵件問我要不要 credit
老外還是熱心的，但是我覺得這漏洞本身限制很大很雞肋，而且 @香依香偎 師傅在一年前就提出了這個利用方式：
所以我拒絕了credit。
后來通過 @TiGer 師傅得知得知這個 logback 漏洞實際上出現過實際例子的利用：
可以參考：https://www.cnblogs.com/zpchcbd/p/15542705.html
總結
回過頭來看看這個log4j 2.17.0 的配置文件 RCE，確實有點離譜，因為修改完配置文件后，它不像 logback 一樣可以實時生效，屬于雞肋中的雞肋了。
實際上 @pwntester 大神也說了：
大多數使用數據庫的 Java 應用程序都有配置文件，您可以在其中指定 JNDI 地址以獲取 JDBC 數據源
簡單搜索發現，可以通過 JNDI設置配置文件的部分應用如下：
jetty
https://wiki.eclipse.org/Jetty/Feature/JNDI#Configuring_JMS_Queues.2C_Topics_and_ConnectionFactories
Apache ODE
https://ode.apache.org/using-a-jndi-datasource-under-servicemix-jbi.html
Apache Shrio
https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/jndi/JndiTemplate.html
https://www.programmerall.com/article/1371213168/
Tomcat
https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html
TomEE
https://tomee.apache.org/jndi-names.html
SpringBoot
https://blog.roncoo.com/article/133919
等等等
太多太多了，實際上正如@pwntester說的那樣，JNDI 類似于在一個中心注冊一個東西，以后要用的時候，只需要根據名字去注冊中心查找，注冊中心返回你要的東西。比如在 web應用中，我們可以將一些東西（最常用的就是數據庫相關的配置信息）交給服務器軟件去配置和管理，在程序代碼或者配置文件中只要通過名稱查找就能得到我們注冊的東西，而且如果注冊的東西有變，比如更換了數據庫，我們只需要修改注冊信息，名稱不改，因此代碼也不需要修改。
這是SUN公司提供的一種標準的Java命名系統接口，是一種特性，因此一般來說，只要存在 JNDI 的地方，都能夠利用 ldap 協議去實現 RCE，當然，不僅僅是 ldap 協議，實際上還有很多可用的協議：
總之，我認為log4j 2.17.0這個 CVE，分配了就算了，但過分的是，這老外還好意思發表在推特上來說log4j 2.17.0又出 RCE 漏洞（刷洞就刷洞，還吆喝一嗓子，結果還是這漏洞，不是讓別人像吃了屎一樣難受嗎）
一句話總結：通過配置文件來實現 RCE，只能說是一種攻擊手段，而不能說是一種常規漏洞。
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1802/
暫無評論