How to develop secure applications for Android. Yandex Workshop
The proportion of users who use mobile devices in their daily lives is steadily increasing. Most of these devices are smartphones and tablets based on iOS, Android and Windows. Mobility, specific features of user interaction with the device and new operating systems are the factors leading to the emergence of unusual problems associated with information security. We will consider a part of these problems, their solutions, and in practice we will make sure that the development of tools for analyzing mobile applications is not that difficult.
Let's start with the fact that we list a few characteristic features for most mobile devices that may affect safety as well:
So what risks do these features generate? Miniaturization leads to the fact that the device is easy to lose, after which it could potentially be in the hands of an attacker. The mass and ease of monetization makes the device attractive to intruders. Just forcing the phone to send an SMS to a paid number, you can get a good profit. A large number of users also means that the percentage of not very technically competent users is large enough. The versatility of mobile devices means that they can store almost the entire range of personal information that can be used: contacts, correspondence, photos, videos, passwords and tokens from various important services up to banking clients. A permanent connection to the network is an additional risk, since attackers do not need to gain moments to attack.
Unfortunately, due to the fact that the mobile device market has experienced such an explosive growth, security guards have slightly fallen away from the opposing side, so now there is almost a race for survival between them and the attackers. It is not simple. The devices produce dozens of different vendors, they run different platforms, they install a huge number of applications, many of which have vulnerabilities. All this creates a huge number of problems.
')
Of course, mobile platform developers are aware of all these risks and try to provide protection against them. Consider what levels of protection are in Android. Firstly, there is protection from physical access: PIN, passwords, biometrics, strokes. However, there is a very specific biometrics, and with passwords and strokes there are certain problems: when entering, there can be noticeable traces on the screen that can be used to recover what was typed.
However, protection is, and often works. For applications there are also several levels of protection. First, applications almost always have unique UIDs and are launched by separate processes and in an isolated virtual machine. An interesting feature of Android is the non-dynamic application privileges: all accesses are requested during installation. Those. the user is immediately familiar with what applications can access. On the issue of file system security, Android developers have come quite strictly. The system partition is mounted in read-only mode, the distribution of privileges and rights in file systems is done almost manually, since version 3.0 file system encryption has appeared. I will give an example of the init.rc script for android versions 4.x:
This is only a small part of the script, but it is clear that the rights to files and folders for critical parts of the system are arranged very carefully. Access to them from the attacker should not be.
The developers also took care of the possibility of encrypting traffic by implementing SSL. However, there is one specific feature. Android has a repository of root certificates, and if you look at the dump of this repository, you can find an interesting thing: in addition to the root certificates of well-known certification authorities, there are some rather strange certificates. For example, the certificate of the Japanese government:
The same certificate is from the government of China. So, being in Japan or China, you can become a victim of a man-in-the-middle attack . Fortunately, in the fourth androids, the built-in storage can be disabled.
As I said above, the privilege mechanism in Android is quite clever. The developers initially identified API calls that can provide certain risks and divided into groups: access to the camera, bluetooth, geolocation, messages, calls, networks. To use these APIs, the application must explicitly request access to them during installation. The mechanism is flexible and convenient, but not devoid of some of the problems that developers sometimes face. The fact is that this mechanism is not well documented, just a few lines describe each resolution. And developers are very often faced with the fact that the created application does not work due to lack of permissions. Many do not understand, but simply request as much as possible permissions. Everything starts to work, but at the same time the application has access to completely unnecessary things, which is extremely negative for security. Understanding this problem, Google has provided a grant to outside researchers for a more detailed description of the API.
So, we came to the conclusion that the operating system is still relatively secure. What could be the problem? Often problems arise through the fault of the users themselves. There are many ways to break the system protection on their own, without the intervention of intruders. The first is jailbreaking. On android it is made surprisingly easy. Often, you can simply choose in the bootloader what to load instead of the usual operating system kernel. This allows you to completely kill almost all defense mechanisms. Often users use too simple passwords that can be easily cracked by intruders. Sometimes users put strange applications from untrusted sources. In principle, a Trojan horse can be acquired even on Google Play, but when installed from third-party stores or from pirated sites, the likelihood of such an outcome increases significantly. Often, users forget to disable the debug mode on the device, which allows not only to quickly install the jailbreak, but also to quickly pull out all the data, having received physical access to the device. However, in modern versions of Android, there are fewer problems with the debug mode.
Unfortunately, problems arise not only through the fault of users. The reason may be the developers. First of all, problems arise when developers do not fully understand how their application functions on a mobile platform. It is very often possible to see such a limited worldview, when a developer imagines some abstract device on which his spherical application works in a vacuum, with which only the user interacts. This is too one-sided picture. For example, it does not take into account that an attacker can gain physical access to the device. Much of the application interacts with the server backend, the security of which many people forget. Often it is not taken into account that the application may interact with other installed programs that may be malicious. Yes, and with the device, applications interact not directly, but through frameworks, execution environment, libraries, OS. There may be vulnerabilities in each of these components. And these vulnerabilities can be very low-level: in the kernel, in the drivers, in the shells of the vendors.
Applications may also have problems. Many developers allow their applications to store data not only in their isolated part of the file system, but also in shared storage (for example, on an SD card). By allowing confidential user data to be saved in this way, the developer creates a serious vulnerability. Another potential bait for attackers is to transfer data through open channels, or via SSL, but without checking the certificates. For mobile devices, almost the entire set of vulnerabilities of their big brothers is also relevant. Many people forget about this and do not sanitize user input. Using WebView to display information, you can also get a whole bunch of attacks. Android-specific problem - the transfer of sensitive data to log files. Users often do not pay attention to the request to read the system log files from the application. And developers often forget to release minimized debugging information in the release logs. Because of this, very important information may be recorded there. For example, tokens that attackers can use.
Sandbox application is not a panacea against attacks. The application cannot work in complete isolation; it must have interaction points, both with other applications and with the operating system. Interprocess communication in android is quite flexible. For example, your application may contain such functionality as content providers, allowing third-party applications to access data. There are also services, activities and Broadcast receivers that can access messages circulating inside the operating system. In fact, if these components are not protected by privileges, as is often the case, some third-party code can access them. As a result, some application can perform actions that should not be available to it. Let's say your application has access to read and send SMS. If you forget to restrict access to content providers, anyone can read user messages without having the necessary privileges.
Let's move on to the practical part. Content providers allow you to access information through a universal interface, this is an abstraction of the database cursor. For example, the address book is available as a content provider. Access permissions may not be set to read or write, which allows an attacker to view or enter some critical information. To identify such vulnerabilities there are several software tools. As examples, I would like to mention Mercury , the development of the company MWR, and its standalone CPA utility. If you aim to write such an application yourself, you can understand the following. Since many things are recorded when you install the application, data on content providers is very easy to extract. They are registered in the application manifest, content providers are registered, respectively, information about them is available through the standard android package manager. It contains information both about the way in which the content provider is available and about the privileges. Accordingly, I use my utility to extract this data and give the opportunity to select any of the content providers. Naturally, the unprotected ones are of interest. Then you can try to transfer data to the content provider, or get it to read any file. The results can be quite unexpected. For example, on Samsung Galaxy S smartphones there is a biometric screen lock, which is removed when the user brings the camera to his face. This application puts along with itself content provider com.sec.provider.facekey.
He has no privileges for reading and writing. If you try to contact this provider using the
The closest scientific and technical seminar in Yandex will be held on June 10th. It will be devoted to the topic of recommender systems and distributed algorithms .
Let's start with the fact that we list a few characteristic features for most mobile devices that may affect safety as well:
- miniature;
- mass character;
- universality;
- storage of important data for the user;
- permanent connection to the network (GPRS / 3G / EDGE / WiFi).
So what risks do these features generate? Miniaturization leads to the fact that the device is easy to lose, after which it could potentially be in the hands of an attacker. The mass and ease of monetization makes the device attractive to intruders. Just forcing the phone to send an SMS to a paid number, you can get a good profit. A large number of users also means that the percentage of not very technically competent users is large enough. The versatility of mobile devices means that they can store almost the entire range of personal information that can be used: contacts, correspondence, photos, videos, passwords and tokens from various important services up to banking clients. A permanent connection to the network is an additional risk, since attackers do not need to gain moments to attack.
Unfortunately, due to the fact that the mobile device market has experienced such an explosive growth, security guards have slightly fallen away from the opposing side, so now there is almost a race for survival between them and the attackers. It is not simple. The devices produce dozens of different vendors, they run different platforms, they install a huge number of applications, many of which have vulnerabilities. All this creates a huge number of problems.
')
Android security
Of course, mobile platform developers are aware of all these risks and try to provide protection against them. Consider what levels of protection are in Android. Firstly, there is protection from physical access: PIN, passwords, biometrics, strokes. However, there is a very specific biometrics, and with passwords and strokes there are certain problems: when entering, there can be noticeable traces on the screen that can be used to recover what was typed.
However, protection is, and often works. For applications there are also several levels of protection. First, applications almost always have unique UIDs and are launched by separate processes and in an isolated virtual machine. An interesting feature of Android is the non-dynamic application privileges: all accesses are requested during installation. Those. the user is immediately familiar with what applications can access. On the issue of file system security, Android developers have come quite strictly. The system partition is mounted in read-only mode, the distribution of privileges and rights in file systems is done almost manually, since version 3.0 file system encryption has appeared. I will give an example of the init.rc script for android versions 4.x:
... # create data/gps for GPS demon mkdir /data/gps 771 gps system chown gps system /data/gps chown gps root /sys/class/sec/gps/GPS_PWR_EN/value chmod 660 /sys/class/sec/gps/GPS_PWR_EN/value # for sensor control chown system input /sys/class/input/input0/enable chown system input /sys/class/input/input0/delay chown system input /sys/class/input/input0/wake chown system input /sys/class/input/input0/data ... This is only a small part of the script, but it is clear that the rights to files and folders for critical parts of the system are arranged very carefully. Access to them from the attacker should not be.
The developers also took care of the possibility of encrypting traffic by implementing SSL. However, there is one specific feature. Android has a repository of root certificates, and if you look at the dump of this repository, you can find an interesting thing: in addition to the root certificates of well-known certification authorities, there are some rather strange certificates. For example, the certificate of the Japanese government:
... Alias name: 123 Creation date: 30.08.2011 Entry type: trustedCertEntry Owner: C=JP,O=Japanese Government,OU=ApplicationCA Issuer: C=JP,O=Japanese Government,OU=ApplicationCA Serial number: 31 Valid from: Wed Dec 12 18:00:00 MSK 2007 until: Tue Dec 12 19:00:00 MSK 2017 ... The same certificate is from the government of China. So, being in Japan or China, you can become a victim of a man-in-the-middle attack . Fortunately, in the fourth androids, the built-in storage can be disabled.
As I said above, the privilege mechanism in Android is quite clever. The developers initially identified API calls that can provide certain risks and divided into groups: access to the camera, bluetooth, geolocation, messages, calls, networks. To use these APIs, the application must explicitly request access to them during installation. The mechanism is flexible and convenient, but not devoid of some of the problems that developers sometimes face. The fact is that this mechanism is not well documented, just a few lines describe each resolution. And developers are very often faced with the fact that the created application does not work due to lack of permissions. Many do not understand, but simply request as much as possible permissions. Everything starts to work, but at the same time the application has access to completely unnecessary things, which is extremely negative for security. Understanding this problem, Google has provided a grant to outside researchers for a more detailed description of the API.
Users and Android
So, we came to the conclusion that the operating system is still relatively secure. What could be the problem? Often problems arise through the fault of the users themselves. There are many ways to break the system protection on their own, without the intervention of intruders. The first is jailbreaking. On android it is made surprisingly easy. Often, you can simply choose in the bootloader what to load instead of the usual operating system kernel. This allows you to completely kill almost all defense mechanisms. Often users use too simple passwords that can be easily cracked by intruders. Sometimes users put strange applications from untrusted sources. In principle, a Trojan horse can be acquired even on Google Play, but when installed from third-party stores or from pirated sites, the likelihood of such an outcome increases significantly. Often, users forget to disable the debug mode on the device, which allows not only to quickly install the jailbreak, but also to quickly pull out all the data, having received physical access to the device. However, in modern versions of Android, there are fewer problems with the debug mode.
Developers and Android
Unfortunately, problems arise not only through the fault of users. The reason may be the developers. First of all, problems arise when developers do not fully understand how their application functions on a mobile platform. It is very often possible to see such a limited worldview, when a developer imagines some abstract device on which his spherical application works in a vacuum, with which only the user interacts. This is too one-sided picture. For example, it does not take into account that an attacker can gain physical access to the device. Much of the application interacts with the server backend, the security of which many people forget. Often it is not taken into account that the application may interact with other installed programs that may be malicious. Yes, and with the device, applications interact not directly, but through frameworks, execution environment, libraries, OS. There may be vulnerabilities in each of these components. And these vulnerabilities can be very low-level: in the kernel, in the drivers, in the shells of the vendors.
Applications may also have problems. Many developers allow their applications to store data not only in their isolated part of the file system, but also in shared storage (for example, on an SD card). By allowing confidential user data to be saved in this way, the developer creates a serious vulnerability. Another potential bait for attackers is to transfer data through open channels, or via SSL, but without checking the certificates. For mobile devices, almost the entire set of vulnerabilities of their big brothers is also relevant. Many people forget about this and do not sanitize user input. Using WebView to display information, you can also get a whole bunch of attacks. Android-specific problem - the transfer of sensitive data to log files. Users often do not pay attention to the request to read the system log files from the application. And developers often forget to release minimized debugging information in the release logs. Because of this, very important information may be recorded there. For example, tokens that attackers can use.
Sandbox application is not a panacea against attacks. The application cannot work in complete isolation; it must have interaction points, both with other applications and with the operating system. Interprocess communication in android is quite flexible. For example, your application may contain such functionality as content providers, allowing third-party applications to access data. There are also services, activities and Broadcast receivers that can access messages circulating inside the operating system. In fact, if these components are not protected by privileges, as is often the case, some third-party code can access them. As a result, some application can perform actions that should not be available to it. Let's say your application has access to read and send SMS. If you forget to restrict access to content providers, anyone can read user messages without having the necessary privileges.
Content Providers Analysis
Let's move on to the practical part. Content providers allow you to access information through a universal interface, this is an abstraction of the database cursor. For example, the address book is available as a content provider. Access permissions may not be set to read or write, which allows an attacker to view or enter some critical information. To identify such vulnerabilities there are several software tools. As examples, I would like to mention Mercury , the development of the company MWR, and its standalone CPA utility. If you aim to write such an application yourself, you can understand the following. Since many things are recorded when you install the application, data on content providers is very easy to extract. They are registered in the application manifest, content providers are registered, respectively, information about them is available through the standard android package manager. It contains information both about the way in which the content provider is available and about the privileges. Accordingly, I use my utility to extract this data and give the opportunity to select any of the content providers. Naturally, the unprotected ones are of interest. Then you can try to transfer data to the content provider, or get it to read any file. The results can be quite unexpected. For example, on Samsung Galaxy S smartphones there is a biometric screen lock, which is removed when the user brings the camera to his face. This application puts along with itself content provider com.sec.provider.facekey.
He has no privileges for reading and writing. If you try to contact this provider using the
* from sqlite_master-- , the result will be quite unexpected. Rather, it will be unexpected for those who think that SQL injections are only in web applications. This query allows you to get acquainted with the entire database, I will really have a SQL injection. And we see there an amusing table called facefeature, which has fields for “face features” and “face image”. You can access them directly and get the encoded data. Thus, having no privileges, we get access to the user's biometric data.The closest scientific and technical seminar in Yandex will be held on June 10th. It will be devoted to the topic of recommender systems and distributed algorithms .
Source: https://habr.com/ru/post/225543/
All Articles