Tus passwords son suprayectivas

En un proceso de auditoría de seguridad de una aplicación tienes que enfrentarte muchas veces contra esa desafiante pantalla que pide Login y Password para dejarte continuar en el sistema. Tras probar los fallos clásicos de SQL Injection, XPath Injection, LDAP Injection y compañía, toca el turno de pasar a los "sospechosos" habituales, buscando los famosos admin/admin o guest/guest. Si llegado a este punto no hemos conseguido entrar dentro habrá que pensar en sacar el Railgun y pensar en algún ataque de fuerza bruta, donde nos vamos a encontrar con dos problemas fundamentales: Los captcha y los bloqueos de cuenta por número de fallos. Y de esto venía a hablaros hoy.

Captchas sí, ¿pero cuándo?

Cuando se diseña una Intranet para una empresa, casi nadie quiere hacer uso de captchas. Son un dispositivo molesto que incide negativamente en la productividad de la aplicación, ya que el tiempo de registro se va a incrementar y suele ser algo muy molesto para cualquier persona el tener que rellenar cualquier captcha. Sin embargo, la mejor de las estrategias a la hora de mostrar el captcha es tenerlo oculto hasta que no se han producido, por ejemplo dos o tres fallos en la contraseña, lo que denotaría una situación de posible intento de averiguar la contraseña. Esto es algo que hacen por ejemplo Google o Microsoft en sus servicios online, y que pocas veces lo encontramos en una Intranet.

Bloqueo sí, ¿pero cuándo?

La otra barrera que nos solemos encontrar es que cuando intentas hacer una fuerza bruta a una cuenta, siempre te encentras con el bloqueo temporal de la misma tras 3, 5 o 10 intentos fallidos de contraseña, lo que evita que se pueda hacer el ataque de fuerza bruta. Esto suele inutilizar cualquier ataque de fuerza bruta contra una determinada cuenta, y nuestras esperanzas de saltarnos el control de acceso un poco más tocadas, pero...¿no hay solución?

El bloqueo de dirección IP

Una de las grandes injusticias en el bloqueo de la cuenta es que es el usuario el que sale perjudicado, ya que no podrá entrar por culpa de que alguien está intentando romper su contraseña, así que se buscan estrategias para minimizar el impacto negativo de esta medida de seguridad. En algunos sistemas se hace el bloqueo por dirección IP, obligando a los atacantes a cambiar de máquina o dirección IP para continuar con el proceso de fuerza bruta. Sin embargo, cuando alguien realiza esto desde una red de una organización, por ejemplo una universidad, podría dejar a todos los usuarios de esa red que compartan la misma dirección IP pública sin poder conexión. Esto hace que los bloqueos de dirección IP se hagan con poca frecuencia, y deberían realizarse siempre de forma temporal y muy ajustada.

f(usuario)->password es suprayectiva

En todo este proceso, hay algo que no todos tienen en cuenta, y es la extraña relación suprayectiva entre los usuarios y las contraseñas. Si no te acuerdas de las funciones suprayectivas no importa, ya que es tan sencillo como que si B es el conjunto de todas las contraseñas de un sistema de validación, y A es el conjunto de todos los nombres de usuarios, se da siempre la extraña y útil relación de que A tiene más elementos que B y que, con un alto grado de probabilidad, más de un elemento de A apuntará al mismo elemento de B, tendiendo a 1 la probabilidad de que esto pase a mayor número de usuarios haya en el sistema. O lo que es lo mismo, que mientras que los usuarios no se pueden repetir en un sistema, sí lo pueden hacer sus contraseñas.

Figura 1: Una función suprayectiva

 

Política de contraseñas

Si a esto sumamos que existe una política de contraseñas que limita el espacio de contraseñas posibles, quitando de la ecuación todas aquellas que son fáciles de averiguar por no ser complejas, se reduce el número de ellas que puede introducir un usuario por el teclado, y aumenta el grado de compartición de contraseñas, haciendo que las más fáciles de introducir con una determinada política de seguridad sean las más utilizadas. Por ejemplo, en un sistema que exija que la contraseña sea de al menos seis caracteres y alguno sea un número, podríamos confiar en que la clave de acceso elegido por la mayor parte de los miembros de la manada acabe siendo 123456, por eso de que hay algún número y seis caracteres.

Bloqueo por password

Sin embargo, si cambiamos nuestra visión del formulario de acceso del tradicional LOGIN y PASSWORD, por uno mucho más metafórico que diga PASSWORD y LOGIN, sólo deberíamos saber uno de los miembros de la especie que habita en esa Intranet que ha optado por no complicarse la vida. Para resolver esto, lo que deberemos hacer es un ataque de fuerza bruta o de diccionario al nombre, manteniendo la contraseña elegida para la prueba siempre estable.

¿Y cuál es la ventaja de atacar al nombre en lugar de atacar a la contraseña?

Fácil, mientras que la mayoría de las webs tienen protección contra el ataque de fuerza bruta a una cuenta de usuario, contando el número de fallos de passwords en un proceso de login de un usuario, hay una gran cantidad de ellos que te permiten poner una password y probar usuarios al infinito hasta que des con alguno de los miembros que ha optado por elegir esa contraseña tan cómoda que cumple con la política de seguridad. 

Try it yourself!

Si quieres comprobar esto en tus aplicaciones, busca el proceso de login, fija una password y prueba 10 usuarios distintos. Si no te ha bloqueado la conexión, entonces tu web es vulnerable a un proceso de fuerza bruta al nombre de usuario y deberías elegir una password lo menos común y repetida posible.

Saludos Malignos!