hasegawatadamitsu/cve-2014-0094-test-program-for-struts1CVE-2014-0094 programa de prueba para struts1
Este documento resume el impacto de CVE-2014-0094 en struts1. A menos que se indique lo contrario, cada versión fue verificada con java 1.7.0_02, struts 1.3.10, apache-tomcat-6.0.39, FreeBSD 8.2.
Además, bajo ninguna circunstancia se garantiza el contenido del código fuente, de los documentos, etc. Tampoco me hago responsable de ningún evento que pueda ocurrir. Especialmente si se hace mal uso de este contenido, no me involucro en absoluto. (Aunque no haya nada novedoso al respecto).
En esta ocasión, ofrezco ejemplos concretos de soluciones basándome en varias webs. Excepto hechos ya conocidos, he indicado las URL de referencia en las fuentes. Agradezco a quienes hicieron pública esa información.
He intentado evitar los términos demasiado técnicos y usar un lenguaje comprensible, aunque quizá haya inexactitudes.
En cuanto a la vulnerabilidad actual en struts1, parece que tiene nombres como CVE-2014-0094, S2-020, etc., no está muy claro, pero por ahora la llamaremos CVE-2014-0094.
No hace falta repetirlo, pero CVE-2014-0094 conlleva un problema muy grave.
http://www.nta.go.jp/sonota/sonota/osirase/service.htm
"Aviso de suspensión del servicio (importante) de e-Tax (versión web), 'Rincón de creación de declaraciones de impuestos', 'NISA (ISA japonesa)' - 25 de abril de 2014" Según esto, el servicio web de la Agencia Tributaria Nacional usaba struts1, y suspendió el servicio el mismo día en que se descubrió.
Se cree que se detuvo rápidamente para minimizar los daños.
Al realizar pruebas prácticas aquí, con solo acceder a la URL, se confirmó la interrupción del servicio y la filtración de archivos arbitrarios.
Con solo acceder a una URL, usando una dirección de correo anónima, enviando un correo con la URL a una lista de correo, es difícil identificar al culpable y se puede interrumpir el servicio fácilmente.
¿Es realmente un problema tan fácil de atacar?
Esto es lo más importante. Si un tercero ha anunciado que al menos podría haber un impacto, lo correcto es detener primero el sistema para evitar que el daño se extienda. Aunque luego se descubra que no hubo impacto, la información filtrada no se recupera. Por supuesto, se requiere un juicio político. En una empresa, se cuestiona la ética, la conciencia del problema cotidiano, la gestión de riesgos, etc.
Este problema se origina en que algunos valores de configuración del sistema pueden ser reescritos parcialmente. Es necesario investigar qué valores de configuración son reescribibles. Dependiendo de esos valores, se determina qué tipo de ataque es posible.
Estos valores de configuración varían según el contenedor de Servlet. En tomcat6 probablemente no sea posible ejecutar código arbitrario, pero en tomcat8 sí es posible. Además, según el entorno (jetty, WebSphere Application Server, etc.), es necesario verificar qué valores de configuración existen.
En tomcat6, se pueden modificar 23 valores de configuración, y si se cambia class.classLoader.resources.dirContext.docBase el funcionamiento normal del sistema se vuelve imposible, y además, en lugar de mostrar JSP, al especificar un archivo en el servidor, se puede obtener (filtrar) cualquier archivo.
En tomcat8 se puede ejecutar código arbitrario, pero esto se debe a que hay más valores que se pueden configurar en comparación con tomcat6. Si el contenedor Servlet utilizado no tiene ese valor de configuración, por ahora se considera que el problema es menor.
El cambio de valor de configuración de esta ocasión puede realizarse incluyendo la cadena en la URL, también como campo oculto en una solicitud normal, y también es posible incluir ese valor en una cookie.
Desde los registros de acceso, no se puede saber si se ha establecido como campo oculto.
A menudo se realizan reinicios los domingos por la noche, pero justo antes de eso, se reescribe docBase y se obtienen archivos, y luego el sistema se reinicia, por lo que al administrador del sistema le resulta difícil notar la anomalía. Si en ese intervalo se producen muchos estados 404, 500, es probable que se haya producido una fuga de algún archivo.
struts1 ha llegado al final de su soporte (dejando de lado qué significa el soporte de código abierto), y no hay parches de seguridad. Es necesario resolverlo por sí mismo.
El origen del problema está en BeanUtil, y es necesario implementar que ignore las cadenas inapropiadas que lleguen. BeanUtil es una herramienta para cambiar los valores de configuración de objetos (es una forma muy simplificada).
Ejemplos de implementación:
com.haselab.struts.filter
web.xml
Explicación breve: En web.xml se llama a un programa que cambia el comportamiento de BeanUtil al iniciar el sistema. Se invoca a SafeResolverListener.java, y a partir de entonces BeanUtil utilizará SafeResolver.java. SafeResolver.java devuelve "" si la cadena a analizar (ignorando mayúsculas/minúsculas) es 'classLoader'. Es decir, impide que se pueda asignar un valor arbitrario a classLoader. Para este comportamiento, se ha tomado como referencia: https://gist.github.com/nakamura-to/11347570 (Es un programa corto, así que se usa tal cual).
Si en la aplicación es necesario cambiar la configuración de classLoader, este método impediría esa configuración, por lo que no sería válido. Pero generalmente no se debería usar el nombre 'classLoader', así que no hay problema de entrada. Si hay dudas, se puede buscar en todo el código fuente de la aplicación: grep -r -i classLoader * y confirmar que no existe.
Verificamos la reescritura de docBase. Después de desplegar con mvn, mire la carpeta struts en el navegador. Cada vez que se pulsa un botón, se reescribe docBase y se muestra el archivo /etc/passwd.