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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!