La Clave del Oráculo

Hubo un tiempo en que me llamaban para arreglar Oracles y enseñar a la gente a gestionar los tablespaces transportables, a gestionar los parámetros de los init.ora y como funcionaban los pmon y los simones. Montar Oracles con tres puntos de montaje y gestionar las copias de seguridad con el rman y realizar el siempre tan complejo tunning de los servidores oracle.

De todos aquellos tiempos me ha quedado un recuerdo agridulce y un cierto conocimiento del producto estrella de la casa del barquito molón, por eso siempre me gusta conocer las peculiaridades de seguridad del producto. Desde el año 2005 en que lo enfilaron algunos investigadores de seguridad como Cesar Cerrudo o David Litchfield se han visto en el ojo del huracán.

A finales de año 2005 Sans Institute publicó un documento titulado "An Assessment of the Oracle Password Hashing Algorithm" en el que contaba como se podían crackear los hashes de las cuentas de usuario de una base de datos analizando en un chulisimo ejemplo como el algoritmo de generación de passwords concatena usuario y password en mayusculas para luego hacer unas bonitas divisiones. Llegando a las siguientes conclusiones:

- Weak password salt selection;
- Lack of alphabetic case preservation;
- Weak hashing algorithm.

El "salting", como ya sabréis todos, se usa para evitar que dos usuarios con la misma password tengan el mismo hash (las casualidades ocurren, sobre todo con las passwords tontas). El proceso que usa Oracle es pensar, “vale, podrán tener la misma password, pero nunca el mismo par usuario y password”, es decir que no puede haber dos usuarios “pepe” con contraseña “namorao”, con lo cual, si uno los dos y luego hago el hash siempre serán único. Cagada. Podemos tener los siguientes pares pep/enamorao y pepe/namorao que deberían dar la misma unión.

La gente de Sans creo dos usuarios e hizo la siguiente prueba:


¿A que mola? Pasa de minúsculas y encima genera el mismo hash, porque lo hace concatenando el usuario y la password. Por último tras analizar el algoritmo utilizado por Oracle:

1. Concatenate the username and the password to produce a plaintext string;

2. Convert the plaintext string to uppercase characters;

3. Convert the plaintext string to multi-byte storage format; ASCII characters have the high byte set to 0x00;

4. Encrypt the plaintext string (padded with 0s if necessary to the next even block length) using the DES algorithm in cipher block chaining (CBC) mode with a fixed key value of 0x0123456789ABCDEF;

5. Encrypt the plaintext string again with DES-CBC, but using the last block of the output of the previous step (ignoring parity bits) as the encryption key. The last block of the output is converted into a printable string to produce the password hash value.

Sucede igual que cierta fase de cierto reto que aún no tiene solucionario, es decir, que no es costoso computacionalmente cepillárselo, así que hicieron unos cálculos con ataques de diccionario y con ataques de raimbow tables y se podían computar unas 830.000 passwords al día, dejando una contraseña de 8 caracteres cepillada en menos de 40 días con la fuerza bruta y una vez calculadas las rainbow en menos de 4 minutos estaba lista la password.

Claro, este método siempre implicaba el acceso a los hashes a lo cual Oracle contestó con un mail a sus clientes:

Dear Oracle customer,

Oracle Global Product Security has investigated the recent publication by Joshua Wright of the SANS Institute, and Carlos Cid of the University of London’s Royal Holloway College, entitled “An Assessment of the Oracle Password Hashing Algorithm.” This paper presents an analysis of the Oracle Database password hashing algorithm. It describes potential attacks against this algorithm when an attacker has access to password hash information.

Oracle considers adherence to industry standard security practices the best way for customers to protect their database systems. In particular, issues noted in the paper can be addressed through limiting access to password hash information, and by enforcing good enterprise password policies. Moreover, Oracle customers have authentication options available which avoid the issues described in this paper.
[...]

Así que puedes cambiar el mecanismo de autenteicación o tener un "Mundo Perfecto", pero ¿qué sucede en un Mundo Perfecto?

What happens if this attack is launched in a perfect world? In the perfect world all systems - database and host operating system - are fully patched. No known exploits work. All users have only got the privileges they really need. Unauthorized hash retrieval is not possible. Default username/password combinations do not exist anymore since passwords are changed or accounts are disabled. Therefore unauthorized access is not possible. In a prefect world, if a database administrator selects a view or table containing the hashes1, it will be recorded in the audit trail and disciplinary action can be taken. In such an environment, the conclusion is that an attacker will not be able to obtain the encrypted passwords. No reference material means no cracking therefore no risk. End of story? No, not at all.

Así comienza el documento que ha publicado vonjeck en The Hacker Choice.

En este caso, en este Perfect World existen los clientes que se autentican por la red, y es ahí donde se han centrado. El objetivo ha sido analizar el algoritmo que utiliza un cliente para probar su identidad. Para resolver el misterio han hecho unas pruebitas muy chulas usando TOAD como cliente.

El algoritmo estaba descrito en “Advanced Oracle Administrtor Guide” de la siguiente forma:

The purpose of Authentication Key Fold-in is to defeat a posible third party attack (historically called the man-in-the-middle attack) on the Diffie-Hellman key negotiation. It strengthens the session key significantly by combining a shared secret, known only to the client and the server, with the original session key negotiated by Diffie-Hellman.

The client and the server begin communicating using the session key generated by Diffie-Hellman. When the client authenticates to the server, they establish a shared secret that is only known to both parties. Oracle Advanced Security combines the shared secret and the Diffie-Hellman session key to generate a stronger session key designed to defeat a man-in-the-middle attack.

¿Shared Secret? Malo, malo. Si un shared secret (clave compartida) circula por la red es malo. El objetivo ha sido descubrir como funciona ese Shared Secret. Lo curioso es que esa clave es solo conocida por el cliente y el servidor. MMMM. Y lógicamente no será la misma para todas las conexiones, ¿no?. Efectivamente, es distinta. ¿A que no adivináis que es algo que conocen solo el cliente y el servidor? Pues evidentemente algo que derive del hash de la password.

¿Cómo? ¡No es posible! Pues sí. Tirando del hilo han analizado el proceso completo para poder generar una herramienta que capturando el tráfico de inicio de sesión poder realizar un ataque por fuerza bruta y les ha dado la siguiente tabla de tiempos:


Por suerte,esto no funciona siempre así, tras hacer varias pruebas han visto que con clientes nativos en las versiones 9i y 10g el comportamiento es distinto, pero sin embargo con drivers no-Oracle o drivers no-nativos se produce una degradación y el funcionamiento es como el descrito en el documento. Así, por ejemplo con Oracle JDBC Thin Driver incluido en la version 10g Release 2 se fuerza a Oracle 9i and 10g a funcionar de esta manera. Este driver, por ejemplo, es común en desarrollos en entornos IBMWebSphere, Apache TomCat y BEA WebLogic, además, es posible inyectar paquetes que degraden el funcionamiento de 9i y 10g a esta forma de trabajo.

Poca cosita, ¿no? ¿Quiéres probarlo? Bájate las tools que están en este sitio.