STATIC ANALYSIS OF ANDROID APPLICATION
Android applications are now an integral part of our lives, thanks to the excessive use of mobile phones. However, many users are unaware of their device’s protection. If we do not know the design of our applications and how they are penetration tested, which makes you believe that you are safe and secure. You can try to mitigate this risk by performing an android penetration testing static analysis approach to ensure that mobile applications are checked thoroughly for security flaws.
Before we get to dive into the main topic, let’s discuss some of the basic concepts.
- Native Applications: They are designed exclusively for mobile devices and can be downloaded and installed directly from the app store. Development tools and languages such as Android Studio and Java are used to create these applications. These apps will make good use of all the device’s features, such as the camera, GPS, contacts, and so on.
- Application SANDBOX Theory: According to the SANDBOX principle, no two programs running on the same computer can access each other’s data without permission. They should not interfere with the functionality of other apps, either. It uses Linux user-based security to separate resources for each application and assign a unique user identifier (UID). It means that each program can run under its user and virtual machine (VM), Dalvik or ART, so that each process can run independently of the others.
Fig: Sandbox Theory
Now we can get into our main topic,
Static Analysis of Android Application: The static analysis of the android application is the process of source code review of the apk (android application) file. Several reverse engineering tools complete this procedure.
Reverse Engineering: Reverse Engineering decompiles the apk file using different tools like apktool, dex2jar, jd-GUI, and other automation tools like mobSF.
Let us know briefly about one such reverse engineering tool.
- APKTOOL: It is a command-line tool used to reverse engineering 3rd party, closed, binary Android apps. It can modify and make changes to the decode resources to the nearly original form and rebuild it.
The command used to decompile the apk file is:
apktool d <example.apk>
The outcome of the above command is mentioned below,
Fig 1.1: Output of apktool
Fig 1.2: Output of apktool
The output of the apktool includes Manifest file, Dexfiles, Smali files, etc., which are not human-readable formats. However, tools like dex2jar and JD-GUI can help to convert those files to human-readable formats.
Android Manifest File: It is an XML file that contains application package names and the main elements of the application like broadcast receivers, services, and content providers. The android manifest file will give us the necessary information about the Android operating system and app store. It also assists in declaring the permissions to other apps that they can access the data.
Fig 1.3: AndroidManifest File
To declare manifest file is mandatory:
- The app’s package name:All the android applications will have a package name that uniquely identifies the application on the device and in the application store. The package name will help us check the source code-related issues in the application while doing the static analysis.
From the above manifest file, the package name of the diva application is “package=jakhar.aseem.diva”
- The components of the app include all activities, services, broadcast receivers, and content providers that are essential components of any android application. Each component will define specific functionality, which describes the capabilities of the device configurations it can handle.
Now, let us know some basic information about each android component.
Activity: An activity can be described as the screen’s performance action, or you can say it is a representation of a single screen with a user interface.It is like web pages in web applications. For example, an e-commerce application might have one activity that shows a list of orders, another activity to add products to the cart, and a different activity for Wishlist the products.
Activities in the manifest file are declared as follows,
Fig 1.4: Declaration of activities in the manifest file
Any application in the phone/device can launch the activity if the access to an exported Activity is not restricted. Through this, an attacker can gain complete authorization to the sensitive information of the application. Furthermore, they can even modify the application’s internal state or trick the user into interacting with the victim application.
Services: A service usually runs in the backend to carry out operations that don’t provide user provide. For example, a service is playing music in the background while using a different application.
Services in the manifest files are declared as follows,
Fig 1.5: Declaration of services in the manifest file
Any application in the phone/device that can start is bound to the service if access to an exported Service is not restricted. Thus, it allows an attacker/malicious application to perform unauthorized actions, gain access to sensitive information, or corrupt the internal state of the victim’s application.
Broadcast Receivers: Broadcast Receiver is another android component that responds to broadcast messages from another application or the same system. It also can deliver broadcasts to applications that are not running. For example – low battery notification is provided to the user. The android developers can use broadcast messages in the application or outside the usual flow.
Broadcast Receivers in the manifest file are declared as follows,
Fig 1.6: Declaration of broadcast receivers in the manifest file
Content Providers: It’s a component that will allow an application to share data among multiple applications. It hides the details of the database, which is used to read and write private data of the application that is not shared. Therefore, it isn’t easy to access the data from other applications without content providers.
For example, consider looking for contact details in the contact list or want photos from the gallery provided by Content Provider.
Malicious apps can access sensitive data if the access to Content Provider is not restricted to only limited applications.
All the android components will have an attribute called “android: exported = true/false,” and the default value is “false”.
android: exported=true: This element will decide what application, activity/service/content provider will be launched by components of different applications. It can be invoked using the ADB tool.
Fig 1.7: exported=true (content provider)
Fig 1.8: exported=true (service)
Fig 1.9: exported=true (receiver)
To invoke the activity (which means that we can be able to launch the exported activities without login to the application), we can use the following command:
Command: adb shell am <package name>/. activity name
Fig 1.10: Invoke the activity
Fig 1.11: Invoke the activity
android: exported=false: It means with the same user ID, you can launch the android elements by components of the same applications.
iii. The permissions: The app needs to access protected parts of the system or other applications. It can also declare any permissions that other applications must have if they want to access content from the application. The permissions may include access to the internet, contacts, access to the camera, etc.
Permissions in the manifest file are declared as follows,
Fig 1.12: Declaration of Permissions in the manifest file
We need to check if the application is having dangerous permissions enabled like WRITE and READ External Storage.
Fig 1.13: Potentially Dangerous Permissions Enabled
- WRITE_EXTERNAL_STORAGE: The application will be able to write arbitrary data in the device’s external storage, impacting privacy.
- READ_EXTERNAL_STORAGE: The application will be able to read arbitrary data in the device’s external storage, affecting privacy.
Among all these, there are two essential flags which we need to know in the manifest file, and those are Allow Backup and Debug flags, and the default value of those flags is set to false.
Backup allows applications to be backed up to the external storage or another device. It means, if a user replaces or wipes their phone, they can restore app settings and application data (sensitive data) though, the attacker can extract backup information directly from an application sandbox without rooting the device.
Fig 1.14: android: allowBackup=”true”
In case the setting of this flag is true, an attacker can inject their code to carry out this procedure in the backdrop of a vulnerable application process, and the application’s sensitive data can be extracted from the application.
Fig 1.15: android: debuggable=”true”
minSDK version: The minSDK version of any android application must be greater than 18. Any application with a value below 18 is insecure and vulnerable to many security flaws, thus impacting the security of the running applications.
As a pentester, we need to check the following security loopholes in the manifest file:
- Check for package name (“package=jakhar.aseem.diva”), which can help perform the source code analysis.
- Check for minimum android sdk version (It must be above 18)
- Check for allowing back up the flag (It must not set to true)
- Check for Debug flag (It must not set to true)
- Check for Dangerous permissions in use, such as Read/Write External Permissions.
- Check for unnecessary permissions if the application does not require them.
- Check for Exported Android Components such as Activity, Content Provider, Shared Preferences, and Broadcast Receivers are set to TRUE (Exported = True), Usually not set to True.
- Check for API keys, access tokens, and any sensitive information.
Dex2Jar is a command-line reverse engineering tool that can be used to covert dex files to jar files. The output of the apktoolresults in “classes.dex” files which are not human-readable or understandable. The classes.dex file is a Dalvik Executable file, and each android application must have this file.In addition, this file contains the Java libraries which the application can use.
Command: d2j-dex2jar classes.dex
Fig 2.0: Converting dex files to jar files using dex2jar tool
Fig 2.1: Classes.dex file is converted to classes-dex2jar
3.JD-GUI: JD-GUI is a standalone graphical utility tool that displays the Java source code of “.class” files. For immediate access to fields and methods, we will have to search for reconstructed code with JD-GUI. We can check any sensitive information (access tokens, api keys, subscription keys, usernames, passwords, etc.) stored in the java files.
Fig 3.0: Output of JD-GUI
Fig 3.1: User Credentials and API Key in Source Code
Fig 3.2: User credentials are storing in the database
It was a detailed overview of the static analysis of an android application and the tools used for reverse-engineering the application.
Attack & PenTest Team
Varutra Consulting Pvt. Ltd.