To understand the vulnerabilities on the mobile platform as growing number of users are using a personal smartphones and such devices have complex operations that we might not understand the vulnerability behind it. Today's lesson will be based on using Top 10 Mobile Vulnerabilities provided by OWASP as a guideline.

Genymotion With VirtualBox - https://dl.genymotion.com/releases/genymotion-3.5.0/genymotion-3.5.0-vbox.exe

VirtualBox - https://www.virtualbox.org/wiki/Downloads

MobSF - https://github.com/MobSF/Mobile-Security-Framework-MobSF

MobSF Guide https://mobsf.github.io/docs/#/mobsf_docker

OWASP Mobile Application Securityhttps://mas.owasp.org/

OWASP Mobile Testing Checklisthttps://docs.google.com/spreadsheets/d/1MZIvJ5Aze-zpyzLvQZVwyzF0bKWRPfnEd7nqFeH2PfA/edit#gid=997157040

• https://www.owasp.org/index.php/OWASP_Mobile_Security_Project

1. https://github.com/payatu/diva-android
2. https://github.com/dineshshetty/Android-InsecureBankv2

• https://github.com/skylot/jadx/releases
• https://sourceforge.net/projects/dex2jar/

• Comparisons - http://proguard.sourceforge.net/index.html#alternatives.html
• ProGuard - http://proguard.sourceforge.net/

• Dex2Jar - https://sourceforge.net/projects/dex2jar/files/dex2jar-2.0.zip/download
• JD-GUI - https://github.com/java-decompiler/jd-gui/releases/download/v1.4.0/jd-gui-1.4.0.jar
• APK-Tool - https://bitbucket.org/iBotPeaches/apktool/downloads/apktool_2.8.0.jar

• https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project

• https://blog.netspi.com/attacking-android-applications-with-debuggers/

• M1: Improper Credential Usage
• M2: Inadequate Supply Chain Security
• M3: Insecure Authentication/Authorization
• M4: Insufficient Input/Output Validation
• M5: Insecure Communication
• M6: Inadequate Privacy Controls
• M7: Insufficient Binary Protections
• M8: Security Misconfiguration
• M9: Insecure Data Storage
• M10: Insufficient Cryptography

A checklist with security considerations for designing, testing, and releasing secure Android apps. It is based on the OWASP Mobile Application Security Verification Standard, Mobile Application Security Testing Guide and others. Follow the links on each checklist item for detailed instructions and recommendations.

• The Keystore is used to store sensitive data, such as user credentials or cryptographic keys.
• No sensitive data is written to application logs.
• No sensitive data is shared with third parties unless it is a necessary part of the architecture.
• The keyboard cache is disabled on text inputs that process sensitive data.
• No sensitive data is exposed via IPC mechanisms.
• No sensitive data, such as passwords or pins, is exposed through the user interface.
• No sensitive data is included in backups.
• Sensitive data is removed from views when they're moved to the background.

• 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.
• The app does not export sensitive functionality via custom URL schemes without proper protection.
• The app does not export sensitive functionality through IPC facilities without proper protection.
• JavaScript is disabled in WebViews unless explicitly required.
• WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https is supported). Potentially dangerous handlers, such as file, tel and app-id, are disabled.
• If native methods of the app are exposed to a WebView, that WebView only renders JavaScript contained within the app package.
• Object serialization, if any, is implemented using safe serialization APIs.

• The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.
• The app uses proven implementations of cryptographic primitives.
• The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices.
• The app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes.
• All random values are generated using a sufficiently secure random number generator.
• The app doesn't re-use the same cryptographic key for multiple purposes.

• If the app provides users with access to a remote service, an acceptable form of authentication such as username/password authentication is performed at the remote endpoint.
• A password policy exists and is enforced at the remote endpoint.
• The remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted an excessive number of times.
• If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials.
• If stateless token-based authentication is used, the server provides a token signed using a secure algorithm.
• The remote endpoint terminates the existing stateful session or invalidates the stateless session token when the user logs out.
• 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 Keystore.

• WebViews correctly validate incoming URLs.
• The app sanitizes the JavaScript data when injected.
• WebViewClient sanitizes the Intent received from the URL before launching it.

• Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.
• The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards.
• The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.

• The app is signed and provisioned with valid certificate.
• The app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable).
• Debugging symbols have been removed from native binaries.
• Debugging code has been removed, and the app does not log verbose errors or debugging messages.
• Third-party libraries have been checked for weaknesses
• The app catches and handles possible exceptions.
• Error handling logic in security controls denies access by default.
• In unmanaged code, memory is allocated, freed and used securely.
• Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE support and automatic reference counting, are activated.

• A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.
• Sessions and access tokens are invalidated at the remote endpoint after a predefined period of inactivity.
• The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.
• The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.
• Step-up authentication is required to enable actions that deal with sensitive data or transactions.
• 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 detects whether it is being executed on a rooted device. Depending on the business requirement, users are warned, or the app is terminated if the device is rooted.
• The app informs the user of all login activities with his or her account. Users are able view a list of devices used to access the account, and to block specific devices.
• The app educates the user about the types of personally identifiable information. m/android-hacking-and-security-part-18-introduction-to-reverse-engineering/

• Dex2Jar - https://sourceforge.net/projects/dex2jar/files/dex2jar-2.0.zip/download
• JD-GUI - https://github.com/java-decompiler/jd-gui/releases/download/v1.4.0/jd-gui-1.4.0.jar
• APK-Tool - https://bitbucket.org/iBotPeaches/apktool/downloads/apktool_2.2.0.jar

1. Run the following command in terminal on the APK

sh dex2jar.sh diva-beta.apk

2. Once done, a jar file should be generated.
3. Open the jar file using JD-GUI
4. Now you have all the Java Files

AndroidManifest.xml contains all Android intents (pages) and permissions that the application provides.

1. Run the following command in terminal

java -jar apktool_2.0.3.jar d diva-beta.apk -o output

2. Now you should see the XML Document!

Sometimes developers keeps sensitive data logged into the developer console. Find a way to extract the information keyed in by the user

Hint: logcat

1. Run the following command in terminal

$ adb logcat

2. Look for the following line in terminal

E/diva-log( 1695): Error while processing transaction with credit card: 0000000000

3. Open up JD-GUI to see the code causing this vulnerability

https://developer.android.com/guide/topics/data/data-storage.html

• Shared Preferences
• SQLite Databases
• Internal Storage
• External Storage
• Network Connection