Mobile application security breaches as a result of insufficient attention of developers

In the second half of 2017, developers downloaded approximately 2,800 applications on Google Play every day. According to the AppStore, data has not yet been found, but is unlikely to be many times smaller. Each of these applications contains a certain amount of data (data) that is stored or transmitted via cellular and Wi-Fi networks.

A source

Obviously, the data of mobile applications is the main goal of attackers: they not only steal them, but also manipulate them in their own interests . It also poses a number of problems, such as fake and alternative (often unreliable) applications, malware, data leakage, weakly protected data or data protection errors, as well as tools for accessing and decrypting data.

A little bit about yourself

My name is Yuri, I’ve been dealing with issues in various areas of information security for 10 years, including privacy and data leakage. Areas of practical interest are mobile security, cloud computing, forensics, and security and access management. For the past 7 years, I have been speaking at domestic and international conferences (CyberCrimeForum, HackerHalted, DefCamp, NullCon, OWASP, CONFidence, Hacktivity, Hackfest, DeepSec Intelligence, HackMiami, NotaCon, BalcCon, Intelligence Sec, InfoSec NetSysAdmins, etc.) where I offer you attention examples of insecurity and consequences, and I ask them to think a little more about data security.

How developers can affect security

There are many different opinions regarding the developer’s impact on security.

1. "The developer does not always respond in a timely manner to security reports that highlight application deficiencies."
2. “The developer did everything in his power to ensure security, so any problems that arise are only due to user actions” (This can continue until the situation is made public, often with the involvement of journalists, and the effect will not last long)
3. “You should stop blaming developers for all the sins of security ” (appeared relatively recently). In other words, developers are not the only ones involved in creating an application or product.
   For example, there are testers and product managers. At the same time, everyone fulfills his role, which in total allows one to verify the general security of the solution being developed. Opinion was published in the article about a year ago. The clause on separation of duties by role was repeated several times in paragraphs and supplemented by the conclusion that security problems always occur when someone develops a prototype into a commercially successful product. But the separation of roles implies a division of responsibility, so claims about application security may not reach their destination. Such statements reduce attention to security, and developers do not feel responsible for this until the information about the problems becomes public.
   Developers have always been and will be the first to work with applications and can immediately fix problems in them and make them more secure. Early activity also helps developers maintain an adequate level of security. However, users should keep in mind that there is a developer-independent time frame for troubleshooting. So, if the developer just wants to update the application, he creates a new assembly, sends it to the application store and waits for the moderators to approve it (it takes several days), then you need to wait for the applications to update if the automatic update on the user's device has been turned off. Thus, the developer partially controls the process. The question arises, is it worth cultivating and encouraging such delays? This is counterproductive because the developer

It seems that everything is in best practice, but a closer look is a disaster ...

People have many needs (personal, professional, workers); two or more devices and, as a result, more than one service provider and dozens of applications to meet their needs. Despite such flexibility and variety, different software has many common properties. For example, the same technologies for storing, transmitting and protecting data, even taking into account different implementations, may have similarities at the level of architectural features.

As for security mechanisms, some of them are already working by default and do not require developer intervention, while others are vice versa. For example, SSL / TLS, which is used in many applications, is vulnerable to Man-in-the-Middle (MITM) attacks when it comes to improper implementation. At the same time, iOS 10 (and higher) and Android 7 (and higher) already have mechanisms for preventing MITM attacks, which also help to avoid government interception of data from countries such as Kazakhstan and Thailand.

Moreover, these mechanisms are enabled by default, regardless of the actions of the developer, but are implemented differently. Android also has a completely independent mechanism, and iOS is managed, which allows you to activate the operation of third-party SSL certificates.

In addition to network problems, there are problems with locally stored data (internal memory of mobile devices). Most applications actively use local storage for cached data, optimizing network usage and quick access to user data (conversations, files, multimedia, etc.). Many of these applications often store user data without protection or the protection is too weak, for example, the secret key is next to the data encrypted on it.

This hole in the fence even has its own page on Wikimapia.

But there are still specialized forensic solutions in which the results of studying these problems are actively embodied in the form of programmed methods for accessing application data and separately stored user data. And the presence of various security problems often makes data extraction easy and comfortable.

4-year data security audit results

The following figures summarize the results of a study of the problems of security mechanisms for local and network data. Only those mechanisms that are implemented in the considered applications are described. In other words, if, for example, data encryption is not implemented, then no information is provided.

• Without protection - data is stored or transmitted without any protection and encryption, "as is, in the clear."
• MITM without a root certificate (absent in the above examples, but until the spring of 2017, AeroExpress was such an example) - the ability to intercept data with any fake certificate.
• MITM + root certificate - MITM attack is possible when an attacker uses a special certificate, incl. fake / stolen root SSL certificate to intercept and decrypt traffic. Cases when the user is forced to install on their own can be related to the recommendation of the developers, the need to meet the requirements of a particular state (for example, the aforementioned Kazakhstan or Thailand.
• SSL Pinning ( here or here ) - A MITM attack is not possible if the device has not been hacked (there is no jailbreak or root), taking into account the features of the previous paragraph.
• Strong protection - in a general sense, the application is protected from attacks and requires considerable effort to obtain data; it should also be understood that HTTPS technology is not used. This is important because applications actively and overwhelmingly use HTTPS due to the ease of implementation and server support. Along with this, there are a large number of data interception tools that are designed specifically for the problems associated with HTTPS.
• Inclusion in the backup - allows you to access duplicate data (less than or equal to 100% of the stored application data) using various programs, including forensic decisions without the need to have a device with a jailbreak or root. There is application data - they are stored in the working folder of the application. Some of this data is included in the backup. At the same time, where the developer will put the data: in the folders synchronized to the backup or not, this is a question for the developer (therefore, 100% duplication of data in the backup can be achieved. It is believed that access to the backup is easier to get without root and jailbreak than to perform root and jailbreak (on new devices, on old ones it doesn’t matter).

Brief explanation of data type:

• All data - account information, credentials, chats, application and user databases, configuration and cached data - everything that the user saw in his application among his data and documents.
• Media data - all data, including photo, video, audio information (except media streams).
• Geo Docs data - geolocation associated with user documents, files and notes, such as coordinates, location description, address, city, etc.
• Location address data - geolocation that is not tied to specific data elements, but also representing coordinates, location description, address and city, etc.
• Social credentials - username / email address, password or token instead of password (the most common implementation), related to social networks Facebook, Twitter, LinkedIn, etc.).
• Photolocation - information about the place and address, with photos of this place, for example, the image of the building at the address X.
• Information about the application is all that is available in the application settings within the application: changing passwords, setting up credit cards, choosing trusted friends to access a lost account.
• Account media - multimedia files related to the accounts of the owner and his friends, in other words, profile images and a cached image (for the further purpose of storage on the device).

Indicative problems

Insecure data storage

A large number of applications for storing credentials, geolocation or banking information uses the “store in open form” approach. For some people, this may mean uninstalling the application as soon as this becomes widely known.

Mixing data between applications (each application may contain different data) usually indicates that there is a possibility of compromising additional user accounts. For example, an application that is not a social network may have authorization through social networks, and the credentials used (for example, login and token with OpenID) will be saved in open form.

Unsafe communication

Even in the examples reviewed, developers of half of the applications do not follow safe recommendations regarding the correct implementation of security mechanisms. SSL is the most popular communication method for various applications, and each security manual states that you need to check certificates, including the root certificate, to prevent data from being compromised. However, the lack of proper protection often helps to intercept mobile application traffic.

Data leaks

Many popular mobile applications, especially games, often collect a huge amount of personal data to profile and personalize the device owner. This includes data such as age, gender, geolocation, activities on social networks, habits (favorite routes, places visited, music, culinary preferences) and much more. In this case, it is likely that at least 2, 3 or 5 applications disclose the maximum amount of user information. Nevertheless, the collection of such information is in violation of the requirements of many documents and safety recommendations, taking into account the goals and functions of the application. The problem is compounded by the fact that user agreements often do not reflect the essence of defense mechanisms or protected data or have inaccuracies. And nobody reads them.

Habravchane, tell your friends that it is worth restricting access of applications to personal data using operating systems, check installation permissions and read descriptions in markets, as well as reviews of security specialists

Third-party code

Using third-party libraries helps speed up development and take advantage of the experience of other developers in your own application. However, this experience includes all problems, including security issues. This practice can actually, from a security point of view, divide protection into two or more parts: the same data type, for example, a password, will be found in several places (different user scenarios) and with a different level of protection (similar to Facebook).

Delayed Security Patch

Creating an application and its appearance in the market does not mean that the development cycle is completed. On the contrary, developers are just starting to add new functions, fix security errors, inadvertently introduce new security errors, delete old functions, etc., which gives attackers the opportunity to not only detect, but also effectively use the problems that arise.

In the long run, there is no reliable application

Each application can be reliable, weak or unreliable at any time. In addition, application updates violate the idea of ​​getting a “fix” for each next version (the new version may be less secure than the old one), and for some applications updating is required. In practice, actual security concerns continue to be ignored.

As a result, security errors are generated that allow attackers to compromise users again and again. It seems that the more experienced the development team, the less such problems should be in the final product. But, having studied popular applications, we will not see such a thing. This is because they are focused on the work product as the primary measure of progress, i.e. performance is an indicator of success. At the same time, using examples, it is possible to make sure that developers can still create reliable applications and keep them up to date in terms of security, using the right tools and sets of requirements.