Smartphone users are exposed to various threats when they use their phones. These threats can disrupt the operation of the smartphone, and transmit or modify user data. For these reasons, the applications deployed there must guarantee the privacy and integrity of the information they handle. Mobile security involves protecting both personal and business information stored on and transmitted from smartphones, tablets, laptops, and other mobile devices. Mobile security has become increasingly important in mobile computing because of the day-to-day increase in sophisticated attack methods.
Nearly 85% of the smartphones in the world are run by Android OS. Therefore securing Android devices has become a major concern. The University of Cambridge concludes its finding by stating that “on average 87.7% of Android devices are exposed to at least one of 11 known vulnerabilities.”
All smartphones, as computers, are preferred targets of attacks. These attacks exploit weaknesses related to smartphones that can come from means of communication like Short Message Service (SMS, aka text messaging), Multimedia Messaging Service (MMS), Wi-Fi networks, Bluetooth, and GSM, the de facto global standard for mobile communications. There are also attacks that exploit software vulnerabilities from both the web browser and operating system. Finally, there are forms of malicious software that rely on the weak knowledge of average users.
Vulnerabilities present in Android devices can be found by doing Android Application Testing. By knowing the vulnerabilities and the attack vector we can secure our Android devices from such malicious attacks.
Let us understand how vulnerabilities are identified through Android Application Testing. Few security vulnerabilities that are found during testing are shown with Screenshots for your better understanding.
Insecure logging happens when developers intentionally or unintentionally log sensitive information such as credit cards, debit cards, or any such sensitive information.
From a security point of view, it is advised not to log sensitive data like user logins, etc. in logcat.
Below is a demonstration of data being logged in logcat.
Sometimes android applications disclose sensitive information as they are hardcoded into the application for certain reasons. Generally, developers do this for easy access. When an application wants to be tested prior to being released the developers will hardcode the strings so that they can easily access it. But when debugging is not disabled, then it will create a serious security problem.
The below example shows the hardcoded vendor key, a secret code to access a beta application been disclosed from one of the source files.
Hardcoding text attributes directly in layout files is bad for several reasons:
OWASP lists “Insufficient Transport Layer Protection” as risk number three. When designing a mobile application, commonly data is exchanged in a client-server fashion. When this data is exchanged it can traverse both a carrier network and the internet. For sensitive data, if the application is coded poorly, threat agents can use techniques to view this sensitive data while it’s traveling across the wire. You don’t want passwords, credit card numbers, or other sensitive data traveling without some sort of encryption, generally HTTPS. To handle HTTPS correctly you must also learn to code options around certificates in your mobile applications.
The following example reads data using the HTTP protocol (versus using HTTPS).
Input validation vulnerability in Android is a kind of severe vulnerability in Android apps. It occurs when inputs are not sanitized or filtered it is recommended to validate user inputs. A malicious attacker can exploit the vulnerability to bypass the Android security mechanisms and compromise the integrity, confidentiality, and availability of Android devices.
In this case, we can read internal files as there is no input validation. So our app takes an input which is basically a URL field so we will be trying to read files using file URI scheme file://host/path
so try to read .uinfo.txt which was storing info in our last demo