El termino session hijacking se refiere a la posibilidad de "duplicar" las credenciales de autorización en una comunicación valida ya establecida entre un server y un cliente
( también llamada session ) para obtener el acceso a la información o los servicios en
el server.
Si bien el concepto de hijacking es bastante antiguo como lo demuestran los siguientes
links ,aun este año siguen publicándose vulnerabilidades que aprovechan este concepto.
Pero vamos a concentrarnos solamente en los desarrollos web, ya que con la generacion de aplicaciones web 2.0 ( como blogger, gmail, linkedin...) se publicaron varias aplicaciones que hacen uso de este problema.
Conceptos basicos
Para entender este problema primero necesitamos entender algunos conceptos básicos.
Cookies : Una cookie es un valor enviado por un webserver , se almacena en el browser y permite mantener el estado de una session, identificar y hacer seguimiento de un usuario.
La autentificación por cookies tiene los siguientes problemas :
Cookie hijacking
Una cookie puede ser robada mediante packet sniffing dando la posibilidad de realizar
el ataque del que estamos hablando session hijacking.
El trafico de una red ( aun en redes con switch's y particularmente en hot spots publicos )
puede ser obtenido mediante diversas herramientas de sniffing ( dsniff, ethercap, whiresark). Este trafico incluye las cookies, y los ataques existen tanto para trafico encriptado como no encriptado
Otro método de apoderarse de una cookie es mediante cross-site scripting y hacerque el mismo browser envie cookies a un tercer server. Un XSS se consigue mediante la inyección de código ejecutable en un sitio para que luego se ejecute por el browser de una víctima.
Exploits
Entonces este concepto que existía desde hace tiempo, el año pasado salio a la luz con la presentación de Sidejacking en BlackHat 2007. Robert Graham presento una herramienta que
aprovecha esta vulnerabilidad : Ferret
Este programa que utiliza las librerías libcap, en realidad es un sniffer con un filtro
del contenido de los paquetes IP que obtiene las cookies y los sessions ID. Se puede
utilizar tanto en tiempo real como con archivos almacenados.
Primero debemos seleccionar la interface, para eso ejecutamos :
C:\tools\Sidejacking>ferret.exe -W
-- FERRET 1.1.3 - 2007 (c) Errata Security -- build = Aug 8 2007 22:37:48
(32-bits) -- WinPcap version 4.1 beta4 (packet.dll version 4.1.0.1237), based on libpcap version 1.0 - branch
1 \Device\NPF_GenericDialupAdapter (Adapter for generic dialup and VPN capture)
2 \Device\NPF_{2CA78815-F7C7-4197-A7E2-0B5F6F195291} (Intel(R) PRO/Wireless 3945ABG Network Connection (Microsoft's Packet Scheduler)
3 \Device\NPF_{07FD4CEA-12BD-49D1-8418-D0F886943E51} (Broadcom NetXtreme Gigabit Ethernet Driver)
Luego de seleccionar la interfaz, ejecutamos el comando nuevamente
C:\tools\Sidejacking>ferret.exe -i 2
-- FERRET 1.1.3 - 2007 (c) Errata Security -- build = Aug 8 2007 22:37:48
(32-bits) -- WinPcap version 4.1 beta4 (packet.dll version 4.1.0.1237), based on libpcap version 1.0 - branch
1 \Device\NPF_GenericDialupAdapter (Adapter for generic dialup and VPN capture)
2 \Device\NPF_{2CA78815-F7C7-4197-A7E2-0B5F6F195291} (Intel(R) PRO/Wireless 3945ABG Network Connection (Microsoft's Packet Scheduler)
3 \Device\NPF_{07FD4CEA-12BD-49D1-8418-D0F886943E51} (Broadcom NetXtreme Gigabit Ethernet Driver) SNIFFING: \Device\NPF_{2CA78815-F7C7-4197-A7E2-0B5F6F195291}
LINKTYPE: 1 Traffic seen proto="DNS", query="A", ip.src=[10.10.1.3], name="us.magder.info" ID-DNS="us.magder.info", address=[76.76.19.32] ID-DNS="magder.info", Name-Server="ns1.sitelutions.com", address=[66.117.40.216] ID-DNS="magder.info", Name-Server="ns4.sitelutions.com", address=[66.231.186.69] ID-DNS="magder.info", Name-Server="ns3.sitelutions.com", address=[69.26.178.217] ID-DNS="magder.info", Name-Server="ns5.sitelutions.com", address=[0.0.0.0] ID-DNS="magder.info", Name-Server="ns2.sitelutions.com", address=[69.26.176.28]
Ese programa generara un archivo llamado hamster.txt donde dejara la informacion de las cookies capturadas.
Para facilitar las cosas, junto con Ferret tenemos otro ejecutable llamado Hamster que actua como proxy y muestra las cookies en una pagina web, desde la cual podemos accesar
al sitio con el ID clonado.
Hamster no necesita ningun parametro para ejecutarse, simplemente el nombre del comando.
Veamos unos screenshot de las herramientas funcionando.
Un usuario accede a hotmail para ver sus emails.
Mientras Ferret esta capturando paquetes, Hamster permite mediante un browser configurado con el Proxy apuntando al localhost y al port 3128 ver los cookies capturados.
Seleccionamos el session ID que queremos capturar y como vemos en la próxima imagen, tenemos replicado el acceso al webmail, incluso se muestra la configuración del proxy.
Dado que no es dependiente de plataforma o SO , podemos ver los datos accesados en
IE desde Firefox.
Una solucion a este problema seria encryptar la comunicacion mediante SSL para evitar que nos vean las cookies.
Esto fue implementado en algunos casos, pero como dice esta presentacion sobre un nuevo vector de ataque, el diablo esta en los detalles.
Asi surge un nuevo concepto de ataque a las cookies llamado:
Surf Jacking
En Defcon16 Mike Perry demostro en su presentacion 365-Day: HTTPS Cookie Stealing
que el robo de identidad aun es posible utilizando https.
Creo una herramienta que se llama CookieMonster
la cual no publico dado que esta vulnerabilidad no solamente afectaba a Webmails, tambien bancos y otros sitios comerciales tenian esta vulnerabilidad.
HTTP Redirect
Cuando un cliente HTTP o un browser reciben como respuesta "“301 Moved Permanently” desde el webserver, automaticamente seran redirigidos a otro sitio que es espicificado en el header HTTP "Location" de la respuesta. Lo mismo ocurre con los codigos de respuesta
302,303 y 307. Ademas de estos metodos, webowsers pueden ser redirigidos mediante Javascripts y posiblemente utilizando otros metodos.
En el ejemplo siguiente, el cliente envia una peticion HTTP a una pagina example.com y es redirigido a otra pagina enablesecurity.com, que muestra un mensaje "hello" al browser. El usuario no tiene porque conocer que fue redirigido a otro sitio dado que esto es realizado por el browser en forma automatica.
Cookies tienen un flag llamado "secure", que cuando habilitado es habilitado solamente transmitira la cookie a sitios encryptados. Sin embargo muchos sitios no hacen uso de este
flag y permiten que la cookie sea transmitida aun en modo claro.
Por lo tanto si un atacante se situa entre la victima y el server, puede injectar datos para
forzar a transmitir esta cookie en modo claro.
Como funciona ?
Tenemos dos posibles formas de realizar esto.
Pasemos a explicar como funciona, utilizando palabras de Sandro Gauci quien si publico su herramienta.
-- La victima se loguea en un sitio seguro https://somesecurebank.com/
-- El sitio seguro envia una session cookie luego de logueado el cliente.
-- Estando logueado , la victima abre una ventan del browser y se dirige a http://www.example.org/
--El atacante envia de respuesta "301 Moved Permanently" en respuesta al pedido de acceder a http://www.example.org/. Ademas la respuesta contiene en el header “Location: http://somesecurebank.com/” que hace creer que http://www.example.org/ esta volviendo su browser al sitio de somesecurebank.com pero e que aqui el
protocolo cambio por http.
--El browser de la victima comienza una nueva session en claro hacia somesecurebank.com y expone la cookie de session.
--El atacante graba la cookie y la almacena para acceder suplantando la
identidad de la victima.
Si luego el atacante envia un nuevo paquete con el mensaje "301 Moved Permanently" y lo redirecciona hacia http://www.example.org/ el ataque sera totalmente transparente para el usuario ya que todo ocurre sin que el lo note.
Ahora el ataque propuesto por Perry
– Ayer: Usuario se loguea en to httpS://mail.google.com
– Hoy: Usuario visitas www.cnn.com en un hot spot abierto
– Hoy: Injectamos
– Hoy: El browser transmite la cookie GX de gmail oara bajar la imagen.
– Hoy: Hacemos sniff de las cookies, las escribimos a cookies.txt
– Mañana: Usamos cookies.txt para leer su mail
Este tipo de ataques es posible en los siguientes escenarios.
• Redes wireless inseguras ( hot spots abiertos )
• Switched networks permitiendo ARP poisoning
• routers comprometidos
• Tunnel networks como TOR
• DNS poisoned domain names
La herramienta que libero Sandro surfjack.py es un script python que utiliza scapy como backend.
Otra herramienta que utiliza un concepto similar es airpwn presentado en el 2004
Recomendaciones
Para desarrolladores.
Las cookies tienen un flag llamado "secure", que hace que solo sea enviada mediante conexiones SSL. Cuando el browser es redireccionado a un server Http, la cookie no es incluida.
Para el usuario final
Nunca conectarse desde hotspot libres.
Utilizar VPN para conexiones remotas.
Cerrar session una vez terminado el trabajo ( esto en bancos online )
Limpiar las cookies regularmente.
Nota final
Aca pueden encontrar la presentacion de Perry en Defcon16
No comments:
Post a Comment