Share this blog
Special thank you to Marina Caro who assisted in writing this blog.
Patching alone isn’t enough to fix vulnerabilities
Almost all mobile devices have at least one app with a critical vulnerability. Even if a patch is available, that critical vulnerability can leave the app and your data exposed for months.
The recent revelation of the WEBP vulnerability has brought to light the intricate and often fraught process of patching vulnerabilities in modern software— a task that becomes even more daunting when third-party code is involved. Here’s why patch management is a critical, yet complex endeavor:
- New patches can unintentionally introduce additional vulnerabilities, compounding security risks rather than mitigating them.
- Not all users and developers are fully aware of the vulnerabilities’ impacts or the patches available to address them.
- Compatibility issues with new patches can leave systems exposed and vulnerable
In this blog, we delve into the multifaceted challenges of updating software safely and efficiently, particularly when high-impact vulnerabilities are at stake.
The lifecycle of a vulnerability
There are several milestones along the way in the lifecycle of vulnerabilities and patches. According to academic literature, we can resume the process as shown in the following time plot
A. Nappa, et al. “The Attack of the Clones: A Study of the Impact of Shared Code on Vulnerability Patching,” 2015 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 2015
Here are some key milestones to understand:
- T0 – The day when the vulnerability is disclosed.
- Tp – The day when the patch is available
- T50%, T90% and T95% – These indicate the times to patch 50%, 90% and 95% of the population.
We will explore the implications of the lifecycle by using the BLASPASS vulnerability.
What is BLASTPASS
In September 2023, Citizen Lab reported that BLASTPASS is a zero-day mechanism that targets iOS and Android through image parsing. This turned out to be the (in)-famous WebP vulnerability. Specifically, we will focus on Android applications written in Flutter, which are easily portable to various platforms.
Choosing Flutter as the development environment to analyze CVE-2023-4863’s vulnerability patch journey came almost automatically since Flutter allows maintaining almost a single codebase for multiple platforms. Therefore, observing the evolution of patching will shed light on patterns that can very likely be applied across multiple platforms.
Flutter’s ubiquity comes at a high price when it comes to vulnerabilities. The reason for this is that a serious vulnerability in Flutter affects all platforms where the framework runs. It exposes both Android and iOS immediately to threats. In other words, the famous quote “with great power comes great responsibility” can be translated into: with great consequences.
The WebP vulnerability is exploited by crafting an image that causes the parser to overflow a buffer on the heap and distributing it to the victims. That could be one of the exploits that will help, for instance, to install a payload such as spyware on a mobile system.
The key factors for patching
Once we assume the vulnerability is critical and there is an exploit in the wild, there are two important considerations.
- To avoid massive exploitation, a patch must be made available by the responsible party as soon as possible. In this case, it’s Google.
- Ensure enough mobile app decision-makers are informed of the patch’s availability to speed up the patching process.
Several large-scale studies have shown that most application owners simply react slowly or by adhering to their release cycle timeframes. They may consider the vulnerability irrelevant to their use case or that patching would negatively impact other aspects of their business, so they delay the update. We see this in all areas of IT when organizations perform a cost/risk analysis for any patching or risky scenario. Is the potential impact more costly than the update or fix to implement? This is a key driver of why many organizations skip some patches and only go for the cumulative patches or quarterly patches on key services.
Following the white rabbit: CVE-2023-4863 (WebP)
Within one week of Citizen Labs publishing their report (7th of September), a patch was available for Flutter.
Now let’s break down the patching journey and see how it progressed.
The good news is that top brands will do the right thing. No doubt about it, among the top applications that use Flutter within 30 days from the release of the patch the likelihood of finding a vulnerable application to WebP in a random sample of apps selected among the top applications was negligible.
The bad news – but what about the rest? Unfortunately, the top players only represent 5% of apps in the entire Play Store. That leaves an open question around the other 95%.
In order to answer this question, we decided to divide our research into two parts:
- Part 1 – Assess a random sample of apps chosen between patch day to the end of 2023
- Part 2 – Assess a random sample of apps selected between Jan 2024 – March 2024
In In total, this covers six months since release of the patch. For each part of the research, we analyzed 8000 Android applications randomly.
Part 1: How did we do at the end of 2023
Of the 8000 applications sampled for the last 3 months of 2023, about 1% were written in Flutter. But more than 90% of these flutter apps were still vulnerable to WebP by the end of 2023, which is astonishing.
We have an average of 80 apps on our phones, carry an average of three devices, and Flutter is popular across brands of all tiers, so we are likely to have at least one WebP-vulnerable app on our devices.
Part 2 – A new year, a new beginning?
For Q1 of 2024, we selected a new random sample of 8K applications, and the percentage of Flutter apps remained stable at around 1% even considering the growth in Flutter apps in general. The positive is that we witnessed a drop in the number of vulnerable apps (as expected) to 60%. It is unfortunate, however, that even after 6 months of the patch being available, an average user can still be vulnerable to the WebP vulnerability. This is not good news. Especially since users own multiple devices and carry dozens of applications.
Conclusion: Enterprise apps must be vetted prior to being published
Vulnerabilities leave our mobile devices and apps exposed for months even after a patch is released. And almost all mobile devices have at least one app with a critical vulnerability.
The lifecycle we discussed does not take into account people using private or unofficial repositories (i.e. forking) by inheriting and carrying over obsolete and buggy code and causing version drift. Moreover, the “plug and play” inclusion of SDKs severely limits developer control by requiring them to track security issues of code they included or maintain their own code. In reality, these factors aggravate the situation much further for enterprises.
Enterprises that use mobile as a platform will encounter these app vulnerabilities in three different ways.
- For in-house developed apps, developers need to be aware of the vulnerability, and the patch and expedite applying the patch as much as possible.
- The security team needs the ability to assess third-party personal apps on employees’ devices to mitigate any risk to enterprise access.
- Prior to distribution, security teams should ensure that commercial-off-the-shelf (COTS) work apps have no critical vulnerabilities.
It’s crucial to understand that while patches may be available, their timely application across your application footprint is not guaranteed. Control over patch availability and the installation of updated applications often lies beyond your immediate reach. Consequently, this leaves your attack surface exposed and vulnerable for extended periods. To proactively mitigate these risks to your mobile applications, it’s essential to implement additional layers of defense.
How Zimperium Can Help.
Zimperium’s Mobile Application Protection Suite (MAPS) helps to fill the gap between developers and security providing an all-around solution for mobile security. MAPS includes several components that address vulnerabilities, including WEBP.
For mobile applications developed in-house, the zScan component helps app developers identify and assess these critical vulnerabilities during development and pre-release testing. By assessing the app binary and its SBOM within minutes, the solutions provide a comprehensive app risk assessment without slowing down development.
For third-party mobile applications, the Advanced App Analysis (z3a) component assesses the apps for security and privacy risks and detects specific app behaviors, which is crucial for identifying exposure points to threats like WEBP. Upon identifying these undesired app behaviors, the solution allows the security team to mark those apps as “non-compliant”, alerting every end-user to remove the app immediately and mitigate risk.
Our findings were presented at DROIDCON Paris ’24. Learn more by watching the presentation here.
For more information on how Zimperium can help mitigate these risks, visit us at www.zimperium.com.
