Android Application Vulnerabilities

Tram Ho

M1. Improper Platform Usage

1. Insecure version of OS installation allowed

Do not allow applications to be installed on very old OS versions due to the risk of insecurity from the OS itself.

Can be specified in AndroidManifest.xml, minSDKversion section. Temporarily determine min Sdk = 24 and min OS = Android 7

2. Abusing Android components through IPC intents

With Activity Hijacking (Intents): This happens when an Activity depends on the implicit Intent. The attacker registers a correct Intent Filter and controls it, running a malicious Activity instead of what we want, under which the user would use the wrong application without realizing it.

With Malicious Broadcast Injection (exported): If a BroadcastReceiver is exported, always trust the incoming broadcast intents without checking for actions, the received data may receive invalid actions or unwanted data, causing the Malicious intentions can be pervasive within the application.

3. Default credentials on Application Server

Define default credentials on the Backend server

Example: Tomcat server uses tomcat / tomcat, admin / tomcat

4. Security misconfiguration on Server API

Security Misconfiguration in API Server, may be related to the use of old buggy versions, CORS, HSTS …

5. Minimum device security requirements absent

M2. Insecure Data Storage

1. Unencrypted credentials in databases.

The app stores unencrypted account information in database files: * .sqlite, * .db. When the app is installed on the root device, the attacker can download the database files to the device and read it all. information ( in case the DB is not encrypted )

2. Sensitive data storage in plain text .

The application stores sensitive information in plain-text format, easily readable by plain text editing programs.

3. Insecure cookie storage.

When the application stores unsecured cookies, an attacker can use these data to impersonate a valid user’s login session.

4. Store credentials outside Sandbox.

Application files stored in SD Cards (external storage) contain sensitive information and can be read and changed by any other application.

5. Unencrypted backup file.

The application does not encrypt the backup file, can reveal information when the hacker can read it.

6. Store encryption key locally.

An application stores an insecure, hardcoded key, an attacker can use this key to decrypt the encrypted data.

7. Improper file permissions or allow global permission.

Setting insecure permissions makes it possible for other apps to read / write sensitive files stored inside the app.

8. The keyboard cache is disabled on text inputs that process sensitive data

Keyboad cache is disabled on input fields involving sensitive data

9. No sensitive data, such as passwords or pins, is exposed through the user interface

No sensitive data, like passwords or pin codes are displayed through the user interface

10. No sensitive data is included in backups generated by the mobile operating system.

No sensitive data is stored in the backups created by the operating system

11. The app removes sensitive data from views when moved to the background

The application hides sensitive data from the visible interface when switching to the background

M3. Insecure Communication

1. Insecure Transport Layer Protocols

Transferred data is not well protected, possibly eavesdropping and information disclosure.

2. Use of Insecure and Deprecated algorithm

The applications that connect to the server use weak encryption algorithms that make them easy to decrypt by the bad guys. This jeopardizes the security of the communication channel between the application and the server

3. Use of Disabling certificate validation

Allow Hackers to block SSL traffic without installing the certificate (checkServerTrusted nobody)

4. SSL pinning Implementation – Lack of Certificate Inspection

Check SSL Pinning implementation.

Failure to check the Certificate provided by the server and inadvertently accept any Certificate leads the application to be subject to a MITM attack through the SSL Proxy.

5. Third-party Data Transit on Unencrypted Channel

Apps sending data over unencrypted third-party channels resulting in unsecured data

M4. Insecure Authentication

1. Client Side Based Authentication Flaws – Bypass Authentication Schema

Application provides offline authentication function to be able to interact with internal functions after successful authentication.

2. Session invalidation on Backend

The application deletes the user’s sessions on the device, but does not cancel them on the server side. Thereby the attacker can still perform the actions as valid users through the emulation tools required.

3. Session Timeout Protection

Each application needs to protect users with server-side timeouts, to prevent an attacker from using existing sessions, from performing behaviors such as valid users.

After a period of inactivity (the device does not have to turn off the screen), the user must authen again. Length depends on security requirements.

4. Cookie Rotation

Make sure that the cookie reset is done correctly when there is a change to the authentication state. (Anonymous <=> User, User A <=> User B, Timeout)

Change Cookies when there is an authentication / authorize change

5. Using Device Identifier as Session

The application uses device identifiers such as IMEI and UDID to identify the user’s session, allowing an attacker to impersonate anyone by changing the identifier (session id). ) there.

6. Weak Password Policy

The application allows the use of accounts with weak passwords, which can easily let attackers detect, guess passwords, retrieve resources or hijack user accounts.

Password policy must be strong enough. Password security checks must be performed both on the client and the server.

7. No rate limit on Login

The Remote Endpoint has no mechanism against sending login credentials too many times

8. Weak biometric authentication

If the app has biometric authentication (fingerprint, face) then don’t use the APIs that simply return true / false. These APIs need to be based on the keychain / keystore unlocking

9. Not perform 2FA

The application should have 2FA functionality, and this should be done at the remote endpoint as well. Sensitive transactions require increased authentication.

M5. Insufficient Cryptography

1. Insecure Token Creation

The application uses insecure token generation, not enough length, low randomness – predictable, or uses algorithms that can be broken.

2. Use of Insecure and / or Deprecated Algorithms

The application uses insecure or outdated algorithms to easily detect the original of encrypted data such as: RC2, MD4, MD5, SHA1

3. Weak Custom Cryptography Methodology

The developer builds an encryption algorithm on his own, without using pre-supported strong encryption libraries, making it easier for an attacker to decompile the source code, breaking the application’s encryption method.

M6. Insecure Authorization

1. Missing function level access control / Bypass Authorization Schema

The application uses incorrect user authentication functions. An attacker can use functions from low-privileged users to higher-powered users, including administrative privileges.

2. Insecure Direct Object references

Objects use references to get values, but do not have exact authorization, resulting in information disclosure that the user does not have access to.

M7. Client Code Quality

1. Content Providers: SQL Injection and Local File Inclusion

With SQL Injection: The application uses SQLite to store the user data, but does not filter the input so that the attacker can perform accompanying queries to get information in the DB.

With LFI: The application provides file processing functionality, uses the library with unsafe settings, and does not filter the data before processing input inputs so that the attacker can browse / read. other folders or system files.

2. Insufficient WebView hardening / Javascript Injection / Malicious input from external sources

The application allows the execution of Javascript but does not filter the input data, making it possible for an attacker to execute malicious JavaScript to steal the user’s cookie / session.

All input sourced from outside the application and from the user needs to be validated and checked carefully to avoid injection and XSS errors.

3. XML Injection

The application allows the execution of Javascript but does not filter the input data, making it possible for an attacker to execute malicious JavaScript to steal the user’s cookie / session.

4. Abusing URL schemes or Deeplinks

The application uses the deep link defined in the source code so that when the user presses the URI, the OS will automatically call the App or Activity in the App. When clicking a URl, the Android system will do the following steps, sequentially, until successful:

  • Open default application according to user settings that can handle URL, if specified
  • Open the only application that can handle the URL
  • Allows the user to select an application from the dialog

5. Broadcast Thief

An unprotected public implicit Intent with permission types “Signature” or “SignatureOrSystem”.

A malicious BroadcastReceiver can read all public broadcasts of all applications.

Additionally, Hackers can initiate DOS based on ordered broadcasts by preventing the packet from broadcasting to the required receivers of the application based on their priority.

6. Build in wrong mode

App has not been built in release mode, lacks proper settings for release build (e.g. can’t run in debug mode; doesn’t reveal critical info, debug info,. all the foreseeable exceptions; …).

7. 3rd party services may be exploited by known vulnerabilities

Third-party components such as libraries, frameworks, not the latest versions can be exploited using published vulnerabilities.

8. Error handling logic in security controls

If there is an error in the access control process, it must be denied by default. Also handle errors in a controlled manner

M8. Code Tampering

1. Unauthorized Code Modification

Applications do not have mechanisms that detect themselves altered by patching techniques, so they can be infected with malicious code and security mechanisms are easily bypassed.

2. Runtime Manipulation

The application has no protection against hook tools, does not detect code or data that has been altered during the run.

M9. Reverse Engineering

1. Lack of Code Obfuscation

When the product is released, the developer does not use Code Obfuscation techniques, making it easy for an attacker to decompile the source code, clearly see the function names and easily guess the exact side functions. in, redraw the application execution flow.

2. Lack of Root Detection

Risks when using Rooted devices. There is no mechanism to detect or prevent running on the root device.

3. Lack of Emulator Detection

The application does not have a detection and response mechanism when running on virtualization and emulator programs.

4. Device Binding

The application implements device binding using an identity certificate made up of unique features of each device.

That cookie / data only works with the device used from the beginning, if it is transferred to another device, it cannot. Use the device UUID to check.

M10. Extraneous Functionality

1. Lack of Anti-Debugging Method

The developer does not use anti-debugging techniques, making it possible for an attacker to perform data analysis techniques during application execution, thus finding encryption keys or important variable values ​​of the application, thereby serving other extraction methods

2. Passwords / Connection String disclosure

Identify sensitive information (Credential) between mobile and API Hidden and Unscrutinised functionalities

Hidden functions are not present in the UX / UI but exist, leading to an attacker using them and getting information, back-end tests, demos, staging, or UAT environments.

Share the news now

Source : Viblo