03 - Criptografía "fuerte" de los productos Microsoft - 25/10/2002


Autor: Lic. Cristian F. Borghello

http://www.segu-info.com.ar

Situación

Hace poco, el creador de unos cuantos Stores Procedure de SQL Server 2000 se fue de la organización, dejando los mismos encriptados y por lo tanto, dejando a la empresa sin los códigos fuentes.

SQL y su encriptación

SQL Server es el servidor de Base de Datos de Microsoft.

En el mismo pueden crearse, además de BD, Tablas y Vistas, Procedimientos Almacenados (SP), los cuales el administrador programa para realizar tareas que se ejecutaran en el servidor. Este procedimiento es el aconsejado cuando se programan sitios webs con acceso de BD, ya que permite ocultar las consultas realizadas.

Por ejemplo:

consulta.asp pide los datos al usuario (en un site cualquiera), luego ejecuta un SP llamado SP_Consu(almacenado en el servidor en la BD de SQL). Aquí, el encargado de devolver los datos que solicitó el usuario es el SP, el cual podrá hacer verificaciones, consultas extras a otras tablas, etc., siendo transparente para el usuario además de que no permitirá saber el contenido del SP a aquellas personas que vean el codigo ASP en caso de intrusiones.

Ahora, para el administrador de la BD los SP serán perfectamente visibles a menos que su programador haya incluido el comando WITH ENCRYPTION al momento de su creación. Aquí Microsoft almacenará los SP encriptados en un solo sentido. Al decir "en un solo sentido" se asegura que NADIE PODRÁ DESECRIPTARLOS, NI SIQUIERA QUIEN LOS HIZO. Esta encriptación existe por el simple motivo de que el administrador no desea que usuarios de la BD "demasiados curiosos" puedan copiarlos y/o modificarlos.

En resumidas palabras, al encriptar un SP debemos asegurarnos que tenemos los fuentes con nosotros, ya que si los fuentes se pierden, Microsoft nos asegura que deberemos hacer los SP nuevamente.

Según la situación planteada el administrador de la BD se fue sin dejar el código fuente en la organización, solo los SP encriptados.

Mi situación personal era demostrar que Microsoft mentía o hacer lo SP nuevamente.

Tarea: desencriptar los Store Procedures

Analizando tan solo un poco se puede llegar a la conclusión de que si los SP se ejecutaban, era porque SQL podía leer los comandos contenidos en él, por ende podía leer el SP, por ende SQL podía desencriptar los SP, por ende alguien más podía hacerlo.

La búsqueda en Internet y algunos foros me dejó algo desanimado pero después de un día de mirar los SP encriptados había llegado a la conclusión de que se almacenaban en formato UNICODE y que para su encriptación se utiliza un "complicado" XOR.

Como sabemos el XOR (uno o el otro pero nunca los dos) es la única función la cual su inversa es sí misma. Asi:

  Caracter Valor ASCII Valor Binario
Caracter a encriptar A 65 01000001
Caracter Clave 1 49 00110001
Resultado XOR P 112 01110000
Caracter Clave 1 49 00110001
Resultado XOR A 65 01000001

Como vemos, la clave "1" sirve para transformar (encriptar) "A" en "p"; y luego para descifrarla nuevamente en "A".

Como resultado de esta investigación se tienen 2 alternativas: averiguar la clave utilizada por Microsoft, igual a la longitud del SP y basada en el GUID de la base de datos; u obtener cada carácter por fuerza bruta (ver "Porque caen nuestras passwords"). Básicamente el procedimiento adoptado es: dado un carácter, encriptarlo con la primera clave y comparar con el carácter encriptado almacenado. Si son iguales el carácter corresponde y se pasa al siguiente, si no coinciden se cambia la clave y/o el carácter hasta que coincidan.

Procedimiento:

Se debe probar todos los caracteres ASCII: "ABCD...YZabcd...yz012..89". Suponemos que el primer carácter encriptado es "U"; los pasos a seguir son:

  1. encriptar "A" -> "p"
  2. comparar "p" con primer carácter encriptado "U"
  3. Son distintos -> encriptar "B" -> "s"
  4. comparar "s" con primer carácter encriptado "U"
  5. ....
  6. Son distintos -> encriptar "d" -> "U"
  7. comparar "U" con primer carácter encriptado "U"
  8. Son iguales, por lo tanto el primer carácter del SP = "d"; se pasa al siguiente y se comienza con el paso 1 nuevamente hasta que no haya mas caracteres a desencriptar.

El resultado de esta operación fue que en un par de días teníamos la alegría de tener todos los SP desencriptados y la tristeza y certeza de que Microsoft nos había mentido nuevamente.

En la imagen puede apreciarse el SP encriptado en la parte superior (en formato UNICODE) y luego, en la ventana inferior, desencriptado.

Ejemplo Store Procedure Desencriptado

Conclusión:

En caso como los discutidos, no se trata de un fallo insignificante ni mucho menos. Es más, ni siquiera se trata de un fallo en algún algoritmo o método. Es simple: Microsoft sabía cuando hacia SQL Server que la encriptación "indescifrable" a la que iba a hacer objeto sus SP era básica, simple, muy simple por no decir inexistente.

¿Fue un descuido, pensó que nadie lo utilizaría, pensó en serio que era indescifrable, o simplemente no le importó?... No tengo respuesta a estas preguntas, pero por supuesto, esta no es la primera vez que sucede y resulta indignante pensar que miles de administradores confían su seguridad a empresas las cuales no tienen la mínima consideración por la información sensible almacenada.

Me pregunto que si como a ellos no le interesa la privacidad y la seguridad de sus usuarios, todos los administradores debemos pensar igual y dejar que nuestras aplicaciones vuelquen en pantallas azules, regalen información a diestra y siniestra y de última se sigan riendo de nuestra confianza a costa de algunos millones de dólares.

Este artículo nunca intentó ser una guía práctica, simplemente pretende demostrar que las grandes corporaciones (en este caso Microsoft) dejaron hace mucho de interesarse en nosotros.

Complicadas alianzas corporativas no hacen mas que ennegrecer el panorama, intentando por ejemplo, que dejen de darse a conocer los fallos de seguridad, negando u ocultando los mismos, logrando con ello solo alargar lo previsible: que alguien mal intencionado los encuentre causando daños cuantiosamente mayores.

Con profundo dolor siento que piensen así, porque nuestra privacidad reconocida por las Naciones Unidas en 1948 está en juego.

Mas información

Buenos Aires, 25 de octubre de 2002

Con más de 24 años de experiencia compartiendo la mejor información de Seguridad

Contacto