Owasp Mobile Top 10 M4 – Insecure Authentication

In this post, we are going to discuss the insecure Authentication which holds the Fourth position in Owasp Top 10 mobile Risks. Android apps are facing this vulnerability when the app fails to identify the user, allowing an anonymous user to login and using default login credentials. This category includes session management issues, privacy issues related to authentication, and issues where user identification tokens are compromised. Even if the mobile app uses a weak password policy to simplify entering a password, it suffers from insecure authentication.

To exploit this vulnerability, we have different approaches like attacking activities, Brute-force attack, user enumeration and checking password policy.

Attacking Activities:

In Android apps, everything is activities if you are in login screen it’s an activity if you are in profile screen its other activity so we can able to bypass the authentication by forcing the app to show the profile activity without giving username and password. To exploit activities we need to use a drozer framework which we have already discussed in earlier blogs.

first, we need to know what are the activities are available in insecure bank app for that we need to give the below commands

dz> run app.activity.info -a com.android.insecurebankv2

From the results, we come to know that that are 5 activities which are exported and first two are related to the login process.

 Fig. 1

 Com.android.insecurebankv2.LoginActivity is for login page screen (Fig 1.) and the com.android.insecurebankv2.PostLogin activity (Fig 2) is the screen which triggers when the user logged in. so we need to use the com.android.insecurebankv2.PostLogin activity to bypass the authentication. By using drozer let we start the activity by giving the below commands

dz> run app.activity.start  --component  com.android.insecurebankv2 com.android.insecurebankv2.PostLogin

 Fig 2.

 finally, we have bypassed the login page now we can do the transfer, changing the password or viewing the statement is possible. A brute-force attack is also possible but if the app has any brute-force protection mechanism it makes hard to attack. for example, if the app gets often login request it will block the user and it will restrict the access for a while. and there is another issues like Username Enumeration which occur when a user logged and for the second time when he/she too going login in app it shows the username and also when app gets the correct username and the wrong password that time it may show password of the username is wrong so it will conform us the username, it mostly happens in WordPress logins in web applications.

How to Fix:

• Don’t export unnecessary activities or use permissions when the activity is exported
• Implement two-factor authorization if called for the sensitivity of your application
• Disable anonymous accounts
• Implement strong password policy and don’t store the password in local storage

In this post, we have discussed how to attack activities using the drozer tool, and how the way android apps are vulnerable to owasp’s insecure authentication, and how to fix the vulnerability.