Everyday, new vulnerabilities are discovered in mobile devices that can be exploited by intruders. They can send an SMS to a pay-per-call number, they can collect and sell a large database of contact details, and they can also compromise a specific individual. Successful exploitation of a vulnerability requires that a whole range of conditions are met. There is another way, however! Provide the user with a really useful application (a game with birds), whose manifest contains a list of device information that we are interested in. In this article, we will look at ways of obtaining and saving important information from an Android device.
Android OS architecture is built in a way that allows apps to exchange different kinds of information. An app which works with maps requires location, while a voice recorder requires access to the microphone. So, it all seems clear and transparent.
We openly write the required data or features in the application manifest and receive them upon installation. Nobody is being deceives, everything is voluntary. However, the problem is that users are highly illiterate as far as information technology is concerned. Few people wonder why the voice recorder, for example, needs their location or access to SMS. The application clearly declares its intentions in the manifest, and it would be strange to expect it to act differently.
Before the now famous disclosure, I understood that the game with the angry birds on your device is an informant, as, in addition to everything else, it wants to read the device ID and call data. A simple question “Why do you need this data?” reveals the true intentions of its creators.
When installing the application, the user either has to let it do anything it wants, or not have the application at all. Not many people will browse the store for an app with similar functions but fewer requests (there might not even be anything similar), so the users quickly develop the habit of pressing “yes-yes-yes” to all questions. Let’s accept that it is easy to get used to this, as for many years of living offline, users have developed the reflex to automatically sign multipage agreements on the principle “well, everybody signs it, there can’t be anything wrong with it. Anyway, I don’t have a choice, either I sign here or I don’t get what I want.”
If we remove all the application’s permissions, the OS, in order to prevent the app crashing, can simply give it empty values. The application can be deceived by providing it with knowingly false information (position of the North Pole) or simple zeroes. For example, the application may request a list of contacts on the device and the developer presupposes in its architecture that it can be empty (a brand-new device). There is nothing suspicious here; the data is saved and the application has not crashed.
Such tricks were necessary before Android 6.0 Marshmallow. It boasts a new mechanism for working with permissions and allows permissions to be granted and revoked when the application is working. For reverse compatibility of old applications (i.e. the ones whose targetSdkVersion is less than 23), an old mechanism for requesting permissions during installation has remained functional. Updated applications should request permissions when they are working. We can look at the app permissions in the application’s settings and revoke access if we so wish.
Let’s look at how this works on a device running Android 6.0.
Let’s install the birds but revoke all their rights before the first launch.
When the rights are requested during installation from Google Play, we can see that the app’s targetSdkVersion is less than 23.
The settings display tells us that the app creators have slightly more interest.
How about reducing them a bit?