"Es Log4Shell, Jim", como nunca dijo el comandante Spock, "pero no como lo conocemos".

Ese es el resumen más breve que se nos ocurre del error. CVE-2021-42392, agujero de seguridad informado recientemente por investigadores de la empresa de gestión de la cadena de suministro de software Jfrog.

Esta vez, el error no está en el asediado juego de herramientas Log4j de Apache, sino que se puede encontrar en un popular servidor Java SQL llamado Motor de base de datos H2.

H2 no es como un sistema SQL tradicional como MySQL o el servidor Microsoft SQL.

Aunque puede ejecutar H2 como un servidor independiente para que se conecten otras aplicaciones, su principal motivo de fama es su tamaño modesto y su naturaleza autónoma.

Como resultado, puede empaquetar el código de la base de datos H2 SQL directamente en sus propias aplicaciones Java y ejecutar sus bases de datos completamente en la memoria, sin necesidad de procesos de servidor separados.

Al igual que con Log4j, por supuesto, esto significa que es posible que tenga instancias en ejecución del código del motor de base de datos H2 dentro de su organización sin darse cuenta, si utiliza alguna aplicación o componente de desarrollo que lo incluya silenciosamente.

JNDI de nuevo en el centro de atención

Al igual que el Vulnerabilidad de Log4Shell, éste depende del abuso de la Interfaz de nombres y directorios de Java, mejor conocido como JNDI, que es una parte integral de cada instalación estándar de Java.

Se supone que JNDI facilita la identificación y el acceso a recursos útiles en su red, incluida la búsqueda y obtención de componentes de software almacenados de forma remota utilizando protocolos de búsqueda y descubrimiento conocidos como LDAP (el protocolo ligero de acceso a directorios).

Por peligroso que suene, es importante recordar que se puede codificar una funcionalidad similar en cualquier software (compilado o interpretado, script o binario) que tenga acceso a la red, pueda descargar datos arbitrarios y pueda convertir esos datos en código ejecutable de algunos clasificar. JNDI simplemente hace que sea mucho más fácil crear aplicaciones distribuidas que encuentren y carguen componentes remotos. Este tipo de conveniencia 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. Vimos esto en Log4j, donde "escriba una cadena de texto para mantener un registro de los datos enviados por un usuario remoto" podría convertirse sin darse cuenta "descargar y ejecutar un programa no confiable especificado por un usuario remoto".

Afortunadamente, a diferencia de Log4Shell, el error CVE-2021-42392 no puede activarse simplemente incorporando texto con trampas explosivas en consultas que se envían al motor de base de datos H2.

Aunque Jfrog ha documentado varias formas en que los ciberdelincuentes podrían, en teoría, engañar a H2 para que ejecute un código remoto arbitrario, la ruta de ataque más probable implica:

• Una consola basada en web H2 activa. Este es un servidor web incorporado que generalmente escucha en el puerto TCP 8082 y permite a los desarrolladores interactuar con el backend H2 SQL 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. De forma predeterminada, la consola solo acepta conexiones desde la computadora en la que se está ejecutando (localhost, generalmente número de IP 127.0.0.1 en una red IPv4). A menos que se cambie este valor predeterminado, los atacantes necesitarán acceso local de todos modos antes de poder acceder a la consola H2.

Según H2, las aplicaciones que incrustar el motor H2 directamente en su código “no están expuestos externamente”, pero por lo que podemos ver, esta nota se refiere solo al motor de la base de datos en sí mismo cuando no se ejecuta como un servidor SQL, y no al componente de la consola web.

Desafortunadamente, 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 de forma predeterminada. Por ejemplo, el marco JHipster también expone la consola H2 y, de forma predeterminada, establece el webAllowOthers propiedad a true.

(El ajuste webAllowOthers es la propiedad de Java utilizada por H2 para decidir si acepta conexiones de interfaces de red externas).

La página de inicio de sesión de la consola web predeterminada incluye un formulario que permite a los usuarios especificar cómo desean conectarse a la base de datos.

Un usuario malintencionado podría usar este formulario para solicitar una búsqueda JNDI a través de LDAP, al igual que en un Ataque Log4Shell, para engañar a H2 para que obtenga y ejecute un Java remoto .class archivo (un programa Java compilado).

Aunque una URL traicionera 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 de JNDI ocurre antes de que se verifiquen el nombre de usuario y la contraseña.

Esto significa que un atacante no necesita credenciales de trabajo para explotar la vulnerabilidad, por lo que el error abre lo que se conoce como un ejecución remota de código no autenticado (RCE) agujero, el tipo más peligroso.

APRENDA CÓMO SE COMBINAN JNDI Y LDAP PARA LA EJECUCIÓN REMOTA DE CÓDIGO

Para una demostración en vivo de cómo JNDI se puede combinar maliciosamente con búsquedas JDAP para descargar y ejecutar código remoto que no es de confianza, mire este video:

Si no puede leer claramente el texto del video aquí, intente usar el modo de pantalla completa, o ver directamente en Youtube. Haga clic en el engranaje del reproductor de video para acelerar la reproducción o activar los subtítulos.

¿Qué hacer?

• Si tiene aplicaciones que utilizan el motor de base de datos H2, actualizar H2 a la versión 2.0.206.

En el momento de escribir este artículo, 2.0.206 (lanzado el 2022-01-04) está listado como la última versión, aunque la registro de cambios H2 todavía enumera 2.0.206 como "inédito"y no documenta CVE-2021-42392 como uno de los problemas solucionados.

Jfrog, sin embargo, afirma que 2.0.206 incluye un cambio de código similar al que Apache usó en la actualización de Log4j 2.17.0: H2 ya no permite que JNDI se use con ninguna referencia remota.

Esto significa, en teoría, que los atacantes ya no pueden lograr el truco de decir "haga una búsqueda, pero use una solicitud de red que lo lleve a una ubicación externa no confiable para que podamos manipular los resultados".

Por lo que podemos ver, el motor de base de datos H2 actualizado ahora solo usa JNDI para lo que son esencialmente llamadas de función Java locales, por lo que la ejecución remota de código como un 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 su red, puede buscar archivos llamados h2-*.jar.

El texto comodín denotado por * debe ser de la forma X.Y.Z, que representa el número de versión de H2 que está en uso; todo lo que esté por debajo de 2.0.206 debe reemplazarse con la versión más reciente.