Introduction

Untitled

For this attack vector we first need to understand how mobile apps authenticate. They have the option to log into a server but due to the instability of the network, the user may need to authenticate locally as well while being offline. This brings inherit risk with it but luckely we have an oversight to tackle these risks.

Attack vector

When an attacked wants to exploit this vulnerability they are first trying to figure out how the authentication system works and they will do this by intercepting and repeating requests with a MiTM proxy such as OWASP zap or portswigger's burp suite. Afterwards an attacker will attempt to bypass said authentication mechanism and if the attacker is fully aware of how a mobile app would be vulnerable, they would create some kind of malware to install on the users device which will bypass the authetication by making direct calls and reporting back to the attacker on important things such as JWT tokens.

This is a much bigger on mobile devices than on desktops because users on desktops are expected to have a reasonable connection to the internet. Mobile connections are slower and less stable by nature. Because of this, mobile applications often require offline based authentication as well which can have disasterous consequences. Mobile users often have weaker passwords for their mobile devices such as a 4-digit pin which is reasonable to brute force.

Security Weakness

• If we can make authenticated calls without sending a session token along we can speak of "M4.2016: Insecure Authentication"
• If an app is leaking passwords or shared secrets we can speak of "M4.2016: Insecure Authentication"
• If an app allows for registering with a weak password we can speak of "M4.2016: Insecure Authentication"
• If an app uses a feature like TouchID instead of relying on the OS's offline authentication mechanisms, it suffers from insecure authentication.

Impact

What makes this vulnerability so bad is that due to it's nature, the user that is performing the attack is not logged ( as there is no user to speak off). This makes is almost impossible to detect and prevent this attack in the future.

The impact itself can differ:

• Of course there is the reputational damage of being know to have a vulnerable app
• Data theft could occur due to unauthorised access of data

Prevention

• Save any passwords with a salt to stop rainbow tables being used. Use a hashing algortihm that is safe to prevent issues from occuring and to stop the attacker from viewing how long the original password was.
• Use the OS's authentication mechanisms wherever possible.