¿Qué es el secuestro de sesión y cómo funciona?

El secuestro de sesión (también conocido como secuestro de cookies o secuestro lateral de cookies) es un ciberataque en el que los atacantes se apoderan de la sesión de un usuario legítimo para obtener su ID de sesión y luego actuar como ese usuario en cualquier número de servicios de red. Este tipo de ataque es peligroso para la seguridad de las aplicaciones porque permite a los atacantes obtener acceso no autorizado a cuentas protegidas (y a los datos alojados en ellas) bajo la apariencia de un usuario legítimo.

Este artículo explorará todo lo que necesita saber sobre el secuestro de sesión, incluyendo

• ¿Qué es el secuestro de sesión?
• ¿Cómo funciona el secuestro de sesión?
• ¿Cuáles son los tipos de secuestro de sesión?
• ¿En qué se diferencia el secuestro de sesión de la suplantación de sesión?
• ¿Cuáles son los riesgos y las consecuencias del secuestro de sesión?
• ¿Cuáles son ejemplos de secuestro de sesión?
• ¿Cómo protegerse contra el secuestro de sesión?

Cada vez que un usuario accede a un sitio web o a una aplicación a través de una conexión HTTP, el servicio autentica al usuario (por ejemplo, mediante un nombre de usuario y una contraseña) antes de abrir la línea de comunicación y proporcionarle acceso. Sin embargo, las conexiones HTTP por sí solas son "sin estado", lo que significa que cada acción que realiza un usuario se ve de forma independiente. Por eso, si dependiéramos exclusivamente de HTTP, los usuarios tendrían que volver a autenticarse cada vez que realizaran una acción o consultaran una página.

Las sesiones resuelven este problema. Una sesión se crea en el servidor que aloja el sitio web o la aplicación una vez que el usuario se conecta y sirve como referencia para la autenticación inicial. Básicamente, los usuarios pueden permanecer autenticados mientras la sesión permanezca abierta en el servidor. Los usuarios pueden finalizar una sesión cerrando la sesión en el servicio, o algunos servicios finalizan una sesión tras un periodo predefinido de inactividad.

La mayoría de los servicios crean estas sesiones emitiendo un ID de sesión, una cadena de números y letras almacenada en cookies de sesión temporales, URL o campos ocultos del sitio web. En algunos casos, estos identificadores de sesión se cifran, pero no siempre es así. Y en muchos casos, estos identificadores de sesión se basan en información predecible, como la dirección IP del usuario.

El secuestro de sesión se produce cuando los atacantes obtienen acceso no autorizado al identificador de sesión de un usuario, lo que les permite asumir la identidad en línea de ese usuario. De este modo, los atacantes pueden hacerse pasar por usuarios legítimos, obtener información y realizar acciones con la identidad asumida.

El secuestro de sesión comienza cuando un atacante obtiene acceso no autorizado al ID de sesión de un usuario. Los atacantes suelen obtener este acceso robando la cookie de sesión de un usuario (de ahí el nombre alternativo de secuestro de cookies) o convenciendo al usuario para que haga clic en un enlace malicioso que contiene un ID de sesión predicho (más sobre esto más adelante).

Una vez que un atacante tiene el identificador de sesión y el usuario ha iniciado sesión en el servicio, el atacante puede tomar el control de la sesión. Para ello, aplica el identificador de sesión del usuario legítimo a su navegador, lo que engaña al servicio haciéndole creer que el atacante es el usuario legítimo que está participando en esa misma sesión.

Bajo esta apariencia, el atacante puede hacerse pasar por el usuario legítimo y acceder a cualquier información o realizar cualquier acción para la que el usuario esté autorizado. En los casos en que los usuarios tienen un inicio de sesión único (SSO), el atacante puede utilizar este enfoque para obtener acceso no autorizado a cualquier número de aplicaciones, comprometiendo gravemente la seguridad de las aplicaciones en todos los ámbitos.

Si profundizamos en cómo funciona exactamente el secuestro de sesión, descubriremos numerosas formas de llevar a cabo este tipo de ataque. Los tipos de secuestro de sesión incluyen:

El cross-site scripting (XSS) es uno de los mayores riesgos y uno de los métodos más populares de secuestro de sesión. XSS se produce cuando el atacante encuentra vulnerabilidades en el servidor o aplicación de destino y se aprovecha inyectando scripts del lado del cliente en la página web. La página se carga entonces con este código malicioso, pero todo parece legítimo por parte del usuario porque sigue procediendo de un servidor de confianza. Una vez cargado el código malicioso, el atacante puede robar el identificador de sesión del usuario.

El atacante podría enviar un enlace a un sitio web de confianza en un ataque XSS pero con parámetros de consulta HTTP modificados. Una vez que el usuario hace clic en este enlace, el atacante puede acceder a su identificador de sesión o, en algunos casos, el enlace puede incluso enviar esa información directamente al atacante. En casos como este, los atacantes suelen utilizar un acortador de URL para ocultar la URL y, por lo tanto, cualquier cosa sospechosa en el enlace.

Session side-jacking, también conocido como session sniffing, es un tipo de ataque de secuestro más activo. En este caso, los atacantes utilizan programas como Wireshark o Kismet para monitorizar el tráfico de red y robar las cookies de sesión tras la autenticación. Los usuarios son más vulnerables a este tipo de ataque cuando el servidor sólo cifra la página de autenticación y no otras páginas de la sesión. Como resultado, los atacantes pueden obtener el ID de sesión después de la autenticación en las páginas no cifradas a lo largo de la sesión.

Es importante destacar que los atacantes necesitan acceder a la red del usuario para ejecutar este tipo de ataque, lo que significa que el secuestro lateral de sesión suele producirse a través de redes WiFi no seguras o redes públicas. 

La fijación de sesión se produce cuando los atacantes pueden establecer el ID de sesión de un usuario. 

Este tipo de ataque requiere una vulnerabilidad en el sitio web objetivo que permita establecer IDs de sesión a través de URLs o formularios. En este caso, un atacante puede establecer un ID de sesión en nombre de un usuario y luego hacer que el usuario inicie sesión en consecuencia, ya sea enviándole una URL de phishing que contenga el ID de sesión o estableciendo ese ID dentro de un formulario de inicio de sesión falso. 

En ambos casos, el usuario legítimo se conecta a un sitio web y se autentica utilizando el identificador de sesión fijado por el atacante (y, por tanto, conocido por él). Una vez que el usuario ha iniciado sesión, el atacante puede hacerse también con el identificador de sesión.

Muchos sitios web siguen un patrón para emitir los identificadores de sesión y, en algunos casos, puede ser tan sencillo como que sea la dirección IP del usuario. En estos casos, los atacantes pueden monitorizar los identificadores de sesión que se emiten para determinar el patrón. Si pueden hacerlo, entonces pueden predecir fácilmente cómo sería un ID de sesión válido para usuarios específicos y generar ese ID de sesión para utilizarlo ellos mismos.

Del mismo modo, puede producirse un ataque de fuerza bruta si los atacantes acceden a una lista de ID de sesión y los prueban una y otra vez hasta que uno funciona. Normalmente dispondrán de dicha lista si el patrón de generación de IDs es predecible. La diferencia, en este caso, es que pueden no ser capaces de predecir el ID para un usuario específico, por lo que tendrán que probar diferentes IDs de la lista hasta que encuentren una coincidencia.

Un ataque de hombre en el navegador, también conocido como ataque de hombre en el medio o de malware, requiere en primer lugar que los atacantes infecten el ordenador de un usuario con malware. 

Una vez que el malware se instala y un usuario inicia sesión en un sitio web, el atacante puede actuar como un hombre en el medio e interceptar información, modificar las acciones que un usuario realiza in situ o realizar acciones adicionales haciéndose pasar por ese usuario, todo ello sin el conocimiento del usuario. Dado que este tipo de ataque se origina en el dispositivo real del usuario legítimo, puede ser muy difícil detectar cualquier violación de la seguridad de las aplicaciones en este tipo de ataques.

Con este tipo de acceso al dispositivo de un usuario, los atacantes también pueden ir directamente a la carpeta de almacenamiento local temporal del usuario en el navegador (también conocido como el "tarro de las cookies") y luego tomar los ID de sesión para las cookies que quieran.

El secuestro de sesión y la suplantación de sesión son similares en muchos aspectos, pero en última instancia no son el mismo tipo de ataque. La diferencia más significativa entre estos dos tipos de ataques es que el secuestro de sesión se produce cuando un usuario legítimo está conectado a una buena sesión web. En cambio, la suplantación de sesión se produce cuando los atacantes se hacen pasar por un usuario para iniciar una nueva sesión web (lo que significa que el usuario no tiene que estar conectado en ese momento).

La mayor manifestación de esta diferencia es la experiencia para el usuario legítimo. En el caso del secuestro de sesión, un atacante que interrumpe la sesión puede provocar que el sitio web o la aplicación se comporte de forma inusual o incluso que se bloquee para la víctima. Mientras tanto, como el usuario no está conectado activamente durante un ataque de suplantación de sesión, no experimentará ningún "efecto secundario" de la siguiente sesión.

Una instancia exitosa de secuestro de sesión da a un atacante la capacidad de hacer cualquier cosa que el usuario objetivo pueda hacer. Esto conlleva un riesgo significativo para la seguridad de las aplicaciones de varias maneras, sobre todo cuando se trata de iniciar transacciones monetarias, acceder a datos protegidos u obtener acceso no autorizado a otros sistemas a través de SSO.

Algunos de los riesgos más notables del secuestro de sesión incluyen:

• Robo de dinero: Los atacantes adquieren la capacidad de realizar transacciones financieras en nombre del usuario. Esto puede implicar transferir dinero desde una cuenta bancaria o realizar compras con la información de pago guardada.
  
• Robo de identidad: Los atacantes obtienen acceso no autorizado a información personal sensible guardada en cuentas que pueden utilizar para robar la identidad de la víctima más allá de los confines del sitio web/aplicación pirateado.
• Robo de datos: Los atacantes pueden robar cualquier tipo de datos personales u organizativos confidenciales alojados en la aplicación y utilizar esa información para perjudicar a la víctima o a la organización (por ejemplo, en el caso de chantaje) o para perseguir su agenda (por ejemplo, en el caso de venta de información protegida y potencialmente competitiva o de propiedad intelectual).
  
• Acceso a sistemas adicionales a través de SSO: Los atacantes también pueden obtener acceso no autorizado a sistemas adicionales si SSO está habilitado, extendiendo aún más el riesgo potencial de un ataque de secuestro de sesión. Este riesgo es particularmente importante para las organizaciones, muchas de las cuales ahora habilitan el SSO para los empleados. En última instancia, esto significa que incluso los sistemas altamente protegidos con protocolos de autenticación más fuertes y cookies de sesión menos predecibles, como los que albergan información financiera o de clientes, pueden estar tan protegidos como el eslabón más débil de todo el sistema.

Varios ejemplos destacados ilustran exactamente lo que puede ocurrir como resultado de un ataque de secuestro de sesión. Algunos de los ejemplos más notables incluyen:

Cuando se produjo la pandemia de COVID-19, el mundo se volvió digital, y la escuela, el trabajo y los eventos sociales tuvieron lugar a través de aplicaciones de videoconferencia como Zoom. No pasó mucho tiempo hasta que estas videoconferencias se convirtieron en una víctima popular para el secuestro de sesiones, ganándose incluso el nombre de "Zoom-bombing". 

Se produjeron varios casos notables en los que atacantes secuestraron sesiones para unirse a sesiones de vídeo privadas.. Entre los casos más denunciados figuran aquellos en los que los atacantes se dieron a conocer gritando blasfemias, utilizando un lenguaje que incitaba al odio y compartiendo imágenes pornográficas. En respuesta, empresas como Zoom emitieron protecciones de privacidad más estrictas, como contraseñas para las reuniones y salas de espera, para que los anfitriones de las reuniones pudieran admitir manualmente a los invitados.

En 2010, Mozilla Firefox lanzó una extensión del navegador llamada Firesheep que abría una vulnerabilidad para las personas que utilizan el navegador en redes Wifi públicas sin cifrar. En concreto, la extensión Firesheep facilitaba a los atacantes el robo de las cookies de sesión de estos usuarios desde cualquier sitio web añadido a sus preferencias en el navegador. En última instancia, muchos sitios web respondieron para protegerse contra este riesgo de secuestro de sesión exigiendo conexiones HTTP seguras (HTTPS).

En 2019, un investigador de una plataforma de bug bounty encontró una vulnerabilidad en Slack que permitiría a los atacantes forzar a los usuarios a redirecciones de sesión falsas y luego robar sus cookies de sesión, lo que en última instancia daría a los atacantes acceso a cualquier dato compartido dentro de Slack (que para muchas organizaciones termina siendo bastante). Slack respondió rápidamente y parcheó la vulnerabilidad 24 horas después de que el investigador la identificara.

En 2017, un investigador de seguridad identificó una vulnerabilidad en GitLab en la que los tokens de sesión de los usuarios estaban disponibles directamente en la URL. Al profundizar, el investigador descubrió que GitLab también utilizaba tokens de sesión persistentes que nunca caducaban, lo que significaba que una vez que un atacante obtenía un token de sesión, podía utilizarlo sin preocuparse de que caducara.

Esta combinación de exposición abierta y tokens persistentes suponía un grave riesgo, ya que exponía a los usuarios a varios ataques graves mediante el secuestro de la sesión a través de un ataque de fuerza bruta. Finalmente, GitLab solucionó la vulnerabilidad cambiando la forma en que utilizaba y almacenaba esos tokens.

El secuestro de sesión sigue siendo una de las principales amenazas de ciberseguridad, pero existen varias formas de proteger a su organización y a sus usuarios de este tipo de ataque. Los mejores resultados se obtienen utilizando varios (si no todos) de estos enfoques juntos para proporcionar varias líneas de defensa para la protección.

Asegúrese de que los sitios web y las aplicaciones que utiliza su equipo (especialmente los que forman parte de un universo SSO) exigen el uso de HTTPS en todas partes, incluso más allá de las páginas de inicio de sesión, para garantizar sesiones totalmente seguras en todas las etapas. También deberías exigirles que utilicen el cifradoSSL / TLS para todo, incluso para compartir las claves de sesión. 

Este nivel de cifrado es la primera línea de defensa para proteger la visibilidad de las claves de sesión. Por último, deberías establecer un estándar para bloquear el acceso a las cookies desde los scripts del lado del cliente para proteger contra ataques XSS.

Cuanto más largas y aleatorias sean las cookies de sesión que se generen, mejor, ya que esto las hace más difíciles de predecir o adivinar, ofreciendo así protección contra ataques de fuerza bruta. La mejor manera de lograr esta verdadera aleatoriedad es utilizar un framework web para generar y gestionar las cookies de sesión en lugar de crear un sistema tú mismo.

La mejor forma de protegerse contra los ataques de fijación de sesión es cambiar la clave de sesión inmediatamente después de que se produzca la autenticación en el inicio de sesión. 

Cambiar la clave después del inicio de sesión hace que incluso si un atacante conoce la clave original, no conocerá la clave que seguirá al usuario durante el resto de su sesión. Este enfoque significa que incluso si un atacante envía a los usuarios un enlace de phishing y los usuarios utilizan ese enlace para iniciar sesión, el atacante no podrá hacer nada con la clave generada.

Añadir nuevas áreas para la verificación de la identidad más allá del inicio de sesión inicial y la cookie de sesión resultante también puede proporcionar otra capa de protección. 

Por ejemplo, puede fijarse en la dirección IP del usuario para determinar si coincide con la ubicación de inicios de sesión anteriores o supervisar el comportamiento general de cada usuario para identificar mejor cualquier anomalía. Sin embargo, este enfoque no es perfecto: puede no detectar problemas, como los casos en los que los usuarios se desplazan con frecuencia, y puede pasar por alto problemas reales, como los casos en los que un atacante inicia sesión desde la misma dirección IP desde la que suele hacerlo el usuario.

Los IDS e IPS comparan el tráfico del sitio con una base de datos de firmas de ataques conocidas. Si estos sistemas encuentran una coincidencia, bloquearán ese tráfico y alertarán a los propietarios del sistema. Estos sistemas pueden ser difíciles y caros de instalar, pero ofrecen una sólida capa de defensa contra el secuestro de sesiones.

Por último, considere la posibilidad de instituir políticas que gestionen la forma en que los usuarios finalizan las sesiones. Dos enfoques populares incluyen el encajonamiento temporal de las sesiones de usuario, en particular tras un periodo de inactividad, y la exigencia de cierre de sesión automático cada vez que se cierra la ventana. Ambos enfoques ayudan a minimizar la cantidad de tiempo que una cookie de sesión en particular permanece activa. En la misma línea, una vez que el usuario cierra la sesión, debe asegurarse de que la cookie de sesión se elimina automáticamente de su dispositivo para evitar cualquier exposición adicional.