Ciberseguridad

Una nueva vulnerabilidad del tipo Log4Shell afecta a la base de datos H2 Java SQL

Los investigadores advierten de un fallo crítico de Java que afecta a la consola de la base de datos H2 Java SQL. Se aconseja a los usuarios que actualicen su base de datos H2 para mitigar el riesgo de ejecución remota de código.

hacker, ciberseguridad
Crédito de foto: Clint Patterson.

Los investigadores han advertido de un nuevo fallo crítico de Java que afecta a la consola de la popular base de datos H2 Java SQL, con la misma causa de fondo que la vulnerabilidad Log4Shell de Apache Log4j. Según los especialistas de JFrog, el problema conlleva un riesgo crítico de ejecución remota de código (RCE) sin autenticación para ciertas organizaciones que deberían actualizar sus bases de datos H2 inmediatamente.

 

Similar a la de Log4Shell, pero menos grave

La causa de la vulnerabilidad H2 es similar a la de Log4Shell, pero el alcance de la explotación es menor. Al igual que Log4Shell, el fallo (CVE-2021-42392) está relacionado con la carga remota de clases de la interfaz de nombres y directorios de Java (JNDI). Un atacante podría desencadenar un RCE si es capaz de insertar una URL maliciosa en una búsqueda JNDI, según explican los investigadores de JFrog en una entrada de su blog.

Según explican desde JFrog , "en pocas palabras, la causa raíz es similar a la de Log4Shell: varias rutas de código en el marco de la base de datos H2 pasan URLs no filtradas controladas por el atacante a la función javax.naming.Context.lookup, lo que permite la carga remota de código (es decir, inyección de código Java o ejecución remota de código)". Cualquier organización que ejecute una consola H2 que esté expuesta a su LAN o WAN se encuentra en riesgo crítico, mientras que la amenaza que suponen las herramientas de desarrollo dependientes de H2 también es significativa.

Sin embargo, los investigadores añadieron  que CVE-2021-42392, que actualmente está a la espera de ser analizada por la National Vulnerability Database, difiere significativamente de la vulnerabilidad Log4j en su alcance de explotación. "A diferencia de Log4Shell, esta vulnerabilidad tiene un alcance de impacto 'directo'. Esto significa que, por lo general, el servidor que procesa la solicitud inicial (la consola H2) será el que reciba el impacto del RCE. Esto es menos grave en comparación con Log4Shell, ya que los servidores vulnerables deberían ser más fáciles de encontrar".

Además, en las distribuciones vanilla de la base de datos H2, la consola H2 solo escucha conexiones localhost por defecto, lo que consigue que la configuración por defecto sea segura. "Esto es diferente a Log4Shell, que era explotable en la configuración por defecto de Log4j"según indican en la publicación referida. Desde JFrog  explican que muchos vendedores también pueden estar ejecutando la base de datos H2, pero no ejecutando la consola H2 en sí, y aunque hay otros vectores para explotar este problema aparte de la consola, estos son dependientes del contexto y es menos probable que estén expuestos a los atacantes remotos.

Para comprobar si una organización es vulnerable a CVE-2021-42392, los administradores de red pueden escanear sus subredes locales en busca de instancias abiertas de la consola H2 con nmap.

 

Cómo mitigar la amenaza RCE de CVE-2021-42392

Por su parte, Chris Morgan, analista senior de inteligencia de ciberamenazas en Digital Shadows, a explicado que la nueva vulnerabilidad va a a los equipos de seguridad dolores de cabeza similares a los de la revelación de Log4Shell, porque puede afectar especialmente a los paquetes de Apache Maven, una herramienta de gestión y comprensión de proyectos de software. Tal y como ha asegurado, "al igual que con Log4Shell, uno de los principales obstáculos será apresurarse a identificar los sistemas susceptibles y remediarlos antes de que los atacantes puedan explotarlos en ataques en vivo".

Para solucionar el problema y reducir el riesgo de ser víctima de un RCE, todos los usuarios de la base de datos H2 deberían actualizar a la versión 2.0.206, que limita las direcciones URL JNDI para utilizar únicamente el protocolo Java (local), según los investigadores de JFrog.  Y esto debe hacerse incluso si no están utilizando directamente la consola H2, “porque existen otros vectores de ataque, y su explotabilidad puede ser difícil de determinar", aclaran.

Si no es posible actualizar H2, las nuevas versiones de Java que contienen la mitigación trustURLCodebase pueden evitar que se carguen bases de código remotas de forma ingenua a través de JNDI. Sin embargo, esta mitigación no es a prueba de balas, y está activada por defecto en las siguientes versiones de Java o posteriores: 6u211, 7u201, 8u191 y 11.0.1.

Además, "cuando el Servlet de la consola H2 se despliega en un servidor web (no utilizando el servidor web H2 independiente), se puede añadir una restricción de seguridad que permitirá sólo a determinados usuarios acceder a la página de la consola", según aseguran desde la publicación de JFrog.



TE PUEDE INTERESAR...

Accede a la cobertura de nuestros encuentros
 
Lee aquí nuestra revista digital de canal

DealerWorld Digital

 

Forma parte de nuestra comunidad
 
¿Interesado en nuestros foros? 

 

Whitepaper