How Token Scope Confusion Leads to Privilege Escalation?

Hello hackers, [music]

welcome back to the new video and in

this video we are going to talk about

token scopes and how it can lead to

privilege escalation when they're

improperly generated or validated. So

these bugs are real and you can find it

in the wild. Actually, this is kind of

inspired from a tweet or post I saw on

X. So here's that post and I thought to

research a bit more on this so I can

share it with you as well how this

actually works and how you can find this

bug [music] while bug hunting or

pentesting. So before we jump into that

we need to clear our basics. What is

token?

A token is a secure digital credential

used to verify a user's identity and

grant them access to protected resources

without requiring them to reenter

credentials for every single request. It

basically means that instead of uh

typing the username and password again

and again to access different features

in a web application, a user is simply

granted a token after single

verification and that token is used in

every single request. So it would be

much easier for the client and the

server to verify the user and it's uh

easy as well. So that's how usually

token works. In simple words, I would

say token basically says this user has

already been authenticated and here is

what they're allowed to do. Now, a token

has different kinds of claims and token

scope is one of the claim inside that

[music] access token. You can also call

it token or access token. So, the scope

inside an access token defines what

action the token is allowed to perform.

Let's say if a user is only allowed to

read and write then the token will have

read write [music] permissions but it

won't have any other permissions like

delete permission. You getting me? And

this is actually really important part

[music] of the token because it

literally defines what a user is allowed

to do and what not. And [music] as a

hacker, we're going to test how we can

escalate our privileges or how we can

test if there are something else we can

do like if we can delete something, we

can write something even though we are

not allowed to do so. I mean that's what

all hacking is about checking something

we are not allowed to do. Okay. So it

usually includes something like this

scope SCP permissions. Okay. There are

like three different names of it but all

of them do the same thing. So usually

scope you will see something like read

colon profile or write colon post. So it

means they can read profile and they can

write posts and there is a expiration

time for each access token as well. So

obviously if you're been testing and if

you see that there is uh no expiration

time then that itself is also a bug and

it would be low. But yeah

so let's talk about the steps of how

tokens work.

Okay, back in notion cuz we love notion.

So we have a diagram here and here you

can see is the traditional cookie based

authentication.

First the browser sends a request a post

request containing username and password

to authenticate the user and then the

server sends back a response by setting

a cookie for the user and it gives

something like set cookie session and

send some random value. You must have

seen it in uh traditional web

applications. And then the user is able

to access authenticated endpoints such

as / API/ user by using their cookie.

And then they're able to get back

response with 300 okay and their

information. So that's how traditional

cookie based authentication works. But

now we have modern based authentication.

In this case, the browser again sends a

post request with username and password

to authenticate the user and then the

server responds. But this time the

server responds with a token. In this

case, a JWT token. Okay? And we know JWT

token contains multiple claims, some

expiration time and scopes and

everything. We talked about scopes cuz

in this video we are going to exploit

scopes anyway. So you got the point and

that's how the server is able to give

particular permissions to a user. Okay.

Now the user will use that token in

every HTTP request to access

authenticated endpoints in this case/

API/ user and then they will simply get

200 okay response. So that's how it

works. So after looking at this diagram

this will make more sense. We have a

first step request. So user attempts to

access a protected resource by logging

in with their credential, username and

password and then second step is

verification. The server validates the

credential. If they are correct, the

server generates a unique

cryptographically signed token. The

third step we have the server sends the

token back to the client. Example, the

user's web browser or mobile app where

it is stored securely. And then for all

the feature requests to the protected

parts of the application, the client

includes this token in HTTP header.

Right? And then for each request, the

server validates the token signature and

expiration time. So as long as the token

is valid, it will work for the user. And

when the token expired, they just simply

have to login again with the username

and password. But this is still much

better, right? They don't have to like

provide their credential for each

request. So now you know how this works.

Really simple and easy. So I have

created a custom lab and in this lab I'm

going to demonstrate you how scopes can

be exploited but it's kind of like a

different one like I have already

created a lot of videos on JW attacks

but this is not JWD attack this is

different this is about how token scope

is not properly validated and how it can

lead to authorization issue focus on my

point here it's not an authentication

issue user is getting authenticated just

fine It's about authorization. The level

of privileges they have is getting

affected. Okay. So, keep that in mind.

Okay. So, now let's get to the practical

part so you can actually understand

what's going on.

Okay. So, now we are in my browser and

as you can see this uh application is

running on my local host port 3000. I

created this. So, yeah. Anyways, so we

have this login function and there are

two ways the user can login either using

a web client or using a mobile client

and that's where the vulnerability

arise. Actually I'll tell you how. But

before we first jump into that I want to

tell you that this has a dummy database

in the back end and it has few users. So

I'm just going to log in with a user to

simply show you how this actually works.

So let me open up my network tab so I

can see what kind of requests are going

through.

I don't even have to use burp suite for

this cuz network tabs is enough in this

case cuz we're not manipulating

anything.

So we have uh Alice

username and then we have password.

Okay. So we are using the web client to

login. So let's click on login

and as you can see we are redirected to

profile.html and over here we can see

our username and then we can see the

some posts like a simple uh social media

application. So if I go here you can see

there is API me endpoint. So obviously

this is an authenticated endpoint and in

the response we can see our own details

like username, role and scope, read

profile and other post. So let me go to

headers and let me show you something

interesting. So we have authorization

header and we have this value beer

token. This is basically JWT. Okay. So

when we clicked on login the server

provided us with this token so we can

access the application. Now let me go to

JWT decoder.

Great.

So over here we can see claims. Okay,

claims table. I like this little table.

So we have sub value, the subject of the

JWD, the user and then we have ro. Ro is

user. Then we have scope read profile

means we can read our own profile. Okay,

that makes sense. And then we have other

things like expiration time and IAT and

stuff. So anyways, let's go back to

JSON. And

yeah, from here we can easily see how

the scopes looks like. Now let's go back

to the application. Everything looks

simple, right? The application is giving

us a proper scope and we don't see

anything

extra and yeah things are working fine.

But let's log out for now.

And now we are going to use the same

username and password again. So we had

Alice

and then password

but this time we are going to use the

mobile client. So what happens is uh we

know that a lot of uh companies have

their web application and their mobile

application right. So there are

different kinds of clients they use but

the thing is when they are implementing

authorization or authentication checks

sometimes they implement it correctly on

the web client but not so correctly on

the mobile client and it can lead to

issues. So it's kind of like

misconfiguration or improper validation

you can say. So in this case we are the

same user but we're just going to use

the mobile client to login. So let's

click on login.

Okay, everything kind of looks the same.

My profile and I got my post. But I see

another feature over here. And we just

unlocked new feature which we didn't see

when we logged in through the web

client. And we can delete user. So this

is a delete user feature and it was

supposed to be only for admins. So let

me go back to this um / API/meoint

again. And in the response you can see I

have some extra scope. I have reprofile

that is similar to the previous one. But

then I have delete users and this is

extra. Okay, we don't need it. The user

a normal user isn't supposed to have

this. As you can see, our role is still

user. It's not admin. But we somehow

have an extra privilege to delete user.

So this is crazy and this is what I'm

talking about. This is improper

implementation of the token. And this is

about like you didn't change or

manipulate anything using burp suit or

something. you just simply analyze how

the application is working and you found

out that somehow you have an extra role

but obviously when you are exploring

like a real application there's going to

be like thousands of features so you

have to analyze everything through a

normal user perspective first and then

you can analyze it and then you can

check if there is any other feature that

you're not supposed to see by playing

around with different features. For

example, in this case, uh we just simply

switched to mobile client and we were

able to find out a new feature that just

literally appeared for us. And I think

this is what happened in the post. Uh he

was talking about that expost

like it said that uh the scope

separation wasn't clearly enforced and

privilege escalation was possible. So

you should apply the least privilege

scopes and obviously the least privilege

scope was not applied in the mobile

client in this case

and that post also mentioned that the

scope of differently generated tokens

triggered functions with higher

privilege user roles and that's exactly

what happened here.

We just triggered a functionality that

was meant to be a highprivileged user

even though we are low and we are able

to see that feature and can simply

delete the user by clicking on this

button as you can see. So obviously this

is an authorization bug. So yeah that's

how it works. Let me know your thoughts

in the comment section. And I think this

was really fun cuz usually we manipulate

JW tokens and find secret and stuff to

manipulate it. But sometimes we forget

that something simple as this and

misconfigured

uh implementations

could be an issue as well. People

usually miss this kind of stuff. But

yeah, that's crazy.

So that's it. That's what I wanted to

talk about in this video. Hope you

enjoyed watching it. Let me know if

there is something else you want me to

talk about in the next video. And yeah,

I'll see you in the next one.

[music]

>> [music]