TomCat中間件漏洞復現
前言
在滲透測試過程中，遇到php的站相對多一點，所以對apache了解的也多一點。TomCat中間件的站了解的比較少一點，這是自己第一次搭建環境測試漏洞，所以在自己摸索的過程中遇到的坑比較多一點。我會把自己的坑都寫出來，希望可以幫助到大家。
實驗環境搭建
Tomcat的安裝（windows下安裝）
Java環境安裝
JDK安裝
官網下載jbk安裝包：https://www.oracle.com/technetwork/java/javase/downloads/index.html
解壓出來按照提示安裝，並配置環境變量。成功以后如圖所示：
Apache Tomcat7.0 安裝
下載地址：http://www.liangchan.net/soft/download.asp?softid=9366&downid=8&id=9430
全部安照默認設置下一步就行
這需要注意一下：是java下的jre目錄，選錯了安裝不了。安裝好了直接訪問：http://locahost:8080 如下圖所示
漏洞復現
Tomcat 遠程代碼執行漏洞（CVE-2017-12615）
漏洞產生原因
當在Tomcat的conf（配置目錄下）/web.xml配置文件中添加readonly設置為false時，將導致該漏洞產生，（需要允許put請求）
配置文件修改前后對比（這里需要注意一下） 修改前：
默認 readonly 為 true，當 readonly 設置為 false 時，可以通過 PUT / DELETE 進行文件操控。需要手動配置readonly為false才可以進行漏洞利用。修改后：
修改配置文件后，保存重啟。
PUT協議（方法）：PUT方法是HTTP請求方法中的一中。此方法用於請求服務器把請求中的實體儲存在請求資源下，如果請求資源已經在服務器中存在，那么將會用此請求中的數據替換原先的數據，作為指定資源的最新修改版。如果請求指定的資源不存在，將會創建這個資源，且數據位請求正文。
漏洞影響版本
Apache Tomcat 7.0.0 – 7.0.81
漏洞危害
導致服務器被遠程代碼執行
漏洞復現
直接訪問url：http://127.0.0.1：8088/ 使用burpsuite抓包：直接使用PUT提交shell.jsp返回404。（我在這塊干了一件比較蠢的事）
對比圖，修改前正常情況下：
修改后的圖：（直接抓包把GET改成PUT）
需要對文件名構造進行繞過，目前有三種繞過方式：
上傳的對比圖,錯誤的圖：（這邊浪費了很多時間，剛開始一直找不到原因）
上傳成功，如圖所示：（put協議要大寫，我說一直為什么不行）
查看：
木馬寫入成功，菜刀連接即可。
Tomcat遠程部署漏洞
漏洞產生
這是JSP/PHP網站遠程部署的一個工具，管理員只需要遠程上傳一個WAR格式的文件，便可以發布到網站，方便了開發人員部署代碼的同時，也為黑客上傳木馬敞開了大門。
漏洞檢測
通過訪問：Http://localhost:端口/manager 管理地址，嘗試弱口令或默認口令，若能登陸成功，則存在此漏洞。
漏洞復現
- 通過弱密碼登錄管理界面
- 上傳war包
- 然后直接訪問即可getshell
漏洞危害
入侵者可以通過構造war進行上傳木馬文件，從而控制服務器。
漏洞修復
升級tomcat 提升密碼強度 安裝相應的防護軟件 等等
Tomcat反序列化漏洞(CVE-2016-8735)
實驗環境搭建(沒成功)
Apache Tomcat 8.5.2安裝
Tomcat下載地址：http://tomcat.apache.org/
安裝8.0版本的
找到自己需要的版本
點擊bin
找到要下載的版本
直接下載解壓到本地就可以了（免安裝）。
然后是運行Tomcat，第一種方法是設置環境變量在cmd中運行startup.bat批處理文件；我用的是第二種方法，在apache-tomcat-8.5.2\bin下運行cmd命令框，運行startup.bat。如圖所示：
報錯了，原因是沒有jdk的環境變量
解決方法：（我從網上找的原因和解決方法寫的很清楚）
https://blog.csdn.net/zhangchao19890805/article/details/50646644
如果端口沖突可以修改web端口，conf->server.xml大約在69行。如圖所示：
一切准備好了以后，在cmd命令框運行startup.bat。如圖所示會彈出一個Tomcat的運行框，不要關閉。直接在瀏覽器打開就行了。
服務啟動成功。
Jdk1.7.0_80安裝（前面說過了）
漏洞描述
該漏洞與之前Oracle發布的mxRemoteLifecycleListener反序列化漏洞（CVE-2016-3427）相關，是由於使用了JmxRemoteLifecycleListener的監聽功能所導致。而在Oracle官方發布修復后，Tomcat未能及時修復更新而導致的遠程代碼執行。
該漏洞所造成的最根本原因是Tomcat在配置JMX做監控時使用了JmxRemoteLifecycleListener的方法。
漏洞影響版本
ApacheTomcat 9.0.0.M1 到9.0.0.M11
ApacheTomcat 8.5.0 到8.5.6
ApacheTomcat 8.0.0.RC1 到8.0.38
ApacheTomcat 7.0.0 到7.0.72
ApacheTomcat 6.0.0 到6.0.47
漏洞利用條件
外部需要開啟JmxRemoteLifecycleListener監聽的10001和10002端口，來實現遠程代碼執行。
漏洞復現
所需環境工具包：
catalina-jmx-remote.jar：
https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.2/bin/extras/catalina-jmx-remote.jar
groovy-2.3.9.jar：
http://central.maven.org/maven2/org/codehaus/groovy/groovy/2.3.9/groovy-2.3.9.jar
ysoserial.jar：
https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar
在進行漏洞復現之前我們需要配置幾點如下：
conf/server.xml中第30行中配置啟用JmxRemoteLifecycleListener功能監聽的端口：（自己手動添加，注意不要端口沖突）
<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="1001" rmiServerPortPlatform="1002"/>
配置好jmx的端口后，我們在tomcat版本所對應的extras/目錄下來下載catalina-jmx-remote.jar以及下載groovy-2.3.9.jar兩個jar包。下載完成后放至在lib目錄下。
接着我們再去bin目錄下修改catalina.bat腳本。在ExecuteThe Requested Command注釋前面添加這么一行。（手動添加，注意空格）
set CATALINA_OPTS= -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
主要配置的意思是設置啟動tomcat的相關配置，不開啟遠程監聽jvm信息。設置不啟用他的ssl鏈接和不使用監控的賬戶。具體的配置可以去了解一下利用tomcat的jmx監控。
至此所有的配置成功保存后，我們運行tomcat。
順帶監聽本地的1001和1002的RMI服務端口是否成功運行
監聽成功，我們開始來構造Payload執行命令。首先老套路彈個計算器。
Payload: java -cp ysoserial-master-v0.0.4.jar ysoserial.exploit.RMIRegistryExploit localhost 10001 Groovy1 calc.exe
沒彈成功（用的別人的圖，但是步驟沒錯），前面的步驟都正確就是彈不出來。可能是我java環境的原因。