Diferentes ataques a la autenticación multifactor que debes tener en cuenta

Seguro que a dia de hoy ya estás utillizando alguno de los múltiples mecanismos de MFA o autenticación multifactor que existen. También se los denomina coloquialmente 2FA o a veces incluso token.

Puede que no lo sepas, pero si recibes SMS para entrar en un portal o servicio, o si tienes que proporcionar un código de una app de tu teléfono, de hecho estás utilizando un mecanismo de autenticación de más de un factor.

Los mecanismos de autenticación multifactor aumentan la seguridad de nuestras cuentas en linea de forma excepcional, de eso no hay duda. Pero esto no debe servir como excusa para relajarnos en todo lo demás porque, de hecho, un MFA es hackeable de múltiples formas.

Podemos resumir los posibles ataques contra autenticación multifactor en 3 métodos: Ingeniería social, ataques ténicos (contra la tecnología que soporta el MFA) o ataques físicos (como robo de biometría). Comúnmente, además, se emplea más de uno de estos en conjunto.

Lecturas recomendadas:

• Algoritmos OCRA, HOTP y TOTP para 2FA
• Estándares FIDO para autenticación multifactor

10 formas en que los mecanismos MFA pueden ser atacados

Cualquier MFA es hackeable. Evidentemente, no todos los mecanismos descritos a continuación aplican a todos los escenarios. Depende de las tecnologías que estemos utilizando en relación al mecanismo multifactor.

Hay que considerar que los hackers no solo podrían atacar el método de autenticación en si mismo -por ejemplo, suplantando un supuesto servicio de envío códigos via SIM Swapping o similar- sino que podrían atacar en diferentes puntos de la cadena de autenticación.

Baste recordar que, sin importar las diferencias método MFA que utilicemos (biometría, monofactor o multifactor), los sistemas de TI conectados a los mismos tenderán a producir los mismos resultados, al emplear sistemas iguales. Ejemplos:

• Tras imputar un token/MFA/smartcard para iniciar sesión en Microsoft Windows, cuando se acepta el método, se generará siempre un token tipo Kerberos/NTLM o LanManager (en desuso este último)
• Al iniciar sesión en una web, el token de autenticación tenderá a ser siempre una cookie (token de sesión) basada en texto.

1. Secuestro de sesión via Phishing

El atacante toma el control de nuestra sesión ya iniciada, a través de uno de los siguientes métodos:

1. Adivinación/reproducción: normalmente tratando de predecir el identificador único de sesión.
2. Robo del token de acceso de sesión en el punto final
3. Robo del token de acceso de sesión durante la comunicación de red.

Requisitos

• El atacante debe tener previamente un mecanismo para hacer Man-in-the-middle entre la víctima y la red

Demostración

Escenario: el usuario está previamente logueado en su cuenta de Gmail. El usuario recibe un correo aparentemente de LinkedIn. El usuario hace clic en un botón dentro del mismo, lo que desencadena una redirección del tráfico hacia el servidor del atacante, que sirve al usuario una copia exacta del portal de LinkedIn, donde deberá autenticarse. Al pulsar sobre Iniciar sesión, Linkedin enviará un mensaje al móvil del usuario para proporcionarle un código de seguridad. Una vez el usuario lo facilita en la aplicación, el atacante recibe un volcado con el nombre de usuario, contraseña y TOKEN COOKIE o cookie de sesión.

En este ejemplo, Kevin Mitnick ha utilizado Evilginx.

Otro ejemplo lo tenemos debajo, con los falsos inicios de sesión sospechosa detectados en Amazon y muchos otros sites (el siguiente es de un caso que me tocó de cerca).

Mecanismos de defensa

• Implementa programas de concienciación contra el phishing.
• Implementa programas de formación y seguimiento activo del rendimiento de empleados, contra mecanismos de ingeniería social como el phishing.
• Implementa defensa en profundidad y sistemas de seguridad encargados de analizar el correo electrónico, que pueda detonar y sanitizar el contenido de los mismos.

2. Man in the Endpoint u hombre en el medio

Bastante obvio, ¿no? En cualquier caso conviene recordar que, si el atacante ya tiene previamente comprometido nuestro dispositivo (teléfono, portátil, etc) podrá contar con acceso a nuestra cuenta, sin importar si tenemos un mecanismo 2fa/mfa, de una de las siguientes formas.

• Esperar a la autenticación del usuario para usar sus permisos con los fines que desee
• Arrancar un navegador secundario, oculto a los ojos del usuario
• Robar las cookies de sesión de forma directa
• Insertar backdoors
• Otro tipo de adulteración del sistema

Un ejemplo de esto son los troyanos bancarios.

Mecanismos de defensa

3. Subject Hijack o secuestro de sujeto

Un ataque interesante, del que no se tiene constancia de que se haya realizado hasta la fecha, pero que es plausible. Cada producto o token MFA está adherido de forma exclusiva a un «sujeto» que supuestamente utiliza dicho dispositivo o software.

Los atacantes podrían sustraer la identidad del sujeto y después intentar reutilizar la «identidad robada» con otro token diferente. Esto permitiría que suplante la identidad y token de potencialmente cualquier usuario.

Si se consigue manipular un correo electrónico o bien una identidad de directorio activo (UPN) asociado a una smartcard, todo lo que tendría que hacer un insider malicioso o bien alguien que haya comprometido un equipo previamente, es hacer un swap de UPNs entre su cuenta sin privilegios y una que tenga privilegios elevados, como la de domain admin.

Una vez finalizadas las operaciones, volvería a hacer el intercambio de UPN (userPrincipalName o nombre de usuario). Podéis ver un ejemplo de este tipo de ataque, perpetrado por Roger Grimes de Knowbe4 en laboratorio.

Este tipo de escenario requiere que se realice un seguimiento de eventos asociados a actualización de UPN para poder detectar dicho ataque. Se trata del evento 4738 – A user account was changed. Ejemplo:

A user account was changed.

Subject:

   Security ID:  ACME-FR\administrator
   Account Name:  administrator
   Account Domain:  ACME-FR
   Logon ID:  0x20f9d

Target Account:

   Security ID:  ACME-FR\John.Locke
   Account Name:  John.Locke
   Account Domain:  ACME-FR

Changed Attributes:

   SAM Account Name: -
   Display Name:  -
   User Principal Name: -
   Home Directory:  -
   Home Drive:  -
   Script Path:  -
   Profile Path:  -
   User Workstations: -
   Password Last Set: -
   Account Expires:  -
   Primary Group ID: -
   AllowedToDelegateTo: -
   Old UAC Value:  0x10
   New UAC Value:  0x4010
   User Account Control:
   'Not Delegated' - Enabled
   User Parameters: -
   SID History:  -
   Logon Hours:  -

 
Additional Information:

   Privileges:  -

Mecanismos de defensa

• Considera cualquier atributo crítico (como el «sujeto» o «subjetct») relativo a la autenticación como potencialmente vulnerable.
• Revisa los privilegios/atributos y mantén el mínimo privilegio necesario. Un ejemplo es garantizar que solamente los Domain Admins, Administradores, usuario System y otros usuarios con Full Control, Write o Write Public-Information puedan modificar UPNs.
• Audita y genera alertas para modificaciones en atributos sensibles

4. SIM Swapping

El SIM swapping (Subscriber Identity Module) o intercambio de SIM es un método muy popular para realizar ataques contra mecanismos MFA de tipo SMS, aunque potencialmente podría abarcar otros como las aplicaciones con códigos como Authenticator de Google.

Esencialmente, el almacenamiento SIM contiene información sobre la red del cliente, su identificador de dispositivo único o IMEI (identifica al aparato de forma única a nivel global) y otra información relevante, como el suscriptor o dueño del número de teléfono.

Anteriormente guardado en la tarjeta microSD, hoy en día se guarda y transfiere digitalmente. Así que un teléfono al que se transfiera la información de nuestra SIM actuará, exactamente, como si fuera nuestro.

Esto quiere decir que será posible que reciba llamadas y mensajes dirigidos a nosotros. Algo que, durante un ataque de SIM Swap, va aparejado a una silenciosa y repentina pérdida de funcionalidad en nuestro «viejo» teléfono.

Escenario: el atacante transfiere la información de SIM hacia un nuevo terminal en su poder; el viejo deja de funcionar. El método de entrada es normalmente la ingeniería social (engañar a la empresa de telefonía solicitando, por ejemplo, un duplicado sin que se validen los datos apropiadamente, o bien a través de un insider). Algunos troyanos bancarios son capaces de exfiltrar este tipo de información.

Mecanismos de defensa

Según estándares como el NIST en su documento SP 800-63, no se debería aceptar códigos 2FA de tipo SMS como un método válido por la facilidad con que son vulnerados. Existen mecanismos alternativos y mucho más seguros, como el FIDO, App de autenticación (no usa el teléfono, sino el usuario), etc.

5. Recuperación ficticia de códigos SMS

Con solo saber tu número de teléfono y el servicio al que está adscrito puede valerse de problemas inherentes al SMS (Short Message Service) para atacarte mediante una recuperación de códigos ilegítima. Concretamente, es posible porque el origen de los SMS no puede ser autenticado dentro de los propios mensajes, así que debemos confiar en la identidad sin saber a ciencia cierta si es quien dice ser.

Si un hacker quiere colarse en tu cuenta de correo, necesitará tu dirección de email y un número de teléfono asociado a ella.

Escenario:

1. El hacker envia un SMS a nuestro terminal, pretendiendo ser nuestro proveedor de email, pidiéndonos el código SMS de «reseteo», con el pretexto de evitar un reciente inicio de sesión sospechoso en nuestra cuenta. Si no lo hacemos, perderemos el acceso a nuestra cuenta por seguridad.
2. El atacante ahora inicia el proceso de recuperación de cuenta mediante el PIN SMS de recuperación. Irá saltando por los diferentes mecanismos de recuperación. Nos llegará un SMS justo después del que ya nos ha enviado «simulando» ser un mecanismo de seguridad.
3. Al reenviar al atacante el código, se hará con el control total de nuestra cuenta.

Mecanismos de defensa

• Sé consciente de peligros como los mensajes de recuperación fraudulentos y recuerda que el flujo de SMS siempre será del teléfono al navegador y no viceversa.
• Usa MFA siempre que puedas.
• Evita en lo posible métodos de recuperación basados en SMS.
• Evita al máximo difundir innecesariamente los números de teléfono asociados a tus mecanismos de recuperación de cuentas.

6. Ingeniería social sobre el soporte técnico

A pesar de tener un dispositivo 2FA o MFA registrado y de obligado uso según políticas, un usuario podría ser vulnerado engañando a un tercero.

En lo concerniente a la autenticación multi-factor, lo que intentará un hacker normalmente es llamar al servicio de soporte de la empresa y, mediante otra serie de datos relevantes aprendidos sobre el usuario, intentar que le retiren temporalmente el método MFA.

Evidentemente, se usarán mecanismos como la premura o que el usuario es VIP (importante) para estresar al personal de soporte y conseguir nublar su capacidad de análisis. Además, el ser humano tiene una voluntad innata de ayudar a sus semejantes.

Hecho esto, el atacante recibirá la contraseña que ha pedido restablecer y podrá hacer a su antojo. Hé aquí un ejemplo bien construído de scam telefónico que ya compartí hace algún tiempo.

Los mecanismos de defensa serán los correspondientes al punto 1, esencialmente.

7. Generador de códigos duplicados

La mayoría de generadores de códigos MFA comienzan con valor secreto (secret) también llamado «semilla» que, uan vez generado aleatoriamente, se incrementará con una parte final correspondiente al contador que su algoritmo particular genere al utilizarlo.

Hablamos de los OTP (One Time Passwords o Contraseñas de un solo uso). No se repiten nunca y su validez puede estar sujeta a un límite de tiempo (TOTP) o a un número de saltos (HOTP).

Los secretos compartidos estarán siempre guardados en dos sitios, siendo el primero la base de datos del servidor y el segundo el dispositivo cliente.

Si el atacante puede encontrar y acceder a la base de datos que contiene nuestro device ID y semillas o seeds, podrían aprender y clonar el algoritmo en uso para producir un autenticador de tipo software que sea un clon de uno de hardware, por ejemplo. Es lo que le pasó en 2011 a Lockheed Martin a través del hackeo de dispositivos SecurID de RSA.

8. Downgrade o utilización de protocolos inseguros

Peligroso es no tener una implementación de 2FA o multifactor, como igualmente peligros es tener una solución cuya cobertura sea incompleta, o que permita hacer downgrade o reversión hacia mecanismos como 1FA (es decir, una simple contraseña).

Escenario: un usuario malicioso simula no poder utilizar su dispositivo de autenticación fuerte y le solicita al sistema que le permita acceder a su cuenta mediante el envío de un código OTP a una cuenta de correo de recuperación. El usuario atacará este método alternativo, que siempre es más sencillo de atacar que un multifactor.

Pasa lo mismo con las preguntas de seguridad, que en muchos casos son requeridas para la creación de la cuenta. Hay un estudio de Google sobre esto muy relevante si te interesa.

Mecanismos de defensa

• Desactivar mecanismos de recuperación como email o número de teléfono.
• No utilizar preguntas de seguridad o aplicar validación de datos para certificar que son realmente seguras.
• ¡Nunca responder las preguntas de seguridad de forma sincera! Usa una passphrase

9. Vulnerabilidades en los dispositivos

En lo que se conoce como la vulnerabilidad criptográfica ROCA, descubierta en 2017, podemos observar como un único punto de fallo puede echar por tierra la seguridad de todo el sistema, ya sea una mala implementación en chips TPM, Yubikeys o smartcards.

Cualquier usuario que pudiera ver nuestra clave pública era capaz de dar con nuestra clave privada en un corto período de tiempo. Esto puso en un riesgo enorme a cientos de millones de dispositivos, y a día de hoy se considera que existen.

Mecanismos de defensa

• Evaluar correctamente el producto, sabiendo que no solo debemos fijarnos en su implementación funcional, sino en la auditoría de sus sistemas y el tiempo medio de parcheo de errores.

10. Reutilizar biometría sustraída y ataques físicos

¿Qué pasaría si se hacen con el control de información relativa a nuestro físico? Resulta que cambiar de huella dactilar o retina no es en absoluto fácil, no es como sustituir un token por otro o comprar un nuevo FIDO.

En el mundo criptográfico esto se conoce como ataque de no-repudio. Una vez se ha filtrado, estamos comprometidos de por vida (al menos, mientras nuestra cuenta tenga habilitada esa biometría).

Un ejemplo de esto es el ataque a OPM en 2015, que acabó con la filtración de marcas biométricas de 5,6 millones de personas.

Por otro lado, está la amenaza siempre posible de engaño a sistemas de escaneo corporal, como le ocurrió a Apple con su FaceID

Mecanismos de defensa

Consideraciones adicionales para un MFA seguro

He procurado ofrece algunas pautas enfocadas a cada caso, para mitigar o resolver los problemas descritos. En cualquier caso, no es lo único que se debe tener en cuenta, así que revisa estos «objetivos».

Defensas a nivel técnico

1. Utiliza MFA siempre que sea posible
2. NO utilices MFA basado en SMS siempre que sea posible
3. Utiliza soluciones 1:1. Es decir, que para registrar un dispositivo MFA, el usuario deba existir previamente en el sistema
4. Asegúrate de que tu solución MFA sea capaz de detectar e impedir message replay o reenvío de códigos.
5. Asegúrate de que el diseñador de la solución emplea conceptos de SDL (Software Development Licecycle) en su programación
6. Configura un número máximo de intentos no satisfactorios para tu solución, con el consiguiente bloqueo de cuenta.
7. Reparte los diferentes factores en canales distintos. Es lo que se conoce como out-band MFA. Es decir, lo contrario a facilitar los códigos a través del mismo dispositivo por el que se realiza el acceso privilegiado.
8. Para autenticación basada en transacciones, confirma que se envían los detalles importantes por otro medio, antes de que se emita la confirmación desde el dispositivo final.

Y podría añadir, finalmente, asegúrate de formar a tus usuarios en el uso de estas herramientas y darles una formación mínima sobre la mejor forma de usarlos.

Conclusiones

Hemos presentado diferentes formas en las que teóricamente (y en la práctica, según circunstancias) es posible atacar mecanismos de autenticación en dos o más factores con éxito.

Incluso habría otras vías potenciales que no he comentado, como son el comprometer APIs o credenciales compartidas, o la fuerza bruta no controlada sobre el envío de códigos MFA, aunque estas son menos comunes.

Esto debería animarnos a aprender y mantener principios de uso de la información de forma segura y responsable, principalmente para saber cómo reaccionar ante el phishing o el uso de contraseñas robustas (que son el primer factor de autenticación).

Y me gustaría acabar como debería haber empezado y es recordándote la importancia de configurar mecanismos de inicio de sesión seguros siempre que se pueda. Revisa mis guías para activar 2fa en servicios populares o entra en 2factorauth.org para informarte de qué servicios soportan el MFA.