A pesar de que ya estamos viendo no pocos resúmenes de lo más importante acontecido en materia de ciberseguridad durante este 2021, al que ya le quedan pocos días para despedirse parece que, un año más, no vamos a poder cerrar este resumen hasta que estemos comiéndonos las uvas. Y es que si 2020 se despedía con el uso malicioso del software de SolarWinds para realizar ataques de cadena de suministro para acceder a empresas y organizaciones, este 2021 no quiere despedirse sin antes revelarnos una de las vulnerabilidades más destacadas de los últimos años.
¿En qué consiste Log4Shell?
Justo cuando muchos estaban cerrando los últimos flecos para dejarlo todo bien atado antes de celebrar (COVID-19 mediante) las navidades, saltaba la noticia del descubrimiento de una nueva vulnerabilidad con la máxima puntuación de criticidad posible (10 de 10). Bautizada como Log4Shell, este agujero de seguridad permite la ejecución remota de código por parte de un atacante en un servidor que sea vulnerable, aunque también puede ejecutarse sobre sistemas que no estén conectados a Internet si el atacante consigue acceder a la red interna.
Pero, vayamos por partes. Esta vulnerabilidad se ha encontrado en una librería del código de Apache llamada Log4j 2, la cual es una librería de registro de código abierto basada en Java que, actualmente, es usada en muchos productos, servicios y componentes de Java. No es de extrañar entonces que, siendo una vulnerabilidad fácilmente explotable y que permite la ejecución remota de código haya sido protagonista de numerosos titulares durante los últimos días, llegando a ser bautizada por algunos como “la vulnerabilidad de la década”.
Lo cierto es que, con todos los detalles de la vulnerabilidad ya publicados y con pruebas de concepto disponibles para cualquiera que quiera probarla, estemos asistiendo a una carrera entre atacantes que están realizando escaneos masivos por todo internet en busca de sistemas vulnerables, miembros de equipos de defensa o blue teams que llevan días actualizando sistemas y aplicando medidas de mitigación, y desarrolladores, quienes están revisando todas las aplicaciones y librerías de código en busca de cualquier dependencia que pueda incluir versiones vulnerables de la librería Log4j.
Cronología y detección de la vulnerabilidad
Las primeras noticias acerca de la explotación de esta vulnerabilidad aparecieron el pasado viernes 9 de diciembre, cuando la versión de la librería que solucionaba este agujero de seguridad se había publicado unos días antes (6 de diciembre). Sin embargo, tras varias investigaciones han descubierto ataques que la aprovechaban, como mínimo, desde el pasado 1 de diciembre, si bien algunos indicios apuntan que esta vulnerabilidad podría incluso llegar a haber sido utilizada por atacantes durante años, tal y como revelan investigaciones presentadas en BlackHat USA en 2016.
Con respecto a la detección y mitigación de los exploits que traten de aprovecharse de esta vulnerabilidad, ya son varias las soluciones de seguridad que bloquean su ejecución en aquellos sistemas protegidos. No obstante, lo mejor sigue siendo reconocer que sistemas se pueden ver afectados por este agujero de seguridad, al ser Log4j una librería ampliamente utilizada, y parchearlos.
En el caso de las soluciones de ESET, la empresa lanzó el pasado 11 de diciembre actualizaciones para su módulo de protección frente ataques de red con la finalidad de detectar los intentos de explotación de esta vulnerabilidad, bloqueando así los intentos de movimientos laterales que intenten realizar los atacantes. Los nombres utilizados para detectar estos ataques han sido JAVA/Exploit.CVE-2021-44228 y JAVA/Exploit.CVE-2021-44228.B.
De hecho, desde que se añadió esta detección, los intentos de explotación de esta vulnerabilidad se han catapultado hasta la primera posición en la detección de amenazas, según la telemetría de ESET, superando incluso a los intentos de acceder por fuerza bruta a sistemas conectados mediante RDP, ataques que llevaban meses ocupando los primeros puestos.
Pasos para mitigar posibles ataques
Sabiendo que no son pocos los atacantes que están tratando de explotar esta vulnerabilidad durante estos días, es importante aplicar medidas para estar debidamente protegido. Lo primero es encontrar cualquier tipo de software que esté utilizando una versión vulnerable de la librería Log4j, estableciendo un listado de sistemas prioritarios para empezar a buscar en ellos y evaluando su estado frente a esta vulnerabilidad.
Gracias a la comunidad de investigadores se han podido generar unos scripts básicos que permiten detectar la presencia de Log4j y que pueden ser usados modificándolos para adecuarlos a las características de nuestros sistemas.
- Detectando la presencia de Log4j en sistemas Linux y Windows
Este script, disponible en Github, busca archivos JndiLookup.class en cualquier fichero .jar presente en el sistema
Linux
sudo grep -r --include "*.jar" JndiLookup.class /Windows
findstr /s /i /c:"JndiLookup.class" C:\*.jar- Detectando intentos de explotación de la vulnerabilidad en los logs (Linux)
Este script también se encuentra disponible en el enlace a GitHub mencionado anteriormente y busca intentos de explotación en ficheros sin descomprimir dentro del directorio para logs de Linux (/var/log/) y todos sus subdirectorios.
Grep
sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/logZgrep
sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+- Guardando los resultados
Tras ejecutar los scripts o herramientas de detección, debemos asegurarnos de guardar los resultados para así poder generar una documentación completa de la auditoría de nuestros sistemas. Esta auditoría debería indicar si se encontró la librería Log4j en el sistema y si se descubrieron intentos de explotación de la vulnerabilidad Log4Shell en los logs.
- Actualizar a la última versión de Log4j
Las versiones vulnerables de Log4j son aquellas que van desde la 2.0-beta9 hasta la 2.14.1. Es importante no confundir esta librería con log4j-api, la cual no se encuentra afectada por esta vulnerabilidad. La mejor opción es actualizar las dependencias usadas a la última versión disponible, que en el momento de escribir este artículo es la 2.16.0 y que deshabilita JNDI por defecto.
A pesar de que las versiones 1.x de Log4j no se ven afectadas por esta vulnerabilidad en particular, sí que se ven afectadas por otros agujeros de seguridad. Este sería un buen momento para actualizar esas versiones antiguas a la más reciente.
- Bloqueo de direcciones IP sospechosas
Aquellas direcciones IP que son conocidas por ser usadas por atacantes deberían estar bloqueadas por el cortafuegos el sistema de prevención de intrusos instalado.
- Permanecer informado acerca de la evolución de esta vulnerabilidad.
A pesar de que han pasado pocos días desde que esta vulnerabilidad se hizo pública, ya hay una gran cantidad de información al respecto y las medidas de mitigación y detección se van actualizando constantemente. Por ese motivo es importante permanecer actualizado en hilos mantenidos por investigadores, como este de Reddit, para así aplicar las contramedidas necesarias en el caso de que surjan novedades.
Conclusión
Aun teniendo en cuenta la gravedad de la vulnerabilidad y de lo extendida que se encuentra la librería Log4Shell, hemos de poner toda la información disponible en perspectiva antes de correr como pollos sin cabeza tras leer algunos de los titulares sensacionalistas que hemos podido leer durante estos últimos días. Sí, la vulnerabilidad es grave, pero la solución está disponible y hay muchos métodos para mitigar una posible explotación, incluyendo la instalación de software de seguridad capaz de detectar este tipo de exploits.