Principales ataques de tipo Username Enumeration

La enumeración de nombres de cuentas de usuarios (username enumeration) consiste en comprobar la existencia de cuentas de usuarios en la aplicación web. Algunos especialistas dicen que esto no es una vulnerabilidad por sí misma, otros expresan que sí. Independientemente de ello, los ataques de fuerza bruta (generalmente de tipo diccionario) contra las cuentas de usuario son más efectivas en la medida en que se acota el universo de datos a probar/combinar. Contar con un paquete de nombres de usuarios válidos, en teoría, debe  aumentar dramáticamente las probabilidades de encontrar pares usuario/contraseña válidos (alguno autores plantean que las combinaciones pueden reducirse a un 50%).

Los intentos automatizados de enumeración de nombres de cuentas de usuarios pueden provocar ataques de denegación de servicios por el número de peticiones y las acciones de bloqueo contra las cuentas de usuarios que la misma aplicación web puede ejecutar para defenderse.

La enumeración de nombres de cuentas de usuario es más peligrosa cuando simplemente se pueden recopilar los nombres de usuarios directamente de las aplicaciones web. Los pasos que hay que realizar posibilitan que la preparación del ataque de fuerza bruta sean más simples y silenciosos. A continuación se describirán los casos más representativos de los ataques de tipo username enumeration.

Análisis de mensajes de error en las funcionalidades de autenticación

Este es el problema más común que posibilita la enumeración de usuarios:

  • Comprobando la existencia de mensajes que revelan si la contraseña es correcta o no (figura 1): El especialista de seguridad debe intentar autenticarse con un nombre de usuario válido pero con una contraseña incorrecta. En este caso, la aplicación web no debería mostrar un mensaje del tipo “invalid password” o “contraseña incorrecta”.
  • Comprobando la existencia de mensajes que revelan si el nombre de usuario existe (figura 1): El especialista de seguridad debe intentar autenticarse con un nombre de usuario ficticio en la aplicación web. En este caso, la aplicación web no debería mostrar un mensaje del tipo “invalid Account”, “user is not active”, “usuario no válido”, “el usuario no existe”, etc.
  • Comprobando inferencias a partir de los mensajes: Si los mensajes no son coherentes en los casos 1 y 2, aun cuando hayamos comprobado que no muestran mensajes descriptivos. Un ciberatacante podría fácilmente inferir la respuesta ante un usuario ficticio o una contraseña incorrecta. Por ejemplo, en algunas instalaciones de WordPress ocurre lo siguiente:
    • Usuario Válido/Contraseña Falsa: Mensaje-> “Contraseña incorrecta.
    • Usuario Falso/Contraseña Falsa: Mensaje->  “Credenciales Incorrectas.
1

Figura 1. Los mensajes de errores específicos ayudan a los ciberdelincuentes a enumerar los nombres de las cuentas de usuarios.

Solución: Establecer un mensaje común para ambos casos, por ejemplo “Credenciales incorrectas”. Debe establecerse un mecanismo que bloquee temporalmente la dirección IP/nombre de usuario después de N intentos de autenticación.

Análisis de mensajes de error en las funcionalidades de recuperación de contraseñas

Las aplicaciones web proveen un mecanismo para que los usuarios que hayan olvidado su contraseña puedan recibir un enlace (generalmente a través del correo electrónico) para que puedan acceder a la aplicación web. Este formulario informa si el usuario existe en la aplicación web del siguiente modo (figura 2):

2

Figura 2. Instrucciones de recuperación de la contraseña de una cuenta de usuario.

  • En el caso de que el usuario que estemos probando sea válido, debe mostrarse un mensaje similar a: “Se han enviado más instrucciones a su dirección de correo electrónico.“ o “Your password has been successfully sent to the email address you registered with“.
  • Cuando el usuario no sea válido, generalmente se muestra un mensaje similar a: “Lo siento, xyz no se reconoce como nombre de usuario o dirección de correo electrónico.” o “email address is not valid or the specified user was not found“.

Es muy difícil que un ciberdelincuente use este método porque alertaría al usuario de que su cuenta está siendo manipulada por un tercero cuando reciba el mensaje con las instrucciones para recuperar su contraseña. En estos casos además se registra la dirección IP de la petición y cualquier malintencionado que utilice este método quedaría algo expuesto.

Solución: Interponer un CAPTCHA para acceder a la funcionalidad de recuperar la contraseña. De este modo será más difícil de automatizar la comprobación.

Análisis de mensajes de error en las funcionalidades de registro de usuarios

Las aplicaciones web proveen un mecanismo para impedir que se registren dos usuarios con un mismo nombre de cuenta. Durante este proceso es posible descubrir si el nombre de usuario ya está registrado en la aplicación web y por tanto si es válido para la realización de un ataque de fuerza bruta (figura 3).

3

Figura 3. Mensaje de error emitido por una aplicación web, durante el registro de un nuevo usuario, para alertar que ya existe una cuenta con el nombre h3nr7r4u1.

Solución: Interponer un CAPTCHA para acceder a la funcionalidad de registro de usuario. De este modo será más difícil de automatizar la comprobación.

Análisis de mensajes de error en el acceso a URI

Muchos CMS y aplicaciones específicas incorporaran los nombres de usuarios dentro de las URI. Se utilizan rutas como /?q=users/username, author/username/, entre otras. En este caso, puede realizarse un análisis de la longitud de la respuesta HTTP o simplemente, si la aplicación web lo permite, se puede consultar el código de respuesta HTTP que vería según exista o no el nombre de usuario en estemos probando (Figura 4). Una respuesta de código 200 ó 403 indicarán que la URI es correcta y por tanto el nombre de la cuenta de usuario es válido. Un 404 nos dirá lo contrario, que la ruta no existe.

4

Figura 4. Diferencias de código de respuesta HTTP ante la petición de una URI que contiene un supuesto nombre de cuenta de usuario.

Solución: Documéntate sobre como ofuscar o desviar cualquier petición de estas URI, especialmente si provienen de accesos anónimos. Los CMS tienen mecanismos y plugin diseñados para esto. Evita utilizar códigos específicos HTTP y ante cualquier error de acceso reenvíalo a una página de error genérico con código de respuesta 200.

Análisis de patrones de nombres de cuentas de usuario

Existen aplicaciones web que tiene una forma específica de articular los nombres de usuario, teniendo en cuenta por ejemplo los nombres y apellidos de los usuarios. Por ejemplo, en la OTG (OTG-IDENT-004) se menciona el siguiente ejemplo: si Freddie Mercury tiene un ID=“fmercury”, entonces lo más probable es que  Roger Taylor tenga por nombre de usuario “rtaylor.

Solución: Evita la utilización de patrones de nombres evidentes, trata de incorporarle algún elemento aleatorio (como un número al final) para dificultar la predicción del nombre de usuario.

Análisis del tiempo de respuesta ante contraseñas largas

Algunos servicios (OpenSSH) pueden mostrar una diferencia apreciable cuando se compara los tiempos de respuesta de los intentos de autenticación de cuentas de usuarios reales y falsas con contraseñas largas. Independientemente del mensaje que muestren, el tiempo es la clave en este caso para decidir, cuando el nombre de cuenta que estamos probando es real o no. Este mismo comportamiento puede ocurrir en una aplicación web, más allá de que probablemente el servidor web tenga un servicio de SSH vulnerable.

Solución: Interponer un CAPTCHA para acceder a la funcionalidad de autenticación. De este modo será más difícil de automatizar la comprobación.

Recopilación de nombres de cuentas de usuarios mediante ID´s consecutivos

Muchos CMS identifican las cuentas de usuarios con números consecutivos que incorporan dentro de la URI, en este caso los nombres de cuentas de usuario se toman mediante un análisis sintáctico del código HTML recibido mediante programas como cURL y comandos como grep, entre otros. Normalmente se asocia al usuario con el ID=1 como el admin y así sucesivamente. Un ciberatacante puede registrarse, ver el ID recibido por la aplicación web y en función de ello determinar el intervalo de páginas a descargar con nombres de cuentas de usuarios.

La vulnerabilidad no está dada porque aparezca un ID representando al usuario, el problema está cuando estos ID son secuenciales y fijos.

Solución: Documéntate sobre como ofuscar o desviar cualquier petición de estas URI, especialmente si provienen de accesos anónimos. Los CMS tienen mecanismos y plugin diseñados para ofuscar los números de ID. Si desarrollas tu aplicación web desde cero, asignarle un código aleatorio a cada usuario, independientemente del ID en la base de datos y utiliza este código. Puedes cambiar este código con cierta regularidad, de este modo será más seguro su acceso. Evita de paso tener usuarios por defecto con nombres admin y test (entre otros)

Recopilación de nombres de cuentas de usuarios mediante los Autores de artículos

Los CMS generalmente muestran el nombre de la cuenta de usuario del autor que escribe/envía/postea el artículo. Un simple proceso de análisis sintáctico permite recopilar directamente los nombres de cuentas de usuario.

Solución: Documéntate sobre como sustituir la firma de los artículos por un seudónimo o nombre completo en lugar de presentar directamente el nombre de la cuenta de usuario. Los CMS tienen plugin y técnicas para la realización de estas sustituciones.

Hasta aquí una selección de los principales problemas, errores y debilidades que pueden hacer vulnerable a una aplicación ante un ataque de enumeración de usuarios. Plugin y técnicas existen por decenas para cada CMS y tecnología existente, una simple consulta en Google puede ayudar a paliar cualquier dificultad que se presente de este tipo.

Debo confesar que tengo mis criterios sobre la casi inexistente traducción de este ataque al idioma de Cervantes. Tampoco quería colocar un nombre muy diferente por el que se le conoce para que el lector no tuviera dificultad en encontrar la información relacionada en Internet, pero en mi opinión debería denominarse Predicción de nombres de cuentas de usuario o Comprobación de nombres de cuentas de usuarios porque enumeración en español está más asociada a contar cosas. En fin, si tienes más información al respecto me encantaría poder leer tu opinión sobre esto.

En los siguientes enlaces puedes ayudarte a profundizar más en este tema:

  • Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004):  enlace
  • Username Enumeration Vulnerabilities: enlace
  • WordPress Username Disclosure, Vulnerability or Not?: enlace
  • How to Enumerate WordPress Users with WPScan: enlace

Espero que te haya gustado el artículo y te pueda ayudar a fortalecer la seguridad en tu aplicación web. Yo por mi parte he aprendido escribiéndola.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

2 comentarios en “Principales ataques de tipo Username Enumeration

  1. Pingback: WPScan a fondo para webmaster | Behique Digital

  2. Pingback: Guía de Pruebas de OWASP 4.0 | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s