martes, marzo 08, 2016

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

Llegados al punto anterior, en el que el usuario tiene que elegir entre conceder o denegar los permisos, es cuando termina la última medida de seguridad. Si el usuario decide concederlos, a partir de ese momento - y hasta que le sean revocados los permisos o caduquen sin ningún proceso de renegociación el AccessToken - la app podrá acceder a todos los recursos indicados en la lista de SCOPES.

Figura 21: Atacando cuentas de MS Office 365

Cuando el usuario hace clic en YES, en el end-point marcado en Redirect-URI se recibirá el AuthCode, que le permitirá a la aplicación solicitar el AccessToken. Esto se hace de esta forma porque en la petición del AccessToken debe indicarse el Application ID y el Secret para demostrar que se es el dueño de la app que quiere los permisos. La petición que se debe realizar para solicitar el AccessToken es como la que sigue a continuación:
POST common/oauth2/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
grant_type=[authorization_code]&code=[authCode]
&client_id=[client_id]&client_secret=[secret]
&redirect_uri=[redirect_uri]
Como se puede ver, se solicita que se entregue lo que sería el AccessToken en Redirect_URI, y si el AuthCode entregado es el correcto, lo que devolverá el servidor del IDP, en este caso Microsoft, será un token de acceso.

JWT (JSON Web Token)

En el caso de Microsoft el token llega en formato JWT que no es más que una cadena URL Encoded en BASE64 con una estructura de tres partes: Cabecera, Payload y Firma. En la siguiente captura se puede ver un token recuperado en formato JWT.

Figura 22: JWT completo con las tres partes

Si decodificamos la cadena en BASE64, podremos ver que en el payload está la información completa de toda la sesión de acceso. En ella aparece la información de la app, la lista de permisos y los datos de la cuenta que ha concedido los permisos.

Figura 23: Información decodificada del payload

Este token, en bruto, tendrá que ser enviado en cada petición de acceso a los recursos de la cuenta en el IDP siempre que se haga una llamada a la API de Office365 o Windows Live. Las peticiones habrán de ser hechas siguiendo el formato que aparece a continuación:
GET https://login.microsoftonline.com/common/oauth2/authorize
HTTP/1.1
Host: login.microsoftonline.com
Authorization: Bearer [Access_Token]
Usando la API de Office365 para acceder a los recursos

Todo este proceso está automatizado en nuestra plataforma, así que cuando el usuario acepta - besa al sappo - lo que aparecerá en la lista de tokens serán todos aquellos válidos que pueden utilizarse para acceder a los datos de la cuenta.

Figura 24: AccessToken válido en Sappo para acceder a una cuenta Office365

En el caso de Office365, el acceso es completo a los correos electrónicos, así que podemos listar todos los mensajes en la bandeja de entrada o en cualquiera de las carpetas de la cuenta. Para que sea más sencillo lo hemos integrado en un interfaz de usuario que permite navegar por el buzón.

Figura 35: Acciones implementadas con ese AccessToken en Office365

Entre las opciones, está también la de borrar el mensaje de correo y, lo que es más peligroso, la de enviar mensajes desde la cuenta.

Figura 26: Envío de correos usando la API de Office365 y el AccessToken

Este tipo de técnicas se han utilizado para conseguir engañar víctimas y robar dinero cuando se introduce un mensaje manipulado en medio de una conversación leal para, por ejemplo, conseguir que el pago de un trabajo se haga en otra cuenta bancaria - controlada por el cibercriminal - en lugar de la cuenta de la víctima.

Figura 27: Lista de contactos de la cuenta

Estas tareas se podrán realizar mientras que el acceso a la aplicación en Office365 no sea revocado. Para ello, el usuario debería irse a la parte de Configuración de Office 365, y en la sección de Permisos de Aplicación, eliminar el acceso a sus datos de cualquier app no deseada.

Figura 28: Lista de todos los correos. Se pueden visualizar completos y con adjuntos.

Una cosa curiosa es que las nuevas apps con permisos concedidos tardan un rato en aparecer y, cuando aparecen, no tienen por qué permitir acceder a la información detallada de la app. Lo más normal es pedir información de los permisos de la app y no poder acceder a ellos en Office365 si la app es maliciosa como las que creamos aquí.

Figura 29: Aplicación con permisos en el perfil del usuario de Office365

El funcionamiento es análogo, pero no exactamente igual, en Windows Live, así que en la siguiente parte veremos un caso usando otra implementación de Microsoft.

Autores: Chema Alonso & Pablo González

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

7 comentarios:

andujar dijo...

Esto quien te lo ha programado? Esta claro que tu no

Maligno dijo...

@Andujar, mi equipo de Eleven Paths. Como todos los productos. ¿Te gusta? Si quieres que te programemos algo ponte en contacto con nosotros }:)

Saludos!

luis enrique hernandez uribe dijo...

Kiero saber de algun programa para espiar whatsapp las conversaciones d mis contactos ppdria decirme algun programa k si funcione x favor o d donde lo puedo descargar

Anónimo dijo...

Luis Enrique, esa acción puede constituir un delito. No siga por ese camino o saldrá escaldado.

Inseguro y Navegando dijo...

Gracias!

gnxrsa dijo...

La jungla de las apps, Microsoft (en este caso) deja a qualquiera que cree una aplicacion que pida permisos de acceso a las cuentas o365?

Lo persigue de alguna forma? No deve ser muy complicado con algun algoritmo de checkeo de comportamiento de la aplicacion... aunque supongo que cuando sea dirigido es imposible basarse en comportamiento.

Se puede limitar en las cuentas corporativas de o365 el hecho de restringir a que aplicaciones van a poder dar permisos los usuarios de la empresa?

tnks

Unknown dijo...

¿Cómo los puedo contactar?

Entradas populares