Android Rooting and Real World Security Threat
Author: Marco Beierer (email@example.com)
Advisor: Ulrich Fiedler
Bern University of Applied Sciences
January 14, 2014
Android is currently the most widely used operating system for smartphones. One reason for the success of Android is the openness of the system. An open system has lots of advantages for the users as well as the hardware manufacturers. However, the openness also has its price and brings some risks for the users. The advisor of this project, Mr. Ulrich Fiedler, wants to demonstrate the rooting methods and the security risks of Android to his students and business partners. The latter has the goal to raise their awareness for security risks on the Android platform.
The given assignment consists out of three parts. The first part is to have a look at the current situation of the Android smartphone market and to determine which Android smartphone models are currently the most widely used. The second task is to discuss the advantages and risks of rooting an Android device, as well as to classify and describe the common rooting methods. The third assignment is to construct a real world scenario to demonstrate a possible threat. At the end of the project there should be a final report summarising the results and two screenplays which describe the demonstration of rooting a smartphone and the real world thread.
The time scope of the project is one semester. Thus nearly a half year from mid September 2013 to mid January 2014. The needed equipment for the investigation and preparation of the screenplays is provided by Mr. Fiedler.
2 Android Market Research
In this section I will have a look at the market share of Android devices in Switzerland and research which devices are currently the most widely used and sold. Because of the dynamic in this fast changing market, it would make sense to only look at the numbers of the last year.
Because the most manufactures and telecommunication companies are interested in keeping there sales figures secret, it would be difficult to determine an accurate list of the best selling smartphones. In the following subsections I present some ideas about possible sources and if it was possible the receive reliable numbers from them.
2.1.1 Internet Research
During an Internet research I couldn't achieve lots of useful information. The most available information was older than one year and thus not representative for the current market. Also the information found was mostly about the market share of the different operating systems or the manufacturers. Information about the devices was not publicly available. Maybe one market research company have done such a survey and compiled a report, but this report was just available for the subscribers of the company. Also the report was about one year old and does thus not represent the current situation.
There was no information available about the specific situation in Switzerland.
2.1.2 Contact to Telecommunication Companies
After the Internet research I tried to write an email to the three leading telecommunication companies in Switzerland and asked them about there sales figures. To write an email to Sunrise was not as easy as I thought, because there was no email address available on the website and firstname.lastname@example.org was deactivated. Swisscom and Orange had at least an address of the press relations team published on their website. From Orange I got the information that they don't share any information about their sales. Swisscom needed some time, but they finally sent me a list of the most sold smartphones in 2013. They provided no precise numbers, but at least I know that Swisscom sold the Samsung Galaxy S4, S4 mini, S3, S3 mini and the HTC One the most in 2013.
2.1.3 Survey in Retail Stores
Another idea was to do a survey in the retail stores of the telecommunication companies. Because it is really difficult to receive representative numbers from this surveys I decided to pass this idea. I thought the numbers would hardly depend on different coefficients which I could not control. For example the location of the shop and thus the properties of the surrounding residents. It would only make sense if I made an survey in all stores which sale smartphones in at least one city, which was not practical.
2.1.4 Survey of Computer Science Students
Another possibility was to do a survey under the Computer Science students of the Bern University of Applied Sciences. But this approach had the same disadvantages as a survey in the retail stores, the results wouldn't be representative.
2.1.5 Bestseller and Top 10 Lists
One of the best information source were the best selling lists of online shops. Many online shops provide the ability to order the products by sales figures and this information could be used to compile a list. However this information has also some disadvantage. For example if an smartphone is available in multiple colors the sales are distributed over multiple entities.
Some online stores, especially the shops of the telecommunication companies, only mark some phones as bestsellers. This information is also valuable, but has the disadvantage that we do not know, if they are really bestselling or if it is just a marketing trick. However, because of the currentness of this information, I gave them a higher weight than the best selling lists. Also if it is just a marketing trick, the changes are good that they sell better because of the trick and thus the information gives some indication.
2.1.6 Google Trends
Another source of information is the data provided by Google Trends. Google Trends is a tool which allows the user to compare the frequency of multiple search strings. The presented data is normalised and thus very useful to compare multiple smartphone models. However, also this source has some disadvantages. You never know exactly, why somebody searches a specific phone. For example a phone which causes lots of difficulties is maybe more often searched than a better model with the same sales figures, because the users are looking for solutions. However, if you look for the search term "HTC One", the term "HTC One problems" is not included in the data and thus the data is relatively accurate, because the most people with problems define there problem in the search term. Another flaw of the data provided by Google trends is that some models have very similar names. For example the newest model of HTC is called "HTC One", but there are older models, which are called "HTC One S" or "HTC One X". The same is true for the Samsung Galaxy series.
Google Trends allows to filter the results by country and thus to only show the numbers of Switzerland. It is also possible to filter by search engine, thus it is possible to get the numbers of the web search and the shopping search separately.
To compile a list of the best selling smartphones in Switzerland I used a mix of different methods described in the section "Ideas". I have determined the best selling smartphones by using a weighted matrix.
First all smartphones best selling in 2013 by Swisscom got one point, which was weighted with 20%, because this information is very precise and fresh. Then I had a look at the Top 10 lists of Brack.ch and Interdiscount.ch. The Top 10 smartphones got between 0.1 and 1.0 points, respectively to their rank. This information was weighted with 10% each. At last I gave each phone, which was marked as bestseller in the online shops of Swisscom, Sunrise, Orange and melectronics one point. This points were weighted with 15% each.
From this information I have compiled a list of the Top 5 smartphones in Switzerland, which were the HTC One (0.74), Samsung Galaxy S4 (0.75), Samsung Galaxy S3 (0.40), Samsung Galaxy S4 mini (0.35) and the Samsung Galaxy S3 mini (0.21). To confirm and stabilise the results, I compared the named models with Google Trends. The subtotal score was weighted with 60%, the average of the web search and the average of Google Shopping in the last 12 months with 20% each. With the additional data the result changed slightly and the final rank was as following:
- HTC One (0.634)
- Samsung Galaxy S4 (0.588)
- Samsung Galaxy S3 (0.464)
- Samsung Galaxy S4 mini (0.216)
- Samsung Galaxy S3 mini (0.140)
3 Android Rooting
Rooting an Android device is interesting for two different groups of people. On one site it is interesting for the user itself, because he could get more control over the phone and do tasks with the phone which are not allowed or possible with an unrooted phone. Restrictions on an unrooted phone may occur because the manufacturer does not like the user to do some things or because there are security restrictions. Beside the user also an attacker may be interested in gaining root access. If an attacker could achieve root access he could do whatever he wants on the victims phone without asking permission to do sensible actions or access secret data.
3.1 Advantages of rooted Smartphones
For the user a rooted smartphone could have lots of advantages and gives him full control over the phone. It is for example possible to customise the look and feel of the user interface, uninstall unwanted applications of the manufacturer or provider which were shipped with the phone or tune the phone for better speed and battery life. There are also applications available, which are just running on a rooted phone. For example automated backup applications, ad blocking applications or applications for using wireless tethering even if not allowed by the telecommunication provider.
A nice and detailed top 10 list of things to do with a rooted phone is available on lifehacker.com.
3.2 Risks of a rooted Smartphone
As seen above a rooted device has lots of advantages, however it also brings some risks for the user. One risk is that the user gives applications permissions to do everything on the device. The default permission system has no effect for applications which are granted root access. And because many applications which are providing additional features are closed source, there are just limited ways to control what they are really doing under the hood of the phone. There are applications which at least give the user the control over which applications are allowed to gain root access, but if these applications have security vulnerabilities it is maybe possible to bypass the restrictions and every installed application is able to gain root access easily.
There are further risks, but they are specific to the used rooting method and are thus discussed in the sections below.
3.3 How Rooting works
The process of rooting itself is very straightforward. It is just necessary to copy a su binary to one location which is set in the systems PATH variable and make the su binary executable. The difficulty is to gain the permission to do so. There are two different ways to achieve this goal and root a phone: It is rather possible to exploit a security vulnerability (for example a privilege escalation) on the running system or to flash a modified ROM to the device.
3.4 Classification of Rooting Methods
As noted in the section above, there are two methods to root a smartphone. Both methods are described in detail in the following subsection.
3.4.1 Custom ROM Flashing
The first method is to flash a ROM with a modified operating system, which already contains the su binary, to the device. In the most cases a ROM with an aftermarket Android distribution like CyanogenMod is used. The most alternative distributions are heavily modified and provide additional features for the smartphone out of the box.
The biggest challenge of this method is to circumvent the boot loader of the device. The most manufactures ship their phones with a locked boot loader, which means that just ROMs which are signed by the manufacturer are runnable on the device. This is a security function but also an attempt of the manufacturer to gain control over the software and apply restrictions. In earlier days the most boot loaders were locked and it was thus necessary to find a security vulnerability in the firmware to unlock or replace the boot loader. Today many manufacturers accepted that the users like to customise their phone and thus officially provide a method to unlock the boot loader.
188.8.131.52 Advantages and Disadvantages
The biggest advantage of flashing over exploiting is that the root access is permanent. The disadvantage is that updates must be shipped by the ROM provider which is often a private person or group which is not interested in long term support of a free ROM.
One risk of rooting a phone by flashing is that it is necessary to trust the ROM provider. The ROM provider may have not just added the su binary, but also added a backdoor which allows him to fully control the device over the network or use it in his botnet.
A further risk is to loose the warranty of the phone. Using a custom ROM is not allowed by the most manufacturers and if a user violates this rule, he looses the warranty. This is also true if the manufacturer provides an official method to unlock the boot loader. It is also not possible to unroot the phone before using the warranty because many devices have a counter build in which increases every time a new ROM is flashed to the device and a violations to the warranty terms is thus easily detectable.
It is possible to unroot a rooted device by flashing a recovery ROM provided by the manufacturer of the device. The process is the same as for rooting the device originally, just with another ROM.
3.4.2 Soft Flashing
Soft flashing is for users who like to keep the factory ROM provided by the manufacturer of the device nearly untouched. With soft flashing just the needed su binary is added to the stock operating system and a root control application is installed. Soft flashing shares the risks of the custom ROM flashing method.
For soft flashing it is necessary to flash a custom recovery image to the smartphone. When the phone is booted into recovery mode, a script is executed, which copies the su binary and the root control application to the devices main operating system. When both components are copied, the original stock recovery image is installed again and no traces (except an incremented flashing counter) are left.
To unroot the device it is just necessary to delete the su binary. This could be done with some root control applications, like SuperSU.
Exploiting is a softer method than flashing because the root access is just gained temporary and normally gained through a special one click application. The application tries the exploit known security vulnerabilities in the operating system to copy the su binary.
The challenge of this method is to find an applicable security vulnerability in the system which could be used to execute the process. Because a security vulnerability is of course also risky for the user, they are normally closed after time. Especially if a privilege escalation or other high impact attack is possible through that vulnerability. It is also difficult to achieve that the su binary survives an update of the manufacturer. It is thus necessary to develop a new exploit for every release of the operating system and it is impossible to stay up to date and have root access at the same time.
Exploiting is especially interesting for criminals to gain full access to a device through a malicious application offered for example in an application store. Exploiting is interesting for them, because many old phones run an outdated version of Android and are thus vulnerable to security vulnerabilities which were closed in newer versions of the operating system. Currently (October 2013) only 1.5% of the Android users are using the latest available Android version .
One risk of gaining root by exploiting is that the security vulnerability normally stays open after rooting because it is not possible to update the operating system without loosing root access. This means that every application or attacker could theoretically exploit the used vulnerability. Because there is the risk that it is not possible to gain root access again after an update it is likely that many users never update their rooted device and thus are vulnerable to all vulnerabilities discovered after rooting.
Because rooting is not permanent it is normally possible to unroot by simply apply an update to the phone. Otherwise the su binary must be deleted or the execute permission must be revoked.
4 Android Real World Security Threat
The first idea was to develop a general scenario where an vulnerability in the Android operating system is exploited. But this was unfortunately not possible, because no vulnerabilities were publicly known at the time of investigation and to review the Android source code to discover a new vulnerability was probably not possible within the given time frame.
The alternative idea was to develop a scenario of industrial espionage where costs and time are not limited. In the scenario a secret agent gets in contact with a business man of the target company and tries to win some trust. When the business man is unaware of his phone, for example when he leaves his phone unattended on a table for a short time, the secret agent should be able to unnoticeable install a hidden system application on the smartphone in under five minutes. As trigger device for the installation a laptop or better another smartphone could be used. The installed application could for example redirect emails or use the microphone to eavesdrop business meetings of the victim. The scenario could for example play at a trade fair, at a business convention, at a advanced training seminar or in private at a sports club. The last example is just possible if the business phone is used in private or vice versa, but this is often the case in this day and age.
4.1 Technical Details
The technical realisation is based on the soft flashing method described in the chapter above. The soft flashing method works without problems with all smartphones with an unlocked boot loader or an at startup accessible download mode. For example the devices produced by Google and Samsung. For devices with a locked boot loader the unlocking part would be to time consuming for the given scenario and there are some additional barriers, like unlocking the lock screen, to take. However, it is possible with some effort, but first unlocking the boot loader is not in the scope of this project.
4.2 Proof of Concept
The public available soft flashing images normally used for rooting smartphones provide what is needed for a proof of concept. The rooting method is called CF-Auto-Root and developed by a Android hacker named Chainfire. The images are available for a range of smartphones. For the proof of concept the given images are manipulated so that a malicious application is installed in place of the root control application. This could be done by simple replacing the application in the images. The method is described in detail in the chapter "Soft Flashing" above. The proof of concept works without problems, but has the side effect, that also the su binary is installed. To get more control over the installation process it is necessary to build a custom recovery image to install an malicious application or do other modifications at the devices operating system.
4.3 Build a Custom Recovery
It is possible to build a custom recovery image for an Android smartphone because the source code of the Android project is openly available. Also the license agreement allows the modification of the source code. The source code is published under the Android Open Source Project (AOSP). However it is not that easy to build a functional firmware because the most device manufacturers do not publish the needed drivers for the smartphones. So it is necessary to collect all available data about the used hardware and research the drivers or in the worst case reverse engineer the drivers and rebuild them. Fortunately the CyanogenMod community and the communities of other aftermarket firmware distributions have done this already for multiple devices.
To build a working recovery image based on the CyanogenMod project it is necessary to setup an Android development environment and grab the code base of CyanogenMod including the customised recovery source code by ClockworkMod. Afterwards it is necessary to search for the device specific modifications and configuration files for the given smartphone as well as for the used board and integrate them into the Android source code. It may also be necessary to download and integrate the specific kernel source code. If everything is setup correctly, the recovery source code could be modified and an working image be built. For this project just some confirmation screens were disabled, so that the infection process runs smoothly without user interaction.
4.4 Prepare the Cache Image
Because of the limited size of the recovery partition, a second partition is used to store the data needed for installing the malicious application. As data storage the otherwise unused cache partition is used. To store data on the cache partition it is necessary to download it from the device, convert it to the ext4 file system and then simply mount it on the host computer. After manipulating the cache image, the image has to be converted back to the file system used by the smartphone. The needed tools are part of the AOSP.
For the installation of the malicious application we need an installation script, the stock recovery image and the malicious application itself. All three are stored on the cache partition. The installation script is stored as a file called "extendedcommand" in the folder "recovery". This file is automatically executed by the ClockworkMod recovery system when the user enters into the recovery mode. Within the script it is possible to call every function provided by the recovery system, like for example mount() or format().
4.5 The malicious System Application
The goal of the imagined attack is to install a malicious system application on the device. This application could do nearly everything with the device. Because it is not necessary to go through to default installation routine, the application could have any permission needed, without approval by the user. Using repeating scheduled tasks, broadcast receivers and an inconspicuous name, the malicious application could stay nearly invisible on the device. It is just listed in the list of all applications and not in the list of running or downloaded applications. Because it is an system application, it could also not be uninstalled by the user without root access. The user could just disable the application temporary.
The implemented example application sets up a repeating scheduled task at boot time. Then the application takes automatically pictures with the front camera every 60 seconds and sends the photos to an deposited email address. This all happens automatically without user interaction and without any visible feedback on the graphical user interface.
4.6 Flash Recovery and Cache Image to the Device
To install the malicious application it is necessary to flash the customised recovery and cache image to the smartphone. Therefore the application Heimdall is used. Heimdall is an open source flashing software for Samsung devices and available for multiple operating systems. It comes with a command-line and a graphical interface. To be able to flash the images, the smartphone has to be in the download mode. To boot into download mode, it is necessary to hold multiple buttons at startup time. The buttons are device specific. When the flashing process was successful, the phone automatically boots into the recovery system and executes the defined commands. First the malicious application is installed as system application and thus copied into the folder where the system applications are stored, then restricted permissions are set to the application file, so that the user is not able to simply remove the application. Afterwards the stock recovery is restored, so that the user does not recognise that somebody has manipulated his device. Finally, the cache partition is formatted. If everything went successful, the device is automatically rebooted into the default operating system. The complete process is normally finished in under one minute.
5 Results and Discussion
In the first chapter it is shown that the HTC One, the Samsung Galaxy S4 and the Samsung Galaxy S3 are the most popular smartphone on the swiss market as of today. In the second chapter rooting methods were classified into custom ROM flashing, soft flashing and exploiting. The advantages and disadvantages as well as the risks of each method were discussed. In the last part of the project a real world security threat scenario for Android smartphones was developed. It is shown that it is possible to arbitrarily manipulate and modify a smartphone if physical access is granted for about one to five minutes, even if no security vulnerability in the firmware is known.
The described application in the real world security threat scenario is very basic and just an example. It is possible to expand it and make the malicious application more evil or even modify the operating system itself to circumvent application restrictions. Currently there are also no persistence mechanisms implemented. It would be possible to install a daemon which checks at boot time if the application is still active and reinstalls it if not. It is also possible to implement capabilities to connect the phone to a command and control server and for example load and install additional malicious applications at any time after the infection. Another idea would be to modify the operating system, so that it hides the malicious application in the application manager and also if a shell is used to browse the file system. To improve the infection process it may be possible to port Heimdall to Android and use a smartphone instead of a laptop for the installation of the malicious application. This would allow to think about more scenarios to infect devices. It may also be possible to improve the infection time by reducing the weight of the recovery image. An advanced improvement would be to take a memory snapshot before the device is infected and restore the snapshot afterwards. So from an user perspective the phone in exactly the same state after the infection.
6 List of References
 Android Developers. October 2, 2013. Accessed on October 10, 2013. https://developer.android.com/about/dashboards/index.html