Some time ago, in jtsec, we started developing a tool which may be of use to users of all skill levels to improve the quality of their smartphones security. Our efforts have yielded its results and we are proud to announce the first version of Android Security Configuration Tester (ASCT).
Android Security Configuration Tester (ASCT) comes to cover the current need of grating a certain level of security in the field of Android devices in an easy and intuitive way. This tool comprehends checks for both new security technologies present in the most modern devices and classic protections that are still in use. The analysis is completed by carrying out scans in both the realm of Android OS and the underlying Linux system. Summing up, it aims for providing the user with attainable, specific and complete information which may be of use in a later deeper analysis.
ASCT is a joint of scripts written in bash. Each of these scripts carries out specific verifications on particular security mechanisms, providing the user with precise and useful information. In this way, the analysis is done through several stages, each of them related to a specific element critical to an Android device’s security.
Firstly, each application is extracted, considering that they are stored in /system/app and /system/priv-app. These applications are then decompiled using apktool and processed following a series of criteria that allow for verifying up to what point they are safely executed. First, a static analysis is carried out in order to spot vulnerabilities and suspicious behaviours. Then, each app manifest is analysed while searching for the permissions it uses and whether it shares ID with other applications.
Once the analysis is complete, a full search is made through the filesystem in order to spot files with special permissions. In Linux systems, these permissions (setgid, setuid, sticky bit) are generally used to allow specific behaviours, for example, the one that is used in the /tmp directory in which every user may edit files while only the owner has the permission to delete them. Nevertheless, if they are not properly used, these permissions may lead to security holes. In this way, the tool gathers information on the files with this kind of permissions and reports them to the user.
The third stage is based on the Linux protection systems which are also available in its Android version: Kernel Module Signing and Security Enhanced Linux (SELinux).
First, Kernel Module Signing is a protection based upon a series of parameters which determine if the modules signature is being checked and, if so, how strictly. ASCT checks the presence and values of all these parameters which are used during bootup. The following picture shows the most common variables that are set to activate this protection.
On the other hand, a series of verifications are carried out on SELinux configuration. SELinux is an additional access control mechanism that is found in Linux systems and which has been incorporated recently as an Android security measure. In the same way as with Kernel Module Signing, checks are made in order to guarantee that SELinux configuration follows the recommended scheme ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index). Once these verifications are done, and following the established recommendations, the system processes are check to assure that the only one running in the init domain is the init process itself.
In this same fashion of process checking, the user is prompted with a list of process that are executed with elevated privileges, so that they can be checked as well. These processes are the only part of the Android ecosystem that may grant an attacker with root privileges and their analysis is particularly relevant.
In a fourth stage, the tool makes an analysis of the state and type of encryption present in the device, as well as the checks on the related configuration options. The encryption parameters shall inform the user about the encryption state of their data and report whether the hardware-based protections are properly configured.
Once this verification is done, ASCT analyses the Address Space Randomization Layout (ASLR) paying attention to different factors. First, in the same way of the previous checks, the ASLR parameters are checked in order to assure its proper configuration. Then, a series of checks are carried out in order to grant the actual randomisation of the address space. Finally, the compilation mode of the binaries contained in the device is check to make sure that they are prepared to make use of this mechanism.
In a last stage, a check is carried out on the parameters that activate and are used as configuration for Android Verified Boot(https://source.android.com/security/verifiedboot/). The presence of AVB aims to grant that all the code that is executed in the device comes from trusted sources by establishing a chain of trust which is based on a hardware key.
Summarising, Android Security Configuration Tester covers every key point on granting the security of an Android Device when it comes to correct configuration and provides the user with useful information which may be used to perform further analysis.
In jtsec we are very proud to announce the first steps of our new tool, which comes to join repertoire and which will be available to our clients in order to improve security at all levels.
