Es Log4Shell pero no como lo conocemos.
Ese es el resumen más breve que podemos hacer del fallo CVE-2021-42392, un agujero de seguridad del que han informado recientemente los investigadores de la empresa de gestión de la cadena de suministro de software Jfrog.
Esta vez, el fallo no se encuentra en el asediado kit de herramientas Log4j de Apache, sino en un popular servidor SQL de Java llamado H2 Database Engine.
H2 no es un sistema SQL tradicional como MySQL o Microsoft SQL server.
Aunque se puede ejecutar H2 como un servidor independiente para que otras aplicaciones se conecten a él, su principal reclamo es su modesto tamaño y su naturaleza autónoma.
Como resultado, puedes incluir el código de la base de datos H2 SQL en tus propias aplicaciones Java y ejecutar tus bases de datos completamente en memoria, sin necesidad de procesos de servidor separados.
Al igual que con Log4j, por supuesto, esto significa que puedes tener instancias en ejecución del código del motor de base de datos H2 dentro de tu organización sin darte cuenta, si utilizas alguna aplicación o componente de desarrollo que lo incluya.
JNDI de nuevo en el punto de mira
Al igual que la vulnerabilidad de Log4Shell, ésta depende del abuso de la interfaz de nombres y directorios de Java, más conocida como JNDI, que forma parte integral de toda instalación estándar de Java.
Se supone que JNDI facilita la identificación y el acceso a recursos útiles a través de la red, incluyendo la búsqueda y obtención de componentes de software almacenados remotamente utilizando protocolos de búsqueda y descubrimiento bien conocidos como LDAP (Lightweight Directory Access Protocol).
Por peligroso que parezca, es importante recordar que una funcionalidad similar puede codificarse en cualquier software (compilado o interpretado, script o binario) que tenga acceso a la red, pueda descargar datos arbitrarios y sea capaz de convertir esos datos en código ejecutable de algún tipo. JNDI simplemente facilita mucho la construcción de aplicaciones distribuidas que encuentran y cargan componentes remotos. Este tipo de comodidad programática a veces mejora la seguridad, porque a menudo es más fácil auditar y revisar el código cuando sigue una ruta bien documentada. Pero a veces reduce la seguridad, porque facilita la introducción de efectos secundarios inesperados por error. Lo vimos en Log4j, donde “escribir una cadena de texto para mantener un registro de los datos enviados por un usuario remoto” podía convertirse inadvertidamente en “descargar y ejecutar un programa no fiable especificado por un usuario remoto”.
Afortunadamente, a diferencia de Log4Shell, el fallo CVE-2021-42392 no puede activarse simplemente embebiendo texto con trampa en las consultas que se envían al motor de la base de datos H2.
Aunque Jfrog ha documentado varias formas en las que los ciberdelincuentes podrían, en teoría, engañar a H2 para que ejecute código remoto arbitrario, la ruta de ataque más probable implica:
- Una consola activa de H2 basada en la web. Se trata de un servidor web integrado que normalmente escucha en el puerto TCP 8082, y permite a los desarrolladores interactuar con el backend SQL de H2 mientras se está ejecutando. Si este puerto está bloqueado o la consola está inactiva, esta vía de ataque no funcionará.
- Una consola H2 escuchando en una interfaz de red externa. Por defecto, la consola sólo acepta conexiones desde el ordenador en el que se está ejecutando (localhost, normalmente el número IP 127.0.0.1 en una red IPv4). A menos que se cambie este valor por defecto, los atacantes necesitarían de todos modos un acceso local para poder acceder a la consola de H2.
Según H2, las aplicaciones que incrustan el motor H2 directamente en su código “no están expuestas externamente”, pero por lo que podemos ver esta nota se refiere sólo al motor de la base de datos en sí cuando no se está ejecutando como un servidor SQL, y no al componente de la consola web.
Lamentablemente, Jfrog señala:
Hemos observado que algunas herramientas de terceros que dependen de la base de datos H2 ejecutarán la consola H2 expuesta a clientes remotos por defecto. Por ejemplo, el framework JHipster también expone la consola H2, y por defecto establece la propiedad webAllowOthers en true.
(La configuración webAllowOthers es la propiedad Java utilizada por H2 para decidir si acepta conexiones desde interfaces de red externas).
La página de inicio de sesión de la consola web por defecto incluye un formulario que permite a los usuarios especificar cómo quieren conectarse a la base de datos.
Un usuario malintencionado podría utilizar este formulario para solicitar una búsqueda JNDI a través de LDAP, al igual que en un ataque Log4Shell, con el fin de engañar a H2 para que obtenga y ejecute un archivo Java .class remoto (un programa Java compilado).
Aunque una URL maliciosa utilizada para lanzar un ataque se enviaría en el mismo formulario de inicio de sesión que solicita un nombre de usuario y una contraseña, Jfrog descubrió que la búsqueda JNDI se realiza antes de verificar el nombre de usuario y la contraseña.
Esto significa que un atacante no necesita credenciales para explotar la vulnerabilidad, por lo que el fallo abre lo que se conoce como un agujero de ejecución remota de código no autenticado (RCE), el tipo más peligroso.
Para una demostración en vivo de cómo JNDI puede combinarse maliciosamente con las búsquedas JDAP para descargar y ejecutar código remoto no confiable, ve este video:
¿Qué hacer?
- Si tienes aplicaciones que utilizan el motor de base de datos H2, actualiza H2 a la versión 2.0.206.
En el momento de escribir este artículo, la versión 2.0.206 (lanzada el 4/1/22) figura como la más reciente, aunque el registro de cambios de H2 sigue indicando que la versión 2.0.206 es “inédita”, y no documenta CVE-2021-42392 como uno de los problemas solucionados.
Sin embargo, Jfrog afirma que la versión 2.0.206 incluye un cambio de código similar al que Apache utilizó en la actualización de Log4j 2.17.0: H2 ya no permite utilizar JNDI con ninguna referencia remota.
Esto significa, en teoría, que los atacantes ya no pueden hacer el truco de decir “haz una búsqueda, pero utiliza una petición de red que te lleve a una ubicación externa no fiable para que podamos manipular los resultados”.
Por lo que podemos ver, el motor de base de datos H2 actualizado ahora sólo utiliza JNDI para lo que son esencialmente llamadas a funciones Java locales, de modo que la ejecución de código remoto como efecto secundario inesperado del uso de JNDI ya no es posible, ni por accidente ni por diseño.
- Para encontrar instancias del código H2 en tu red, puedes buscar archivos llamados h2-*.jar.
El texto comodín denotado por * debe ser de la forma X.Y.Z, representando el número de versión de H2 que está en uso – cualquier cosa por debajo de 2.0.206 debe ser reemplazada por la última versión.
