42.84% of Android devices tested are vulnerable to CVE-2015-3864. Although Google issued an update to the Hangout app that disabled automatic processing of media files, we know that CVE-2015-3864 can be exploited remotely and reliably via the browser. The number of Android devices is estimated to be between 1.4 and 2 billion. Scaling our statistics to the global status of all Android users, we estimate that between 599.76 million and 856.8 million devices are currently vulnerable to CVE-2015-3864.
In July, Zimperium uncovered set of vulnerabilities in libstagefright and thsmre rest is history. Vendors promised us updates for Stagefright. We launched Zimperium Handset Alliance, ZHA , where about 30 vendors and carriers can communicate. Google started to maintain monthly releases of updates . Samsung and other vendors followed . All of this, and most users are still not receiving any updates.
After Zimperium zLabs announced Stagefright, we released the free Stagefright Detector app. We know that many users received updates, but not all users. We also know that multiple groups or individuals had successful attempts at predicting or bypassing ASLR  and were able to exploit Stagefright vulnerabilities remotely. On March 4th, Northbit, released a research report that describes how to bypass ASLR when exploiting mediaserver (and libstagefright) vulnerabilities.
The following statistics do not contain the recent vulnerabilities fixed by Google in the March update. We can safely assume that the very most of the devices that did not receive an update over the last month, are vulnerable to CVEs like:
These issues are just two examples that could allow remote code execution via mediaserver. In order to bypass SELinux, attackers would need to chain one of the two above vulnerabilities with a kernel exploit. One candidate for such exploit could be obtained by exploiting the recent vulnerability fixed in an emergency patch released on March 18th after Zimperium reported a 0day exploit being used in the wild to Google.
Other interesting vulnerabilities that were published recently are:
These are information disclosure vulnerabilities and could potentially leak sensitive information like addresses. Such vulnerabilities could help bypass ASLR and allow reliable exploitation via stagefright-like vulnerabilities.
Over half a million users downloaded Stagefright Detector. The results are nothing less than fascinating. Since users continue to download Stagefright Detector over time, in many cases users were already patched for some of the vulnerabilities, yet it is interesting to see how many of these users got patched over time, and in which countries.
On the bright side, if we exclude the two vulnerabilities with the highest percentage of devices still vulnerable, CVE-2015-3864 and CVE-2015-6602, between 67.59% to 89.87% were patched against the first and second batch of Stagefright vulnerabilities.
When examining the risk on a country by country basis, some vendors and carriers deserve the “Delivered an update against all chances” award and some vendors/carriers deserve the “Don’t care about about the users’ security” award.
Regression following an update
We observed other trends – for example, some vendors shipped updates with regression that exposed the users to one of the CVEs that the same vendor patched in the previous release.
For example, Sony users with build 23.4.A.1.200, after updating from 23.4.A.0.546 got re-exposed to:
Motorola devices updating from LXB22.46-28.1 (5.0.2) to LPB23.13-56 (5.1) got re-exposed to CVE-2015-3876
Samsung devices updating from LRX21T (5.0) to LMY47X (5.1.1), got re-exposed to CVE-2015-3876
Samsung devices updating from KTU84P (4.4.4) to LRX22G (5.0.2) got re-exposed to CVE-2015-3876
Asus devices updating from KVT49L (4.4.2) to LRX21V (5.0) got re-exposed to CVE-2015-1538,
LG devices updating from KOT49I (4.4.2) to LRX22G (5.0.2) got re-exposed to cve-2015-6575-1
HUAWEI devices updating from HUAWEIGRA-L09C02B120 (5.0) to HUAWEIGRA-L09C02B191 (5.1.1) got re-exposed to CVE-2015-6602
We noticed that after some of these regressions above, many vendors started to use Zimperium’s Stagefright Detector app to verify that there is no regression prior to sending a new build out as an update.
New Stagefright vulnerabilities
When we look at newer Stagefright vulnerabilities, the status is a alarming. Every month Google releases an update and other vendors follow (well… sometimes). Once such an update is available, only a small set of devices receive the update. Google will attempt to fix it with Android N, but it will take a few years before the entire ecosystem will be running Android N+. In addition, due to the large number of Android vendors and hardware manufacturers, creating updates will remain a non-trivial process, especially when drivers need non-trivial security patches.
Once a generic exploit is public
One potential scenario could be a worm spreading by way of mild social engineering. Such a worm would likely infect users by sending links through SMS, MMS, Instant Messages, or e-mail. If a user were to click the link, they would be taken to a malicious web server that exploits Stagefright via the browser. There are two other serious types of attacks that could leverage Stagefright vulnerabilities and don’t require user interaction.
The first potential scenario is a watering hole attack. Such an attack would aim to compromise mobile devices that visited a trusted but compromised site commonly used by a targeted group.
The second methodology involves MITM. These attacks could be executed via Wi-Fi access points, rogue base stations, or other compromised on-path systems.
Remediation, protection and recommendations:
Organizations, Carriers and Vendors: We detect exploitation of Stagefright vulnerabilities and can work with your teams to enable immediate detection. We can also block Stagefright exploits delivered via MMS. Contact us via [email protected] to discuss.
Carriers and IM vendors: We advise carriers and IM vendors to be prepared to block SMS messages with links in the event that a worm begins spreading.
Follow Zuk Avraham (@ihackbanme)Oren DB
Follow Oren DB (@noy_oren)Joshua Drake
Follow Joshua Drake (@jduck)Nikias Bassen
Follow Nikias Bassen (@pimskeks)Yaniv Karta
Follow Yaniv Karta (@shokoluv)