Top 7 Vulnerabilities in Android Applications

Android application vulnerabilities have become a problem because of Google Play’s open format, and also because users can sideload apps, removing any oversight regarding the safety of apps.

There are also updates and patches to the Android operating system. You can’t count on Android to update itself in a timely manner, because wireless carries control update schedules on all but Google’s Pixel devices.

Expert testing of Android mobile applications shows that in most cases, insecure data storage is the most common security flaw in android apps.

According to a report, Vulnerabilities and Threats are slightly more common in Android applications, compared to their iOS counterparts(43% vs 38%). But the experts categorize this difference as minimal: the security level of apps is roughly equivalent between the two platforms.

Comprehensive security checks of a mobile application include a search for vulnerabilities in the client and server, as well as data transmission between them.

Android App Vulnerabilities

Mobile apps are seeing huge growth in development. Many of these systems have a client-server architecture. The client runs on the Android or iOS operating system, which is most widely used. This client is downloaded from the app distribution sites to the user, where developers are publishing their wares.

As viewed from the user’s point of view the mobile program is the client installed on the smartphone. The user communicates with that to make transactions, pay bills, or read emails. But there’s actually another aspect as well: the server, which the developer hosts.

Current smartphone operating systems come with complex security mechanisms. By default, an installed device can only access files in its own sandbox folders, and user rights do not allow files to be modified from the system. Nonetheless, developer mistakes in developing and writing code for mobile apps create security vulnerabilities and attackers can exploit them.

A mobile application’s extensive security tests include a scan for client and server vulnerabilities, as well as data transfer between them. We will address risks to users including risks from contact between the client and server sides of mobile apps.

What are the two models of interprocess communication? what are the strengths and weaknesses of the two approaches?

There Are Two Aspects:

Client-Side vulnerabilities

60% of vulnerabilities are on the client side

89% of vulnerabilities can be exploited without physical access

56% of vulnerabilities can be exploited without administrator rights

Insecure interprocess communication(IPC) is a common critical vulnerability allowing an attacker to remotely access data processed in a vulnerable mobile application.

Android provides Intent message objects as a way for application components to communicate with each other. If these messages are broadcasted, any sensitive data in them can be compromised by malware that has registered a BroadcastReceiver instance.

Developers should use LocalBroadcastManager to send and receive broadcast messages not intended for third-party applications.

Server-Side Vulnerabilities

Server-side components vulnerabilities both in application code and in the app protection mechanisms. The latter include flaws in the implementation of two-factor authentication. Let us consider one vulnerability our experts encountered in an application. If two identical requests are sent to the server one right after the other, with a minimal interval between them, One Time Passwords (OTP) are sent to the user’s device both as push notifications and via SMS to the linked Phone Number. The attacker can intercept SMS messages and impersonate the legitimate user, for instance, by cleaning out the user’s bank account.

It is not necessary to send one-time passwords twice in both SMS messages and push notifications. Instead, use the passwords twice in both SMS messages and push notifications. Instead, use the password delivery method selected by the user.

The average server-side component contains five code vulnerabilities and one configuration vulnerability. Configuration flaws include disclosure of sensitive information in error messages, fingerprinting in HTTP headers, and TRACE availability.

Top 7 vulnerabilities

It’s not logical to order the top seven list of vulnerabilities. These are encounter by either severity, impact, or prevalence, as these vulnerabilities found can cause problems for an organization in terms of data loss, sharing private information, or other areas ripe for exploitation by hackers. Here are the Top 7 vulnerabilities, and the solution for how to avoid them:-

1- Binary Protection:

Insufficient Jailbreak / Root Detection. Rooting or jailbreaking a device circumvents data protection and encryption schemes on the system. When a device has been compromised, any form of malicious code can run on the device, which can significantly alter the intended behaviors of the application logic. Recovery and data forensic tools generally run on rooted devices as well.

Recommendation:
With regards to security, it is best to not have the app run on rooted or jailbroken devices, or to at least do some form of root/jailbreak detection. Detecting whether a device has been compromised adds an extra layer of policy enforcement and risk mitigation to protect the data within the application from being exposed.

2- Insufficient Transport Layer Protection:

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption must be used for all authenticated connections, especially Internet-accessible web pages. Backend connections should be encrypted as well, or risk exposing an authentication or session token to malicious actors on the same network as the application host. These backend connections may represent a lower likelihood of exploitation than a connection over the external Internet; however, their impact in the case of exploitation can still result in a compromise of user accounts or worse.

Recommendation:
Encryption should be used whenever sensitive data, such as credit cards or health information, is transmitted. Applications that fall back to plaintext or otherwise be forced out of an encrypting mode can be abused by attackers.

Ensure the application has a security constraint that defines confidentiality and integrity-based secure transport guarantee. This will ensure that all data is sent in a manner that guarantees it cannot be observed or changed during transmission. If TLS must be terminated at a load balancer, web application firewall, or other in-line hosts, it should re-encrypt the data in transit to the target host(s).

3- Insufficient Authorization/Authentication:

Insufficient Authorization results when an application does not perform adequate authorization checks to ensure that the user is performing a function or accessing data in a manner consistent with the security policy.

Authorization procedures should enforce what a user, service, or application is permitted to do. When a user is authenticated to a website, it does not necessarily mean that the user should have full access to all content and functionality.

Recommendation:
Enforce a proven authorization framework scheme that emphasizes policy-based configuration files over hard-coded authentication/authorization checks wherever possible.

4- Cryptography-Improper Certificate Validation:

This application is either not validating SSL/TLS certificates or is utilizing an SSL/TLS certificate validation system that will not correctly verify that a trusted provider issued the certificate. The client should be configured to drop the connection if the certificate cannot be verified, or is not provided. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.

Recommendation:
Ensure that your application’s certificate validation is configured to correctly verify that certificate is provided, and from a trusted source like a reliable Certificate Authority. Or, code-in the latest certificate transparency standards approved by IETF or the CA/B Forum.

5- Brute Force – User Enumeration:

There are numerous ways for an attacker to determine if a user exists in the system is; a brute force attack is a method to determine an unknown value bypassing an automated process to try a large number of possible values. The attack takes advantage of the fact that the entropy of the value is smaller than perceived.

For example, while an 8-character alphanumeric password can have 2.8 trillion possible values, many people will select their passwords from a much smaller subset consisting of common words and terms.

If error messages change when the username and/or password are submitted incorrectly, an attacker can determine the existence of a valid username/email address based on any differences in the error messages.

Recommendation:
The user enumeration vulnerability typically occurs in the following functionality: Login, Registration,
or Forgot Password. The application should not reveal whether a username is valid. The response to valid and invalid input in either field should be completely identical.

For example, instead of “Sorry, your password is invalid”, a proper response might say: “Sorry, your username or password is incorrect. Please try again.”

6- Insufficient Session Expiration:

After a user signs out of an application, the identifiers that were used during the session are supposed to be invalidated. If the server fails to invalidate the session identifiers, it is possible for other users to use those identifiers to impersonate that user and perform actions on his behalf.

Recommendation:
First, it is a best practice to ensure a logout button is implemented in the application; and second, when the user clicks this button their session is properly invalidated.

7- Information Leakage- Application Cache:

Sensitive data can be leaked from application caches, either through the main application code or via third-party frameworks. Mobile devices present a unique challenge with regards to secure data storage. The devices can be easily lost or stolen. Many users do not lock their devices. The cached data can be viewed by an attacker who is performing data forensics on the physical device.

Recommendation:
Ensure the sensitive data is not accidentally leaked through the cache. Developers can prevent it by creating a threat model for OS, framework, and platform to check and verify the way data is handled during URL caching, keyboard press caching, logging, copy or paste caching, app background, browser cookies objects, HTML5 data storage and analytic data that is sent to the server or another app.

FAQs