Notas del curso Hacking ético: descubriendo vulnerabilidades en aplicaciones web

• Autenticación: proceso que permite a un usuario de un sitio web u otro servicio similar verificar que es quien dice ser.
• Autorización: Proceso que permite verificar si un usuario que solicita un recurso o acceso cumple con los criterios necesarios.
• Perfil o rol: atributo de identificación de usuario basado en sus acciones, permisos o nivel de privilegios.

Método que sirve para dar fe de que alguien es quien dice ser. Puede ser:

• Usuario y contraseña.
• Certificados digitales.
• API keys.

Este tipo de error en WordPress nos está indicando que existe el usuario director:

Y este que no existe el usuario:

Lo correcto sería que no diera pistas y además limitase los intentos erróneos:

• Uso de diccionarios de usuarios y contraseñas.
• Pruebas secuenciales: ¿Problema? Posibilidad de detección, DoS y bloqueo de cuentas de usuarios.
• Diccionarios en Kali: /usr/share/wordlists/

Un diccionario muy común es rockyou.txt, basado en un leak que presenta las contraseñas más utilizadas de usuarios:

Medusa

medusa -h <IP/Domain> -u <Usuario> -P password.txt -M http -m DIR/login -T 10

Hydra

hydra <IP> http-form-post "/path/to/login/login.php:user=^USER^&pass=^PASS^:Error login" -L usuarios.txt -P passwords.txt

Burp suite

En el curso se muestra un vídeo con Kali Linux iniciando sesión en http://192.168.1.99/multillidae/index.php?page=login.php con Burp Suite interceptando el tráfico. En Burp, enviamos la petición del POST al Intruder, y en la pestaña Positions indicamos con qué campo queremos hacer la fuerza bruta (elige el tipo de ataque Sniper). En la pestaña Payloads se añaden las claves con las que queremos probar. Cuando tenemos la petición con la credencial correcta, podemos copiarla y pegarla en el navegador.

Durante el registro y en la posterior gestión de contraseñas del usuario se debe tener en cuenta:

• Evitar el uso de contraseñas “débiles”:
  • Longitud superior a 8 caracteres.
  • Uso de caracteres alfanuméricos combinados con caracteres especiales.
  • Historial de contraseñas.
  • Contraseñas presentes en leaks (fugas de información) públicos.
• Solicitud de la contraseña actual para modificarla.
• Implementación de segundo factor de autenticación 2FA.

Dado un listado de usuarios, se prueba la misma contraseña para cada uno de ellos.

Lo que se persigue con este ataque es:

• Búsqueda de información sobre usuarios de la app.
• Evasión de posibles bloqueos de cuentas (probamos una contraseña en varios usuarios y no varias contraseñas con el mismo usuario).
• Patrones de contraseñas predecibles.
• Ejemplos:
  • Mayo2021
  • Empresa21
  • Verano19

Las cookies son identificadores de sesión que se asigna a un usuario para poder reconocer a dicho usuario en peticiones futuras.

• El protocolo HTTP por diseño no almacena un estado de las sesiones activas.
• Identificadores de sesión para guardar el estado de las comunicaciones entre cliente y servidor.
• Cookies asignadas en el lado del servidor y almacenadas en el lado de cliente.

Si no tuviéramos una cookie, en una plataforma de compra online no pondríamos mantener un carrito de la compra, por ejemplo.

• Estructura de la cookie de sesión:
  • No debe ser predecible.
  • Resistente a tampering (alteración).
  • Tiempo de expiración adecuado.
  • Atributos de seguridad correspondientes.
• Tiempo de validez de la sesión.
• Funcionalidad de logout.

• Interceptación a nivel de red.
• Cross-Site Scripting.
• Web-Cache.

Si una aplicación web sufre de una vulnerabilidad de Cross-Site Scripting, es posible que alguien esté consiguiendo la cookie de sesión de un usuario a través de un alert de JavaScript, por ejemplo.

• Uso del método HTTP TRACE (devuelve las primeras cabeceras que se enviaron en la petición) habilitado en el servidor para obtener la cookie de sesión del cliente.
• Uso de peticiones XMLHttpRequest para enviárselas a la víctima para que esta realice una petición con el método TRACE al servidor.
• Evasión de cabeceras de restricción como HTTPOnly.

En las primeras cabeceras, veremos el valor de la cookie de sesión. Con esta cookie de sesión, el atacante podría identificarse como la víctima.

Por esto es importante eliminar el método TRACE de los métodos soportados por el servidor.

• La aplicación no reasigna una cookie de sesión nueva en cada iteración.
• Se aceptan cookies creadas por el usuario.
• Ingeniería social.

Los atributos de seguridad que deberían de tener las cookies:

• Secure: solo se transmite la cookie sobre un canal cifrado.
• HTTPOnly: cookie solo accesible a través de HTTP (evitar JavaScript).

En la siguiente captura vemos como la cookie de sesión JSESSIONID no tiene ningún atributo de seguridad:

En esta captura sí:

• Almacenamiento de información en la cache del navegador.
• Sesiones abiertas, credenciales,datossensibles,etc.
• Posibilidad de acceder al almacenamiento local de la cache o utilizando el botón atrás.
• Uso de cabeceras en el lado del servidor:
  • Cache-Control: must-revalidate, no-cache, no-store, max-age=0, s-maxage=0
  • Expires: 0
  • Pragma: no-cache

En la siguiente captura vemos cabeceras del servidor que indican al navegador web que no utilice la caché:

De esta manera no correríamos el riesgo de almacenar en local credenciales, números de cuenta, tarjetas de crédito, etc.

Verificar si un usuario tiene o no permisos para aplicar cierta acción sobre la aplicación.

• Basado en el modelo de roles de los usuarios de la aplicación:
  • Administrador.
  • Usuario básico.
  • Usuario no autenticado.
• Basado en permisos o acciones sobre la aplicación:
  • Administrador.
  • Editor.
  • Visitante.

Acceso a datos de otros usuarios o acciones con el mismo nivel de permisos o rol asignado.

POST /account/viewSettings HTTP/1.1 https://mywebsite.es/es/campaign/id/30
Host: www.tubanco.com
Cookie: SessionID=CookieSession https://mywebsite.es/es/campaign/id/29

username=usuario1

Esto es un problema cuando el identificador de sesión va en la URL.

Acceso a datos de otros usuarios o acciones con diferente nivel de permisos o rol asignado.

Generalmente de un usuario básico con permisos de visualización a un usuario con permisos de edición o administración.

POST /account/deleteEvent HTTP/1.1
Host: www.tubanco.com
Cookie: SessionID=CookieSesion

EventID=3000

POST /admin/addUser HTTP/1.1
Host: www.example.com
Cookie: SessionID=CookieSesion

userID=usuario1&role=3&group=admin

Acceso a contenido de otros objetos dentro de la misma aplicación.

• Identificadores internos de la aplicación.
• Variables autoincrementables.
• Registros de bases de datos.
• Archivos internos.

https://tubanco.com/consulta?transferencia=12345
https://tienda.com/pagina?itemmenu=234
https://files.com/files/12345642/documento.pdf

Utilizar diferentes métodos HTTP para acceder al mismo recurso.

Petición:

nc www.example.com 80
GET /admin HTTP/1.1
Host: www.example.com

Respuesta:

HTTP/1.1 403 Forbidden
Date: Mon, 04 Oct 2021 22:44:11 GMT

Si cambiamos el método de la petición:

nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

Podríamos obtener incluso una cookie de sesión:

HTTP/1.1 200 OK
Date: Mon, 04 Oct 2021 22:44:11 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, Mon, 04
Oct 2021 22:44:11 GMT; domain=www.example.com
Connection: close

• Burpsuite.
• Herramientas de desarrollador del navegador.
• Cookie Quick Manager

• Enumeración de usuarios, fuerza bruta y política de contraseñas.
• Revisar las características de las cookies de sesión y su tiempo de validez.
• Parámetros de sesión en las URLs.
• Funcionalidad de Logout.
• Fijación de sesión, Cache del navegador y método TRACE.
• Pruebas de autorización cruzada (para comprobar si desde un usuario no privilegiado se puede acceder a otro no privilegiado y privilegiado).
• IDORS.
• Sobrecarga de métodos HTTP