The road to improving application security is a long one, with the Open Web Application Security Project (OWASP) playing a pivotal role. This group published the first incarnation of the Top 10 Mobile Application Vulnerabilities in 2011, with the most recent update delivered in 2016. It’s a useful framework for evaluating the overall security posture of mobile applications, as demonstrated by the excellent studies published by NowSecure in 2018 and Positive Technologies in early 2019.

In the mobile app protection space, things change quickly and one year is a long time.  So, I thought that I’d do a quick review of publicly announced Common Vulnerabilities and Exposures (CVEs) to see if the findings from these reports still apply.  I’m not trying to do an exhaustive review, nor am I trying to explain each and every one of these vulnerabilities as there are tons of excellent blogs covering this topic already.  This blog is a quick scan to see if these vulnerabilities are still happening, and are relevant, today.

Here Are The Top There Vulnerabilities We Reviewed

#1: Insecure Data Storage

Let’s start with the most common vulnerability identified in the studies by NowSecure and Positive Technologies: insecure data storage. In scanning the CVEs for the last year, we can see several examples of this vulnerability in iOS and Android applications today. Here are some examples:

• A set of popular media for on-demand video playback applications for iOS and Android sent unencrypted analytic information to head-end servers and third-party ecosystem partners. In looking at Apptopia data, this CVE could have impacted as many as one million users based on the download data for the past year. The type of unencrypted information included:
  • Device model & resolution
  • Mobile carrier
  • Days since first use
  • Days since last use
  • Total number of app launches
  • Number of app launches since upgrade
  • Previous app session length to head-end servers as well as third-parties
• An Android Home Security Application stored users’ ID and password information in clear text within application log files.
• An iOS note-taking application used a password to record notes leading the user to believe that messages are stored securely and encrypted within the application; when in reality, the messages were stored in clear text within the application database.
• An Android/iOS application used to manage office access and resources for locations without dedicated staff stored hard-coded OAuth Credentials in plaintext.

#2: Insecure Communications

The next most common vulnerability found in the NowSecure study was insecure communications. Again, here are some examples of this CVE in Android and iOS CVEs issued within the last year.

• An SDK used in over half a dozen financial Android financial applications did not adequately ensure that the X.509 certificate is associated with its specified host, thereby possibly exposing communication to potential Man-In-The-Middle (MITM) attacks. In looking at Apptopia data, this CVE could have impacted as many as 242,000 users based on the download data for the past year.
• A Coronavirus application used HTTP instead of a more secure method like HTTPS for communication between the mobile application and the Server APIs. The application contains Protected Health Information (PHI) and Personally Identifiable Information (PII), which could be exposed by using an insecure method.
• A popular Android SDK for analyzing user behavior has a default configuration with SSL communication disabled by default. This means that any mobile applications using this SKD with the default settings, was not using a secure connection when transmitting users’ data.

#3: Reverse Engineering

Another commonly cited vulnerability was Reverse Engineering. Similar to the previous two CVEs, here are some examples:

• A cybersecurity company reverse-engineered an IoT smart lock’s Android application. Through reverse engineering, the company was able to determine the encryption keys for communication between the lock and its associated application, thus, demonstrating that this lock is vulnerable to unauthorized applications. By doing this, a determined individual could craft their own key to unlock any of these devices.
• In another case, another security company reverse-engineered a mobile application used to control/communicate with a specific series of robots. As a result of this analysis, the security engineers could spy on video calls, intercept calls intended for another user, and even remotely operate any robot built by this manufacturer – all with zero authentication.
• As a final example, we know from previous blogs that user IDs/passwords to communicate with server APIs are sometimes hard-coded into applications. Sure enough, we found an example of this in 2020 where an Android application for communication with satellites hard-coded mast account communications to an FTP server.

Do The Top 10 Cves Still Hold True?

In doing this quick review of CVEs released in the past year, it’s clear that the vulnerabilities identified in the Android Mobile top 10 are still as pertinent today as they were in 2018 and 2019.

In this blog, we showed that many of the top vulnerabilities identified in earlier studies are still being reported in applications today. But has the frequency of application vulnerabilities changed significantly year to year?  A quick comparison of the percentage of Android application CVEs between 2019 and 2020, shows that it’s stayed pretty consistent. In 2019, there were 14% of Android CVEs and in 2020, there were 11%. In other words, we’re still finding the same relative number of Android application issues in 2020 as we did in 2019. Despite the many hacks and commonly acknowledged vulnerabilities, there still hasn’t been any real improvement in application security!

While progress has been made in making mobile applications more secure for end-users, it’s clear that there is still some work to be done to the apps themselves. There are many solutions out there, and my recommendation is to leverage the full gamut of them from SAST/DAST testing to leveraging native platform technologies like scoped storage and integrating application security technologies in order to ensure that your product and end customers are not impacted by security issues like the ones outlined above.