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.
*****************************************************************************************
*****************************************************************************************
Esto quien te lo ha programado? Esta claro que tu no
ResponderEliminar@Andujar, mi equipo de Eleven Paths. Como todos los productos. ¿Te gusta? Si quieres que te programemos algo ponte en contacto con nosotros }:)
ResponderEliminarSaludos!
¿Cómo los puedo contactar?
EliminarKiero 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
ResponderEliminarLuis Enrique, esa acción puede constituir un delito. No siga por ese camino o saldrá escaldado.
ResponderEliminarLa jungla de las apps, Microsoft (en este caso) deja a qualquiera que cree una aplicacion que pida permisos de acceso a las cuentas o365?
ResponderEliminarLo 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
@chema alonso como creo ese sappo porque ahora en 2020 no aparece verde , no entiendo es diferente
ResponderEliminar