Hace poco, mientras probaban una plataforma de cadena de bloques en busca de vulnerabilidades, nuestros expertos de Kaspersky Blockchain Security descubrieron que el proceso de recuperaci\u00f3n de la contrase\u00f1a de la plataforma era vulnerable a un ataque mediante la enumeraci\u00f3n de nombres de usuario. Los desarrolladores de la web necesitaban conocer este tipo de ataque y sus peligros.<\/p>\n
Las aplicaciones web con un sistema de autentificaci\u00f3n mediante usuario y contrase\u00f1a suelen incluir varios componentes que interact\u00faan con la base de datos del usuario: la ventana de inicio de sesi\u00f3n (por razones obvias), el formulario de registro (para evitar que se dupliquen los nombres de usuario) y la p\u00e1gina para restablecer la contrase\u00f1a (para asegurarse de que la cuenta correspondiente existe). Si los desarrolladores no implementan estas funciones de forma segura, los atacantes pueden usarlas para determinar si cierto usuario existe en la base de datos.<\/p>\n
Antes era habitual que los desarrolladores implementaran todas estas funciones sin ning\u00fan tipo de protecci\u00f3n, por lo que los atacantes podr\u00edan utilizar una lista de nombres de usuario y un programa que los introduc\u00eda uno a uno. Con el tiempo, para deshacerse de los ciberdelincuentes, los desarrolladores comenzaron a aplicar estrategias de protecci\u00f3n como los captchas<\/em>, un l\u00edmite en los intentos de inicio de sesi\u00f3n y el uso de asteriscos u otros medios para ocultar ciertos detalles de la respuesta.<\/p>\n En las aplicaciones web modernas, la ventana de inicio de sesi\u00f3n generalmente cuenta con este tipo de protecci\u00f3n. Sin embargo, a veces faltan los formularios de registro y las p\u00e1ginas para restablecer la contrase\u00f1a. Adem\u00e1s, los desarrolladores web no siempre consideran que la presencia o ausencia de un usuario en la base de datos se pueda determinar seg\u00fan lo que tarde en responder el servidor. Por ejemplo, si el nombre de usuario aparece en la base de datos, la respuesta del servidor tarda 2 milisegundos. Si no, la respuesta tarda el doble: 4 milisegundos. Para un ser humano, la diferencia es indetectable, pero para las herramientas de enumeraci\u00f3n automatizadas, es f\u00e1cil de detectar.<\/p>\n Un ataque de enumeraci\u00f3n permite a un atacante comprobar si existe un nombre en concreto en la base de datos. Esto no permitir\u00e1 que el ciberdelincuente acceda de forma inmediata, pero s\u00ed le concede la mitad de la informaci\u00f3n necesaria. Por ejemplo, para configurar un ataque de fuerza bruta, no tendr\u00e1 que buscar por parejas de nombres de usuario y contrase\u00f1as, solo tendr\u00e1n que encontrar la contrase\u00f1a de un nombre de usuario verificado, lo que le ahorrar\u00e1 tiempo y esfuerzos.<\/p>\n Recuerda tambi\u00e9n que casi todos los servicios utilizan las direcciones de correo electr\u00f3nico como nombres de usuario. Por tanto, el usuario promedio utiliza el mismo nombre de inicio de sesi\u00f3n en muchos sitios web y no todos se toman la seguridad tan en serio; de hecho, las noticias sobre filtraciones de nombres de inicio de sesi\u00f3n y contrase\u00f1as son muy comunes. Las recopilaciones consolidadas de los datos de estas filtraciones est\u00e1n disponibles en los foros de los ciberdelincuentes. Adem\u00e1s, los usuarios suelen usar las mismas contrase\u00f1as en diferentes sitios web, por lo que, despu\u00e9s de asegurarse de que existe un nombre de usuario en tu sitio web, un atacante puede introducir una recopilaci\u00f3n como esa para comprobar si las contrase\u00f1as del usuario existen en otros sitios web y luego intentan acceder con esas contrase\u00f1as<\/p>\n Adem\u00e1s, los operadores del spear phishing<\/em> a menudo emplean ataques de enumeraci\u00f3n durante la fase de reconocimiento. Despu\u00e9s de comprobar que su objetivo tiene una cuenta en tu servicio, pueden enviar un correo electr\u00f3nico supuestamente de tu parte, pidi\u00e9ndole al usuario que cambie su contrase\u00f1a y que se vincule a una p\u00e1gina de phishing<\/em> que se parece a tu sitio web. Cuando el cliente desprevenido introduce una nueva contrase\u00f1a, tambi\u00e9n tiene que confirmar la antigua, y de esta forma proporcionan a los estafadores todo lo que necesitan.<\/p>\n \u00bfAlguna vez te has percato de c\u00f3mo responden los sitios web modernos al env\u00edo de un formulario para restablecer una contrase\u00f1a? No dicen \u201cTe hemos enviado un enlace para restablecer tu contrase\u00f1a\u201d o \u201cEl correo electr\u00f3nico especificado no est\u00e1 en nuestra base de datos\u201d, como sol\u00edan hacerlo los sitios web. En su lugar, escriben: \u201cSi este correo electr\u00f3nico existe en nuestra base de datos, te enviaremos un mensaje con un enlace\u201d. En otras palabras, los sitios web no confirman ni desmienten expl\u00edcitamente la existencia del nombre de usuario. Hicieron este cambio precisamente para protegerse contra los ataques de enumeraci\u00f3n.<\/p>\n Asimismo, no es necesario que expliques con detalle en la ventana de inicio de sesi\u00f3n que el usuario ha introducido una contrase\u00f1a incorrecta o que ese nombre de usuario no existe en el sistema. Simplemente di que no se ha encontrado esa combinaci\u00f3n de nombre de usuario y contrase\u00f1a. No es lo ideal desde el punto de la experiencia del usuario: por ejemplo, a m\u00ed me desespera cuando olvido qu\u00e9 correo electr\u00f3nico utilic\u00e9 para el registro, pero estoy bastante seguro de la contrase\u00f1a, o viceversa, pero el sitio web no me indica en qu\u00e9 campo estoy equivocado. Sin embargo, con la seguridad la comodidad casi siempre se ve sacrificada, y en el caso de los servicios de autenticaci\u00f3n, se justifica un sesgo de seguridad menor.<\/p>\nLos peligros de un ataque de enumeraci\u00f3n de nombres de usuario<\/h2>\n
C\u00f3mo protegerte de un ataque de enumeraci\u00f3n<\/h2>\n