hi there my name is bailey bursick and
i'm here with my co-worker mark
marzinski and we're from the microsoft
identity product group
where we work on active directory active
directory federation services
and azure active directory and our team
is one that works with customers who are
deploying azure 80 and we take those
learnings and feedback from those
interactions and inject them back into
the product to make it better
and so today we're going to be talking
about modern authentication for the
security admin
and since we work mostly with identity
people during our day-to-day
we have some conversations with the
security folks and we've noticed that a
lot of security folks don't have the
same identity background
and haven't gotten the opportunity to
dig into some of these uh modern auth
protocols so
we're really excited to share some of
these with you today
and so to kick it off before we get into
what saml oauth2 and openid connect are
and then share
an attack that we've been seeing on the
rise we're going to first talk about
why you would even want to move to
modern auth in the first place
and so when we're referring to modern
auth we're referring to
what's um happened after its predecessor
with basic or legacy auth which
if you're familiar with basic auth
essentially you're
not able to allow for users to mfa so
with modern auth you can actually
have mfa instead of just relying on the
username and password
there's also more tools to protect those
resources so including some monitoring
there
i have a few examples up on the slide
but in terms of a real world example
if you have your entire fleet is windows
10
for example but then an attacker is
trying to
use a windows 7 device and it's trying
to slip through the cracks there
you're going to have some additional
monitoring there to determine that
that's irregular or abnormal and so that
enhanced monitoring is going to be there
with those modern auth capabilities
and the last big selling point for
modern auth is that those user
credentials
um are not exposed to the client and as
we walk through a few of the flows today
you'll see what we mean by that
and so to get into our first flow with
saml so
saml stands for security assertion
markup language and it's essentially an
xml based authentication standard for
ssowing to
web-based apps and this one of the three
has been around for a while so there's a
lot of
web apps that already have it and since
there is a lot of libraries that have
been
um older than the two other protocols
we're going to share with you
it's easier for devs to implement so
there's also no server to server
comms with xaml and so in addition to
it being around for a while if you have
um
certain older on-prem idps they may not
support openid connect or oauth
and also it would prevent you from
having the additional overhead of having
customers consenting to an application
and so you'll see that later with the
other flows but if this sounds like
something you'd be looking for then a
cmo flow may be correct for your
particular use cases
so to walk through what that would look
like and as an example i have azure
active directory as the idp since we
come from that product group but feel
free to mentally substitute that for
octa or google or whatever you use as
your identity
as your idp and so in this example right
here
we have an end user who's trying to
access a web app via their browser
and then also it's important to note
that there's a federated trust between
azure id
and that particular web app so first in
this flow we're going to have the user
open a browser and access that
particular web app
and then after that happens then the web
app is going to redirect
the saml authorization request back over
to the browser
once that happens the browser is going
to relay that information
over to azure ad
and then that user is going to get
authenticated within azure id
and important as i mentioned earlier
that an advantage of modern auth is that
those user credits are not
shared just a cml token is going to be
sent back to the browser so
the browser isn't going to get the
user's username and password they're
just going to get like a
yes this user is good to go and so those
tokens are going to be sent back to the
browser
and then that saml token is going to be
redirected from the browser
to that web app the web app is then
going to validate that saml response and
token
and then it's going to return that
requested web page to the user
so again you know with those credentials
not being sent directly to the web app
if that web app for whatever reason got
compromised um the username and password
of that particular user
would not be compromised so important to
note
and what i just showed you was a service
provider initiated saml flow so you
might hear the term
service provider initiated or identity
provider initiated
when we're talking about cml flows um
and so
to give you an example of what an
identity provider initiated flow may
look like
within azure id that may be like
starting from the my apps page or if you
use octa that might be starting from
their end user dashboard
but essentially it's just beginning at a
different point in that sample flow
and so other than that you know from
your perspective as a security admin you
may not need to go much more deeper into
this particular one
but as a defender you know what do you
need to look for and what should you
care about with respect to cml flows
so first of all the biggest one that i
think that has been on everybody's mind
is gold and saml attacks so since solar
gate happened
this has been much more top of mind for
a lot of customers that we've spoken
with
and so as a defender you know it's
really important to ensure
that those bad actors aren't able to
compromise
those different certificates so what
happens in a golden samuel attack bad
actor compromises
the samuel assertion that you saw in
that previous flow and then is able to
forge those cml requests so essentially
then they're able to sso into any
service as any user
which is particularly scary some other
things that you may want to look out for
is defenders
the assertion consumer service url also
called the acs url
you may hear it referred to as the reply
url which is required for some apps
that is what uh routes the user to the
app that they're supposed to go to so if
this is
compromised then a bad actor could be
routing your end user to a malicious app
and so it's important that um that's
validated that
you know that hasn't been changing and
on the next slide i'll go through some
ways that you could reduce your risk
of these uh different things to look out
for
so the third thing that we've noticed is
that if the sample log
out rule is too complicated so um
if the log out rule is too complicated
the user may not be successfully logged
out
and so you could imagine that if the
user is on a shared machine or a shared
device
then the next user who would come up to
that or the next
person would be able to have that
previous user's access
and then the last thing that we've
noticed that you may want to take note
of is token monitoring so
swapping those sample tokens for session
tokens and you can
reduce your risk of that by ensuring
there's some sort of inactivity timeout
or a maximum token lifetime to reduce
the possibility of those types of
attacks and just monitoring those tokens
in general it's going to be a great best
practice
and so overall with these different
things that we've seen what can you do
so in case of something like gold and
saml attack
protecting your idps like you protect
your domain controllers is really
important
because if they can get a hold of or if
a bad actor can get a hold of
your idp then they can issue claims as
absolutely anybody which is particularly
scary
the next one is to protect your
certificate so use good cert hygiene
use an hsm monitor for any changes any
configuration changes and any addition
of certificates and if this is you know
a lot that you have here i want to let
you know that we have you know some
updated guidance
uh our azure 80 secops guide so if you
go to aka dot ms slash azure adsec ops
you're going to see a guide that
mark and myself contributed to but
several other folks within the identity
orig have written section have written
sections on
where we go through what to monitor what
to look for and certain risk levels to
be aware of with different areas
in azure id we cover everything from uh
apps to pim to other things but you will
see some related content
to those particular cmo flows so just
worth noting
and with that i'm going to hand it off
to mark to talk about two of our other
flows today
all right thanks bailey the next one
we're gonna talk about here is oauth 2
and before we get into the details uh
bailey and i found this tweet that we
thought
really landed a message home that we
wanted to make sure landed with this
audience so i'll just read it out here
but
how do developers mess up oauth2 you
only need to understand the oauth
oidc jwt which is json web token
jwks standards nuances of http redirects
nuances of rsa versus ecd essay remember
to validate
the json web token is signed using an
expected algorithm
check the expiration to have a chance of
getting it right
so this um twitter user here littlejoe
tables um there is not
wrong there is a lot going on in these
modern authentication protocols
and one of the takeaways that we wanted
to make sure this audience
uh had got was that if your developers
are starting to move
to these modern authentication protocols
they should not be trying to
roll their own implementation of oauth
and open id connect
there's a lot of things to keep track of
here um they really need to use a
library because well first of all
it's a waste of their time to like write
their own implementation when they could
use a library but
if they don't get a lot of these things
correctly it really can lead to
some drastic security mistakes and
things like that so we want to make sure
we're using libraries and we'll cover
some of that here in a little bit but
um hopefully as we talk through this
rest of these sections here this whole
thing this like word soup that littlejoe
tables had here which is
which is totally accurate um will start
to actually make a little bit more sense
so let's dig into
here uh what we mean by oauth 2. so if
you haven't heard of oauth before
oauth is an authorization framework so
it's not about authentication it's about
authorization and it's really just a
delegation protocol you may have seen it
phrased as
getting the right of access from one
component of a system
to another so that example on the right
here is what the oauth consent dialog
box looks like from an azure id
perspective so here we can see
that there's an application called
contoso test app and it's
asking for the ability for the user to
read that user's contacts calendar and
profile and um if you haven't used azure
id that's okay you've probably seen this
on different other
web properties and if you haven't seen
that at all i'm sure you've probably
seen this on your mobile phone
when you install an application right
and the application might be asking for
the ability to
maybe read your contacts you access your
pictures or access your counter
very very similar type of thing that you
probably experienced on your mobile
phone
now oauth is built to leverage http and
it uses tokens and scopes to kind of
communicate this
information so let's take a look at a
little bit of the components here of
oauth so
if you take a look at the oauth um rfc
you're going to see four key components
that's the resource owner
it's the protected resource the client
and the authorization server and this
kind of
seems a little weird it's not used to
what we're kind of looking at but as we
talk through this and then we have some
slides to kind of lay this out
visually from a sample um hopefully this
will start to make a little bit more
sense for you but the first one here
the resource owner this is just the
person
and they're going to be at a browser and
we have browser and quotes here because
it doesn't have to be
like edge or chrome or safari it could
also be like a
mini web browser inside of an
application or something like that but
they're going to be some sort of web
flow
and this owner resource owner or user
has access to an api and they have the
ability to delegate that access
to that api and what they're really
delegating access to is that protected
resource which is the next component
this is usually going to be a web api
and this is the thing the resource owner
has
access to so in that previous slide you
saw that the protected web api that i
was being asked to
get access to was the ability to read
the calendar and contact so we're trying
to get to that protected resource
the thing that's trying to get to that
protected resource is the client
now this isn't client like has to be a
thick client like on a desktop or
anything it could be a web app
but this is really going to be that
piece of software that is accessing that
protected resource
on behalf of that resource owner so that
previous example
that was the contoso contoso test app
that contoso test app is going to
consume
this protected resource it's going to
consume that web api and the way it's
going to do that
is it's going to do that through
something called access tokens and it's
going to get an access token
from the authorization server and this
is the per trusted protected resource
that's going to issue access tokens to
the client that the protected resource
sorry this is the authorization service
trusted by the protected resource
it's going to issue those access tokens
to the client that client is going to
take those from the authorization server
and take those to the protected resource
so one of the key things to learn here
of all these four components is that the
user
never is exposing their credentials to
the client
they're only going to expose those
things to the authorization server when
they do authentication there so this is
one of those patterns that bailey talked
about
why i want to move to modern
authentication it's better from a
security perspective we're not exposing
those users credentials
to that client piece of software okay so
let's take a look at this from like an
example kind of lay this out a little
bit so
um very similar to bailey's diagram here
we have our
user in the lower left that's the
resource owner uh
by the actual oauth rfc and that user is
using some sort of application
that's going to be the client and that
client is going to want to access
some sort of protected resource in our
case here that's going to be the
microsoft graph right that wanted to be
able to read
about that user's contacts and calendars
and profile it's going to be using the
microsoft
graph and the way it's going to do that
is it's going to need to talk to the
authorization server to get that access
token
in our case here that is azure active
directory and if everything works well
right like it's supposed to that client
is going to get
an access token which will show up here
on the lower left
and that client is going to take that
access token and it's going to
give it to that protected resource so
it's able to access the data it wants to
access so
let's take a look inside what's inside
this access token so this access token
is frequently called a bearer token or
if you're actually reading the
uh oauth rfc it's just called a token
and the reason it's called that is
because whoever has that token right
whoever bears that token whoever carries
that token
has the right to use it so we want to
make sure we're protecting those tokens
as much as we can we want to make sure
we're using https wherever possible
now in the oauth rfc it does not define
a token format or a message message
signature but one of the more commonly
used formats you're going to see with
these access tokens is a
jot token or a json web token or jwt and
in this
json web token it defines the ability to
sign in and code and all this is defined
in rfc 7119 if you want to look more
info
about json web token specifically we're
not going to go into too many more
details about
those specifically but there's a very
very common access token format
now the key thing to understand about
access tokens
is that the authorization server is
going to issue that access token
and the protected resource is going to
consume that access token
and those are the only two people in
this entire diagram flow that need to be
able to use those tokens now the client
job is going to take that access token
and take it to that protected resource
but the client has no need to actually
look at that token or understand what's
inside that token as long as the
authorization server
issues the access token and that
protected resource which trusts it
can consume access token our stuff will
work we're good to go the client
does not need to go and look at those
tokens or make any changes right that
kind of stuff it just takes the token
from the authorization server
and takes it to the protected resource
and then what's inside that token when
the protected resource is going to get
it
it's going to define what it can do like
the ability to do user.reader and that's
going to be inside that access token so
this is what an access token looks like
when it's encoded this is again this is
what the client's going to see
and the client has no need to actually
inspect this or look at this it just
needs to take this
and take this over to that protected
resource so let's look at what it looks
like when it's actually decoded
so uh powerpoint isn't the best uh
tool to kind of look through an access
token so uh this is like a json
file so but we bolded a few things here
to kind of make this stick out for you a
little bit so the first one here is
the very top you see the type is that
json web token this is coming from
azure id and we can tell that because
you can see that kind of towards the
upper middle
you see the field of iss this is who
issued the token
and you can see sts.windows.net that's
azure id
and we can see the app display name is
going to that line of business
workshop demo so um those are some
things in the token
um there's lots of stuff in here we're
not going to cover all them but this is
what it looks like when it's decoded so
another question really is how do i move
this token from one
field to another so there are many many
different
flows as part of oauth and one of the
things as defenders that we want to make
sure that we're doing
is we want to make sure we understand
these flows and what is the right flow
for the job i've seen for multiple
customers that i work with
that um sometimes the devs just don't
know and they're just pick a flow that
they think is right and they really
should be using a different flow and
i've had this where the hawk on this
doesn't do this and
they've really just picked the wrong
flow so what i've seen some customers do
this that is actually really successful
is
the defenders and the app development
teams and things like that kind of agree
on
these are the different types of
application behaviors that we have in
our environment
and then as a new application comes in
this is the right flow for the for the
job so let's
talk about these flows the first flow is
the authorization
code grant which is the majority of your
app types will use this and i have about
four or five slides we'll kind of walk
through this flow
it's kind of has the most steps in it
but the other flows kind of behave in a
very very similar way but once you kind
of understand that flow
you'll be able to pick up the rest
pretty pretty easily the next flow is
the implicit
grant flow and this should only be used
for single page apps right so that's
where everything kind of lives in the
browser
and we kind of want you to move to
authorization code flow if possible and
the reason for that is
that client piece uh that client
component also needs to authenticate to
the authorization server
and an implicit grant flow because
everything takes place in the browser
there's no shared secret from that
client so we kind of want to move you to
the authorization
code grant flow as possible another very
very common flow
that you'll probably run into is the on
behalf of grant so this is when that
client application is going to call that
protected resource like call a web api
and then that web api needs to call
another web api so
i'm very common i've seen with customers
where they're maybe calling some you
know base api and the api needs to query
another database somewhere else for more
additional information
the on behalf of grant would be the flow
you'd want to use for that
the third one here is the device code
grant so this is when we have those
um input constrained devices where we
don't have maybe a web browser we don't
actually maybe have a mouse and keyboard
you know so iot types of stuff
maybe we have like just an ssh window or
something like that that's when we
want to use a device code grant so for
iot printers things like that this is a
really really good
flow to use the next one here is the
client credentials rent
so this is really for those service and
service calls there's no
uh resource owner in the picture there's
no user in the picture so this is for
like service accounts
and daemons that's when you want to use
that so those are the main five flows we
want
people to be using now i'm also going to
include this six flow which is a legit
flow but
we really don't want to use it which is
called the resource owner password
credential grant or sometimes this will
be referred to as
the ropc flow and if you look at those
terms we just learned which is resource
owner user
and password credentials grant you're
basically just having the user
give their username and password to the
client tab which was one of those
patterns that we don't really want to
follow that bailey talked about
moving to modern authentication we don't
want to do this so be very very
sure if you're going to use an app that
does ropc flows because
you need to really understand the risks
that you're going to be exposed to and
one of the customers that i work with
didn't quite understand that and they
had a bunch of apps that were being used
in rpc flow once they really took the
time to learn these flows they realize
they don't want to do this at all and
they move to the authorization code
grant flow
so let's take a look at what this um
actually looks like here from a
authorization code flow so we have those
same resources that we just showed you
before right we have our user who's the
resource
owner we have the application which is
considered to be the client
we have that protected resource which is
the microsoft graph
we have our authorization server in our
case here this is going to be azure
active directory but this could be octa
google any other type of identity
provider that does oauth
and what's going to happen here is that
application or the client is going to
request authorization
to the resource owner so that
application is going to request
uh authorization to the user and it's
going to redirect to that authorization
endpoint
against azure active directory and here
this is where that user is going to
provide their credentials they're going
to authenticate against the
authorization server
and once they authenticate that's where
we see that dialog box that you saw
before
and once they click accept to that the
authorization server is going to
redirect
the user back to the client and give
them a special authorization
code now the client is going to take
that authorization server
i'm sorry to take that uh take from the
authorization server that authorization
code
i'm saying the same authorization word
like six times and i'm getting like
tongue tied there so okay we have
authorization code and it also has its
own credentials right
and it's gonna use those client
credentials it's gonna present those as
well as the authorization code it just
got from that user
um to the authorization server that
everything works out like it's supposed
to
now the client is going to get an access
token
and it's going to use that access token
it's going to go against the protected
resource
and it's going to be able to access that
resource on behalf of that user so that
dialog box that we saw
with the contoso test app was asking the
user can i read your
uh contacts and calendar and profile the
user clicked yes
this is what's going to end up happening
is that client piece of software is
going to get an access token it's going
to go against the protected resource
which in our case here
is the microsoft craft okay so
a few key points i want to make sure uh
we understand from an oauth flow
perspective so the first thing was
that user or the resource owner never
provided their credentials to the client
app the only place
that those client credentials their
username and password was used or
however they're authenticating
was against the authorization server
which in our case here was azure
this is a really really good pattern we
did not expose those credentials
to the client piece of software this is
really really good from a security
perspective
the second thing here is that the user
has the ability to delegate those
permissions
that are needed for the client and we
can make sure we're following
the principles of lease privilege right
those permissions that that client asked
for
with the ability to read contacts and
recounter because that's all it really
needed to do it didn't ask for
to read everything else about the user
it didn't ask to read all users in the
directory it didn't ask to read write
into the directory it was able to be
scoped down
to only what that application needed to
do and this is a tremendously good
security practice as defenders that we
want to make sure
all our applications are following
that's going to be in our go do's coming
later we want to make sure we're using
lease privilege wherever possible
and then the client access for uh act
sorry the client access the protected
resource
with the access token and it's the
reason that works is because that
protected resource
in our case here is microsoft graph
trust the authorization server so you
have to have that kind of set up ahead
of time but that's how that access token
works
so this is really really good flow
authorization is we want to be using
but let's take a look at this ropc flow
this is one of those patterns that we
don't want to be following so it's a
real simple one
the user gives their username and
password
to that application an application
logs in as that user to the
authorization server to get that access
token
there's no delegation here there's no
mfa here right this is just the
application
authenticating as that user to the
authorization server and this is
basically
just basic off right so bailey talked
about we don't want to be on basic off
we want to move to that modern
authentication
this is not really a good pattern from a
modern authentication perspective there
are very specific scenarios where you'd
want to use this
but this is very very risky so we want
to make sure we understand
fully what's about to happen to us
because our users
are going to give their username
password to this client application that
we better trust
because that client is most likely going
to cache that username and password as
well so now those credentials are going
to be stored there so we really really
don't want to use this pattern
unless we really really have to maybe
it's a specific kind of business app
that you guys
um write as defenders or something like
that and we really know what we're going
to get ourselves into we're okay with it
but
you know you really really want to make
sure everyone's aware of what's going to
happen
when we use ropc code phone okay
so let's look at open id connect so open
id connect
is actually a standard that's built on
top of oauth 2. so auth 2 was designed
this way to be extended like this an
open id connect
it basically extended oauth 2 and now
this will also perform the user
authentication right
oauth 2 is authorization sometimes the
preview is off z
open id connect is off and open id
connect uses
json web tokens as well as json object
signing and encryption
and basically you're going to have a
very very similar pattern
as you saw with oauth 2 except for when
you get an access token
you're also going to get an id token so
one of the ways that you can kind of
visualize and think through this is that
that client piece of software
is going to be that relying party i'm
kind of like how bailly talked about
from a cellular perspective where that
identity provider trusts that um i'm
sorry the app trust the identity
provider very similar way here
the client is now the relying party and
then this claim is going to be who
issued that token who's the subject of
the token who the token is for
how long the token is good for it's all
going to be an open id connect
so let's take a look here how this
actually works so it's going to be very
very similar to our previous flow and
again
we have our same components as before we
have our resource owner who's the
user we have the client which is the
application we have a protected resource
which is the microsoft graph we have an
authorization server which is azure
active directory so
again our application is going to ask
the user
to get redirected to the authorization
endpoint because it's going to ask for
that consent so it redirects the user to
azure active directory
and we should see this is when the user
gets
authenticate and gets prompted so this
is just like before the user
authenticates they click accept
now the authorization server is going to
redirect the
user back to the client piece of
software with that authorization code
that client now is going to do this
again same thing as authorization code
flow right so now we're going to send
the
client credentials as well as the
authorization code to the authorization
server
and if everything works out we're now
going to get that access token like we
got before but now we get an additional
token we get that id token and now that
application is going to use that
access um token to protect to access
that protected
resource and now we have an id token
over here from the application
perspective
and it's able to request additional
access tokens to kind of keep
um accessing that resource if it needs
to so the openid connect flow
is very very similar hopefully that
makes sense you're not at this point
it's very very similar to the oauth 2
flow
instead of just getting an access token
you also get an id token
all right so what should we be looking
for as defenders from this so the first
thing is
you want to make sure you're asking your
independent software vendors like isvs
or you know people you're buying your
software from
you want them to support open id connect
wherever possible we don't want to use
these legacy protocols we want to be
able to use things like mfa we want to
build you some of those additional
uh things that bailey talked about where
we can detect things because we have
more information as defenders which is
really really good it's harder for
the attacker to kind of guess all that
different stuff we really want to use
this
and i know a lot of people feel that
like well i'm just a random company like
why would they listen to me
bailey and i work with some very large
customers and some actually some very
small customers and
the voice uh really really matters um so
when you're
uh you know when you're buying software
ask for this
and tell them that you want this you
don't want to do these legacy protocols
anymore you want to make sure you're
using open id connect wherever possible
okay the next thing uh if you're not
sure if it's a good idea to roll your
own library
reread that tweet and ask your devs if
they know all those different parts of
it because
you just really don't want to do this
it's kind of you know to me it feels
like it's very much like kind of like
rolling your own cryptography where
you'd be like oh no no we're not going
to do that we're going to use
you know what well-known things use our
libraries we want to make sure we do the
same thing from this
it's a waste of time from your
developer's perspective and also there's
bug fixes there's updates to things or
secure things
like you just don't really want to rule
your own so if you're using azure id
or any other microsoft identity stuff
like azure ad b2c the msl library is
what you want to use we have them for
python.net java you know mobile stuff
all kinds of stuff use these libraries
it handles a lot of this
these problems for you automatically the
third thing is
we don't want to use the ropc flow
hopefully at this point i made that very
clear
unless you absolutely have to and you
have a lot of trust in that client
application because you're basically
doing basic
auth your users are giving up their
username password to this piece of
software
and it's probably going to cache that so
we really really don't want to use that
uh fourth thing here we want to make
sure we're using https
wherever we can for this because whoever
has that access token
has the right to use it so we want to
make sure we're protecting those access
tokens
sometimes like i said they're called
bearer tokens and documentation or just
tokens
we want to make sure protecting those we
want to make sure we're using https
and then lastly here we want to make
sure we are focusing on least privilege
when it comes to apple education consent
that's a great great practice in in
general
um so when your line of business apps
are being used to open id connect you
want to make sure they're not asking for
too many permissions which is pretty
common right from a
like oh i don't know what i'm going to
need so i'm going to ask for the ability
to do directory read write all and just
do everything we want to make sure we're
following these privilege and we also
want to make sure that when we purchase
software
it is also following these projects this
is not a
new problem around least privileged with
applications right anyone that's been in
this field a little bit
someone buys a piece of software they go
okay can you please set up and install
it for us and it's like it needs domain
admin and it needs schema admin and
you're like
we're not doing any of this stuff this
is way too many permissions very very
similar thing with this we want to make
sure we're enforcing lease privilege
with this
and then last here at the very part here
there's an emerging attack when it comes
to application consent that bailey's
going to talk about so this is some
stuff we're starting to see
we want to make sure his defenders were
really really aware of that so with that
bailey's going to kind of
talk about that and then close up with
some go do's
thank you mark so diving into some of
those application
consent phishing attacks that we've been
seeing on the rise and before i go into
what that attack actually looks like i
want to go through some vocabulary that
may be
new to some folks who are listening so
i'm going to disambiguate between
delegated permissions and application
permissions and so
if you haven't heard the term delegated
permissions before we're basically
talking about permissions that are used
by an app that have a signed-in user
present in order to make calls on behalf
of that user and these can be consented
to by
non-admin users but some higher
privilege permissions do require that
admin consent
uh in azure id it may be different for
your identity provider
and then those effective permissions so
you can see i have this little venn
diagram
at the bottom and that's referring to
the intersection of the user's
underlying permissions
and what the application has been
granted consent to do
um and so essentially if we were to
think about it if a user were to consent
on behalf for an
app to read email they're not consenting
for
that app to read every user's email it
would just be theirs because i as a user
cannot read your inbox
for example and so we're talking about
application permissions it's a little
bit different so those are used by apps
and they run without a signed in user
present
and these are typically going to be your
higher level permissions and they always
require admin consent
and so some of these can include app
roles and app only permissions
um but you can think of these as
delegated
as an end user i can consent to these
application as an admin i have to
consent to these
and if an admin consents to delegated
permissions that consents to it on
behalf of the entire tenant which is
important to note as well
and so what is the attack that we've
been seeing come on the rise and so this
is something and
i have some screenshots of what this may
look like to end users
a lot of covet 19 themed emails um or it
could be a malicious web app so
for example it'll be a very normal
looking 0365 access
looks legit for my day to day or perhaps
a
you know link like this that i would
have to approve
and so essentially what we've seen
happening is that if a user then
consents and they go through those flows
that mark and i showed you earlier
um then the attacker can gain access to
their mail forwarding rules
file contacts you name it based off of
the permissions that that app has been
granted and so how do you find that
illicit consent
so speaking from an azure id perspective
and so
you know i imagine it would be a similar
process with whatever identity
provider that you have but what you
would look through is that first going
to that office 365 portal so if you
search through those audit logs
you can actually look for indicators of
compromise there and so
if you look at particularly the is admin
consent flag if that's set to true
then that indicates somebody with that
global admin access
may have granted access or granted that
permission on behalf of the entire
tenant which is particularly scary
because
if an admin fell for one of those
consent props that i showed earlier
then that's for every user in the entire
tenant and so not just your
everyday user with a smaller scope of
effective permissions
you can also check in the azure 80
portal so if you go into the audit logs
there
or if you go through uh go over to the
enterprise apps tab you can flip through
the permissions tab for each individual
apps
but i imagine that as defenders you may
have a lot
of apps to go through and that may not
be a good approach for you so we have a
powershell script up on the screen and
so if you go to aka dot ms
get azure ad permissions it'll actually
spit out a report of
all the granted permissions in your
environment and different apps and i'll
walk through what that looks like in a
moment
and that's totally free um but you know
an even better solution would be using
something like mcas or another cosby
solution um but this powershell script
is really awesome
because as i pull up an example here if
you go through and you start with
um just checking out the higher risk
apps or higher
um or apps with higher user assignment
that's something to monitor that if
you know there's something that you
wouldn't expect to be seeing
also be sure as you go through these and
if you see anything that looks really
bland so a um a customer of mine
actually had this attack happen to them
and it was where an end user was
consenting to something that had a very
generic name
but it seemed very similar to a video
conferencing app that they normally used
every day
but it actually put their entire company
directory up
online because they consented for the
app to be able to read the entire
directory which as an end user i can
see who's in my org and so all of that
personal information was published
online so
something to note in addition to just
your everyday users it's really
important to monitor those high risk
users so we have that in a tab for you
as well if you run this report
and so that's where you know those who
have higher privilege or higher access
so
for example any executives anyone who
may work in finance someone who
if the content that they had access to
got leaked it may be you know a front
page news story or something for your
organization so
might want to look into those and also
reviewing permissions for those
delegated applications so
you know especially those read
permissions like my customer um
fell victim to write permissions uh
star.all
um reviewing those to make sure that
they're appropriate when i say
reviewing to make sure that they're
appropriate i don't want you to have a
takeaway from this saying that
you know if an app asks for user read
write all it is
objectively a bad application that's not
what i'm seeing here
what i'm saying is to look at the
different permissions that are assigned
to a particular app
does this look legitimate is this app
something that actually needs that level
of permission
and then making a judgment call there as
a defender while balancing
you know the business impact there and
so i have a few more actionable steps
that you can take as well within azure
id
um but this also applies to any idp that
you may be using
so in terms of application consent uh my
customer had
this very bottom one checked so allowing
end users to consent for
any app um without restrictions there
and so we actually advise the center one
here
the little goldilocks recommendation of
allowing end users to consent to apps
from
verified publishers and so that would um
the publisher verification process is
something that
on the next screen i'll be able to show
you one where it's unverified
um but if they are verified that means
that you know microsoft has confirmed
that that is who they say they are
and that you can have a little bit more
trustworthiness to that application
and something else that you can do is by
you know setting up a policy with
mcas and you'll be able to automatically
revoke an
app or specific user from an app if risk
is detected
so something else to note there as well
now if you've selected that little
goldilocks option
you know you might say hey do i have an
ad as an admin have to consent to all of
these on behalf and the answer to that
would be no
so risk-based user step-up consent is
enabled by default within azure 80
and essentially the way it works is that
if i as a user
request for something to be stepped up
to my admin
then or rather excuse me i as an end
user want to consent to an
app and then it will require that admin
approval so
in order for the end user to get access
i as an admin will have to go through
and say
yes that end user made consent to it and
so
the admin has the ability to prove or
deny the end user just gets a warning
and an audit event is going to be logged
as well so you'll be able to have all of
that tracked as to
which admin um said yes to that user
having access and whatnot
and so a third thing that you could do
is detect risky oauth
apps so mark went through that oauth
flow earlier but something you can do
here is by
you know running that powershell script
an even better thing to be doing would
be to use something like azure monitor
where you could set up alerts that'll
notify you
when an oauth app meets certain criteria
so if they have that high permission set
or if it was authorized by you know 50
or more users or whatever you want to
set for yourself
and then that way you'll be able to be
in the know as to what's going on
and the last thing that you know if you
have the budget for it or the ability
would be to have a um hunting solution
like a cosby solution like mcas
because then you're going to be able to
have some fancier detection and
monitoring there and
additional hunting capabilities
now i think also it's important that if
you see something say something so
at the bottom of these app consent
screens it'll have a does this app look
suspicious report it here
and that'll send it over to our team
over at microsoft and we'll be able to
take action on it so
if you see something like this and if
this app like data extractor doesn't
seem like something legitimate that your
user should be seeing feel free to
report it to us and we'll be able to do
something about it
now some further app consent resources
that if you are not already aware could
be really valuable for you to take note
of
so we have some incident response
playbooks at aka.mslash
ir playbooks so if you haven't updated
yours lately that would be a great place
to start
we also have a sample malicious app
consent
or app with a consent prompt it's
written in python
and so you can go to mark's github to be
able to go check that out if you want to
go scare some people and demo to them
why this is really valuable that they
should go look at it
and then if you felt like this app
consent section was really short and you
wanted to learn a little bit more about
it
there's actually a full length hour-long
talk available on youtube
at aka.msla b-side ct for connecticut
2020 on app consent and so you can watch
an hour-long version of this instead of
about
a 15-minute bit on app consent
so if we look a little bit different we
had a slight glitch um but so we are
back
on the recording and so to get into our
go do's
uh that we have mentioned throughout the
talk today if perhaps this was a lot of
content
also know that this entire talk is
recorded and i believe will be on
youtube
so feel free to go back and replay any
bits if you want to
have a little bit of a recap because i
recognize this is a lot of technical
content that we're throwing at you
so the first go-to that we have for you
today is to start moving your apps to
modern auth so at the very
beginning of the talk we talked about
the advantages of modern auth over basic
auth
in that you can mfa you have additional
monitoring and all the good stuff
um and also that your users credentials
are not going to be
exposed so moving those apps to modern
auth if at all possible
use open id connect or oauth 2. if
that's not possible
saml is also a good option especially
because it's been around for so long
the second thing that we recommend that
y'all do is protect your
idp like your domain controllers
um so also protecting and monitoring
your certificates
and all of this kind of bubbles up into
those golden samuel attacks that we've
been seeing especially if you're
orgasing
so laurie it happened what do we do to
help um reduce our risk of something
like that happening to us
protecting your idp like your domain
controllers the next thing to kind of
look into
is ensuring that you have inactivity
timeouts and maximum token lifetimes
and then if you would like more
information on some
things to do in terms of security and
operations if you go to aka dot ms slash
azure adsec
ops we have a guide for you on things to
monitor different risk levels
and things that you can do within azure
id and if you don't use azure id
it's still a good guide to get you
started on some best practices that you
can apply to your own identity provider
the third thing that we really want to
stress is that you should use the
correct oauth 2
or open id connect flow for the job so
mark went through several different
flows
look into those and determine what's
best for your
situation also encourage your developers
to use a library and
not to roll their own just like as mark
mentioned how you wouldn't want them
creating their own cryptographic
algorithm
you don't want them to roll their own
libraries and so also in addition to
that
moving away from ropc if at all possible
because again
the whole purpose of using modern auth
one of the big selling points is that
you are not exposing that user's
credentials
and so if you already have apps using
ropc try to move over to a different
flow
the fourth thing is to ensure least
privilege is being followed by internal
and isb apps
so if you do end up running um that
powershell script to go see all of those
permissions
or if you do check up on permissions in
your environment you know call upon your
vendors to see if they can
make an app be lesser permissioned or
use the least privilege
possible if you believe that app is over
permissioned also your internal
developers look into
if they can use a lesser permission to
do that particular action
also look at current consented apps for
those that are suspicious the ones that
have really generic names like oh 365
access
or just mail we've seen other ones with
more hackery sounding names but often
times these apps are trying to hide in
plain sight so you're going to see a lot
of really bland
generic names on there within that also
updating your instant response
books for this type of attack and if you
wanted to that youtube link that i
shared earlier to go watch that
full bit of content on those app consent
phishing attacks and the very last thing
is to go deeper on oauth 2
open id connect saml json web tokens
this is going to be the new ntlm
kerberos tickets so if you are an
subject matter
subject matter expert on you know ntlm
kerberos all of that
just know that the next wave of stuff
that you're going to need to know
is a lot to open id connect and some of
the stuff that we've talked about today
so really set aside some time to go
through those flows and make sure that
you were
able to accurately defend on those and
so
as we close out mark was there anything
else that you wanted to share today
no i think that's it i mean i just
really can't stress that last one like
you're going to be seeing more apps that
use these protocols not less as you go
forward so this is really worth the time
i mean
we went very quickly through i mean this
is some very complex topics
that you may not have been exposed to so
we have quite a bit of time here i think
for us to be in the chat to answer
questions um this
is a very hard talk to do with no
audience
faces or anything like that so we have
no idea if you you followed it so
we'll be um in the chat here to answer
any questions but yeah please make sure
you spend some time
understand this stuff because you're
going to really want to do this i know
some of the best security people
they really understand ntlm they really
understand kerberos tickets kerberos and
all that good stuff
this is going to be the next way with
that stuff so you really want to make
sure this is a good investment of your
um timing career to help protect this uh
protect your environment using this
stuff so
um with that we have some time for q a
bailey i will be in the discord
you can also reach us on twitter she's
at bailey bursick and she's shooting up
the twitter followers chart
i'm at mark morrow but feel free if you
watch this later if you have any
questions feel free to bring us up ping
us and we're happy to
answer anything we can