Secuestro de sesión

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

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 llamó 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[editar]

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[editar]

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 email 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 paquete de usos atacante que husmea para leer tráfico de red entre dos partidos para robar la galleta de sesión. Muchos sitios de web utilizan SSL encriptación para login páginas para impedir atacantes de ver la contraseña, pero no utiliza encriptación para el resto del sitio una vez autenticó. Esto deja atacantes que puede leer el tráfico de red para interceptar todo el dato que está entregado al servidor o las páginas web vieron por el cliente. Desde este dato incluye la galleta de sesión, le deje a impersonate la víctima, incluso si la contraseña él no es compromised. Unsecured Wi-Fi hotspots es particularmente vulnerable, cuando 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-sitio scripting, donde los trucos atacantes el ordenador del usuario a correr código qué está tratado como fidedigno porque aparece para pertenecer al servidor, dejando el atacante de obtener una copia de la galleta o actuar otras operaciones.
  • Malware Y los programas indeseados pueden utilizar navegador hijacking para robar los archivos de galleta de un navegador sin el conocimiento de un usuario, y entonces actuar acciones (gusta instalar aplicaciones de Androide) sin el conocimiento del usuario. Un atacante con el acceso físico sencillamente puede intentar para robar la llave de sesión por, por ejemplo, obteniendo el archivo o contenidos de memoria de la parte apropiada del ordenador de cualquier el usuario o el servidor.[2]

Ataques[editar]

Firesheep[editar]

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[editar]

Una aplicación llamada "WhatsApp Sniffer" apareció en Google Play en mayo 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[editar]

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 que 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[editar]

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 fuente abierta 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 fuente abierta 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[editar]

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[editar]

Referencias[editar]

Enlaces externos[editar]