 Hello, my name is Micah Silverman. I am a senior security hacksawer for Opta. I work on our developer advocacy team and Today I want to talk to you about a particular OAuth 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 OAuth There's been a lot of conversation in the OAuth working group about mandating the pixie 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's 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 log in 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 on 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 user's 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 Paper call if you're not familiar with it. It allows you to create a speaker profile It's for people that give conference talks and I want to take a moment just to say that paper call isn't doing anything wrong here But paper call uses the authorization code flow and paper call has a confidential OAuth client So I wanted to demonstrate this in in a real-world sort of way So on paper 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 anything There's no authenticated state for any of them and these paper call URLs are publicly accessible without any kind of authorization Now we're going to start off with our Rube here our target user going to interact with paper 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 pretty cats that just shows Random pictures of cat gifts, but unbeknownst to them there 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 Rube and let me go fetch Rube's 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 lets 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 it just 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 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 room 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 log out from everything and start over and I want to demonstrate How pixie saves the client from this particular type of attack? Now I'll 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 Aaron Perrecchi put together for demonstration purposes and We're basically gonna 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 gonna start out over here at this site called avocato.lal 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 Roob dude Snag the Roob's password All right, and just like before the authorization code was intercepted and the user was Unceremoniously dumped back to the front door in this case Avocado.lal if I go back to Google and I log in with Google we can see that I'm logged in as our Roob dude now also just like before let's jump up here and Let's go back to Avocado.lal Google and now I'm gonna log in as our Haxor Alright, and now you can see just like before I ended up in an authenticated state as the Roob dude because I was able to replace the code With the one that was picked up. So this is exactly what we did before with paper 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 gonna do the pixie version of this confidential client So now I'm logging in with pixie.php And I'm gonna do the same thing down here oops Because we're gonna start off with our Roob just like before let me clear out our Extension consoles. Alright, here we go. So I'm gonna log in as Roob 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 log in with Google now I'm logged in with Roob 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 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 octadev on Twitter and like this video and subscribe to our channel If you found it useful have a good one