Peligro de extraños: hackeo en vivo de cómo funciona un exploit de Log4Shell

La vulnerabilidad Log4Shell tomó por sorpresa a la comunidad Java a finales de 2021, y muchas organizaciones aún están mitigando su impacto. Para ayudar a los equipos de desarrollo a mantenerse informados a medida que evoluciona la situación, Snyk creó y sigue actualizando su centro de recursos sobre la vulnerabilidad Log4j.

Durante un reciente hackeo en vivo de Stranger Danger, Simon Maple, Field CTO en Snyk; Eric Smalling, Senior Developer Advocate en Snyk; y Micah Silverman, Director de DevSecOps Acceleration, hablaron sobre la vulnerabilidad Log4Shell y demostraron cómo podría funcionar un exploit.

Log4Shell en pocas palabras

Log4Shell es una vulnerabilidad crítica, muy extendida y fácil de explotar en el framework de registro de Java Log4j2. Esta vulnerabilidad ha afectado a una gran cantidad de aplicaciones Java, ya que Log4j2 se usa con mucha frecuencia en muchas otras bibliotecas de código abierto.

«Como demuestra el hecho de que esta vulnerabilidad haya permanecido latente desde 2013, a veces hay efectos secundarios inesperados», dijo Micah. «Esto es parte de la naturaleza de los proyectos de código abierto».

Para corregir esta vulnerabilidad, los desarrolladores deben identificar dónde usan sus aplicaciones la biblioteca Log4j2 —como dependencia directa o indirecta— y actualizarla a la versión 2.17.1. Esto no solo mitiga la vulnerabilidad Log4Shell, sino también otra vulnerabilidad de denegación de servicio que se divulgó poco después.

¿Quieres saber más? Preparamos una guía completa para corregir Log4Shell.

Anatomía de Log4Shell

En 2013, se agregó a la biblioteca Log4j la posibilidad de usar referencias de Java Naming and Directory Interface (JNDI) mediante cadenas interpoladas en los mensajes de registro. Las cadenas interpoladas pueden contener variables, llamadas a funciones u otras expresiones que se pueden resolver. El problema es que JNDI puede buscar URL en estas cadenas y activar una conexión de red a un endpoint malicioso.

Además, un servidor LDAP no autorizado podría responder a la solicitud de JNDI con una referencia maliciosa a una clase Java remota u otro código no deseado. Esta clase podría deserializarse, incluso si no está en el classpath de la aplicación, lo que daría lugar a un ataque de ejecución remota de código (RCE).

Demostración del exploit Log4Shell

Para nuestra demostración del hackeo en vivo, usaremos un ejemplo de exploit Log4Shell (disponible en GitHub) que creamos en Java y ejecutaremos en un servidor Tomcat. Cuando ingresamos una contraseña incorrecta en la página de inicio de sesión, la aplicación nos informa que nuestros datos se registrarán.

«Es común registrar eventos en los frameworks de Java y en tu aplicación cuando se producen errores o excepciones, o a veces incluso durante una transacción normal», explicó Simon. «Esto te ayuda a entender los distintos flujos y cómo las personas usan tu sitio».

Al revisar el código de nuestra aplicación, vemos que cuando un nombre de usuario es incorrecto, usamos Log4j para registrarlo. Situaciones como esta, en las que los usuarios pueden ingresar datos que luego se registran, son la forma más común de explotar la vulnerabilidad Log4Shell.

Por ejemplo, podemos usar el campo de inicio de sesión para inyectar una cadena maliciosa que prepare el terreno para un ataque RCE. Pero primero, revisemos nuestro script de exploit en Python. Lo más importante que debes saber sobre este script es que genera una clase Java que crea un nuevo socket al inicializarse y luego se conecta a nuestro propio servidor.

«Esto formará parte de un proxy remoto que configuraremos», explicó Simon. «La clase se ejecutará en un bucle continuo: recibirá comandos, los ejecutará y los enviará de vuelta a nuestro servicio conectado».

Crearemos y compilaremos el archivo Java en nuestro servidor malicioso y lo pondremos a disposición mediante un servicio HTTP. Después, crearemos nuestro servidor LDAP, que enviará una cadena para que el servicio JNDI de la aplicación objetivo busque nuestra clase Java maliciosa.

Una vez que iniciemos el servidor LDAP y el servidor HTTP, estaremos casi listos para ejecutar el exploit. Para ejecutar la parte de «shell» de Log4Shell, también configuraremos un servidor proxy inverso con netcat, una utilidad de red. El proxy inverso nos permite ejecutar comandos remotos en el servidor Tomcat, lo que deja la aplicación y el servidor vulnerables a nuevos ataques.

Ejecutamos el exploit al ingresar nuestra cadena maliciosa en el campo de inicio de sesión de la página de acceso de la aplicación objetivo. Cuando Log4j registra esta cadena, la biblioteca también intenta resolverla. Esto hace que la aplicación use el servicio JNDI para conectarse al servidor LDAP, obtener la referencia a nuestra clase Java maliciosa en el servidor HTTP y ejecutarla localmente. Luego, esta clase Java se conecta a netcat y crea nuestro proxy inverso.

Mitiga Log4Shell con Snyk

Como mencionamos antes, la forma ideal de mitigar Log4Shell es identificar y actualizar todas las instancias de Log4j en tus dependencias directas e indirectas. Snyk Open Source puede analizar automáticamente tus dependencias para detectar paquetes con vulnerabilidades como Log4Shell.

La plataforma Snyk comienza por identificar y clasificar todos los artefactos de tu proyecto para determinar cómo analizarlos. Por ejemplo, Snyk realiza análisis de composición de software (SCA) en archivos pom.xml y pruebas estáticas de seguridad de aplicaciones (SAST) en archivos Java. Snyk también puede analizar configuraciones de infraestructura como código (IaC) y archivos Docker de aplicaciones en contenedores.

Después de analizar la aplicación vulnerable de arriba, podemos abrir los resultados del análisis del archivo pom.xml, que es el archivo de configuración de Maven que contiene nuestras dependencias. También podemos ver en la interfaz de Snyk el árbol de dependencias, que muestra que nuestra aplicación usa Log4j como dependencia directa e indirecta. Al hacer clic en la opción Corregir esta vulnerabilidad, Snyk puede abrir automáticamente un pull request (PR) para actualizar todas las instancias de Log4j a la versión 2.17.1. Si volvemos a ejecutar el exploit anterior, veremos que ya no funciona.

De manera similar, los desarrolladores pueden usar el complemento de Snyk para IntelliJ (u otro IDE) o la CLI de Snyk para analizar problemas de seguridad y corregirlos directamente durante el desarrollo. Snyk se integra en todo el proceso de desarrollo para simplificar la gestión de vulnerabilidades de las aplicaciones.

En algunas situaciones, las organizaciones no podrán actualizar de inmediato los paquetes vulnerables, por lo que tendrán que considerar otras opciones para mitigar los riesgos de Log4Shell. Los desarrolladores podrían eliminar la clase de búsqueda JNDI o implementar otras soluciones rápidas, pero estas no son tan eficaces como el parche oficial incluido en las versiones más recientes de la biblioteca.

Independientemente de cómo decidan mitigar la vulnerabilidad Log4Shell, Snyk puede ayudar a identificar instancias de Log4j y miles de otras posibles vulnerabilidades mediante el análisis de las dependencias de código abierto o los contenedores de un proyecto. Así, las organizaciones obtienen la visibilidad que necesitan para entender el perfil de riesgo de sus aplicaciones.