Secuestro de cuentas

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Problema de autorización

Se debe intentar cambiar el email de una cuenta y el proceso de confirmación debe ser examinado. Si se considera débil, el email debe cambiarse al del objetivo previsto y luego confirmarse.

Problema de normalización Unicode

  1. La cuenta de la víctima prevista: victim@gmail.com
  2. Se debe crear una cuenta usando Unicode
    por ejemplo: vićtim@gmail.com

Como se explica en this talk, el ataque anterior también podría realizarse abusando de proveedores de identidad de terceros:

  • Crear una cuenta en el proveedor de identidad tercero con un email similar al de la víctima usando algún carácter unicode (vićtim@company.com).
  • El proveedor tercero no debería verificar el email.
  • Si el proveedor de identidad verifica el email, quizá puedas atacar la parte del dominio, por ejemplo: victim@ćompany.com, registrar ese dominio y esperar que el proveedor de identidad genere la versión ascii del dominio mientras la plataforma víctima normaliza el nombre de dominio.
  • Iniciar sesión a través de ese proveedor de identidad en la plataforma víctima, que debería normalizar el carácter unicode y permitirte acceder a la cuenta de la víctima.

Para más detalles, consulta el documento sobre Unicode Normalization:

Unicode Normalization

Reutilización de token de restablecimiento

Si el sistema objetivo permite que el enlace de restablecimiento sea reutilizado, deben hacerse esfuerzos para encontrar más enlaces de restablecimiento usando herramientas como gau, wayback, o scan.io.

Antes de la toma de control

  1. Deberías usar el email de la víctima para registrarte en la plataforma y establecer una contraseña (se debe intentar confirmar la cuenta, aunque la falta de acceso al correo de la víctima puede hacer esto imposible).
  2. Hay que esperar hasta que la víctima se registre usando OAuth y confirme la cuenta.
  3. Se espera que el registro normal sea confirmado, permitiendo el acceso a la cuenta de la víctima.

Mala configuración de CORS para toma de control

Si la página contiene mala configuración de CORS podrías ser capaz de robar información sensible del usuario para tomar control de su cuenta o hacer que cambie información de autenticación con la misma finalidad:

CORS - Misconfigurations & Bypass

CSRF para toma de control

Si la página es vulnerable a CSRF podrías ser capaz de hacer que el usuario modifique su contraseña, email o autenticación para que luego puedas acceder a ella:

CSRF (Cross Site Request Forgery)

XSS para toma de control

Si encuentras una XSS en la aplicación podrías ser capaz de robar cookies, local storage, o información de la página web que podría permitirte tomar control de la cuenta:

XSS (Cross Site Scripting)

  • Attribute-only reflected payloads on login pages can hook document.onkeypress, exfiltrate keystrokes through new Image().src, and steal credentials without submitting the form. See Attribute-only login XSS behind WAFs for a practical workflow.

Same Origin + Cookies

Si encuentras un XSS limitado o un subdomain take over, podrías manipular las cookies (por ejemplo fijándolas) para intentar comprometer la cuenta de la víctima:

Cookies Hacking

Atacar el mecanismo de restablecimiento de contraseña

Reset/Forgotten Password Bypass

Restablecimientos por preguntas de seguridad que confían en nombres de usuario suministrados por el cliente

Si un flujo de “actualizar preguntas de seguridad” recibe un parámetro username aunque el llamante ya esté autenticado, puedes sobrescribir los datos de recuperación de cualquier cuenta (incluyendo admins) porque el backend típicamente ejecuta UPDATE ... WHERE user_name = ? con tu valor no confiable. El patrón es:

  1. Inicia sesión con un usuario desechable y captura la cookie de sesión.
  2. Envía el nombre de usuario de la víctima más las nuevas respuestas mediante el formulario de restablecimiento.
  3. Autentícate inmediatamente a través del endpoint de login por preguntas de seguridad usando las respuestas que acabas de inyectar para heredar los privilegios de la víctima.
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (admin dashboards, dangerous stream-wrapper features, etc.) is now exposed without touching the real answers.

Los nombres de usuario enumerados pueden entonces ser apuntados mediante la técnica de overwrite mencionada arriba o reutilizados contra servicios auxiliares (FTP/SSH password spraying).

Response Manipulation

Si la respuesta de autenticación puede reducirse a un booleano simple, intenta cambiar false a true y comprueba si obtienes acceso.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. El header Host se modifica tras iniciar una solicitud de restablecimiento de contraseña.
  2. El header proxy X-Forwarded-For se altera a attacker.com.
  3. Los headers Host, Referrer y Origin se cambian simultáneamente a attacker.com.
  4. Tras iniciar un restablecimiento de contraseña y optar por reenviar el correo, se emplean los tres métodos mencionados.

Response Manipulation

  1. Code Manipulation: El código de estado se altera a 200 OK.
  2. Code and Body Manipulation:
  • El código de estado se cambia a 200 OK.
  • El cuerpo de la respuesta se modifica a {"success":true} o a un objeto vacío {}.

Estas técnicas de manipulación son efectivas en escenarios donde se utiliza JSON para la transmisión y recepción de datos.

Change email of current session

De this report:

  • El atacante solicita cambiar su correo por uno nuevo
  • El atacante recibe un enlace para confirmar el cambio de correo
  • El atacante envía el enlace a la víctima para que lo haga clic
  • El correo de la víctima cambia al indicado por el atacante
  • El atacante puede recuperar la contraseña y tomar el control de la cuenta

This also happened in this report.

Bypass email verification for Account Takeover

  • El atacante inicia sesión con attacker@test.com y verifica el correo al registrarse.
  • El atacante cambia el correo verificado a victim@test.com (sin verificación secundaria al cambiar el correo)
  • Ahora el sitio permite que victim@test.com inicie sesión y hemos eludido la verificación de correo del usuario víctima.

Old Cookies

Como se explica in this post, era posible iniciar sesión en una cuenta, guardar las cookies como usuario autenticado, cerrar sesión y luego iniciar sesión de nuevo.
Con el nuevo inicio de sesión, aunque se generaran cookies diferentes, las antiguas volvían a funcionar.

Trusted device cookies + batch API leakage

Los identificadores de dispositivo de larga duración que regulan la recuperación pueden ser robados cuando una batch API permite copiar subresponses no legibles en destinos escribibles.

  • Identificar una trusted-device cookie (SameSite=None, long-lived) usada para relajar las comprobaciones de recuperación.
  • Encontrar un first-party endpoint que devuelva ese device ID en JSON (p. ej., un OAuth code exchange retornando machine_id) pero que no sea legible cross-origin.
  • Usar una batch/chained API que permita referenciar subresponses anteriores ({result=name:$.path}) y escribirlos en un sink visible para el atacante (page post, upload-by-URL, etc.). Example with Facebook Graph API:
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • Cargar la batch URL en un <iframe> oculto para que la víctima envíe la cookie trusted-device; la referencia JSON-path copia machine_id en el post controlado por el atacante aunque la respuesta OAuth sea ilegible para la página.
  • Replay: establece la cookie del dispositivo robado en una nueva sesión. Recovery ahora trata al navegador como confiable, exponiendo a menudo flujos más débiles “no email/phone” (p. ej., carga automatizada de documentos) para añadir un email del atacante sin la contraseña ni 2FA.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks