Sidejacking con ferret y hamster. Ataque y defensa

Seifreed · 21-Jun-2009, 18:18

Sidejacking es la tecnica que permite esnifar cookies y reemplazarlas contra sitios web suplantando la identidad de la victima. Se diferencia de un hijacking Man in the middle en que un ataque MitM interfiere con la sesion original, y el sidejacking no, pues la victima continua usando su sesion sin darse cuenta de que nosotros tambien estamos en su sesion.

En la conferencia "Black Hat Hacker", llevada a cabo en Las Vegas, USA, en Agosto de 2007, Robert Graham, de la firma Errata Security, demostro con sus herramientas ferret y hamster lo sencillo que es el robo de datos de cuentas de mail.

<EDIT 26-Sep-08>
Sobre esto, Sor_Zitroen me comento que existe la herramienta libre (GPL) SurfJack para realizar lo que en el documento que me paso llaman Surf Jacking. Ellos dicen en la portada: "HTTPS will not save you". Con eso esta todo dicho. Y esta documentacion esta en http://resources.enablesecurity.com/...%20Jacking.pdf

Y para terminar sobre esto, en palabras de Sor_Zitroen: "SurfJack sólo sería válido si la cookie que se utiliza se puede enviar tanto por HTTP como por HTTPS. Vamos, que si se establece en la cookie el flag de seguridad para enviar sólo por canales cifrados ya no sería posible realizarlo.
</EDIT 26-Sep-2008>

Podemos bajar las herramientas programadas por el de http://www.erratasec.com/sidejacking.zip.

Expliquemos en que consisten estas herramientas y como podemos usarlas para realizar un ataque.

Ferret es un sniffer de linea de comandos que esnifa cookies. Hamster actua de proxy basandose en los resultados capturados por Ferret. Veamos brevemente los pasos a seguir en el ataque.

Descomprimimos las utilidades en un directorio, por ejemplo c:\risperdal.

Vemos que interfaz de red queremos que Ferret esnife:

Código: ferret -W

Supongamos que nuestra interfaz wireless es la 2, y que queremos esnifar por ella. Hariamos:

Código: start ferret.exe –i 2 sniffer.mode=most sniffer.directory=\pcaps

con esto ya tenemos a Ferret capturando cookies que pasen por nuestra interfaz wifi, y almacenandolas en c:\risperdal\hamster.txt

Ejecutamos hamster:

Código: start hamster

Ya tenemos un proxy local escuchando en el puerto 3128. Abrimos un navegador (yo lo hago con IE, pues habitualmente uso Opera y hamster jode las cookies que tengamos), lo configuramos para que salga por el proxy 127.0.0.1:3128 y escribimos

Código: Dedicated Server Hosting | VPS | Domains | Webhosting | Private Racks by LeaseWeb

Nos saldran varias posibles sesiones de victimas. Elegimos alguna y con alta probabilidad... estamos dentro.

Si la victima no cierra sesion y la cookie es persistente, como es el caso de gmail por ejemplo, podemos reutilizar el archivo hamster.txt siempre que queramos.

El ataque fue demostrado para redes wireless abiertas, en redes wireless protegidas por cifrado (WPA/WPA2) el ataque es imposible a menos que sepamos la clave de cifrado. Y en la demostracion del ataque se uso una conexion wifi abierta, pero nada impide realizar el ataque en una red cableada. Podemos poner a Ferret esnifando en una interfaz de red cableada. Toda cookie que pase por esa interfaz sera guardada en hamster.txt. En un entorno con hub es trivial. En un entorno switcheado tambien es trivial ya en nuestros dias, basta con un simple ataque de ARP-Spoofing.

Contramedidas:

He leido por ahi, y en mas de una pagina web, de hecho en todas las que he encontrado que hablen del tema, que una contramedida eficaz es usar https en lugar de http. Pues bien, eso es falso. Todas estan equivocadas. Tal y como apunto Mike Perry el 6 de Agosto en la prestigiosa lista de correo bugtraq, la cookie de autenticacion GX de mail.google.com se transmite tanto por http como por https. Esta es la unica cookie necesaria para autenticarse en gmail.

Para demostrar la validez del ataque aun usando https, puedes visitar en tu ordenador victima de pruebas https://mail.google.com. Ahora borra todas las cookies menos la cookie GX. En Firefox lo puedes hacer con la extension CookieCuller. Despues cierra la pestaña de gmail y visita http://mail.google.com. Sorpresa: aun estaras autenticado.

<EDIT 26-Sep-2008>
Aclaracion: Notese que digo Para demostrar la validez del ataque aun usando https. Lo importante es la cookie de autenticacion aunque la conexion vaya cifrada con https.
</EDIT 26-Sep-2008>

La unica contramedida posible es borrar todas las cookies y/o (mejor y) hacer logout. Y si usamos wifi, cifrar siempre la conexion.
Fuente

Tronador · 21-Jun-2009, 19:01

Precisamente hoy estuve leyendo sobre el tema y estaba ppor probar el SurfJack.

El link de descarga del surfjack: http://surfjack.googlecode.com/files/surfjack-0.2b.zip

Es requisito tener instalado Scapy y por supuesto Python.

Angelus_7722 · 21-Jun-2009, 20:00

mmm...... este método queríamos con badcode mostrarlo en el CP, lo probé entre máquinas virtuales y funciona excelentemente, es muy sencillo

Gracias Seifreed.

saludos

Tronador · 21-Jun-2009, 21:59

Una pregunta, alguien ha usado el surfjack?