Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Finalizamos la serie hablando de ataques de diccionario en el mundo de las contraseñas de Oracle. En el tercer capítulo de la entrega comentamos cómo se obtenían las distintas combinaciones de usuario y hash de clave en Oracle. Recordad que propusimos algunos ejemplos reales en una instalación XE, disponibles en http://www.sahw.com/images/oracle_audit/usuarios.txt.

Los ataques de diccionario son tremendamente fáciles de ejecutar cuando se dispone de los hashes, y dependerá de la calidad de nuestro diccionario, así como de la complejidad de la clave a analizar, el éxito de la prueba. Como en cualquier otro ataque de diccionario, se trata de obtener el hash de una palabra conocida (presente en el diccionario) y verificar si es igual al del usuario cuya contraseña estamos analizando. En caso de que coincidan, la clave del usuario será la palabra que estemos empleando en el diccionario.

Ejemplos

Una de las herramientas más conocidas, aunque no es la única, es checkpwd, que podéis obtener en http://www.red-database-security.com/software/checkpwd.html. Su empleo es extremadamente sencillo, y puede ejecutarse en Windows, Linux y MacOS. Cuenta además con un binario que realizará la verificación sin mostrar la contraseña, con lo que se puede preservar el conocimiento de la misma. Adicionalmente permite al auditor ejecutar la verificación tanto offline como directamente contra la base de datos, método con el cual no haría falta obtener la relación de hashes.

Oracle Audit

En el siguiente ejemplo, conectamos a la base de datos y hacemos la verificación. El operador -quiet hará que solo se muestren las contraseñas que sea posible vencer por ataque de diccionario, no apareciendo las claves que resitan el ataque:

Oracle Audit

Los métodos de ataque en línea no están recomendados, salvo que se tenga permiso expreso para ello. Por tanto, si tenéis que analizar offline un fichero con cientos o incluso miles de usuarios, emplear la utilidad se vuelve tedioso, ya que para cada caso, hay que introducir el usuario y el hash. Para facilitaros la vida, he escrito este sencillo script Perl con el que sólo hay que procurar tener un fichero llamado usersandpasswordhashes.txt en el que en cada linea, separado por al menos un espacio, haya una relación de usuario y hash. Los usuarios de sistemas no Windows, siéntanse libres de modificar las llamadas al sistema.

#!/usr/bin/perl -w
# chechpwd.exe automation 
 	
my $input="usersandpasswordhashes.txt";
my $output="checkpwd_audit_results.txt";

open (INPUT,"< $input") || die "ERROR: Cannot open entry file $input\n";
		
while ($line=){	
		
	my @string = split (" ", $line);
	my $userandhash = $string[0].":".$string[1];	
    print "Analyzing username $string[0]\n\n"; 	
	system("ECHO ===================== >> $output");
	system("ECHO $string[0] >> $output");
	system("ECHO ===================== >> $output");	
	system("checkpwd.exe $userandhash password_file.txt >> $output");	
    system("ECHO. >> $output");
	} 
			
close INPUT;	

Tenéis un ejemplo del fichero que produce el script en http://www.sahw.com/images/oracle_audit/checkpwd_audit_results.txt

Pues aquí acaba nuestro recorrido por la auditoría de contraseñas en Oracle Database. Espero que estos contenidos os sean de utilidad y os ayuden a mejorar la calidad de las claves presentes en vuestros sistemas.

Un saludo,

Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle

TEMARIO

Auditoría de contraseñas en Oracle Database (1 de 4). Introducción y primeros pasos
Auditoría de contraseñas en Oracle Database (2 de 4). Adivinación de Oracle SID (System ID)
Auditoría de contraseñas en Oracle Database (3 de 4). Fuerza bruta sobre claves Oracle
Auditoría de contraseñas en Oracle Database (4 de 4). Ataques de diccionario sobre claves Oracle

Buenas,

Continuando con lo explicado en los dos primeros artículos toca hablar de cómo utilizar ataques de fuerza bruta para evaluar la calidad de las claves Oracle. No obstante, antes de hacerlo, es preciso comprender dónde y cómo se almacenan las claves.

Distintas versiones, distintas ubicaciones

Las contraseñas Oracle se guardan, por norma general, en una tabla llamada DBA_USERS. Excepciones a esta norma hay muchas, así por ejemplo, SYS.USER$, o la tabla USERS$, lugar donde se almacenan en la versión XE que estamos utilizando para esta serie de artículos.

Oracle passwords

Históricamente la presencia de numerosos usuarios de sistema en la configuración de fábrica ha supuesto y sigue suponiendo muchos problemas para la seguridad Oracle. Me recuerda al caso de los servidores de largo y medio alcance de IBM, donde los sistemas operativos suelen venir con una cantidad ingente de usuarios creados que si no son modificados pueden provocar un problema cuando el sistema entre en producción.

A lo largo de los años, y según han ido cambiando las versiones de Oracle, también han ido cambiando los métodos de generación y conservación de claves. Desde el cifrado de la concatenación de usuario y clave en las versiones entre 7 y 10g R2 hasta el empleo de salts en 11g, donde se emplea SHA-1 para generar un hash de la concatenación de clave y salt. Para cada versión el auditor debe repasar la documentación y comprender cómo y dónde se conservan las claves. Tenéis un estupendo artículo al respecto en http://www.red-database-security.com/whitepaper/oracle_passwords.html que puede servir de orientación.

Es importante reseñar que desde la versión 11g en adelante los hashes no se almacenan en DBA_USERS. En esta versión hay que recuperar los campos name y spare4 de SYS.USER$.

SELECT name,spare4 FROM SYS.USER$ WHERE password is not null;

Tampoco entraremos a comentar otras ubicaciones donde puedan estar presentes los hashes de las claves, como las vistas que se hayan creado, duplicados de las tablas, rollbacks, copias de seguridad, etc. En definitiva, la misión del auditor es identificar dónde están las claves y obtener la relación usuario-hash para poder así realizar una verificación de calidad de las mismas. También es importante determinar quién puede obtener esos datos, qué permisos son necesarios y por supuesto, hay que indagar en todos los métodos posibles para obtenerlos, incluyendo el pentesting.

Caja negra, gris y blanca

En el primero de los casos, las pruebas irán encaminadas, mediante pentesting, a hacernos con un listado de usuarios y hash de clave para tratar de obtener claves en claro. El ataque constará de dos partes:

  • Intrusión al sistema, habitualmente por cuentas con clave por defecto no modificadas o bien aprovechando algún exploit que nos permita el acceso.
  • Extracción de relación de usuarios y hashes, bien por haber logrado acceso privilegiado que permita hacerlo directamente, bien por provocar escalada de privilegios que nos permita finalmente obtener la relación. En algunos casos, si la configuración de seguridad no es adecuada, bastará con tener los privilegios mínimos para obtener la relación.

En el caso de caja gris el auditor tratará de obtener la relación de usuarios empleando las credenciales no privilegiadas que le han sido entregadas. Es frecuente, por mala configuración, que incluso los perfiles más bajos puedan obtener la relación de usuarios y hashes. Este modelo es análogo al de caja negra, pero con la diferencia de que el auditor contará de partida con una cuenta en el sistema.

Para el caso de caja blanca, que será el que ejemplifiquemos, el auditor solicitará al DBA que extraiga la relación de usuarios y hashes para analizarlas.

Los usuarios especiales y los datos críticos, el botín más cotizado

Siempre que sea posible, habida cuenta de que por defecto son las cuentas más poderosas, el análisis tendrá en cuenta especialmente los siguientes usuarios: SYS, SYSTEM, SYSMAN y DBSNMP. En la documentación hallaréis descripciones de cada uno de estos usuarios.

No debemos perder de vista los usuarios con privilegios elevados (DBA y otros) que se hayan podido crear tras la instalación. Basta con descuidar un sólo perfil privilegiado para que un atacante tome control total de la instalación. Es tan importante que SYS disponga de una clave de alta calidad como cualquier otro usuario creado con perfil suficiente para acceder a los datos críticos. No olvidemos que en Oracle la seguridad debe siempre enfocarse a la seguridad de los datos, así pues, si el usuario SHERNANDO tiene privilegios mínimos globales pero es dueño de la tabla más importante del sistema, su compromiso es equivalente al de comprometer la cuenta SYS.

Fuerza bruta sobre las claves

En nuestro ejemplo vamos a crear algunos usuarios adicionales con distintas claves:

Oracle passwords

A continuación, sacaremos a fichero todas las relaciones usuario-hash, empleando el comando spool.

Oracle passwords

Recogemos el fichero, en este caso de C:\XEClient\bin y lo ponemos a buen recaudo. He dejado una copia del fichero en http://www.sahw.com/images/oracle_audit/usuarios.txt por si queréis utilizarlo.

Hay infinidad de programas para someter a los hashes obtenidos a fuerza bruta. Uno de los más populares es orabf, que incluye una lista de claves habituales y diversas opciones para construir los ataques de fuerza bruta. Veamos un ejemplo de cómo se utiliza:

Oracle passwords

En el ejemplo anterior vemos cómo el usuario SYS tiene una clave por defecto llamada password, que ni siquiera ha sido preciso romper mediante fuerza bruta puesto que estaba en el diccionario. Otro ejemplo:

Oracle passwords

En este caso ha bastado un minuto para averiguar la clave. Veamos qué pasa si cambiamos la clave de pass2 a clave2 (ampliamos de 5 a 6 caracteres)

Oracle passwords

Sometemos el nuevo hash a fuerza bruta:

Oracle passwords

Como era previsible, el tiempo de ataque se ha elevado a varios minutos. A mayor calidad de la clave, más tiempo. Por lo general el tiempo de cómputo elevado no hace rentable los intentos de fuerza bruta en claves complejas de 7 o más caracteres.

Existen infinidad de herramientas para fuerza bruta: herramientas W32 como la mostrada, UNIX, procedimientos PL/SQL, scripts Perl … Tenéis una buena selección de las mismas en http://www.petefinnigan.com/tools.htm, y cada día aparecen más. Cuestión de probarlas, y elegir la que más os guste.

Fuerza bruta con múltiples cuentas

Entre las muchas herramientas existentes siempre recomiendo Inguma, de Joxean Koret, un framework de seguridad bastante completo que además tiene funcionalidades específicas para Oracle. Además de su versatilidad, Inguma está escrita en Python, con lo que es multiplataforma, y para el caso que nos ocupa tiene un módulo de fuerza bruta para contraseñas Oracle llamado bruteora que podemos lanzar contra las cuentas usuales en la base de datos:

Oracle passwords

Al ser código abierto, es fácil incorporar las cuentas declaradas en la base de datos para complementar las cuentas frecuentes empleadas por Inguma, con lo que finalmente es posible obtener también una valoración de la calidad de todas las contraseñas que existan en el sistema. Este método, a diferencia de otros, es online, con lo que el auditor debe tener presente el impacto sobre el sistema a auditar.

Un saludo,