Misconfigurations in Android apps occur when security settings are incorrectly applied, leading to vulnerabilities that can be exploited by attackers. These errors often result from building the application with insecure options, such as allowing network traffic in clear text, leaving debug modes active in production, or requesting excessive permissions without proper justification. We will cover some manual ways, but keep in mind that you can use Mobile Security Framework (MobSF) to detect in an automated way.
Since Android 9 (API 28), the system has started to block HTTP connections in clear text by default, forcing apps to use secure HTTPS connections. This policy is controlled via the network_security_config.xml file, referenced in AndroidManifest.xml, where it is possible to granularly define whether specific domains can use cleartext traffic.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="<package_name>">
<application
android:usesCleartextTraffic="true" <!-- Allows cleartext (HTTP) connections -->
android:allowBackup="true"
android:debuggable="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>However, many applications end up disabling this protection by setting android:usesCleartextTraffic="true" in AndroidManifest.xml, allowing insecure HTTP connections to any domain. This practice represents a severe risk, as it leaves the app vulnerable to interceptions and data manipulation, especially on public or compromised networks. Indiscriminate permission of clear text traffic should be avoided and, if necessary, limited only to controlled domains and in development environments.
The android:debuggable="true" flag in AndroidManifest.xml allows the app to be debugged via tools like adb, which is useful in development, but dangerous in production.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="<package_name>">
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme"
android:debuggable="true"> <!-- Enables debug mode -->
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>With this flag activated:
- It is possible to access the app's internal files with run-as <package_name>, even without root;
- Log output with adb logcat may contain sensitive information such as tokens, internal errors and user data;
- The app can be more easily inspected and manipulated by tools like Frida, Xposed, Objection, etc.
adb logcat
-> If you want, you can use pidcat to have colorful and organized output (https://github.com/JakeWharton/pidcat)
pidcat <package_name>
The android:allowBackup="true" flag in AndroidManifest.xml allows the system to automatically back up application data, including internal files, preferences, and databases.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="<package_name>">
<application
android:allowBackup="true" <!-- Enables backup mode -->
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme"
android:debuggable="true">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>If this option is enabled, you can extract application backup files, which may contain sensitive data, using the following command:
adb backup -apk -shared -all -f backup.ab
On Android, permissions are declared in the AndroidManifest.xml file using tags, such as ACCESS_FINE_LOCATION, CAMERA, READ_CONTACTS, among others. The main security issue lies in requesting excessive or unnecessary permissions, which increases the attack surface and raises concerns regarding user privacy and data misuse.
For example, a map or delivery app legitimately needs access to the device's location, this is expected and aligned with the purpose of the app. However, when a simple flashlight app requests access to SMS, contacts or microphone, it may indicate incorrect configuration or possible abuse of user data.
Misapplied permissions:
- Expand the potential for exploitation by malicious actors;
- Allow unintentional access or leakage of sensitive information;
- Undermine user trust and violate Play Store policies.
Permission usage should always be tied to a real functional need, and safer alternatives should be considered (e.g., using ACTION_IMAGE_CAPTURE intent instead of requesting the CAMERA permission). Developers must also handle permission checks and user prompts properly using ContextCompat.checkSelfPermission() and requestPermissions() to avoid runtime issues.
-> Displays a detailed report about the specified application, including requested and granted permissions, installation information, components, and package settings on the connected Android device.
adb shell dumpsys package <package_name>
Info+: MASTG-TEST-0024: Testing for App Permissions:OWASP
The minSdkVersion setting defines the minimum version of Android on which the app can be installed. When set to very old versions (e.g. API 23, Android 6.0), the app can run on devices with multiple known vulnerabilities and without security updates from Google.
Risks:
- Old devices no longer receive security patches.
- The app can be exploited via operating system vulnerabilities, such as flaws in:
- File permissions;
- WebView implementations;
- Binder and Kernel failures.
-> You can check the minSdkVersion value of an APK with the following command:
aapt dump badging app.apk | grep sdkVersion
The Janus vulnerability CVE-2017-13156 allows attackers to modify a digitally signed APK without invalidating its signature, enabling the injection of malicious code. This flaw affects Android devices running versions between 5.1.1 (API 22) and 8.0 (API 26) by exploiting a weakness in the Android Runtime (ART), which incorrectly interprets APK and DEX file formats.
The vulnerability works by appending extra bytes to APK and DEX files without affecting the APK’s digital signature. This is possible because the v1 signature scheme only verifies the ZIP entries within the APK, ignoring any extra data, which allows malicious code to be embedded.
There are four APK signing schemes: v1, v2, v3, and v4. This vulnerability only affects APKs signed using v1, which is still accepted by Android versions prior to 8.0. APKs signed with v2 or higher are protected, as these schemes validate the entire APK file, including extra data, thereby preventing unauthorized modifications.
Note: Apps signed with multiple schemes (e.g., v1 + v2 + v3) can still be vulnerable on older devices, since these systems rely solely on the v1 scheme during verification.
-> You can check the APK’s signing scheme using:
apksigner verify -verbose app.apk
-> And you can check the minimum SDK version supported by the app with:
aapt dump badging app.apk | grep sdkVersion
You can exploit the Janus vulnerability using the proof of concept (PoC) created by V-E-O, available at: https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156
Steps to explore:
1- Extract the classes.dex file from any APK you want to inject, using, for example, apktool:
apktool -s d <App.apk>
2- Use the janus.py script to merge (concatenate) the extracted DEX file with the vulnerable APK, taking advantage of the signature verification failure:
python janus.py classes.dex <original.apk> <output.apk>
3- Install the modified APK on the vulnerable device, updating the existing app without invalidating the digital signature.
If you use the DEX file from another application, the modified app may crash when running, but the fact that it can install without an integrity error confirms that the exploitation was successful.
Info+: https://medium.com/mobis3c/exploiting-apps-vulnerable-to-janus-cve-2017-13156-8d52c983b4e0