Cómo combatir el secuestro de cuentas: por qué la MFA es solo un primer paso
Introducción
La autenticación multifactor (MFA) no elimina la amenaza de apropiación de cuentas. Sí, añade obstáculos, pero los atacantes más decididos han descubierto formas ingeniosas de eludir todos los factores de autenticación disponibles. En lugar de considerar que resuelve el problema de la autenticación, debemos entender que la MFA amplía la superficie de ataque: cada factor introduce un nuevo sistema de dependencias, nuevas fuentes de errores y vulnerabilidades, y nuevas oportunidades para la ingeniería social. Por desgracia, muchas organizaciones de seguridad ven la MFA como antes veíamos el perímetro de red: una barrera que protege frente a una amplia variedad de ataques. La falacia del perímetro seguro, puesta de manifiesto por los defensores de la seguridad de confianza cero permitió a los atacantes aprovechar vulnerabilidades dentro de las redes para desplazarse lateralmente y escalar privilegios. Del mismo modo, la falsa creencia de que la MFA evita la apropiación de cuentas impide que las organizaciones de seguridad reconozcan sus puntos débiles y las numerosas vulnerabilidades que aún existen en los sistemas y que exponen las cuentas de los usuarios a apropiaciones delictivas. Al analizar cómo eluden los atacantes la MFA, este informe técnico demuestra que esta hace aún más importantes otras medidas de seguridad, en concreto, la mitigación de bots, la protección de la cadena de suministro de JavaScript y la supervisión del riesgo contextual. Estas técnicas refuerzan las ventajas de seguridad de la MFA y, al mismo tiempo, reducen la fricción que impone a los usuarios.
Los factores que impulsan la MFA
A pesar de sus puntos débiles, la MFA ha llegado para quedarse, y con razón: la autenticación basada únicamente en contraseñas ha demostrado claramente ser insuficiente.
Los seres humanos sencillamente no podemos recordar largas cadenas de caracteres aleatorios. Por eso, recurrimos a atajos: elegimos contraseñas predecibles y fáciles de recordar, reutilizamos contraseñas en distintas aplicaciones y las apuntamos en notas adhesivas. Aunque las empresas mitigan este riesgo imponiendo requisitos de longitud y complejidad para las contraseñas, la memoria humana tiene sus límites; incluso ante estos requisitos, encontramos formas de seguir siendo predecibles: ponemos en mayúscula solo la primera letra, sustituimos caracteres alfanuméricos por caracteres especiales de aspecto similar ($ por S) y añadimos al final de la contraseña cifras fáciles de adivinar, como 123. (Consulte los resultados de la investigación sobre la previsibilidad de las contraseñas.)
Los seres humanos también compartimos defectos que nos hacen vulnerables a la ingeniería social. Revelamos nuestras contraseñas cuando los atacantes se aprovechan de nuestra confianza, nuestro deseo de encajar, nuestro respeto por la autoridad y nuestra disposición a ayudar. De hecho, a veces basta con pedirle a alguien su contraseña para que la revele, como puede verse en este divertido vídeo de Jimmy Kimmel Live.
Dadas estas debilidades de la autenticación basada en contraseñas, los organismos gubernamentales y las asociaciones sectoriales están impulsando la adopción de la autenticación multifactor (MFA). En mayo de 2021, el presidente Biden emitió una orden ejecutiva que exigía a los organismos federales adoptar la MFA en un plazo de 180 días, y la Agencia de Seguridad de Infraestructuras y Ciberseguridad (CISA) está promoviendo la MFA entre las empresas privadas. El Consejo de Normas de Seguridad del Sector de las Tarjetas de Pago exige, mediante su Norma de Seguridad de Datos v4.0 que las organizaciones implementen la MFA para cualquier acceso a los datos de titulares de tarjetas de crédito antes del 31 de marzo de 2025.
Dado que las claras ventajas de la MFA frente a la autenticación basada únicamente en contraseñas están impulsando su adopción, los profesionales de la seguridad deben prestar cada vez más atención a sus inconvenientes, a cómo amplía la superficie de ataque y crea nuevas vulnerabilidades que permiten a los atacantes eludir los controles de autenticación.
La superficie de ataque ampliada de la MFA
La MFA se define como la aplicación de dos o más factores en el proceso de autenticación. Por factor entendemos una forma de demostrar que usted es quien dice ser mediante:
- Conocimiento: algo que sabe, como una contraseña o un número de identificación personal (PIN)
- Posesión: algo que tiene, como un dispositivo móvil, una tarjeta inteligente, un token de hardware o una unidad USB
- Inherencia: algo que eres, según lo determinado mediante datos biométricos como las huellas dactilares, el reconocimiento facial y los patrones del iris
Existen innumerables formas de implementar la autenticación multifactor (MFA), y muchas de ellas abren nuevas superficies de ataque o dejan las aplicaciones expuestas a las mismas vulnerabilidades que caracterizan la autenticación basada únicamente en contraseñas.
MFA basada en SMS
Existen innumerables formas de implementar la MFA, y muchas de ellas abren nuevas superficies de ataque o dejan las aplicaciones expuestas a las mismas vulnerabilidades que caracterizan la autenticación basada únicamente en contraseñas.
La implementación más extendida de la MFA utiliza SMS para enviar a los usuarios una contraseña de un solo uso (OTP), que, en principio, demuestra que poseen un smartphone. Por lo general, el usuario inicia sesión con un nombre de usuario y una contraseña, lo que hace que la aplicación envíe el mensaje de texto. A continuación, el usuario consulta la OTP y la introduce en la aplicación, con lo que completa la autenticación y genera un token de sesión que será válido durante un periodo determinado.
Vulnerabilidades restantes de la autenticación basada en SMS
Implementar el factor de posesión mediante SMS no permite subsanar varias vulnerabilidades importantes. Dado que el usuario introduce la OTP y la contraseña en la aplicación, y que esta envía la OTP de vuelta al servidor a través del mismo canal de comunicación que utiliza, un atacante que haya comprometido la aplicación, el dispositivo o la red podrá acceder a la contraseña, la OTP y el token de sesión.
Atacar el endpoint
Mediante numerosas técnicas consolidadas que siguen siendo habituales, los atacantes toman el control de los dispositivos infectándolos con malware, lo que da lugar a un ataque de intermediario en el navegador (MitB). La ejecución de código en el navegador permite a los atacantes obtener la contraseña y la contraseña de un solo uso (OTP), con las que pueden autenticarse en nombre del usuario. Otra posibilidad es que el atacante deje que se complete la autenticación y, a continuación, robe el identificador de sesión, que podría utilizar para eludir la autenticación y acceder a la cuenta del usuario. (Para conocer las tendencias recientes del malware que infecta los endpoints, consulte el informe de F5 Labs sobre BlackGuard Infostealer.)
Comprometer la aplicación
Al infectar una aplicación, los atacantes pueden hacerse con el control de las cuentas de un gran número de usuarios. Además de comprometer la infraestructura de una empresa mediante malware, los ciberdelincuentes pueden acceder a los datos de la aplicación vulnerando cualquiera de las bibliotecas de código que la componen, una táctica conocida como ataque a la cadena de suministro.
En un ataque a la cadena de suministro de software, el atacante suele dirigirse a un proveedor externo de confianza o a un repositorio de código abierto que proporciona componentes de software (bibliotecas, marcos de trabajo, servicios) a la organización objetivo. El atacante introduce malware en el componente, que posteriormente se integra en la aplicación. Este ataque puede ser eficaz porque no todos los proveedores y equipos de código abierto cuentan con las competencias y los recursos necesarios para aplicar prácticas de programación segura.
Las aplicaciones web y móviles son especialmente vulnerables a los ataques a la cadena de suministro porque suelen incluir decenas de scripts de terceros, muchos de los cuales se añaden dinámicamente a las páginas mediante gestores de etiquetas. Estos scripts, que cambian con frecuencia y sin previo aviso, no pasan por los controles de seguridad del código de la organización. Si un atacante logra comprometer cualquiera de estos scripts, obtiene el control total de la aplicación, lo que significa que puede leer los datos introducidos por el usuario, acceder a los datos almacenados en la memoria del navegador o manipular el recorrido del usuario para redirigirlo sin previo aviso a una aplicación maliciosa.
Estos ataques a la cadena de suministro, como Magecart, han provocado brechas de seguridad que han afectado a cientos de miles de credenciales. Al igual que los ataques MitB, estos ataques a la cadena de suministro son eficaces contra cualquier solución de MFA en la que el token que acredita la posesión se introduce en la aplicación, como suele ocurrir en la mayoría de las implementaciones que utilizan OTP. Dado que el código malicioso lee los datos introducidos por el usuario, podría robar tanto la contraseña estática como la OTP, además de cualquier otra información personal o financiera recopilada por la aplicación.
Escucha en la red
Dado que, con la autenticación basada en SMS, la contraseña, la OTP y el token de sesión viajan a través de la misma conexión de red, esta forma de MFA sigue siendo vulnerable a ataques de tipo «man-in-the-middle» (MitM) que utilizan vectores de ataque habituales, como el envenenamiento de DNS, el envenenamiento de ARP y los puntos de acceso inalámbricos maliciosos.
Ingeniería social
Uno de los ataques más comunes y eficaces contra la MFA basada en SMS utiliza la ingeniería social para llevar a cabo un ataque de intermediario (MitM) mediante proxies de phishing en tiempo real (RTPP).
En este ataque, el ciberdelincuente utiliza correos electrónicos de phishing para engañar al usuario y hacer que visite un sitio controlado por el atacante, donde introduce sus credenciales. Hasta aquí, esta táctica es idéntica a un ataque de phishing destinado al robo de credenciales, pero para eludir la MFA se requiere un paso adicional. Cuando el usuario introduce su nombre de usuario y contraseña en la aplicación, el atacante reenvía esas credenciales a la aplicación objetivo, que a continuación envía al usuario una solicitud de segundo factor. Es muy probable que el usuario apruebe la solicitud porque cree que se está autenticando en una aplicación de confianza; hace clic en el botón de aprobación o introduce el token en la aplicación. En ambos casos, el atacante obtiene acceso a la aplicación. (Para ver una demostración del ataque, consulte este vídeo de Kevin Mitnick).
Gracias a la automatización y a la propensión de los usuarios a caer en estafas de phishing, los ataques RTPP pueden tener éxito a gran escala. (Para obtener más datos sobre el crecimiento de los proxies de phishing en tiempo real, consulte el Informe sobre phishing y fraude de F5 Labs.)
Nuevas vulnerabilidades de la autenticación mediante SMS
Además de no subsanar muchas de las vulnerabilidades existentes de la autenticación basada únicamente en contraseñas, el uso de SMS como segundo factor expone una aplicación a vectores de ataque adicionales.
Robo del dispositivo físico
Quizá el ataque más evidente contra la autenticación basada en la posesión sea el robo de un dispositivo físico. Un delincuente que robe un teléfono podría acceder a una contraseña de un solo uso (OTP) mostrada en una notificación, incluso con el teléfono bloqueado. Muchas víctimas del robo de teléfonos han acabado perdiendo los fondos de sus cuentas bancarias.
Intercambio de SIM (módulo de identidad del abonado)
Los delincuentes no necesitan tener físicamente un teléfono para acceder a las contraseñas de un solo uso (OTP) enviadas por SMS. El intercambio de SIM (https://www.darkreading.com/edge/sim-swapping-attacks-what-they-are-how-to-stop-them), también conocido como secuestro o portabilidad fraudulenta de la SIM, permite a los atacantes eludir la autenticación mediante SMS, la forma de autenticación multifactor (MFA) más utilizada en las aplicaciones orientadas al cliente. En un ataque de intercambio de SIM, el estafador aprovecha la posibilidad que ofrecen los proveedores de servicios de telecomunicaciones de transferir un número de teléfono a otro dispositivo, una función útil cuando un teléfono se pierde o es robado.
El estafador comienza recopilando información personal sobre la víctima mediante búsquedas en Internet, phishing o ingeniería social. Con esta información, convence a la compañía telefónica para que transfiera el número de teléfono de la víctima a la tarjeta SIM del estafador. Otra posibilidad es que el atacante acceda a la cuenta del usuario con el proveedor de servicios mediante el relleno de credenciales, intentos de acceso por fuerza bruta o un ataque de diccionario.
Al hacerse con el control del servicio telefónico de la víctima, el estafador recibirá todos los SMS y las llamadas de voz destinados a ella. Esto le permite interceptar cualquier código de seguridad enviado por mensaje de texto.
Dispositivos de token físicos
Los tokens de hardware son dispositivos especializados, normalmente bastante pequeños, que muestran una contraseña de un solo uso (OTP), que el usuario introduce en una aplicación para autenticarse. Estos dispositivos permiten demostrar su posesión sin que la aplicación tenga que comunicarse con el usuario, lo que elimina una de las principales vulnerabilidades de la autenticación mediante SMS.
En lugar de depender del envío de la OTP al usuario en cada inicio de sesión, el dispositivo genera una secuencia de OTP a partir de un valor semilla inicial y un algoritmo. El valor semilla se comparte entre el dispositivo y el servicio de autenticación durante la configuración. Al valor semilla se le añade un contador que se incrementa con un evento, como una solicitud de inicio de sesión, o tras un intervalo de tiempo, como 60 segundos. Estas se denominan, respectivamente, OTP basadas en eventos (EOTP) y OTP basadas en tiempo (TOTP). Tanto las EOTP como las TOTP son tipos de OTP basadas en hash (HOTP), ya que el contador y la semilla se pasan conjuntamente a una función hash que genera una cadena de dígitos aparentemente aleatoria que, si se implementa correctamente, no revela ningún patrón predecible.
Al evitar la necesidad de enviar la OTP por SMS, los tokens de hardware impiden que se pueda interceptar antes de que llegue al usuario mediante técnicas como el intercambio de SIM. Sin embargo, dado que el usuario debe introducir la OTP en la aplicación, que la transmite al servicio de autenticación a través del mismo canal de comunicación que la contraseña, se mantienen la mayoría de las demás vulnerabilidades de la autenticación basada en SMS. El atacante puede obtener la contraseña y la OTP comprometiendo el dispositivo, la red o la aplicación de las mismas formas que en el caso de las OTP enviadas por SMS.
El ataque más común contra la autenticación basada en SMS, los proxies de phishing en tiempo real, funciona igual de bien con las OTP generadas en dispositivos físicos, ya que se engaña al usuario para que introduzca la OTP en el sitio falso, independientemente de si esta aparece en un teléfono o en un dispositivo especializado.
Aunque los dispositivos de hardware eliminan la posibilidad de que los atacantes capturen la OTP mientras se transmite al usuario, estos dispositivos dependen de valores semilla que pueden verse comprometidos. Los atacantes pueden acceder al valor semilla obteniendo acceso físico a los dispositivos (véase la mención de un ataque con microscopio electrónico en Más de 12 formas de hackear la MFA), comprometiendo la base de datos utilizada por el servicio de autenticación o interceptando el proceso de configuración en el que el dispositivo y el servicio de autenticación acuerdan el valor semilla.
Aplicaciones de autenticación
Las aplicaciones de autenticación pueden funcionar de forma muy similar a los tokens de hardware, generando una secuencia de OTP a partir de una semilla inicial y un algoritmo, lo que evita tener que transmitir la semilla a través de un canal vulnerable. Sin embargo, también pueden ir un paso más allá y utilizar un canal alternativo para transmitir la OTP. En este caso, tras verificar correctamente el nombre de usuario y la contraseña, el servicio de autenticación envía una notificación push a la aplicación de autenticación para solicitar al usuario que apruebe la petición. Una vez aprobada, la aplicación de autenticación envía la OTP directamente al servicio de autenticación, sin que el usuario tenga que introducirla en la aplicación. La comunicación entre la aplicación de autenticación y el servicio de autenticación se realiza a través de una conexión independiente.
El uso de un canal de comunicación alternativo impide que un atacante acceda a la OTP poniendo en riesgo la aplicación, ya que la OTP nunca se introduce en ella. También resulta más difícil obtener tanto la contraseña como la OTP poniendo en riesgo la conexión de red, porque ambas se transmiten a través de canales seguros distintos. Sin embargo, poner en riesgo el dispositivo podría permitir que un atacante accediera tanto a la contraseña como a la OTP si la propia aplicación y la aplicación de autenticación se ejecutan en el mismo dispositivo. (Consulte el informe sobre software malicioso de F5 Labs que compromete Google Authenticator.)
Lamentablemente, las aplicaciones de autenticación no impiden el uso de proxies de phishing en tiempo real. Mediante un mensaje de texto de phishing, se sigue engañando al usuario para que introduzca su nombre de usuario y contraseña en un sitio web falso. Al introducir sus credenciales, la aplicación enviará una solicitud a la aplicación de autenticación. Como el usuario cree que está iniciando sesión en una aplicación de confianza, es probable que apruebe la solicitud, con lo que se completa la autenticación. Aunque el atacante nunca llega a ver la contraseña de un solo uso (OTP), su proxy pasa a controlar una sesión autenticada, lo que le permite acceder a la cuenta del usuario. (Para obtener más información sobre los proxies de phishing en tiempo real (RTPP) y la autenticación mediante notificaciones push, consulte este artículo sobre plataformas de phishing en Hacker News).
Además, la facilidad de uso de las aplicaciones de autenticación ha creado otra vía para que los atacantes puedan eludir la MFA mediante ingeniería social. En los ataques de bombardeo de MFA o de fatiga de MFA, el atacante engaña a la víctima para que le facilite su código de autenticación enviándole múltiples solicitudes fraudulentas. Por lo general, el atacante utiliza herramientas automatizadas para generar un gran número de solicitudes y abrumar a la víctima con una cantidad excesiva de notificaciones o mensajes en los que se le pide que introduzca su código de autenticación.
Aunque el bombardeo de MFA puede engañar a un usuario para que introduzca una contraseña de un solo uso (OTP) recibida por SMS o generada por un dispositivo físico, resulta especialmente eficaz contra las aplicaciones de autenticación, ya que el usuario puede detener fácilmente la avalancha de solicitudes con solo pulsar un botón.
Autenticación biométrica
Existen aún más formas de implementar la autenticación biométrica que la autenticación basada en la posesión. No solo hay numerosos métodos para activar la solicitud de autenticación y comunicar esos datos al servicio de autenticación, sino que también existen muchas modalidades biométricas, desde las huellas dactilares hasta el escaneo del iris. El hardware necesario para realizar el escaneo puede estar integrado en el dispositivo que ejecuta la aplicación, como una cámara con lector de huellas dactilares en un portátil, o puede requerir hardware independiente. El lector biométrico puede estar controlado por el sistema operativo o por una aplicación especializada. Dadas estas variaciones en la implementación, resulta difícil modelar todas las vulnerabilidades. Sin embargo, es importante tener en cuenta que, pese a la reputación de la autenticación biométrica como opción más segura, sigue presentando vulnerabilidades muy claras.
De hecho, uno de los métodos más habituales para eludir el factor de posesión, los proxies de phishing en tiempo real, también puede utilizarse para eludir la autenticación biométrica. Cuando el usuario inicia sesión en una aplicación controlada por un atacante creyendo que se trata de una aplicación de confianza, esta utilizará sus credenciales para iniciar sesión en la aplicación en su nombre, lo que activará la solicitud de autenticación biométrica. Mientras el usuario crea que se está autenticando en la aplicación real, es probable que continúe con la autenticación biométrica, dando así al atacante acceso a la cuenta. (El estándar FIDO2 WebAuthn, creado por el W3C, incluye protección contra el phishing, aunque todavía no está ampliamente adoptado por las aplicaciones web.)
La posibilidad de vulnerar la autenticación biométrica comprometiendo el dispositivo final, la aplicación o la red depende de la implementación concreta. Si el sistema de autenticación biométrica se ejecuta en el mismo dispositivo que la aplicación, comprometer dicho dispositivo podría vulnerar la autenticación. Si la aplicación gestiona el proceso de autenticación biométrica, comprometerla podría vulnerar la autenticación. Y si la autenticación biométrica se transmite a través del mismo canal de comunicación que utiliza la aplicación, comprometer la red podría vulnerar la autenticación. En resumen, la autenticación biométrica requiere un modelado de amenazas detallado y específico para cada implementación.
La autenticación biométrica presenta una vulnerabilidad específica: la posibilidad de copiarla y suplantarla. Pensemos en las huellas dactilares. Las dejamos por todas partes, en casi cualquier superficie lisa que tocamos. Las dejamos en los pomos de las puertas, en restaurantes y en la basura. Recoger huellas dactilares de estas superficies es muy sencillo; todos lo hemos visto infinidad de veces en series policíacas. Reproducirlas es igual de sencillo, ya sea con una impresora 3D o incluso con ositos de gominola.
En el caso de otras formas de biometría, existe una competición constante entre los investigadores de seguridad que revelan cómo se pueden suplantar los datos biométricos y los proveedores que desarrollan tecnología contra la suplantación. Las máscaras 3D han engañado a los lectores faciales de los aeropuertos, aunque estas máscaras pueden detectarse mediante pruebas de presencia real y otros métodos. Del mismo modo, los atacantes han utilizado grabaciones de voz con síntesis de voz mediante deepfakes para eludir los sistemas de reconocimiento de voz, aunque quizá sea posible detectar estas suplantaciones gracias a las sutiles distorsiones que introducen los dispositivos de grabación. Incluso las imágenes del iris pueden reproducirse y suplantarse mediante lentes de contacto cosméticas o un ojo artificial, aunque diversas técnicas contra la suplantación —incluidas las diferencias de iluminación entre el tejido humano y los materiales sintéticos— pueden detectarla. En resumen, la seguridad de los lectores biométricos dependerá del estado actual de las tecnologías de suplantación y contra la suplantación.
Aunque viviéramos como ermitaños y evitáramos tocar físicamente cualquier superficie, los atacantes podrían robar nuestros datos biométricos. Mediante software malicioso, ingeniería social y la explotación de vulnerabilidades sin parchear, los atacantes han robado miles de millones de nombres de usuario y contraseñas. Si pueden vulnerar las bases de datos que almacenan nuestras contraseñas, sin duda también accederán a las que almacenan nuestros datos biométricos. Y una vez que una sola brecha de seguridad exponga nuestros datos biométricos, puede que ya no sea seguro utilizarlos para autenticarnos, dependiendo de si es posible detectar su suplantación.
El hecho de que no podamos cambiar fácilmente las características que miden los sistemas biométricos agrava el riesgo de seguridad que suponen la copia y la suplantación. Cuando un atacante roba una contraseña, podemos cambiarla. Si roba un dispositivo OPT o un teléfono móvil, podemos sustituirlo y restablecer la semilla. Sin embargo, si un atacante obtiene acceso a nuestra huella dactilar, la huella de la palma de la mano, la imagen facial o cualquier otra característica biológica y aprende a suplantarlas eficazmente, no podemos cambiar estas características físicas sin sufrir un dolor considerable.
Mejora de la seguridad de la autenticación multifactor
Aunque la MFA supone una mejora con respecto a la autenticación de un solo factor basada en contraseñas, sigue siendo vulnerable, al menos en las formas de implementación más extendidas actualmente. Por tanto, en lugar de considerar la MFA como el final del camino hacia la seguridad, hay que verla como un nuevo comienzo. Las prácticas recomendadas de seguridad de las aplicaciones siguen siendo tan pertinentes como siempre, entre ellas el modelado de amenazas, las revisiones de código, el análisis de vulnerabilidades, las pruebas de penetración y los ejercicios de red teaming. Al modelar las amenazas, se debe examinar cada aspecto del proceso de autenticación y gestión de sesiones, teniendo en cuenta los numerosos puntos de ataque, desde el almacén de identidades hasta la seguridad física, de la red y de los datos. Es probable que los ciberataques se dirijan al eslabón más débil. En concreto, las vulnerabilidades de la MFA ponen de manifiesto varias áreas clave que requieren mayor atención: mitigar la automatización, protegerse frente a los ataques a la cadena de suministro de JavaScript y tener en cuenta el contexto de riesgo.
Elimina los bots de tu red
Los ciberdelincuentes recurren a bots para ampliar el alcance de varios ataques importantes contra la MFA, como el relleno de credenciales, los proxies de phishing en tiempo real y el bombardeo de MFA. Por tanto, mitigar los bots es fundamental para proteger todas las formas de MFA.
En los ataques de relleno de credenciales, según la definición de OWASP, los delincuentes obtienen credenciales robadas en filtraciones anteriores, normalmente comprándolas en la web oscura, y las prueban en los sistemas de inicio de sesión de otras aplicaciones. Dado que se han expuesto miles de millones de credenciales en filtraciones, los delincuentes maximizan sus beneficios automatizando las pruebas con bots para poder probar cantidades ingentes de credenciales. La Oficina Federal de Investigación, la Comisión de Bolsa y Valores y la Fiscalía General de Nueva York han advertido sobre los riesgos financieros del relleno de credenciales, y la Asamblea Global de Privacidad, una asociación que agrupa a más de 130 organismos reguladores, declaró que el relleno de credenciales constituye una amenaza mundial para la privacidad.
Prevenir el relleno de credenciales es tan importante para la autenticación multifactor (MFA) como para la autenticación basada únicamente en contraseña. El objetivo de la MFA es precisamente utilizar más de un factor, pero, si no se protege el primero, solo queda uno. Una vez que un atacante descubre la contraseña de un usuario, la autenticación de dos factores se convierte en autenticación de un solo factor y se pierde la defensa en profundidad.
Además, mitigar la actividad de los bots es fundamental, ya que los delincuentes los utilizan para atacar mucho más que contraseñas. De hecho, los bots son una herramienta clave para lanzar con éxito ataques de proxy de phishing en tiempo real, que constituyen uno de los mecanismos más habituales para eludir la MFA. Cuando un usuario cae en la trampa de un correo electrónico de phishing que lo induce a introducir sus credenciales en un sitio falso, el atacante debe reenviar esas credenciales a la aplicación de destino para generar la solicitud de MFA, ya sea mediante SMS, una aplicación de autenticación o sofisticados sistemas biométricos. Para reenviar la solicitud rápidamente y a gran escala, el delincuente debe automatizar el proceso, lo que significa que un bot la enviará a la aplicación. (Para obtener una visión general de los servicios que utilizan bots para eludir las OTP, consulte el artículo de Krebs on Security «El auge de los bots de interceptación de contraseñas de un solo uso»). Esto significa que, al impedir que bots no deseados envíen credenciales, una organización puede reducir drásticamente la eficacia de los proxies de phishing en tiempo real y proteger mejor tanto los factores de autenticación de posesión como los inherentes.
Otra forma evidente en la que los delincuentes utilizan bots para atacar la MFA es mediante el bombardeo de MFA. En este contexto, el bombardeo consiste en generar un gran volumen de solicitudes de inicio de sesión para provocar tantas solicitudes de autenticación que el usuario acabe aceptando, ya sea por error o simplemente para dejar de recibirlas. Para generar suficientes solicitudes dirigidas a un gran número de usuarios y lograr que el ataque resulte rentable, el delincuente tendrá que automatizar el proceso, lo que, una vez más, significa que las solicitudes de inicio de sesión que lleguen a su sitio web serán creadas por bots.
Como ilustran estos ejemplos, prácticamente cualquier ataque contra la MFA dependerá de bots para tener éxito a gran escala, lo que significa que las organizaciones que implementen la MFA deben tomarse en serio la mitigación de bots.
Por desgracia, muchas organizaciones no son conscientes del grado de sofisticación de los bots ni de la determinación de los delincuentes para modificarlos con gran frecuencia a fin de eludir la detección. En cambio, demasiadas empresas confían en técnicas de mitigación de bots que ya no funcionan, como los CAPTCHA, las listas de bloqueo de direcciones IP y las huellas digitales de las cabeceras HTTP.
CAPTCHA sirve de poco para protegerse de los bots, aparte de molestar a los clientes reales, porque los bots pueden sortear estos desafíos mediante servicios económicos de resolución de CAPTCHA que recurren al aprendizaje automático y a granjas de clics. Basta con buscar en Internet resolución de CAPTCHA para encontrar al menos una docena de servicios que compiten en precio y rapidez. Para obtener más información sobre estos servicios, consulte un artículo de Dan Woods, director de Inteligencia de F5, titulado Fui un solucionador humano de CAPTCHA. Y lo que es aún más interesante: ChatGPT logró sortear un CAPTCHA mediante ingeniería social, convenciendo a una persona para que lo resolviera en su nombre.
Para las organizaciones que dependen de listas de bloqueo de direcciones IP basadas en WAF para mitigar la actividad de los bots, la tarea resulta igual de abrumadora. Existen servicios que ofrecen a los creadores de bots decenas de millones de direcciones IP residenciales destinadas a eludir la detección de bots. Estos servicios se anuncian como proxies residenciales rotativos: el bot envía solicitudes HTTP al proxy, de forma similar a como muchos navegadores corporativos envían solicitudes a través de proxies directos, y el servicio cambia continuamente la dirección IP pública utilizada para enviar la solicitud al sitio web o a la API. En el pasado, los bots solían utilizar proxies de centros de datos, a menudo procedentes de servicios en la nube, que son bien conocidos y fáciles de identificar. Sin embargo, estos nuevos servicios de proxy utilizan direcciones IP residenciales de la misma zona geográfica que sus clientes. Dado que cada dirección IP podría representar simultáneamente a un bot o a un cliente legítimo debido al uso de NAT por parte de los proveedores de servicios de Internet (ISP), no es viable bloquear todas estas direcciones IP sin rechazar también a sus clientes reales. (Para consultar una investigación sobre cómo obtienen estos servicios dichas direcciones IP, véase el artículo Tu teléfono es mi proxy.)
Intentar detectar bots basándose en diferencias en el orden de las cabeceras tampoco funciona ya, porque los bots han descubierto el truco. De hecho, varios proyectos de código abierto, entre ellos stealth-puppeteer y undetected-chromedriver, se encargan de establecer correctamente el orden de las cabeceras, lo que facilita eludir los sistemas de detección al utilizar estos populares frameworks de automatización.
Hoy en día, detectar bots avanzados requiere una recopilación avanzada de señales, supervisión ininterrumpida, aprendizaje automático y una respuesta rápida ante los cambios en las herramientas de los bots. Sin una solución específica de gestión de bots que detecte estos cambios y responda rápidamente a ellos, los bots permitirán a los delincuentes ampliar eficazmente los ataques contra la autenticación multifactor (MFA).
Protéjase contra los ataques a la cadena de suministro de JavaScript
Prácticamente cualquier forma imaginable de MFA fallará si la aplicación se ve comprometida. Si el atacante inserta código en una aplicación, todo está perdido. El atacante puede capturar credenciales y otros datos de autenticación multifactor, secuestrar sesiones robando sus identificadores o extraer datos directamente de la aplicación. Dado que las aplicaciones web modernas suelen estar compuestas por más de 20 archivos JavaScript, en su mayoría de terceros y no revisados por el equipo de seguridad de aplicaciones de la organización, el riesgo de que una aplicación se vea comprometida mediante ataques a la cadena de suministro de JavaScript es mayor de lo que suele creerse.
Los protocolos de seguridad actuales del lado del cliente son demasiado estáticos para proteger las aplicaciones web dinámicas de hoy en día. La Política de Seguridad de Contenidos (CSP) restringe las acciones de los scripts de formas que podrían evitar ataques a la cadena de suministro de JavaScript, pero también podría afectar con demasiada facilidad al funcionamiento de un sitio si un proveedor externo actualiza dinámicamente un script de manera contraria a las restricciones de la CSP. Aunque puede ser deseable que un script falle si infringe una política de seguridad, ese fallo en producción podría afectar drásticamente a los clientes. (Véase «¿Por qué está fallando la CSP?»). La Integridad de Subrecursos (SRI), otro protocolo de seguridad web, es aún menos viable para el contenido dinámico de terceros, ya que exige actualizar las etiquetas de los scripts con el valor hash cada vez que cambia un script, algo imposible si los cambios se producen sin previo aviso. De hecho, la SRI está diseñada para impedir precisamente el tipo de actualizaciones de scripts del que dependen la mayoría de las aplicaciones modernas.
Ante la falta de controles claros para eliminar las vulnerabilidades de la cadena de suministro de JavaScript, las organizaciones deben buscar soluciones creativas que les permitan, al menos, supervisar el riesgo. Pueden documentar mejor los scripts de su sitio web y clasificarlos según su nivel de riesgo en función de su origen y frecuencia de cambio. Los scripts añadidos mediante gestores de etiquetas deben someterse a revisiones periódicas para evaluar el riesgo. Existen herramientas de supervisión que permiten hacer un seguimiento del comportamiento de los scripts mediante monitorización sintética, CSP en modo de generación de informes o agentes basados en JavaScript que se ejecutan en el navegador.
Dado que los scripts de terceros cambian con tanta frecuencia y sin que exista la posibilidad de someterlos a una revisión de seguridad, es importante que las organizaciones supervisen continuamente sus aplicaciones para detectar comportamientos sospechosos, como scripts que leen datos confidenciales y los transfieren a dominios que no son de confianza. Sin esta supervisión de los ataques a la cadena de suministro de JavaScript, ningún tipo de MFA mantendrá a salvo a los usuarios.
Reconozca a los usuarios legítimos conocidos y cuestione los comportamientos sospechosos
El objetivo de la MFA debe ser mejorar la seguridad, no imponer a los clientes medidas de seguridad innecesarias que solo sirven para aparentar. Al adaptar los requisitos de inicio de sesión al riesgo contextual, las organizaciones pueden evitar penalizar continuamente a los clientes recurrentes de gran valor con requisitos de MFA y, en su lugar, facilitarles el proceso mediante sesiones de usuario prolongadas, ofreciéndoles una experiencia personalizada y sin esfuerzo, del mismo modo que la TSA agiliza el paso de los viajeros de confianza con TSA PreCheck.
El riesgo contextual tiene muchas dimensiones:
- Geografía: según las direcciones IP, ¿el usuario está iniciando sesión desde su ubicación habitual?
- ASN (número de sistema autónomo): según la dirección IP, ¿el usuario está iniciando sesión desde el mismo proveedor de servicios de Internet de siempre, quizá uno asociado a su casa, trabajo o cafetería favorita?
- Dispositivo: ¿El usuario está iniciando sesión desde el mismo dispositivo de siempre?
- Hora/día: ¿El usuario inicia sesión a la misma hora del día o el mismo día de la semana que de costumbre, quizás por la mañana para realizar sus operaciones bancarias y por la noche para jugar?
- Comportamiento: ¿Escribe el usuario a la misma velocidad de siempre, mueve el ratón siguiendo los mismos patrones y copia y pega de forma similar?
- Funcionalidad: ¿El usuario utiliza las mismas funciones que de costumbre?
Si el usuario cuenta con un historial demostrado de buen comportamiento y accede a un sitio desde el mismo lugar, con el mismo dispositivo, a la misma hora del día, mostrando un comportamiento similar y utilizando las funciones habituales, puede que ni siquiera sea necesario exigirle que inicie sesión; en su lugar, se puede realizar una autenticación silenciosa continua para prolongar la sesión y ofrecerle una mayor comodidad. Si el contexto se desvía de lo habitual, lo que indica un mayor riesgo, puede añadir políticas adaptativas a su aplicación para aumentar gradualmente los requisitos de seguridad: exigir el inicio de sesión con contraseña, requerir la autenticación de dos factores (2FA), marcar una cuenta para su revisión, avisar al usuario por SMS o correo electrónico sobre el inicio de sesión, o bloquear la cuenta para obligar al usuario a ponerse en contacto con el servicio de asistencia.
Con demasiada frecuencia, la duración de la sesión se establece en un periodo fijo independientemente del riesgo contextual, lo que permite que cualquier persona que disponga de un token de sesión siga accediendo a los datos para los que el usuario está autorizado, sin tener en cuenta el riesgo de secuestro de la sesión. Un enfoque más seguro consiste en seguir los principios de confianza cero: dar por hecho que se ha producido una vulneración y supervisar continuamente. Si el contexto cambia durante una sesión, finalícela antes de tiempo y solicite autenticación adicional, con un nivel de exigencia que dependerá de cuánto haya cambiado el contexto y de la sensibilidad de los datos.
Conclusión
Siguiendo el tópico de que la seguridad es un viaje, la MFA ha abierto varias bifurcaciones en el camino y ha aportado opciones adicionales que, si se implementan correctamente, mejoran la seguridad de forma significativa. Sin embargo, ninguna modalidad de MFA, independientemente del número de factores, de lo bien implementada que esté o de su coste, nos permite saltarnos el trayecto para llegar al destino. Sin duda, veremos más proclamas sobre la muerte de las contraseñas y más revuelo en torno a nuevas técnicas de MFA que supuestamente harán que la autenticación sea segura de una vez por todas, pero los atacantes decididos seguirán encontrando formas de eludir las nuevas tecnologías.
En su camino hacia una mayor protección de las aplicaciones críticas, cuenta con F5 como aliado. Los servicios de F5 Distributed Cloud incluyen Bot Defense para mitigar los bots, Client-Side Defense para supervisar los ataques a la cadena de suministro de JavaScript y Authentication Intelligence para reconocer a los usuarios recurrentes y cuantificar el riesgo contextual. Con el apoyo de F5, puede garantizar la seguridad de la MFA y, al mismo tiempo, optimizar la experiencia del cliente. Obtenga más información sobre los servicios de F5 Distributed Cloud y regístrese para hablar con nuestro equipo.
PUBLICADO EL 26 DE JUNIO DE 2023