OAuth 2.0 Auth Code Injection Attack in Action

[Music] hello my name is Micah Silverman I am a senior security hacks or for octa I work on our developer advocacy team and today I want to talk to you about a particular Roth attack called the authorization code injection attack now I'm not going to go into a lot of detail about OAuth and the various flows I will make sure to have a bunch of links down in the comments to get the introductory stuff if you're new to oh oh ah there's been a lot of conversation in the OAuth working group about mandating the pixi extension even for confidential clients and so that's why I thought it would be interesting to put together a practical example of this exploit and how pixie defeats it the authorization code flow for confidential clients has long been considered the most secure flow that there is and that is still true but pixie adds an extra degree of protection as we'll see if you're familiar with OAuth and the authorization code flow you know that for confidential clients there is a client secret and that protects the confidential client against most types of attacks so what is pixie going to give us that isn't already there to see that let's take a look at this attack to better understand it now first of all you see my terrific diagramming skills here this may look a little complex at first but let's just take a look at the overview of this attack and then we'll see it in action so we have a target user on the upper left and an attacker on the lower right the target user has been tricked into installing a malicious browser extension the target user is going to begin the login with Google as normal so down on the lower left we have a legitimate website that allows you to login with Google and on the upper right we have Google's authorization server and then finally in the middle there we have a centralized attack server that's part of this exploit so the target user kicks off login with Google as normal the browser extension intercepts and publishes the authorization code that gets sent back as part of the redirect now in the attacker side the attacker also begins a login flow with Google as normal this is important and we're going to discuss why and now the browser extension on the attackers machine intercepts the redirect and pauses the extension then retrieves the target users authorization code that was published to the attack server and then the browser extension makes the the browser follow the redirect URL with its original state but the injected authorization code from the target user since the code is valid and the state is valid the legitimate website exchanges the code for the tokens and now the attacker is logged in as the target user let's take a look at this in action on the top here I have Google Chrome running and the console on the top right is the console for the browser extension not the regular browser console now I'm showing here pay per call if you're not familiar with it it allows you to create a speaker profile if for people that give conference talks and I want to take a moment just to say that pay per call isn't doing anything wrong here but pay per call uses the authorization code flow and pay per call has a confidential o auth client so I wanted to demonstrate this in in a real-world sort of way so on pay per call I've created two speakers one is called hacks or dude with neo as the profile picture and the other is called rube dude and that is a picture from spongebob I'm not using any of these pictures with permission now neither one of these has established a session with any there's no authentication stage for any of them and these paper call URLs are publicly accessible without any kind of authorization now we're gonna start off with our rube here our target user going to interact with pay per call as they normally might oh and one thing I want to show you here the they both have these browser extensions installed the target user has this one called pre cats that just shows random pictures of cat gifts but unbeknownst to them they're this browser extension is is up to no good all right so I'm gonna go ahead and choose to log in with Google and I'm gonna start logging in as normal so I have this real Google account called hroub and let me go fetch rubes password here so I'm logging in as rube now the malicious browser extension has intercepted the authorization code and we can't let the browser use that authorization code because it's a one-time use code so what the browser extension does is dump the user back to the front door of where they started in this case paper call now the user might be confused because they're not logged in here but the beauty of this attack is that if they go and choose Google again they actually already have established a session with Google Google sees that they're authenticated and creates a new authorization code and let them authenticate so as an end user you might just think oh there was a glitch in the matrix there was some sort of network hiccup but now I'm authenticated all is right with the world in the meantime my attack server now has this intercepted authorization code and I can verify that over here by just doing a simple HTTP interaction with it and shows me the list of codes that it currently has waiting in a queue so up here on the hackers browser and in the Chrome browser I'm gonna log in with Google and this is an important part of the step an important part of the process because it's important that I establish a session with Google so that I can get a valid State so I'm actually logging in with a real account and let me look that one up there we go and now you can see that where I've ended up is in a logged in State as our rube and if we look in the browser history here we can see that it intercepted the original code and it's now replacing that original code with the code that it retrieved from the attack server so now we've effectively tricked the user with this browser extension the the legitimate target user and now our hacker has been able to log in as this legitimate user okay next thing that I want to do here is I want to logout from everything and start over and I want to demonstrate how pixie saves the client from this particular type of attack now fast-forward through this so you don't have to watch me logging out okay to continue on here I'm gonna use a client an OAuth client that my colleague Eric II put together for demonstration purposes and we're basically going to repeat this demonstration but we're gonna do it with this test client so that we can see how it works both with the regular authorization code flow and with the authorization code flow plus pixie so we're going to start out over here at the site called avocado dot low and we'll start at Google which is the regular authorization code flow now just like I did before I'm gonna log in with Google this brings me over here and I'm gonna log in as my rube dude snag the rubes password alright and just like before the authorization code was intercepted and the user was unceremoniously dumped back to the front door in this case avocado glove if I go back to Google and I log in with Google we can see that I'm logged in as our root dude now also just like before let's jump up here and let's go back to abakada allow google and now i'm going to log in as our hacks or all right and now you can see just like before I ended up in an authenticated state as the Rube do because I was able to replace the code with the one that was picked up so this is exactly what we did before with pay per call but now in this kind of test environment now I'm gonna log out once more I'll fast-forward through it and now we're gonna try and do the same exact thing with pixie and see what happens okay one more time we're going to start over only this time we're going to do the pixie version of this confidential client so now I'm logging in with pixie dot php' and I'm gonna do the same thing down here whoops because we're gonna start off with our rube just like before let me clear out our extension consoles all right here we go so I'm gonna log in as rube all right just like before I am dumped back into the front door and if I go back to Google so if I go back to login with Google now I'm logged in with rube dude just like before so intercepted code published to the attack server now let's go back to our attackers console and I'm gonna log in as the attacker just like I did before all right now this time we intercept the code we replace it but this time it fails it says invalid code verifier so pixie has foiled this particular attack because when you're using just the regular old authorization code flow while you have to have established a session and the state value is checked against that session the state and the code the authorization code are not tied together in any way with pixie however the code challenge and the code are tied together and there's no way for me to know the code verifier that generated that code challenge and so when I come back here even though I've injected the authorization code the code challenge and the code verifier that the code challenge was derived from are completely different and the authorization server can can recognize that and it fails because we have an invalid code verifier so this is why pixie is very important even when you're dealing with a confidential client and why in my personal opinion for OAuth 2.1 we should have a must-buy pixie when it comes to even confidential clients to avoid this sort of or to mitigate this this authorization code injection attack now if you're not familiar with this make sure that you check out the links in the comments so that you can get familiar with OAuth in general and the pixie extension specifically I hope this has been informative go ahead and give us a shout out on at octave dev on Twitter and like this video and subscribe to our channel if you found it useful have a good one

Channel: OktaDev

Views: 5,274

Keywords: oauth2, security, authorization code flow, exploit, oidc, openid connect, pkce, proof key for code exchange

Id: 1ot45WwQWJE

Length: 14min 9sec (849 seconds)

Published: Tue May 26 2020

Reddit Comments

[u/Daneel_Trevize]

I must have missed how this affects anyone that doesn't have a malicious browser extension to exfiltrate a fresh valid auth code in the first place.

[u/dfett]

I'm one of the researchers that came up with the auth code injection attack. If you want to learn more on the details of the attack, I recommend reading my recent blog post which explains code injection attacks and how/when PKCE protects against them: https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

[u/JayTh3King]

I could be misunderstanding, but this just seems like a XSS/CSRF attack but in a browser extension?

Microsoft OAuth i believe mitigates this by allowing you to optionally pass a state={some special state} along with requests to verify the flow as an additional step.