The Problem of Fragmentation on Mobile Platforms
Google has striven to reduce this problem with measures like Google Play Services, which allows updating of Google and Google Play applications without a need to update the whole operating system. Even so, as may be seen from the diagram below, Android users are still divided between five versions of the operating system.
This means that the performance of applications is different, depending on the version of Android with which they are run, and can even affect access to various characteristics or functions of the device in use. For this reason, Android applications are developed in a way that sets several parameters including MinSDKVersion, MaxSDKVersion and TargetSDKVersion. These are, respectively, the minimum version of Android compatible with the application, the maximum version of Android compatible with the application and the version that suits the application best, normally the one with which the application was tested.
From the point of view of user security, fragmentation involves a major problem. This is because most vulnerabilities that are identified are patched only for the latest version of the operating system, which leaves the majority of users of the platform at risk.
When it comes to iOS, this is not so extensive a problem, since as soon as Apple launches a new version of the operating system, only a short period of time goes by before the majority of its devices move to this version. It is true that there can be devices for which the new version is not available. Normally, these are items old enough to be considered as having reached the end of their useful life, which is not the case for Android devices.
The main reason for this fragmentation is that Google wanted Android to be present on the largest possible number of mobile devices. Hence, they made it open code, so that manufacturers could develop items incorporating the operating system, with responsibility for making new versions of the system available falling to them. A study by the OpenSignal company has verified the existence of more than 18,000 different models of devices including the Android operating system, which implied an increase of 60% relative to 2013.
This increase makes it highly unlikely that the objective of finding a solution for fragmentation is anywhere near being achieved.
As for Apple, since they are the only manufacturers of devices with the iOS operating system, they have more control both over physical equipment and over software updates.
The following is a list of some of the vulnerabilities in Android that are the biggest dangers and have not yet been patched in versions earlier than the most recent, which means for around 79% of users of the platform.
Master Key – Bug #8219321- CVE-2013-4787 – Duplicate File
As a preventive measure, Android requires all applications to be signed. This signature is intended to check the integrity of the APK (Android application package), as it contains the hash value for each of the files included in it. In this way, the Android application manager checks that these hash values are correct at the moment when the app is installed, thus ensuring that the APK has not been modified. Unfortunately, certificates are not subjected to obligatory checking by a certifying authority, but can be self-signed. This means that they are not a particularly secure safety mechanism.
In March 2013, researchers at Bluebox publicized a vulnerability known as Master Key, which was later discussed in detail in the presentation Android: One Root to Own Them All at the Black Hat U.S.A. Conference of 2013. The security failure allowed arbitrary code to be included in any APK signed by a developer without affecting the signature. To achieve this, it was necessary to include two files with the same name in the APK. In this way, Android verification affected only the first file, but the second was later executed.
To correct this fault, Google implemented a security measure which analysed all the names of files included in the APK. If any duplicate name is detected, an error message is displayed during the installation process.
This solution was brought in with Version 4.2 of Android. A cure for the problem for earlier versions had to wait for updates from device manufacturers, but checks have shown that more than a year and a half later there are some cases in which such updates have still not reached users. Researchers at SecLab and Duo Security produced a mobile application for rooted devices called ReKey which corrects the vulnerability, so that users do not have to wait for updates. To check if a device is affected, it is possible to use the Bluebox Security Scanner application available through Google Play. play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner&hl=es (Link currently unavailable)
Bug #9950697 – Name Length Field
This vulnerability was discovered by Jay Freeman (saurik), the developer of Cydia, at the beginning of November 2013. It is a variant of the Master Key problem described above. This fault is also related to the verification of APK signatures and affects all the versions of Android earlier than 4.4 (KitKat).
For a detailed analysis of the problem, see this researcher’s own blog.
To check whether a device is affected by this vulnerability, the application SRT AppScanner, available through Google Play, can be used. play.google.com/store/apps/details?id=de.backessrt.appintegrity (Link not available currently)
Heartbleed - CVE-2014-0160
At the beginning of April 2014, Google researchers published details of a vulnerability discovered in OpenSSL libraries. This vulnerability, known as Heartbleed, makes it possible to obtain sensitive information such as credentials or coded data from affected systems with the Heartbeat function activated.
To check whether a device is affected by this vulnerability, which can hit all versions of Android earlier than 4.3, it is possible to use the applications Bluebox Heartbleed Scanner play.google.com/store/apps/details?id=com.bblabs.heartbleedscanner (Link currently unavailable) Heartbleed Segurança Escáner available through Google Play.
Bug #9950697 - Extra Field
In early July 2014, a Chinese researcher announced a vulnerability in Android that allowed modification of the contents of an APK without altering the validity of its certificate. It is true that this vulnerability is difficult to exploit and occurs only in very specific cases (modification of classes.dex files that are smaller than 64kb in size). Nevertheless, it might permit an attacker to obtain sensitive information about the user affected.
Fuller details may be seen on the Sophos blog.
To check if a device is affected by this vulnerability, the SRT App Scanner application available through Google Play may be used.
CVE-2013-6272
At the start of July 2014, Curesec researchers publicized a vulnerability that affected all versions of Android before 4.4.3, thus more than 70% of the users of the platform. The vulnerability takes advantage of com.android.phone, an application that was specifically designed to allow access to premium-rate telephone numbers, to call such numbers without interaction with users, which could cause them serious monetary losses.
It is possible to check if a device is affected by this vulnerability by installing the application produced by Curesec for this purpose.
Fake ID – Bug #13678484
Towards the end of July 2014, researchers at Bluebox announced a vulnerability known as Fake ID, more details of which were given in the presentation Android Fake ID Vulnerability at the Black Hat U.S.A. Conference of 2014. The vulnerability has been hitting Android users since January 2010 and lies in the fact that the Android packet installer does not check the chain of certification. Thus, if the identity of the issuer of the certificate for an application is falsified, Android does not notice this and will take the certificate as valid.
This vulnerability affects all versions of Android, except 4.4 (KitKat), which was patched by Google.
As in the case of Master Key, a check on whether a device is affected can be made by using the Bluebox Security Scanner application available through Google Play. play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner&hl=es (Link currently unavailable)
CVE-2014-6041
Recently, the researcher Rafay Baloch, published a vulnerability that affects the default browser present in nearly 75% of Android devices. This vulnerability allows to avoid SOP (Same Origin Policy) policy, making possible both to obtain information of the other open pages in the browser and the cookies. If the latter aren’t protected it would be possible to use them to impersonate the affected users or hijack their sessions.
Apart from these vulnerabilities, account must be taken of faults caused by unsafe development of applications. Researchers at FireEye undertook an analysis of the 1,000 applications most often downloaded from Google Play. They assessed various aspects such as the validity of digital certificates by checking the certification chain (certificate pinning), verification of the connection host and SSL error management when Webkit is used as an engine to render web pages in an application, and instances of the development of applications with multi-platform frameworks like Cordova.
The following conclusions were reached:
- Of the applications analysed, 73% did not check certificate validity.
- Of the applications analysed, 8% did not verify connection hosts.
- Of the applications analysed, 77% did not manage SSL errors when Webkit was in use.
Similarly, as was also demonstrated by researchers at FireEye, most of the payment-handling libraries incorporated in applications in order to obtain financial benefits are out of date and vulnerable, and directly expose user information to Man in the Middle attacks
Conclusions
In view of the above, as has been stated on other occasions, it is Google, the body chiefly responsible for the development of Android, that must take the necessary steps and put in the effort needed to improve the platform’s security, since it has already reached 1,000 million active users and a market share of more than 87% in Spain. Such measures must include a reduction in fragmentation to the fullest extent possible. One major step in this regard is the launch of Android One, the Android operating system for low cost devices. For this version of Android, Google has accepted responsibility for sending updates directly to mobile devices, with no need for interaction on the part of their manufacturers, thus ensuring that the range of devices that incorporate it will not suffer from the acute problem of fragmentation.
Obviously, the ultimate responsibility falls on Google. However, it is the responsibility of everybody involved to take the appropriate steps to reduce the risks and failings of the platform:
Manufacturers of mobile devices should be more involved in the security aspects of the items they produce. They should act quickly and efficiently to provide updates for their devices.
Applications developers should adopt methods with the motto security by design, allowing assessment of the security of applications, as in the case of OWASP (Open Web Application Security Project) or OASAM (Open Android Security Assessment Methodology). As was indicated in the post on «secure development of applications for mobile devices», methods of this sort have the aim of identifying risks relating to the safety of such items and provide the necessary checks during development to reduce their impact and the likelihood that they might be exploited.
One further aspect of considerable importance that must be kept in mind by developers is that when a new application is being produced it is common to re-use code, as there is no point in re-inventing the wheel, after all. According to a report by the Codenomicon company published at the R.S.A. Conference U.S.A. 2014, between 80% and 90% of software developed for mobile devices is based on re-used code. In most instances, the security flaws that may be present in the re-used code are not taken into account. Hence, on many occasions it happens that neither developers nor end-users are aware of the faults that these applications include, so that users are at risk.
For their part, end-users should follow the advice that is offered on the website of the Spanish Web-surfer Security Office (Oficina de Seguridad del Internauta):
Tags: