Nuevas vulnerabilidades de la autenticación basada en SMS

Además de no poder cerrar muchas de las vulnerabilidades existentes de la autenticación basada únicamente en contraseña, el uso de SMS como segundo factor expone una aplicação a vectores de ataque adicionales.

Robo de dispositivo físico

Quizás el ataque más obvio contra la autenticación basada en posesión es el robo de un dispositivo físico. Un delincuente que roba un teléfono podría obtener acceso a una OTP que se muestra en una notificación, incluso con el teléfono bloqueado. Muchas víctimas de robo de teléfonos han perdido los fondos de sus cuentas bancarias.

Intercambio de SIM (Módulo de Identidad del Suscriptor)

Los delincuentes no necesitan la posesión física real de un teléfono para obtener acceso a las OTP enviadas por mensaje de texto. El intercambio de SIM , también conocido como secuestro de SIM o portabilidad de SIM, permite a los atacantes eludir la autenticación basada en SMS, que es la forma más popular de MFA utilizada en aplicaciones orientadas al cliente. En un ataque de intercambio de SIM, el estafador explota la capacidad de los proveedores de servicios de telecomunicaciones de transferir un número de teléfono a otro dispositivo, una característica que resulta beneficiosa cuando se pierde o se roba un teléfono.

El estafador comienza recopilando información personal de la víctima a través de investigación en línea, phishing o ingeniería social. Con esta información, el atacante convence a la compañía telefónica para que transfiera el número de teléfono de la víctima a la SIM del estafador. O bien, el atacante podría entrar en la cuenta del usuario con el proveedor de servicios utilizando credential stuffing, adivinación por fuerza bruta o un ataque de diccionario.

Al controlar el servicio telefónico de la víctima, el estafador recibirá todos los SMS y llamadas de voz destinados a ella. Esto permite al estafador interceptar cualquier token de seguridad enviado vía mensaje de texto.

Dispositivos de token de hardware

Los dispositivos de token de hardware son dispositivos especializados, normalmente bastante pequeños, que muestran un OTP, que el usuario escribe en una aplicação para su autenticación. Estos dispositivos proporcionan un medio para demostrar posesión sin requerir comunicación de la aplicação al usuario, lo que elimina una de las principales vulnerabilidades de la autenticación basada en SMS.

En lugar de confiar en enviar la OTP al usuario para cada inicio de sesión, el dispositivo genera un flujo de OTP basado en un valor inicial y un algoritmo. El valor de la semilla en sí se comparte entre el dispositivo y el servicio de autenticación durante la configuración. El valor de la semilla se aumenta con un contador que se incrementa con un evento, como una solicitud de inicio de sesión, o una duración de tiempo como 60 segundos . A estos los llamamos respectivamente OTP basada en eventos (EOTP) y OTP basada en tiempo (TOTP). EOTP y TOTP son ambos tipos de OTP basado en hash (HOTP) porque el contador y la semilla juntos se pasan a una función hash que genera una cadena de dígitos aparentemente aleatoria, que, cuando se implementa correctamente, no revela un patrón predecible.

Al evitar la necesidad de enviar el OTP mediante texto, los tokens de hardware hacen imposible capturar el OTP antes de que llegue al usuario a través de medios como el intercambio de SIM. Sin embargo, debido a que el usuario debe ingresar el OTP en la aplicación, que transporta el OTP al servicio de autenticación utilizando el mismo canal de comunicación que la contraseña, la mayoría de las otras vulnerabilidades de la autenticación basada en SMS permanecen. El atacante puede obtener acceso a la contraseña y al OTP comprometiendo el punto final, la red o la aplicação de las mismas formas que lo haría con los OTP enviados por mensaje de texto.

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 los OTP generados en dispositivos de hardware, ya que se engaña al usuario para que escriba el OTP en un sitio falso independientemente de si el OTP aparece en un teléfono o en un dispositivo especializado.

Si bien los dispositivos de hardware eliminan la posibilidad de que los atacantes capturen el OTP en tránsito hacia el usuario, los dispositivos dependen de valores de semilla que pueden verse comprometidos. Los atacantes pueden acceder al valor de la semilla obteniendo acceso físico a los dispositivos (ver la mención de un ataque de microscopio electrónico en 12+ formas de hackear MFA ), comprometiendo la base de datos utilizada por el servicio de autenticación o interceptando el proceso de configuración en el que se acuerda el valor de la semilla entre el dispositivo y el servicio de autenticación.

Aplicaciones de autenticación

Las aplicaciones de autenticación pueden funcionar de forma muy similar a los tokens de hardware, generando un flujo de OTP basado en una semilla y un algoritmo iniciales, lo que evita la necesidad de comunicar la semilla a través de un canal vulnerable, pero también pueden ir un paso más allá al utilizar un canal alternativo para comunicar la OTP. En este escenario, luego de la verificación exitosa de un nombre de usuario y una contraseña, el servicio de autenticación envía una notificación push a la aplicación de autenticación, que solicita al usuario que apruebe la solicitud. Tras la aprobación, la aplicación de autenticación envía el OTP directamente al servicio de autenticación sin necesidad de que el usuario lo escriba en la aplicação. 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 distinta.

El uso de un canal de comunicación alternativo significa que un atacante no puede acceder al OTP comprometiendo la aplicação, ya que el OTP nunca se ingresa en la aplicação. También es más difícil obtener la contraseña y el OTP al comprometer la conexión de red porque la contraseña y el OTP se envían a través de canales seguros distintos. Sin embargo, comprometer el punto final podría permitir que un atacante acceda tanto a la contraseña como al OTP si la aplicação en sí y la aplicación de autenticación se ejecutan en el mismo dispositivo. (Consulte el informe de F5 Labs sobre malware que compromete Google Authenticator).

Lamentablemente, las aplicaciones de autenticación no impiden el uso de servidores proxy de phishing en tiempo real. El usuario todavía es engañado para que ingrese su nombre de usuario y contraseña en un sitio falso a través de un mensaje de texto de phishing. Al ingresar sus credenciales, la aplicação enviará una solicitud a la aplicación de autenticación. Dado que el usuario cree que está iniciando sesión en una aplicação confiable, es probable que apruebe la solicitud, lo que completa la autenticación. Aunque el atacante nunca ve el OTP, el proxy del atacante ahora tendrá control sobre una sesión autenticada, lo que le dará al atacante acceso a la cuenta del usuario. (Para obtener más información sobre RTPP y la autenticación de 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 otro medio por el cual los atacantes pueden vencer la MFA a través de la ingeniería social. En los ataques de bombardeo MFA o ataques de fatiga MFA, el atacante engaña al objetivo para que le dé su código de autenticación enviándole múltiples solicitudes fraudulentas de código. El atacante generalmente utiliza herramientas automatizadas para generar una gran cantidad de solicitudes, abrumando a la víctima con una cantidad excesiva de notificaciones o mensajes pidiéndole que ingrese su código de autenticación.

Si bien el bombardeo de MFA puede engañar a un usuario para que ingrese un OTP desde un mensaje SMS o un dispositivo de hardware, es particularmente efectivo contra aplicaciones de autenticación porque el usuario puede detener fácilmente el flujo de solicitudes con solo presionar un botón.

Autenticación biométrica

Hay incluso más formas de implementar la autenticación biométrica que la autenticación basada en posesión. No sólo existen 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 formas de biometría, desde huellas dactilares hasta escaneos de iris. El hardware necesario para realizar el escaneo puede estar incorporado al dispositivo que ejecuta la aplicação, como una cámara con lector de huellas dactilares en una computadora portátil, o requerir hardware separado. El lector biométrico puede ser controlado por el sistema operativo o una aplicação especializada. Dadas estas variaciones en la implementación, es difícil modelar cada vulnerabilidad. Sin embargo, es importante darse cuenta de que, a pesar de la reputación de la autenticación biométrica de ofrecer una mayor seguridad, todavía existen vulnerabilidades muy claras en la autenticación biométrica.

De hecho, uno de los métodos más populares para eludir el factor de posesión, los servidores proxy de phishing en tiempo real, también se pueden utilizar para eludir la biometría. Una vez que el usuario inicia sesión en una aplicação controlada por un atacante, pensando que es una aplicação confiable, esa aplicação utilizará las credenciales para iniciar sesión en la aplicação en nombre del usuario, lo que activará la solicitud de autenticación biométrica. Mientras el usuario crea que se está autenticando en la aplicação real, es probable que proceda con la autenticación biométrica, dándole al atacante acceso a la cuenta. (El estándar FIDO2 WebAuthn , creado por el W3C, incluye protección contra phishing, aunque todavía no ha sido ampliamente adoptado por las aplicações web.)

La posibilidad de anular la autenticación biométrica comprometiendo el punto final, la aplicação o la red depende de la implementación específica. En la medida en que el sistema de autenticación biométrica se ejecuta en el mismo dispositivo que la aplicação, comprometer el punto final podría romper la autenticación. En la medida en que la aplicação gestiona el proceso de autenticación biométrica, comprometer la aplicación podría romper la autenticación. Y en la medida en que la autenticación biométrica se envía a través del mismo canal de comunicación utilizado por la aplicação, comprometer la red puede romper la autenticación. En resumen, la autenticación biométrica requiere un modelado de amenazas detallado específico para la implementación.

La autenticación biométrica abre una clara vulnerabilidad a la copia y la suplantación de identidad. Considere las huellas dactilares. Los dejamos por todos lados, en casi todas las superficies lisas que tocamos. Los dejamos en los pomos de las puertas, en los restaurantes, en la basura. Recoger huellas dactilares de estas superficies es trivial; todos lo hemos visto innumerables veces en los dramas policiales. Replicar huellas dactilares es igualmente trivial utilizando cualquier cosa, desde una impresora 3D hasta ositos de goma .

En el caso de otras formas de biometría, existe una competencia en curso entre los investigadores de seguridad que revelan cómo se puede falsificar la biometría y los proveedores que desarrollan tecnología anti-falsificación. Las máscaras 3D han engañado a los lectores faciales en los aeropuertos, aunque estas máscaras pueden detectarse mediante controles de vida y otros métodos. Asimismo, los atacantes han utilizado grabaciones de voz con síntesis de voz deepfake para eludir los sistemas de reconocimiento de voz, aunque es posible detectar estas falsificaciones a través de las sutiles distorsiones añadidas por los dispositivos de grabación. Incluso las imágenes del iris pueden reproducirse y falsificarse utilizando lentes de contacto cosméticos o un ojo artificial, aunque varias técnicas anti-falsificación (incluidas distinciones de iluminación entre tejido humano y materiales sintéticos) pueden detectar la falsificación. En resumen, la seguridad de los lectores biométricos dependerá del estado actual de la tecnología contra la suplantación de identidad y la prevención de la misma.

Incluso si viviéramos vidas de ermitaños y evitáramos tocar físicamente las superficies, los atacantes podrían robar nuestros datos biométricos. Mediante malware, ingeniería social y explotación de vulnerabilidades sin parchear, los atacantes han robado miles de millones de nombres de usuario y contraseñas. Si los atacantes pueden violar las bases de datos que almacenan nuestras contraseñas, con seguridad violarán las bases de datos que almacenan nuestros datos biométricos. Y una vez que una sola violación expone nuestros datos biométricos, puede que no sea seguro usarlos para autenticación, dependiendo de si se puede detectar su falsificación.

Lo que agrava el riesgo de seguridad que supone la copia y la suplantación es el hecho de que no podemos cambiar fácilmente las características que miden los datos biométricos. Cuando un atacante roba una contraseña, podemos cambiarla. Si un atacante roba un dispositivo OPT o un teléfono celular, podemos reemplazarlo y restablecer la semilla. Sin embargo, si un atacante obtiene acceso a nuestra huella dactilar, huella de la palma, imagen facial o cualquier otra característica biológica y aprende cómo falsificarlas de manera efectiva, no podremos cambiar esas características físicas sin sufrir un dolor significativo.

Mejorar la seguridad de MFA

Si bien la MFA es una mejora con respecto a la autenticación de un solo factor basada en contraseña, aún es vulnerable, al menos en las formas de implementación actualmente populares. Así que, en lugar de pensar en la MFA como el final del recorrido de seguridad, piense en ella como un nuevo comienzo. Las mejores prácticas de seguridad de las aplicaciones siguen siendo tan relevantes como siempre, incluido el modelado de amenazas, las revisiones de código, el escaneo de vulnerabilidades, las pruebas de penetración y el trabajo en equipo rojo. En el modelado de amenazas, observe 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 de datos. Los ciberataques probablemente se dirigirán al eslabón más débil. En particular, las vulnerabilidades de MFA apuntan a algunas áreas clave de preocupación que requieren más atención: mitigación de la automatización, protección contra ataques a la cadena de suministro de JavaScript y consideración del contexto de riesgo.

Eliminar bots de tu red

Los delincuentes dependen de los bots para escalar varios ataques clave a MFA, incluidos el credential stuffing, los servidores proxy de phishing en tiempo real y el bombardeo de MFA, lo que significa que mitigar los bots es clave para proteger todas las formas de MFA.

En los ataques de credential stuffing , según la definición de OWASP , los delincuentes obtienen credenciales robadas de infracciones anteriores, generalmente a través de compras en la red oscura, y prueban esas credenciales comparándolas con los inicios de sesión de otras aplicações. Debido a que miles de millones de credenciales han sido expuestas a través de violaciones, los delincuentes maximizan sus ganancias automatizando las pruebas con bots para poder probar cantidades masivas de credenciales. La Oficina Federal de Investigaciones , la Comisión de Bolsa y Valores y el Fiscal General de Nueva York han emitido advertencias sobre los riesgos financieros del credential stuffing, y la Asamblea Global de Privacidad , una asociación de más de 130 agencias reguladoras, declaró que el credential stuffing es una amenaza global a la privacidad.

Prevenir el credential stuffing es tan importante para la MFA como para la autenticación basada solo en contraseña. El objetivo principal de MFA es el uso de más de un factor, pero si no logras proteger el primer factor, entonces te quedas con un solo factor. 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 los bots es fundamental porque los delincuentes los utilizan para atacar más que solo contraseñas. De hecho, los bots son una herramienta clave para lanzar ataques de phishing en tiempo real exitosos, que son los mecanismos más comunes para derrotar a MFA. Siempre que un usuario es víctima de un correo electrónico de phishing que lo induce a ingresar sus credenciales en un sitio falso, el atacante deberá reenviar esas credenciales a la aplicação de destino para generar la solicitud de MFA, ya sea que esa solicitud involucre SMS, una aplicación de autenticación o biometría sofisticada. Para reenviar la solicitud rápidamente y a gran escala, el delincuente necesitará automatizar el proceso, lo que significa que la solicitud se reenviará a la aplicação desde un bot. (Para obtener una descripción general de los servicios que utilizan bots para evitar OTP, consulte la publicación de Krebs on Security El auge de los bots de intercepción de contraseñas de un solo uso). Esto significa que al evitar que bots no deseados envíen credenciales, una organización puede debilitar la eficacia de los servidores proxy de phishing en tiempo real y proteger de forma más eficaz los factores de autenticación de posesión e inherencia.

Otra forma obvia en que los delincuentes usan bots para atacar a MFA es a través del bombardeo de MFA. En este contexto, el bombardeo implica generar solicitudes de inicio de sesión en grandes volúmenes para desencadenar tantas solicitudes de autenticación que el usuario cumplirá por error o simplemente para detener la molestia. Para generar una cantidad suficientemente grande de solicitudes para muchos usuarios para que el ataque sea rentable, el delincuente necesitará automatizar, lo que nuevamente significa que las solicitudes de inicio de sesión que lleguen a su sitio serán creadas por bots.

Como ilustran estos ejemplos, casi cualquier ataque contra MFA dependerá de bots para tener éxito a gran escala, lo que significa que las organizaciones que implementan MFA deben tomar en serio la mitigación de bots.

Lamentablemente, muchas organizaciones no aprecian la sofisticación de los bots y la determinación de los delincuentes de reequiparlos con gran frecuencia para evitar la detección. En cambio, muchas empresas dependen de técnicas de mitigación de bots que ya no funcionan, como CAPTCHA, listas de direcciones IP denegadas y huellas dactilares de encabezados HTTP.

CAPTCHA no hace mucho por la protección contra bots más allá de molestar a los clientes reales, ya que los bots pueden evitar estos acertijos utilizando servicios de resolución de CAPTCHA de bajo costo que se basan en el aprendizaje automático y en granjas de clics. Simplemente haga una búsqueda en Internet sobre servicios de resolución de CAPTCHA y encontrará al menos una docena que compiten en precio y velocidad. Para obtener una buena información sobre estos servicios, consulte el artículo de Dan Woods, director de inteligencia de F5, titulado I Was a Human CAPTCHA Solver . Aún más interesante, ChatGPT logró eludir el CAPTCHA mediante ingeniería social para que una persona lo resolviera en su nombre.

Para las organizaciones que dependen de listas de denegación de IP basadas en WAF para mitigar los bots, la tarea es igualmente abrumadora. Hay servicios disponibles 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 de reenvío, y el servicio rota continuamente la dirección IP pública utilizada para enviar la solicitud al sitio web o la API. Anteriormente, los bots solían usar proxies de centros de datos, a menudo 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 área geográfica que sus clientes. Debido a que cada dirección IP podría representar simultáneamente un bot o un cliente válido debido al NAT de los proveedores de servicios de Internet (ISP), no es posible bloquear todas estas direcciones IP sin rechazar a sus clientes reales. (Para investigar cómo estos servicios obtienen estas direcciones IP, consulte el documento Su teléfono es mi proxy ).

Intentar detectar bots basándose en las diferencias en el orden de los encabezados tampoco funciona ya porque los bots han descubierto el truco. De hecho, varios proyectos de código abierto, incluidos stealth-puppeteer y undetected-chromedriver , hacen el trabajo de corregir el orden de los encabezados, lo que hace que sea fácil evitar las detecciones al usar estos populares marcos de automatización.

Hoy en día, la detección de bots avanzados requiere una recopilación de señales avanzada, monitoreo 24/7, aprendizaje automático y una reacción rápida a la reestructuración de los bots. Sin una solución de gestión de bots dedicada, una defensa que detecte y reaccione rápidamente a la reestructuración, los bots permitirán a los delincuentes escalar de manera efectiva los ataques contra MFA.

Protéjase de los ataques a la cadena de suministro de JavaScript

Casi cualquier forma de MFA imaginable fallará si se compromete la aplicação . Si el atacante inserta código en una aplicação, se acabó el juego. El atacante puede capturar credenciales y otras entradas de MFA, apoderarse de sesiones robando identificadores de sesión o extraer datos directamente de la aplicação. Debido a que las aplicações web modernas generalmente están compuestas por más de 20 archivos JavaScript , en su mayoría de terceros y no revisados ​​por el equipo de seguridad de aplicação de la organización, el riesgo de que la aplicação se vea comprometida a través de ataques a la cadena de suministro de JavaScript es mayor de lo que a menudo se cree.

Los protocolos de seguridad del lado del cliente existentes son demasiado estáticos para defender las aplicaciones web dinámicas actuales. La Política de seguridad de contenido (CSP) restringe las acciones de los scripts de maneras que podrían prevenir ataques a la cadena de suministro de JavaScript, pero la CSP podría fácilmente dañar la funcionalidad de un sitio si un proveedor externo actualiza un script dinámicamente en formas contrarias a las restricciones de la CSP. Si bien es posible que desees que un script falle si infringe una política de seguridad, esa falla en producción podría afectar dramáticamente a los clientes. (Ver ¿Por qué está fallando la CSP? ) Sub-resource Integrity (SRI), otro protocolo de web security , es aún menos factible para el contenido dinámico de terceros ya que requiere actualizar las etiquetas de script con el valor hash cada vez que cambia un script, lo que no es posible si los cambios ocurren sin previo aviso. De hecho, SRI está destinado a evitar el tipo de actualizaciones de scripts de las que dependen la mayoría de las aplicações modernas.

Sin controles claros para eliminar las vulnerabilidades de la cadena de suministro de JavaScript, las organizaciones necesitan ser creativas para encontrar medios para al menos monitorear el riesgo. Las organizaciones pueden documentar mejor los scripts en su sitio y clasificarlos por riesgo según la fuente y la frecuencia del cambio. Los scripts agregados a través de administradores de etiquetas deben someterse a revisiones periódicas para evaluar el riesgo. Se pueden obtener herramientas de monitoreo que rastrean el comportamiento de los scripts utilizando monitoreo sintético, CSP en modo de informe o agentes basados en JavaScript que se ejecutan en el navegador.

Debido a que los scripts de terceros cambian con tanta frecuencia y sin posibilidad de revisión de seguridad, es importante que las organizaciones monitoreen continuamente sus aplicações para detectar comportamientos sospechosos, como scripts que leen datos confidenciales y los filtran a dominios no confiables. Sin esta supervisión de los ataques a la cadena de suministro de JavaScript, ninguna forma de MFA mantendrá a los usuarios seguros.