7 oct 2024

Los delincuentes ya no roban contraseñas, roban sesiones activas ¿Cómo?

Los atacantes recurren cada vez más al secuestro de sesiones para lograr una adopción generalizada de MFA. Los datos respaldan esto:

  • Microsoft detectó 147.000 ataques de reproducción de tokens en 2023, un aumento interanual del 111% (Microsoft).
  • Los ataques a las cookies de sesión ahora ocurren en el mismo orden de magnitud que los ataques basados ​​en contraseñas (Google).

Pero el secuestro de sesiones no es una técnica nueva, entonces, ¿qué ha cambiado?

El secuestro de sesión tiene una nueva apariencia

Cuando pensamos en el ejemplo clásico de secuestro de sesión, pensamos en los ataques Man-in-the-Middle (MitM) de la vieja escuela que implicaban espiar el tráfico de red local no seguro para capturar credenciales o, más comúnmente, detalles financieros como datos de tarjetas de crédito. O bien, realizando ataques del lado del cliente que comprometan una página web, ejecutando JavaScript malicioso y utilizando secuencias de comandos entre sitios (XSS) para robar el ID de sesión de la víctima.

El secuestro de sesiones se ve bastante diferente hoy en día. El secuestro de sesión moderno, que ya no está basado en la red, es un ataque basado en la identidad que se realiza a través de Internet y tiene como objetivo aplicaciones y servicios basados ​​en la nube.

Si bien el medio es diferente, los objetivos son en gran medida los mismos: robar material de sesión válido (cookies, tokens, identificaciones) para "retomar" la sesión desde el dispositivo del atacante (un dispositivo remoto, navegador y ubicación diferentes).

A diferencia del secuestro de sesiones tradicional, que a menudo falla cuando se enfrenta a controles básicos como tráfico cifrado, VPN o MFA, el secuestro de sesiones moderno es mucho más confiable para eludir los controles defensivos estándar.

También vale la pena señalar que el contexto de estos ataques ha cambiado mucho. Teniendo en cuenta que alguna vez probablemente intentaba robar un conjunto de credenciales de dominio utilizadas para autenticarse en el Active Directory interno, así como en su correo electrónico y aplicaciones comerciales principales, hoy en día la superficie de identidad se ve muy diferente: con decenas o cientos de credenciales separadas y cuentas de usuario en un amplio conjunto de aplicaciones en la nube.

¿Por qué los atacantes quieren robar las sesiones?

En resumen: el robo de sesiones en vivo permite a los atacantes eludir los controles de autenticación como MFA. Si puede secuestrar una sesión existente, tendrá menos pasos de los que preocuparse: no tendrá que preocuparse por convertir nombres de usuario y contraseñas robados en una sesión autenticada.

Si bien, en teoría, los tokens de sesión tienen una vida útil limitada, en realidad pueden seguir siendo válidos por períodos más largos (generalmente alrededor de 30 días) o incluso indefinidamente mientras se mantenga la actividad.

Como se mencionó anteriormente, un atacante puede ganar mucho al comprometer una identidad. Si se trata de una identidad de IdP, como una cuenta de Okta o Entra con acceso SSO a sus aplicaciones posteriores, ¡perfecto! Si no, tal vez sea una aplicación valiosa (¿como Snowflake, tal vez?) con acceso a la mayor parte de los datos de sus clientes. O tal vez sea una aplicación menos atractiva, pero con integraciones interesantes que se pueden explorar.

No sorprende que se hable de la identidad como el nuevo perímetro de seguridad y que los ataques basados ​​en la identidad sigan apareciendo en los titulares.

Sin embargo, no todos los métodos de secuestro de sesiones son iguales, lo que significa que reaccionan de forma diferente a los controles a los que se enfrentan. Esto crea diferentes pros y contras según el enfoque elegido por el atacante.

Comparación de enfoques de secuestro de sesión

Para secuestrar una sesión, primero se deben robar las cookies de sesión asociadas con una sesión de usuario en vivo. En el sentido moderno, existen dos enfoques principales para esto:

  • Utilizando kits de herramientas de phishing modernos como AitM y BitM.
  • Usar herramientas que apuntan a datos del navegador, como infostealer.

Vale la pena señalar que ambos métodos se dirigen tanto al material de credenciales típico (por ejemplo, nombres de usuario y contraseñas) como a las cookies de sesión. Los atacantes no necesariamente eligen buscar cookies de sesión en lugar de contraseñas; más bien, las herramientas que utilizan admiten ambas cosas, ampliando los medios disponibles para ellos. Si se identifican cuentas sin MFA (y todavía hay muchas), las contraseñas funcionarán bien.

Ataques de phishing modernos: AitM y BitM

Los kits de herramientas de phishing modernos hacen que la víctima complete cualquier verificación de MFA como parte del proceso.

En el caso de Adversary-in-the-Middle (AitM) la herramienta actúa como un proxy, lo que significa que el atacante puede interceptar todo el material de autenticación, incluidos secretos como tokens de sesión.

Este ataque funciona mediante un Proxy web inverso que es posiblemente el enfoque más escalable y confiable desde el punto de vista de un atacante. Cuando una víctima visita un dominio malicioso, las solicitudes HTTP se pasan entre el navegador de la víctima y el sitio real a través del sitio malicioso. Cuando el sitio malicioso recibe una solicitud HTTP, la reenvía al sitio legítimo que está suplantando, recibe la respuesta y luego la reenvía a la víctima.

Las herramientas de código abierto que demuestran este método incluyen Modlishka, Muraena y el siempre popular Evilginx. En el mundo criminal, también hay disponibles conjuntos de herramientas privadas similares que se han utilizado en muchas infracciones en el pasado.

Browser-in-the-Middle (BitM) va un paso más allá. En lugar de actuar como un proxy web inverso, esta técnica engaña al objetivo para que controle directamente el propio navegador del atacante de forma remota mediante enfoques de control y uso compartido de la pantalla del escritorio como VNC y RDP. Esto permite al atacante recopilar no solo el nombre de usuario y la contraseña, sino también todos los demás secretos y tokens asociados que acompañan al inicio de sesión. En este caso, la víctima no está interactuando con un clon o proxy de un sitio web falso. Literalmente controlan de forma remota el navegador del atacante para iniciar sesión en la aplicación legítima sin darse cuenta. Es el equivalente virtual de un atacante que le entrega su computadora portátil a la víctima, le pide que inicie sesión en Okta y luego se lleva la computadora portátil.

En términos prácticos, el enfoque más común para implementar esta técnica es utilizar el proyecto de código abierto noVNC, que es un cliente VNC basado en JavaScript que permite utilizar VNC en el navegador. Probablemente el ejemplo más conocido de una herramienta ofensiva que implementa esto es EvilnoVNC, que activa instancias Docker de VNC y proporciona acceso a ellas, al mismo tiempo que registra las pulsaciones de teclas y las cookies para facilitar el compromiso de la cuenta.

A diferencia del MitM tradicional, que suele ser muy oportunista, el AitM tiende a ser mucho más específico, ya que es producto de una campaña de phishing. Si bien AitM escala mucho mejor que los ataques MitM tradicionales (que eran muy locales), con AitM estás naturalmente enfocado en cuentas que pertenecen a una aplicación o servicio específico según la aplicación que estés emulando o el sitio que estés suplantando.

Ladrones de información (infostealer)

Por otro lado, los ladrones de información tienden a ser menos específicos que AitM: son mucho más oportunistas. Esto es particularmente evidente cuando se observan los mecanismos de entrega típicos de infostealers: infectando sitios web (o complementos), publicidad maliciosa, sitios de descarga P2P, foros de juegos, anuncios en redes sociales, repositorios públicos de GitHub… y la lista continúa.

Algunas estadísticas recientes muestran el alcance del problema:

Hay buenas razones para esto cuando se habla de secuestro de sesión:

  • Los ladrones de información se dirigen a todas las cookies de sesión guardadas en los navegadores de la víctima, así como a toda la demás información y credenciales guardadas, lo que significa que se ponen en riesgo más sesiones como resultado de un ataque de ladrón de información en comparación con un ataque AitM más dirigido que solo resultará en el compromiso de una única aplicación/servicio (a menos que sea una cuenta de IdP utilizada para SSO con otras aplicaciones posteriores).
  • Debido a esto, los ladrones de información son bastante flexibles. En el caso de que existan controles a nivel de aplicación que impidan el acceso a la sesión desde el dispositivo del delincuente (como controles estrictos de bloqueo de IP que requieren una dirección IP de oficina específica que no se pueda eludir mediante redes proxy residenciales), puede intentarlo otras aplicaciones. Si bien es común tener controles más sólidos, por ejemplo, en su inicio de sesión de M365, es menos probable que se implementen para aplicaciones posteriores, lo que puede ser igual de fructífero para un atacante. Incluso si normalmente se accede a estas cuentas a través de SSO, un atacante aún puede robar y reanudar las sesiones con las cookies de sesión sin necesidad de autenticarse en la cuenta de IdP.

¿Pero el EDR no bloquea a los infostealers?

No necesariamente. Los mejores EDR probablemente detectarán a la mayoría de los ladrones de información comerciales, pero los atacantes están innovando continuamente y, en particular, se sabe que grupos de amenazas más sofisticados y con mejores recursos desarrollan paquetes de malware personalizados o hechos a medida para evadir la detección. Así que es un juego del gato y el ratón y siempre hay excepciones que se escapan de la red, o vulnerabilidades que pueden explotarse para sortearlas, como esta falla en Microsoft Defender SmartScreen, que recientemente fue explotada para entregar malware de robo de información.

Las infecciones por Infostealer a menudo se remontan al compromiso de dispositivos no administrados, como en organizaciones que respaldan BYOD o en el caso de contratistas externos que utilizan sus propios equipos. Y la mayoría de los ataques históricos de robo de información se han atribuido a dispositivos personales. Sin embargo, dado que los perfiles del navegador se pueden sincronizar entre dispositivos, un dispositivo personal comprometido puede fácilmente resultar en el compromiso de las credenciales corporativas:

  1. El usuario inicia sesión en su cuenta personal de Google en su dispositivo de trabajo y guarda el perfil.
  2. El usuario habilita la sincronización de perfiles (es fácil de hacer y el diseño lo recomienda) y comienza a guardar secretos corporativos en el administrador de contraseñas del navegador.
  3. El usuario inicia sesión en su dispositivo personal y el perfil se sincroniza.
  4. Recogen una infección de robo de información en su dispositivo personal.
  5. Todas las credenciales guardadas, incluidas las corporativas, son robadas por el malware.

Por lo tanto, no se puede confiar en que EDR elimine por completo el riesgo que representan los ladrones de información cuando se considera la realidad de cómo funcionan los ataques de identidad y cómo las identidades personales y corporativas de sus usuarios pueden converger en el lugar de trabajo moderno.

¿Qué pasa con las PassKey?

Las passkey son un control de autenticación resistente al phishing, lo que significa que son efectivas para prevenir ataques AitM y BitM que requieren que la víctima complete el proceso de autenticación para poder secuestrar la sesión. Sin embargo, en el caso de los ladrones de información, no se realiza ninguna autenticación. El ataque de robo de información se dirige al punto final (la computadora del usuario), mientras que la acción de importar cookies de sesión robadas al navegador del atacante simplemente reanuda la sesión existente en lugar de volver a realizar el proceso de autenticación.

Detectar y responder al secuestro de sesión

Existen múltiples capas de controles que, en teoría, funcionan para evitar el secuestro de sesiones al final de la cadena de ataque.

Etapa 1: Entrega del malware

Primero se debe atraer a la víctima para que descargue el infostealer. Como se mencionó anteriormente, esto puede suceder en muchos lugares diferentes y, a veces, no sucede en un dispositivo corporativo con los controles esperados (por ejemplo, seguridad del correo electrónico, filtrado de contenido, listas de bloqueo conocidas como malas). E incluso cuando ya están vigentes, a menudo no son suficientes.

Etapa 2: ejecutar el malware

El principal control que protege contra esto es su solución AV/EDR que, ya se sabe, no es infalible.

Etapa 3: Detección de sesiones no autorizadas

Una vez que un atacante ha robado las cookies de su sesión, la última oportunidad que tiene de detectarlas es en el momento en que se utilizan para secuestrar la sesión.

La última línea de defensa para la mayoría de las organizaciones serán los controles dentro de la aplicación, como las políticas de restricción de acceso. Como se mencionó anteriormente, generalmente no es tan difícil eludir las restricciones de bloqueo de IP, por ejemplo, a menos que estén especialmente bloqueadas, como la dirección IP de una oficina específica. Incluso entonces, si el atacante no puede acceder a su cuenta M365, es poco probable que cada una de sus aplicaciones posteriores tenga los mismos niveles de política restrictiva.

Entonces, si bien existe una posibilidad razonable de que los ladrones de información sean detectados y bloqueados en dispositivos corporativos, no es una garantía absoluta, y muchos ataques de ladrones de información los eludirán por completo. Cuando se trata de detectar y bloquear sesiones no autorizadas, depende de controles variables a nivel de aplicación, que tampoco son tan efectivos.

Esta demostración en video muestra la cadena de ataque en acción desde el punto de compromiso de un ladrón de información, que muestra el robo de cookies de sesión, la reimportación de cookies al navegador del atacante y la evasión de controles basados ​​en políticas en M365. También muestra el objetivo de aplicaciones posteriores a las que normalmente se accede a través de SSO en el contexto de un compromiso de Microsoft Entra y Okta.

Agregando una nueva línea de defensa: el navegador

Los profesionales de la seguridad están acostumbrados a aprovechar el concepto de la Pirámide del Dolor en estas situaciones. Cuando una detección falla, generalmente se centra en detectar el tipo incorrecto de indicador (es decir, está vinculado a una variable que es fácil de cambiar para el atacante).

Para que el ataque tenga éxito, el atacante debe reanudar la sesión de la víctima en su propio navegador. Ésta es una acción, un comportamiento, que no se puede evitar. Entonces, ¿qué pasaría si pudieras detectar cada vez que un atacante utiliza un token de sesión robado y secuestra una sesión?

El equipo de Push Security ha lanzado un control que detecta precisamente esto. Inyectando un marcador único en la cadena de sesiones del user-agent que ocurren en los navegadores inscritos en Push. Al analizar los registros del IdP, puede identificar la actividad de la misma sesión que tiene el marcador Push y que carece del marcador.

Esto sólo puede suceder cuando una sesión se extrae de un navegador y se importa maliciosamente a un navegador diferente. Como beneficio adicional, esto significa que también actúa como última línea de defensa contra cualquier otro tipo de ataque de apropiación de cuentas, donde de repente se accede a una aplicación a la que normalmente se accede desde un navegador con el complemento Push instalado desde una ubicación diferente.

La detección de sesiones robadas es solo una característica poderosa diseñada para brindar una defensa en capas contra la apropiación de cuentas, junto con:

  • Detectar y bloquear el comportamiento del usuario al ingresar su contraseña en cualquier sitio al que no pertenece la contraseña.
  • Detectar cuando una página de inicio de sesión a la que accede se clona desde una página legítima.
  • Detectar y bloquear el acceso a una página que ejecuta un kit de phishing AitM o BitM.

Para ver cómo el agente de navegador de Push Security detiene los ataques de identidad usted mismo, solicite una demostración con el equipo hoy o regístrese para una prueba de autoservicio.

Fuente: THN

Suscríbete a nuestro Boletín

0 Comments:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!