Master Key vulnerabilities in Android: countermeasures and attempts to exploit

Part two. The first part is available here.

Risks associated with the vulnerabilities

Bluebox reported that the vulnerabilities could be used to attain root rights in the system providing a vast range of opportunities, from identity theft to creating a mobile botnet.

“While the risk to the individual and the enterprise is great (a malicious app can access individual data, or gain entry into an enterprise), this risk is compounded when you consider applications developed by the device manufacturers (e.g. HTC, Samsung, Motorola, LG) or third-parties that work in cooperation with the device manufacturer (e.g. Cisco with AnyConnect VPN) that are granted special elevated privileges within Android, specifically System UID access,”  Bluebox report.

Modifying the contents of such applications grants the attacker full control of all data on the device. And, in the case of corporate gadgets, the vulnerable device becomes a potential point of unauthorized access to the corporate network.

This is truly a joyless prospect.

Action taken

Google was immediately informed about both vulnerabilities and then from Google the information was spread on to its partners. The patches should have been deployed long before the information about the vulnerabilities was available to the general public. A patch for CyanogenMod was even released.

The Google Play Store introduced new rules prohibiting applications with both vulnerabilities, sorting them out at the validation stage. Unfortunately, the security filters are not always effective.

The discoverer of the vulnerability, Bluebox Company, released a special scanner for detecting vulnerable devices.

Security solutions developers surely took measures to protect mobile devices. In particular, our programs using data from Kaspersky Security Network identify vulnerable devices and applications that exploit these flaws. For more information see the article from our expert Stefano Ortolani on Securelist.com.

Does it mean that the threat is over? Yes, on the one hand it does, but on the other hand it does not.

Hackers are prepared

Despite all the measures taken, malware authors seem to have decided to quickly rewrite the malicious code that exploited the first of the two vulnerabilities described in the previous post. According to Jeff Forristal in Bluebox Security, it may be due to the fact that the official patch for the vulnerability had appeared in the open repository of Cyanogenmod, even before Google released it.

As I already mentioned, Bluebox Security informed Google of the master key vulnerability in February 2013. According to Google policy, information about flaws is published after 90 days to give the company’s partners time to take action. This time, however, the problem was serious enough for Google to release the patch and the information about the Android flaw after 150 days: the patch appeared in the Android Open Source Project on July 25.

This patch appeared in the repository Cyanogenmod on July 6. Cyanogenmod is based on the code published by Google, i.e. the patch first had to turn up in Android Open Source Project and only after that made it to the Cyanogenmod. Whatever the case, the patch was out and the attackers most likely refurbished it to produce the exploit that was detected first on July 23.

There are no grounds for backbiting Cyanogenmod. As Forristal remarked, the standard of Google’s “90 days of silence” were long gone, the pause had been sufficient, so the Cyanogenmod moderators had the right and the foundation to publish the information about patching the dangerous breach.

Interestingly, the hackers were pretty quick to write an exploit. If Forristal is right about abusers re-engineering the patch from the Cyanogenmod repository, then the criminals really did a good job in just seventeen days.

Android’s congenital problem

According to our statistics, 98.96% of malware for smartphones and tablets in the past year were written for Android, which was the attackers’ primary target. The core of the problem was, sadly, the decentralized approach to Google’s operating system. As Apple produces its own devices and develops the operating system, the Android gadgets are made by a large number of assorted manufacturers interested largely in consumers purchasing new devices. As a result, updating the firmware is difficult and installing newer versions of the operating system on older devices is not possible at all. But smartphone owners have no incentive to buy new devices as long as their old ones are functioning.

As a result, the statistics show that more than a third of Android devices run 2.3.x Gingerbread, released in early 2011. The shares of the newer versions 4.0 Ice Cream Sandwich and 4.1 Jelly Bean are respectively 23.3% and 32.5%, while 4.2.x Jelly Bean has just crossed the mark of 5.5%.

Not to mention, apart from the official Google Play app store, where incoming applications are checked for malicious content (although this test is sometimes far from perfect), there are many third-party stores without any restrictions and filters against infection. Naturally, applications exploiting these vulnerabilities appeared there as soon as the information had gone public. And don’t forget the numerous compromised devices with “pirated” applications installed.

Android OS is highly fragmented, it’s vulnerable, a large number of operating devices use its older versions, and it is extremely popular.

With this regard comes the question of Android devices within a corporate environment if a company follows the Bring Your Own Device (BYOD) paradigm. The superficial decision is obvious: “zero tolerance,” mandatory isolation of the user and corporate data, maximum prevention of any intrusion from a mobile device into the corporate network, obligatory implementation of mobile devices security solutions – last spring we published the detailed article on the risks of BYOD, providing a number of tips on controlling personal mobile devices within corporate networks and protecting data.

The aforementioned master keys are just another reminder of the issues brought up by insufficient attention to protecting data. No software developer is immune to mistakes, even critical ones. Always keep that in mind and be on alert, especially when there are many ways to reduce the risks and not become a victim of hackers.