Twitter y sus cookies

Como explican los chicos de Securitybydefault en http://www.securitybydefault.com/2010/09/twitter-y-las-galletas-caducadas.html , twitter no está destruyendo realmente las cookies (ni siquiera aunque uno cierre sesión como dios manda xD) o al menos no en un tiempo razonable.
Esto qué quiere decir? quiere decir que se pueden reutilizar las cookies para continuar una sesión que fue abierta con las de la ley (con usuario y password correctos). De esta forma, quien se haga con nuestras cookies es capaz de utilizar nuestra cuenta.

Inconvenientes:
-Una vez obtenida la cookie el usuario malvado podría eliminar todos nuestros followers, agregar nuevos, insultar a mamá y papá, decirle a la novia que no la querés ver mas xD (podría no ser tan malvado), etc etc etc.

Algo bueno?:
-emm... digamos que si. Este usuario poseído, no podrá hacer cambios irreversibles como cambiar la contraseña o el mail asignado a nuestra cuenta, porque para ello debería conocer nuestra contraseña y estamos suponiendo que tenemos una contraseña segura y que no tiene relación alguna con el nombre de la cuenta ni el mail, ni nada tan predecible.

Realmente funciona? SISI, hace mas de 2hs cree una cuenta en twitter (luego de haber probado con mi cuenta privada) y aún se puede entrar utilizando las cookies.

Las cookies son las 12 siguientes:

.twitter.com    TRUE    /    FALSE    1285196450    __utmb    43838368.10.10.1285194542
.twitter.com    TRUE    /    FALSE    1348266650    __utmv    43838368.lang%3A%20es
.twitter.com    TRUE    /    FALSE    0    __utmc    43838368
.twitter.com    TRUE    /    FALSE    1348266650    __utma    43838368.1707552852.1285194542.1285194542.1285194542.1
.twitter.com    TRUE    /    FALSE    0    _twitter_sess    BAh7DzoVaW5fbmV3X3VzZXJfZmxvdzAiLXNob3dfZGlzY292ZXJhYmlsaXR5%250AX2Zvcl9zb3l1bmFwcnVlYmFtYXMwOhNwYXNzd29yZF90b2tlbiItMmRhMjM3%250AZTA5NTdjYmE0NjJhNDQ1YjE4Nzg1NDE0NTgzYmQ4NDBlMjoMdHpfbmFtZSIN%250AQnJhc2lsaWE6CXVzZXJpBMNcjgs6E3Nob3dfaGVscF9saW5rMDoHaWQiJTUy%250AYjY0YTg2ODZmZjM2ZWU1NTIyYWIwZjhiNzNlYjY5IgpmbGFzaElDOidBY3Rp%250Ab25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOgxj%250Ac3JmX2lkIiVjNzA1MjRiNjZlODFkOGE2ZWQ3MTI2NGRmOTVhN2QyNDoPY3Jl%250AYXRlZF9hdGwrCGomkDsrAQ%253D%253D--91b23fa140937e74c8499f08229b4484cc3d73c3
.twitter.com    TRUE    /    FALSE    0    auth_token    2da237e0957cba462a445b18785414583bd840e2
.twitter.com    TRUE    /    FALSE    1300962542    __utmz    43838368.1285194542.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
.twitter.com    TRUE    /    FALSE    1285799324    k    190.230.174.206.1285194524262928
twitter.com    FALSE    /    FALSE    0    lang    es
twitter.com    FALSE    /    FALSE    0    tz_offset_sec    -10800
twitter.com    FALSE    /    FALSE    0    original_referer    4bfz%2B%2BmebEkRkMWFCXm%2FCUOsvDoVeFTl
twitter.com    FALSE    /    FALSE    1287786524    guest_id    128519452426515090

Para realizar la prueba es necesario copias las cookies anteriores a un archivo e importarlas a nuestro browser preferido (entiendase FIREFOX) mediante algún plugin como ser "Add N Edit Cookies", una vez importadas vamos a www.twitter.com y magia!! :P somos "soyunapruebamas".

Podemos ver las cookies importadas:

Las cookies _twitter_sess, __utmc, auth_token, lang, original_referer y tz_offset_sec expiran (teóricamente) al finalizar la sesión, pero claramente NO lo están haciendo.
__utmb expira: 09/22/2010 21:24:32.
__utmv expira: 09/21/2012 20:54:32
__utma expira: 09/21/2012 20:54:32
k expira: 09/29/2010 19:28:44
__utmz expira: 03/24/2011 07:29:02
guest_id expira: 10/22/2010 19:28:44


A las 21:15 del 22 de septiembre de 2010, habiendo expirado casi todas las cookies, aún es posible utilizarlas...


La misma prueba hecha en facebook nos demuestra el funcionamiento esperado de las cookies:
-Si no cerramos sesión, las cookies se pueden reutilizar.
-Si cerramos sesión, las cookies se invalidan y es necesario volver a autenticarse.


Esto a simple vista podría no parecer peligroso, pero sumado a la aparición de un bug XSS en twitter, es posible que nuestras cookies sean robadas y ya no podríamos invalidarlas cerrando la sesión.


Aca un poco mas sobre una de las cookies auth_token: http://domdingelom.blogspot.com/2008/12/all-your-twitter-are-belong-to-us.html .
Aca un poco mas sobre el bug XSS: http://www.rtve.es/noticias/20100921/twitter-sufre-mayor-ataque-su-historia-culpa-fallo-seguridad/355656.shtml .

Importen las cookies, prueben y no hagan destrozos a "soyunapruebamas", gracias xD.

Archivo cookiest.txt http://www.megaupload.com/?d=1JX7UNZJ .
Hash MD5: 973b5eff003532bb2f4508cfcd9c9f93  cookies.txt

Segundo desafío :P

Así es, esta entrada es para el segundo desafío (continuación del anterior, al menos en la historia xD). La facultad y la pasantía ciertamente me están desgastando el cuerpo, hoy me dormí un par de veces en la clase de inteligencia artificial, pero debo admitir que el profesor no ayudaba xD. Pero esto no es un diario xD, así que a lo que nos truje.
El segundo desafío es: http://forensicscontest.com/2009/10/10/puzzle-2-ann-skips-bail . Esta vez nos encontramos con un desafío un tanto mas interesante y un archivo de capturas un poco mas grande también.
Una vez comprendida bien las preguntas me dispuse a abrir el archivo de captura para buscar las respuesta, claramente usando wireshark :P.

RESPONDIENDO LAS PREGUNTAS:

1-Viendo un poco la captura encontramos en el paquete número 53 el inicio de una conexión tcp al puerto 587, que no es el puerto estandard de los servidores de correo (25), pero si seguimos la conexión queda en evidencia de que se trata de una conexión a un servidor de correo.

En la imagen se ve prácticamente toda la conexión con el servidor de correo y como se trata de stmp básico vemos todo en texto claro nada de cifrado.
Desde esta imagen podemos responder varias preguntas, vemos que el mail de la señorita "Ann Dercover" es "sneakyg33@aol.com".

2-Los dos puntos negros en la imagen anterior marcan la autenticación llevada a cabo, parece texto sin sentido, esto se debe a que el nombre del usuario (primero punto) y el password (segundo punto) están codificados en Base64 (para mas información http://es.wikipedia.org/wiki/Base64). Ahora pasemos a decodificar (nótese la diferencia entre codificar y cifrar, son cosas totálmente diferentes, base64 es un tipo de codificación no de cifrado).
Para decodificar los campos los extraemos manualmente y los decodificamos con el programa base64 de la siguiente manera:
Primero metemos las cuatro cadenas codificadas dentro de un archivo de texto para automatizar un poco todo (no se justifica para tan pocos datos codificados, pero buee), y luego procesamos una a una cada linea del archivo de la siguiente manera:

Y magia xD, el usuario de Ann Dercover es el que indicamos anteriormente y su password es "558r00lz".

3-En primer momento creí que la respuesta a esta pregunta también se podría sacar de la primer imagen, y me arriesgué a creer que el mail del señor X es "sec558@gmail.com". Pero no!, viendo la pregunta 4 me encontré con un segundo mail enviado por Ann, comenzando en el paquete 153. Esta vez el mail va dirigido a una dirección un tanto sospechosa xD "mistersecretx@aol.com", la cual sin lugar a dudas es la dirección del señor X.

4-En este segundo mail Ann escribe al señor X:

Ann pide al señor X que traiga su pasaporte falso y traje de baño :P.

5-Parte del texto del mail de Ann nos indica que la dirección de encuentro está adjunta al correo electrónico. Vemos que de hecho hay un archivo adjunto, con el nombre "secretrendezvous.docx", codificado en "base64".

6- Bien, esta parte es mas divertida, ahora hay que extraer el archivo codificado en base64, decodificarlo y calcular su hash md5.
Copiamos toda la parte codificada en base64 en un archivo, lo copié directamente desde wireshark seleccionando toda la parte codificada. Una vez listo el archivo lo decodificamos de la siguiente forma:

La opción "i" indica a base64 que ignore los caracteres no válidos que encuentre, sin la opción activada nos informará que se encontraron caracteres inválidos, por la forma en que los paquetes llegaron y como los muestra wireshark. Una vez que tenemos el archivo nos fijamos su estructura y file nos informa correctamente el tipo de archivo según su magic number. Con md5sum calculamos el checksum del archivo en cuestión "9e423e11db88f01bbff81172839e1923  secretrendezvous.docx".

7-Ahora, una vez mas, por no tener Microsoft Office y porque mi OpenOffice no es demasiado amigable con los .docx abro el archivo desde google:

El punto de encuentro se indica en la imagen, Avenida Constituyentes 1 Calle 10 x la 5ta Avenida, Playa del carmen México.

8-Descargamos la imagen (botón derecho guardar imagen, god bless google!) y vemos que se trata de un png, luego calculamos su checksum.

Y ahí quedan todas las preguntas respondidas :D.

Bueno, ahora voy a cumplir con mi cuerpo y me voy a dormir xD.