Let the fun begins. As per Owasp, Vulnerabilities has been categorized as TOP 10.
M1 – Improper Platform Usage M6 – Insecure Authorization
M2 – Insecure Data Storage M7 – Client Code Quality
M3 – Insecure Communication M8 – Code Tampering
M4 – Insecure Authentication M9 – Reverse Engineering
M5 – Insufficient Cryptography M10 – Extraneous Functionality
Also for practice collection of vulnerable Applications-pentestlab.blog
We are using Insecure bank Android Application to demonstrate vulnerabilities-
By using drozer we can gather information about Android application
Command – run app.package.info –a <.apk name>
Details – UID, GID, Users Permissions, Data directory, Apk Path, shared libraries, shared users, version and Application name.
As I have defined all Android components Activities, services, Content provider and broadcast receivers in https://gbhackers.com/android-application-penetration-testing-part-5/ now we can look for their loopholes and how those components might vulnerable in an application.
Exported Activities (exported = True) are those activities which can be accessed by other application on the same device. Most of the time after authentication on an Android
Application, it shifts to a new activity which basically users are aware off (like music playlist after your music player login). But developers keep those activities exported and even without custom permissions.
In Android manifest file, Activities are mentioned with exported value or by using drozer commands.
We can get information about exported activities.
Command – run App.activity.info –a <.apk name>
Manifest file
<activity android:label=”@7F070040″ android:name=”com.android.insecurebankv2.LoginActivity”><intent-filter><action android:name=”android.intent.action.MAIN”><activity android:label=”@7F070040″ android:name=”com.android.insecurebankv2.LoginActivity”><intent-filter><action android:name=”android.intent.action.MAIN”> </action><category android:name=”android.intent.category.LAUNCHER”> </category></intent-filter></activity><activity android:label=”@7F070057″ android:name=”com.android.insecurebankv2.FilePrefActivity” android:windowSoftInputMode=”0x00000034″> </activity><activity android:label=”@7F070054″ android:name=”com.android.insecurebankv2.DoLogin”> </activity><activity android:label=”@7F07005B” android:name=”com.android.insecurebankv2.PostLogin” android:exported=”true”> </activity><activity android:label=”@7F07005E” android:name=”com.android.insecurebankv2.WrongLogin”> </activity><activity android:label=”@7F070055″ android:name=”com.android.insecurebankv2.DoTransfer” android:exported=”true”> </activity><activity android:label=”@7F07005D” android:name=”com.android.insecurebankv2.ViewStatement” android:exported=”true”> </activity>
As permissions are not defined or exported value is true for activities after post login, we can use this to bypass the authentication.
Let’s try to call post login activities without credentials using drozer.
Example – Dotransfer, Viewstatement, Changepassword
Command in drozer – run app.activity.start –component <.apkname>< activityname>
run app.activity.start –component com.android.insecurebankv2 com.android.insecurebankv2.DoTransfer
Another way of invoking other application’s activities is to write a malicious app and feed it with the name of the package and activity to be launched. In our case, the malicious app doesn’t require any permission to launch the “Post login” activities of the vulnerable app.
Setting android: exported attribute’s value to false
In the AndroidManifest.XML file of our application, we should add the following attribute to the application component to be secured. In our case after post login activities should be secured.
<activity android: label=”@7F070055″ android: name=”com.android.insecurebankv2.DoTransfer” android: exported=”false“></activity>
True: The provider is available to other applications. Any application can use the provider’s content URI to access it, subject to the permissions specified for the provider.
False: The provider is not available to other applications. Set android: exported=”false” to limit access to the provider to your applications. Only applications that have the same user ID (UID) as the provider will have access to it.
The above code restricts other applications or any system component other than the current app from accessing this Activity. Only applications that have the same user id as the current app will be able to access this Activity.
The android: exported attribute is not the only way to limit an activity’s exposure to other applications. We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.
This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.
Multi-factor authentication (MFA), long considered a cornerstone of cybersecurity defense, is facing a formidable new…
A sophisticated cyberespionage campaign linked to Chinese state-sponsored actors has exploited a previously patched Check…
A critical security flaw (CVE-2025-20059) has been identified in supported versions of Ping Identity’s PingAM…
A sophisticated malware campaign leveraging GitHub repositories disguised as game modifications and cracked software has…
Netskope Threat Labs uncovered a sprawling phishing operation involving 260 domains hosting approximately 5,000 malicious…
A new wave of cyberattacks leveraging the Winos4.0 malware framework has targeted organizations in Taiwan…
View Comments