Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author attacked the Facebook Workplace (enterprise internal Facebook product) phone application on Android. In particular, they hit the Oauth flow.

The OAuth flow for phone applications with Facebook is quite weird because of the usage of deep links or custom URIs. The challenge is that an attacker can register the same handler and receive the callback with the access token. Facebook did a few things in order to prevent this from happening:

• When using a Facebook webview, the redirects can only go to specific URL schemes, with some of the generic ones (fb{APP_ID}://) are blocked.
• If in a mobile browser, then a confirmation is made to the user to make sure they actually want to redirect.
• Check for specific headers for Facebook servers.
• Check for unique values associated with the application for the Facebook SDK.

Some of the defenses were not universal though. They were expected to be validated by a specific app or URI. The second option above (validation of mobile browser redirect) was not implemented in the Workplace OAuth flow. As a result, an attacker could register the fbWP_APP_id:// scheme for the application then steal the access token from the end of the OAuth flow.

The fourth (final) protection mentioned above was the required usage of an Android specific key for the SDK. By providing an empty key in the header for Workplace, the dialog would not appear (as it does on Facebook) and the access token would be sent back. Another terrible bug!

The first protection above blocks redirects to non-allowlisted URI schemes, such as fb and fb-work. The author noticed that by specifying xd_arbiter in the redirect_uri parameter and change the URI scheme to fb:// the redirect would succeed.

For whatever reason, having this specific combination of inputs bypassed the allowlist protections for the fb:// and several other URIs. Then, if the an attacker had control over a specific URI on the phone, they could force the redirect to occur with the access token, resulting in a major compromise.

Overall, the threat of a malicious URI handler is really interesting and not something that I considered. It was cool to see how Facebook tried to protect against the abuse of this in the authorization process but also how it was bypassed. Good finds!