Logo Web Xombra.com

Sitios Web Promocionados

Visitalos!

Xombra.com  - Seguridad Informatica!

Nube de TAGS

solucionada años después grave vulnerabilidad oracle db xombra solucionado remota cve reportada investigador auditor software joxean koret matalaz afecta versiones database versión g r permitiría controlar tráfico cliente servidor modificarlo través ataque mitm soluciona fallo importante polémica evidenciado pobre gestión seguridad

.:Categorías:.

Aniversarios (11) Apple (31) Bugs (1917) Exploits (26) Gnu/linux (803) Hack (505) Información (22) Microsoft Windows (189) Mozilla (117) Noticias (701) Opinion (325) Php (46) Seguridad (994) Virus Y Troyanos (737)

Solucionada (4 años después) grave vulnerabilidad Oracle DB - xombra.com

Oracle ha solucionado una grave vulnerabilidad remota (CVE-2012-1675) reportada en 2008 por el investigador y auditor de software Joxean Koret (@matalaz), que afecta a todas las versiones de Oracle Database (desde 8i hasta la versión 11g R2). La vulnerabilidad permitiría controlar el tráfico cliente-servidor y modificarlo, a través de un ataque MITM. Oracle soluciona el fallo tras una importante polémica en la que se ha evidenciado su pobre gestión de la seguridad.

La vulnerabilidad reside en el servicio TNS Listener, encargado de gestionar el establecimiento de las comunicaciones entre las distintas instancias de la base de datos, sus servicios y el cliente. Por diseño y sin requerimiento de autenticación, cuando se procesa el registro de dos o más instancias de base de datos con el mismo nombre, el TNS Listener crea automáticamente un balanceador de carga entre todos los servidores de base de datos registrados. Por tanto, cualquier otro servidor que se añada a posteriori recibirá de manera prioritaria el tráfico de cualquier otro cliente de la red.

Ese error de diseño, definido por defecto en las bases de datos de Oracle, genera que para esa nueva instancia añadida, se cree un cluster de tipo Oracle RAC o una instancia Oracle Fail over. Estos actúan como balanceadores y procesan todo el tráfico posterior.

La llamada exacta encargada de la conexión y que no requiere de autenticación sería:

COMMAND=SERVICE_REGISTER_NSGR

En el momento que se le responda con un nombre de servicio que ya esté registrado, por ejemplo: 'ORCL11' el atacante sólo tendría que ir registrando la instancia continuamente, cerrando el socket anterior de la conexión, para así hacer creer al sistema que se trata de un registro legítimo de un balanceador de carga. Al ser el último en registrarse, será a su vez el primero en recibir el tráfico de cliente.

El ataque por tanto, se basaría en 'enrutar' de manera eficiente ese tráfico hacia una máquina especialmente manipulada para recibirlo, procesarlo y devolver en su caso las respuestas necesarias a la víctima. Según el ataque, se conseguiría capturar más del 50% del tráfico establecido entre clientes y servidor, funcionando sólo como sniffer de red (TNS proxy). Si se procediera a la inyección arbitraria de código, tendríamos además el control total de las posibles víctimas que pasaran por nuestro proxy, reenviándoles SQL queries especialmente manipuladas o apoderándonos de la sesión de usuario y haciéndonos pasar por usuarios legítimos frente al servidor.

Para ello, se proporciona una prueba de concepto (sniffer) que permite inspeccionar las llamadas realizadas entre el cliente y el servidor de Oracle DB y como ilustración, existe un video que demuestra la vulnerabilidad:

La polémica

Uno de los aspectos más curiosos de este fallo es cómo ha salido a la luz. Joxean Koret reportó la vulnerabilidad hace cuatro años (aunque probablemente lleve ahí desde 1999). En el último lote de parches, Joxean fue mencionado como uno de los colaboradores al que se le daba crédito por corregir un fallo. Cuando Joxean escribió a Oracle para saber qué fallo descubierto por él había sido corregido (ha reportado varios), se le confirmó que era este. Ante este panorama, Koret publicó todos los detalles técnicos del problema, pensando que ya estaba corregido.

Habiendo recibido un correo bastante "subrealista" por parte del equipo de seguridad de Oracle, decidió continuar con la comunicación. En el correo Oracle afirmaba que "the vulnerability was fixed in future releases of the product", lo que no tiene sentido (fue corregida en futuras versiones).

Koret, dispuesto a llegar al final del asunto, preguntó de forma directa y simple si se había corregido o no el fallo, a lo que Oracle continuó respondiendo con frases hechas y excusas sin sentido. Finalmente, se confirmó que, aunque Oracle lo había afirmado en su lote de parches, en realidad este gravísimo fallo no había sido corregido.

Tras la polémica, finalmente Oracle ha roto su ciclo de actualizaciones para publicar un CVE y un parche.

Más información:

Oracle Security Alert for CVE-2012-1675
https://blogs.oracle.com/security/entry/security_alert_for_cve_2012

Oracle TNS Poison vulnerability is actually a 0day with no patch available
http://seclists.org/fulldisclosure/2012/Apr/343

The history of a -probably- 13 years old Oracle bug: TNS Poison
http://seclists.org/fulldisclosure/2012/Apr/204

CVE-2012-1675 Oracle Database TNS Poison 0Day Video Demonstration
http://eromang.zataz.com/2012/04/30/oracle-database-tns-poison-0day-video-demonstration/

Oracle Database TNS Listener Poison Attack (2008)
http://www.joxeankoret.com/download/tnspoison.pdf

Fuente:
Por José Mesa Orihuela y Sergio de los Santos
Twitter: @ssantosv
http://unaaldia.hispasec.com/



Publicado el: 03/05/2012
Por: sinfallas
Visto: 359538 Veces


Imprimir PDF