SAPPO: Spear APPs to steal OAuth-tokens (1 de 4)

Durante los últimos años hemos visto una gran cantidad de ataques a organizaciones que han terminado con el robo de información y la exposición pública de la compañía. Compromisos de seguridad famosos que han pasado a formar parte del ideario de nuestra profesión para constatar la necesidad de invertir en más medidas de seguridad y conseguir sistemas más resistentes a los ciberataques. Aún cuando en origen es totalmente correcta esta aproximación, la ejecución de dicha inversión sigue siendo el verdadero problema de fondo, ya que mientras algunos responsables de seguridad invierten grandes cantidades de dinero en nuevas tecnologías, muchos de los "BASICS" permanecen si ser resueltos totalmente. 

Figura 1: Estructura del ataque SAPPO

Si revisamos los orígenes de muchos de los ataques más famosos de nuestros últimos años, veremos que en la gran mayoría muchos de los ataques comenzaron por un sencillo ataque de Spear Phishing con el que el atacante consiguió acceso a una identidad interna de la organización que no tenía configurada más medida de seguridad que un usuario y contraseña, sin contar con un segundo factor de autenticación o un segundo factor de autorización (2FA&2FA). 

Como vamos a ver en este artículo, esto aún puede ser mucho más complejo de proteger aún si nos centramos en los ataques que tienen como objetivo el robo del acceso a las cuentas de correo electrónico sin necesidad de robar el usuario y la contraseña, es decir, el robo de tokens OAuth que permitan a un atacante saltarse hasta el 2FA ya que por diseño el acceso vía API usando OAuth está fuera de estas protecciones. Esto es lo que vamos a atacar con SAPPO y vamos a explicar en este artículo cómo funciona.

Robo de Cuentas en IDPs

En este artículo, los IDP (Identity Providers) que hemos seleccionado han sido Office 365 y Windows Live, pero el trabajo es análogo para otros IDP como Twitter, Facebook, Google, etcétera, como veremos en trabajos posteriores. El objetivo de las técnicas de robo de tokens es conseguir acceso a los recursos vía API consiguiendo que el usuario, en lugar de entregar un conjunto de credenciales válidas, entregue solo un AuthCode OAuth que permita el acceso a sus datos.

Si pensamos en las formas en las que puede estar protegida una cuenta Office365 contra un ataque nos podemos encontrar con diferentes escenarios.

- Solo 1FA: En este caso la cuenta Office 365 está protegida únicamente por usuario y contraseña, con un único primer factor de autenticación. El atacante puede robar las credenciales vía ataques de Spear Phishing. 

- 2FA y Applicaction Passwords: En este caso la cuenta está protegida por un 2FA y solo aquellos clientes con un Applicaton Password estarán exentos de pasar por el 2FA. El atacante debería robar un application password del lugar donde esté almacenada o tener acceso a 2FA. 

- 2FA sin Application Passwords: La cuenta tiene un 2FA y no se hace uso de Application Passwords, así que o se consigue el acceso a usuario, password y 2FA o se consigue hacer un ataque de red para hacer un hijacking de sessión. Como vimos en el artículo dedicado a SSLStrip+, el dominio de Outolook.com tenía una pequeña ventana de tiempo para poder atacar la sesión HTTPs con HSTS. 

- 2FA sin acceso a red o 2FA: Si la cuenta es remota, y no hay acceso ni a la red para hacer un ataque de man in the middle ni al 2FA parece el entorno más complicado.

En todos los casos, si centramos los esfuerzos en el robo de tokens OAuth, todos los escenarios serían igual de sencillos ya que ninguna de las medidas de protección que se usan en unos y otros aplican al escenario de ataque que vamos a explicar.

Spear Phishing: Ataques y contramedidas

Los ataques de Phishing se basan en engañar al usuario para conseguir que introduzca las credenciales dentro de una web falsa. Estas webs están alojadas en dominios fraudulentos que simulan ser el entorno conocido por la víctima, así si se deseara robar una cuenta de Office365 se simularía el login de Office 365. Si se deseara robar un Apple ID, se simularía la web de Apple ID. Así de sencillo.

Figura 3: Un sitio web de Phishing robando datos de Apple ID

Para conseguir atraer víctimas a estos sitios, se pueden hacer dos tipos de ataques. El masivo, conocido como SPAM Phishing, que no va personalizado y se envía a una gran cantidad de destinatario esperando tener éxito basado en probabilidades o el dirigido a una víctima concreta, llamado Spear Phishing.

En este último caso, el correo electrónico está personalizado con detalles que hagan pensar a la víctima en la veracidad del mensaje. Es en este último tipo de mensajes donde los atacantes ponen sus esfuerzos cuando estamos en un escenario de APT contra una organización.

Figura 4: Un correo de Spear Phishing personalizado para una víctima concreta

Para evitar los ataques de Phishing, SPAM Phishing & Spear Phishing se utilizan diferentes medidas de seguridad. Estas son variadas, y se aplican a diferentes niveles de la organización:

- Awareness: Consiste en educar al usuario a reconocer uno de estos ataques de Phishing, SPAM Phishing y Spear Phishing. Para ello se les explica que no deben dar sus datos a sitios web que les envían por correo electrónico, que deben fijarse en el dominio de los servidores a los que se conectan, etcétera. Por desgracia, ni son totalmente correctas estas recomendaciones en todos los casos, ni las organizaciones luego fomentan su cumplimiento, ya que el uso masivo y descuidado que se hace de los mensajes de correo electrónico en las empresas va en contra de ellas. 

Es común ver a agencias contratadas por equipos de marketing contratados para eventos, consultoras de RRHH o asesores varios que envíen correos electrónicos a los empleados de una organización solicitando una acción o registro en una web. Es decir, mientras que por un lado hacemos "awareness" para reconocer los ataques de phishing, por otro lado se entrena a los empleados para caer en el phishing. 

- Tecnología AntiPhishing: Tanto a nivel de correo electrónico, como a nivel de navegador, se integran medidas para detectar correos electrónicos de SPAM Phishing como sitios de Phishing. Herramientas como los filtros AntiPhishing de Google Safe Browsing o el Microsoft Smart Screen vienen integrados para detectar webs que estén haciendo Phishing.  Sin embargo, cuando hablamos de ataques dirigidos tipo Spear Phishing, la cosa es mucho más complicada de detectar, y en casi todas las ocasiones pasa por debajo del radar de estas tecnologías. 

- Segundo Factor de Autenticación: El último bastión para evitar el robo de las cuentas es proteger las identidades digitales. Para ello, lo ideal sería proteger una cuenta con tres factores, siendo uno algo que se conozca (password), otro algo que se tenga (teléfono o token físico) y otro tercero algo que se sea (biometría). Algunas organizaciones utilizan smartcards protegidas por biometría o certificados digitales almacenados en tokens USB que se abren con biometría y passwords. La elección dependerá de cada sistema. En el caso de Office 365/Windows Live se puede poner un 2FA para proteger las cuentas.

Por desgracia, ninguna de estas tres medidas va a ser útil para proteger a los usuarios contra ataques destinados a robarte los tokens OAuth, tal y como vamos a ver.

OAuth en pocas palabras

OAuth es un protocolo de autorización implementado como OAuth2 en la mayoría de los IDPs de Internet. Se basa en un sistema de autorización en el acceso a los recursos por parte del usuario dueño de la identidad, o lo que es lo mismo, se basa en el que el usuario de YES a permitir que una aplicación acceda a sus datos. Por resumir el proceso, existen tres fases:

Figura 5: Esquema de funcionamiento de OAuth

1.- Solicitud de Acceso

En esta primera parte, una aplicación registrada en el IDP, es decir, en el caso de que queramos acceder a los datos de Office365 de usuarios una aplicación registrada como de Office365, genera una URL con la lista de permisos que quiere que un usuario le de. Para ello se genera una URL que lleva una lista de SCOPES (ámbitos de acceso) que será donde tendrá concedido el permiso una vez el usuario lo autorice.

Figura 6: SPAM Phishing de falsa cuenta de Spotify lleva a un servidor hackeado

Figura 7: El servidor hackeado hace un redirect a una URL para solicitar permisos de acceso

2.- Aprobación de Acceso

Cuando el usuario hace clic o es redirigido a la URL de solicitud de acceso, se le mostrará una pantalla en la web del IDP (Microsoft, Google, etc...) en la que se le informará de los accesos que se le están solicitando y en la que deberá decir YES o NO. Esa es la última barrera antes de conceder a la aplicación solicitante todos los datos que está pidiendo. 

Figura 8: El usuario no ha iniciado la sesión pero la lista de SCOPES está en la URL

Cuando el usuario no ha iniciado sesión e los servicios del IDP, entonces la web que aparecerá será similar a la del login, tal y como se ve en la figura. Sin embargo, en la URL se puede ver como hay una lista de permisos que son los que la URL del punto 1 ha generado.  Por el contrario, si el usuario ya ha iniciado sesión previamente, se irá directamente a la parte de aprobación o no de los permisos de acceso, en una web como la que se ve a continuación.

Figura 9: Falsa app de Spotify solicitando acceso a la cuenta en Windows Live

Si el usuario hace clic en YES, entonces el servidor del IDP generará un AuthCode en esta fase que le permitirá a la aplicación solicitar ya el token de acceso a los recursos.

3.- Consecución del Acceso

Si el usuario concedió e AuthCode en la parte anterior, ahora es cuestión de la aplicación consumidora solicitar el AccessToken. Para ello deberá usar su ApplicationID, su Secret, su AuthCode y solicitar que el AccessToken le sea enviado a un EndPoint. Será ahí donde el IDP le hará llegar vía API el token válido que da acceso a los recursos solicitados en la lista de SCOPES. La aplicación, quedará registrada en la lista de apps con permisos concedidos. En la siguiente imagen se ve una app maliciosa aprobada en una cuenta de Windows Live.

Figura 10: App maliciosa aprobado su acceso vía OAuth2 en Windows Live

A partir de ese momento, ya se podrá acceder vía API a cada uno de los recursos del IDP que hayan sido aprobados, como veremos en las siguientes partes de este artículo.

Autores: Chema Alonso & Pablo González

*****************************************************************************************

- SAPPO: Spear APPs to steal OAuth-tokens (1 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (2 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (3 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (4 de 4)

*****************************************************************************************