- Hi, welcome.
Today, I'm going to be talking about
new phishing attacks that exploit OAuth authorization flows.
My name is Jenko Hwong,
I'm currently a Researcher at Netskope.
Here are some of the areas that I've dabbled in
and are interesting to me from my research perspective.
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.
So in the beginning,
certainly phishing was predominantly carried over SMTP.
This is probably late 90s when we started to see phishing.
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.
As mobile came along,
more apps, protocols came phishing,
then targeted those applications
and so we got SMS phishes, snitches, IMs chats.
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.
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.
So none of this is new.
And in this case,
maybe the attackers trying to create
something like Citibank's website hosted in Azure.
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.
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.
There might be additional content inspection
(sneezes) excuse me,
content inspection use to detect credentials
within the payload as well, form, fields, et cetera.
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.
So none of this is new,
this has been sort of 10 or 20 years of phishing evolution.
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.
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.
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.
So in this case,
there's a redirect the user then authenticates
as they would with their identity platform.
And when we're talking about OAuth,
it's really Azure AD or Google Identity.
That authentication process could be a very secure
and have MFA.
Ultimately, the user is presented with some kind of
authorization step, approve these permissions,
approve this task.
The permissions are called scopes in OAuth land.
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.
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.
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.
And in this case, it creates a URL
that you can copy and paste into a browser,
but it's actually an OAuth flow.
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.
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.
So initially phishing responded
to this new authorization identity platform called OAuth
with so similar techniques, just, here's a new login.
Yeah, great.
We have an OAuth log in, but it's just another log in,
I'll just move it.
So, a lot of this was business as usual
from the phishing side.
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.
It might redirect to a valid domain login screen
or something else depending.
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.
The controls for the most part,
I would say have stay the same
because really the techniques have not changed much.
So why do we care to maybe delve
and research into the protocol deeper, right?
So far, this hasn't made much difference.
Well, obviously I wouldn't be talking if that were the case.
Here's why attackers
have dealt deeper and why from a research perspective,
it's worth us focusing on this.
One is, instead of targeting the username and password,
we target the OAuth session tokens.
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.
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.
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.
So getting access to session tokens effectively allows us
to quote, bypass MFA.
The second reason is that all of this is REST enabled,
so hijacking, the actual tokens does not require
a compromise of an endpoint.
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.
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.
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.
This is far easier, far easier because we have REST APIs
and we'll see that in the upcoming deep dives.
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.
So in the illicit consent grants,
it's exploiting wider consensus privileges,
tricking the user to approve them.
So this works with attacker, creating their own application,
a fake application, perhaps named close to an existing app.
They register it in the identity platform,
it could be their own account.
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.
I asked the user to give this application access,
read and write to everything in Google Drive.
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.
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.
So this has happened and there was a reference here
just in the last year or so,
of illicit consent grant attacks.
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.
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.
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.
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.
So, this is where complexity is the enemy of security.
So let's get to device code authorization,
which is really the flow I want to focus on today.
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.
Best example is smart TV, where you need to authenticate
against your content subscription,
so you can get your movies on the TV.
They'll have this menu these days could be, you know,
some device like a Roku or, you know, Apple TV.
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.
So, well, there's an RFC to solve that.
Back in 2019,
some smart people came up with a way to do that.
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.
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.
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.
They even have a QR code capability,
so that your mobile device can even go to the URL directly.
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.
However, usability is one of the biggest drivers here
and I have a saying that,
on usability is the father of insecurity.
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.
So, let's look at device code authorization
a little bit deeper.
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.
So, okay.
Similar to what I said before.
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.
Just a short note,
Dr. Syynimaa has a great deal of information
at his blog, o365blog,
super great resource.
He has his tool set AAD internals,
great stuff about Windows AD, Outlook Office,
as well as OAuth in there.
It's highly recommended.
So let's jump into
demonstrations.
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.
And we'll actually go through a device code flow
and sort of see the implications from both sides.
So in this case,
we're logging into
the standard URL
for this company.
That Ed is part of Feast Health,
and we want to gain access first to Outlook.
So we punch in name, password, get two factor.
This case it's software based, we punch in that code.
Do you want to stay signed in? No.
We'll go through it and boom, we're on Outlook.
Now, meanwhile,
the attacker independently is thinking of phishing.
We'll start up a script, sort of running in demo mode.
This is part of the open source software,
we are releasing concurrently.
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.
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.
When you create an application, the OAuth world,
you have to get back ID in a secret.
We're actually reusing one,
we didn't have to create an app to carry out this phish.
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.
Okay, we'll explain the other fields as we go.
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.
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.
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.
It's awesome, Ed can't resist and he types in the code.
Now let me go back and point out in the message.
There's a real URL in here, it's microsoft.com,
nothing shady or funny.
It's a trap link but it's actually pointing
to the text as part of the device code authorization.
So we can see that some phish detection might fail right off
here on domain alone because of this microsoft.com.
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.
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.
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.
Okay.
We use the client ID and we get the title.
All right, so there's continue
and that's it for the user.
They entered the code, they authenticated, they're done.
Meanwhile, we are polling the attacker script is polling,
checking every five seconds.
This is all part of the protocol
for device code authorization.
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.
There it is.
So let's note a few things, okay.
Number one,
what's in the response is scopes associated with the tokens.
These are the permissions that
we have access too with this token.
The resource,
the tokens applied to scrapped API,
we have an access token, we have a refresh token, okay.
This is great.
What can we do in the graph API?
Okay, you can see the indirection here.
We put the application Microsoft Office,
that's what the user thinks they've approved.
We've got access to the graph API,
which is a little bit broader than just Outlook.
So one thing we can do is get all 80 users
with that access token,
running as Ed or with his permissions.
And there's a list of three users, Ed,
included David and Sandra.
We will go to, just to compare, we'll go to
Ed's view, the victim,
in Azure Portal.
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.
What else can we do?
We can gain access to Ed's email.
So we just did a call with that same access token
and got three emails.
Thank you from 365 team,
some social security credit card numbers, all looks great.
Switch to Outlook as Ed and you can see in the inbox,
nav pane on the left, the same emails.
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.
So let's do one that allows us
to get more at all of Azure, okay?
More of all of Azure resources.
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.
We are still using the Outlook client ID and the scope.
We have to specify scope before we didn't,
we got a bunch of scope permissions.
Here we're using open ID,
which is a pretty basic scope sort of username, email,
basic profile information.
Okay, and what we got back is interesting.
We request their resource or Azure and that's fine.
But look at the scope, it changed,
which is part of the protocol.
It comes back with what you really have access to.
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.
That happens to be a global administrator, we have hit gold.
Okay, we got a new access token.
This access token has the scope privilege for this resource.
So, and we didn't really have to supply anything special.
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.
Okay, long list.
Let's go back to the beginning.
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.
Let's look at subscriptions, it is in fact,
Azure subscription 1, great.
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.
Virtual machines that has SSH keys.
There's a storage account for data.
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.
And in fact,
there is the container
and there is ss1,
ss3.
So everything matches up
and we've just enumerated everything.
And since, as a global administrator,
we could do anything pretty much within the whole AD,
as well as the subscription.
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.
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.
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.
Normally with a smart TV example,
the user's explicitly trying to hook up a streaming service
and authenticate to it.
So the user is expecting to be part of this flow.
Here, the attacker's in control, user is sitting,
minding their own business, we will, as an attacker,
start with generating some user codes.
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.
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.
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.
Device_code, which I'll use later,
user_code, which I'll give to the user
to log in the device with expiration time.
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.
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.
Look at all of the stuff that the application
or the device has done.
No secrets required.
All public information in fact,
client IDs are,
for the most part easily determined for local clients.
And they're also logged,
so it's actually really easy in the Microsoft area
to identify client IDs, no secrets are needed.
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.
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.
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.
You just had to point the user to identity platform
and give them a code, and then you have their tokens.
Once you have access tokens,
that pivot from a Microsoft perspective does look like this.
You supply, you make a refresh token call
and you get back a fresh set.
And here's where you can see the scope changes.
We pointed this out during the demo,
and this is just repeated just to show that.
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.
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.
The user does not see a consent screen,
does not see a list of permissions.
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.
Google's a bit different, we do supply a scope.
It just means that the scopes you get,
ultimately with OAuth tokens
are things you never had to request.
And we ended up getting user impersonation,
scopes and Microsoft, which allows us to do anything
that the user can do.
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.
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.
Okay, but this is limited
because the lateral move is not logged.
The lateral move being, when we refreshed
the token to get an Azure access token, that was not logged.
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.
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.
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.
So that is the sign-in URLs
that start this whole process off for the user.
There are some standard ones for Google,
Microsoft has two
because the second one redirects to the third.
So we could block those URIs,
security team could.
But it's an imperfect solution
because you actually might need to allow it
for some valid log-ins.
What's an example of that?
Not a smart TV that could probably be against all policy,
but it could be
Azure.
Azure CLI
does device code authorization,
at least has one flow
where it does verbatim device code authorization.
So,
you have to be careful what is broken
if you're on the defensive side.
And it just means that there's opportunities
where the prevention may be imperfect
or can't be put in place.
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.
But IP allow lists and often our challenge,
as well as geolocation and other characteristics.
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.
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.
In Google, that is more obscure, you can do it,
but it's not as obvious as a straight API call.
There are some practical considerations to keep in mind,
the main one is that the user
or device code one generated is temporary.
It will expire typically after 15 or 30 minutes,
it's in the response of the REST API call.
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.
If going over email, an email would have its advantages
and that the phish could be rich, all right?
It could sell a story.
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.
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.
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.
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.
So I pointed that out mainly because that is the one area
from a practical implementation viewpoint
would need to be accommodated.
So, there are some comparisons between OAuth providers,
in this case, it took the two major ones,
Microsoft and Google.
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.
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.
You get what you get with the initial scope.
But all in all this drives towards
maybe mentioning some ongoing research areas.
The problem with OAuth is not that
it's got flaws or is insecure,
the problem is more that it's complicated.
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.
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.
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.
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.
And the last area is particularly interesting in that.
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.
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.
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.
Anyway, long story short, it's a very interesting area.
And beyond this list of the more important takeaway is that,
we have a complicated authorization protocol.
We have differences in plan implementation as we've seen.
Microsoft's has a few quirks,
Google has some different ones,
results in different behavior.
It's ubiquitous.
It is as much a standard as anything on the internet.
You can't avoid it, everyone's using it
and it's distributed by nature over a large network
with REST APIs.
So,
this is particularly interesting area for us
to keep an eye on,
in terms of security risks and opportunities.
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.
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.
So thank you for your time
and if there's time for questions, we'll take them now.