DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows

00:12 - My name is Jenko Hwong, I’m currently a Researcher at Netskope.

00:17 - Here are some of the areas that I’ve dabbled in and are interesting to me from my research perspective.

00:26 - So to recap some of the past about phishing, I’d like to just spend a minute talking about that, so that we can understand some of the latest evolution of techniques.

00:40 - So in the beginning, certainly phishing was predominantly carried over SMTP.

00:46 - This is probably late 90s when we started to see phishing.

00:51 - Attacker is very focused on fake domains, creating them, hosting websites, maybe creating SSL certs as well to lend some validity to their fake site and ultimately tricking the user into supplying their username and password.

01:12 - As mobile came along, more apps, protocols came phishing, then targeted those applications and so we got SMS phishes, snitches, IMs chats.

01:27 - For the most part, a lot was the same, but because of the limited UX and real estate, certain things like URL shorteners, being able to detect the cells, or you can see the SSL cert or even see the URL were different or challenges affecting the user as well as any software security controls in the picture.

01:53 - With cloud infrastructure providers, suddenly the attackers had an easier way to host and their actual fake website, on top of that, the domains now, and the SSL certs reflected those same popular cloud providers, so the victims, as well as the security controls have more of a challenge in detecting fake domains, phishes, certs, et cetera.

02:25 - So none of this is new. And in this case, maybe the attackers trying to create something like Citibank’s website hosted in Azure.

02:39 - The controls I alluded to and for the most part grew into a series of techniques upfront, detection of phishes using various link analysis domains, URLs, the certs themselves, checking on the sender reputation, having threat Intel, that helps with that, so that phish on the incoming basis could be blocked before reaching the user.

03:03 - Post-user receiving an actual phish, some of the same techniques might be used to prevent the user from actually connecting on an HTTP request outbound to their fake website.

03:18 - There might be additional content inspection (sneezes) excuse me, content inspection use to detect credentials within the payload as well, form, fields, et cetera.

03:30 - Ultimately, if credentials were hijacked, set of controls like MFA and policies governing IP addresses that can be used with credentials also were applied MFA, especially was pretty effective at minimizing the impact of compromised credentials.

03:48 - So none of this is new, this has been sort of 10 or 20 years of phishing evolution.

03:57 - If I could simplify it at that. Now what’s changed with some of the last few years, well as OAuth, which was introduced in 2013, as OAuth got more popular, driven a lot by security and the interaction of all these websites and web apps, that part of OAuth that dealt with authorization in a secure manner became very popular and sort of has caused us to rethink both how to phish and how to defend against it.

04:30 - And OAuth at a high level, if you’re not that familiar, involves the application, this could be the website, or it could be a local application on the desktop or mobile, often referred to as the client or device, while the application might request authorization from the user to do something, and that could be approved, hey, have the payment log in so on.

04:54 - And it directs the user to identity platform, right? Part of the OAuth model is to not have the applications, handle no store, anything about the user credential.

05:05 - So in this case, there’s a redirect the user then authenticates as they would with their identity platform.

05:13 - And when we’re talking about OAuth, it’s really Azure AD or Google Identity.

05:18 - That authentication process could be a very secure and have MFA.

05:23 - Ultimately, the user is presented with some kind of authorization step, approve these permissions, approve this task.

05:31 - The permissions are called scopes in OAuth land.

05:36 - And if everything goes well, the session tokens, OAuth session tokens are supplied back to the application and the application has these access tokens and can generate new ones with the refresh token, and can use it to actually gain access to the resources of the user or to perform a task because they essentially have post authentication status.

06:02 - So as a user, this is familiar in various contexts, one is payments, you’re shopping, you get to checkout and PayPal, which isn’t OAuth provider allows you, websites to easily pay with PayPal, websites, if you clicked through as a user, redirect the user to PayPal, so that you can go through your authentication MFA, and right now we’re dealing with PayPal as a user, so the original website does not see or have a chance to compromise your credentials.

06:37 - And as you complete the process with PayPal, you end up on the right with their version of an authorization or consent screen, which is, do you agree to pay that original website such and such money for whatever you are shopping for? There are other contexts, even technical tools like CLIs and Google Cloud have a login process, of course.

07:07 - And in this case, it creates a URL that you can copy and paste into a browser, but it’s actually an OAuth flow.

07:14 - And in the browser, once you go to that URL, you’re prompted to enter your username and password, and then you get to a consent screen saying, hey, the CLI, which is really registered as the Google Cloud SDK, once access your Google account, and it’s asking for these permissions.

07:35 - If you go ahead and hit allow you just confirmed and you see some confirmation messages, and back on the command line, you might see a final message that, hey, you’re now logged in.

07:49 - So initially phishing responded to this new authorization identity platform called OAuth with so similar techniques, just, here’s a new login.

08:02 - Yeah, great. We have an OAuth log in, but it’s just another log in, I’ll just move it.

08:06 - So, a lot of this was business as usual from the phishing side.

08:12 - However, we did see some evolution where the code presenting that actual fake login would actually do a real-time validation check against the identity provider to validate that credential and then based on whether it was valid or not, it might take different actions that would help maintain stealth.

08:30 - It might redirect to a valid domain login screen or something else depending.

08:37 - And that might help prevent the user from maybe raising a flag manually, also provide an opportunity to validate credentials upfront, so that you could do that check right away instead of later.

08:52 - The controls for the most part, I would say have stay the same because really the techniques have not changed much.

09:00 - So why do we care to maybe delve and research into the protocol deeper, right? So far, this hasn’t made much difference.

09:09 - Well, obviously I wouldn’t be talking if that were the case.

09:14 - Here’s why attackers have dealt deeper and why from a research perspective, it’s worth us focusing on this.

09:23 - One is, instead of targeting the username and password, we target the OAuth session tokens.

09:30 - There are some advantages there, the model of OAuth essentially allows a refresh of them and the defaults pretty much allow you to do that forever.

09:38 - The session token gives you the same power as the original credential, has one advantage, which is we don’t have to rechallenge with MFA.

09:49 - If MFA is enabled the user, once they go through that manually, the tokens effectively are blessed and the refresh token just allows this unlimited ability to have a long duration credential.

10:05 - So getting access to session tokens effectively allows us to quote, bypass MFA.

10:13 - The second reason is that all of this is REST enabled, so hijacking, the actual tokens does not require a compromise of an endpoint.

10:23 - We have these nice REST APIs, we have a complicated flow, there’s the ability to insert us into the flow or perhaps gain access to tokens remotely, which is huge because tokens are not a new concept, they’ve been around since the beginning of the web.

10:38 - We’ve had web sessions and we’ve had session IDs kept in cookies or local storage, and we’ve had web attacks, SSRF that exploited those sessions to hijack them, we’ve had endpoint compromises that have also, looked at grabbing or harvesting those tokens.

10:59 - However, there’s a pretty high bar to take advantage of that because you would have to compromise the endpoint or do a browser attack.

11:06 - This is far easier, far easier because we have REST APIs and we’ll see that in the upcoming deep dives.

11:17 - So, there have been actual attacks. So, one of them is called illicit consent grants, the texts that have exploited the protocol, I’m sorry, I didn’t quite finish that.

11:31 - So in the illicit consent grants, it’s exploiting wider consensus privileges, tricking the user to approve them.

11:38 - So this works with attacker, creating their own application, a fake application, perhaps named close to an existing app.

11:46 - They register it in the identity platform, it could be their own account.

11:51 - They send out ultimately a phish to the user requesting broad scopes to some resource, so imagine it could be a Google Drive my sync, some name that seems plausible.

12:08 - I asked the user to give this application access, read and write to everything in Google Drive.

12:17 - If I can get the user to click, they’ll approve these bigger scopes and OAuth tokens will be created, and will be accessible by the user because the user that’s part of the flow is specifying how to retrieve those tokens and they get actually pushed through a redirect URL to application.

12:43 - So, from a user perspective or victim perspective, the chance they either have to identify or know that it’s a fake application or an administrator security, or IT administrator needs to be able to prevent users from clicking and approving these app requests.

13:03 - So this has happened and there was a reference here just in the last year or so, of illicit consent grant attacks.

13:13 - From a user perspective, they’ve just see in a consent screen, a list of permissions that might be wider or deeper than they expect.

13:23 - And the controls against these are, as I have mentioned, the administrators running the organization, watching the network, having ability to prevent users from creating or registering fake apps and ID, which might prevent a insider attack, and they can prevent users from consenting and hitting, except it changes this flow, they’re not actually present it with an Accept button, the administrator’s thing control.

13:51 - I just wanted to point out that the Microsoft documentation has this nice 12 point numbered system, I did not add that, that’s actually part of the documentation and they’re explained pretty well within the documentation, kudos to them.

14:04 - It’s great as a researcher and I have to say as a user, it’s extremely confusing to have 12 points to explain in okay dialogue.

14:12 - So, this is where complexity is the enemy of security.

14:20 - So let’s get to device code authorization, which is really the flow I want to focus on today.

14:26 - What’s the purpose? Briefly to provide usability that is easier authentication or authorization on a limited input device where you need some kind of authorization and authentication.

14:40 - Best example is smart TV, where you need to authenticate against your content subscription, so you can get your movies on the TV.

14:47 - They’ll have this menu these days could be, you know, some device like a Roku or, you know, Apple TV.

14:57 - But the problem is if you were to enter that credential on the actual device, you’d be faced with something like a remote control, completely heinous.

15:09 - So, well, there’s an RFC to solve that. Back in 2019, some smart people came up with a way to do that.

15:19 - And when it’s implemented the application vendor, in this case, the smart TV vendor implements the device code flow, and now the user has a better flow.

15:32 - They’re presented with a short URL. They’re told to go to a different device that has a real keyboard or something that they can do.

15:39 - Here’s a relatively short URL to punch in there and relatively a short code to type in there, and then you will go through a normal authentication or login process to prove this TV gaining access to, in this case, your Netflix subscription.

15:56 - They even have a QR code capability, so that your mobile device can even go to the URL directly.

16:05 - So that’s all well and good, but the user gets when they follow the URL something like this, punch in that short code, voila, everything’s working.

16:14 - However, usability is one of the biggest drivers here and I have a saying that, on usability is the father of insecurity.

16:24 - It drives less security and that is our opportunity to exploit because things get simplified, things get dropped, things get less secure or things just aren’t looked at from a security viewpoint.

16:39 - So, let’s look at device code authorization a little bit deeper.

16:45 - So, what really happens under the hood is a user is trying to log in or do some tasks, the device gets some user codes and sends a URL with that user code to the user, so that they can authenticate and once they do, OAuth tokens are created, which are then accessible from the device.

17:07 - So, okay. Similar to what I said before.

17:13 - But to show how easy it is to abuse that, or at least how difficult it is as a user to protect your credentials, I’d like to go through the demo now.

17:24 - Just a short note, Dr. Syynimaa has a great deal of information at his blog, o365blog, super great resource.

17:35 - He has his tool set AAD internals, great stuff about Windows AD, Outlook Office, as well as OAuth in there.

17:45 - It’s highly recommended. So let’s jump into demonstrations.

17:52 - So, lay the stage here on the left side will be the browser of the victim, the right side will be the terminal of attacker.

18:01 - And we’ll actually go through a device code flow and sort of see the implications from both sides.

18:07 - So in this case, we’re logging into the standard URL for this company.

18:16 - That Ed is part of Feast Health, and we want to gain access first to Outlook.

18:20 - So we punch in name, password, get two factor.

18:27 - This case it’s software based, we punch in that code.

18:31 - Do you want to stay signed in? No. We’ll go through it and boom, we’re on Outlook.

18:36 - Now, meanwhile, the attacker independently is thinking of phishing.

18:41 - We’ll start up a script, sort of running in demo mode.

18:46 - This is part of the open source software, we are releasing concurrently.

18:52 - I want to point out a few things. One of the first steps that we’re doing as part of the phishing is actually following the device code authorization flow.

19:01 - We’re gonna generate a code. If you look at a post or specifying a set of APIs, the graph APIs as our resource, and we’re actually using a client ID, this is the application client ID.

19:15 - When you create an application, the OAuth world, you have to get back ID in a secret.

19:21 - We’re actually reusing one, we didn’t have to create an app to carry out this phish.

19:25 - This is the Outlook ID that we’re reusing. (couch) When we execute this four step, we get back a user code that we’re gonna phish the user with, along with the login URL, it’s called the verification URL.

19:36 - Okay, we’ll explain the other fields as we go.

19:40 - Now I’m gonna send out the phish and in a second the phish will appear, I’m gonna pause and just say that after the phish is sent out, part of the device code authorization flow is to poll the identity platform, in this case, Azure, for OAuth tokens, which will be created after the user logs in.

20:05 - So it will sit there waiting. And in a second there it is, on the left, we see a new email, let’s check it out and has received an email from the Microsoft Office 365 product team.

20:20 - It is thanking for being such a great customer and as part of that, he’ll get one terabyte extra storage and increased file size, attachments file size of a hundred megabytes.

20:30 - It’s awesome, Ed can’t resist and he types in the code.

20:34 - Now let me go back and point out in the message.

20:39 - There’s a real URL in here, it’s microsoft. com, nothing shady or funny.

20:46 - It’s a trap link but it’s actually pointing to the text as part of the device code authorization.

20:54 - So we can see that some phish detection might fail right off here on domain alone because of this microsoft. com.

21:02 - Okay, so let’s go back as follows that punches in the supply code in the phish and what’s happening? He is being prompted to authenticate.

21:15 - Okay. Since he had already logged into Outlook, it is cached in the browser otherwise to type in as username and password, and perhaps MFA code.

21:29 - And then get to this stage. I want to point out, here’s the prompt, are you trying to sign into Microsoft Office? That Microsoft Office came from the use of the client ID in our phishing step initially.

21:46 - Okay. We use the client ID and we get the title.

21:51 - All right, so there’s continue and that’s it for the user.

21:56 - They entered the code, they authenticated, they’re done.

22:00 - Meanwhile, we are polling the attacker script is polling, checking every five seconds.

22:06 - This is all part of the protocol for device code authorization.

22:10 - Now that the user is logged in, we should have OAuth tokens and this will return in a few seconds with access tokens, session tokens.

22:18 - There it is. So let’s note a few things, okay.

22:23 - Number one, what’s in the response is scopes associated with the tokens.

22:30 - These are the permissions that we have access too with this token.

22:38 - The resource, the tokens applied to scrapped API, we have an access token, we have a refresh token, okay.

22:48 - This is great. What can we do in the graph API? Okay, you can see the indirection here.

22:53 - We put the application Microsoft Office, that’s what the user thinks they’ve approved.

22:59 - We’ve got access to the graph API, which is a little bit broader than just Outlook.

23:09 - So one thing we can do is get all 80 users with that access token, running as Ed or with his permissions.

23:16 - And there’s a list of three users, Ed, included David and Sandra.

23:20 - We will go to, just to compare, we’ll go to Ed’s view, the victim, in Azure Portal.

23:33 - We will actually go into the Azure Active Directory and check out the users just to convince theirselves this is real data matching, right? All matches.

23:45 - What else can we do? We can gain access to Ed’s email.

23:49 - So we just did a call with that same access token and got three emails.

23:56 - Thank you from 365 team, some social security credit card numbers, all looks great.

24:03 - Switch to Outlook as Ed and you can see in the inbox, nav pane on the left, the same emails.

24:10 - So this is great. Through the graph API, we have access to email, some of AD, but to make it interesting, we want to show that you can actually pivot, move laterally and trade in, or rather use the refresh token we have to gain a different access token with different scopes, different implicit scopes.

24:36 - So let’s do one that allows us to get more at all of Azure, okay? More of all of Azure resources.

24:45 - So what did we do here? We use the refresh token that we got under the guise of Microsoft Office against the graph API and we use that refresh token to get a new access token that has access to the resources in Azure.

25:08 - We are still using the Outlook client ID and the scope.

25:14 - We have to specify scope before we didn’t, we got a bunch of scope permissions.

25:20 - Here we’re using open ID, which is a pretty basic scope sort of username, email, basic profile information.

25:28 - Okay, and what we got back is interesting. We request their resource or Azure and that’s fine.

25:37 - But look at the scope, it changed, which is part of the protocol.

25:41 - It comes back with what you really have access to.

25:44 - We asked for open ID, we got back user impersonation, user impersonation is we can do everything that user can within this resource area of Azure.

25:53 - That happens to be a global administrator, we have hit gold.

26:00 - Okay, we got a new access token. This access token has the scope privilege for this resource.

26:06 - So, and we didn’t really have to supply anything special.

26:10 - I want to point out no secrets. So what can we do with that? Let’s enumerate all resources in Azure, at least in the subscription that Ed is part of.

26:24 - Okay, long list. Let’s go back to the beginning.

26:27 - Let’s take a look at this. First, we listed the subscription that this user has access to this token, just to convince ourselves we’re in Ed’s view in the portal.

26:40 - Let’s look at subscriptions, it is in fact, Azure subscription 1, great.

26:45 - A bunch of resources in that subscription. So let’s look at all resources and compare it with what we retrieved, just to convince ourselves we’re looking at real data and discs, and computes.

26:57 - Virtual machines that has SSH keys. There’s a storage account for data.

27:06 - SAJEH1 is listed there, right there, and on that is a container that storage account has a container as SCJEH1 drilling into that container are two files, ss1. txt and ss3. txt.

27:25 - And in fact, there is the container and there is ss1, ss3.

27:34 - So everything matches up and we’ve just enumerated everything.

27:38 - And since, as a global administrator, we could do anything pretty much within the whole AD, as well as the subscription.

27:47 - So that’s the end of the phish. And the super interesting part from this view is the pivot, as well as that we had to supply, and we did not need to supply any secrets along the way, it was really easy.

28:06 - Let’s switch back and look at the voice code authorization and a little bit more detail going back to the protocol itself and let’s figure out how we abused and carried out that demo.

28:24 - So let me highlight a few things. When we turn this into a phish, you pretty much use the standard device code authorization, but of course there is no initial login or task by the user.

28:41 - Normally with a smart TV example, the user’s explicitly trying to hook up a streaming service and authenticate to it.

28:49 - So the user is expecting to be part of this flow.

28:55 - Here, the attacker’s in control, user is sitting, minding their own business, we will, as an attacker, start with generating some user codes.

29:04 - And I want to point out this is a real snippet of all the key attributes in the REST API call to generate a code and get the standard URL.

29:15 - I supply client ID, which we have seen can be spoofed or rather be an existing client ID, including the vendors, in this case, it’s Outlook.

29:25 - I don’t need to supply a secret here. And I can specify a resource, whether it’s graph API or outlook. com and I immediately get back the information I need to start my phish.

29:40 - Device_code, which I’ll use later, user_code, which I’ll give to the user to log in the device with expiration time.

29:47 - I give that to the user and my phish, the user, if they’re convinced, this is the key step, the number four, but if they’re convinced they go and authenticate, enter the code, go through authentication, including MFA.

30:02 - And once they’re done, what’s happened is the device is in the background, polling and checking the identity platform, which will let it know once the user is finished logging in successfully, at which case a lot tokens will be created and returned as part of this polling API call.

30:25 - Look at all of the stuff that the application or the device has done.

30:29 - No secrets required. All public information in fact, client IDs are, for the most part easily determined for local clients.

30:39 - And they’re also logged, so it’s actually really easy in the Microsoft area to identify client IDs, no secrets are needed.

30:48 - So you can see that this is a little disturbing because if you squint and step back and ignore the text, we now have a process where I just need to convince the user to type in a code in a standard Microsoft or Google URL.

31:07 - If I do that, then just to note, I do know that I’ve mixed and matched Google URLs with Microsoft ones, but in all cases, this is very real and often common, right? All of these attributes are similar across both and what I was saying is that to carry out this phish, if you step back from it all, all you need to do is convince the user to go to a particular URL, enter in a code, authenticate, OAuth tokens will be created, stored by the identity platform, and you can go and retrieve them.

31:58 - That’s a little bit crazy, all right? You don’t have to create your own infrastructure to do that, your own login page, your own application.

32:06 - You just had to point the user to identity platform and give them a code, and then you have their tokens.

32:17 - Once you have access tokens, that pivot from a Microsoft perspective does look like this.

32:26 - You supply, you make a refresh token call and you get back a fresh set.

32:32 - And here’s where you can see the scope changes.

32:34 - We pointed this out during the demo, and this is just repeated just to show that.

32:42 - So, to summarize some of the key points, what’s not just with Microsoft, but common across all off vendors is a device code authorization that has three aspects or qualities.

32:55 - You don’t need server infrastructure. You don’t need to register your own OAuth application, in fact, you can use an existing one, even the vendor’s client application.

33:07 - The user does not see a consent screen, does not see a list of permissions.

33:11 - They’re not prompted for that. They are prompted with this somewhat obscured, do you want to sign into the application? But that’s it, not, do you want to grant the application access to everything in your email, all users and AD, and your Azure, as well as other services? They don’t see that, right? Microsoft has sense of implicit or default scopes that is in step two, the application, when it starts this whole process, never supply a scope.

33:47 - Google’s a bit different, we do supply a scope.

33:51 - It just means that the scopes you get, ultimately with OAuth tokens are things you never had to request.

33:59 - And we ended up getting user impersonation, scopes and Microsoft, which allows us to do anything that the user can do.

34:08 - Microsoft allows this lateral move to other services or resources, I should say, as that user, by being able to refresh a token and for a different resource and get that back.

34:23 - Logging is limited and what is logged? Is when attacker actually retrieves though off token, their IP address is logged and it shows as an actual authentication or sign in, in the sign-in logs of Azure for this user.

34:45 - Okay, but this is limited because the lateral move is not logged.

34:50 - The lateral move being, when we refreshed the token to get an Azure access token, that was not logged.

34:59 - So, partial information. Here’s some of the details in that line item or entry and we can see that the application information ID is shown, but not much else.

35:15 - We know what user is operating here, right? The attacker did this retrieval of OAuth tokens for Ed, but this just looks like an Ed action, right? Nothing identifies the attacker, other than the IP address on the prior view, which can easily be obfuscated through a proxy or VPN.

35:43 - So what can reasonably be done to protect against this? Or what would be encountered? Probably the most effective one would be blocking a verification URL.

35:54 - So that is the sign-in URLs that start this whole process off for the user.

35:59 - There are some standard ones for Google, Microsoft has two because the second one redirects to the third.

36:06 - So we could block those URIs, security team could.

36:12 - But it’s an imperfect solution because you actually might need to allow it for some valid log-ins.

36:20 - What’s an example of that? Not a smart TV that could probably be against all policy, but it could be Azure.

36:32 - Azure CLI does device code authorization, at least has one flow where it does verbatim device code authorization.

36:44 - So, you have to be careful what is broken if you’re on the defensive side.

36:51 - And it just means that there’s opportunities where the prevention may be imperfect or can’t be put in place.

36:58 - There are some recommendation to use, to block access or use of tokens based on IP, or location, or endpoint and if that’s within control, that’s a possibility.

37:13 - But IP allow lists and often our challenge, as well as geolocation and other characteristics.

37:21 - So prevention is best described as imperfect but possibility detection is difficult because the logging of anything related to OAuth tokens or temporary session tokens is very limited.

37:37 - Remediation does exist if, once you do know there’s a problem with a user, you can revoke all OAuth tokens in Microsoft’s world.

37:45 - In Google, that is more obscure, you can do it, but it’s not as obvious as a straight API call.

37:53 - There are some practical considerations to keep in mind, the main one is that the user or device code one generated is temporary.

38:01 - It will expire typically after 15 or 30 minutes, it’s in the response of the REST API call.

38:07 - And it just means the attacker can either in response, play a phishing numbers game that is ignored and just blast out to a large number of users at a certain time in order to get them to respond.

38:22 - If going over email, an email would have its advantages and that the phish could be rich, all right? It could sell a story.

38:29 - However, the timing may have a result in a low response to the phish, so practically speaking, though, you could choose other forms of communication, including chat, SMS, that might create a more instant response because of how those application are actually used in everyday interactions.

38:55 - So there’s ways around this temporary timeframe, you could also fall back and actually create some infrastructure hosted websites and then have your phish instead of supplying a code, instead points the user to a website, the fake hosted website to generate a code and get your discount code, so discount codes exist in that model today, and it’s probably reasonable that someone would fall through that.

39:24 - You could even have images dynamically generated that show codes and images are suggested because that would be allowed over JavaScript in actual mail browsers.

39:37 - They might be blocked, but the user always has an option to load images and that could dynamically at that point in time generate a code and would give a fresh 15 minutes for the user to do that.

39:48 - So I pointed that out mainly because that is the one area from a practical implementation viewpoint would need to be accommodated.

39:59 - So, there are some comparisons between OAuth providers, in this case, it took the two major ones, Microsoft and Google.

40:07 - The main difference is, there’s more exposure on the Microsoft side because of the handling of the scopes are implicit in default, and you can get quite a lot of permissions without even asking for them, whereas on Google, they really tightened up the scopes you get from device code authorization, meaning the access tokens can access user profile have limited Google Drive access mainly to files that the app itself has created and some YouTube more profile info.

40:38 - So because of that, the lateral movements very different on the Microsoft side, it was easy as we saw in the demo to switch between or among a large number of services, as well as on Google, it’s pretty limited and strict.

40:55 - You get what you get with the initial scope.

41:01 - But all in all this drives towards maybe mentioning some ongoing research areas.

41:09 - The problem with OAuth is not that it’s got flaws or is insecure, the problem is more that it’s complicated.

41:19 - We talked about the normal OAuth flow, the payments, examples, in CLI log in examples, we did a demo of how one other flow, the device code, authorization flow can be easily exploited.

41:35 - There’s three more flows, which aren’t quite as obvious as device code off on authorization, but in terms of having exposure, but certainly are interesting areas to research because some of them have usability type requirements like implicit grants where thing like consent can be bypass because there’s a way to get access token silently in the background, right? The default scopes that Microsoft has in their implementation is another area to delve further into, just to see how those scopes are specified and returned, because there maybe areas to explore there.

42:21 - Consent is described. Let me preface that with, there is a model for incremental consent, so that an application can present one at a time permissions or ask the user one at a time for certain permissions as needed.

42:40 - But then it gets into dynamic user consent and some language that just hints that it’s not as quite straight forward in terms of behavior, as you might think, and complexity breeds sort of opportunities for exploit.

42:56 - And the last area is particularly interesting in that.

42:59 - Browsers today allow sort of usability features where you log into one application, let’s say you’re in Chrome, you log into Gmail, then you suddenly open up a tab and put in that same browser URL for G Drive, we don’t have to reauthenticate to G Drive, even though that it’s a separate app, you not even presented with a consent screen for either application.

43:27 - So already browsers today for usability provide this kind of auto log-in and scope expansion in the sense of switching scopes that don’t involve users explicitly, entering credentials every time, and reapproving scopes and permissions.

43:46 - What does that mean? It just means usability might have short cut some parts of the protocol because it is OAuth underneath, right? So back in 2013, it’s not all hypothetical, there was some opportunity to mimic what happened with certain Chromium browsers or Chrome browsers, basically where you could have a token traded in and get more of a super or uber token that could access a lot of information across apps without have gone through any reauthentication.

44:25 - Anyway, long story short, it’s a very interesting area.

44:29 - And beyond this list of the more important takeaway is that, we have a complicated authorization protocol.

44:42 - We have differences in plan implementation as we’ve seen.

44:46 - Microsoft’s has a few quirks, Google has some different ones, results in different behavior.

44:53 - It’s ubiquitous. It is as much a standard as anything on the internet.

45:00 - You can’t avoid it, everyone’s using it and it’s distributed by nature over a large network with REST APIs.

45:10 - So, this is particularly interesting area for us to keep an eye on, in terms of security risks and opportunities.

45:21 - So thank you, that is the end of the talk. We didn’t cover in detail, but there are open source tools that you can use to run the demo as well as do self phishing, as well as explore what permissions are available.

45:38 - Once you do get responses to phishes, and finally, there is a list of references, which is in the initial presentation, but repeated here as well.

45:51 - So thank you for your time and if there’s time for questions, we’ll take them now. .