Account Takeover Due to Misconfigured Login with Facebook/Google

Dec 20, 2017 — 3 min read

The mobile applications that uses Login with Facebook or Login with Google, I’ve found more than 70% of them suffers a misconfiguration in validating the tokens at their backend which leads to account takeover.

What’s the common issue in Facebook and Google Login?

The access tokens generated by Facebook or ID tokens generated by Google are not validated properly at the backend. These tokens are not validated if they are generated from their own app or not. This means any malicious app can takeover the user accounts on the misconfigured targeted app. Let’s discuss the technical part of both Facebook and Google login.

Facebook Login

A mobile app generally uses Facebook SDK for login into the app. Now when a user login with Facebook, Facebook generates an access token which is then sent to the backend for token validation. This is how an app generally validates the token:

https://graph.facebook.com/v2.10/me?fields=verified,email,name,id&access_token=XXXXXXXXXXXXXXX

The response of this token validation url gives this:

{
  "verified": true,
  "email": “[email protected]”,
  "name": "Bhavuk Jain",
  "id": “XXXXXX”
}

The parameter verified shows it as true. This parameter verified is highly misinterpreted. The true value means the token is valid but this doesn’t mean the access token is generated by the target app or not and therefore allows a malicious app to gain access to the target's app user account using the access token which was generated for the malicious app.

The proper way of authenticating the access token as mentioned by Facebook deep inside the documentation is this:

Creating a HMAC 256 using access token and app secret and then sending it to the API will help in preventing this misconfiguration:

https://graph.facebook.com/v2.10/me?fields=verified,email,name,id&access_token=XXXXXXXXXXXXXXX&appsecret_proof=XXXXXXXXXXXXX

This is the correct way of validating the access tokens.

More info here: https://developers.facebook.com/docs/graph-api/securing-requests

There’s one more way of validating the access token. Just compare the app id in the response with one of the whitelisted app ids. (Not recommended though).

Similarly in Google Login, Google generates an ID token and this is how developers generally validates it:

https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjkzOXXXXXXXXXX

Response of this API:

{
 "azp": “XXXXX.apps.googleusercontent.com",
 "aud": “XXXXX.apps.googleusercontent.com",
 "sub": "1000017729808XXXXXX”,
 "email": “[email protected]”,
 "email_verified": "true",
 "at_hash": "GfILIXhViTXXXXXXXXXX",
 "iss": "https://accounts.google.com",
 "iat": “XXXXX”,
 "exp": “XXXXXX”,
 "name": "Bhavuk Jain",
 "picture": "https://lh4.googleusercontent.com/-P3L8oCL4OhM/AAAAAAAAAAI/AAAAAAAAAMs/1ia6G7mh0lg/s96-c/photo.jpg",
 "given_name": "Bhavuk",
 "family_name": "Jain",
 "locale": "en",
 "alg": "RS256",
 "kid": “XXXXX”
}

Most of the times, the developers forget to compare the value of aud with the whitelisted ones. The aud represents the app id that has generated this token. This should be validated if the aud value belongs to the known apps or not.

Proof of Concept/Impact of these Misconfigurations

Any malicious app can takeover the user accounts of the misconfigured targeted app, given that the user has accessed the malicious app and logged in with either Facebook or Google. For example, let’s say there is a competitor of Uber, “XYZ” app. There’s a high probability that a user is common to both Uber and XYZ. If XYZ app has a misconfiguration either with Facebook/Google Login, Uber can access the user accounts of XYZ’s app using the access tokens of their own customers.

How this issue could be prevented solely by Facebook/Google:

In the access token validation APIs, if they make it mandatory to pass secret token in order to process the access token and fetch user data, all the apps will get secured automatically. I also raised this issue to Facebook but they don’t consider this as an issue because it’s the developer’s job to properly authenticate the tokens.

A few apps in which I found this misconfiguration includes Instacart, Stackoverflow, GroupMe by Microsoft, Smartsheet, Waze by Google, Boozt Fashion etc. Most of the companies had take this issue as P1 and paid accordingly. But there are a few applications that don’t consider this as an issue and the vulnerability still exists which includes Snapdeal, Freecharge, 9Gag, Udemy.

There are still hundreds of applications that suffer from this misconfiguration. If you found one, give me a high five on Twitter or just leave a comment here.

Share this post: