Pregunta:
Vectores de ataque para contraseñas de sitios web de fuerza bruta
jrdioko
2011-08-30 04:55:30 UTC
view on stackexchange narkive permalink

Cuando se habla de seguridad de contraseñas, mucha discusión se centra en el riesgo de que se adivine una contraseña en un ataque de fuerza bruta. Para los sitios web donde un usuario ha registrado una cuenta, ¿cuáles son los posibles vectores de un ataque de fuerza bruta?

Ingresar pares de nombre de usuario / contraseña en los campos de autenticación del sitio web directamente es uno, pero a menudo se mitiga con un tiempo de espera o bloqueo después de intentos fallidos. Llevar a cabo un ataque a una base de datos robada de contraseñas hash es otra, pero se supone que la base de datos se ha visto comprometida. ¿De qué otra manera podría llevarse a cabo un ataque de contraseña por fuerza bruta (asumiendo que estamos hablando de cuentas de sitios web, no cuentas de Unix, servicios, etc.)?

Cinco respuestas:
gowenfawr
2011-08-30 08:45:33 UTC
view on stackexchange narkive permalink

¿De qué otra manera podría llevarse a cabo un ataque de contraseña por fuerza bruta?

Has cubierto ambas bases, y eso es todo. O envíe repetidamente a cualquier interfaz web que esté disponible o consiga una copia de los hashes descifrando el servidor de la base de datos, abusando del software web, lo que sea.

La piratería de la interfaz web suele ser más un problema de fuerza inteligente que fuerza bruta y, como resultado, funciona mejor de lo que supondría. Por ejemplo, dado un sitio web que tenía un directorio de empresa (primero, último y extensión) para aproximadamente 100 personas, pude "forzar" el 30% de las cuentas simplemente juntando algunas conjeturas algorítmicas con esos datos. Y el sitio de autenticación era Microsoft Exchange, así que me mantuve por debajo del umbral de bloqueos recomendados por la NSA y estaba bien. (De hecho, esta fue una prueba de penetración y verifiqué antes de la prueba para asegurarme de no bloquear a los usuarios, pero fue una suposición fácil de hacer correctamente). Incluso con el ritmo lento de adivinar, terminé en menos de un día.

Tate Hansen
2011-08-30 09:18:22 UTC
view on stackexchange narkive permalink

He visto una buena cantidad de sitios que cambian su comportamiento según las credenciales proporcionadas; envíe un nombre de usuario que no existe y posiblemente obtenga un mensaje de error único o una respuesta HTTP más rápida en lugar de enviar un par de nombre de usuario / contraseña legítimo.

Una idea: digamos que roba con éxito una sesión válida de un usuario registrado y la funcionalidad de cambio de contraseña requiere que ingrese la contraseña existente del usuario; es posible que pueda forzar con éxito el formulario de cambio de contraseña sin activar bloqueos o captchas para descubrir la contraseña original.

Dog eat cat world
2011-08-30 14:38:09 UTC
view on stackexchange narkive permalink

Gowenfawr ya cubrió la enumeración de usuarios (si la entendí correctamente).

La mayoría de los sistemas (si no todos), las políticas de bloqueo son para cada cuenta. Por lo tanto, debería ser posible iterar sobre todos los usuarios que conoce, probando una cantidad de contraseñas que lo mantendrían por debajo del umbral de bloqueo para cada cuenta. Y una vez que se haya alcanzado el tiempo de gracia para los inicios de sesión no válidos, inténtelo de nuevo.

¿No sería esto también muy cercano a un ataque de cumpleaños a la contraseña de los usuarios?

Leí un artículo sobre un estudiante que hizo algo similar a un banco en línea. El nombre de usuario era el número de seguro social y el cliente bancario promedio era un hombre de entre 30 y 40 años. Él generó números de seguridad social aleatorios para este grupo de edad y probó diferentes pines (¡el inicio de sesión era de solo 4 dígitos!). Creo que pudo acceder a una cuenta bancaria en línea por cada ~ 20k intentos.

El uso de dicha lista de contraseñas (o contraseña generada por inicio de sesión) en todos los usuarios es de hecho uno de los ataques más eficientes.
dig
2018-04-03 10:13:27 UTC
view on stackexchange narkive permalink

La razón por la que la fuerza bruta es un tema de discusión popular es en gran parte la cultura pop: es relativamente fácil de entender para las personas que no entienden cómo funcionan las computadoras, por lo que hay muchos tropos y representaciones comunes de esta clase de ataques. Su viabilidad práctica es más limitada.

Dicho esto, los sistemas de software caseros suelen ser vulnerables en formas que los sistemas analizados minuciosamente tienden a proteger. Por ejemplo, la implementación adecuada del bloqueo requiere la recopilación y el almacenamiento de ciertos datos por usuario y por cliente. No es raro que los programadores sin experiencia no estén dispuestos o políticamente incapaces de, por ejemplo, definir los campos o tablas SQL adicionales y, por lo tanto, descuiden la implementación de una política de bloqueo. Es una regla general que los sistemas diseñados sin un análisis de seguridad adecuado tienden a enfatizar demasiado el aspecto de accesibilidad de la seguridad de los datos y subenfatizan el aspecto de confidencialidad , y dado que el bloqueo ha implicaciones inmediatas para la accesibilidad, incluso puede ser desfavorecido por algunas organizaciones con sitios web.

Tom
2018-07-19 18:56:57 UTC
view on stackexchange narkive permalink

En teoría , los ataques de fuerza bruta deberían limitarse a un conjunto muy pequeño de escenarios posibles, por la sencilla razón de que si su sistema de autenticación no protege contra ataques de fuerza bruta está roto, punto .

En realidad , muchos sistemas de autenticación están dañados y, de hecho, permiten la fuerza bruta Ataques. Sus protecciones son inexistentes o no son efectivas.

Además, como adivinaste correctamente, puedes realizar un ataque de fuerza bruta si controlas la ejecución, es decir, si tienes la base de datos de contraseñas, o el texto cifrado o lo que sea más datos que desea atacar.

También hay un subconjunto específico de ataques de fuerza bruta en los que se omite la protección contra la fuerza bruta. En el hardware, a veces puede desactivar la protección de fuerza bruta o devolver el dispositivo a un estado anterior (por ejemplo, recuperarse de la copia de seguridad) e intentarlo de nuevo. Este es un escenario muy específico con condiciones muy limitadas para que funcione, pero hace unos años hubo un caso de iPhone en el que el FBI probó este enfoque, aparentemente con éxito.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...