Secuestro de sesión

En informática, el secuestro de sesión, a veces también conocido como secuestro de cookie es la explotación de una sesión de ordenador válida—a veces también llamado una llave de sesión—para obtener acceso no autorizado a información o servicios en un sistema computacional. En particular, suele referirse al robo de una cookie mágica utilizada para autenticar un usuario a un servidor remoto. Es particularmente relevante para desarrolladores web, ya que las cookies de HTTP utilizadas para mantener una sesión en muchos sitios web pueden ser fácilmente robadas por un atacante utilizando un ordenador de intermediario o al acceder a cookies guardadas en el ordenador de la víctima (ver robo de cookie de HTTP).

Un método popular utiliza paquetes IP enrutados por origen. Esto permite a un atacante en un punto B de la red que participe en una conversación entre A y C al empujar que los paquetes IP pasen a través de la máquina B.

Si el encaminamiento basado en origen no es factible, el atacante puede utilizar secuestro "ciego", por el cual adivina las respuestas de las dos máquinas. Así, el atacante puede enviar una orden, pero nunca puede ver la respuesta. Aun así, una orden común sería poner una contraseña que permita el acceso desde algún lugar más en la red.

Un atacante también puede estar entre ("inline")  A y C utilizando un programa de captura para mirar la conversación. Esto es conocido como "ataque de intermediario".

Historia de HTTP

Las versiones 0.8 y 0.9 del protocolo HTTP no tenían cookies y otras características necesarias para secuestros de sesión. La versión 0.9beta de Mosaic Netscape, liberada el 13 de octubre de 1994, permitía cookies.

Las versiones tempranas de HTTP 1.0 tenían algunas debilidades de seguridad relacionandas a secuestros de sesión, pero eran difíciles de explotar debido a las ambigüedades de los servidores y navegadores HTTP 1.0 iniciales. Debido a que HTTP 1.0 ha sido designado como opción retrocompatible para HTTP 1.1 desde principios de los 2000 —y ya que los servidores HTTP 1.0 son todos esencialmente servidores HTTP 1.1 el problema de secuestro de sesión ha evolucionado a un riesgo de seguridad casi permanente.

La introducción de supercookies y otras características con el HTTP 1.1 modernizado ha permitido que el problema del secuestro se transforme en un problema de seguridad actual. La estandarización de estados de máquina de servidores web y navegadores ha contribuido a este problema de seguridad actual.

Métodos

Hay cuatro métodos principales utilizados para perpetrar un secuestro de sesión. Estos son:

• Fijación de sesión, donde el atacante fija la identidad de sesión de un usuario a una conocida por él, por ejemplo enviando al usuario un correo electrónico con un enlace que contiene una identidad particular de sesión. El atacante ahora sólo tiene que esperar hasta que el usuario ingrese.
• Lado de sesión jacking, donde el analizador de paquetes atacante husmea para leer tráfico de red entre dos partes para robar la cookie de sesión. Muchos sitios de web utilizan encriptación SSL en páginas de login para impedir a los atacantes ver la contraseña, pero no utiliza encriptación para el resto del sitio una vez autenticó. Esto deja la posibilidad a los atacantes de leer el tráfico de red para interceptar todos los datos que se entregan al servidor, así como las páginas webs visitadas por el cliente. Dado que estos datos incluyen la cookie de sesión, el atacante puede hacerse pasar por la víctima, incluso si su contraseña no está comprometida. Los Wi-Fi hotspots son particularmente vulnerables, ya que cualquiera compartiendo la red generalmente será capaz de leer la mayoría del tráfico de web entre otros nodos y el punto de acceso.^[1]​
• Cross-site scripting, donde el atacante engaña al ordenador del usuario para ejecutar código que es interpretado como confiable ya que parece pertenecer al servidor, permitiéndole obtener una copia de la cookie o llevar a cabo otras operaciones.
• Malware y programas indeseados pueden utilizar un secuestro de navegador ("Browser Hijacking") para robar los archivos cookie de un navegador sin el conocimiento del usuario, y entonces realizar acciones (como instalar aplicaciones de Android) silenciosamente. Un atacante con el acceso físico sencillamente puede intentar robar la cookie de sesión, por ejemplo, obteniendo el archivo o los contenidos de la memoria del ordenador del usuario o del servidor.^[2]​

Ataques

Firesheep

En octubre de 2010, una extensión de Mozilla Firefox llamada Firesheep fue liberada lo que hizo fácil a secuestradores de sesión que atacaran usuarios de Wi-Fi públicos sin encriptar. Muchos sitios web como Facebook, Twitter, y cualquiera que el usuario añadiera a sus preferencias permitían al usuario de Firesheep a acceder información privada de cookies fácilmente y amenazar la propiedad personal del usuario del Wi-Fi público.^[3]​ Unos meses más tarde, Facebook y Twitter respondieron ofreciendo (y más tarde exigiendo) HTTP Seguro en todos los accesos.^[4]​^[5]​

Sniffer de WhatsApp

Una aplicación llamada "WhatsApp Sniffer" apareció en Google Play en mayo de 2012, y era capaz de mostrar mensajes de otros usuarios de WhatsApp conectados a la misma red que el usuario de la aplicación.^[6]​ En ese tiempo WhatsApp utilizaba infraestructura XMPP con encriptado, no comunicación de texto plano.^[7]​

DroidSheep

DroidSheep es una herramienta sencilla de Android para secuestro de sesión de web (sidejacking). Escucha  paquetes de HTTP enviados vía una conexión de red inalámbrica (802.11) y extrae la id de sesión de estos paquetes para reutilizarla. DroidSheep puede capturar las sesiones utilizando la librería libpcap y permite: redes abiertas (sin encriptar), redes encriptadas con WEP, y redes encriptadas con WPA/WPA2 (solo PSK). Este software utiliza libpcap y arpspoof.^[8]​^[9]​ El apk fue liberado en Google Play pero fue retirada de ahí por Google.

CookieCadger

CookieCadger es una aplicación en Java que automatiza el sidejacking y la repetición de peticiones HTTP GET inseguras. Cookie Cadger ayuda a identificar fugas de información desde aplicaciones que utilizan peticiones HTTP GET inseguras. Los proveedores web han empezado a avanzar en resolver esto desde el lanzamiento de Firesheep en 2010. Hoy, los sitios web más importantes pueden ofrecer SSL/TLS durante todas las transacciones, impidiendo fugas de información desde cookies tanto en Ethernet por cable o por Wi-Fi inseguro. Cookie Cadger es una herramienta de penetración de seguridad gráfica de código abierto hecha para interceptar y repetir peticiones concretas HTTP GET inseguras a un navegador. Cookie Cadger es una utilidad gráfica qué toma todo el poder de la herramienta Wireshark y de Java para proporcionar una herramienta plenamente multiplataforma, completamente de código abierto la cual puede usarse para monitorear redes Ethernet cableadas, Wi-Fi inseguro, o cargar un archivo de información de captura de paquetes para análisis off-line. Cookie Cadger ha sido usado para destacar las debilidades de sitios donde la juventud comparte información como Shutterfly (utilizados por la liga AYSO de fútbol) y TeamSnap.^[10]​

Prevención

Los métodos para impedir secuestro de sesión incluyen:

• Encriptación del tráfico de datos entre las partes utilizando SSL/TLS; en particular la llave de sesión (aun así idealmente todo tráfico para la sesión completa).^[11]​ Los sitios de banca y comercio electrónico confían ampliamente en esta técnica, porque impide completamente los ataques de tipo sniffer. Aun así, todavía es posible ejecutar otros tipos de secuestro de sesión. En respuesta, científicos de la Universidad Radboud Nijmegen propusieron en 2013 una manera de impedir el secuestro de sesión correlacionando la sesión de aplicación con las credenciales SSL/TLS.^[12]​
• Uso de un número aleatorio largo o string como llave de sesión. Esto reduce el riesgo que un atacante sencillamente pueda adivinar una llave de sesión válida a través de prueba y error o de ataques de fuerza bruta.
• Regenerando la sesión id después de un exitoso login. Esto impide la fijación de sesión porque el atacante no sabe la id de sesión del usuario después de que él/ella se ha registrado.
• Algunos servicios hacen controles secundarios de identidad del usuario. Para ejemplo, un servidor web podría comprobar que la dirección IP de cada petición que hizo la usuaria sea la misma que la última utilizada durante aquella sesión. Esto no impide ataques por alguien quién comparte la misma dirección de IP, sin embargo, y podría ser frustrar para usuarios cuya dirección IP tiende a cambiar durante una sesión de navegación.
• Alternativamente, algunos servicios cambiarán el valor de la cookie con cada petición. Esto reduce dramáticamente la ventana en la cual un atacante puede operar y hace fácil identificar si ha tenido lugar un ataque, pero puede causar otros problemas técnicos (por ejemplo, dos peticiones legítimas, con muy poca diferencia de tiempo del mismo cliente pueden llevar a un error de control de token en el servidor).
• Los usuarios también pueden querer cerrar la sesión de los sitios web cada vez que terminan de usarlos.^[13]​^[14]​ Aun así esto no protegerá contra ataques como Firesheep.

Véase también

• ArpON
• Cross-petición de sitio forgery
• Galleta de HTTP
• TCP Ataque de predicción de la secuencia

Referencias

1. «Warning of webmail wi-fi hijack». BBC News. 3 de agosto de 2007. 
2. Rudis Muiznieks. «Exploiting Android Users for Fun and Profit». The Code Word. 
3. «Firefox extension steals Facebook, Twitter, etc. sessions». 25 de octubre de 2010. 
4. «Facebook now SSL-encrypted throughout». 27 de enero de 2011. 
5. «Twitter adds ‘Always use HTTPS’ option». 16 de marzo de 2011. 
6. «Sniffer tool displays other people's WhatsApp messages». 13 de mayo de 2012. 
7. «WhatsApp no longer sends plain text». 24 de agosto de 2012. 
8. «DroidSheep». 
9. . Archivado desde el original el 20 de noviembre de 2016. Consultado el 11 de diciembre de 2017. 
10. «How Shutterfly and Other Social Sites Leave Your Kids Vulnerable to Hackers». Mother Jones. 3 de mayo de 2013. 
11. «Schneier on Security: Firesheep». 27 de octubre de 2010. Consultado el 29 de mayo de 2011. 
12. «Prevent Session Hijacking by Binding the Session to the Cryptographic Network Credentials». Proceedings of the 18th Nordic Conference on Secure IT Systems (NordSec 2013). 2013. 
13. See «NetBadge: How To Log Out». 
14. See also . Archivado desde el original el 24 de julio de 2010. Consultado el 11 de diciembre de 2017. 

Enlaces externos

• Web oficial de ArpON

•   Datos: Q638079