Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree

Durante este mes de agosto, el equipo de Microsoft Research ha publicado un interesante paper sobre las "Pre-Hijacked Accounts", o lo que es lo mismo, todas las posibilidades para dejar una cuenta "pre-hijacked" en un servicio, antes de que un usuario se saque la cuenta en esa plataforma. Y me ha parecido más que interesante. Es decir, que el atacante entra antes que la víctima en una plataforma web y le deja la cuenta configurada para poder controlarla en todo momento.

Figura 1: Pre-Hijacked Accounts: o cómo robar una cuenta

a un usuario antes de que se la cree

El estudio lo que trata es de anotar cuáles son las posibles vulnerabilidades y los posibles ataques que se pueden hacer dependiendo de cuál es el proceso de creación de una cuenta, de federación del login, y de los sistemas de recuperación de contraseñas que se pueden realizar.

Figura 2: Papper sobre Pre-Hijacked Accounts en Web Services

Supongamos que el login de un sitio web permite tener un login mediante usuario y contraseña - donde el usuario es el alias del correo electrónico - pero este sitio también permite tener un acceso federado con un IDP externo - como Google o Microsoft, por ejemplo -, y luego se pueden poner mecanismos de recuperación de contraseñas basados, por ejemplo, en número de teléfono.  En estos casos, dependiendo del proceso de verificación y onboarding de nuevas cuentas, se pueden realizar diferentes ataques de Pre-Hijacking que merece la pena conocer.

Figura 3: Libro de "Hacking Web Technologies Silver Edition" 3ª Edición

de 0xWord, escrito por Enrique Rando, Pablo Gonzalez, Ricardo Martin,

Chema Alonso y Amador Aparicio.

En este esquema, se pueden dar los siguientes ataques, que os resumo a continuación, a ver si soy capaz de resumirlos. En todos ellos, asumimos que existen dos rutas para crear una cuenta, pero que son para la misma cuenta. Es decir, que acabará existiendo la posibilidad de autenticarse con contraseña, o por medio del login federado del IdP.

1.- Classic-Federated Merge Attack

En este escenario, el atacante se crea una cuenta utilizando el login de usuario (basado en e-mail) y contraseña. El atacante no puede verificar el e-mail porque le llega el correo al dueño de la dirección de correo electrónico.

Figura 4: Cuentas con ID/Email/Passwor/IdP/Session & Phone Number

Sin embargo, la cuenta se queda creada sin verificar y en un futuro, el dueño del e-mail utiliza la ruta de creación vía IdP. El sistema activa la cuenta, y el atacante tiene el login/password que utilizó por la ruta (inconclusa) de la verificación vía correo electrónico.

2.- Unexpired Session Attack

En este caso el usuario se crea la cuenta sin utilizar la verificación de e-mail ni el IdP, ya que el sistema permite utilizar otro ID verificado como el número de teléfono, pero el correo electrónico que queda configurado es el de la víctima. El atacante consigue crear la cuenta y es totalmente funcional, con lo que puede abrir una sesión y mantenerla abierta "ad infinitum" mediante un script. La víctima, en el futuro, crea la cuenta con el sistema federado o recupera la contraseña por medio del correo electrónico y entra en una aplicación que tiene una sesión abierta que vigila todo lo que hace.

3.- Trojan Identified Attack

En este caso, se crea un identificador, y no se permite crear una cuenta por medio de un IdP Federado. No obstante, una vez creada la cuenta con un id y password, se pueden añadir cuentas para Federar el login. La cuenta está pre-troyanizada (por ejemplo con una app que tiene un token OAuth - como hacíamos en Sappo - de esta plataforma). Cuando el usuario intenta crear su cuenta con e-mail, ya existe un identificador con su correo electrónico asociado, así que tiene que recuperar la contraseña y tomar acceso, pero la cuenta está troyanizada.

4.- Unexpired e-mail Change Attack

En este caso, el atacante se crea la cuenta con un identificador o con el e-mail de la víctima sin que sea necesario verificarlo. El atacante, a pesar de haber creado una cuenta con el e-mail de la víctima, lanza un proceso de cambio de correo electrónico asociado a la cuenta que no concluye. La víctima quiere crearse la cuenta, no puede, recupera la contraseña y toma control de la cuenta. El atacante, en el futuro, puede terminar el proceso de cambio de correo electrónico y tomar control de cuenta.

Figura 5: Ejemplos de ataques de Pre-Hijacked Accounts

En este caso, se puede dar la casuística de que el atacante cambie el e-mail asociada, pero no resetee la contraseña porque la plataforma permite hacer login con un e-mail enviando un link de click-to-login, lo que permitiría que la víctima siguiera con su id/password pero que el atacante entre con click-to-login.

5.- Non-Verifying IdP Attack

En este caso hablamos de un servicio que permite a una empresa tener su propio IdP (como por ejemplo hacen la empresas con Office365 cuando quieren tener su IdP empresarial controlado). El atacante se crea un IdP propio, y abre una cuenta siguiendo la ruta federada de su propio IdP. Después, añade un usuario y contraseña para la ruta no federada utilizando el e-mail de la víctima. Cuando la víctima recupera la contraseña para esa cuenta, el atacante tiene acceso con el login de la cuenta federada.

Figura 6: Más ataques de Pre-Hijacked Attacks

Esto puede hacerse también cuando las cuentas permiten un identificador y varias cuentas federadas. Así, se crea la cuenta con el identificador de la víctima y se controla con una cuenta federada. Después, la víctima inicia sesión con su cuenta, pero usando la ruta de federación de IdP. Si la plataforma permite varias cuentas de login federadas, entonces funcionaría igualmente.

6.- E-mail verification Trick

Este punto es interesante, ya que en muchos de los ejemplos, la plataforma no deja crear la cuenta sin verificar el correo electrónico. En estos casos, se puede crear una cuenta con un identificador de e-mail controlado por el atacante, y luego abusar el proceso de "cambiar de e-mail", lo que permitiría tener la cuenta, y el e-mail de la víctima en proceso de cambio, lo que si la víctima toma control, tendrá su cuenta creada... y troyanizada.

Figura 7: Suposiciones para cada ataque, acciones de atacante y víctima.

En todos estos ejemplos, además, hay que tener en cuenta que aunque se deje una cuenta creada pero no habilitada, habilitada pero no verificada, o creada, verificada pero no transferida, si se puede configurar un número de teléfono como forma de recuperar la contraseña, para hacer click-to-login por SMS, o se pueden configurar otros e-mails durante el proceso, la plataforma podría dejar suficiente información a configurar en una cuenta para hacer un pre-hijacked de la cuenta que en el futuro se saque la víctima. Os recomiendo el paper, que ha sido una lectura muy interesante para este domingo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)