Part 1 of “Android Pentesting Methodology” covered Android architecture. Part 2 covered APKs, basic app reversing, and popular debugging tools. In this blog post (part 3 of the same series), we will examine static analysis and dive into the inner workings of the AndroidManifest.xml file.
Static Analysis
Static program analysis is the analysis of computer software performed without executing any programs, in contrast with dynamic analysis, which is performed on programs during their execution.
Static code analysis is a process for programmatically examining the application code on the disk, rather than while it is running. Static analysis is performed on the code in order to “regenerate” it from smali/byte code. This is important to understand since code is only a representation, which implies that the actual code may change, resulting in many false-positives when employing automated tools like MobSF.
Some common security issues to check for in Android applications are: excessive permission, hardcoded credentials, weak cryptographic functions, workflow bypass, hidden features, inappropriate log management, unsecured storage, and so on.
Let’s go over some fundamental principles before we get into the analysis section.
- Mobile Web Application: These applications are non-native, which means we could use mobile browsers to access them. The majority of them are HTML5, JavaScript, and CSS apps with a web interface that looks and feels like a native app.
- Native Applications: These are made specifically for mobile devices and can be downloaded and installed through the app store. These applications are made with development tools and languages like Java via Android Studio. These apps will take advantage of every function on android devices, including the camera, GPS, contacts, and so on.
- Hybrid Applications: Both native and mobile web versions of these applications are available. These are web apps that have been converted to a native mobile platform and have taken advantage of cross-platform web technologies such as HTML5, CSS, and JavaScript. Facebook, for example, can be accessed via a mobile app or a browser such as “m.facebook.com.”
- Application SANDBOX Theory: According to the SANDBOX concept, no two apps on the same computer can access each other’s data without authorization. They should also not interfere with the operation of other apps. It isolates resources for each program and assigns a unique user identifier using Linux user-based security (UID). It implies that each program can run independently of the others, with its own user and virtual machine (VM), Dalvik or ART.
Static Analysis
The process of reviewing the source code of an APK (android application) file is known as static analysis. This can be carried out using many reverse engineering tools such as apktool, dex2jar, jd-GUI, and other automation tools like mobSF to decompile the APK file. Let us look at one such reverse engineering tool in more detail.
To decompile the APK file, run the following command:
apktool d <example.apk>
Manifest files, Dexfiles, Smali files, and other non-human-readable forms are among the apktool output. Tools like dex2jar and JD-GUI, on the other hand, can assist in the conversion of such files to human-readable forms. For more information refer to Android Pentesting Methodology (Pt. 2).
Let’s see the most important file in the APK – AndroidManifest.xml. During a mobile application penetration test, we can find most of bugs by reviewing the android manifest file.
Android Manifest.xml
The Android manifest file is an XML file that specifies the names of application packages as well as the program’s essential parts, such as broadcast receivers, services, and content providers. It contains information about the Android operating system and other useful information. It also aids in defining permissions so that other applications can or cannot access the data.
For Android mobile application development, it is necessary to define the manifest file:
Here we are using AndroGoat application. Every Android application will have a package name that will uniquely identify it on the device and in the app store. While performing static analysis, the package name will assist us in identifying source code-related issues in the application.
The AndroGoat application’s package name is “package=owasp.sat.agoat” according to the manifest file.
All activities, services, broadcast receivers, and content providers that are key components of any android application are included in the app’s components. Each component will have its own functionality, which will specify the device configurations that it can manage.
Let us now learn some fundamental details about each Android APK component.
Activity
Activities are the visual elements, or screens, that you see when instructing with android applications as a user. They can be vulnerable to attacks when they allow access to user data without proper authentication.
An activity is a depiction of a single screen with a user interface, or it can be characterized as the screen’s performance action. In web applications, it’s similar to web pages. An e-commerce application, for example, could have one activity that displays a list of orders, another action that adds things to the cart, and still another activity that Wishlist’s the products.
The following activities are declared in our sample manifest file:
If access to an exported Activity is not controlled, any application on the phone/device can launch it. An attacker can get total authorization to the application’s sensitive information this way. They can even change the internal state of the application or fool the user into interacting with the victim application.
Services
A service is often used in the backend to do tasks that do not require user input. For example, a service could be playing music in the background while another application is being used.
The following service are defined in our manifest file:
If access to an exported Service is not controlled, any application in the phone/device that can start is tied to the service. As a result, it enables an attacker/malicious application to perform illegal activities, get sensitive information, or damage the internal state of the victim’s application.
Broadcasts Receivers
Another Android component that listens to broadcast messages from another application or the same system is the Broadcast Receiver. It can even send broadcasts to apps that are not currently operating.
For instance, the user receives a low battery notice. Android programmers can utilize broadcast messages within the app or outside of the normal flow.
The manifest file declares the following broadcast receivers:
Content Providers
It masks the database’s details, which are used to read and write private application data that is not shared. As a result, without content providers, accessing data from other apps is difficult.
Consider looking for contact information in the contact list or requesting photographs from Content Provider’s gallery. If Content Provider access is not restricted to only a few apps, malicious apps might gain access to important data.
The property “android: exported = true/false” will be present in all android components, with the default value of “false.”
android:exported=trueIf the exported property is set as true, the application, activity, service, or content provider can get access to other application components (like intent, layout, resources, etc.). The ADB utility can be used to start it.
We can use the following command to invoke the activity (which implies we can launch the exported activities without logging into the application):
adb shell am <package name>/.<activity name>
android: exported=false
This means that you can start Android components from within the same application using the same user ID.
Permissions
The app requires access to restricted areas of the system or other applications. It can also provide any permissions that other apps must have in order to access the application’s content. Access to the internet, contacts, and the camera, for example, are all possible permissions.
Note: We need to see if the application has harmful permissions like WRITE and READ External Storage enabled.
The manifest file (in this case) declares the following permissions:
- WRITE_EXTERNAL_STORAGE: The application will be allowed to write arbitrary data to the device’s external storage, potentially compromising privacy.
- READ_EXTERNAL_STORAGE: The application will be able to read arbitrary data from the device’s external storage, which might compromise privacy.
Additionally, there are two crucial options in the manifest file that we must be aware of: the Allow Backup and Debug values, both of which are set to false by default.
As can be seen below, allowBackup is set to true.
Applications can be backed up to external storage or another device via backup. The attacker can obtain backup information directly from an application sandbox without rooting the device if the user replaces or wipes their phone storage.
If this flag is set to true, an attacker can inject code to carry out this method in the background of a susceptible application process, allowing sensitive data from the application to be collected.
The minimum SDK version for any Android application must be greater than 18. Any application with a value less than 18 is insecure and subject to a variety of security issues, potentially risking the security of other apps.
Some basic security checks to carry out when examining the Android manifest file are listed below:
- Look for the package name (such as “package=owasp.sat.agoat”) to aid in the source code examination.
- Check for the Android SDK version that is required (> 18).
- Look for the Debug flag (must not be set to true).
- Check for potentially dangerous permissions like Read/Write External Permissions.
- If the application does not require them, look for any superfluous permissions.
- Exported Android Components such as Activity, Content Provider, Shared Preferences, and Broadcast Receivers should all be set to TRUE (Exported = True).
- Search for API keys, access tokens, and any other sensitive data.
In this blog, we discussed static analysis and the various components of the Android manifest file (AndroidManifest.xml). In the upcoming blog we’ll briefly discuss dynamic analysis along with a basic walkthrough on Mobile Security Framework (MobSF).
By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
