El fallo crítico en la base de datos SQL de Java de código abierto H2 es similar a la vulnerabilidad Log4J, pero no supone una amenaza generalizada.
Los investigadores descubrieron un fallo relacionado con la vulnerabilidad de la biblioteca de registro Log4J, que en este caso abre la puerta a que un adversario ejecute código remoto en sistemas vulnerables. Sin embargo, este fallo no supone el mismo riesgo que el identificado anteriormente en Log4Shell, dijeron.
La empresa de seguridad JFrog descubrió el fallo y lo calificó de crítico en el contexto de la consola de base de datos Java H2, una popular base de datos de código abierto, según una publicación del jueves en el blog de los investigadores.
H2 es atractiva para los desarrolladores por su solución ligera en memoria -que excluye el requisito de que los datos se almacenen en el disco- y se utiliza en plataformas web como Spring Boot y plataformas de IoT como ThingWorks.
Sin embargo, el fallo (CVE-2021-42392) es similar al de Log4Shell. "No debería estar tan extendido" debido a algunas condiciones y factores, escribieron los investigadores de JFrog Andrey Polkovnychenko y Shachar Menashe en su post.
Log4Shell (CVE-2021-44228) se vinculó a la biblioteca de registro Apache Log4j a principios de diciembre e inmediatamente fue explotada por los atacantes. Se crearon 60 variantes del exploit original creado para el fallo en un periodo de 24 horas, así como una corrección defectuosa que podía causar ataques DoS cuando se publicó por primera vez.
¿En qué se parece el fallo de H2 a Log4J?
La raíz del fallo de H2 se basa en la carga remota de clases JNDI, por lo que es similar a Log4Shell en el sentido de que permite que varias rutas de código en el marco de la base de datos H2 pasen URLs no filtradas controladas por el atacante a la función javax.naming.Context.lookup. Esto permite la carga remota de código, también conocida como inyección de código Java o ejecución remota de código, dijeron los investigadores.
"En concreto, el método org.h2.util.JdbcUtils.getConnection toma como parámetros el nombre de la clase del driver y la URL de la base de datos", explicaron en el post. "Si la clase del controlador es asignable a la clase javax.naming.Context, el método instanciará un objeto de la misma y llamará a su método de búsqueda".
Razones para tener cuidado, pero no para entrar en pánico
Sin embargo, a diferencia de Log4Shell, el fallo de H2 tiene un alcance de impacto "directo", lo que significa que normalmente el servidor que procesa la solicitud inicial -es decir, la consola de H2- sentirá el peso directo del fallo de ejecución remota de código (RCE), escribieron los investigadores en un post publicado el jueves.
"Esto es menos grave en comparación con Log4Shell, ya que los servidores vulnerables deberían ser más fáciles de encontrar", escribieron los investigadores.
"Esto es diferente a Log4Shell que era explotable en la configuración por defecto de Log4j", escribieron los investigadores. Aun así, la consola H2 puede modificarse fácilmente para escuchar también conexiones remotas, lo que ampliaría el riesgo, añadieron los investigadores.
De hecho, este aspecto de la ejecución del fallo disminuye definitivamente su gravedad en comparación con el problema de Log4j, señaló un profesional de la seguridad.
"Log4j era único en el sentido de que cualquier número de cadenas manipuladas por el ataque, desde cabeceras hasta rutas de URL, podía dar lugar a la explotación de la víctima dependiendo de cómo se configurara la aplicación para utilizar el registro con Log4j", escribió Matthew Warner, director de tecnología y cofundador del proveedor de tecnología de detección y respuesta automatizada de amenazas Blumira, en un correo electrónico a Threatpost. "En este caso, la consola de la base de datos H2 debe ser expuesta a propósito a Internet cambiando la configuración".
En tercer lugar, aunque muchos proveedores pueden estar ejecutando la base de datos H2, es posible que no ejecuten la consola H2 con ella, dijeron los investigadores de JFrog. Hay otros vectores de ataque que pueden explotar el fallo de H2; sin embargo, son "dependientes del contexto y es menos probable que estén expuestos a atacantes remotos", observaron los investigadores.
¿Quién está en riesgo?
Si el fallo de H2 no merece la misma alarma que el de Log4Shell, cabe preguntarse por qué merece la pena destacarlo. El equipo de JFrog dijo que puede ser extremadamente crítico y permitir un RCE no autenticado a quienes ejecutan una consola H2 expuesta a una red de área local (LAN) o, peor aún, a una red de área amplia (WAN). De hecho, atacar directamente la consola H2 es el vector de ataque más grave, según los investigadores.
Warner, de Blumira, dijo que, según la información de fuente abierta (OSINT), es probable que haya menos de 100 servidores en Internet afectados por el fallo H2, "por lo que sólo un número muy limitado de organizaciones" se ven directamente afectadas, dijo.
"Esta vulnerabilidad es un buen recordatorio de que es importante asegurarse de que los servicios sensibles sólo se exponen internamente para mitigar posibles riesgos futuros", añadió Warner.
Aun así, los investigadores de JFrog señalaron que muchas herramientas para desarrolladores dependen de la base de datos H2 y exponen específicamente la consola H2. Esto es preocupante debido a la "reciente tendencia de ataques a la cadena de suministro dirigidos a los desarrolladores, como paquetes maliciosos en repositorios populares".
Estos ataques enfatizan "la importancia de que las herramientas para desarrolladores sean seguras para todos los casos de uso razonables", escribieron los investigadores, por lo que esperan que muchas herramientas dependientes de H2 sean más seguras después de aplicar su corrección recomendada.
En este sentido, el equipo de JFrog recomienda a todos los usuarios de la base de datos H2 que se actualicen a la versión 2.0.206, que corrige la CVE-2021-42392 limitando las URLs JNDI para que utilicen únicamente el protocolo java local, negando cualquier consulta LDAP/RMI remota, explicaron los investigadores.
"Esto es similar a la corrección aplicada en Log4j 2.17.0", escribieron.
Incluso aquellos que no utilicen directamente la consola H2 deberían actualizar "debido al hecho de que existen otros vectores de ataque, y su explotación puede ser difícil de determinar", añadieron los investigadores.
Fuente: https://threatpost.com/log4j-related-flaw-h2-database/177448/