A list of checks with tips for analyzing the security of Android applications
Based on OWASP MASVS and OWASP MSTG
Starting with open AndroidManifest.xml.
For fast and easy analizing you can use MobSF.
- Allow backup (+ fullBackupContent)
- Allow debug
- AndroidManifest.xml
- res/values/strings.xml
- local.properties or gradle.properties
- res/assets/*
- Dynamic Ananlysis (
adb logcat) - Static Ananlysis (
android.util.Log,Log.,Logger,System.out.print,System.error.print,logfile,logging,logs)
- HTTP
- Websockets
- Raw TCP (WireShark)
The app verifies the X.509 certificate and work only with certificates signed by a trusted CA (MSTG‑NETWORK‑3)
- Check with porxying SSL traffic throug BurpProxy
- Go to https://ssllabs.com/ssltest/analyze.html and check SSL configuration of server.
- Check that tracker services, monitor user behavior, sell banner advertisements, improve the user experience, and more do not send sesitive data to third parties.
- Looking for showed on app screen
passwords,PAN,credentials, etc...
Storage of PII (Personal Identifying Information) and sensetive information (MSTG-STORAGE-1 and MSTG-STORAGE-2)
- Shared Preferences
- SQLite Databases
- Realm Databases
- Internal Storage
- External Storage
- CacheDir
- Firebase Real-time Databases (
https://\<firebaseProjectName\>.firebaseio.com/.json)
- Check the permissions of the files in
/data/data/<package-name>.
- Identify development files, backup files, and old files that shouldn't be included with a production release.
- Can another process read or change internal storage data of app with sending malicious data to input (Through user input for example (PTRAV/SQLI/COMMAND INJ/etc...) / Through IPC Mechanisms)
- AndroidManifest.xml
- Providers
- Services
- Activities
- Receivers
! Look at android:exported=true, intent-filters, android:permission, android:protectionLevel=signature
-
Static Analysis:
android.content.ContentProviderandroid.database.Cursorandroid.database.sqlite.query.update.delete
-
Dynamic Analysis:
- Use
adbfor trigger IPC mech-s - Drozer for check attack surface and IPC entrypoints
- Use
-Looking for keys and secrets in Storages and resources - AndroidManifest.xml - res/values/strings.xml - local.properties or gradle.properties - res/assets/* - Android Storages
-
Looking for Private Keys in Storages and code
- Key
- PrivateKey
- PublicKey
- SecretKey
- KeyInfo
-
Сheck cryptographic methods and algorithms
- java.security.*
- javax.crypto.*
- android.security.*
- org.bouncycastle.*
- org.spongycastle.*
- crypto
- Cipher
- Mac
- MessageDigest
- Signature
- Security
Insecure classes: - java.util.Random (PRGN can produce predictable numbers if the generator is known and the seed can be guessed.) - is no longer support SHA1PRNG
- Java AES Crypto - A simple Android class for encrypting and decrypting strings.
- SQL Cipher - SQLCipher is an open source extension to SQLite that provides transparent 256-bit AES encryption of database files.
- Secure Preferences - Android Shared preference wrapper than encrypts the keys and values of Shared Preferences. (Check what is a secret password/key for generetion key / Check where storing a key for decrypt SP(It can get into backup data))
The easiest way to check it is to do it dynamically.
- Does the application have its own authentication mechanism?
- Does th application check access using the existing password or biometric authentication mechanism?
- Is it possible to get access to the application interface on the device without screen lock mechanism?
! If the application doesn't have its own authentication mechanism it should check that device have screen lock mechanism with a password or biometric key.
You can also search for classes used for local authentication: - KeyguardManager - check that lock screen have password. - biometricManager - for biometric authentication. - BiometricPrompt - for dialog with user.
-
If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. (Just check entropy of session tokens) (MSTG‑AUTH‑2)
-
If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. (Check JWT Security:
none-algorithm / brute-force secret key / RS256 changing on HS256 with public key signing) (MSTG‑AUTH‑3) -
The remote endpoint terminates the existing session when the user logs out. (MSTG‑AUTH‑4)
-
A password policy exists and is enforced at the remote endpoint. (MSTG‑AUTH‑5)
-
The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. (MSTG‑AUTH‑6)
-
Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire. (MSTG‑AUTH‑7)
The app only requests the minimum set of permissions necessary.
All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.
- Dynamic Analysis
- Static Analysis (In the layout definition TextViews attributes: android:inputType=textNoSuggestions)
adb backup -f backup.ab -apk ru.example.appand see what is in backup
- Just open some sesetive information in app screen and exit to louncher.
- Is /identify sensitive information/ or /credentials/ stored in memory too long.
Apps that process or query sensitive information should run in a trusted and secure environment.
- PIN- or password-protected device locking
- Recent Android OS version
- USB Debugging activation
- Device encryption
- Device rooting (see also "Testing Root Detection")
Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore.
For example:
public void authenticationSucceeded(FingerprintManager.AuthenticationResult result) {
cipher = result.getCryptoObject().getCipher();
//(... do something with the authenticated cipher object ...)
}
If app does not use cipher object and simply checks its appearance, this is called "event-bound authentication".
A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.
Sensitive transactions require step-up authentication.
The app informs the user of all sensitive activities with their account. Users are able to view a list of devices, view contextual information (IP address, location, etc.), and to block specific devices.
The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.
The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.
The app only depends on up-to-date connectivity and security libraries.