Incluso antes de comenzar a comprender la compleja ciencia de la seguridad de la información, me pareció que la autenticación 2FA es una forma garantizada de proteger su cuenta y que "estos sus hackers" no pueden, por ejemplo, retirar mi moneda interna para comprar ropa para los personajes de una cuenta de juego. Pero con el tiempo, se ha demostrado experimentalmente que un sistema de autenticación de dos factores puede tener una gran cantidad de vulnerabilidades.
En palabras simples, la autenticación de dos factores es una confirmación de la acción al ingresar el código generado para aumentar la seguridad y lanzar palos en las ruedas de los hackers condicionales durante el movimiento o antes de que comience.
El sistema de confirmación de código está muy extendido, se usa en todas partes en varios sitios y se puede conectar para inicios de sesión primarios y secundarios. Pero la aplicación no se limita a esto: los desarrolladores adjuntan una confirmación sobre la funcionalidad de recuperación de contraseña, confirmación de registro / suscripción, confirmación adicional de transacciones financieras, cambio de contraseña, cambio de datos personales. Además, de vez en cuando, 2FA se usa como un muro después del cierre de sesión para el tiempo, y no una contraseña u otra forma de confirmación.
En este artículo, he recopilado formas de probar 2FA en busca de vulnerabilidades, su explotación, así como las posibles opciones para eludir la protección existente contra ciertos tipos de ataques. Veamos la lista de comprobaciones de vulnerabilidad que se aplican a 2FA:
1. Falta de límite de velocidad
El algoritmo de límite de velocidad se usa para probar si una sesión de usuario (o dirección IP) puede limitarse en intentos o velocidad, y bajo qué circunstancias esto sucede. Si el usuario ha completado demasiadas solicitudes dentro de un cierto período de tiempo, la aplicación web puede responder con un código 429 (muchas solicitudes) o aplicar un límite de velocidad sin mostrar errores. La ausencia de un límite de velocidad implica que durante la enumeración normal no hay restricciones en el número de intentos y / o velocidad: se permite iterar sobre los códigos cualquier cantidad de veces (a cualquier velocidad) dentro del período de validez de la sesión / token.
Muy a menudo tiene que lidiar con un límite de velocidad "silencioso", si ve que no hay errores y el cuerpo / código HTTP no cambia en las solicitudes posteriores, debe estar contento demasiado pronto, y primero debe verificar el resultado final del ataque utilizando un código válido.
2. Existe un límite de velocidad, pero se puede eludir
Casos que tuve que conocer antes:
1) Limitar la velocidad de los flujos sin bloqueo después de alcanzar cierta velocidad
A menudo, los investigadores de seguridad intentan recoger el código usando 5 o más hilos para hacer un ataque más rápido (en Burp Intruder, el número predeterminado de hilos es 5 sin demora). Pero a veces, un sistema de seguridad que se rompe o un equilibrador de carga normal solo puede responder a este factor único. Si está tratando de forzar la fuerza bruta con 5 hilos, debe reducir el número a 1 y luego a 1 con un retraso de un segundo. Anteriormente, tuve la suerte de observar ese comportamiento y fue con la ayuda de tales manipulaciones que se produjo la selección exitosa del código, lo que condujo a la Toma de Cuenta. Si el código 2FA no tiene una fecha de vencimiento específica, entonces tenemos mucho tiempo para clasificar. Si el período de validez está presente, el éxito del ataque se reduce, pero el peligro potencial de vulnerabilidad aún está presente, ya que aún existe la posibilidad de ingresar al código deseado.
2) El código OTP generado no cambia
Esto no se aplica a los códigos que cambian constantemente, como en Google Authenticator, sino solo a los códigos estáticos que vienen en SMS, correo electrónico o en persona a través de messenger.
La esencia de esta omisión es que el mismo código OTP se envía constantemente o durante algún tiempo, por ejemplo, 5 minutos, lo cual es válido durante todo este tiempo. También vale la pena asegurarse de que no se produzca un límite de velocidad silencioso.
Ejemplo de informe:
hackerone.com/reports/420163Supongamos que la aplicación genera un código aleatorio del 001 al 999 y lo envía al teléfono, en 10 minutos cuando la función "enviar de nuevo" está habilitada, obtenemos el mismo código. Pero el límite de velocidad está vinculado a la solicitud, que limita el número de intentos por token de solicitud. Podemos solicitar constantemente un nuevo código, generar un nuevo token de solicitud, aplicarlo a una solicitud posterior (usando grep-match en un conjunto de eructos o usando nuestro propio script) y realizar la fuerza bruta de un rango de números del 001 al 999. Por lo tanto, usar constantemente un nuevo token de solicitud seleccionaremos con éxito el código correcto, ya que no cambia y es estático durante un cierto período de tiempo. Las limitaciones de este ataque son un número largo o mezclar letras con números como código de confirmación.
Esta situación no debe fomentarse, debe intentar ordenar al menos parte de nuestra lista, ya que existe la posibilidad de que el código generado esté en esta parte de la lista, ya que se genera aleatoriamente. Al intentarlo, debe confiar en el azar, pero aún existe la posibilidad de obtener la combinación correcta, lo que demuestra una vulnerabilidad que definitivamente debe corregirse.
3) Restablezca el límite de velocidad-a cuando actualice el código.
En la solicitud de verificación del código, el límite de velocidad está presente, pero después de activar la función de reenvío del código, se restablece y le permite continuar con el código de fuerza bruta.
Ejemplos de informes:
https://hackerone.com/reports/149598 , - teoría;
hackerone.com/reports/205000 , un exploit práctico basado en un informe anterior.
4) Saltando el límite de velocidad cambiando la dirección IP
Muchos bloqueos se basan en la restricción de recibir solicitudes de IP, que ha alcanzado el umbral de un cierto número de intentos al ejecutar una solicitud. Si se cambia la dirección IP, existe la oportunidad de eludir esta restricción. Para verificar este método, simplemente cambie su IP usando el servidor Proxy / VPN y vea si el bloqueo depende de la IP.
Formas de cambiar la IP:
- Los proxies se pueden usar en un ataque usando el complemento IP Rotator para Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension . En mi opinión, esta es la mejor opción, ya que nos brinda ~ intentos ilimitados de fuerza bruta y direcciones IP que le permiten realizar un ataque de fuerza bruta sin errores e interrupciones 42x.
- Una buena opción podría ser un script de Python con un módulo de solicitudes de proxy, pero primero necesita obtener una gran cantidad de proxies válidos en algún lugar.
Dado que la herramienta de rotación de IP envía solicitudes utilizando direcciones IP de AWS, todas las solicitudes se bloquearán si la aplicación web está detrás del firewall de CloudFlare.
En este caso, debe descubrir adicionalmente la IP del servidor web original o encontrar un método que no afecte a las direcciones IP de AWS.
5) El sitio incluye soporte para X-Fordered-For
El encabezado X-Fordered-For incorporado se puede usar para cambiar la IP. Si la aplicación tiene un procesamiento incorporado para este encabezado, simplemente envíe X-Forward-For: deseado_IP para reemplazar la IP para evitar la restricción sin el uso de proxies adicionales. Cada vez que se envía una solicitud desde X-Fordered-For, el servidor web pensará que nuestra dirección IP coincide con el valor transmitido a través del encabezado.
Materiales sobre este tema:
hackerone.com/reports/225897medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf341573. Omita 2fa sustituyendo parte de la solicitud de una sesión de otra cuenta
Si se envía un parámetro con un valor específico para verificar el código en la solicitud, intente enviar el valor de la solicitud a otra cuenta.
Por ejemplo, al enviar un código OTP, se verifica la identificación del formulario, la identificación del usuario o la cookie asociada con el envío del código. Si aplicamos los datos de los parámetros de la cuenta en la que desea omitir la verificación del código (Cuenta 1) a una sesión de una cuenta completamente diferente (Cuenta 2), obtendremos el código y lo ingresaremos en la segunda cuenta, entonces podremos omitir la protección en la primera cuenta. Después de volver a cargar la página 2FA debería desaparecer.
4. Omita 2FA utilizando la "funcionalidad de memorización"
Muchos sitios que admiten la autorización 2FA tienen la funcionalidad "recordarme". Es útil cuando el usuario no desea ingresar un código 2FA en inicios de sesión posteriores. Es importante identificar la forma en que 2FA es "recordado". Esto puede ser una cookie, un valor en sesión / almacenamiento local, o simplemente adjuntar 2FA a una dirección IP.
1) Si se adjunta 2FA usando una cookie, el valor de la cookie debe ser indiscutible
Es decir, si una cookie consiste en un conjunto de números que aumentan para cada cuenta, entonces es muy posible aplicar un ataque de fuerza bruta al valor de la cookie y evitar 2FA. Los desarrolladores deben proporcionar la cookie (junto con la cookie de sesión clave y el token CSRF) con el atributo HttpOnly para que no pueda ser robada usando XSS y utilizada para evitar 2FA.
2) Si 2FA está conectado a la dirección IP, puede intentar reemplazarlo
Para identificar este método, inicie sesión en su cuenta utilizando la función de almacenamiento 2FA, luego cambie a otro navegador o modo de incógnito del navegador actual e intente iniciar sesión nuevamente. Si no se solicita 2FA, se ha adjuntado 2FA a la dirección IP.
Para reemplazar la dirección IP, puede usar el encabezado X-Fordered-For en la etapa de ingresar el nombre de usuario y la contraseña, si la aplicación web lo admite.
Con este encabezado, también puede omitir la función de lista blanca de la dirección IP, si hay una presente en la configuración de la cuenta. Se puede usar junto con 2FA como protección adicional de la cuenta o incluso no se puede solicitar 2FA si la dirección IP coincide con la lista blanca (con el consentimiento del usuario). Por lo tanto, incluso sin conectar el 2FA a la dirección IP, en algunos casos se puede eludir el 2FA eludiendo los métodos de protección asociados.
En general, adjuntar 2FA a una dirección IP no es una forma completamente segura de protección, porque cuando está presente en la misma red, cuando está conectado al mismo proveedor de servicios VPN / Internet con una dirección IP estática, se puede omitir 2FA.
La forma más segura de protegerse es no recordar 2FA en absoluto en detrimento de la usabilidad.
5. Error de control de acceso incorrecto en la página de entrada 2FA
A veces, una página de diálogo para ingresar 2FA se presenta como una URL con parámetros. El acceso a dicha página con parámetros en la URL con cookies que no coinciden con los utilizados para generar la página o sin cookies no es seguro. Pero si los desarrolladores decidieron aceptar los riesgos, entonces debe pasar por varios puntos importantes:
- ¿El enlace caduca para la entrada 2FA?
- si el enlace está indexado en los motores de búsqueda.
Si el enlace tiene una larga vida y / o los motores de búsqueda contienen enlaces de trabajo para la entrada 2FA / los enlaces pueden indexarse (no hay reglas en robots.txt / metaetiquetas), entonces existe la posibilidad de utilizar un mecanismo de derivación 2FA en la página de entrada 2FA, en la que omita completamente el nombre de usuario y la contraseña, y obtenga acceso a la cuenta de otra persona.
6. Censura inadecuada de los datos personales en la página 2FA
Al enviar un código OTP en una página, la censura se utiliza para proteger datos personales como correo electrónico, número de teléfono, apodo, etc. Pero estos datos pueden divulgarse completamente en los puntos finales de la API y otras solicitudes para las cuales tenemos suficientes derechos en la etapa 2FA. Si inicialmente no se conocían estos datos, por ejemplo, ingresamos solo un inicio de sesión sin conocer el número de teléfono, entonces esto se considera la vulnerabilidad de divulgación de información. Saber el número de teléfono / correo electrónico se puede utilizar para posteriores ataques de phishing y fuerza bruta.
Un ejemplo de explotación de una vulnerabilidad usando Credentials Stuffing. Digamos que hay una base de datos en el dominio público con inicios de sesión y contraseñas para el sitio A. Los atacantes pueden usar los datos de esta base de datos en el sitio B:
- Primero, verifican si el usuario existe en la base de datos del sitio B utilizando el error "Enumeración de cuentas" al registrar / recuperar la contraseña. Por lo general, muchos sitios no consideran esto una vulnerabilidad y toman riesgos. La "vulnerabilidad" radica en la presencia de un error sobre el hecho de registro de usuario en el sitio. Idealmente, un mensaje seguro en la página de recuperación de contraseña es el siguiente:
- Después de obtener la base de datos de usuarios existentes, los atacantes aplican contraseñas a estas cuentas.
- Si se encuentran con 2FA, entonces se atascan. Pero en caso de censura insuficiente de los datos del usuario, pueden complementar su base de datos con sus datos personales (si no estaban en la base de datos original).
7. Ignorando 2FA en ciertas circunstancias
Al realizar algunas acciones que conducen al inicio de sesión automático en su cuenta, es posible que no se solicite 2FA.
1) Ignora 2FA al recuperar una contraseña
Muchos servicios inician sesión automáticamente en su cuenta después de completar el procedimiento de recuperación de contraseña. Dado que el acceso a la cuenta se proporciona instantáneamente, cuando inicia sesión en su cuenta 2FA, puede ignorarse e ignorarse por completo.
Impacto de un informe de hackerone similar que envié recientemente:
Si un atacante obtiene acceso al correo electrónico de la víctima (puede piratear la cuenta mediante phishing, ataques de fuerza bruta, relleno de credenciales, etc.), puede omitir 2FA, aunque en este caso 2FA debería proteger la cuenta. Por el momento, para 2FA hay una verificación del código de Google Authenticator o del código de respaldo, pero no del código del correo electrónico, por lo que este Bypass tiene sentido.
2) Ignorar 2FA al iniciar sesión a través de una red social
Puede adjuntar una red social a su cuenta de usuario para iniciar sesión rápidamente en su cuenta y al mismo tiempo configurar 2FA. Cuando inicia sesión en su cuenta a través de las redes sociales, se puede ignorar 2FA. Si se piratea el correo electrónico de la víctima, será posible recuperar la contraseña de la cuenta de la red social (si lo permite) e ingresar al servicio sin ingresar 2FA.
Impacto de uno de los informes:
- Un montón de otras vulnerabilidades, como la configuración incorrecta de OAuth enviada anteriormente # 577468, para capturar completamente la cuenta, rompiendo 2FA.
- Si un atacante hackeó el correo electrónico del usuario, podría intentar recuperar el acceso a la cuenta de la red social e iniciar sesión en la cuenta sin verificación adicional.
- Si un atacante una vez pirateó la cuenta de una víctima, podría asociar una red social con la cuenta e iniciar sesión en la cuenta en el futuro, ignorando completamente 2FA e ingresando el nombre de usuario / contraseña.
3) Ignorar 2FA en una versión anterior de la aplicación
Los desarrolladores a menudo agregan versiones provisionales de una aplicación web a dominios / subdominios para probar ciertas funciones. Curiosamente, si inicia sesión con su nombre de usuario y contraseña, no se solicitará 2FA. Quizás los desarrolladores están utilizando una versión anterior de la aplicación, en la que no hay protección para 2FA, 2FA en sí está deshabilitado o fue deshabilitado intencionalmente para las pruebas.
Además, puede verificar otras vulnerabilidades al mismo tiempo, - registrar un nuevo usuario en un servidor provisional cuyo correo electrónico existe en la base de datos de la versión de producción puede proporcionarnos datos personales de la producción; la ausencia de un límite de velocidad en funcionalidades importantes, por ejemplo, recuperación de contraseña. Un ejemplo de la última vulnerabilidad es un error de Facebook de $ 15,000, que permitió hackear una cuenta usando el código de recuperación de contraseña de bruteforce en beta.facebook.com
www.freecodecamp.org/news/responsible-disclosure-how-i-could-have-hacked-all- facebook-accounts-f47c0252ae4d .
4) Ignorar 2FA en caso de plataforma cruzada
Las implementaciones de 2FA en la versión móvil o de escritorio pueden diferir de la versión web de la aplicación. 2FA puede ser más débil que en la versión web o completamente ausente.
7. Al deshabilitar 2FA, no se solicita el código actual.
Si, al deshabilitar 2FA, no se solicita confirmación adicional, como el código actual de la aplicación de autenticación de google, el código del correo electrónico / teléfono, entonces en este caso existen ciertos riesgos. Con una solicitud limpia, existe la posibilidad de un ataque CSRF. Si se encuentra un vector de derivación de protección CSRF (si existe), entonces 2FA se puede deshabilitar. También se puede utilizar una vulnerabilidad de clickjacking: después de un par de clics de un usuario desprevenido, 2FA se desconectará. La validación del código anterior agregará protección adicional 2FA, dados los posibles ataques CSRF / XSS / Clickjacking, así como las configuraciones incorrectas de CORS.
Le daré un ejemplo de hackerone.com: cuando apaga 2FA de una forma, debe ingresar dos variables al mismo tiempo, el código actual con la aplicación de autenticación de Google y la contraseña. Esta es la mejor y recomendada protección.
8. Las sesiones creadas previamente siguen siendo válidas después de la activación de 2FA
Cuando 2FA está habilitado, es deseable que finalicen las sesiones paralelas en la misma cuenta y se muestre el cuadro de diálogo de entrada de 2FA, lo mismo con un cambio de contraseña. Si la cuenta se vio comprometida y la primera reacción de la víctima es la inclusión de 2FA, la sesión del atacante se deshabilitará y el próximo inicio de sesión y contraseña requerirán 2FA. Con todo, esta es la mejor práctica a seguir. A menudo noto cómo los intercambios de criptomonedas agregan una protección similar. Ejemplo de informe de HackerOne, -
https://hackerone.com/reports/534450.
9. La ausencia de un límite de tasa en su cuenta
2FA se puede implementar en varias funciones de la cuenta personal del usuario para mayor seguridad. Esto puede ser un cambio de dirección de correo electrónico, contraseña, confirmación de un cambio de código para transacciones financieras, etc. La presencia de rate-limit-a en su cuenta puede diferir de la presencia de rate-limit-a en 2FA al ingresar a su cuenta. A menudo me he encontrado con casos similares cuando era posible seleccionar libremente un código 2FA en mi cuenta, mientras que en la entrada se estableció un límite de velocidad "estricto".
Si los desarrolladores inicialmente agregaron protección contra cambios de datos no autorizados, entonces esta protección debe ser respaldada y corregida por todos los bypass-s posibles. Si se encuentra la omisión, se considera una vulnerabilidad de omisión de la característica de seguridad implementada por los desarrolladores.
10. versiones de API
Si ve algo como / v * / en la solicitud de la aplicación web, donde * es un número, entonces es probable que pueda cambiar a una versión anterior de la API.
En la versión anterior de la API, puede haber una protección débil o no tener ninguna. Esta es una ocurrencia bastante rara y ocurre si los desarrolladores olvidaron eliminar la versión anterior de la API en el entorno de producción / preparación.Por ejemplo, / endpoint / api / v4 / login realiza una solicitud de inicio de sesión, verificando el nombre de usuario y la contraseña. Si 2FA está presente en la cuenta, esta solicitud debe ser seguida por / endpoint / api / v4 / 2fa_check, nada más. Si reemplazamos la versión de API antes de 2FA, entonces, en algunos casos, podemos evitarlo. / endpoint / api / v3 / login puede conducir a / endpoint / v3 / login_successful? code = RANDOM, ignorando 2fa_check porque en esta versión de la API, 2FA simplemente no se implementó.Otro ejemplo: en request / endpoint / api / v4 / 2fa_check hay un límite de velocidad, mientras que / endpoint / api / v3 / 2fa_check le permite iterar sobre los códigos sin ninguna restricción.11. Control de acceso incorrecto al solicitar códigos de respaldo
Los códigos de respaldo se generan inmediatamente después de que se habilite 2FA y están disponibles en una sola solicitud. Después de cada llamada posterior a la solicitud, los códigos pueden ser generados por uno nuevo o permanecer sin cambios (códigos estáticos). Si hay vulnerabilidades de configuración incorrecta de CORS / XSS y otros errores que permiten "extraer" códigos de respaldo de la solicitud de respuesta para el punto final de visualización del código de respaldo, entonces un atacante podría robar códigos y omitir 2FA si se conoce el nombre de usuario y la contraseña.En general, 2fa es una de las formas más confiables para proteger su cuenta, a menos que, por supuesto, los desarrolladores almacenen los códigos 2FA actuales de todos los usuarios de la aplicación web en el panel de administración, y esto ha sucedido en mi práctica. También me gustaría señalar que los desarrolladores de algunas empresas crean aplicaciones para generar sus propios códigos 2FA (por ejemplo, Salesforce, Valve) y, debido a la falta de seguridad, este énfasis en la independencia del uso de otras aplicaciones de autenticación brinda a los atacantes un punto de entrada adicional para evitar 2FA. El rango de aplicación de esta protección es bastante amplio y brinda a quienes desean evitar la protección 2FA más oportunidades, espacio para la creatividad y aumenta el número de variaciones de los bypass-2FA.Espero que esta información sea útil para los investigadores de seguridad de la información, los cazadores de recompensas de errores, así como para que los desarrolladores minimicen la cantidad de vulnerabilidades en el servicio que se está desarrollando. ¡Mantente a salvo!