Como verán hace un par o dos pares de meses que no ando por aquí. Básicamente es por mi PÉSIMA administración del tiempo, no soy lo que se dice la persona mas ocupada del mundo, pero siempre me las arreglo para que el tiempo no me sea suficiente xD.
Llevo alrededor de 6 meses ya en mi pasantía en el centro de redes de la Universidad Nacional de Córdoba, y debo decir que es increíble todo lo que se aprende en el campo de batalla. Definitivamente era lo que me hacía falta, práctica.
Pero como esto NO es un diario, o por lo menos ahora no lo es, les traigo la primera parte de mi interpretación del reto http://noconname.org/concursos/NcN_2010_Reto_Forense.pdf , aquí la imagen del dispositivo a analizar http://noconname.org/concursos/okin.dd.bz2 .
En primera instancia cabe aclarar que este no es un reto como los demás, aquí no hay mas consigna que: Todo lo que encuentres y puedas justificar vale.
""Obras a la Mano":
Una vez descargado el archivo lo descomprimimos y utilizamos el famoso file para ver de qué se trata okin.dd.
root@moon:/home/juan/ForensicTests/NcNForense# file okin.dd
okin.dd: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=42006dd3-3ea3-42dd-aa42-e86c3376ea31
root@moon:/home/juan/ForensicTests/NcNForense#
Como nos comenta el pdf se trata del dd (copia cruda, hablando mal y pronto) de una partición de tipo ext2.
Para asegurarnos de que tenemos el archivo correcto procesamos okin.dd con md5sum y lo comparamos con el valor que dice el pdf:
root@moon:/home/juan/ForensicTests/NcNForense# md5sum -b okin.dd
9c9a5e0d25dd57db10c99e84d9b03d48 *okin.dd
root@moon:/home/juan/ForensicTests/NcNForense#
Si no coincidiera estamos en problemas, habría que volver a descargar el archivo o probar descomprimiendo nuevamente okin.dd.bz2.
Entonces tenemos una partición en un archivo, en principio no podemos ver su contenido (archivos y directorios) porque se trata simplemente de un archivo mas en nuestro disco.
Pero al tener la certeza de que se trata de una partición, solo necesitamos decirle al sistema operativo que la trate como un dispositivo de bloques como cualquier otro. Para lograr esto usamos losetup, que nos permite asociar a un dispositivo de loop un archivo o un dispositivo de bloque, que en nuestro caso significa: nos permite emular un dispositivo de bloque a partir de nuestro archivo okin.dd.
juan@moon:~/ForensicTests/NcNForense$ losetup --all
Antes de crear un dispositivo hay que ver cuál de los loop devices no está en uso, e mi caso losetup --all no devuelve nada y por lo tanto puedo utilizar cualquiera de los loop.
juan@moon:~/ForensicTests/NcNForense$ ls /dev/loo*
loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7
Entonces utilzio loop1, y como se trata de evidencia forense, le indicamos a losetup que configure el loop device como SOLO lectura.
root@moon:/home/juan/ForensicTests/NcNForense# losetup -r /dev/loop1 okin.dd
Listamos nuevamente los dispositivos loop en uso y vemos ahora que loop1 está en uso con nuestro archivo.
root@moon:/home/juan/ForensicTests/NcNForense# losetup -a
/dev/loop1: [0801]:692806 (/home/juan/ForensicTests/NcNForense/okin.dd)
Podemos ver nuestro dispositivo con fdisk:
root@moon:/home/juan/ForensicTests/NcNForense# fdisk -l /dev/loop1
Disco /dev/loop1: 123 MB, 123379200 bytes
255 cabezas, 63 sectores/pista, 15 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x00000000
El disco /dev/loop1 no contiene una tabla de particiones válida
No tiene particiones válidas porque no se trata de un disco particionado, sino simplemente de una partición.
Ahora creamos un directorio donde montaremos nuestra partición para por fin poder ver qué contiene.
root@moon:/home/juan/ForensicTests/NcNForense# mkdir analisis
root@moon:/home/juan/ForensicTests/NcNForense# mount -o ro /dev/loop1 analisis/
Lo montamos como cualquier otro dispositivo de bloques, expecificando la opción de solo lectura, no es necesario especificar el tipo de partición ya que lo detecta automáticamente (aunque no estaría mal hacerlo).
Podemos ver que se montó correctamente mediante:
root@moon:/home/juan/ForensicTests/NcNForense# mount | grep loop1
/dev/loop1 on /home/juan/ForensicTests/NcNForense/analisis type ext2 (ro)
root@moon:/home/juan/ForensicTests/NcNForense#
Eso es todo por ahora, de aca en mas ya se puede recorrer la partición como lo hacemos normalmente. Para la próxima veremos el contenido, los archivos, sus fechas, etc, y ver cuánta información se puede obtener.
viernes, 28 de enero de 2011
miércoles, 22 de septiembre de 2010
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
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
jueves, 2 de septiembre de 2010
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.
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.
Suscribirse a:
Entradas (Atom)