Mobile App Security: Tracking CVEs with Python

Despite the popularity of mobile devices and the ever-increasing number of vulnerabilities found in their applications, the focus on mobile app security is still overshadowed by other security topics such as web applications. It can be tricky to stay informed on new risks in mobile application development specifically.

Many mobile security issues stem from back-end service issues rather than client-side mobile app vulnerabilities. Back-end issues fall within web application territory, however, a unique approach is required for identification and reporting of client-side mobile app vulnerabilities. Because each mobile application is a unique implementation, developers often make the same mistakes. It’s a great idea to stay up to date on these security vulnerabilities.

The Common Vulnerabilities and Exposures (CVE) system is the most widely used reference for publicly known software vulnerabilities and is accessible through the U.S. Government’s National Vulnerability Database (NVD). Though the database can be searched using keywords such as “Android” and “iOS” to spot some mobile app entries, unwanted results will appear such as platform vulnerabilities and many mobile apps CVEs will be missing.

Fortunately, the Common Platform Enumeration (CPE) 2.3 specification has a "configuration" string that contains a label for the operating system of the affected software. For example, mobile app CVEs such as CVE-2019-1948 have either "android" or "iphone_os" listed towards the end of the CPE string. However, spotting mobile app CVEs, such as the one shown in Image 1: Example Mobile App CVE, is not as simple as browsing through a list of mobile apps on the NVD website.

To develop a solution, we use the Python programming language to specifically identify mobile apps within the NVD data JSON feed via the CPE configuration. First, with Python 3.8 installed, we import a few default Python packages and establish some basic variables. See Image 2: Imports and Initial Variables.

The NVD separates data sets by calendar year. We construct a list of years to download, starting roughly when modern mobile apps begin appearing in the NVD in 2012. Then we download each ZIP file from the NIST website and load the JSON data within. See Image 3: Loading the NVD JSON Feed.

From here, we look at each CVE in the NVD and tag the CVE ID, publication date, and English description into variables. See Image 4: Parsing CVE Data.

Next, we iterate over the CVE’s CPE data and extract the CPE uniform resource identifiers (URI). See Image 5: Parsing CPE Data.

Now we look at CPE URI, which is constructed like this: cpe:2.3:a:cisco:webex_meetings:*:*:*:*:*:iphone_os:*:*

We use Python’s split() method to specifically parse out the CPE v2.3 host platform field. With this information, we tag CVE IDs that contain a host platform of iphone_os or android into our matching_cves list. See Image 6: Parsing CPE’s Host Platform.

Next, we build a simple HTML report file listing all the iOS and Android mobile application CVEs, sorted with the most recent CVEs first, and with a link to more about each CVE on NVD. See Image 7: Generating CVE Report.

The output report file for mobile app CVEs looks like Image 8. We suggest revisiting this report often to stay up to date on the most recent mobile application vulnerabilities. See Image 8: Sample Report of Mobile App CVEs.

Several new mobile app CVEs are published each week, describing a broad assortment of vulnerabilities. By tracking the CVEs appearing in the NVD, app analysts and developers can stay informed about vulnerabilities facing mobile apps. Keeping on top of new types of vulnerabilities and having an effective way to test for them can significantly reduce risk as an app owner.

For reference, the complete Python code can be found on GitHub.

This article is for informational purposes only, its content may be based on employees’ independent research, and does not represent the position or opinion of Booz Allen. Furthermore, Booz Allen disclaims all warranties in the article's content, does not recommend/endorse any third-party products referenced therein, and any reliance and use of the article is at the reader’s sole discretion and risk.