DeepSec 2019 Talk: Oh! Auth: Implementation Pitfalls of OAuth 2.0 & the Auth Providers Who Have Fell in It – Samit Anwer
Since the beginning of distributed personal computer networks, one of the toughest problems has been to provide a seamless and secure SSO experience between unrelated servers/services. OAuth is an open protocol to allow secure authorization in a standard method from web, mobile and desktop application. The OAuth 2.0 authorization framework enables third-party applications to obtain discretionary access to a web service. Built on top of OAuth 2, OpenID Connect is a helpful “identity layer” that provides developers with a framework to build functional and secure authentication systems. OpenID Connect can perform identity authorization and provide basic profile information for different clients, from web and mobile apps to JavaScript clients.
In this race of providing OAuth/Open ID Connect based access to assets, authorization service providers have been forced to release half-baked solutions in the wild because of which relying parties and users face myriad of issues ranging from authorization code compromise (unauthorized resource access) to account takeovers.
The key to adding authorization or Single Sign-On (SSO) measures to your app is to ensure you are balancing security with usability. Developers likely make trade-offs when making decisions about specific implementation – and there are a lot of decisions to make. Developers still want to double down on security to avoid flaws in 2.0, paying attention to things like session management, encryption/obfuscation of stored data and IDs, and securing the source code of an app.
In this work we will discuss common malpractices that relying party devs perform when implementing OAuth/OpenID based relying party solutions. However, all is not in the hands of relying party developers, the authorization service providers have a big role to play as well.
There are mainly 4 entities involved in a typical OAuth setup: relying party/client, user/resource owner, resource provider, and authorization server. In this work, we discuss the goof-ups that each of these entities can introduce with special focus on vulnerabilities that the authorization server can introduce.
The highlight: We present our case study on OAuth authorization providers and detail the issues we found in their solutions. This includes a vulnerability in Microsoft’s authorization server – login.windows.net. As can be seen in the PoC video the auth code can be replayed to generate fresh access tokens and id tokens. Moreover, the code verifier is not being validated which can lead to a compromise of the access/id tokens on native apps which use Microsoft’s identity provider – login.windows.net.
We asked Samit a few more questions about his talk.
Please tell us the top 5 facts about your talk.
- OAuth is an open standard for token based delegated access. It is widely used across platforms and is customizable to a great extent. In this talk we will learn what OAuth is and what it brings to the table. We will go over various grants OAuth offers and identify which one to use when.
- The talk also focuses on the security aspects of the protocol and highlights common implementation mistakes made by Client app/relying party and authorization server devs.
- In the talk I will be discussing some attacks on OAuth as a result of these mistakes and their mitigation as well.
- The talk will cover a demo of a vulnerability I found in Microsoft’s Identity server which results in the attacker gaining access to victim’s resources for as long as s/he likes.
- The talk also covers some best practices to reduce damage if access tokens/auth codes leak in order to facilitate defence in depth.
How did you come up with it? Was there something like an initial spark that set your mind on creating this talk?
The spark was a vulnerability I found with Microsoft’s Identity Provider, which had a faulty PKCE implementation because of which the attacker could get life long access to a victim’s resources.
Why do you think this is an important topic?
OAuth is widely used by all platforms including web, desktop and native apps. Its security is a common concern for devs of auth servers, relying parties and end users. This makes it a very suitable and interesting topic to discuss.
Is there something you want everybody to know – some good advice for our readers maybe?
The talk will provide a good overview of OAuth from the need of it to various attacks observed in the wild. For anyone looking to implement or adopt OAuth this is definitely a must attend.
A prediction for the future – what do you think will be the next innovations or future downfalls when it comes to your field of expertise / the topic of your talk in particular?
A lot of work is happening with regards to doubling up on security for OAuth by weaving more layers into the basic OAuth mechanism. Token binding, PKCE and Claimed HTTPS scheme URI redirections are some examples. In the future I would expect some innovative attacks coming forth to counter these defenses.
Samit Anwer is a Web and Mobile Application security researcher. He joined Citrix as Security Engineer soon after completing his Master’s degree from IIIT Delhi in Mobile and Ubiquitous Computing in 2015. He is actively involved with vulnerability research in Web/Mobile apps and has responsibly disclosed several security vulnerabilities with Google Cloud Print API, XSS filter evasion on IE 11/MS Edge, code execution on Microsoft Windows 10, Microsoft’s OAuth 2.0 implementation and buffer overflows on MS Edge/IE 11.
He is an active member of the Null Bangalore Chapter, IEEE community and has spoken on various security topics at the following venues: DEFCON China, Beijing (2018), BlackHat Asia, Singapore (2018), AppSec USA, Orlando (2017), CodeBlue, Tokyo (2017), c0c0n X, Kerala (2017) and Null meets (2015, 2016, 2017, 2018)
His technical interests lie in using static program analysis techniques to mitigate security and performance issues on mobile/web apps, breaking web/mobile apps, and researching on cutting edge authentication and authorization mechanisms.