Tuesday, February 11, 2025
HomeAndroidAndroid Application Penetration Testing - Part 6

Android Application Penetration Testing – Part 6

Published on

SIEM as a Service

Follow Us on Google News

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-

Information gathering

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.

Attacking Android Components

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.

  • Attacking activities 

Exported Activities

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>

Drozer

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

Before 

After

 Demo 

Using Malicious App to invoke Activities of other apps

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.

Securing the Activity component

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.

Limiting access with custom permissions

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.

Other Parts

Gurubaran
Gurubaran
Gurubaran is a co-founder of Cyber Security News and GBHackers On Security. He has 10+ years of experience as a Security Consultant, Editor, and Analyst in cybersecurity, technology, and communications.

Latest articles

Apple iOS 0-day Vulnerability Exploited Wild in Extremely Sophisticated Attack

Apple has released emergency security updates to address a zero-day vulnerability, CVE-2025-24200, that has...

SHA256 Hash Calculation from Data Chunks

The SHA256 algorithm, a cryptographic hash function, is widely used for securing data integrity...

New Report of of 1M+ Malware Samples Show Application Layer Abused for Stealthy C2

A recent analysis of over one million malware samples by Picus Security has revealed...

Seven-Year-Old Linux Kernel Bug Opens Door to Remote Code Execution

Researchers have uncovered a critical vulnerability in the Linux kernel, dating back seven years,...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

BADBOX Botnet Surges: Over 190,000 Android Devices Infected, Including LED TVs

The BADBOX botnet, a sophisticated malware operation targeting Android-based devices, has now infected over...

Malicious Android & iOS Apps Downloaded Over 242,000 Times, Stealing Crypto Recovery Keys

A sophisticated malware campaign, dubbed SparkCat, has infiltrated Google Play and Apple’s App Store,...

Android Security Update Fixes Linux Kernel RCE Flaw Allow Read/Write Access

On February 3, 2025, Google published its February Android Security Bulletin, which addresses a...