Exposed Cryptography I

Buen día.

En el ámbito de seguridad informática existen mil y un diagramas que representan los vectores de ataque que pueden ser empleados en contra de nuestras aplicaciones, nuestros servidores, nuestra organización; pero todos ellos comparten algo en común, podemos definir más allá de los daños de integridad y denegación de servicios, que la seguridad se enfoca en los datos, y para ello es necesario sobre pasar una cantidad de seguridad igual o mayor a la denotada en la imagen. 

Como lo sabemos muy bien el único sistema totalmente seguro es aquel que se encuentra apagado (y eso que tengo mis dudas), pero el propósito de este documento es recalcar la existencia de una capa/nivel/barrera que pocos utilizan, que pocos estudian o en la cual es muy complicado conseguir personas capacitadas para verificar la seguridad de las mismas, en este caso hago referencia al último y más alto nivel de seguridad que podemos tener, la criptografía. 

¿POR QUÉ LA CRIPTOGRAFÍA?

La criptografía es una ciencia diseñada bajo la base matemática más rigurosa posible y que fundamenta su seguridad en la complejidad computacional, además de que todo lo referente a criptografía es expuesto al publico en general para ser sometido a ataques, revisiones y todo tipo de pruebas, una vez superado todo esto es posible definir si debe o no debe ser utilizado. La perspectiva es correcta, esta es la capa de protección más segura de todas pues mediante matematicas y la complejidad computacional, es posible asegurar en gran medida que un documento, contraseña, session, token, etc ... no sea generado a voluntad o no sea posible revertir el proceso y descubrir su contenido.

Veamos esto en detalle haciendo un contraste entre ambos lados de la moneda, el que ataca y el que desarrolla, habrán algunos ejemplos prácticos de buenas y malas implementaciones, admiren y diviértanse hay cosas que ni yo me las creo, esto se hace con un fin académico y esperamos puedan ayudarnos enviandonos sus Exposed Cryptography a trackmaze@gmail.com

Empecemos por algo que todos tenemos que tener muy claro, toda aplicación o sitio web NO debe almacenar las contraseñas de sus clientes en texto claro, deben ser almacenados solamente los valores hash generados por un cifrado unidireccional como es el caso de MD5, SHA1, SH2, etc... esto se debe a que esta información no puede ser conocida por otra persona ajena al cliente, ya sea el desarrollador o administrador del sistema, aquí no aplica el principio de confidencialidad, dado que muchas personas solo manejan una contraseña para todos los servicios y ante una posible vulneración del servidor sería posible que un atacante se diera con ellas y hacer estragos.

Es común ver que si olvidamos nuestra contraseña hay una opción de recuperarla, pero cuando dicen "recuperarla" en realidad lo que ocurre es que le cambian la que uno tenia por una aleatoria o le envían al correo un enlace directo para cambiarla y en realidad nunca recuerdas que contraseña tenias antes, pero veamos este caso de http://vive.tuboleta.com/default.aspx  un portal muy reconocido de compra de boletas para conciertos y demás eventos en colombia.

-- Al tener una cuenta y entrar a la opción de olvido su contraseña

-- Realmente recupero mi contraseña O.o

Esto es obviamente una muy mala implementación de criptografía, pues devuelve como tal la contraseña almacena dando así por entendido que en la Base de Datos están en texto claro todas las contraseñas de todas las personas, donde también al cambiar la contraseña no genera un reporte al correo y por tanto ante una eventual vulnerabilidad que tenga la pagina web, toda esta información se filtraría y podría ser usada en contra de los clientes... Este caso es peculiar pues es casi un hecho rotundo la momento de desarrollar que las contraseñas no deben estar en texto claro.

  ¿BASE64 un algoritmo indescifrable?

Ahora veamos otro peculiar caso de mala implementación criptografíca, en este caso tenemos a http://www.larebajavirtual.com/ una reconocida franquicia de farmacias distribuidas por todo colombia y en el cual su portal de internet nos permite realizar compras o pedidos online de medicamentos, almacenando así direcciones, compras anteriores, datos de tarjetas de credito, etc... A la hora de hacer el login y especificar que deseamos recuperar nuestra contraseña debido a que la olvidamos.

El sistema nos pide nuestro correo para enviarnos un enlace con el que podamos acceder al cambio de contraseña (hasta aquí nada fuera de lo común).

Pero al revisar el enlace de restablecer podemos notar que lleva 2 parámetros que lo diferencian de cualquier otro intento de restablecer la contraseña.

Viendo de cerca ambos parametros y de acuerdo a la experiencia que tengamos, no resultará notar fácilmente que ambos están codificados en BASE64 y por tanto podemos revertir el proceso y ver el contenido original, así que haciendo esto nos damos cuenta de que el primer parametro (al que le oculte una parte) es el número de cédula de la persona a la que se le desea cambiar la contraseña, y el segundo parametro consiste en la fecha en la que se realiza esta cambio:

????????xMzkwMQ==   corresponde a una cédula 
MjAxNTAxMjU=   corresponde a una fecha, en este caso 20150125

Ya se imaginarán lo que uno puede hacer con esto, dado que es posible cambiarle la contraseña a un usuario solo conociendo su número de cédula, además de que una vez hecho esto el sistema no genera verificación en el correo y automaticamente inicia sesión con la nueva contraseña, pudiendo un atacante cambiar de inmediato los datos, robar información de trasacciones, compras anteriores, etc..

Este caso que vemos aquí, es muy usual pues muchos desarrolladores creen o les enseñaron que un modo de proteger la información es codificandola en BASE64 pues un cliente normal no podrá saber de que se trata y además dicha información se puede descifrar en el servidor, haciendo las validaciones mucho más fáciles, además de saber que una opción tan importante como el cambio de contraseña no se debe validar solo con el número de cédula ya que estos datos se pueden recolectar en la misma pagina o por otros medios, generando así que el atacante pueda cambiar y hacerse con todos los usuarios registrados.

¿Para qué tokens aleatorios si yo puedo crear mis propias cookies?

Como este último ejemplo también encontramos muchas veces que en los tokens de validación que nosotros conocemos como cookies, se usa este mismo principio y los datos no son generados de forma aleatoria si no que son valores codificados en BASE64, valores como el mismo nombre de usuario o como el nivel de privilegios con el que inicia sesión un usuario, error que permite que un atacante descifre fácilmente dicha información y la pueda alterar para tener acceso a otras cuentas falsificando dichos valores por los de otros usuarios, en este caso quisiéramos mostrarles pantallazos pero esto supone una grave vulnerabilidad para los portales a los que los hemos hallado...

Envianos tus Exposed Cryptography

Sí tienen más información de aplicaciones o portales que hagan mal uso de funciones criptograficas para el manejo de datos sensibles, datos secuenciales, cifrado de correos, cifrados propios, etc.. pueden enviar dicha información a trackmaze@gmail.com dado que estamos haciendo una recopilación de Exposed Cryptography y más adelante en futuros post veremos más de cerca la seguridad de cada uno de estos algoritmos además de ver técnicas de cracking para contraseñas, y muchos más Exposed Cryptography que encontremos a lo largo de nuestra labor diaria.. 

Bytez