[Music]
okay
oh
thanks for joining if you're new you
missed the first hour it was fantastic
shame on you
no seriously um
this is part two so in this talk we're
looking at is mistaken identity samuel
oath oydc and for those of you hang out
hey thanks for staying
again my name is wolfgang cisco
advisory cso work with duo
so 2020 happened
and i had more time in my hands
and uh as we all did and so i had a lot
of time to get in the lab and had a lot
of time to get playing i started
thinking about something i'm like you
know what what's interesting is
if you like plot out what people do we
connect up we authenticate we authorize
the user and then the user does
something
it turns out we've got like a lot
on the front end of that right and we
can do firewalls and proxies and
everything we can do everything i talked
about in my last talk in terms of
identity proofing and multi-factor and
passwordless risk-based authentication
from an authorization perspective we can
do
our back in abac and segregation of
duties uh we can do
um you know the the risk-based
authorization continuous model we have a
lot of controls
right up until the user does things
and so if you think about this like the
principle least trust which is do i
trust the user to do something
right into the principalities privilege
which is all right now they trust you
what can you do in the system we've got
a ton in the beginning which is what
that street cred talk was all about this
talk is the next part
because i started wondering what if i
had batman level money
and of course like all you guys are like
if i had batman level money what would i
do i'm sure i would spend it on my
security program right right
um probably will get the black suit the
cowl uh probably chased down the people
who did the ransomware and beat them up
there would be some of that i'd want the
cool car i would want the cool car
if we had batman level money we could
probably solve
all that authentication of all that was
solved what would happen
and it occurred to me
the line from
one of the early batman movies where
joker was like without me there'd be
without you there'd be no me i mucked up
the line sorry for that without you
there'd be no me right without batman
there's no joker without controls
there's no adversaries and those
controls always get better the
adversaries always get better fishing is
a great example of this we've had on
nearly 25 years of fishing and uh in the
early days
they would put bad stuff in emails but
we shall watch your email they're like
haha i'll put it in a zip file like no
you won't i will block all zip files
like aha i will send it in iso file and
oh by the way now windows open those
automatically check mate you're like no
i shall block the iso files
it is very interesting watching those
patterns because usually about six
months to 12 months from the time a
control becomes available it becomes
widely deployed right in that type of
window um the adversaries still keep
using the whole technique and then it
passes this threshold
and once it passes that threshold in
this case with the iso files once like i
think the number was 40 once 40 percent
of the organization was blocking iso
files they just changed the img files
and windows still opened them anyways
and they bought them another two years
of fishing us
this is what jokers do
and this is what controls do all
controls do is they make better
criminals
so if we solve for that if we solve for
that where are they going to go next
they're going to go here so this talk is
not about what you should do for today's
threats this talk is about what you
should do for the threats that we're
going to face in 2025.
now arguably if you're building
applications and you have pen tests
you're like yeah but my adversaries are
my pen testers and they're trying to
steal and do this now okay fine cool but
my main point is
right now this is plenty of
opportunities for criminals to exploit
terrible credentials
um
but this is where they're going to go as
we get better at that
so this talk is about saml and oauth and
what you see um some quick scoping i am
a cso so i will be making cso level
statements and if you're an engineer
you're gonna be like but that is wrong
that is that is absolute and you can
email me and you can tell me i'm wrong
or when we do q a you could say you were
wrong i'd be like great here i'll give
you the microphone because you know it's
better i get that i get that this is a
blue team talk this is a security
architecture talk this is about the apps
we developed this is about defending
what we are creating
so we're going to talk through some
mistakes
and
we're going to start with a basic
question please obviously make sure that
we're doing sso please make sure we're
fettering your identity please make sure
we're using the strongest possible
security in your sas applications uh if
you guys haven't
i i direct you to sso tax which is a
whole bunch of people who are charging
way too much for sso please give those
people grief because we need to fix this
so we can all
do that however
once we do that what happens
all right
when we authenticate with sso
generally we're authenticating with saml
saml as a standard came out in 2005.
one of the things i get asked all the
time is wolf why isn't passwordless
taken all over it was standardized in
2020 i'm like well because things are
not ssl yet and that was standardized in
2025 or 2005.
it takes a while for these things to
take off all right next thing is it does
authentication and authorization right
does the
least trust and least privilege all that
in one it relies in xml
now
why well because xml is really cool in
the 2000s and we put xml everywhere
we have since learned our lesson in the
2010s and 2020s we no longer do that we
now think jason is very cool and we put
json
everywhere
if you like fast forward like 20 years
people like why the hell are they using
json and that's something modern it's
gonna be the same thing that was the
cool standard so we built xml now that
has some downstream problems which i'll
cover in a minute security is handled by
the browser that's a phenomenal idea
because i totally trust most browsers
and security on the warriors handled by
tls or mtls i do like that we should
encrypt all traffic everywhere uh one of
the fundamental principles about zero
trust and crypt traffic across all all
areas all right how does it work
and what do i mean by the front channel
so the front channel
uh is basically any data path that goes
right through the browser so if i've got
a user in a browser and i'm talking to a
client app and i've got a service
provider behind that and i've got an idp
anything that is interceptable on the
browser anything that's modifiable in
the browser that's all the front channel
and that of course is where most of your
danger is
these are really fun in ctfs
crack the sandal insertion
steal this job because it's in the
browser and you just go and you open up
dev tools and you download it
now what does the flow look like for
saml well
user agents going to go ahead and
connect to the service provider right
and let me open up that application and
i'm going to be redirected back to the
ssl hey log in first cool let's make
sure everything's fine
um the ssl is going to verify credits
and contacts of course again hopefully
that's pastor lewis and device trust and
everything else we've already talked
about um and then
with that i'm going to get a
redirect to the service provider hey
give me an assertion for this
application
that's going to be sent back here's the
assertion take it over there and then
the client is going to send it on to the
target resource that's the basic flow
pretty cool pretty easy
a couple problems with that first again
everything is xml everything is xml this
is a example insertion if you want to
play with this the easiest way to do it
is just to get
you know the sml plug-in for like chrome
or whatever your browser is of choice
and go ahead and look at that
you can see
that there is signing i don't know that
color comes through
so there's signing there's a signature
here essentially showing the screen so
the assertion itself is signed
and then the
auth statement and everything else below
it is signed
keep that in mind that's going to be
that's a fun tool for later that's going
to come back to haunt us
again xml string in the browser
which means again that all security is
hanging by the string
once we go ahead and log in
first thing to talk about is those
certificates
public private keys
generally
generally exchanged by x.509
certificates doesn't need to be
exchangebacks.509 certificates just a
convenient thing to do seems like a
great idea
if we've got a hold of those
certificates we can do code signing and
other issues
sure sure
also what's fun about those is
should we
do publicly signed certs so just a quick
question raise your hands who thinks we
should do publicly science hurts
who thinks we shouldn't
who's not going to answer because it's
the last talk of cyphercon
ah there's all the hands
sweet
there's my people all right so one of
the things we think about is maybe we
should do publicly signed why because
we've been beat up again and again and
again
do not do self-signed certs that is the
mark of the devil it is against
compliance standards the compliance gods
will smite you um if you are
a red teamer you will take advantage of
that to do man in the middle attacks all
sorts of problems with self-sensors
they're terrible however one of the
things to remember with self-signed
certs is we are reliant on that ca is
the trust anchor right so publicly send
is good because i can make sure that
it's signed by the public ca i can
validate the chain i can do all those
sort of things
saml doesn't have any of that
saml goes is it signed or not
that's it there's no validation back to
aca
so a little bit of a weakness there
also what that means is if you're
spending a whole bunch of time doing
public and privately signed certs
nowhere in the standard and arguably
nowhere near the applications is in that
being checked
but hey the cert people will love you
right your provider will be very happy
that you're buying lots of service
um should we expire those certs well
yeah probably a lot of people are
sending their search to 2038 as we all
know 2038 is the new 2000
that is the longest you can put a
certain out so just sign it for 2038 not
worry about it
obviously much like any credential any
secret the longer it lives the less we
should trust it so we probably should
rotate that on a regular basis at least
when people leave we may have had access
to that certificate
but how many people are doing that with
samuel like oh my t people just
were in the middle of the great
resignation okay
great
um where did they go oh they went
somewhere else okay um did they take
anything with us no absolutely not did
you check uh sure
how did you check with the lp okay
that's great does the dop check with
certs or creds
yeah uh yeah it totally does i'm sure it
does
right
right so we need a pad to go ahead and
do some rotation in there
and we also need to make sure of course
that uh
if the search signing doesn't pass
right what happens if i send a bad
assertion does it get discarded it
should be
um does the developers still accept it
anyways
we've seen that
oftentimes developers are really focused
on making things work which i love them
for that is great what that means is if
then try else right and the trials is
like okay well that didn't work so i
guess we're good because it's signed
what what so we want to make sure that
they're discarding them also in part of
discarding them we're wanting to make
sure that they
are actually keeping track when they're
asserting them or rather when they're
discarding them and hopefully forwarding
that on into a sim or something else
all right
back to
the
uh
back to the affected xml
all right
with xml
xml being a fantastic thing that it is
that signing is actually handled by a
parser xmld6 and this was a
vulnerability that was discovered a
couple years ago oh i don't see if i
have it down here
no i don't sound like i'll show you in
just a minute
so what's cool about xml is it's text
and again developers are great at making
sure things work so if that xml doesn't
work well that's a problem we'll try and
fix it parsers are always trying to fix
the problems so what xml dsig does is it
does the signature process and does that
signature process
after the comments so it strips out in
the comments and then we validate
against that makes sense right why would
i need to comment anything in my xml
i don't need to know that comment
probably not important we can discard
that
there is a vulnerability in samuel that
actually took advantage of that which
was pretty cool so what you would do is
you would authenticate with your evil
domain right like wolf at victim.com
that's some org attacker right so i got
my attacker and i've got my insertion
and i've authenticated it now once i get
to the search and i'd modify that and
actually comment out the some attacker
org so now i've got
wolff at victim.com and i pass that
assertion back in and the other reads it
and validates that because okay
well there's a comment here so i guess
we'll discard that
and suddenly
some attacker dot com becomes victim.com
why because it's xml based because
that's how xml parsers work that's what
they're designed to do they're designed
to be very simple with text manipulation
so we want to make sure that we are
aware
of all the different ways assigning can
fail
another interesting thing about that is
what happens if the assertions
signing
and the main signing cert
doesn't match but if the assertion
signing is good but the the
actual
response setting is bad or vice versa
in different fault paths they'll handle
that differently there was a attack
against shibboleth where if the
assertion
response was good but the actual
uh signing itself the right the top
signing was good the bottom signing was
not what it would do would be like oh
that's weird
but you passed one pass you're in and
then people could log in with that so
they were obviously modifying those
assertions with valid responses multiple
different fault paths can happen when
we've got multiple different signatures
to maintain especially with these xf
online certificates
and again that's assuming that we're
doing good cert values
which gets to the golden sample attack
which is like my favorite of all the tax
and i'll cover that really quickly but
golden salmon attack i think it was
cyber arc who discovered this um as a
attack vector and then of course it was
used in the
um solarwinds attack basically very cool
certain ssl
sites
maybe like the ones
by companies that start with the letter
m
allow you to export those certs and
don't really have good controls of those
okay that
that probably shouldn't happen but no
one's going to do that unless of course
you have admin credentials and once you
export it and have this cert what can
you do again it's just an xml file so
you can just keep printing your own
assertions and signing them and logging
into everything so golden samuel ticket
is effectively getting a hold of adfs's
uh cert and then signing all your
assertions and having full access to
anything that trusts
any sample
i like that it's good it's fun
so basically
certain mansion kind of important
um that is
saml very very briefly there are some
links if you want to take a look at that
but that really set the ground for what
we faced
with oauth and oidc right there's lots
of different mistakes in the saml
protocol that we learned from trusting
the front channel being one of them
not having good uh signing mechanisms
for the response and insertions
not having checks by the idp not
rotating keys
and any problems with any compromised
xml libraries all those things stripped
us up
so with that with those mistakes rick
hey cool
let's do it again
and so we started with oauth 2.0 so all
2.0 published in 2012
several years after sam all
authorization framework only so
originally owath was like cool
twitter is fun
uh no one would ever want to buy it and
also we're gonna let people make their
own apps on twitter and so we want to
authorize people to send tweets in our
behalf and everything
very common use case or i want to be
able to log in from this that very
common use case i use if then then oh if
this than that and i want to schedule
tweets or schedule messages so i want to
authorize that out very common use case
the browser's security is sometimes
handled in the browser in the front
channel we'll talk about those use cases
oftentimes not and security is on the
wire again
we're looking at can the identity be
trusted and what can the identity be
doing and this is completely on the
authorization side
oh and
once we're in
we'll talk about identity tokens next
but once we're in what's being exchanged
is an access token
so open id connect comes out next right
because we were like oh this is great
i'm going to use this for authentication
and like but it wasn't designed for
authentication but that doesn't matter
i'm going to use it looks great but you
probably shouldn't but i'm going to and
then people would do it and there'd be
all sorts of problems i saw a talk on
at gerk con i think it was
2012 or 13 which is just great he's like
here are 16 different ways that my team
completely owned your oauth
roll your own authentication product and
that is
painfully awesome
so we came up with open id connect you
guys remember openid connect the old
version this was odc 2 2 was built on
top of
oauth and was meant to really handle the
authentication side and really this
whole goal is to exchange identity
tokens with flows i'm going to work
through those flows in just a minute
it's very similar to saml in that we're
going to have a series of steps to go
ahead and get a token and then we're
going to use that string we're going to
use that token to authenticate and we're
never going to go back and check
everything again because clearly
everything is just fine once you log in
all right
identity tokens are
used for authentication issued by a
secured token service
they are generally jots i'll show you
what that looks like in a minute access
tokens are used by
oauth to do access requests are
generally consumed by an api
and hopefully hopefully those are not
living to 2038 hopefully there's some
sort of pattern where we're expiring
them in a reasonable period of time so
we've got refresh tokens to go ahead and
get new identity and access tokens
there's also you know reference tokens
and stateless tokens if you're used to
the old school like you're going to put
a cookie on right
that's a reference token i got a token
i'm going to go back and hold all your
state in the back end stateless tokens
i'm going to hold all the state in the
front end on that token
why well because we want to scale and
we're doing everything with ephemeral
architecture
so all this dumps back into jots or json
web tokens
looks something like this base64 encoded
string again it's json because that's
exciting
the top header includes what the
algorithm is how it's signed
and then the payload includes a whole
bunch of assertions about who i am and
what i'm doing and what roles i should
have in the system
what's kind of cool is hey if i want to
be admin i can just you know it's a
string i just modify it
turn just clear text why not
so we need some sort of signing
mechanism to make sure that we're not
just adding roles
or modifying it as an adversary so it
supports a couple different algorithms
it supports hmac and rsa obviously
rsa or ecdsa should be the one you use
because it's public private key pair as
opposed to hmac which is symmetric
also supports none
why
why not
yolo
so
what uh what can we do here well we can
rewrite
and invalidate the signature that's
usually what we're doing we're testing
these things out that seems good well
but wolf it's now an invalid signature
yes he also my point earlier about
developers almost never catching that
here's another one maybe they're good
they're like hey i'm going to make sure
that that token passes signature
good idea so i'm going to rewrite i'm
going to set the algorithm to none like
oh it must be none okay well
you pass
sweet i'm now administrator
or if it is
a hmac you can
rewrite it and rewrite the signature
that's also fun so there's a few
different ways you can mess with us
so what do we need to do one thing we
need to do is make sure that your
developers whenever they're using jots
whenever they're using this pattern are
using public private key pairs uh again
protecting those public private
preparers with everything i said about
xaml
and that they are looking for
uh job signing and they're discarding
the assess tokens
one of the the mistakes with this is
again if you've done a pen test or
you've done a ctf
you can just do this again and again and
again and i love that i think that's
very nice as a seesaw perspective i
really want to fail 40 times and no one
notice
that is glorious
and the 41st time i find a way in
okay no one knows
clearly wolf's just has problems with
tokens yeah that's that's it that's
exactly
why why doesn't that get flagged why is
not that get alert i do not understand
that part
there's this concept of circuit breaker
pattern which i really like which is
over a certain threshold you should take
some action
one of the first times i thought saw
this
was uh we were
i was doing the blue team side of this a
colleague of mine was doing the red team
inside this and we set up all the
security for the organization we're like
all right now you're gonna come and do
your pen test and like ha we're
compliant we will we will not be broken
and this poor pen tester kept coming in
and he would just bang his head bang his
head bang his head he was trying
everything i mean this is great we are
the best ever like yeah like that must
be all the governance i provided you
like
yeah we'll go with that wolf like no no
that's that's all the controls we talked
about right like no no
what was it they had set up nginx where
if you went past a certain number of
five hundreds
and four oh four so page not found
server error you exceeded that threshold
it would block your ip address for 15
minutes
and that number kept getting higher it
started out 15 minutes so it's just
enough time if you're a user to go huh i
wonder why that happened to go get some
coffee and wander away and come back and
use the website it's also just enough
time if you're using sql map and
crawling a website
to hit those thresholds and then break
and then he's out of the game for 15
minutes trying to figure out what went
wrong
awesome awesome pattern to really
frustrate adversaries awesome pattern
two if you're thinking about a bot to
get that bot to move on to the next ip
address and move away so i love circuit
breaker patterns here
one additional thing i didn't mention
was claims giving away too much info
once you start looking at jobs
i don't think this is one is it this is
just my mpdrs okay
once you start looking at jots you can
find out all sorts of information like
oh you're using that provider oh you're
using that company oh this is how you
define my role right it's fantastic if
you want to do any sort of uh intel as
an adversary you can get all sorts of
stuff out of this why because stateless
tokens which means your developers are
cramming all sorts of stuff in this
which probably shouldn't be there you
probably don't want your adversaries
knowing what you're running or your
users to know what roles you're putting
them in
so
what else what else can we do about this
um oh flows we should talk about flows
so we're going to talk about logging in
getting an oitc credential and getting
an oauth access token
to do that we're going to be using a
basic flow pattern so i'm going to
go out i got my browser i've got a
client i've got a ticket service or sts
that's handling all our tokens
then i got the resource server that i
want to reach to
so let's say that i wanted to allow zoom
to see my facebook i don't know why i
want to log in
all the time through facebook so people
can track me because that's just what i
do it sounds fun um so i'm going to say
yes go ahead and do that and then i'm
going to get a pushback from it going
hey wait a minute who are you go ahead
and log in i'm going to be prompted to
log in through facebook and i'm going to
get this prompt which i'll show you in
just a minute and i'll get a redirect
that says okay now that you're logged in
take that
back to the resource
get my token and send that token into
the api and then i can go ahead and do
the thing
this effectively is called an
authorization code grant because what
we're exchanging is authorization code
to go ahead and perform these steps
it's authorization code
i should mention there's a thing called
the implicit flow which is basically
that but all through the front channel
and is terrible it's one of my if you
want to let go on the burp suite where
they got like some of the ctf challenges
it's one of the ones on there and uh is
breaking the implicit flow so again 2020
right we all didn't have much time
or had too much time we're in our uh
home labs i'm doing these labs and i
break it and i take over a blog like
yeah
i walk in my office oh yeah i'm like i'm
a hacker in my house again
that's nice what'd you do like i broke
the implicit flow it's like
following a cookbook which everyone else
could do like yes
yes i did
because it's that easy and if i can do
it it's terrible so
the reason i tell you that entire thing
is
make sure you inventory your flows
and make sure that your enterprise
developers are actually
not using implicit flows or using the
authorization code grant or co-grant
with
make sure they know they have flows and
that they know what there's
they have if you're like hey
do what flows are you using and they
give you a blank look
we know that we've started down a path
and you can be you know wolf could
probably break in and they'll just cry
they'll just cry at that point
so
start off with that right make sure
we're not trusting the front channels we
know
and make sure we've got good inventory
of those flows
now i want to talk a little bit about um
what happens in that flow with the
authorizations because i think there's
something very interesting in that and
i'm sort of like pointing the way to
where i'm going to hit the baseball when
it comes to fishing if you were in my
earlier talk you probably heard me say
that 502 has solved fishing forever
and say that but what i said was what's
interesting about 502 is
you can prevent a url from getting a
credential because the protocol itself
uses that url before it exchanges
the shared secret and therefore the old
tricks about oh i'm going to send in a
weird url that maybe you'll click on and
maybe you'll think you know zoom with
three letters is what it is those old
tricks don't work anymore it's a really
cool way to stop that level of fishing
so just remember that fishing is now
solved let's go back to our wathoid you
see so i go ahead and i've got
this request to say hey i want to zoom
to see my facebook and i'm going to get
a prompt back now this prompt
looks like this this is called the
authorization interface there are many
authorization interfaces this is
facebook's how yours looks may vary
there's customization everything you can
do there they identify the service which
you can see there
is zoom and they identify the user okay
it's me
and they
specify the scope that we're trying to
access in this case i think it's just my
profile and picture email address i'll
touch on the scope in just a minute now
any people use zoom recently right we
all use zoom pretty frequently does that
look like the zoom logo to you
i want to know when they set up this
authorization interface because that is
an old logo
but it also made me realize
how hard is it to find the new logo
also
how hard is it to create a application
that maybe looks like zoom but isn't
all these are like quintessential
fishing techniques 101 incredibly easy
to do incredibly easy to replicate to
given someone that they're clicking on
something it's those old tricks right to
confuse users to authenticate
um and authorize so you may go okay
that's that's cool that sounds fun in
theory but it is the only theory there
was a google docs attack which of course
wasn't google docs but you get an email
and says oh
you've got an email to google.com once
you've got google we'll click on the
link okay i click on the link this takes
you through that flow and says ah gmail
needs to see google docs and google
analytics to see gmail so you need to
authorize me like well it certainly
looks like google
i will authorize that
and then what happened behind the scenes
is once you authorize that that was a
malicious endpoint which would then read
your email and send out a bunch of
emails saying oh by the way you got a
google doc from your friend wolf
very
very annoying very quickly caught
very easily stopped
but it's that type of pattern i'm
telling you is going to happen with
these interfaces as we get better at
stopping fishing upstream
all right
so
let's talk about
what else can go wrong here if the
resource owner is suspicious or if the
adversary is in the browser
and i'm going ahead and saying hey give
me my url
and doing my authentication and getting
the authorized authentication
authorization code back because i'm
trying to get authorization code right
i'm going to get something that looks
like this
the first thing i want to talk about is
the scope so i mentioned earlier that um
the zoom one was scoped for for email
and profile
when you scope oh i just see that's
really yet always pretty well defined
you can do a profile email address you
can do phone
if you really want to give out your
phone and encourage everyone to spam you
you can collect all this information and
authorize it and also the authorization
interface is meant to be iterative so
they can ask for it multiple times but
there's really little control or
customization over oac scopes
on the other hand with oauth scopes
it is the wild west you can do any sort
of scope you want now
arguably as we all know from like a
least privileged perspective we should
be doing something like you know
crud based or some very specific
authorization and there's some really
great apis out there like i really like
slacks how slack has defined their apis
and what that means is if i compromise
like um
admin
barriers read if i compromise
that token i can't use it for write i
can't use it for apps and so on so forth
so it's very nicely cut and scoped so
that if the blast radius of any stolen
jot is actually limited to a specific
scope and limited to a specific set of
apis
really really cool
as you might imagine oftentimes when i'm
being
asked to give architectural advice
that's not the case
the developer's like we've got our scope
that's great what's your scope acme co
acme coat your entire company yes
because it's great because then we have
one job for everything
that's great yeah single sign-on hurts
fantastic
i don't think that's single cent no it
really is everything can get everywhere
yes
that i believe that last
part i believe
so make sure your enterprise folks in
addition to
uh inventorying flows are creating
well-defined scopes another thing i want
to touch on is this redirect
the redirect itself
uh is
ostensibly pointing to the uri which
should get that token right this is the
end point of where that token is going
if it is tampered with or if it is
changed it will send the
token to wherever that redirect says
so to fix that what you want to do is
make sure that your sts is enforcing
callback urls or specific urls you're
enforcing specific origins you're
forcing which means your developers have
to limit those apis to specific urls in
specific locations
so there's some definite work to do
there
also kind of cool about that
um
you know when we think about cores and
urls
um is
is
like the golden oldies are back right
like open redirects and unrestricted
file loads just became a thing again
which is so exciting to me it's like
1990s hacking and you may think well the
10 textbook that's right but some of the
bug bounties out of facebook this is
exactly what happened the bug bonus on
facebook they figure out a way to upload
a file to facebook and then figure out a
way to use an a redirect uri to get to
that uh facebook page or the facebook
content that was uploaded and then they
get people to click on that link and
that person will click on that link and
it'll take your facebook token and send
it right on to that content that was
uploaded and then the person that the
content uploaded could go ahead and take
that lincoln login as you
so
definitely kind of cool because it's old
school hacking but definitely kind of
problematic so we should be putting in
restrictions thankfully scs and the
whole standard will support this again
if your developers are looking for it
all right
next one one more classic you know cross
site request forgery is back so at the
bottom of this we've got the state code
right so the way to prevent
cross site request forger i like i like
saying that i'm going to get a little
slap every other the way to prevent that
is to have a unique state such that we
can verify from beginning to end that
the request for this token is what we
are uh that the token is being provided
for valid requests and the bell request
is asking for a token that's the
anti-sea surf mechanism and the
authorization code flow
so what could go wrong with this
um
well it's
optional so that's a problem
much like not signing it doesn't have to
be there and sometimes it's missing
that's problematic it's also guessable
so this is one of the things i find
really interesting when i was doing some
of this early research i was reaching
out to all my writing friends like tell
me the craziest thing that you've ever
seen and one guy's like you wouldn't
believe it i looked at it and i'm like
that statement looks like md5
and i looked at the clock and i realized
that state looks like the
the md5 hash of the time stamp and then
i crafted a request with a couple
seconds earlier and i stole tokens and
the first time i heard that like that is
really clever
the fifth time i heard that from
different red teams
i went there is a book somewhere that's
teaching
like 101 here's how to roll your own
oauth that says a good way to create
state is doing md5 of a time stamp
and there's got to be because so many
people are making this mistake i don't
get it
all right uh it could be unvalidated it
doesn't have to be checked again a lot
of you i'm sure you're seeing the count
of theme here and even we get all this
right there's still a way to do a
partial
request where i start a request but i
don't finish it and therefore i've got
a valid authorization code if i can
intercept your authorization and use my
valid code i can go ahead and get the
token
which is why there's this thing called
pixie so proof key for code exchange
which does everything we just said but
ins at the this step
the client issues a code challenge and a
code verifier and the code verifier is a
random string the code challenge is a
hashed value so we're hashing that
random string
and then goes through the whole process
and passes that code challenge on to the
authorization service so the sts
finishes it and at the very end it sends
back the code verifier so we're able to
verify from the client to the
authorization service back and forth
that it truly is
one communication hasn't been
intercepted hasn't been modified
pretty cool technique just add some a
couple steps to the url
um really good anti-sea surf mechanism
especially if you're using like shot 256
for that that hash again gets the code
verify at the end
the whole point of that is make sure
your developers are preferably using
their authorization code flows
with pixi to minimize that type of
threat vector uh again it's out there
it's been out there for a long time it's
a check box
uh if they have an inventory and they
got other problems they may not realize
that
all right other mistakes
with jots
so we talked about not using state
guessable state we talked about not
checking state we talked about not using
pixie another thing i want to talk about
is
the time side of things
so when we go ahead and
request these tokens
and we're doing the thing how long does
that token live for
again hopefully it's not forever i call
this like the twinkie design pattern
where you just set it for the longest
number possible and you hope it never
expires
just everything's fine just give it a
twinkie one of the things that's
incredibly important to remember is you
know security is a basically about space
and time
right time is a security property space
is a security property we want the
adversary as far out from you as
possible and we want the adversary to
have as little time on target as
possible the trade-off for that is that
the time period is too short then of
course we can run into additional
overhead of constantly getting tickets
and everything else but we want to have
as much um
as much control of the time value so
that the adversary is as little as time
as possible
so when we're going ahead and having
that token eventually it should air out
that's a setting
and when it happens we'll send a client
id and refresh token and get one back
and then now with the new access token
keep doing things which is cool right
everything's cool that's great we've we
now have a way of refreshing and getting
new tokens we've got a way to make sure
that no one's doing anything
however
cross-set scripting
what happens if the adversary is able to
within the browser
get that token steal it and reuse it
through a cross-set scripting attack
so
we don't want to allow them to steal and
use a long live token easy we'll stop
that we also want to make sure that they
don't steal a refresh token and use that
to renew an access token the way to do
that is to make sure that our sts
is going to invalidate the entire
refresh chain on detecting that so if i
do a cross-site scripting to you and i
got your refresh token oh yeah both of
you guys so still both tokens i got two
of them
and uh and
i use that now to get your access token
eventually let's say it's 10 minutes
let's say i do it in minute two
uh eight minutes later your guys's
tokens are going to expire and you're
going to go out and get new ones
now the sts should track that go wait a
minute
why are they asking me for new ones i
just gave wolf their tokens that's odd
and at that point in time which goes
back to to having a short time on target
at that point in time you should be
logged out you should be logged out and
i should be logged out and that should
minimize how long an adversary can use
any of those tokens so everything in
that refresh token chain has to be
logged out
also again circuit pattern if someone is
doing that again and again and again and
again
we should detect that block that the ipa
layer alert that send it to the sock
send it in
what else with tokens so i talked about
the twinkie pattern i talked about now
bouncing them
um
yeah so i think we're just about done
here my main point about looking at this
like i said in the beginning is all
controls do is they make for better
criminals we've got a ton of things on
the front end which is great we've got
principalities trust we've got the
principalities privilege we've got
controls on that side but at the same
time adversaries continue to attack that
side because the reality is there's so
many holes in all those things
eventually we're going to get to this
great point in time
where
we can trust all that
and when it happens
what we'll be relying on what all
security would come down to is a string
either a saml xml string
or a json string
it'll all come down to a string
so that's why i think it's incredibly
important we start thinking about these
things
before we get attacked by the jokers and
start thinking about how we can move
around this do you want to screenshot
that sorry about that
i'm clicking like a madman
so what can we do in a process level
will train developers on securing saml
oauth the way to see
we already trained developers on
everything under the sun so i know that
may not move the needle much but we
definitely need to give them good
training and good patterns
to follow
that pattern side too is really
important i was
when i was a security officer
i had this application and we had pen
testers come in and pinterest would test
the application like how
we broke your authentication
good
send it to my developers they would fix
it and while later on i bring the pen
tester back and he tests a different
application
i broke your authentication
sent to the developer said fix it
while later
i got in my head after going about this
like five six times i should put that
code on screen and bring my developers
in so i had to code on screen and i was
ready to yell at them and my developers
came in they're like oh that's cool like
yeah you recognize it like i absolutely
recognize that i was thinking myself you
should because i've just given you six
different pen test reports
saying what's going on like where do you
recognize that from
all hostile i was
not enough coffee
and they're like oh that's a wiki and
like
it's on your wiki
like yeah yeah that's that's our like
template for starting new apps
wait show me and what they were doing
was their template for starting new apps
was vulnerable code that they would put
in place
and build an application and wait till i
did a pen test and then give a finding
and then they fix it
again and again and again we simply
changed the wiki page and we no longer
had that finding
so cool
so again i would tell you guys
somewhere out there
is a page
or a book
or a reddit finding or a reddit post
that says if you want a state value take
an md5 of your timestamp
we need to find that
and we need to end that so training
developers sounds great better give them
tools so that they've got repeatable
patterns
make sure we got good requirements on
this a lot of times we don't uh make
sure our design is taking into account
this from a threat modeling perspective
uh make sure verification including
often and off z on our pen testing
oftentimes i feel like we're not right
testing that side why do you why would
we i fish them and give me passwords i
mean
why do i need to go any further no let's
pretend you didn't get the passwords
what would you do then
from an architectural level
commercial sso and sts addresses a lot
of these default settings
you know normal advice supplies do not
roll your own
s-bom i think is really important if you
guys haven't looked at s-bomb use that
to select sds and identify any
vulnerabilities uh monitor a report on
abnormal behavior if this is happening
again and again and again and again and
again
find it
stop it
put in place the circuit breaker pattern
that is incredibly important because
otherwise we just have open season for
our adversaries and fantastic to beat it
up
all right
that is it from me
here's a qr code for the brave uh i've
got a couple minutes for questions if
anyone has anything
once going twice
[Music]
all right thank you so much
[Applause]
okay
right here
[Music]
you