一、負(fù)載均衡反向代理下的webshell上傳

1、nginx 負(fù)載均衡

負(fù)載均衡策略	策略
輪詢	請求順序逐一分配
權(quán)重	按照權(quán)重大小分配
ip_hash	根據(jù)客戶端IP分配
URL_hash	根據(jù)URL分配
least_conn	根據(jù)連接數(shù)分配

下來我簡單介紹幾種負(fù)載均衡的策略

1. 輪詢
   輪詢：nginx默認(rèn)就是輪詢其權(quán)重都默認(rèn)為1，服務(wù)器處理請求的順序：ABABABABAB…

upstream mysvr { server 192.168.137.131; server 192.168.137.136;       
}

注意：

• 在輪詢中，如果服務(wù)器down掉了，會自動剔除該服務(wù)器。
• 缺省配置就是輪詢策略。
• 此策略適合服務(wù)器配置相當(dāng)，無狀態(tài)且短平快的服務(wù)使用。

2. weight
   跟據(jù)配置的權(quán)重的大小而分發(fā)給不同服務(wù)器不同數(shù)量的請求

upstream mysvr { server 192.168.137.131 weihet = 100; server 192.168.137.136 weihet = 200;
}

3. ip_hash
   ip_hash:nginx會讓相同的客戶端ip請求相同的服務(wù)器

upstream mysvr { server 192.168.137.131; server 192.168.137.136;ip_hash;
}

2、搭建環(huán)境

github下載

cd /ant/loadbalance/loadbalance-jsp
docker-compose up  -d

這里我搭建環(huán)境的時候出了點(diǎn)問題，不知道為什么dockers-compose up -d 執(zhí)行不了， 然后我我把docker-compose 刪了重新安裝發(fā)現(xiàn)還是不行，然后我恢復(fù)快照重新搭建環(huán)境，最后解決辦法是卸載docker 重新安裝docker和docker-compose。

cd /usr/local/bin/
#下載docker-compose
wget https://github.com/docker/compose/releases/download/1.14.0-rc2/docker-compose-Linux-x86_64
#重命名
rename docker-compose-Linux-x86_64 docker-compose docker-compose-Linux-x86_64
#給執(zhí)行權(quán)限
chmod +x /usr/local/bin/docker-compose

上述下載方式有問題，由于compose更新了，Docker Compose V2 是 Docker Compose 的主要版本碰撞版本。它在Golang中完全重寫了（V1是用Python編寫的）。撰寫 V2 的安裝說明與 V1 不同。V2 不再是獨(dú)立的二進(jìn)制文件，必須調(diào)整安裝腳本。
然后我們采用下列方式重新安裝docker

#在 Linux上 安裝 Docker
curl -sSL https://get.daocloud.io/docker | sh
#安裝 Docker Compose
curl -L https://get.daocloud.io/docker/compose/releases/download/v2.16.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
#給予執(zhí)行權(quán)限
chmod +x /usr/local/bin/docker-compose

環(huán)境搭建完成，現(xiàn)在我們的整體框架如下圖
nginx 反向代理到兩臺內(nèi)網(wǎng)服務(wù)器上，Node1 和 Node2 均是 tomcat 8 ，在內(nèi)網(wǎng)中開放了 8080 端口，他們兩個之間可以互相通信，我們在外部是沒法直接訪問到的。

然后我們進(jìn)入docker-nginx 查看一下nginx 配置。
做了輪詢的負(fù)載均衡策略。

假定在真實(shí)的業(yè)務(wù)系統(tǒng)上，存在一個 RCE 漏洞，可以讓我們獲取 WebShell。
上傳我們的一句話木馬。
嘗試用蟻劍登錄

成功連接目標(biāo)，因?yàn)閮膳_節(jié)點(diǎn)都在相同的位置存在 ant.jsp，所以連接的時候也沒出現(xiàn)什么異常。

3、負(fù)載均衡下的 WebShell連接的難點(diǎn)總結(jié)

難點(diǎn)一、需要在每一臺節(jié)點(diǎn)的相同位置都上傳相同內(nèi)容的 WebShell

假如說node1上有ant.jsp，node2上沒有，這就會出現(xiàn)一會連接失敗，一會連接正常的問題
我們進(jìn)入node2刪除ant.jsp

一旦有一臺機(jī)器上沒有，那么在請求輪到這臺機(jī)器上的時候，就會出現(xiàn) 404 錯誤，影響使用。還好負(fù)載均衡的策略是輪詢，還存在一定的規(guī)律，如果是其他策略，更難以把控。

難點(diǎn)二、無法預(yù)測下次的請求交給哪臺機(jī)器去執(zhí)行。

由于難點(diǎn)一測試時刪除了 node2的ant.jsp，我們重新copy一下
docker cp ant.jsp 46c0af8b0ca3:/usr/local/tomcat/webapps/ROOT/ant.jsp
由于nginx服務(wù)器上配置了 輪詢負(fù)載均衡，所以我們無法下次的請求交給哪臺機(jī)器去執(zhí)行，有點(diǎn)飄忽不定。

難點(diǎn)三、下載文件時，可能會出現(xiàn)飄逸，導(dǎo)致下載失敗。

由于 antSword 上傳文件時，采用的分片上傳方式，把一個文件分成了多次HTTP請求發(fā)送給了目標(biāo)，導(dǎo)致兩臺節(jié)點(diǎn)上，各一半，而且這一半到底是怎么組合的，取決于 LBS 算法

難點(diǎn)四、目標(biāo)機(jī)器不能出外網(wǎng)

目標(biāo)機(jī)器不能出外網(wǎng)，要想深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，但隧道隨時可能斷開連接，tunnel 腳本全部都會失效。
1、reGeorg內(nèi)網(wǎng)滲透工具
ReGeorg可以稱為內(nèi)網(wǎng)代理。實(shí)際上，它可以起到代理的作用

模擬上圖的場景
主機(jī)A、主機(jī)B、攻擊者
假如主機(jī)A上運(yùn)行了Web服務(wù)，且IP或者端口映射到公網(wǎng)，可以被外部人員訪問，主機(jī)B是在外網(wǎng)訪問不到的。攻擊者通過漏洞在主機(jī)A上傳了Webshell，但同時又出于某些限制并未能得到主機(jī)A的主機(jī)權(quán)限也無法反彈shell，那么他這個時候，也是無法通過常規(guī)方法反彈shell或者直接登錄主機(jī)A從而訪問到主機(jī)B的。

ReGeorg就在這個時候起了作用，攻擊者已經(jīng)有了主機(jī)A的webshell權(quán)限（即可以在web服務(wù)器中上傳文件），而主機(jī)A可以和主機(jī)B通信。那么在主機(jī)A上安裝reGeorg工具，使得攻擊者發(fā)出的請求以及目標(biāo)機(jī)器的響應(yīng)經(jīng)過A的http轉(zhuǎn)發(fā)，達(dá)到攻擊者可以和主機(jī)B進(jìn)行通信的效果。
2、ab（http）與abs（https）壓測工具
ab全稱為：apache bench
ab是Apache超文本傳輸協(xié)議(HTTP)的性能測試工具。其設(shè)計意圖是描繪當(dāng)前所安裝的Apache的執(zhí)行性能，主要是顯示你安裝的Apache每秒可以處理多少個請求。

總結(jié)

看似四個難點(diǎn)，歸根結(jié)底是由于nginx,上配置了負(fù)載均衡的問題，我們無法預(yù)測，管控下一次請求在那臺服務(wù)器上，所以導(dǎo)致了這一系列問題，下面我們介紹一些解決辦法。

4、解決方法

方法一、關(guān)機(jī)/停服

關(guān)掉其中一臺機(jī)器，這種行為最不推薦，但如果你不在乎關(guān)掉服務(wù)器的損失當(dāng)我沒說。這種方法影響業(yè)務(wù)，不建議嘗試，測試除外。

方法二、判斷是否執(zhí)行

既然無法預(yù)測下一次是哪臺機(jī)器去執(zhí)行，我們可以在Shell 執(zhí)行 Payload 之前，判斷要不要執(zhí)行。
創(chuàng)建shell 腳本

MYIP = `ifconfig | grep "inet 172" | awk "{print $2}"`
if [ $MYIP == "172.18.0.3" ];thenecho = "aaaaaaaa"ifconfig
elseecho = "bbbbbbbb"
fi

蟻劍不知道出現(xiàn)莫名的問題

方法三、在Web層做 HTTP 流量轉(zhuǎn)發(fā)

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

我們的目的是：所有的數(shù)據(jù)包都能發(fā)給「LBSNode 1」這臺機(jī)器。
如上圖所示，我們可以在node2上做數(shù)據(jù)轉(zhuǎn)發(fā)，整合數(shù)據(jù)后轉(zhuǎn)發(fā)給node1
首先：我們通過nginx,直接訪問node1，
其次：我們把請求發(fā)給Node2,Node2 上面的 /antproxy.jsp 把請求重組之后，傳給了 Node1 的 /ant.jsp，成功執(zhí)行。

1.創(chuàng)建 antproxy.jsp 腳本

修改數(shù)據(jù)轉(zhuǎn)發(fā)的目標(biāo)地址

注意：
不要使用上傳功能，上傳功能會分片上傳，導(dǎo)致分散在不同 Node 上。
要保證每一臺 Node 上都有相同路徑的 antproxy.jsp，保證每一臺都上傳了腳本

2.修改 Shell 配置, 將 URL 部分填寫為 antproxy.jsp 的地址

這里轉(zhuǎn)發(fā)的目標(biāo)地址，我第一次改成172.18.0.2:18080,出現(xiàn)蟻劍連接不上的問題，然后改成172.18.0.2:8080，就可以連接成功。

3. 測試執(zhí)行命令, 查看 IP

這個方法有個缺點(diǎn)，需要目標(biāo)Node1和 Node2之間內(nèi)網(wǎng)互通，如果不互通，就無法解決問題。

二、apache漏洞

1、Apache HTTPD 換行解析漏洞(環(huán)境沒搭建成功)

Apache HTTPD 換行解析漏洞（CVE-2017-15715）
影響版本：2.4.0~2.4.29
影響說明：Apache HTTPD是一款HTTP服務(wù)器，它可以通過mod_php來運(yùn)行PHP網(wǎng)頁。在解析PHP時，1.php\x0a將被按照PHP后綴進(jìn)行解析，導(dǎo)致繞過一些服務(wù)器的安全策略。

在1.php后面插入一個\x0A,php會解析成1.php%0a,從而成功解析

2、Apache HTTPD 多后綴解析漏洞

Apache HTTPD 支持一個文件擁有多個后綴，并為不同后綴執(zhí)行不同的指令。比如，如下配置文件：

AddType text/html .html
AddLanguage zh-CN .cn

其給.html后綴增加了media-type，值為text/html；給.cn后綴增加了語言，值為zh-CN。此時，如果用戶請求文件index.cn.html，他將返回一個中文的html頁面。
意思就是說只要文件后綴中包含了 html、php的文件,他就可以被解析成相應(yīng)的文件.

以上就是Apache多后綴的特性。如果運(yùn)維人員給.php后綴增加了處理器：

AddHandler application/x-httpd-php .php
那么，在有多個后綴的情況下，只要一個文件含有.php后綴的文件即將被識別成PHP文件.
漏洞復(fù)現(xiàn)
環(huán)境運(yùn)行后，訪問http://192.1`68.137.131/uploadfiles/apache.php.jpeg即可發(fā)現(xiàn)，phpinfo被執(zhí)行了，該文件被解析為php文件。
我們就可以利用Apache解析漏洞進(jìn)行g(shù)etshell。

3、Apache Solr 遠(yuǎn)程命令執(zhí)行漏洞（沒寫完）

Apache Solr 遠(yuǎn)程命令執(zhí)行漏洞（CVE-2019-0193）
影響版本：Apache Solr < 8.2.0 的版本
影響說明：Apache Solr 是一個開源的搜索服務(wù)器。Solr 使用 Java 語言開發(fā)，主要基于 HTTP 和 Apache Lucene 實(shí)現(xiàn)。此次漏洞出現(xiàn)在Apache Solr的DataImportHandler，該模塊是一個可選但常用的模塊，用于從數(shù)據(jù)庫和其他源中提取數(shù)據(jù)。它具有一個功能，其中所有的DIH配置都可以通過外部請求的dataConfig參數(shù)來設(shè)置。由于DIH配置可以包含腳本，因此攻擊者可以通過構(gòu)造危險的請求，從而造成遠(yuǎn)程命令執(zhí)行。
在Apache Solr < 8.2.0 的版本中， DataImportHandler的dataConfig參數(shù)為用戶可控，攻擊者可通過構(gòu)造惡意的dataConfig腳本交由轉(zhuǎn)換器（Transformers）進(jìn)行解析，而Solr在解析的過程中并未對用戶輸入的腳本進(jìn)行檢查，導(dǎo)致攻擊者可在Solr服務(wù)器上執(zhí)行任意代碼。

solr 工作機(jī)制
1.solr是在lucene工具包的基礎(chǔ)之上進(jìn)行了封裝，并且以web服務(wù)的形式對外提供索引功能
2.業(yè)務(wù)系統(tǒng)需要使用到索引的功能（建索引，查索引）時，只要發(fā)出http請求，并將返回數(shù)據(jù)進(jìn)行解析即可

Solr DataImportHandler
Solr DataImportHandler可以批量把數(shù)據(jù)導(dǎo)入到索引庫中.

DataImportHandler有如下功能：1、讀取關(guān)系數(shù)據(jù)庫中數(shù)據(jù)或文本數(shù)據(jù)2、根據(jù)配置從xml（http/file方式）讀取與建立索引數(shù)據(jù)3、根據(jù)配置聚合來自多個列和表的數(shù)據(jù)來構(gòu)建Solr文檔4、使用文檔更新Solr（更新索引、文檔數(shù)據(jù)庫等）5、根據(jù)配置進(jìn)行完全導(dǎo)入的功能（full-import，完全導(dǎo)入每次運(yùn)行時會創(chuàng)建整個索引）6、檢測插入/更新字段并執(zhí)行增量導(dǎo)入（delta-import，對增加或者被修改的字段進(jìn)行導(dǎo)入）7、調(diào)度full-import與delta-import8、可以插入任何類型的數(shù)據(jù)源（ftp，scp等）和其他用戶可選格式（JSON，csv等）

這里有前輩做的一張圖，來幫助我們理解。

Core：索引庫，其中包含chema.xml/managed-schema，schema.xml是模式文件的傳統(tǒng)名稱，可以由使用該模式的用戶手動編輯，managed-schema是Solr默認(rèn)使用的模式文件的名稱，它支持在運(yùn)行時動態(tài)更改，data-config文件可配置為xml形式或通過請求參數(shù)傳遞（在dataimport開啟debug模式時可通過dataConfig參數(shù)傳遞）
漏洞利用的前提條件: Solr有一個具有dataimport功能的core，這個功能需要在這個core對應(yīng)的配置文件中指定節(jié)點(diǎn)的class屬性為，solrconfig.xmlrequestHandlersolr.DataImportHandler

且Solr未開啟認(rèn)證（默認(rèn)未開啟認(rèn)證），在這種情況下，Solr Admin UI上的操作是不需要登錄憑據(jù)的。

開啟認(rèn)證可通過編輯配置文件：server/solr-webapp/webapp/WEB-INF/web.xml
復(fù)現(xiàn)漏洞
搭建環(huán)境

運(yùn)行環(huán)境

docker-compose up -d
docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db

訪問http://192.168.137.131:8983/即可查看到Apache solr的管理頁面，無需登錄

4、Apache HTTP 服務(wù)器的路徑穿越和文件泄露漏洞

Apache HTTP 服務(wù)器 2.4.49 中的路徑穿越和文件泄露漏洞 （CVE-2021-41773）
影響版本：2.4.49
影響說明：在 Apache HTTP Server 2.4.49 中對路徑規(guī)范化所做的更改中發(fā)現(xiàn)一個缺陷。攻擊者可以使用路徑遍歷攻擊將 URL 映射到預(yù)期文檔根目錄之外的文件。
如果這些目錄之外的文件不受通常的默認(rèn)配置“要求全部拒絕”的保護(hù)，則這些請求可以成功。如果還為這些別名路徑啟用了 CGI 腳本，則可能允許遠(yuǎn)程執(zhí)行代碼。
漏洞復(fù)現(xiàn)

curl -v --path-as-is http://your-ip:8080/icons/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

/%2e%2e/ 就是/…/ ,且icons目錄存在，執(zhí)行命令后，就行當(dāng)于返回到根目錄下執(zhí)行/etc/passwd
如果在服務(wù)器上啟用 mods cgi 或 cgid 的話，此路徑遍歷漏洞將允許任意命令執(zhí)行：

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

什么是cgi?
CGI的全稱是Common Gateway Interface，通用網(wǎng)關(guān)接口。粗略地說，CGI就是位于服務(wù)器端的處理網(wǎng)頁請求的程序。CGI程序本身是服務(wù)器操作系統(tǒng)上的一個簡單的應(yīng)用程序，它接受輸入進(jìn)行處理并輸出內(nèi)容，這些輸入輸出都又通過Web服務(wù)器軟件（比如apache）處理，最終完成需要的功能。

5、Apache SSI 遠(yuǎn)程命令執(zhí)行漏洞

影響說明：在測試任意文件上傳漏洞的時候，目標(biāo)服務(wù)端可能不允許上傳php后綴的文件。如果目標(biāo)服務(wù)器開啟了SSI與CGI支持，我們可以上傳一個shtml文件，并利用<!–#exec cmd=“id” -->語法執(zhí)行任意命令。
漏洞復(fù)現(xiàn)
環(huán)境啟動后，訪問http://192.168.137.140:8080/upload.php，即可看到一個上傳表單。
然后我們上傳一個1.shtml文件

<!--#exec cmd="id" -->

然后我們用burpsuite 測試一下

然后我們修改post 改成我們的1.shtml 運(yùn)行后成功執(zhí)行了<!–#exec cmd=“id” -->命令

上述提到SSI
什么是SSI？
SSI（服務(wù)器端包含）是放置在 HTML 頁面，并在頁面 被服務(wù)。它們允許您將動態(tài)生成的內(nèi)容添加到 現(xiàn)有 HTML 頁面，而不必提供整個頁面 通過CGI程序或其他動態(tài)技術(shù)。

例如，您可以將指令放入現(xiàn)有 HTML 中 頁面，例如：

<!--#echo var="DATE_LOCAL" -->并且，當(dāng)頁面投放時，將評估此片段并將其替換為其值：Tuesday, 15-Jan-2013 19:28:54 EST

各個服務(wù)器對SSI命令的支持各有不同，但 #include 和 #exec 是通用的。使用 SSI 的頁面文件通常都使用擴(kuò)展名.shtml，而不是.html 或 .htm，這樣以便服務(wù)器能夠辨認(rèn)出哪些頁面包含SSI指令，這些頁面需要先經(jīng)過服務(wù)器處理，翻譯執(zhí)行其中的SSI指令，然后才發(fā)送給客戶端瀏覽器。 (當(dāng)然有些服務(wù)器還是支持.html,.htm文件中有SSI指令的)。

如何辨認(rèn)服務(wù)器是否支持SSI？

1. 拷貝以下HTML內(nèi)容，保存為文件名test.shtml

<!–#echo var=”DATE_LOCAL” –>

2. 將這個文件上載到你的服務(wù)器上，然后用瀏覽器瀏覽服務(wù)器上的這個網(wǎng)頁。

3. 如果看到網(wǎng)頁顯示當(dāng)前日期，則你的服務(wù)器支持 SSI。