¿Cómo abordan los pentesters el ataque a 2FA (autenticación de dos factores)?

6

Estoy buscando formas prácticas de atacar a 2FA. ¿Qué necesita considerar y cómo evaluaría la efectividad de 2FA? Mi único pensamiento es que atacarías la implementación en sí misma.

    
pregunta Arlix 27.11.2015 - 11:52
fuente

3 respuestas

3

Su objetivo como pentester es identificar amenazas previamente desconocidas o no reconocidas.

Sea extremadamente claro que cualquier cosa que haga aquí debe ser autorizada explícitamente por su cliente. No hacerlo puede ponerte en serios problemas. Si se está preguntando acerca de los detalles sobre esa pregunta, consulte Law Stack Exchange .

Atacar dos factores puede ser fácil si está mal configurado. En muchos casos, hay mecanismos de reinicio o de desvío que recurren al correo electrónico. Si se configura correctamente, se vuelve poco práctico atacar directamente y es necesario buscar vías para capturar tokens o comprometer directamente una aplicación autenticada.

Si el segundo factor es un token de hardware, deberá utilizar MitM en la aplicación que consume el token. Si la aplicación es HTTP u otro transporte no cifrado, esto se puede lograr con la captura de red (no es realmente MitM pero necesita una posición MitM para hacer la captura). Si la aplicación está utilizando TLS con un certificado no válido, puede lograrlo mediante el envenenamiento de DNS (esperando las solicitudes de DNS para el dominio de destino y enviando varias respuestas de DNS con TTL grandes dirigiendo al usuario a su MitM con su propio certificado autofirmado. la aplicación está utilizando HTTPS con certificados válidos que podría comprometer un punto final a través de otras técnicas y capturar la entrada del token directamente en el agente de usuario. Puede valer la pena comprometer una aplicación que consume el token. Si están usando un sistema de token TOTP, puede comprometer al más débil de los servicios que utilizan el mismo token serial y luego reutiliza el token dentro de la ventana de caducidad. Si están usando un sistema de token administrado por única vez como Safenet Cryptocard, esto no funcionará ya que el token se consume en uso, independientemente del tiempo de espera. ser para capturar el token en el primer intento, sustituir un valor falso por el autenticador real y canalizar una sesión por separado para autenticar. De esa manera, el usuario Creo que han cometido un error y simplemente reintentar. Mientras se encuentre en esa posición, es posible que pueda secuestrar directamente las cookies de sesión u otros tokens directamente si no se emplean defensas complementarias como las sesiones bloqueadas de dispositivo / IP o anti-CSRF.

Si el segundo factor ya está hecho por correo electrónico, su vector de ataque es la captura de red del SMTP entrante en el MX. Esto puede no ser práctico si el cliente está utilizando un proveedor externo seguro. Debería ser relativamente fácil si ejecutan sus propios servidores de correo.

Si el segundo factor se realiza a través de SMS, es posible que los tokens que se utilizan en el hombro estén físicamente presentes, ya que muchos teléfonos están configurados automáticamente para mostrar textos incluso cuando están bloqueados. Hay ataques más sofisticados que involucran teléfonos comprometidos que pueden usarse de otra manera.

La ingeniería social es el último truco aquí, sin embargo. Si de alguna manera puede hacer que un usuario lo llame para pedir ayuda, se hace pasar por Soporte de TI o, de lo contrario, puede que le digan el token directamente a medida que "ayuda" a solucionar su problema.

    
respondido por el Alain O'Dea 28.11.2015 - 04:16
fuente
2

Me recuerda esto artículo reciente .

(Pase el mouse por spoiler)

  

Un ataque de phishing lo hizo usar un nombre de dominio similar al de Google con un certificado válido.

Otros métodos podrían ser:

  • fichas de OTP predecibles.
  • MITM donde no hay cifrado o autenticación presente para proteger los datos en tránsito, por lo que el atacante puede interceptar y usar la OTP.
  • Encriptación o autenticación débil que también permite lo anterior.
  • fallas lógicas en la implementación, por ejemplo, permitir una OTP desde otra cuenta de usuario, permitir la reutilización de OTP, etc.
  • Debilidades en tokens de dispositivos de confianza (previsibilidad, fugas, etc.). Aquí es donde, por ejemplo, se coloca una cookie en el dispositivo utilizado para la autenticación para marcarlo como un dispositivo confiable que no necesita el segundo factor en el futuro.
  • XSS que permite recuperar el token.
  • CSRF permite deshabilitar la autenticación de dos factores.
  • 2FA restablece (por ejemplo, dispositivo perdido) usando un mecanismo mucho menos seguro (por ejemplo, un ataque físico en el que la cuenta de correo electrónico se registra y deshabilita 2FA solo implica hacer clic en un enlace).
respondido por el SilverlightFox 30.11.2015 - 11:02
fuente
1

2FA es mucho más seguro y, por lo tanto, más difícil de romper. Sin embargo, recuerdo haber escuchado sobre un método en el pasado para servicios que utilizan la verificación por SMS como el segundo factor. Si obtuvo la contraseña y también el número de teléfono, podría intentar un ataque de SE contra el proveedor de servicios móviles e intentar que el agente redireccione los mensajes a su número. Por lo tanto, todos los códigos de verificación de SMS irían al atacante.

    
respondido por el user92592 28.11.2015 - 00:14
fuente

Lea otras preguntas en las etiquetas