Voy a escribir un artículo que a más de un dba Oracle le dará qué pensar, y si es algo proactivo, le hará realizar algún que otro cambio en las bases de datos que administra.
à  ƒómo de fácil pensáis que es obtener la contraseña del usuario SYSTEM o cualquier otro usuario?
Os doy la respuesta: muy fácil.
à  ˆay alguna manera de evitarlo?
Os contaré las ideas que se me han ocurrido. Pero cualquier otra que podáis aportar seguro que es bien recibida.
Introducciéndonos...
Bueno, antes de continuar quería comentar que no he encontrado ninguna información sobre este tema en castellano, y la que hay en inglés está muy dispersa.
Oracle almacena las claves en la tabla SYS.USER$, en la columna PASSWORD, utilizando un algoritmo que es una variación del estándar MD5. El algoritmo de cifrado es unidireccional, lo que significa que no se puede descifrar la clave tomando la cadena almacenada en la columna PASSWORD.
Podéis visualizar el nombre de usuario con su clave cifrada con cualquiera de estas consultas:
SE LECT NAME,PASSWORD from SYS.USER$; ó SELEC T NAME,PASSWORD from DBA_USERS;
Según leí en las news en comp.databases.oracle, más concretamente en este mensaje de 1993, se venía a decir que Oracle para generar las claves lo que hace es convertir el nombre de usuario y la password que se le da a mayúsculas, por lo que la clave cifrada será la misma si, por ejemplo, tu contraseña es "tiger" ó "Tiger" ó "TiGEr" y a partir de ahí aplica un proceso a la cadena resultante que para el tema que nos ocupa no es lo más importante.
En el mensaje al que hago referencia también habla en el punto 3 de que una de las metas cuando se diseñó el algoritmo de cifrado debía ser que para distintos usuarios con la misma password, la cadena cifrada resultante debe ser distinta:
"3. If different users have the same password, then the one-way
hash value (encrypted value) for the passwords will be different."
Esto lo consiguieron de una manera muy simple, que consiste en hacer que lo que se cifra no es sólamente la password, sino una concatenación del nombre de usuario + password, previamente convertido a mayúsculas. La forma en que se demuestra esto es la siguiente:
Si tenemos un usuario 'ARTURO' con contraseña 'Secreto', su cadena almacenada en la columna PASSWORD se cifrará a partir de 'ARTURO'+'SECRETO'.
Si tenemos un usuario 'ART' con contraseña 'Urosecreto', su cadena almacenada en la columna PASSWORD se cifrará a partir de 'ART'+'UROSECRETO'.
Con la siguiente query comprobaremos que la clave cifrada es la misma:
SQL> selec t username,password from dba_users where username LIKE 'ART%'
USERNAME PASSWORD
-- ---------------------------- ------------------------------
ARTURO 621V3E7638423350
ART 621V3E7638423350
Esta forma de cifrar la clave también significa que la clave cifrade del usuario 'SCOTT' con la contraseña 'TIGER' será 'F894844C34402B67' en todas las instalaciones de Oracle del mundo mundial.
Como ya he dicho, el algoritmo es unidireccional así que olvidaros de intentar descifrar la clave. Pero con lo que acabamos de ver, y sabiendo que ya hay programas que pueden cifrar cadenas usando el algoritmo MD5 modificado que usa Oracle, vemos que sólo con tener el nombre de usuario y la cadena de la columna PASSWORD es posible mediante comparación, por fuerza bruta o ataque de diccionario, obtener la clave.
Un ejemplo práctico de cómo romper la clave
La utilidad que encontré para "romper" claves de Oracle se llama orabf.exe, que se puede descargar con su manual directamente de aquí http://static.natalian.org/2005-11-27/orabf-v0.7.4.zip.
Esta primera prueba está hecha con el usuario SCOTT, aunque resulta inútil porque antes de empezar comprueba las passwords por defecto:
C:>orabf.exe F894844C34402B67:SCOTT -c 3
orabf v0.7.5, (C)2005 orm(at)toolcrypt.org---------------------------------------
Trying default passwords...
password found: SCOTT:TIGER
En esta segunda el usuario SCOTT tiene otra password:
orabf.exe 225E25B9A5319105:SCOTT -c 3
orabf v0.7.5, (C)2005 orm(at)toolcrypt.org---------------------------------------
Trying default passwords...done
Starting brute force session using charset:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
press 'q' to quit. any other key to see status
password found: SCOTT:
51297999 passwords tried. elapsed time 00:00:44. t/s:1153610
Si a alguien le interesa mucho cómo romper la clave puede investigar más el manual de este programa. Nosotros ya hemos visto que es posible obtener las contraseñas, así que nos centraremos en cómo evitar que puedan hacerlo con nuestras bases de datos.
A proteger la base de datos...
Ahora mismo no tengo demasiado tiempo para dar explicaciones de cada una de las medidas a tomar. Iré nombrando las que se me ocurren:
1.- Estaremos protegidos siempre y cuando nadie tenga acceso a
2.- Nunca utilizar claves como "chupete", "temporal", "madrid", etc, pues son más vulnerables a ataques por diccionario.
3.- Hemos visto en la prueba de arriba, que con una ataque de fuerza bruta se comprueban aproximadamente 1 millón de contraseñas por segundo. Esto significa que tardaría menos de una semana en hacer todas las combinaciones para una contraseña de 8 caracteres y sólo unas horas si por ejemplo, repartiéramos el trabajo en 10 pcs. Por lo que el tercer consejo es: usar siempre contraseñas muy largas y cambiarlas cada pocos días.
4.- No repetir contraseñas.
A todo esto sólo añadir una cosa. Haber encontrado esta debilidad a Oracle no significa que sea peor que otra base de datos. Como habéis visto, con poco esfuerzo adicional en la administración no significará un problema. Por ejemplo SQL Server, que es otra base de datos que creo conocer bastante bien, tiene maneras más variadas de conseguir superacceso, o como lo queráis llamar, a su base de datos. Empezando porque sólo se puede instalar sobre Windows, que ya supone un problema de seguridad para todo lo que ahí se encuentre, y más aún cuando pertenece a un dominio o se tiene acceso físico a la máquina. Pero sobre esto no escribiré nada porque ya hay bastante información en español en Internet.