La vulnerabilidad zero-day en la popular librería Log4j ha generado repercusión más allá de la industria de la seguridad: esto es lo que sabemos hasta ahora
Justo cuando la temporada navideña se aproxima, una vulnerabilidad crítica en una librería de Apache llamada Log4j 2 ha llamado a la puerta. Log4j es una librería de registro de logs basada en Java que es ampliamente utilizada por muchos productos, servicios y componentes de Java. No es de extrañar que el fallo, que obtuvo un puntaje 10 sobre 10 en la escala de severidad CVSS y que pone en riesgo a innumerables servidores de que cibercriminales tomen control total de los mismos, haya tenido mucha repercusión más allá de la industria de la seguridad.
De hecho, con la publicación del código del exploit como prueba de concepto que ya está disponible online, ahora somos testigos de una carrera masiva entre actores maliciosos que están escaneando Internet y explotando sistemas vulnerables, y aquellos que se dedican a la defensa, que están actualizando los sistemas e implementando las mitigaciones correspondientes, así como los desarrolladores, que están auditando aplicaciones y librerías de código para cualquier dependencia que pueda incluir versiones vulnerables de la librería log4j.
Qué es Log4Shell
Indexada como CVE-2021-44228, el fallo consiste en una vulnerabilidad de ejecución remota de código (RCE, por sus siglas en inglés) que permite a un atacante ejecutar el código de su elección en un servidor afectado. Si el adversario de alguna manera obtiene acceso a la red local, incluso si los sistemas internos no están expuestos a Internet, la misma puede ser explotada. En última instancia, una vulnerabilidad de RCE significa que un atacante no necesita tener acceso físico para ejecutar código arbitrario que podría conducir a un control completo sobre los sistemas afectados y al robo de datos confidenciales.
Línea de tiempo
Para ayudar a entender cómo fueron transcurriendo los hechos entorno a esta vulnerabilidad crítica, aquí hay una línea de tiempo básica:
- 26 de noviembre: se reserva el ID de CVE para la vulnerabilidad.
- 1 de diciembre: El primer exploit conocido para esta vulnerabilidad es detectado en actividad en el contexto de un ataque.
- 10 de diciembre: se publica el ID de CVE y se lanza un parche.
- 11 de diciembre: a las 14:24 (CET), el módulo de protección contra ataques de red de ESET recibió una actualización de detección para cubrir esta vulnerabilidad.
Detección
ESET ha publicado una detección para exploits de esta vulnerabilidad que podrían estar presentes tanto en el tráfico entrante como saliente en los sistemas Windows. Los atacantes que intenten moverse lateralmente desde tales sistemas quedarán bloqueados. La detección contra intentos de explotación se implementó con los siguientes nombres de detección:
- JAVA/Exploit.CVE-2021-44228
- JAVA/Exploit.CVE-2021-44228.B
Pasos para la mitigación
Para protegerse de los exploits para esta vulnerabilidad es fundamental encontrar todas las versiones vulnerables de la librería. Comience por hacer una lista ordenada de sistemas en los cuales buscar, evaluándolos uno por uno a medida que avanza en la lista. La parte más complicada puede ser buscar en versiones vulnerables existentes en archivos Java Archive (JAR) como dependencias transitivas.
Aquí hay algunos scripts básicos que puede usar (que deben ser modificados para adaptarse a sus sistemas):
Detecte la presencia de Log4j en sus sistemas (Linux y Windows)
Este script, disponible en GitHub, busca el archivo JndiLookup.class defectuoso en cualquier archivo .jar de su sistema.
Linux
Código:
sudo grep -r --include "*.jar" JndiLookup.class /
Windows
Código:
findstr /s /i /c:"JndiLookup.class" C:\*.jar
Detecte intentos de explotación de la vulnerabilidad en sus registros (Linux)
Este script, también disponible en el enlace de GitHub anterior, busca intentos de explotación en archivos sin comprimir en el directorio de registros de Linux /var/log y todos sus subdirectorios:
Grep
Código:
sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log
Zgrep
Código:
sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+
Registre los resultados
Después de ejecutar cualquier script o herramienta de detección, asegúrese de registrar los resultados, ya que esto le permitirá crear una completa documentación de auditoría de todos sus sistemas. Una auditoría debe indicar si encontró Log4j en un sistema y si se descubrieron intentos de explotación en los registros.
Actualice a la última versión de Log4j
Todas las versiones de Log4j, desde la 2.0-beta9 a la 2.14.1, son vulnerables. Tenga en cuenta que esta librería no debe confundirse con log4j-api, que no se ve afectada por esta vulnerabilidad. El mejor remedio es actualizar sus dependencias para usar la última versión, que es 2.15.0.
Aunque las versiones 1.x de Log4j no se ven afectadas por esta vulnerabilidad en particular, presentan otras vulnerabilidades. Por lo tanto, es importante que existan planes concretos para migrar a la última versión de la librería. De hecho, ahora es el mejor momento para seguir adelante con esos planes.
Bloquear direcciones IP sospechosas
Finalmente, las direcciones IP que se sabe que son sospechosas pueden bloquearse con su firewall y/o sistema de prevención de intrusiones.
Fuente: https://www.welivesecurity.com/la-es/2021/12/14/que-se-sabe-sobre-vulnerabilidad-log4shell/
Marcadores