Introduction

Untitled

With this exploit, an attacker will try to gain higher priviledges than they should, this sounds easy but as you can see there is an added complexity with mobile testing, being that sometimes administrative functions can be decided upon from within the device instead of on a server.

Attack vector

This vulnerability type can manifest in several ways:

• If our app allows for administrative functions, and these functions do not rely the internet to work, we can try to put our device offline and execute these mobile functions locally as an admistrator
• If an API endpoint that requires authorization does not implement it (fully), the attacker can simply access those functions with a low priviledge or unauthenticated user
• An attacker can attempt to execute a binary attack (More about this in a seperate chapter)

Security Weakness

We need to make a distinction between authorization and authentication. Authorization either allows or disallows us to execute a function as a certain user or unauthenicated. Authentication means we proof to the server who we are. As you can see both are closely related since you first need to prove who you are and then have the server check if that user can access certain functionality.

If the user is not authenticated properly but the server executes all the API calls anyway, all other authorization checks are automatically vulnerable as well. We can not properly authorise someone who is not authenticated.

IDORs for example indicate the presence of an authorization issue since the code is probably not properly checking authorization levels.

Hidden endpoints can also often be weak as developers often assume these hidden back-end endpoints are impossible for attackers to spot and thus don't need very strict authorization control, but in reality we know better.

Lastly if there is ever a parameter in the request that indicates the user priviledge level and the server minds this parameter we also have an issue, however if the parameter is sent but the server simply does not care, there is also no issue of course. For example:

{
"action":"create",
"userType":"user"
}

Impact

In this case, it really depends on what function is being executed that a user is not supposed to be able to execute, if that function has no impact, of course there will also be no impact by the issue itself but that does not mean the issue should remain unfixed and we should certainly investigate further as defects usually cluster together and the presence of one usually indiciates the presene of others.

The impact itself could be, but is not limited to:

• Information theft