針對Log4j漏洞的總結，以及看到一些有意思的點分享一下。
ps:本來計划周五晚上發，實在太累，周六才發。
1、臨時緩解方式
周四晚上應急完后，發了個朋友圈。
昨天晚上驗證方法未經自己驗證，復制的各大產商給的方案。今日驗證后，發現有錯誤，包括今天有產商發的文章依舊是錯誤的。
- 首先區分版本，2.10以下版本中環境變量方法是無效的。
- 2.10以上版本，系統環境變量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 設置為true，這個是無效的（不信的朋友自行驗證）。LOG4J_FORMAT_MSG_NO_LOOKUPS這個環境變量才是有效的。
同時禁用lookup功能，（1）jvm參數 -Dlog4j2.formatMsgNoLookups=true 是有效的， （2）代碼加載log4j2.formatMsgNoLookups=True 也是有效的。
對於研發同學添加緩解措施，使用環境變量方法，然后重啟進程是最快速，對業務影響最小的，畢竟都有HA的么。jvm添加啟動參數，有些代碼是封裝的，對於有些不想修改代碼的朋友，建議還是使用環境變量。
不擔心穩定性的環境中，升級rc1版本、rc2版本也是可行的。
另外說到禁用lookup，那么可以將log4j-core的jar包中相關內容刪除掉也是可以的，尤其是jddilookup.其他的lookup也是可以調用的，只是目前沒有有效攻擊方式。
2、驗證環境
centos，jdk1.8我已經驗證了。
本地nc -l 1234，啟動1234端口，然后java -jar log4j-test-lcamry.jar。
從nc端可以看到數據輸入就說明payload攻擊成功。
然后可以修改環境變量進行測試了。
log4j-test-lcamry.jar鏈接: https://pan.baidu.com/s/1rY4H_-ZFJLsmr-HHurB7UQ 提取碼: hi67
3、利用waf可被繞過的變形payload
除了禁用lookup方法之外，很多甲方的朋友應該是利用waf進行攔截，那么大部分的還是針對${jndi:寫的payload，那么此時可利用
${${abc:-j}${abc:-ndi}:
進行繞過。
需要更新一下waf規則。
正則匹配的請速度更新，注意regddos的問題。此處如果利用語義/機器學習等作為檢測，其實是有一定好的效果的。
4、反制逆向工程師
ghidra，一款優秀的逆向工具，同樣的利用log4j的模塊。如果是某個逆向的文件，里面包含了${jndi:的paylaod，也能引起觸發相關的惡意請求。
那么這個東西有什么用，是不是就可以用來對逆向工程師做反制了。不知道后面蜜罐產商們會不會增加這個。當然利用jsonP也是很有效的方式。
5、大量調用log4j的其他工具
下面是個lisi，我沒有挨個去研究，復制的別人的（可能有誤）
- Apache Struts2
- Apache Solr
- Apache Druid
- Apache Flink
- ElasticSearch
- flume
- dubbo
- Redis
- logstash
- kafka
未來一段時間內，會有調用log4j的中間件/服務都會暴露出利用手段，還是需要持續關注。
6、黑產也在利用該攻擊方式
僵屍網絡、勒索軟件已經開始利用該payload（早上看到360發的一篇文章、還有teapot發的，可以看看很有意思，我這里就不貼了），甚至自動化攻擊的惡意軟件也不是沒有可能，后續危害才剛剛開始.
7，甲方該如何應對
我們從應急的角度上已經基本結束（waf、業務方修復等），那么接下來從檢測，防御角度上還是要有更進一步的深入。
例如DNS的惡意利用（dnslog、dns隧道等等）的深入檢測以及防御，檢測可以有規則OR模型，防御可以有dns污染等。具體的手段私下探討了。
利用ldap、rmi進行命令執行，隨着更多使用log4j的中間件/程序出現，會有更多的cc鏈使用新增（參考歷史上各大反序列化漏洞），那么如何深入的檢測也是未來需要做的。
我們經常聊得構建縱深防御體系，那么此時將會發揮重要作用的時候來了。甲方的朋友們可以深入研究起來了。