2017年9月19日，Apache Tomcat官方确認并修複了兩個高危漏洞，漏洞CVE編号:CVE-2017-12615和CVE-2017-12616,該漏洞受影響版本為7.0-7.80之間，官方評級為高危，在一定條件下，攻擊者可以利用這兩個漏洞，擷取使用者伺服器上 JSP 檔案的源代碼，或是通過精心構造的攻擊請求，向使用者伺服器上傳惡意JSP檔案，通過上傳的 JSP 檔案 ，可在使用者伺服器上執行任意代碼，進而導緻資料洩露或擷取伺服器權限，存在高安全風險。
漏洞編号:
CVE-2017-12616
CVE-2017-12615
漏洞名稱:
CVE-2017-12615-遠端代碼執行漏洞
CVE-2017-12616-資訊洩露漏洞
官方評級:
高危，實際測試漏洞危害較低
漏洞描述:
CVE-2017-12616：資訊洩露漏洞
當Tomcat中啟用了 VirtualDirContext時，攻擊者将能通過發送精心構造的惡意請求，繞過設定的相關安全限制，或是擷取到由VirtualDirContext提供支援資源服務的JSP源代碼，進而造成代碼資訊洩露。
CVE-2017-12615：遠端代碼執行漏洞
當 Tomcat運作在Windows作業系統時，且啟用了HTTP PUT請求方法（例如，将 readonly 初始化參數由預設值設定為 false），攻擊者将有可能可通過精心構造的攻擊請求資料包向伺服器上傳包含任意代碼的 JSP 檔案，JSP檔案中的惡意代碼将能被伺服器執行。導緻伺服器上的資料洩露或擷取伺服器權限。
在一定的條件下，通過以上兩個漏洞可在使用者伺服器上執行任意代碼，進而導緻資料洩露或擷取伺服器權限，存在高安全風險。
漏洞利用條件:
CVE-2017-12615漏洞利用需要在Windows環境，且需要将 readonly 初始化參數由預設值設定為 false，經過實際測試，Tomcat 7.x版本内web.xml配置檔案内預設配置無readonly參數，需要手工添加，預設配置條件下不受此漏洞影響。
CVE-2017-12616漏洞需要在server.xml檔案配置VirtualDirContext參數，經過實際測試，Tomcat 7.x版本内預設配置無VirtualDirContext參數，需要手工添加，預設配置條件下不受此漏洞影響。
影響範圍:
CVE-2017-12615影響範圍： Apache Tomcat 7.0.0 - 7.0.79 (windows環境)
CVE-2017-12616影響範圍：Apache Tomcat 7.0.0 - 7.0.80
Apache Tomcat預設開啟PUT方法，org.apache.catalina.servlets.DefaultServlet的readonly預設為true，而且預設沒有在conf/web.xml裡寫，需要手工添加并且改為false，才可以測試。
本次Apache Tomcat兩個CVE漏洞涉及到 DefaultServlet和 JspServlet，DefaultServlet的作用是處理靜态檔案 ，JspServlet 的作用是處理jsp 與jspx 檔案的請求，同時DefaultServlet 可以處理 PUT 或 DELETE請求，以下是預設配置情況：
除了jsp和jspx預設是由org.apache.jasper.servlet.JspServlet處理，其他預設都是由org.apache.catalina.servlets.DefaultServlet來處理。
可以看出即使設定readonly為false，預設tomcat也不允許PUT上傳jsp和jspx檔案的，因為後端都用org.apache.jasper.servlet.JspServlet來處理jsp或是jspx字尾的請求了，而JspServlet中沒有PUT上傳的邏輯，PUT的代碼實作隻存在于DefaultServlet中。
這個漏洞的根本是通過構造特殊字尾名，繞過了tomcat檢測，讓它用DefaultServlet的邏輯去處理請求，進而上傳jsp檔案。
目前主要三種方法：
evil.jsp%20
evil.jsp::$DATA
evil.jsp/
利用這兩種姿勢PUT請求tomcat的時候，騙過tomcat而進入DefaultServlet處理的邏輯，如圖:
調試DefaultServlet.java代碼流程，如下:
設定readOnly為false
先調用棧
重點看doPut，這裡tomcat開始處理PUT請求，可以看到這裡如果readonly是true就直接進入error了，是以需要設定成false。
真正寫入檔案在FileDirContext.java的rebind函數裡。
上面遺留了一個問題就是當請求jsp%20或是jsp::$DATA字尾的時候，為什麼最終卻寫入.jsp字尾的檔案，這些其實是java.io. FileOutputStream的問題了，具體需要分析jdk的C代碼才能得到解答，如圖
跟到open是native的，已經不是java層面的問題了，這個open實際上是一個jni接口，然後調用windowsAPI CreateFileW建立檔案，這裡下載下傳openjdk6的jdk代碼分析，如圖:
這裡Java_java_io_FileOutputStream_open便是上邊java代碼裡open函數的C代碼實作，其中參數path對應open函數的name變量，繼續跟蹤，如圖:
繼續跟入winFileHandleOpen，這裡最終是調用windows的CreateFileW實作檔案建立，如圖：
而在windows下，建立檔案是對字尾名稱有要求的，例如：如果字尾末尾是空格，會被去掉，a.txt::$DATA傳入CreateFileW也會被處理成a.txt
前面沒有說evil.jsp/，這種方法也可以PUT上傳，但是不同于上面兩種，這種方法是利用了File類的特性，先看代碼，如圖:
這裡測試發現java.io.File會過濾掉子檔案名末尾的斜杠，寫一個測試用例确實是這樣的，如圖:
具體跟蹤一下代碼，如圖:
繼續跟入，如圖:
在這裡這個normalize(path, n, (prev == slash) ? i - 1 : i)會将檔案名末尾的/過濾掉，是以可以導緻後面檔案寫入jsp檔案。
Apache Tomcat 7預設值是 true，在預設條件下，無法成功利用這兩個漏洞。為了觸發漏洞，需要在conf/web.xml 中 defaultservlet 的配置readonly參數值為false。
我們通過構造的請求上傳b.jsp，執行該請求請求就會由DefaultServlet 處理，進而PUT操作就會順利執行，成功上傳檔案，以下通過構造請求，觸發并複現該漏洞：
在分析的時候，我們也發現File類存在一個利用點，normalize函數過濾掉了末尾斜杠。我們通過構造請求測試，發現可以被利用，通過對全版本測試，發現Windows、Linux、Unix下的Apache Tomcat 5.X、6.X、7.x、8.x、9.x版本均受到影響，從這點可以看出官方給出的更新檔存在繞過，目前該問題已經得到Apache官方的确認。
從以上分析可以得出，該漏洞利用的前提條件需要手動開啟readOnly功能，以支援上傳操作，在Apache tomcat 7.X版本預設配置的情況下是無法成功利用漏洞，從實際測試來看，漏洞危害性并沒有那麼高。
但是如果使用者一旦啟用了readOnly功能，黑客可利用漏洞成功入侵。
從以上分析可以得出，該漏洞利用的前提條件需要手動開啟readOnly功能，開發或運維人員可以排查是否啟用了PUT方法并開啟了readOnly功能。
根據業務評估配置conf/webxml檔案的readOnly值為Ture或注釋參數，禁用PUT方法并重新開機tomcat服務，臨時規避安全風險；
注意： 如果禁用PUT方法，對于依賴PUT方法的應用，可能導緻業務失效。
目前官方已經釋出了7.0.81版本修複了兩個漏洞，建議使用者盡快更新到最新版本；
對于最新版本繞過的問題，建議使用者持續關注官方資訊，及時更新到最新版本；
可以選用阿裡雲雲盾WAF産品進行防禦。
未使用WAF前：
成功上傳檔案
使用WAF後的防禦效果：
請求405報錯，上傳檔案失敗
除标準常用的GET和POST方法外，HTTP請求還使用其他各種方法，PUT方法是HTTP請求方法中的一種。此方法用于請求伺服器把請求中的實體儲存在請求資源下，如果請求資源已經在伺服器中存在，那麼将會用此請求中的資料替換原先的資料，作為指定資源的最新修改版。如果請求指定的資源不存在，将會建立這個資源，且資料位請求正文。
在以往的實際安全事件案例中，我們可以看到，由于PUT方法自身不帶驗證機制，有很多利用PUT方法很快捷簡單的成功入侵伺服器，上傳Webshell或其他惡意檔案，進而擷取敏感資料或伺服器權限，從web安全年最佳實踐來看，我們不推薦使用這些不安全的http OPTIONS方法。
從安全最佳實踐來說，我們應該遵循“最小化”原則，不要随意開啟不必要的服務或方法，僅開啟必要的功能，減小風險暴露面，進而降低安全風險，保障業務的安全性。
檢視響應的 Allow: GET, HEAD, POST, OPTIONS,TRACE
注：該測試僅限于自身業務。
IIS：
IIS預設拒絕PUT和DELETE請求，如果使用了不安全的方法，建議禁用webDAV子產品。
Apache:
Tomcat：
修改web.xml配置，增加以下内容，并重新開機tomcat服務：
最後感謝阿裡巴巴集團安全部柏通的技術支援。