JAVA安全之CVE-2020-1938復現和分析
一、漏洞簡介
Apache Tomcat是由Apache軟件基金會屬下Jakarta項目開發的Servlet容器.默認情況下,Apache Tomcat會開啟AJP連接器,方便與其他Web服務器通過AJP協議進行交互.但Apache Tomcat在AJP協議的實現上存在漏洞,導致攻擊者可以通過發送惡意的AJP請求,可以讀取或者包含Web應用根目錄下的任意文件,如果配合文件上傳任意格式文件,將可能導致任意代碼執行(RCE).該漏洞利用AJP服務端口實現攻擊,未開啟AJP服務對外不受漏洞影響(tomcat默認將AJP服務開啟并綁定至0.0.0.0/0).
1、危險等級
高危
2、漏洞危害
攻擊者可以讀取 Tomcat所有 webapp目錄下的任意文件。此外如果網站應用提供文件上傳的功能,攻擊者可以先向服務端上傳一個內容含有惡意 JSP 腳本代碼的文件(上傳的文件本身可以是任意類型的文件,比如圖片、純文本文件等),然后利用 Ghostcat 漏洞進行文件包含,從而達到代碼執行的危害
3、影響范圍
Apache Tomcat 9.x < 9.0.31
Apache Tomcat 8.x < 8.5.51
Apache Tomcat 7.x < 7.0.100
Apache Tomcat 6.x
4、前提條件
對于處在漏洞影響版本范圍內的 Tomcat 而言,若其開啟 AJP Connector 且攻擊者能夠訪問 AJP Connector 服務端口的情況下,即存在被 Ghostcat 漏洞利用的風險。注意 Tomcat AJP Connector 默認配置下即為開啟狀態,且監聽在 0.0.0.0:8009 。
5、漏洞原理
Tomcat 配置了兩個Connecto,它們分別是 HTTP 和 AJP :HTTP默認端口為8080,處理http請求,而AJP默認端口8009,用于處理 AJP 協議的請求,而AJP比http更加優化,多用于反向、集群等,漏洞由于Tomcat AJP協議存在缺陷而導致,攻擊者利用該漏洞可通過構造特定參數,讀取服務器webapp下的任意文件以及可以包含任意文件,如果有某上傳點,上傳圖片馬等等,即可以獲取shel
二、漏洞分析
1.漏洞成因分析:
tomcat默認的conf/server.xml中配置了2個Connector,一個為8080的對外提供的HTTP協議端口,另外一個就是默認的8009 AJP協議端口,兩個端口默認均監聽在外網ip。
tomcat在接收ajp請求的時候調用org.apache.coyote.ajp.AjpProcessor來處理ajp消息,prepareRequest將ajp里面的內容取出來設置成request對象的Attribute屬性
如下圖:
在代碼的507行
可以通過此種特性從而可以控制request對象的下面三個Attribute屬性
javax.servlet.include.request_uri
javax.servlet.include.path_info
javax.servlet.include.servlet_path
然后封裝成對應的request之后,繼續走servlet的映射流程如下圖所示:
接著看第252行。
2.利用方式:
(1)利用DefaultServlet實現任意文件下載
當url請求未在映射的url列表里面則會通過tomcat默認的DefaultServlet會根據上面的三個屬性來讀取文件,如下圖
通過serveResource方法來獲取資源文件
通過getRelativePath來獲取資源文件路徑
然后再通過控制ajp控制的上述三個屬性來讀取文件,通過操控上述三個屬性從而可以讀取到/WEB-INF下面的所有敏感文件,不限于class、xml、jar等文件。
(2)通過jspservlet實現任意后綴文件包含
當url(比如http://xxx/xxx/xxx.jsp)請求映射在org.apache.jasper.servlet.JspServlet這個servlet的時候也可通過上述三個屬性來控制訪問的jsp文件如下圖:
控制路徑之后就可以以jsp解析該文件 所以只需要一個可控文件內容的文件即可實現rce.
代碼段分析1:
tomcat默認監聽的8009端口用來處理AJP協議。AJP協議建立在TCP socket通信之上,tomcat使用該協議和前級的Web Server傳遞信息,這次的漏洞就出在客戶端可以利用ajp協議數據包控制request對象的一些字段。
具體地,tomcat源碼的org.apache.coyote.ajp.AjpProcessor類的service()方法如下:
它調用的prepareRequest()方法用來解析一些請求頭,部分內容如下:
可以看到,當ajp數據包的頭設置為SC_REQ_ATTRIBUTE時(具體數值可以查詢AJP協議規范),Connector會緊接著讀取變量n(屬性名)和v(值),當n不是SC_A_REQ_LOCAL_ADDR、SC_A_REQ_REMOTE_PORT、SC_A_SSL_PROTOCOL時,就會用v來賦值屬性n。接著,service()方法將修改過的request代入后面的調用。
=在org.apache.catalina.servlets.DefaultServlet中,當我們的請求聲明的是GET方法時,存在調用service()->doGet()->serveResource(),分析serveResource()代碼如下:
其調用的getRelativePath()方法內容如下:
從javax.servlet.RequestDispatcher中可以看到這三個屬性的名稱:
所以,我們就能通過AJP協議改變request的這三個屬性來控制請求的路徑,serveResource()方法獲得path后的代碼大致如下:
它會直接把通過path獲取的資源序列化輸出,因此客戶端再按照AJP協議解析數據包就能得到文件內容。
代碼段分析2:
同樣的道理,tomcat默認將jsp/jspx結尾的請求交給org.apache.jasper.servlet.JspServlet處理,它的service()方法如下:
可以看到jspUri也是由兩個可控的屬性定義的,后續代碼:
代碼在這里根據jspUri生成了一個JspServletWrapper,它會調用service()方法完成jsp代碼的編譯,將其轉換成一個servlet。該servlet最終會以.java文件的形式寫入%CATALINA_HOME%/work/Engine/Host/Context目錄下:
經過上述調用,這就形成了文件包含漏洞。當Web應用上有某個文件內容可被我們控制時,就可以造成rce漏洞。
三、漏洞復現
1.環境的準備
(1)windows下漏洞復現環境準備,這里以tomcat-8.5.32為例。
https://github.com/backlion/CVE-2020-1938/blob/master/apache-tomcat-8.5.32.zip
(2)安裝jdk并配置JDK環境
(3)然后啟動tomcat,點擊tomcat目錄/bin 文件夾下的startup.bat
root@kali2019:~# git clone https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi root@kali2019:~# cd CNVD-2020-10487-Tomcat-Ajp-lfi/ root@kali2019:~/CNVD-2020-10487-Tomcat-Ajp-lfi# chmod +x CNVD-2020-10487-Tomcat-Ajp-lfi.py root@kali2019:~/CNVD-2020-10487-Tomcat-Ajp-lfi#
python CNVD-2020-10487-Tomcat-Ajp-lfi.py 192.168.1.9 -p 8009 -f WEB-INF/web.xm
讀取文件
讀取web-inf/web.xm文件
python CNVD-2020-10487-Tomcat-Ajp-lfi.py 10.10.10.134 -p 8009 -f WEB-INF/web.xml
python CNVD-2020-10487-Tomcat-Ajp-lfi.py 10.10.10.134 -p 8009 -f index.jsp
命令執行
執行whoami命令
python "文件包含(CVE-2020-1938).py" 10.10.10.134 -p 8009 -f /test.txt
ping dnslog
反彈shell
- 反彈shell用的命令需要進行bash編碼
- 在線bash編碼:http://www.jackson-t.ca/runtime-exec-payloads.html
- https://ares-x.com/tools/runtime-exec/
- POC下載地址:https://github.com/sv3nbeast/CVE-2020-1938-Tomact-file_include-file_read
在反彈shell的過程中,我嘗試多次之后失敗了。就放了一張米斯特斯文師傅的一張成功的圖片。
REF
https://www.cnblogs.com/backlion/p/12870365.html
https://xz.aliyun.com/t/7325
https://www.svenbeast.com/post/fqSI9laE8/