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

El secuestro de sesión (también conocido como secuestro de cookies o 'cookie side-jacking') es un ciberataque en el que los atacantes toman el control de la sesión de un usuario legítimo para obtener su ID de sesión y luego actúan 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 que contienen) 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 consecuencias del secuestro de sesión?
• ¿Cuáles son ejemplos de secuestro de sesión?
• ¿Cómo puede protegerse contra el secuestro de sesión?

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

Las sesiones resuelven este desafío. Se crea una sesión en el servidor que aloja el sitio web o la aplicación una vez que un usuario inicia sesión, y luego sirve como referencia para la autenticación inicial. Esencialmente, 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 del servicio, o algunos servicios finalizan una sesión después de un período 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 en el sitio web. En algunos casos, estos ID de sesión se cifran, pero no siempre es así. Y en muchos casos, estos ID de sesión se basan en información predecible, como la dirección IP de un usuario.

El secuestro de sesión ocurre cuando los atacantes obtienen acceso no autorizado al ID de sesión de un usuario, lo que les permite asumir la identidad en línea de ese usuario. Al hacerlo, los atacantes pueden hacerse pasar por usuarios legítimos, obtener información y realizar acciones bajo 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 conseguir 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 contenga un ID de sesión predecible (más detalles a continuación).

Una vez que un atacante obtiene el ID de sesión y el usuario ha iniciado sesión en el servicio, el atacante puede tomar el control de la sesión. Esto se logra aplicando el ID de sesión del usuario legítimo a su propio navegador, lo que engaña al servicio haciéndole creer que el atacante es el usuario legítimo que participa en esa misma sesión.

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

Profundizar en el funcionamiento exacto del secuestro de sesión revela numerosas formas de llevar a cabo este tipo de ataque. Los tipos de secuestro de sesión incluyen:

El cross-site scripting (XSS) representa uno de los mayores riesgos y enfoques más comunes para el secuestro de sesión. El XSS se produce cuando el atacante detecta vulnerabilidades en el servidor o la aplicación objetivo y las explota 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 para el usuario, ya que proviene de un servidor de confianza. Una vez cargado el código malicioso, el atacante obtiene acceso para robar el ID de sesión del usuario.

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

El 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 herramientas de rastreo de paquetes, como Wireshark o Kismet, para monitorear el tráfico de red y robar cookies de sesión después de la autenticación. Los usuarios son más vulnerables a este tipo de ataque cuando el servidor solo cifra la página de autenticación y no otras páginas dentro de la sesión. Como resultado, los atacantes pueden obtener el ID de sesión post-autenticación en las páginas no cifradas a lo largo de la sesión.

Es importante destacar que los atacantes necesitan acceso a la red del usuario para ejecutar este tipo de ataque, lo que implica que el session side-jacking suele producirse en redes WiFi no seguras o redes públicas. 

La fijación de sesión ocurre 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 escenario, un atacante puede establecer un ID de sesión en nombre de un usuario y luego lograr que el usuario inicie sesión de forma consecuente, ya sea enviándole una URL de phishing que contenga el ID de sesión o configurando ese ID dentro de un formulario de inicio de sesión falso. 

En cualquier caso, el usuario legítimo inicia sesión en un sitio web y se autentica utilizando el ID de sesión fijado por (y, por lo tanto, conocido por) el atacante. Una vez que el usuario ha iniciado sesión, el atacante también puede asumir el ID de sesión.

Muchos sitios web siguen un patrón para la emisión de IDs de sesión y, en algunos casos, puede ser tan simple como utilizar la dirección IP del usuario. En estas situaciones, los atacantes pueden monitorear los IDs de sesión emitidos para determinar el patrón. Si lo logran, 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 su propio uso.

De manera similar, un ataque de fuerza bruta puede ocurrir si los atacantes obtienen acceso a una lista predefinida de IDs de sesión y los prueban repetidamente hasta que uno funciona. Normalmente, dispondrán de dicha lista si el patrón para generar los IDs es predecible. La diferencia, en este caso, es que es posible que no puedan predecir el ID para un usuario específico, por lo que deberán probar diferentes IDs de la lista hasta encontrar 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 intermediario e interceptar información, modificar las acciones que un usuario realiza en el sitio o llevar a cabo 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 estos escenarios.

Con este tipo de acceso al dispositivo de un usuario, los atacantes también pueden acceder directamente a la carpeta de almacenamiento local temporal del usuario en el navegador (también conocida como el «tarro de cookies») y, a continuación, obtener los IDs de sesión de las cookies que deseen.

El secuestro de sesión y la suplantación de sesión son similares en muchos aspectos, pero no son, en última instancia, el mismo tipo de ataque. La diferencia más significativa entre estos dos tipos de ataques es que el secuestro de sesión ocurre cuando un usuario legítimo ha iniciado sesión en una sesión web válida. En contraste, la suplantación de sesión ocurre 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 haber iniciado sesión en ese momento).

La manifestación más significativa de esta diferencia radica en la experiencia del 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 comporten de forma inusual o incluso fallen para la víctima. Mientras tanto, dado que el usuario no ha iniciado sesión activamente durante un ataque de suplantación de sesión, no experimentará ningún «efecto secundario» en la siguiente sesión.

Una instancia exitosa de secuestro de sesión otorga al atacante la capacidad de realizar cualquier acción que el usuario objetivo pueda llevar a cabo. Esto conlleva un riesgo considerable para la seguridad de las aplicaciones de diversas maneras, especialmente en lo que respecta a la iniciación de transacciones monetarias, el acceso a datos protegidos o la obtención de 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 monetario: Los atacantes obtienen la capacidad de realizar transacciones financieras en nombre del usuario. Esto podría implicar la transferencia de dinero de una cuenta bancaria o la realización de compras con 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 una víctima más allá de los límites del sitio web/aplicación hackeado.
• Robo de datos: Los atacantes pueden robar cualquier tipo de datos personales u organizacionales sensibles alojados en la aplicación y utilizar esa información para dañar a la víctima o a la organización (por ejemplo, en el caso de chantaje) o para perseguir sus propios fines (por ejemplo, en el caso de vender información protegida, potencialmente competitiva o propiedad intelectual).
  
• Acceso a sistemas adicionales a través de SSO: Los atacantes también pueden obtener acceso no autorizado a sistemas adicionales si el SSO está habilitado, lo que amplía 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 sus empleados. En última instancia, esto significa que incluso los sistemas altamente protegidos con protocolos de autenticación más robustos y cookies de sesión menos predecibles, como los que albergan información financiera o de clientes, pueden estar protegidos solo hasta el punto del eslabón más débil de todo el sistema.

Varios ejemplos de alto perfil 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 la pandemia de COVID-19 golpeó, el mundo se digitalizó, con eventos escolares, laborales y sociales que 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 del secuestro de sesión, incluso ganándose el nombre de «Zoom-bombing». 

Se produjeron varios incidentes notables en los que atacantes se involucraron en el secuestro de sesiones para unirse a sesiones de video privadas. Los casos más reportados incluyeron aquellos en los que los atacantes se hicieron notar gritando blasfemias, lenguaje de odio y compartiendo imágenes pornográficas. En respuesta, empresas como Zoom implementaron protecciones de privacidad más robustas, como contraseñas de reunión y salas de espera, para que los anfitriones pudieran admitir manualmente a los invitados.

En 2010, Mozilla Firefox lanzó una extensión de navegador llamada Firesheep que abrió una vulnerabilidad para las personas que utilizaban el navegador en redes Wi-Fi públicas no cifradas. Específicamente, la extensión Firesheep facilitó a los atacantes el robo de las cookies de sesión de estos usuarios de 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 en una plataforma de recompensas por errores 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 resulta ser bastante). Slack respondió rápidamente y parcheó la vulnerabilidad en las 24 horas siguientes a su identificación por parte del investigador.

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 usarlo sin preocuparse por su caducidad. 

Esta combinación de exposición abierta y tokens persistentes representaba un riesgo grave, exponiendo a los usuarios a diversos ataques severos mediante el secuestro de sesión a través de un ataque de fuerza bruta. GitLab finalmente corrigió 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 al utilizar múltiples (si no todos) estos enfoques de forma conjunta para proporcionar varias líneas de defensa.

Asegúrese de que los sitios web y las aplicaciones que utiliza su equipo (especialmente aquellos que forman parte de un universo SSO) requieran el uso de HTTPS en todas partes —incluso más allá de las páginas de inicio de sesión iniciales— para garantizar sesiones totalmente seguras en cada etapa. También debe exigirles el estándar de utilizar el cifrado SSL/TLS para todo, incluido el intercambio de 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. Finalmente, debe establecer un estándar para restringir el acceso a las cookies desde scripts del lado del cliente para protegerse contra ataques XSS.

Cuanto más largas y aleatorias sean las cookies de sesión generadas, 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 propio.

La mejor manera 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 al iniciar sesión. 

Cambiar la clave después del inicio de sesión asegura que, incluso si un atacante conoce la clave original, no conocerá la clave que acompañará 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 estos lo utilizan para iniciar sesión, el atacante no podrá hacer nada con la clave generada.

Añadir nuevas áreas para la verificación de 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, se podría examinar la dirección IP del usuario para determinar si coincide con la ubicación de inicios de sesión anteriores o monitorear el comportamiento general de cada usuario para identificar mejor cualquier anomalía. Sin embargo, este enfoque no es perfecto: puede señalar falsos positivos, como en casos donde los usuarios se desplazan con frecuencia, y puede pasar por alto problemas reales, como en situaciones donde un atacante inicia sesión desde la misma dirección IP que el usuario habitualmente.

Los IDS y los IPS comparan el tráfico del sitio con una base de datos de firmas de ataque 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 costosos de instalar, pero ofrecen una sólida capa de defensa contra el secuestro de sesiones.

Finalmente, considere instituir políticas que gestionen cómo los usuarios finalizan las sesiones. Dos enfoques populares incluyen limitar el tiempo de las sesiones de usuario, particularmente después de un período de inactividad, y requerir el cierre de sesión automático cada vez que se cierra la ventana. Ambos enfoques ayudan a minimizar el tiempo que una cookie de sesión particular permanece activa. En la misma línea, una vez que un usuario cierra sesión, debe asegurarse de que la cookie de sesión se elimine automáticamente de su dispositivo para evitar cualquier exposición adicional.

Basta un certificado caducado para que los sistemas y aplicaciones críticos dejen de funcionar. Pero sin visibilidad, es imposible ir por delante. Keyfactor está aquí para ayudarle a evitar el secuestro de sesiones y las caídas del sistema-póngase en contacto con nosotros hoy mismo.