Seguridad Log4Shell, el fallo de seguridad de la década
Cada mes aparecen nuevas vulnerabilidades que, en la mayoría de casos, se pueden parchear mediante actualizaciones de software. La gravedad de estos fallos suele variar, pero la de Log4Shell es una de las más peligrosas de la última década por los efectos que puede tener en los servicios que usamos a diario, y que incluso podrían permitir tomar el control del robot Ingenuity que se encuentra en Marte.
En los últimos días hemos conocido una grave vulnerabilidad que ha sido llamada Log4Shell, o LogJam. Un día después de conocerla, se ha publicado una prueba de concepto del exploit para aprovechar esta vulnerabilidad de día cero. La vulnerabilidad afecta al sistema de logueo de Apache Log4j, basado en Java. Su gravedad es de las más altas, ya que se trata de una vulnerabilidad no parcheada que permite la ejecución de código de manera remota en los dispositivos afectados.
Log4j es usado por multitud de servicios
A pesar de que la mayoría de servicios que utilizamos a diario han dejado de lado Java para el logueo, hay muchos que todavía los siguen utilizando. Multitud de programas para empresas, web apps y software de servidores de compañías como Apple, Amazon, Cloudflare, Twitter y Steam también lo utilizan.
La vulnerabilidad fue descubierta por el equipo de seguridad de Alibaba Cloud, y se la comunicaron a Apache el pasado 24 de noviembre. Por ello, Apache la comunicó el pasado día 10 junto con el lanzamiento del software que soluciona la vulnerabilidad. También afecta a algunas configuraciones de Apache Struts2, Apache Solr, Apache Druid, Apache Flink y otros.
Tras la publicación del exploit en GitHub, multitud de hackers han empezado a escanear Internet en busca de sistemas vulnerables. Si el sistema de logueo de un servicio utiliza una versión afectada por el fallo, un atacante puede acceder sin autenticación al servicio.
Cita:
Mass scanning activity detected from multiple hosts checking for servers using Apache Log4j (Java logging library) vulnerable to remote code execution (
https://t.co/GgksMUlf94).
Query our API for «tags=CVE-2021-44228» for source IP addresses and other IOCs.
#threatintel
— Bad Packets (@bad_packets) December 10, 2021
Todas las soluciones disponibles para el fallo
El bug, con código CVE-2021-44228, afecta a todas las versiones de Log4j 2.0-beta9 (lanzada en septiembre de 2013) hasta la 2.14.1 (lanzada en marzo de 2021). Por ello, todas las versiones de prácticamente los últimos ocho años son vulnerables. La actualización 2.15.0 lanzada la semana pasada ya soluciona la vulnerabilidad, y todas las versiones posteriores estarán protegidas.
En el caso de tener una versión entre la 2.10 y la 2.14.1, es posible mitigar el fallo cambiando el valor de «log4j2.formatMsgNoLookups» a «true», o eliminando la clase JndiLookup del classpath. No obstante, lo recomendable es actualizar lo más rápido posible para evitar sufrir los ataques que están lanzándose a sistemas de todo el mundo. Investigadores de Cybereason han lanzado también un paquete «vacuna» llamado Logout4Shell, que hace uso de la vulnerabilidad, pero para cambiar el ajuste que permite aprovecharla, quedando el dispositivo protegido.
Con estos ataques, se van a ir conociendo más dispositivos y sistemas vulnerables. La mayoría de infecciones que vamos a ver aquí buscarán introducir ransomware en los sistemas para proceder a pedir rescates en criptomonedas.
Este fin de semana conocidos que el helicóptero Ingenuity, lanzado junto con la Perseverance, utiliza Log4j. Por ello, técnicamente, si se pueden interceptar y descifrar los paquetes de datos que envía a la Tierra, sería posible hackear el robot y controlarlo de manera remota. No obstante, todo el tráfico que llega a la Tierra está cifrado.
Debido a lo peligroso que puede ser actualizar un software en un dispositivo al que no se tiene acceso, es posible que decidan no parchearlo. Lo más sensato en este caso es hacer el cambio en la configuración de «log4j2.formatMsgNoLookups», evitando así posibles ataques sin tener que actualizar el software.
En definitiva, es recomendable que actualices. Puedes conocer si estás afectado por la vulnerabilidad con Log4Shell-Detector.
Fuente: https://www.adslzone.net
Lo que se sabe hasta ahora de la vulnerabilidad Log4Shell
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/
Descubren una tercera vulnerabilidad en la librería Log4j
Además de los intentos de explotación activa a nivel global de la primera vulnerabilidad descubierta en Log4j, los atacantes ya están explotando la segunda y encima se descubre una tercera.
Despues de que el 1 de diciembre se detectara actividad del primer exploit conocido para la vulnerabilidad zero-day de ejecución remota de código (RCE) en Log4j (CVE-2021-44228), la librería para la generación de registros de logs en Java desarrollada por Apache, el 14 de diciembre se descubrió una segunda vulnerabilidad (CVE-2021-45046).
Este segundo fallo es de una severidad moderada (recibió un puntaje de 3.7 sobre 10 en la escala CVSS) y está presente incluso en la versión 2.15.0 que se lanzó hace una semana para corregir la primera vulnerabilidad, la cual es extremadamente crítica y fue catalogada con una severidad de 10 sobre 10. Actualmente ya está disponible la versión 2.16.0.
Al parecer, el parche para la CVE-2021-44228 en la versión 2.15.0 estaba incompleto y permitía la explotación de un segundo fallo, explicó Apache Software Foundation. Esta segunda vulnerabilidad permite a un actor malicioso llevar adelante ataques de denegación de servicio (DDoS) y fue reparada en la versión 2.16.0, por lo que se recomienda actualizar cuanto antes. Según explicaron especialistas de Cloudflare, esta segunda vulnerabilidad también está siendo explotada activamente.
Por si fuera poco, investigadores de la compañía Praetorian descubrieron una tercera vulnerabilidad en la versión 2.15.0 de Log4j. La misma permitiría a un actor malicioso bajo ciertas circunstancias exfiltrar datos sensibles de las víctimas. Según explicaron los especialistas, los detalles técnicos no serán divulgados por el momento para evitar que la situación se vuelva más compleja con los actuales intentos de explotación de la primera vulnerabilidad. Sin embargo, publicaron un video que demuestra la exfiltración en la versión 2.15.0.
Mientras tanto…
Considerando que la librería Log4j es ampliamente utilizada y por lo tanto una enorme cantidad de compañías y servicios reconocidos podrían estar expuestos a este fallo, días después de que se lanzó el parche para la zero-day el pasado 10 de diciembre, desde ESET comenzamos a detectar actividad maliciosa en todo el mundo intentando explotar la vulnerabilidad, aunque en mayor porcentaje en Estados Unidos y Reino Unido.
https://www.eset.com/fileadmin/_processed_/a/1/csm_MicrosoftTeams-image__2__f49699eb72.png
Los investigadores de ESET detectaron también que han estado escaneando la red en busca de UniFi Video, un sistema de la compañía Ubiquiti para la administración de cámaras de seguridad vía IP cuyo ciclo de vida terminó. Este sistema tiene versiones vulnerables tanto para Linux como para Windows y hay más de 8500 sistemas corriendo estas versiones.
Por otra parte, otras compañías de seguridad registraron en menos de 24 horas más de 60 nuevas variantes de exploit original y también se detectó al menos 10 muestras de malware diferentes intentando explotar la CVE-2021-44228, desde mineros de criptomonedas, troyanos como Tsunami o Mirai, así como herramientas como Meterpreter para realizar pruebas de pentesting. Por si fuera poco, ya se registró el primer grupo de ransomware aprovechando la vulnerabilidad log4shell. Se llama Khonsari y se sabe que los actores de amenaza detrás de este ransomware utilizaban el mismo servidor para distribuir el RAT Orcus. Por otra parte, en las últimas horas se detectó la explotación de Log4Shell para obtener acceso inicial y descargar el el ransomware Conti.
Desde ESET publicamos el siguiente artículo que incluye pasos para la mitigación de la CVE-2021-44228, cómo detectar la presencia de Log4j en Linux y Windows y cómo detectar también los intentos de explotación de esta vulnerabilidad.
Lectura relacionada: Lo que todo líder de una empresa debe saber sobre Log4Shell
Fuente: https://www.welivesecurity.com/la-es/2021/12/17/descubren-tercera-vulnerabilidad-libreria-log4j/
Guía de mitigación de Log4j publicada por el Departamento de Seguridad Nacional de Estados Unidos
La Agencia de Ciberseguridad e Infraestructura del Departamento de Seguridad Nacional de Estados Unidos (CISA) ha publicado unas recomendaciones sobre el plan de actuación frente a la ya extendida vulnerabilidad de Apache Log4j.
En primer lugar, los fabricantes deberían identificar, mitigar y actualizar los productos que utilicen Log4j a la última versión de la librería.
Por otro lado, todas las organizaciones deberían tomar las siguientes acciones inmediatamente:
- Identificar todos los activos que sean accesibles a través de Internet que permitan la entrada de datos por parte del usuario y utilicen la librería Log4j en algún lugar de su infraestructura.
- Identificar todos los activos que utilicen Log4j.
- Actualizar o aislar los activos afectados. Una vez identificados, la organización deberá buscar indicadores de compromiso y patrones habituales de actividades de post-explotación. Se asumirá que el activo ha sido comprometido.
- Monitorizar patrones de tráfico poco habitual. Por ejemplo, tráfico de salida relacionado con los protocolos JNDI, LDAP/RMI, DNS o DMZ.
Flujo de actuación para identificar instalaciones vulnerables. Fuente https://www.cisa.govUna vez contenido el riesgo, los usuarios u organizaciones afectadas deberán actualizar la librería a la última versión disponible siempre que sea posible. En caso de que la actualización no sea posible, se recomiendan tomar las siguientes contramedidas:
- Desactivar el software que utilice la librería. Lo que podría limitar la visibilidad de otros problemas operacionales, al ser ĺa librería encargada de tomar registros.
- Bloquear las búsquedas JNDI. Es una opción efectiva, pero que puede requerir un trabajo de desarrollo y una pérdida de funcionalidad.
- Desconectar temporalmente las infraestructuras afectadas. Esto reduciría la posibilidad de un ataque.
- Crear una red aislada para separar las infraestructuras afectadas del resto de la red de la entidad.
- Desplegar un WAF para proteger a las infraestructuras afectadas. Si bien no es una solución completa, puede ayudar a reducir el número de amenazas.
- Aplicar micro-parches. Existen algunas soluciones que no forman parte de la actualización oficial pero que pueden ayudar a mitigar los riesgos para algunos casos concretos.
Para mantenerse actualizado, la CISA ha creado un repositorio de Github donde publicará las actualizaciones de este protocolo de actuación: https://github.com/cisagov/log4j-affected-db
Más información:
Apache Log4j Vulnerability Guidance
Fuente: https://unaaldia.hispasec.com/2021/12/guia-de-mitigacion-de-log4j-publicada-por-el-departamento-de-seguridad-nacional-de-estados-unidos.html
