本篇文章為大家展示了怎么深入分析Apache Tomcat從文件包含到RCE漏洞原理，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

公司主營業(yè)務(wù)：網(wǎng)站建設(shè)、成都做網(wǎng)站、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)建站是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)建站推出溫嶺免費(fèi)做網(wǎng)站回饋大家。

漏洞簡介

2020年02月20日，于CNVD公開的漏洞公告中發(fā)現(xiàn)Apache Tomcat文件包含漏洞（CVE-2020-1938）。

Apache Tomcat為Apache開源組織開發(fā)的用于處理HTTP服務(wù)的項(xiàng)目。Apache Tomcat服務(wù)器中被發(fā)現(xiàn)存在文件包含漏洞，攻擊者可利用該漏洞讀取或包含 Tomcat 上所有 webapps目錄下的任意文件。

本次漏洞是一個單獨(dú)的文件包含漏洞，該漏洞依賴于Tomcat的AJP（定向包協(xié)議）協(xié)議。AJP協(xié)議自身存在一定的缺陷，導(dǎo)致存在可控參數(shù)，通過可控參數(shù)可以導(dǎo)致文件包含漏洞。AJP協(xié)議使用率約為7.8%，鑒于Tomcat作為中間件被大范圍部署在服務(wù)器上，本次漏洞危害較大。

AJP13協(xié)議介紹

我們對Tomcat的普遍認(rèn)識主要有兩大功能，一是充當(dāng)web服務(wù)器，可以對一切靜態(tài)資源的請求作出回應(yīng)，二就是Servlet容器。

常見的web服務(wù)器有 Apache、 Nginx、 IIS等。常見的Servlet容器有Tomcat，Weblogic，JBOSS等。

Servlet容器可以理解為是Web服務(wù)器的升級版，拿Tomcat來舉例，Tomcat本身可以不做Servlet容器使用，僅僅充當(dāng)Web服務(wù)器的角色是完全沒問題的，但是在處理靜態(tài)資源請求的效率和速度上是遠(yuǎn)不及Apache，所以很多情況下生產(chǎn)環(huán)境中都會將Apache作為web服務(wù)器來接受用戶的請求，靜態(tài)資源有Apache直接處理，而Servlet請求則交由Tomcat來進(jìn)行處理。這么做就可以讓兩個中間件各司其職，大大加快相應(yīng)速度。

眾所周知我們用戶的請求是以http協(xié)議的形式傳遞給Web 服務(wù)器的，我們在瀏覽器中對某個域名或者ip進(jìn)行訪問，頭部都會有http或者h(yuǎn)ttps的表示，而AJP協(xié)議瀏覽器是不支持的，我們無法通過瀏覽器發(fā)送AJP的報文。當(dāng)然AJP這個協(xié)議也不是提供給我們用戶來使用的。

在Tomcat $CATALINA_BASE/conf/web.xml默認(rèn)配置了兩個Connector，分別監(jiān)聽兩個不同的端口，一個是HTTP Connector  默認(rèn)監(jiān)聽8080端口，一個是AJP Connector 默認(rèn)監(jiān)聽8009端口。

HTTP Connector的主要就是負(fù)責(zé)接收來自用戶的請求，不管事靜態(tài)還是動態(tài)，只要是HTTP請求就時由HTTP Connector來負(fù)責(zé)。有了這個 Connector Tomcat才能成為一個web服務(wù)器，但還額外可處理Servlet和jsp。

而AJP協(xié)議的使用對象通常是另一個Web服務(wù)器。例如Apache ，這里從網(wǎng)上找到了一張圖，以此圖來進(jìn)行說明。

通常情況下AJP協(xié)議的使用場景是這樣的。

AJP是一個二進(jìn)制的TCP傳輸協(xié)議，瀏覽器無法使用，首先由Apache與Tomcat之間進(jìn)行AJP協(xié)議的通信，然后由Apache通過proxy_ajp模塊進(jìn)行反向代理，將其轉(zhuǎn)換成HTTP服務(wù)器然后在暴露給用戶，讓用戶來進(jìn)行訪問。

之所以要這么做，是因?yàn)橄啾菻TTP這種純文本的協(xié)議來說，效率和性能更高，同時也做了很多優(yōu)化。

其實(shí)AJP協(xié)議某種程度上可以理解為是HTTP的二進(jìn)制版，為了加快傳輸效率從而被使用，實(shí)際情況是像Apache這樣有proxy_ajp模塊可以反向代理AJP協(xié)議的很少，所以日常生產(chǎn)中AJP協(xié)議也很少被用到

Tomcat 遠(yuǎn)程文件包含漏洞分析

漏洞分析環(huán)境搭建

首先從官網(wǎng)下載對應(yīng)的Tomcat源碼文件，和可執(zhí)行文件。

http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.50/

下載好后將兩個文件夾放入同一個目錄下

然后在源碼中新增pom.xml并加入以下內(nèi)容

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
 <modelVersion>4.0.0</modelVersion>
 <groupId>org.apache.tomcat</groupId>
 <artifactId>Tomcat8.0</artifactId>
 <name>Tomcat8.0</name>
 <version>8.0</version>
 
 <build>
 <finalName>Tomcat8.0</finalName>
 <sourceDirectory>java</sourceDirectory>
 <testSourceDirectory>test</testSourceDirectory>
 <resources>
 <resource>
 <directory>java</directory>
 </resource>
 </resources>
 <testResources>
 <testResource>
 <directory>test</directory>
 </testResource>
 </testResources>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>2.3</version>
 <configuration>
  <encoding>UTF-8</encoding>
  <source>1.8</source>
  <target>1.8</target>
 </configuration>
 </plugin>
 </plugins>
 </build>
 
 <dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.12</version>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.easymock</groupId>
 <artifactId>easymock</artifactId>
 <version>3.4</version>
 </dependency>
 <dependency>
 <groupId>ant</groupId>
 <artifactId>ant</artifactId>
 <version>1.7.0</version>
 </dependency>
 <dependency>
 <groupId>wsdl4j</groupId>
 <artifactId>wsdl4j</artifactId>
 <version>1.6.2</version>
 </dependency>
 <dependency>
 <groupId>javax.xml</groupId>
 <artifactId>jaxrpc</artifactId>
 <version>1.1</version>
 </dependency>
 <dependency>
 <groupId>org.eclipse.jdt.core.compiler</groupId>
 <artifactId>ecj</artifactId>
 <version>4.5.1</version>
 </dependency>
 </dependencies>
</project>

然后添加一個Application

1、按照下面圖示新增Application的配置信息

2、在Man class:中填入:org.apache.catalina.startup.Bootstrap

3、在VM options:中填入:-Dcatalina.home="apache-tomcat-8.5.34"，catalina.home替換成tomcat binary core的目錄

4、jdk默認(rèn)是1.8，因?yàn)槲已b的就是jdk1.8版本

5、啟動過程中Test模塊會報錯，且為TestCookieFilter.java，注釋里面的測試內(nèi)容即可

然后運(yùn)行 訪問127.0.0.1:8080出現(xiàn)以下頁面則環(huán)境搭建成功

漏洞復(fù)現(xiàn)

   任意文件讀取

RCE

漏洞分析

首先根據(jù)網(wǎng)上的介紹我們定位到 org.apache.coyote.ajp.AjpProcessor這個類，根據(jù)網(wǎng)上透漏的漏洞消息，我們得知漏洞的產(chǎn)生是由于Tomcat對ajp傳遞過來的數(shù)據(jù)的處理存在問題，導(dǎo)致我們可以控制“javax.servlet.include.request_uri”，“javax.servlet.include.path_info”，“javax.servlet.include.servlet_path”，這三個參數(shù)，從而讀取任意文件，甚至可以進(jìn)行RCE。

我們先從任意文件讀取開始分析

我所使用的環(huán)境使用Tomcat 8.0.50版本所搭建的，產(chǎn)生漏洞的點(diǎn)并不在AjpProcessor.prepareRequest()方法，8.0.50版本的漏洞點(diǎn)存在于AjpProcessor的父類，AbstractAjpProcessor這個抽象類的prepareRequest()中

我們在這里下斷點(diǎn)

然后運(yùn)行exp，然后先看一下此時的調(diào)用鏈

首先由于此次數(shù)據(jù)傳輸使用的是AJP協(xié)議，監(jiān)聽的8009口，并非我們常見的HTTP協(xié)議。所以首先SocketPeocessore這個內(nèi)部類來進(jìn)行處理，

處理完成后經(jīng)過幾次調(diào)用交由AbstractAjpProcessor.prepareRequest()，該方法就是漏洞產(chǎn)生的第一個點(diǎn)。

我們單步步入request.setAttribute()方法

這里我們可以看到，attributes是一個HashMap，那這樣就非常好理解了，就是將我們通過AJP協(xié)議傳遞過來的三個參數(shù)循環(huán)遍歷存入這個HashMap

可以看到這里是一個while循環(huán)，我們來直接看循環(huán)完成后的結(jié)果

執(zhí)行完后就會在Request對象的attributes屬性中增加這三條數(shù)據(jù)。

到這里就是漏洞的前半部分，操縱可控變量將其改造層我們想要的數(shù)據(jù)。

我們先看一下exp發(fā)出的數(shù)據(jù)包是什么樣的

我們通過使用WireShark抓包，看到了AJP報文的一些信息，其中有四個比較重要的參數(shù)，

URI:/asdf

javax.servlet.include.request_uri:/

javax.servlet.include.path_info: WEB-INF/Test.txt

javax.servlet.include.servlet_path:/

首先要講到的就是這個URL，通過之前對AJP協(xié)議的介紹，我們知道通過AJP協(xié)議傳來的數(shù)據(jù)最中還是要交由Servlet來進(jìn)行處理的，那么問題就來了，應(yīng)該交由那個Servlet來進(jìn)行處理？

我們通過翻閱網(wǎng)上關(guān)于Tomcat的架構(gòu)的一些文章和資料得知，在Tomcat $CATALINA_BASE/conf/web.xml這個配置文件中默認(rèn)定義了兩個Servlet

一個是DefaultServlet

另一個是JspServlet

由于 $CATALINA_BASE/conf/web.xml這個文件是tomcat啟動時默認(rèn)加載的，所以這兩個Servlet會默認(rèn)存在Servlet容器中

當(dāng)我們請求的URI不能和任何Servlet匹配時，就會默認(rèn)由 DefaultServlet來處理，DefaultServlet主要用于處理靜態(tài)資源，如HTML、圖片、CSS、JS文件等，而且為了提升服務(wù)器性能，Tomcat對訪問文件進(jìn)行緩存。按照默認(rèn)配置，客戶端請求路徑與資源的物理路徑是一致的。

我們看到我們請求的URI為“/asdf”這就符合了無法匹配后臺任何的Servlet這么一個條件，這里要注意一下，舉個例子，譬如我們請求一個“abc.jsp”  但是后臺沒有“abc.jsp” 這種不屬于無法匹配任何Servlet，因?yàn)?jsp的請求會默認(rèn)走JspServlet來進(jìn)行處理

好的，根據(jù)這段介紹，結(jié)合我們發(fā)送的數(shù)據(jù)包中的“URI:/asdf”這一屬性，我們可以判斷此次請求是由DefaultServlet來進(jìn)行處理的。

我們定位到DefaultServlet的doGet方法

doGet方法里又調(diào)用了serveResource()方法

serveResource()方法由調(diào)用了getRelativePath()方法來進(jìn)行路徑拼接，我們跟進(jìn)看一看

這里就是將我們傳入的path_info 、servlet_path 進(jìn)行復(fù)制的地方，request_uri用來做判斷，如果發(fā)送的數(shù)據(jù)包中沒有request_uri，就會走else后面的兩行代碼進(jìn)行賦值，這樣會就會導(dǎo)致漏洞利用失敗

接下來就是對路徑的拼接了，這里可以看到如果傳遞數(shù)據(jù)時不傳遞servlet_path，則result在進(jìn)行路徑拼接時就不會將“/”拼接在“WEB-INF/web.xml”的頭部，最后拼接的結(jié)果仍然是“WEB-INF/web.xml”

接下來返回DefaultServle.serveResource()

緊接著判斷path變量長度是否為0，為0則調(diào)用目錄重定向方法

下面的代碼就要開始讀區(qū)我們指定的資源文件了

我們跟進(jìn)StandardRoot.getResource()方法

getResource()方法中又調(diào)用了一個很重要的方法validate()方法并將path作為變量傳遞進(jìn)去進(jìn)行處理，我們繼續(xù)跟入

這里就牽扯到為什么我們?yōu)槭裁床荒芡ㄟ^"/../../"的方式來讀取webapps目錄的上層目錄里文件的原因了，首先是正常請求

我們可以看到正常請求最后return的result的路徑就是我們文件所在的相對路徑。

當(dāng)我門嘗試使用WEB-INF/../../Test.txt來讀區(qū)webapps以外的目錄中的文件時?？梢钥吹酱藭r返回的result就是null了，而且會拋出異常。

這一切的原因都在RequestUtil.normalize()這個函數(shù)對我們傳遞進(jìn)來的路徑處理上，我們跟進(jìn)看一看

關(guān)鍵的點(diǎn)就在下面的截圖代碼中。我們傳入的路徑是“/WEB-INF/../../Test.txt”,首先程序會判斷我們的路徑中是否存在“/../”，自然是存在的且索引是8大于0，所以第一個if 判斷不會成功，也就不會跳出while循環(huán)，此時處理我們的路徑，截取“/WEB-INF/..”以后的內(nèi)容，然后在用String,indexOf()函數(shù)判斷路徑里是否有“/../”,顯然還是有的，且索引為零，符合第二個if判斷的條件，return null。

此處的目的就是 不允許傳遞以“/../”為開頭的路徑，且不允許同時出現(xiàn)兩個連在一起的“/../” 所以我們最多只能讀取到webapps目錄，無法讀取webapps以外的目錄中的文件。

想要讀取webapps目錄下的其余目錄內(nèi)的文件可以通過修改數(shù)據(jù)包中的"URI"這個參數(shù)來實(shí)現(xiàn)

如此一來，程序最中拼接出我們所指定文件的絕對路徑，并作為返回值進(jìn)行返回

接下來就是回到getResource()函數(shù)進(jìn)行文件讀取了

以下是任意文件讀取的調(diào)用鏈

RCE

接下來講一下，RCE實(shí)現(xiàn)的原理

之前講過Tomcat $CATALINA_BASE/conf/web.xml這個配置文件中默認(rèn)定義了兩個Servlet，剛才任意文件讀取利用了DefaultServlet，而RCE就需要用到另一個也就是JspServlet

默認(rèn)情況下，JspServlet的url-pattern為.jsp和.jspx，因此他負(fù)責(zé)處理所有JSP文件的請求。

JspServlet主要完成以下工作：

1.根據(jù)JSP文件生成對應(yīng)Servlet的Java代碼（JSP文件生成類的父類我org.apache.jasper.runtime.HttpJspBase——實(shí)現(xiàn)了Servlet接口）

2.將Java代碼編譯為Java類。

3.構(gòu)造Servlet類實(shí)例并且執(zhí)行請求。

其實(shí)本質(zhì)核心就是通過JspServlet來執(zhí)行我們想要訪問的.jsp文件

所以想要RCE的前提就是，先要想辦法將寫有自己想要執(zhí)行的命令的文件(可以是任意文件后綴，甚至沒有后綴)上傳到webapps的目錄下，才能訪問該文件然后通過JSP模板的解析造成RCE

來看下我們這次發(fā)送的Ajp報文的內(nèi)容

這里的“URI”參數(shù)一定要是以“.jsp”進(jìn)行結(jié)尾的，這個jsp文件可以不存在。

剩下的三個參數(shù)就和之前沒什么區(qū)別了，“path_info”參數(shù)對應(yīng)的就是我們上傳的還有jsp代碼的文件。

我們定位到JspServlet.Service()方法

可以看到首先將"servlet_path"的值取出賦值給變量jspUri

然后將"path_info"參數(shù)對應(yīng)的值取出并賦值給“pathInfo”變量，然后和“jspUri”進(jìn)行拼接

接下來跟進(jìn)serviceJspFile()方法

首先生成JspServletWrapper對象

然后調(diào)用JspServletWrapper.service()方法

獲取對應(yīng)的Servlet

調(diào)用該Servlet的service方法

接下來就是就是解析我們上傳文件中的java代碼了至此，RCE漏洞原理分析完畢。下面是調(diào)用鏈

此次的漏洞存在于一個不是很常用的協(xié)議, Ajp協(xié)議上，雖然影響范圍沒有說想象中的嚴(yán)重，但是我測試了四個以上的Tomcat版本，默認(rèn)配置中都是有監(jiān)聽8009端口的，通常情況下如果將這些版本的Tomcat直接暴露在公網(wǎng)上提供服務(wù)的話，很大概率是會受到次漏洞的影響的，如果tomcat僅作為Servlet容器的話，外層有Apache這樣的web服務(wù)器，或者nginx這樣的反向代理服務(wù)器，Tomcat為這些服務(wù)器轉(zhuǎn)發(fā)過來的消息提供服務(wù)的話，很大程度上就會減少此漏洞造成的影響。此次漏洞的核心就在于Tomcat    對于Ajp協(xié)議的的處理上出現(xiàn)了問題，將核心參數(shù)對外暴露并且一定程度上可控。想要防止此次漏洞最好的方法就是將web.xml中監(jiān)聽8009端口的那項(xiàng)配置給注釋掉，哪怕Tomcat不直接對外提供服務(wù)的情況下仍然不可以掉以輕心。

上述內(nèi)容就是怎么深入分析Apache Tomcat從文件包含到RCE漏洞原理，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)頁題目：怎么深入分析ApacheTomcat從文件包含到RCE漏洞原理
文章來源：http://jinyejixie.com/article26/poedjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、域名注冊、標(biāo)簽優(yōu)化、外貿(mào)建站、App開發(fā)、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)