| ESTUDIO COLECTIVO DE DESPROTECCIONES Última Actualizacion: 25/10/2001 |
Programa | Access 97. Fase 1 | W95 / W98 / NT
Descripción | Motor de Base de datos
Tipo | Aplicación comercial
Tipo de Tutorial | [X]Original, []Adaptación, []Aplicación, []Traducción
Url | http://www.microsoft.com
Protección | Contraseña de acceso a bases de datos
Dificultad | 1) Principiante, 2) Amateur, 3) Aficionado, 4) Profesional, 5) Especialista
Herramientas | UltraEdit v6.10a
Objetivo | Eliminar la contraseña de acceso a una base de datos.
Cracker | Mr.Blue
Grupo | Whiskey Kon Tekila
Fecha | 14 de Octubre de 1999
INTRODUCCION
Vamos a demostrar la "seguridad" de los datos en Access 97. Todo lo que se va explicar ha sido probado sobre Access 97, aunque sospecho que es válido para cualquier base de datos en formato Access (al menos desde el Access 95). He dividido nuestro proyecto en varias fases, cada una más difícil que la anterior, pero todas muy fáciles. Ya veréis. Parchear una base de datos para eliminar la contraseña de acceso. Parchear el Access 97 para poder abrir bases de datos protegidas con contraseña de acceso (sin saberla, claro). Diseño de un gestor de contraseñas para bases de datos de Access que permita descubrir la contraseña de una base de datos, modificarla o borrarla.
ORIENTÁNDONOS
Para no empezar dando palos de ciego, debemos encontrar dónde almacena Access las contraseñas de acceso a una base de datos. Lógicamente, si queremos que dicha base de datos pueda abrirse desde cualquier ordenador con Access, deberá almacenarse en el mismo fichero de la base de datos ya que de lo contrario, ésta no podría abrirse en otro ordenador aunque supiéramos la contraseña así que nos olvidamos del registro de Win95, archivos ocultos y demás paranoias. ¿Qué formas de guardar una clave de acceso, en el mismo fichero al que se supone que protege, se nos ocurren?. Pueden ocurrírsenos muchas, cito varias en orden ascendente de seguridad: Guardarla (encriptada o no) en una posición fija del fichero. Guardarla (encriptada o no) en una posición variable, apuntada por un puntero que indica la posición en el fichero de la contraseña. No guardarla directamente en el fichero, si no encriptar el fichero completo mediante dicha clave, de forma que solo pueda desencriptarse con la contraseña utilizada en la encriptación. ¿Cuál usa Access? Para adivinarlo vamos a hacer una pequeña prueba: Creamos una pequeña base de datos, lo más simple posible, por ejemplo con una sola tabla y con un solo campo, no hace falta introducir datos. Si no tenemos ni idea, podemos utilizar una base datos ya existente. Supongamos que llamamos a esta base de datos (sin contraseña de acceso) 'bd1.mdb'. Realizamos dos copias de la base de datos anterior con nombres nuevos, por ejemplo 'bd2.mdb' y 'bd3.mdb'. A las dos copias generadas ('bd2.mdb' y 'bd3.mdb'), le ponemos contraseña de acceso. Para ello abrimos el Access 97, seleccionamos 'Abrir base de datos...' en el menú 'Archivo'. Puesto que vamos a realizar un cambio en la "seguridad" de las bases de datos, debemos abrirlas en modo exclusivo (checkbox situado a la derecha de la ventana). Establecemos las contraseñas de acceso a las bases de datos (menú 'Herramientas', opción 'Seguridad -> Establecer contraseña para...'). A 'bd2.mdb' le ponemos, p.e. "WKT!" y a la otra "Mr.Blue" (respetad las mayúsculas y minúsculas porque tienen importancia). ¿Hecho? A continuación procedemos a realizar una comparación binaria de los ficheros "protegidos" con el "virgen". Esto permitirá distinguir cual de los tres sistemas de almacenamiento de la contraseña que he citado anteriormente, ha elegido Microsoft para la protección de los datos. Así, si el número de diferencias entre los ficheros es muy grande (comparable al tamaño del fichero) podemos suponer que se ha utilizado la tercera opción. Si el número de diferencias es pequeño y la posición de éstas es variable, se ha usado el segundo. Y si finalmente, las diferencias son pocas y comienzan siempre en el mismo offset del fichero, se ha usado el primero. Podeis usar vuestro comparador binario favorito, yo usaré el comando del MS-DOS 'FC' ('File Compare') que seguro que tiene todo el mundo. El formato es 'FC fichero1 fichero2 /b'. El '/b' es para que realice la comparación en modo binario y no en modo texto:
`fc bd1.mdb bd2.mdb /b` | `fc bd1.mdb bd3.mdb /b`
`Comparando archivos bd1.mdb y bd2.mdb` | `Comparando archivos bd1.mdb y bd3.mdb`
`00000042: 86 D1` | `00000042: 86 CB`
`00000043: FB B0` | `00000043: FB 89`
`00000044: EC B8` | `00000044: EC C2`
`00000045: 37 16` | `00000045: 37 75`
`00000600: 12 13` | `00000046: 5D 31`
| `00000047: 44 31`
| `00000048: 9C F9`
| `00000600: 12 13`
ANALIZANDO
Vamos a ver qué enfoque le damos a esto. Sabemos que la contraseña se guarda encriptada a partir de la posición 0x42 del fichero. El Access, al abrir una base de datos, debe mirar si tiene contraseña de acceso para pedírsela al usuario. Tal y como hemos visto, las únicas diferencias entre una base de datos con contraseña y la misma sin ella son las posiciones que ocupa la contraseña encriptada (aparte de la posición 0x600, que como hemos visto, parece no afectar). El fichero no varía de longitud, aunque las contraseñas utilizadas sean más o menos largas, señal de que las contraseñas son almacenadas en un espacio reservado para ellas dentro del archivo, que no es reutilizado para otra cosa cuando no existe contraseña. Lógicamente, si restauramos en 'bd2.mdb' los valores que tiene 'bd1.mdb' en las posiciones 0x42 a 0x45, la base de datos 'bd2.mdb' queda desprotegida. Igual ocurre si hacemos lo mismo con 'bd3.mdb'. Podemos probarlo con el editor hexadecimal. Tal y como se dijo anteriormente, se puede suponer que los ficheros de Access disponen de estas catorce posiciones para almacenar la contraseña de acceso encriptada si ésta existe, y si no, guarda algo que, una vez desencriptado, debe indicarle a Access que esa base de datos no tiene contraseña de acceso. Este "algo", en 'bd1.mdb', es la cadena de catorce bytes, que comienza en la posición 0x42: 86 FB EC 37 5D 44 9C FA C6 5E 28 E6 13 B6 Este "algo" encriptado, ¿será lo mismo para todos los archivos de Access sin contraseña de acceso? Vamos a buscarnos un par de bases de datos (*.mdb) ya existentes por nuestro disco duro, y nos aseguramos que no tienen contraseña de acceso abriéndolas con el Access. Abrimos varios archivos con nuestro editor hexadecimal y comparamos a partir de la posición 0x42 el contenido con esta cadena. Todas tienen esta cadena, ¿verdad?. Pues sí, acabamos de encontrar la forma de abrir un archivo de Access con contraseña de acceso desconocida. No tenemos mas que escribir a partir de la posición 0x42 la cadena anteriormente citada. Para finalizar la primera parte de este proyecto, se incluye un ejemplo de programa en ensamblador para Windows que realiza esta tarea. Es recomendable su estudio y comprensión ya que algunas de las funciones de la API que utiliza serán de vital importancia para la segunda parte. En cuanto a la variación en la posición 0x600 de los ficheros, lo que Access 97 parece almacenar aquí no es más que un contador, en donde almacena el número de veces que se ha cambiado la contraseña de la base de datos, empezando la cuenta por 0x12. .... era una raza muy atrasada .... .... al borde del siglo XXI aún utilizaban aplicaciones Micro$oft ...
[ Entrada | Documentos Genéricos | WkT! Web Site ]
[ Todo el ECD | x Tipo de Protección | x Fecha de Publicación | x Orden Alfabético ]
(c) Whiskey Kon Tekila [WkT!] - The Original Spanish Reversers. Si necesitas contactar con nosotros, leeestoantes e infórmate de cómo puedes ayudarnos