How it all started

The road to protecting Android has been thorny. At the end of 2021, Android devices had over 2.5 billion active users, representing about 75% of the global market. This OS has been rapidly developing since 2008 and has undergone many changes. This also applies to the security system.

It all started with basic things. Such as screen PIN, running the application in an isolated environment, specifying certain permissions in the application's configuration files. Now it is a multi-level device protection, both hardware and software.

Android uses the Linux kernel, so its architecture and all the mechanisms used are very similar.

At the kernel level , additional functions were added, as well as security measures were strengthened, for example, regarding the use of IPC interprocess communication tools (only sockets are supported in Android) of the so-called Binders; additional settings have been implemented in the SELinux policy to restrict access to network sockets with certain privileges. 

At the application level, a division is made into read-only system applications and read-write user applications that run in their sandboxes with well-defined rights.

The principle of separation of application privileges and the principle of least privilege are the most important aspects in the Android security model. Permissions are requested by applications through their declaration in the AndroidManifest.xml file. This file is a description of the basic information about the system application. Based on the permissions specified in the manifest, the system decides whether such rights can be granted.

Development of security in Android

The use of rights restrictions in applications was not enough to protect against malware - Google continues to tighten measures. The differentiation of rights at the OS level is undoubtedly effective, but not flexible, since all applications may need completely different settings that the user wants to customize as quickly as possible. The first attempts at flexible separation of powers were made in Android 4.3 through the App Ops section .

In App Ops , the user could revoke and turn off anything. However, this was the most ineffective for him. The application could "fall" even after the recall of something minor. Android 6.0 fixed this “little” annoyance: now the application requests permissions at the moment when it needs them. 

It seemed like a good solution, but an even bigger vulnerability opened up. It is worth changing the version number in the assembly rules to an older one, and the application will receive all the permissions at once. They wanted to do it safely, but it was not possible to implement this idea to the end. “We shouldn’t bend under the changing world, let it bend under us,” thought Google, and with a strong-willed hand cut off the publication of applications for outdated OS versions. Now, starting with Android 10, the powers of the software for older versions are revoked, the application simply does not work. In the 11th version, it became possible to make permission for a single launch. 

Gradually, Google introduces restrictions on the types of permissions and device information that an application can receive: 

• With Android 8 , it is no longer so easy to get to the serial number of the device, some system variables become unavailable;  

• Android 9 prohibits the use of cameras and a microphone when the application is in the background, and you can not use HTTP without TLS; 

• Android 10 introduces restrictions related to accessing the location, launching activities by background applications, which can cause problems, for example, when running smartwatch applications. It is important that from the 10th version, full disk encryption is mandatory . For convenient and flexible permission management, a permission manager was also introduced, which allows you to configure each application in a granular way.

• In Android 11 , access to the memory and camera becomes more complicated, additional settings for managing connected smart devices appear in Smart Lock: this function is able to independently determine the need for increased security.

Gradually, more and more there is a tie to various encryption keys that represent critical information. For this reason, the Trusted Execution Environment is introduced . It stores this data and is itself a dedicated system, which allows you to avoid leaking keys when the main system is compromised. Also, to reduce the risk of system disruption, trusted boot is used , which checks the integrity of the OS when the device starts.

System innovations

The measures taken were not enough to protect against malicious applications, so since 2012, a system has been introduced to check downloaded software for suspicious behavior using static and dynamic analyzers, as a result of which SMS fraud and phishing are detected.

One of the latest innovations is the introduction of the SafetyNet check . SafetyNet is a set of APIs that allows applications to check a device for compromise. SafetyNet is vital for banking and financial software: it checks the originality of the device by serial numbers, the originality of the firmware, the presence of root rights, checksums, checking whether the device is trusted by its fingerprint.

The verification has been modified to provide a high degree of reliability for the client application when interacting with the server that serves the mobile application, and now the authenticity of the transmitted data is checked using a specialized key.

Using Certificates and Signatures in Android

Security mechanisms are being introduced not only with regard to the OS stuffing itself: developers must also follow the new Google requirements. For example, now you can’t just take and add a trusted certificate to the system or build an apk application without a specialized developer signature.

With regards to APKs, initially Google introduced the use of specialized cryptographic hashes and the signature of the developer, the hashes were counted on a part of the file. However, after the Janus attack , it turned out that not the entire file is used to verify the DEX file. Accordingly, it was possible to make changes to the unused part. The bug was fixed in the new digital signature format APK signature scheme v2 and v3 , now the digital signature applied to the entire file. It has become impossible to simply install an application from Apk. To pass all Google checks and its full functioning, it must be verified, and for this, the developer must have the appropriate key.

Starting with Android 10, some features of the mechanism for adding certificates to system certificates appeared. Prior to Android 4.0, there were only system certificates that were built into the system and users had no control over them. The only solution was to root the device and change the system folders with these certificates. Then it became possible to add user certificates. In Android, TrustManager is used to manage trusted data, in this case it will check the reliability of certificates. That is, now Android has system certificates (/system/etc/security/cacerts/), user CA certificates are stored in a specialized directory (/data/misc/user/0/cacerts-added). 

Adding user certificates is sometimes not enough to solve some problems, for example, if you need to proxy traffic, and you need to add a certificate to system certificates, which is difficult in the latest versions of Android. According to the latest developer guidelines from Google, there are network settings requirements that prevent the application from trusting user certificates: they are kind of trusted, but not very much. This requirement applies specifically to application network traffic. In the case when access to the organization's website with a self-signed certificate is required, user certificates can also be used. Returning to the issue of adding certificates to the system storage, a problem arises - the FS section where system certificates are stored is mounted in read-only mode, so it's not that easy to add a certificate. This has become especially difficult since Android 11 and even 10. The complexity is related toFDE (Full Disk Encryption), since the mounting process occurs after the disk is decrypted at boot time.

Tips for attackers: How to add read-only certificates to system directories?

Adding a user certificate to the system ones means changing the system directories, which is prohibited. The only way to get around this is by rooting your phone. After that, there are two paths: short and pleasant vs long and a bit hardcore. I'll start with the second one:

1. After the phone is hacked, it becomes possible to change the system files. Therefore, the section with trusted certificates can be changed, the only thing is that you will need to remount the system so that the added certificates are pulled up. Therefore, after the standard installation of a user certificate, the magic sequence of commands and rebooting the device will lead to the successful completion of the operation.

adb root # run as root 

adb remount # puts the system partition into read-write mode

adb ls /data/misc/user/0/cacerts-added # view certificates, user 

adb pull /data/misc/user/0/cacerts-added/cert.0 # pull the added certificate from the device to the computer 

adb push cert.0 /system/etc/security/cacerts/ # push certificate from PC to device

2. An easy way is to use the Magisk AlwaysTrustUserCerts plugin . He will do everything himself. All you need to do is install the certificate and reboot your phone. And voila - the certificate will be in the right store.
   
   As mentioned above, there is a SafetyNet check that is sensitive to whether the phone is compromised. That is, it checks for root rights. A pentester needs to proxy traffic, that is, a trusted system certificate is needed, therefore, root rights are required. However, in this case, a check will not be carried out, since the integrity of the device has been violated, which means that the application will not work. There is a way out - you can use Magisk hide and set Burp to ignore requests for Google.

Developer Tips: How to try to protect your app from hackers

That is, you can bypass all protection systems and proxy traffic. How then to protect your application? SSL Pinning comes to the rescue . Certificate pinning is the implementation of an SSL certificate used on the server into the mobile application code. In this case, the application will ignore the device's certificate store, relying only on its own store, and will allow a secure SSL connection to the host signed only by the certificate stored in the application itself. This is implemented due to the fact that the application checks certificates from the pin list. 

There are several ways to mount them there: 

1. With the help of TrustManager , a certificate file is added to the application files, a KeyStore is created to store the application keys. Further work is carried out through the TrustManager, which will access the KeyStore, where the certificate itself is located. TrustManager will only work with this certificate and check if it matches. In other words, if traffic is proxied, corresponding errors will appear. 

2. Another approach to implement pinning is to use the OkHttp CertificatePinner library , which contains a constructor that fixes a specific certificate fingerprint for a domain. This certificate thumbprint is embedded in the code. 

3. The last method is Network Security Configuration , where, just like in the previous method, the fingerprints of the certificates used are fixed.

And again the heading "advice to attackers"

Unfortunately for developers and fortunately for pentesters, and this can be bypassed, for example, using Frida , only very carefully . Using Frida and Magisk Hide in the wrong order can damage your device and cause nothing to work. The fact is that both programs use the same zygote64 process to inject into the running application code. Their conflict can break the bypass of SSL Pinning, and the hiding of root rights, this is where SafetyNet will catch us.

***

Android has come a long way in terms of changes and improvements. The system has become much more secure. Today it is no longer a "leaky" system, but a strong competitor to other mobile operating systems, and you need to learn how to work with it.