BSidesATL 2020 - Connect: Exploiting OAuth 2.0 and OpenID Connect

hi everyone my name is noir Cavani here from Jacksonville Florida really glad to be here to give this presentation normally I would speak for hours about OAuth an open idea connect it's one of my passion but one of my talks that I'm very passionate about but I'll try to make it as short as possible I know I have only 25 minutes or even less now so quickly introduction about me my name is Noir people ask me how to pronounce your name it's kind of sells like Pinot Noir you know like the wine I am a QA security tester leads at Fidelity National Financial which is a title insurance company I my total official actress's test architects but I'm

basically the lead of the QA security team which basically is responsible of testing for security vulnerabilities in our in-house applications I've been a tester developer and this is a picture of me I thought I wasn't sure if there was going to be a video so I decided to put a picture since I there's no face to face interaction I took this picture four weeks ago so before starting working from home and all of that then I realized that I changed a little bit since then so after working from home I look like this now this is more recent picture if you notice a difference I just shaved my just had a haircut the agenda for today I'm just gonna start

talking about why I'm giving this presentation and then I'm gonna give a very brief overview or I'll try to make it brief about OAuth 2.0 and Open ID Connect then I'm going to talk about some general risks and mistakes with the OAuth protocol and implementation and design mistakes and then I'm gonna give some examples from bug bounty programs which is you know if you notice the title of this presentation is lessons learned from about manic programs so why am i giving this talk well the short answer is to spread awareness I see a lot of mistakes and misunderstanding going around about modern authorization and authentication protocols which are which are worth 2.0 and open ID Connect and

related standards and it's it's a difficult subject and it's a very broad subject but definitely it's a critical subject because you know if you think about it this is your entry point your applications to your systems in authentication and authorization are in a your gateway for the users into your applications if you have one a bullet is there then obviously you have a big problem a lot an open ID are everywhere today if you look at single page applications they commonly use OAuth for authorization and authentication with a wide spread of micro-services today you also see these protocols being very widely used they're replacing older techniques such as using cookies for authentication and session management

they're also replacing Sam old in some areas although I think sam'l is still valid and usable for a lot of use cases there are a lot of common mistakes either at the design level or at the implementation level so we're gonna give some examples about some of the common mistakes and the list is really long so I'm just gonna really just scratch the surface here one of the things that I have felt about OAuth is that there is a lack of understanding by everyone not everyone of course but some people don't fully understand these protocols and this applies to applications security analyst or InfoSec specialists especially that a lot of them that have met they don't really come from strong

development background and these protocols require that you understand the web very well and you understand application development very well but it really not only that I actually see developers and senior developers who keep struggling with making the right design choices when it comes to OAuth and open idea connect so there's definitely a lack of skill set and I'm not sure what the solution is but this person diction comes in in a way to basically help people kind of like be aware about some of the common mistakes another problem is these tenors seem to be evolving with time there have been some best practices there used to be like this is the way you do it for

native apps and mobile apps and now there is a change today in what is considered the best practice and some of the older kind of like recommendations are we find now then they're not really with the most secure way of doing things so now you see new recommendations and even new standards or sub standards that came to resolve some of the issues issues that came up over time now where do we learn about these mistakes and that's a problem that I've been thinking about for a while but recently I've been watching I decided that the best way to find in a common errors and problems insecurity is not really to look at you know you have some valuable resources

like Oh a sub 10 which you know every 5 years they come out and they gather you know user feedback about what are the common mistakes but there first of all they're very broad mister problems and second of all there are like how you gather this information is a very user feedback oriented so I realized that we actually have growing treasure trove of data about security vulnerabilities and that we can tap into that repository of information what matters for for for for finding this information about the bugs that are important for us because not everything that we see you know is necessarily you know a big problem that is going to cost us money and add value

right so there's this famous code by Einstein that not everything that counts can be counted and not everything that can be counted counts so based on that I wanted to see ok what is what are the mistakes that really matter here how do we know that these bugs you know a lack of I don't know a header is that really a critical or a high issue or is that a low issue versus forging the signature on on some certificates right so so I went I decided to go to bug bounty programs and I think that's the that's the repository of information that I've been talking about the bug bounty programs are getting more widespread and

they're they're getting larger and larger over time Google has paid apparently sick and half-million dollar in 2019 in bug bounty programs think about that six and a half million dollars and then increase there's the maximum prize to one and a half million dollar what I'm happening dollar if you find a critical security vulnerability in in Google products this just came I think in November think about that one bug could be worth 100 1 million and a half Apple also increase their maximum limit for bug bounty to a million dollar last year well then you have programs like you see here hacker 1h1 is a curve one which is a popular crowdsourcing platform for bug panic program and the

other one on the right here is about crowd a hacker one paid 40 million dollars to their testers last year in 2019 which is apparently more than all of that they've paid in the years before so so this is definitely growing sourcing of bugs but what's more importantly is that these bugs a lot of them are publicly disclosed bugs so you can go and read about them and learn from them so we have now like unprecedented repository of information that security researchers can use to basically gather empirical information about what is going on in the real world today these bugs some of them have value so not matter every bug in the bug bounty programs get assigned a reward

and that depends on the policy of the company that is sponsoring the program but some of them have value assigned a couple months ago I remember I was PayPal paid about $20,000 for two different bucks each $20,000 and there were bugs in like the login screen of PayPal and if you think about it $1,000 doesn't sound that high because if somebody were to exploit across the script in bug in the login screen of PayPal and steal the passwords of users that's really critical and so but yeah so so so some of them have met a value and you can use that value as a proxy measure to do to kind of like it and that's an idea of how important these

bugs however this comes with a lot of caveat and you have to take it with a big grain of salt because you know they're for different reasons I'm not gonna get into right now but you know commas have different policies for how to assign money value to two bugs and also different companies have different priorities I guess so let me jump right into what is worth 2.0 Oh what 2.0 is a protocol that allows users to delegate access to their own resources resources they want a third party application this is a protocol used mainly for API authorization it was designed for API in in the first place but it can be used for a lot of other contexts but it is

really for API in the first place there are different scenarios where this can be used can be used for server-to-server authentication scenarios can be used in browser-based apps can be used on native apps and mobile apps and it can even be used today in like consoles and TV smart TVs and things like that it is also important to focus on the fact that Oh what itself is designed to be an authorization protocol not an authentication protocol and that's a critical distinction I don't have time to get into the details for that but I always love to put this picture here and just to draw the attention that you know our stands for open authorization it's

really for authorization for authentication all right quick example I'm just gonna run through a quick scenario or actually a quick example of real world use case of Olaf that I faced recently so I don't know how many of you are familiar with mint.com I mean that calm is a website that you can use to collect basically it gathers the your bank statements and sorry and transaction information from your bank accounts from different sources and put them in one place where you can do your budgets and get a quick look at your money and financials one of the things that mint has to be able to do is or the main thing is that it has

to be able to connect to your back and on your behalf and get and collect your data and historically this used to be done by mint asking you to provide them with your credentials for these bags so you would basically give mint at con your bankofamerica.com username and password you'll give them your chase password you'll give them whatever bank accounts you have and obviously a lot of secure risks come with that so recently they released they started releasing new feature where now instead of asking you for a password they use now OAuth to ask you to authorize them mint.com or into it which is the parent company to access the bank on your behalf but

they're not no longer collecting your password what happens is that they ask you to go to your bank and here in this case I have screenshot of Citibank website where city is asking me hey do you want to allow this application to access your credit card information on your behalf and if I click on authorize right if I click on authorize access then it will base the grant that access to mint.com method cam will never get my password but they will get instead an access token that allows them to access my bank and if you notice here in the URL you see the oauth2 endpoint so that's an indicator that their years ago in this example I want to grandma to

come access to my bank accounts statements and balance is from terminology point of view I am the resource owner my statements these are the resources want to prove grant client meant that come which is a client accessed to my bank accounts which are you know the XYZ bank hero City Bank in this case was the authorization provider and also the resource provider and the resources that I'm giving access to them these are called scope you know what permissions I'm given to man that calm so the flow looks like this I get to enter in my browser the the client you know the URL of the client application that I want to use the client redirects

me or maybe sometimes it shows a pop-up by either way it redirects me to the authorization provider in this case like Citibank in this example Citibank will authenticate me right and ask me for my consent if I approve that Citibank has access to my or rather mint has access to my bank information then the authorization provider of Citibank will generate another redirect back to the browser to redirect me back to the client app with an was something called authorization code pass in the URL that authorization code is then sent back to the client to Mendte to come and which on its own meant that come use that equation code in in addition to its own

client secret that only meant that come has that it has generated with the Citibank of course and they use the authentication or the authorization code to essentially generate a new access token so now the the authorization provider will verify that the authorization code is valid it's the same one that it had just issued earlier right in this step and then it will if it's valid then it will generate a new access token that can be used to that the client can use to make a request to the API so from that point on men that come will be able to access the API that Citibank provides using the access token and every time of course

the research provider has to validate it's a valid token and then return the requested data so some consideration is about this flow the authorization code is the first kind of like token that gets generated and this one is passing the URL and it's only meant for the redirect and it's meant to be sent to the user to the client or really the user agent so that they can exchange that and send it back to the client app and they can exchange it for access token this authorization code should be only usable only one time it's usually very short-lived so five minutes or less because it's done in as part of a series of redirects that are all automated and

once its user should expire after that right later you get the access token the access token usually is a medium life span I've seen anything from 15 minutes to two hours that's where these are very common values the access token typically is only search on the server on the back-end server at least in this flow and it's usually so it's usually not provided to that to the client except in the cases of of native app and then it is also specific to the client in the resource owner so it has a combination that you know if I use this token this token can be only used for a specific user and to a specific clients so I

can't use a token that was generated for a different application to access the API there's also a refresh token that is used for kind of like to extend the the offline access bit from the client to the authorization server so this way the client can make API calls to in this case Citibank in my in my example for indefinite amount of time usually refresh tokens are good until they are revoked sometimes they might have some lifespan of like a year or so they're usually very very long-lived they're meant for offline access and refresh tokens are used to generate new access tokens since access tokens generally expire within an hour or so another security consideration is that the

client secret which I kinda quickly showed you in the in the in the flow the client secret is usually only used when you have a secure web server that it that is doing the tool can exchange flow you don't want to give this to end users there's no point in like if you put it in your native app in your single page application you have a big problem here so the client secret can be only used when you have a back-end web server that is managing access to the API there's a state variable that is bad pasts you know when the flow starts you the client has to generate a state variable and at the end of the flow the client has to

verify that the state variable hasn't changed and it's still valid this is important to prevent soft request forgery attacks there are also you are a lot of redirects in this flow as you noticed so all of the redirects are always subject to you know the standard open redirect issues that we've known about for many years you know in any application you want to make sure that the redirect is always validated or the redirect URI is always validated by both the authorization provider and the client otherwise they can end up with situations where a malicious attacker can force the user to get redirected to a malicious site and steal their tokens there the flaw that I just described was

the authorization code flow because as you notice there was an authorization code that get passed in the redirect flow there are other flaws there's episode flow which is used generally aimes single page applications and sometimes in native apps like mobile apps it's becoming less encouraged to be used let me say that because it has a problem that it doesn't support client secret and the reason is you don't you know the client in this case is a client is an app that the user has accessed or has control over right native app or single page application and you don't want to put client secret there there's no point because once you put it there then it's

public so in in in this scenario the this flow is generally considered less secure than authorization code resource owner passwords is even even in worse flow in from security perspective because in that flow a client will capture the actual credentials of the user and then passed them to the authorization server this flow is only used is only recommended for legacy apps where you don't have like mainframe app for example or you don't have a browser and the only way to invoke that or get access tokens is to basically getting the password from the user directly and passing assets to the authorization provider there's client credential flow which is used in server-to-server authentication this is more like a service account flow

but then there are few other flows the Refresh token flow is really a sub flow of the above you know it can be used with authorization code flow is just a way to extend offline access there's device flow that is more recent and that you can see now in things where you don't have web browser for example smart TV if you want to authorize your TV to access your Netflix account then the device flow is what's used here number seven is authorization code with pixee PK c ii pixie actually this this came to solve the issues with the implicit flow where you don't have client secrets this is actually today the recommended flow for native apps

like mobile apps especially where you're able to invoke a web browser to do the authentication process but you don't have the ability to use client secret because it's a public client and then you have sam'l beer a certain profile that is used for compatibility with sam'l authentication flows token types there are two main types based on how they work there are the bearer token which basically says every time you see a client making a request if the request has that token then this request and if the token is valid then the request is authorized the bearer token is doesn't change between different requests until it expires of course there's another type of token called the Mac - okay our message access

codes to again and this one relies on cryptographic signature of the request so so this every time you have a new request basically you hash the request and using a secret you generate a token that is only valid for the specific request this is helpful to prevent kind of like replay attacks however I have not seen this flowing practice yet read about it a lot but I still haven't seen an example of somebody using that flow yet I'm sure it is there but I haven't seen it the bearer token is by far the most common scenario then based on format you have JWT tokens which is JSON web token that's very common you'll see it everywhere but you can also have

opaque tokens which is just like randomly generated long string right and those are only comprehensible by the authorization provider there the client cannot see inside them this is a quick example of what JWT token looks like there are three three parts each part is base64 encoded the first part is the header which defines how the the token is assigned the second part is the claims which is you know who the user is what they have access to when the token was issued and the last part is a signature that protects the token from tampering I'm gonna skip up an idea Connect since we're short on time but very quickly I really just want to say this is the

authentication protocol that was based on all that's 2.0 so while all our talk we know wasn't intended for authentication open ID connect came to solve the authentication problem and it really just sits on top of OAuth now I'm gonna jump into some examples from what I've seen from bug bounty programs as I mentioned you know hacker Wong and bugcrowd are like platforms for where you can see a lot of publicly to school disclosed vulnerabilities you just go there and they're public you don't even have to sign in you can go there and search for bugs with specific keywords and this is like a quick search I did and this is really just part of the

screen I had hundreds of results but quick results in a quick search shows that you know on earth I get several you know bugs and some of them are like in big you know apps like uber and Twitter and and so on there were paid thousands of dollars for four for the people who found these bugs so if we take a look at a couple of them in this example this is Twitter or more specifically periscope which is platform owned by Twitter in this case the user or the the tester was able to find that there was unvalidated redirect in the redirect URI so rather than redirecting the user to periscope that TV effort they walking

with Twitter they can be redirected back to attacker comm slash periscope TV which is obviously in a malicious site or an example of the malicious sites nor real one this bug although this is classified here as cross-site scripting this is not really cross the script and this is an open redirect this bug was paid $7,000 and I think this is fascinating and this is very very like if you think about it it's very simple and basic type of issue another example of unvalidated redirects in this case facebook or and uber combination of you know logging into uber with Facebook I don't I'm not sure about Facebook there's no Facebook here I think oh there it is Facebook yeah it is using

facebook login essentially it's more complex here in this scenario there is a chain of redirects but they lead out essentially be having these are being redirected to malicious site this example here it's actually cross tripping through redirect URL so it's it's a probably a combination of on validate unvalidated redirect but also the way that they were presenting the redirects back to the user it was possible for the attacker to inject a script therefore across description and if you think about it as I mentioned earlier cross-site scripting on the authentication process is really dangerous because it allows an attacker to steal either password or access tokens essentially account takeover right so next example Shopify it's really a privilege escalation the

details of this bugs were not fully disclosed but they basically say that there was a lack of foundation of the claims in the token that is passed to the stalky app here and this is called a sake app part of Shopify so privilege escalation if you're not validating the claims or maybe you're not validating the the token is signed by the the party that issued the token then it is easy to tamper with the token and inject whenever you want and that can lead to either account takeovers or privilege escalation issues here's another example of spoofing tokens in this case the JWT token was spoof upon or forcible and the reason this was possible is because the

you know the key that is used to sign a token was actually in the JavaScript code in the client app so back to the point that you know you don't give the client secret or any secrets to public clients you know a browser JavaScript app is a public client when you give it to users then it's no longer secret so in this case the tester was able to find that the the the secret that was used to generate the tokens was in the JavaScript code and they were able to generate spoofed tokens and bypass the authentication and the authorization flow this is my last example CSRF on that seems to be also a pretty common problem and there are a

lot of different techniques to prevent that you know the general technique is to use a CSRF token and validate that but in the case of earth protocol there's also state variable that has you know value or has importance in in preventing CSRF attacks that a lot of developers don't think much about it because states the initial initial purpose when state parameter was included in the RFC of oh it wasn't meant for security it wasn't meant for CSRF protection it was meant to encapsulate the state of the application before the authorization flow happens by turn tada it has a critical value in preventing CSRF attacks in an authorization actually more like implicit code flows so I mentioned again

the token hijacking with CSRF for cross-site request forgery again using the state parameter is critical here leaking authorization codes or access token valid redirects we talked about that talking hijacking by switching clients when you validate the access token you always want to validate that it is meant for the clients that generated that token sometimes client-side form abilities in a crisis crypting allows you to steer access tokens because you know back in the day when we used to cook it for for managing session cookie has had an HTTP only flag that you know a lot of us are familiar with that is meant to prevent JavaScript from accessing the token but in the case of a single page application for example

where Chavez needs to access the token because it needs to pass it to the API there's no equivalent to HTTP only in for access tokens and access tokens are often stored in the web storage in the web browser storage so in case you have a cross-site scripting issue for example in your application then your access tokens are immediately exposed to the attacker finally well not really but exposure of client secret I mentioned that you know this is seems to be a pretty common issue in when when developers put the client secret in their mobile app for example and they'll release it a mobile app can be reversed engineered it's easy to get those client secrets more things to consider in

always enforce HTTPS I don't even know why I'm mentioning that everybody should know that by now no HTTPS means everything is compromised right you know the whole flow is you know it's useless if you don't have HTTPS Everywhere only use the permissions that ya needs validate validate validate validate redirect URI state non JWT signatures X whether the token has expired or not and the that the client is really the tokens are and the authorization code is issued to the white client there's one final risk that I found very interesting it's not really risking a lot itself but it was more of a social engineering attack that came up a couple of years ago on Google Docs or

local and I'm if you look at this screenshot if you notice something weird about this screenshot this was warm that spread out very quickly between Gmail users and you basically get an email from somebody you know that says hey I shared a document with you click on this link to open the document and the link is a Google link so it's not like we've trained users to look at the links and validates they've the domain of the link in this case it was a Google link because it was you know a request to to use the OAuth flow in Google to provide access to a third party application and the third party application name was

ducks now this is not the real Google Docs this is a fake Google Docs app that wanted to access the users email reads and delete and manage your email it also wanted to access your contacts so for a lot of users who are not really aware of social engine even like people who are trained on social engineering phishing attacks this is difficult to spot because there's the URL here on this page was Google right so there's not a lot of things that we teach users to avoid apply here but essentially you know Google Docs you know the really the only red flag that I would think of that you know why would Google Docs need

access to your email I mean Google has access to Google right so it shouldn't really need to ask for this permission so it spread out very quickly and I think millions of users were impacted within like few hours so I thought that was very interesting attack summary alas vulnerabilities are very common unfortunately there are too many points of failure the protocol is complex and it's evolving the consequences of a vulnerability can be severe you know an account takeover an authorization PI pass or authentication pipe as sometimes privilege escalation etc and I think we're going to see more and more of those problems as you know this is becoming more prevalent and I really think there's a short shortage of

spilitt skill set that's Givet skill set of people who understand these protocols and who are able to find issues and to also defend against issues like that and with that I hope I didn't go over time well I guess I did this is Yvette yeah you did it's ok and I am actually going to jump in and have you go answer questions on slack ones like got it I will answer questions on stack thank you everyone I really appreciate that thanks know are we appreciate it thank you