OAuth: La amenaza invisible

El pasado viernes 25 de enero de 2019 se celebró la V Sh3llcon. Este congreso es especial para mí, ya que se celebra en la ciudad de Santander, una tierra muy conocida por mí. Por quinto año tuve el honor de poder estar allí, aunque fuera en un viaje de ida y vuelta y con mucha ‘prisa’. Unos minutos antes de empezar la charla le comenté a Sergio: “Ya son 5 años y aquí seguimos…”. Sergio, que es el presidente de esta CON me respondió: “Ufff, sí…”. Vi el esfuerzo de todo el equipo en sus ojos. No ha sido fácil que Sh3llcon llegase al quinto año. Han sido pioneros en el norte y debemos seguir empujando. Como digo, para mí un honor.

Figura 1: OAuth "La amenaza invisible" en Sh3llcon V

Este año quería mostrar algunas de las cosas que hacemos en el departamento de Ideas Locas. Siempre resulta curioso contar que trabajas en un departamento de Ideas Locas. La primera reacción es de sorpresa, pero una vez que defines lo que se hace en el departamento y que somos la fase de pre-innovación, la gente asiente y entiende.

Ideas, pruebas de concepto ágiles, pruebas de un solo día, artículos, cosas que pueden acabar en patentes, ideas que acaban en producto o servicios, difusión de la parte tecnológica, etcétera. Un día a día en el que uno no tiene tiempo de aburrirse, sobre todo si aparece el boss y dice: "Chicos, reunión de urgencia que tenemos que probar una idea nueva."

En esta edición, como pone en el título, lo que quería contar es la evolución de SAPPO, la herramienta de Ethical Hacking para explotación de servicios por medio de OAuth, tanto en su versión 1, como 2. Una idea que surgió para la RootedCON 2016, pero que ha seguido siendo evolucionada.


Figura 2: RootedCON 2016 "Solo hay que besar un Sappo"
De ahí evolucionamos la plataforma para crear el ataque de RamsomCloud O365 que utiliza el propio Kevin Mitnick en sus conferencias, y se basa en una idea a la que todo el equipo tiene mucho cariño.


Figura 3: Kevin Mitnick explicando Sappo y Ransomcloud
En Santander quería mostrar cómo la idea surgió y cómo la idea fue evolucionando hasta llegar a la prueba con Twitter completa después de que Chema Alonso lo presentará en la pasada OpenExpo.

La charla en la Sh3llCON V

En la primera parte se hablaba de la evolución del phishing, de que esto ya no era una cosa que se trata de robarte credenciales con un ‘landing page cutre’. El phishing había ido evolucionando, buscando obtener información o buscando que el usuario realice algún tipo de acción beneficiosa para el atacante. Tras ver varios ejemplos, el más claro es el secuestro de WhatsApp Web a través de un QRCode, del cual ya hemos hablado desde el punto de vista técnico.

Figura 4: Esquema de QRCode Hijacking para WhatsApp Web

En resumen, hablamos del SPAM, del Spear Phishing, del Bar Spoofing, de los Punycode, de las WebView de las apps que no muestran dominio, de la codificación que no distingue una I (i mayúscula) de una l (L minúscula), etcétera. Se ve claramente una evolución en las técnicas.

Llegó la hora de OAuth

Lo primero es entender que OAuth es un protocolo abierto, el cual nos va a permitir el proceso de autorización segunda de una API. Las aplicaciones que utilizan este protocolo son las de escritorio, las de web y las móviles. En OAuth versión 1 las móviles y de escritorio encontraban algunos problemas.

Figura 5: Esquema de funcionamiento de OAuth 1

Vimos la diferencia entre OAuth 1 y 2, tal y como se puede ver en las siguientes imágenes. Menos flujo en el caso de la versión 2 del protocolo y los scopes bien definidos.

Figura 6: Esquema de funcionamiento de OAuth 2

Cuando uno pregunta a la gente si conoce OAuth, en muchas ocasiones nos encontramos una respuesta negativa. ¿Dónde se puede encontrar? ¿Lo utilizamos como usuarios diariamente? Pues la respuesta es afirmativa en la mayoría de los casos. Si nos fijamos en la siguiente imagen. Son sólo algunos ejemplos de donde podemos encontrar OAuth.

Figura 7: Sitios que permiten el uso de OAuth

Como se puede ver está en la mayoría de servicios de hoy en día. Durante la charla hablamos de cómo fue los primeros pasos en el trabajo de OAuth. Las típicas preguntas que surgen cuando uno quiere empezar a revisar un tema o empezar a investigar cierto tema. Nos fuimos a la documentación de las API de Twitter y Microsoft (para Office 365 y Outlook).

La revisión de la documentación es fundamental, una primera etapa de aprendizaje y de investigación que debemos llevar a cabo para poder llegar a un objetivo previo o bien definido. Para empezar la investigación, lo primero, aparte de hacer uso de la documentación, es crear una aplicación o app OAuth dentro de la plataforma en la que se quiera trabajar.

Figura 8: Creación de una aplicación OAuth en Microsoft Office365

La parte de conocimiento sobre las peticiones que hay que hacer es fundamental en el uso de las apps OAuth. De esto ya se habla largo y tendido en el artículo de Sappo: Spear APPs to steal OAuth-Tokens. Haciendo un breve resumen tenemos que tener estos conocimientos básicos en mente:

1. App creada en la plataforma. Esto nos aportará un APP ID y un Secret.

2. Se realiza una petición HTTP, en el caso de Microsoft de tipo GET. Se indica el listado de scopes, el APP ID o Client ID y el Redirect URI o dirección de Callback. Esta es la petición que la víctima realizará en un ataque SAPPO. Esta es la petición que el cliente realizará contra el proveedor de identidad. Esto lleva al usuario a un sitio web del proveedor dónde le indicará que la App X quiere tener ciertos permisos. Aquí está el proceso de autorización. Si la víctima acepta o dice ‘Sí’ se hará entrega desde el proveedor a nuestra dirección de Callback de un AuthCode.

Figura 9: Petición de autorización de permisos OAuth

3. Con el AuthCode en poder del cliente, éste puede ir directamente al proveedor para indicarle que quiere recoger un Access Token. Dependiendo del proveedor (Microsoft o Twitter) nos pueden entregar un Access Token o Refresh Token. Es decir, uno o dos tokens.

Figura 10: Petición de Authorization_code

4. En este instante se obtiene el Access Token y se dispone de autorización para acceder a funcionalidades de la cuenta, en función de los scopes que nos hayan autorizado.

Se llevó a cabo en la charla una demo sobre SAPPO en Office 365, aunque ya hemos visto en este blog diferentes ejemplos. Hacemos un recopilatorio:


Figura 11: Robo de Office365 y acceso a los e-mails


Figura 12: Ransomcloud Office365
SAPPO y Twitter

La última demo fue con el SAPPO y Twitter. Totalmente interactiva. Cuando se envía el e-mail para que la víctima haga clic en el enlace que se le envía, el que solicitará el AuthCode al proveedor, si se autoriza la app, ya se tendrá acceso a diferentes funcionalidades. En este caso, se podrá hacer uso de los tuits, publicar, leerlos, leer mensajes directos, eliminar a usuarios que se siguen desde la cuenta y, lo más importante.

Figura 13: PoC de Sappo con Twitter

Lo más importante es que desde la API de Twitter si se bloquea un usuario, si éste te sigue dejará de hacerlo. Esto es algo bastante importante, ya que si un usuario es “infectado” y autoriza a una app a poder bloquear followers puede que se encuentre la cuenta totalmente a 0 en lo que a followers se refiere. Si te ganas la vida de influencer puede ser un riesgo grande.

Referencias de Sappo

[Post] Sappo: Spear APPs to steal OAuth-Tokens
[Post] Sappo: RansomCloud O365
[Post] Cómo se ha hecho a Gmail el ataque de SPAM masivo por OAuth 2

[Post] Google alerta de las apps NO verificadas al pedir permisos OAuth. Microsoft Office 365 aún debe mejorar un poco.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.