#NahamCon2024: OAuth Secret | @BugBountyReportsExplained

June 11, 2024, 9:52 p.m. - by quas

TRANSCRIPT:

0:04
hello and welcome to my presentation
0:06
called all secrets thank you Ben so much
0:09
for letting me speak at hamon also I'm
0:12
sending regards to our hosts and let's
0:14
get on with the presentation it's called
0:16
all secrets and I think every back
0:18
boundy Hunter should be familiar with
0:20
the off protocol because of how many
0:22
misconfigurations are there and because
0:25
they lead to ACC cover and it's just not
0:30
wise to not be familiar with it my name
0:33
is Gregor Nel I go by the nickname Greg
0:36
xande i'm the author of back Bounty
0:38
reers explained brand and I'm also a
0:40
back Bounty Hunter myself let's start
0:44
with all Basics usually it starts with
0:48
the user clicking login with Gmail
0:50
button login with Facebook button
0:52
connect account whatever and what what
0:55
happens under the hood is the website
0:58
we're testing sends the request or the
1:01
browser sends a request to the website
1:03
we're testing which redirects the user
1:06
to the authorization server there are
1:08
very interesting parameters here but
1:10
pretty much the whole presentation is
1:12
about how we can exploit these
1:14
parameters so for now I will just ignore
1:17
them then the second request is to the
1:19
authorization server often it will be
1:22
some big known website like G Gmail or
1:25
or Facebook but it can also be like an
1:28
internal authoriz ation server for
1:31
example you're testing app.com but when
1:34
you're logging in it's actually identity
1:37
appom login appc account appc whatever
1:40
like this and from users perspective it
1:44
looks normally just like the login and
1:46
password flow but very often under the
1:48
hood it actually uses off as well and it
1:51
can be equally vulnerable and the impact
1:54
is is still an accounting cover so do
1:56
not only think about the authorization
1:58
server as the big
2:02
websites then very likely the the actual
2:06
flow will contain a few requests on the
2:09
right hand side here like the user will
2:11
have to either choose the account or
2:13
click authoriz authorize button or
2:16
simply log in if they are logged out but
2:19
what we care about is after this
2:21
flow the user will be redirected back to
2:26
the website we're testing with the very
2:28
important parameter
2:30
code which is a one-time Ed
2:34
parameter which in The Next Step can be
2:38
exchange for the session cookie or
2:41
whatever mechanism the target uses for
2:43
authentication of the user what happens
2:45
in the back end the website we testing
2:48
sends the request to the authorization
2:50
server with the code to know what was
2:53
the user that was logging in and stuff
2:55
like this but from our perspective
2:57
what's important is that this code is
3:00
one time use and it allows us to
3:04
exchange the code for the session cookie
3:07
and in most cases if we can link the
3:09
code we can take over the account
3:11
sometimes there are additional
3:13
protections but usually that's the case
3:16
and that's how this process looks on on
3:18
one slide and as I've said likely if
3:22
that that's the real Target there will
3:24
be more requests but it still comes down
3:28
to this free so one request that
3:31
redirects the user to the authorization
3:33
server then the redirect back to the
3:36
tested website and then exchanging the
3:38
code for the session cookie these are
3:40
sort of free requests that we will
3:42
operate on and the first parameter I'd
3:45
like to cover is the state and let's
3:47
consider this attack scenario as
3:50
attackers we start the login flow in our
3:53
browser with our
3:54
account and then we are redirected back
3:58
to the website we're testing with the
4:00
code parameter but we prevent our
4:02
browser from consuming the code and
4:04
instead we send this code this URL to
4:07
the victim and then victim's browser
4:11
sends the request to the target with the
4:13
code and they are logged in into our
4:17
account so we have like an login
4:20
csrf and you may say login csrf it's not
4:23
a great back it's not a great back it's
4:25
often out of scope of back boundy
4:27
programs and you would be right but
4:30
it is a low or medium if you can just
4:33
log to victim to your account it is not
4:35
a great B but it's not only the the oath
4:38
protocol is not only for logging in it
4:41
can also be used for for example adding
4:44
Integrations imagine you have the the
4:46
Medical website which you can integrate
4:49
with Google Calendar and then your
4:51
medical appointments are automatically
4:54
sensed to your Google calendar if you
4:57
could have the login csrf
5:00
with integration with Google Calendar
5:02
and you can login the victim account to
5:05
your Google calendar and all of a sudden
5:08
you see victim's medical appointments in
5:10
your calendar that's that's a serious bu
5:14
also sometimes you can connect accounts
5:16
so if the victim normally logs in with
5:19
login and password and they are
5:21
currently logged into the website but
5:24
you will all CSF them to your Gmail
5:27
account then those accounts get merged
5:30
and all of a sudden you can log into
5:32
victim's account with your Gmail and in
5:35
this case it's also not uh not a low
5:37
inde definitely a serious bugs so the
5:40
first attack that we have is the login
5:44
csrf and
5:46
the prevention for this is the state
5:49
parameter which can be set in the first
5:51
step it can be a cookie or a local
5:54
storage or whatever then authorization
5:57
server also gets the state but it
5:58
usually just forwards it back to the
6:02
redirect URI to the call back URI and
6:04
then in this step the authorization
6:06
server will check if the state sent here
6:09
in the third step is the same as state
6:12
that was set in the first step and if we
6:15
try to do the attack as we did before we
6:18
just we we would just send to the victim
6:20
this request the second request of the
6:23
flow so we could not predict the state
6:26
so this attack will not work the good
6:29
thing is that the state is not a
6:32
required parameter and many flows just
6:34
do not use it uh which makes the Lan
6:37
csrf possible and the bigger question is
6:41
if if we actually have a serious
6:45
impact let's now continue to the
6:48
parameter which is pretty much the key
6:51
for most of attacks the redirect URI CU
6:55
in the second request to the
6:57
authorization server there is the red
6:59
direct URI parameter which contains the
7:03
URL to which the authorization server
7:06
redirects the user with the code and in
7:10
the early days of of all you could just
7:12
do something like this just use the
7:14
attacker server here and the victim
7:17
would be redirected uh to the attacker
7:20
server and the attacker would just have
7:22
the code and as you already know the
7:24
attacker usually can exchange the code
7:27
for the session token and can just just
7:29
take over the victim's account this
7:32
unfortunately will probably not work in
7:35
in today's web usually the redirect URI
7:39
is validated against a white list and
7:42
you have to do something more very
7:44
likely you have to Simply find an open
7:48
uh redirector or something like this
7:50
that that will allow you to leak the
7:52
code and I'll speak a lot about open
7:54
redirect during this talk and on most my
7:57
slides there will be the most basic um
8:00
like open redirect payload but here are
8:03
just a few payloads that I think will
8:07
work in the majority of open redirect
8:10
this is like Paro 2080 principle of open
8:13
redirect payloads the first one the
8:16
simplest is just concatenating the
8:18
Target website to attacker website it
8:20
will work with the most basic validation
8:23
of uh starts with of or index of then
8:26
you have the fake relative payloads
8:28
where the website thinks that any URL
8:32
that starts with a slash is a relative
8:34
URL so the open redirect can't happen
8:38
but when there are two slashes it's not
8:39
a relative relative URL it's an absolute
8:42
URL so it also
8:44
works in many cases then we have
8:48
different characters before the Ed sign
8:51
and so if you're not familiar if you
8:52
have the Ed sign in the URL what if
8:56
there's no back backslash here this
8:58
would be the house and this would be the
9:00
user but this The Backs slash here
9:03
confuses a lot of pares it comes down
9:06
also to the difference between the w web
9:08
URL standard and the RFC but let's not
9:11
get get into this now but this payload
9:13
is very very useful and works often uh
9:17
recently I've heard about this payload
9:18
working with the question mark before
9:20
the Ed sign I think it's worth to just
9:23
Brute Force anything before the Edwine
9:25
all the special characters because it is
9:29
clear really problematic for different
9:31
passers and another uh payload that that
9:34
works sometimes is the new line payload
9:38
so these two that's encoded uh new line
9:42
sequence and it works if the host is
9:45
checked against a regular expression
9:47
which has the multi-line plugin so it
9:50
will match the next line of the URL even
9:54
though the actual host is is here uh and
9:57
I think these these payloads will cover
10:00
most of open redirect
10:03
scenarios so we know how to exploit the
10:06
most basic redirect URI open redirect
10:08
but to be
10:10
honest you you'll probably not find it
10:13
very easily in these days more likely
10:16
you have to do something like this so
10:19
here we have the redirect URI that is
10:22
checked um but it's only checked that
10:24
it's on the correct host and and the
10:26
protocol but you can control the path
10:29
and parameters this is
10:31
not compliant with the RFC but it is
10:34
often the case and what can you what you
10:37
can do then is you can send the victim
10:40
to a URL like this and then the
10:44
authorization server will see okay the
10:46
redirect is to the trusted website it is
10:49
to the website that that was authorized
10:52
so it shouldn't be a problem but then
10:54
the the tested website you know sees
10:57
this this address and because there is a
11:00
re open redirect here instead of
11:03
consuming the code this endine just
11:05
redirects the user so it redirects the
11:08
user to the attacker's website then
11:10
attacker gets the code and as you
11:12
already know it leads to an account
11:14
takeover what's important is this
11:17
redirect has to preserve parameters
11:20
which is not always the case but we'll
11:23
deal with this problem later so we have
11:26
three attacks already uh we can all also
11:29
exploit the open redirect if uh we can
11:33
manipulate the path of the redirect URI
11:36
and uh if the redirect preserves
11:39
parameters we'll get back to the
11:42
redirect URI later but now let's take
11:44
look at another parameter which is often
11:47
overlooked because it's not seen in in
11:51
many flows
11:53
because the prompt parameter will often
11:56
not be present in this URL but it will
11:59
default to to a value of consent which
12:03
means the user even if they are logged
12:05
in will be shown the this screen right
12:09
here and then they have to click a
12:10
button to for the outflow to continue
12:14
another value possible value of this
12:16
attribute is select account uh if you
12:19
log in with Gmail sometime some
12:21
sometimes you know you have to choose
12:23
the account to which you want to log in
12:25
it can also have the value of login
12:27
prompt login and then the user has has
12:30
to input their username and password and
12:33
this is really bad for for our attack
12:35
cuz it's pretty much as the fishing if
12:37
we need the victim to to fill in the
12:39
username and password but if you use the
12:42
value of prompt none then if the victim
12:45
is logged in already there there will be
12:48
no prompt the victim will be redirected
12:50
straight back to the website we're
12:53
testing which of course minimizes the
12:55
redirection and increases the the risk
12:59
of the attack increases the likelihood
13:02
of the attack sometimes there are
13:04
additional protections uh but there are
13:06
ways to still get through them so now we
13:11
don't add a new attack to our list but
13:14
we know that for all the redirect URI
13:17
related attacks we added a prompt none
13:20
to minimize the user
13:23
interaction the next parameter which uh
13:26
which is can be used to change with
13:29
other attacks is the response mode on
13:32
all the slides so far I use the response
13:34
mode query it is the default value as
13:37
well so it can also be absent in the URL
13:40
but it's the default value will be query
13:43
and it means that the code in the
13:45
redirect URI is present in the in the
13:49
query after the question mark in the URL
13:52
as well as other
13:53
parameters another possible value for
13:55
the response mode is
13:57
fragment and then the read directory is
13:59
very similar but the difference is that
14:02
now the code and the state are in the
14:05
fragment and it may seem like a very
14:07
small difference but it actually very
14:09
very significant
14:11
because the call back end point to which
14:14
you redirected expects the code to be in
14:17
the query so if you send it it frag in
14:20
fragment it likely will just not consume
14:22
it and we've seen it exploited for
14:25
example in Reddit where France Rosen
14:27
would change this parameter
14:29
and then the code would be just present
14:31
in the URL unconsumed which is very
14:34
important and then you need another back
14:37
to leak the URL which is not easy to get
14:41
but here it was really great back with
14:44
um with I I think Google analytics xss
14:47
we also have seen a similar attack on
14:49
Facebook with uh exploiting the sandbox
14:52
URL which had access to the
14:54
URL uh so in
14:57
general if you can somehow how make the
15:00
code be unconsumed and be present in the
15:03
URL which to be honest most of providers
15:07
will allow this to happen if you then
15:09
train with a vulnerability that Leakes
15:12
the URL you can take over the account so
15:16
this is the the next attack that we we
15:19
get we we add to the list unfortunately
15:22
leaking the URL is usually the the more
15:25
difficult
15:27
part and also we can use the fragment to
15:31
uh to the attack I I've shown before
15:34
I've said then that in the redirect U
15:36
here in the middle we need the this
15:39
redirect to preserve parameters which
15:42
will not always be the case but if you
15:44
change the fragment the response mode to
15:47
fragment the victim's code will be
15:49
present in the in the fragment here so
15:53
it will not even be present in this
15:55
redirect but it will still stay in the
15:57
browser the brow the the browser will
16:00
not drop the fragment even if it's a a
16:02
cross domain redirect so then you can Le
16:06
the code the same way as before just the
16:09
difference is that we no longer need
16:11
this redirect to be parameter preserving
16:14
we can just exploit it uh even even
16:17
without it exploiting the fact that the
16:20
browser will preserve the fragment
16:23
during the
16:24
redirect there's also a value of uh
16:27
Forum post of the response mode and the
16:30
difference then is that instead of the
16:32
redirect the response contains a a post
16:36
which sends the it's actually very
16:38
similar request just is the post not the
16:41
get and from from the users perspective
16:44
there's also JS that automatically
16:45
submits this this form so it's not like
16:48
the user has to click
16:50
something and it is generally not useful
16:53
for leaking the code because it's very
16:55
unlikely we will have a way to leak the
16:57
body of the post request
16:59
but I've used it recently because I had
17:01
the accs on the authorization server it
17:04
was like the internal authorization
17:07
server and I wanted to show the impact I
17:10
wanted to take over victim's account but
17:13
so what I did was I wrote this this fet
17:16
request to initiate the authentication
17:18
flow or maybe not initiate it's the
17:21
second request of the authentication
17:22
flow but the code was only present in
17:25
the location header which I could not
17:28
read this this code here it does not
17:31
work so what I've done was I changed the
17:34
response mode to form post and then I
17:38
because I could read the response body I
17:40
could also read the code from the body
17:43
and I could leak the code this way so uh
17:47
it's also a way to to show the clear
17:51
impact of an xss on the authorization
17:53
server there's also a value of web
17:56
message for the response modes and then
17:59
it sends a post message to to the opener
18:02
it can be used for the silent
18:04
authentication without opening new tabs
18:06
and it sounds really sketchy and I uh I
18:09
I want to test it but most targets I've
18:11
tested either do not support it or I
18:14
didn't find a way to to exploit it but
18:16
it definitely sounds like something that
18:19
that has bugs in it and it gets really
18:22
fun fun really fun when you start to
18:25
chain these things together on another
18:27
Target I had the open redirect but only
18:31
in the post
18:32
authentication state so the redirect
18:35
would only happen after successful
18:37
authentication and it was actually the
18:40
the post authentication redirect was
18:43
present in the state parameter generally
18:45
any data in state parameter uh is the
18:48
indicator that we should look further
18:50
into into this so I was like even if I
18:56
redirect the victim after the
18:57
authentication flow the code has already
19:00
already been used so it's useless to me
19:02
so what I did was I changed the response
19:05
mode to fragment and in the redirect URI
19:09
I embedded my code from my web from from
19:12
my account to the Target website so the
19:16
authorization server would redirect the
19:19
victim into this URL with my code in the
19:24
query with the state that redirects to
19:27
my website and then then the
19:28
authorization server because I used
19:31
response mode fragment would add
19:33
victim's code and other parameters in
19:35
the fragment so then the victim would be
19:40
successfully logged into my account
19:42
because there was my code and then the
19:45
victim post redirect post authentication
19:48
would be redirected to my account and
19:50
the the code would survive the redirect
19:52
it would still be present in the
19:54
fragment so I had the way to leak V IMS
19:59
code so that's uh our last attack
20:02
exploiting the post authentication open
20:05
redirect chain with login csrf thank you
20:09
so much I hope youve learned uh
20:12
something new from this presentation you
20:14
should definitely always test off
20:16
because it has great impact and it is
20:19
often misconfigured so it's it really
20:21
pays off to to know this
20:24
protocol and there these URLs uh you can
20:27
access slides from this presentation and
20:30
also you can fill in the survey I will
20:32
appreciate any feedback on the uh
20:35
presentation for now once again thank
20:38
you for listening and I hope you're
20:39
enjoying the nahcon