The Connect with Facebook functionality of Microsoft is vulnerable to the OAuth Covert Redirect attack.
redirect_uri parameter can be modified by the attacker making the Facebook OAuth token leak to a domain not controlled by Microsoft and in this way steal user private information accessible through the token.
A basic undestanding of the OAuth flow is useful to better understand this post, a very good guide can be found here. When reading the guide focus the attention on “Grant Type: Authorization Code” and the “Grant Type: Implicit” which are by far the most common approaches.
PROBING FOR WIDE REDIRECT_URI
redirect_uri parameter is very important because it represents the url to which the authorization_code/access_token (based on Grant Type) is sent. If we are able to change the value of the
redirect_uri and not to make the OAuth flow to fail (because of authenticity checks on the
redirect_uri) we could leak the token/code to a domain controlled by us.
Original Oauth request:
- Completely different domain: redirect_uri=
- Different subdomain: redirect_uri=https://
- Different folder: redirect_uri= https://profile.live.com
The use of a completely different domain is very unlikely to work while in some cases the use of a different folder or subdomain is allowed. Our current payload is:
SEARCHING FOR OPEN REDIRECT
The ability to leak the the token/code to a different subdomain/folder is not useful per se, however it provides to the attacker a wider attack surface to find an Open Redirect vulnerability. An Open Redirect endpoint is a url which redirects the user to a parameter value without any validation. The idea is to find an Open Redirect in *.live.com/* which would leak the token to a domain that we can control.
After some google dorking I have noticed that the endpoint:
g.live.com/0HE_TRACKSTAR_ENUS9/<number> issues a 302 Redirect to external domains based on
Through a 30 line of ruby script I have enumerated the possible domains to which I could leak the token
Among these domains there are some which can be purchased like g.live.com/0HE_TRACKSTAR_CSCZ9/75011 which redirects to http://staysafe.org/ .
Making the user issue a GET request to
&scope=user_photos+user_videos&client_id=441348565910475&ret=login will leak the token/code to http://staysafe.org/.
###CHANGING THE FLOW###
Referencing to the guide that I have pointed out before the
Grant Type used by Microsoft is the
Authorization Code one. Using the exploit we can leak the
Authorization Code but in order to access the protected information we need to exchange the
Authorization code with the
Access Token. However in order achieve this we need to know the
client_secret which we aren’t able to get since it is stored on the Microsoft servers. In order to bypass this limitation we can change
Grant Type to the
Implicit one which directly provides the
Access Token to the url in the redirect_url field.
With the Facebook SDK this can be done by adding the parameter response_type=token.
###STEALING THE TOKEN### An attaker could:
- Purchased the domain
extract the token;
- Make the victim issue a GET request to
###TRIGGER THE EXPLOIT WITHOUT INTERACTION###
The Connect with Facebook functionality can be used in the
Microsoft Sway application where I found a second vulnerability which would allow an attaker to make the user issue arbitrary GET requests by just viewing a
This is possible because, crafting a particular request in the Add image functionality, an attacker is able to persistently control the
src attribute of an img tag. I tried to exploit this kind of vulnerability to get an XSS however the quotes were escaped and the
- 15 May 2015 Vulnerability reported to the Microsoft Security Team
- 4 August 2015 Vulnerability patched
- 25 August 2015 Got reward of 1000$