Subscribe
With the Super Bowl approaching in the U.S., the Black Duck Cybersecurity Research Center (CyRC) set out to evaluate the 10 most popular Android sports and betting apps through the lens of supply chain security. We used Black Duck® Binary Analysis (BDBA) to examine the open source components used in these apps.
Executive summary
In aggregate, the 10 apps analyzed have over 21.5 million downloads from the Google Play Store. For perspective, these apps have been downloaded by as many people as the population of metropolitan São Paulo.
- Average number of components per app: 125
- Average number of vulnerable components per app: 10
- Average number of vulnerabilities per app: 179
Despite evidence of active development, many of the apps we analyzed use outdated open source components with their associated known vulnerabilities. In the software world, two or three years is a long time; in the apps we analyzed, we found open source components dating back to 2010.
Known vulnerabilities in open source components are not necessarily exposed in the app. However, risk increases with the age of the components and the number of known vulnerabilities. Furthermore, outdated components are an indication that development teams are not managing their open source dependencies, which could be an indication that they are not handling security well in general.
The sports and betting apps we analyzed scored significantly worse than the average numbers we encountered in our 2021 report, “Peril in a Pandemic.” In that research, we examined 3,335 apps and found the following:
- Apps with vulnerable components: 63% (in this analysis, 100%)
- Average number of vulnerabilities per app: 39 (in this analysis, 179)
Are these apps safe to use? Some development teams are doing better than others at managing their open source dependencies. Consumers, unfortunately, do not have this visibility and must hope that app developers and app stores will improve their security processes. If we can do this type of analysis, app stores can do this type of analysis.
Setting a bar for vulnerabilities in software components, even a low bar, would improve the security of apps that are permitted in app stores. This would drive down risk for consumers, for app developers, and for the entire ecosystem.
How software is made
Before we dive into the detailed results, let’s take look at how software is created.
Nearly all software is created using open source software (OSS) components as building blocks. Open source components provide functionality, which development teams “glue” together by writing some first-party code. The open source components are the application’s dependencies.
Furthermore, a complete application typically consists of several parts. For a mobile betting application, the mobile app itself is one part. Other parts could include a web application, a back-end server, and a database. The app, web application, and back-end server follow this pattern of a little bit of first-party code on top of building blocks of open source components.
Using open source components allows development teams to quickly bring their software to market, but the open source components must be properly managed to minimize risk. The components themselves can have vulnerabilities that might be exposed in the application.
A doughnut hole inside a doughnut hole
Unfortunately, the full structure is more complicated. Each open source component can itself be assembled from other open source components. A single application’s dependencies, instead of being a neat list, are more like a network or a hierarchy.
Open source components used by the containing software are dependencies, and the open source components used by the dependencies are transitive dependencies.
About Black Duck Binary Analysis (BDBA)
Black Duck Binary Analysis is a software composition analysis (SCA) tool. Like any SCA tool, BDBA identifies the open source components used in an application, and then lists the known vulnerabilities and software licenses of those components. SCA is just one important part in managing software supply chain risk.
Most SCA tools examine the source code of an application to determine its dependencies. A variety of matching techniques are used as appropriate. The tool might look at the source code itself, or examine package manifests such as Maven files or NPM package lists, or it might compare file hashes for already compiled components.
Determining dependencies can be challenging. Software build scripts sometimes retrieve open source components during the build. Furthermore, components might be incorporated as source code or as compiled executables or shared libraries.
BDBA is unique in that it examines executable files; no source code is required. This makes it perfect for examining commercial apps when source code is unavailable. Furthermore, BDBA easily finds both direct dependencies and transitive dependencies.
Method
We searched the Google Play Store for sports betting apps and then compiled a list of all apps with more than 500K downloads. This yielded a list of 11 apps. We then eliminated one from the list as being more of a game than an actual betting app. For the remaining 10, we obtained the packaged apps (as APK files) from APKPure. We analyzed each app’s APK file using BDBA.
We performed the download and analysis twice, once on December 9, 2022, and again on January 20, 2023.
Clearly, these apps are under active development, as all but one released at least one new version in the 42 days between the two analyses. The discussion below is based on the analyses from January 20, 2023.
We deliberately chose to present results and analysis without naming specific apps. Highlighting potential vulnerabilities in specific apps is irresponsible and would only serve to focus attackers’ attentions on potential attack vectors.
We present this research in the hopes that it will encourage development teams to be vigilant about their supply chain and help consumers understand the complexities of software and apps.
Components and vulnerabilities
Each of the 10 apps is displayed as a dot in the graph below, which shows how many components were detected and how many known vulnerabilities are in those components. It’s important to note that just because a component has a known vulnerability, that does not mean it is exposed and exploitable in the app. However, large numbers of known vulnerabilities can be an indication that the development team is not paying attention to the security of their open source dependencies.
The average number of components per app is 125, with an average of 10 components with known vulnerabilities.
App permissions
A coarse method for evaluating the security of an app is to examine its permissions. This sometimes reveals surprising results. For example, a flashlight app has no need for network or camera permissions.
BDBA highlights potentially dangerous app permissions, as shown here.
A few aggregate findings stood out in this category.
- Eight apps request permission for coarse and fine location access. This probably makes sense, because apps that support betting functionality are likely to need the user’s physical location in order to comply with jurisdictional laws.
- The same set of eight apps also requested access to the camera.
- Four apps requested access to record audio.
Sensitive permissions like camera access and recording audio might make sense in the context of an app’s functionality. Nevertheless, careful users should be skeptical about the permissions requested by an app and why they might be necessary.
In the remainder of this blog post, we’ll examine the software components of five apps (again, without naming them) and discuss the interesting security findings.
App A: So close and yet so far
The first app appears as though its development team was trying to keep its dependencies up-to-date, but made one important mistake. Here is the dashboard of results from BDBA.
The summary graphs at the top show that 6 out of 79 detected components have known vulnerabilities. They also display the severities of the vulnerabilities and provide a summary of detected component license types. This analysis is focused on known vulnerabilities, but software licenses can also present risk.
BDBA also creates a list (called a software Bill of Materials, or SBOM) of the detected components in descending order of number of vulnerabilities. The colorful bars show the number of critical-, high-, medium-, and low-severity vulnerabilities. (The last three columns are irrelevant for this analysis.)
Except for sqlite3, this app looks very clean. But that sqlite3 component is contributing 90 known vulnerabilities to the analysis results. The reason for this is that the version in question, 3.6.23, is just about to enter its teenage years. And although 13 years might not seem very old for a human, it is ancient in the realm of software.
sqlite3, like many other open source components, is a high-quality, actively maintained component that provides important functionality for many applications. As with any other piece of software, vulnerabilities are found and fixed over time. Using an up-to-date version of the component helps protect an application against security vulnerabilities and other software bugs.
If the development team for app A was careful about the rest of its SBOM, why did it miss an ancient version of sqlite3? BDBA shows us the location of the component in the uploaded APK file.
sqlite3 was packaged into a shared library, libtdm-5.4-73-jni.so, which is available for different processor architectures inside the app’s APK file. We don’t know the origin of libtdm-5.4-73-jni.so—it could be commercially available or created by another team. Regardless, a very old version of sqlite3 is built into it, making sqlite3 a transitive dependency of app A.
So although app A’s development team appears to be managing direct dependencies well, it missed a transitive dependency that could be exposing the app to multiple security vulnerabilities.
App B: Another sad story of transitive dependencies
We see a similar story with app B, which has 120 components and 102 vulnerabilities across 14 components. Many of the transitive dependencies in app B come from SkiaSharp, an adaptation of the skia 2D graphics component for the .NET ecosystem.
The following components are packaged inside app B, in libSkiaSharp.so. Taken together, these transitive dependencies account for 89 of app B’s 102 vulnerabilities.
- expat
- zlib
- libjpeg-turbo
- libwebp
- freetype
- libpng
- skia
The detected version of expat, 2.1.0, is from October 2017.
Deeper investigation revealed that app B is using SkiaSharp version 1.68.1.1. During a secondary analysis of several versions of SkiaSharp retrieved from NuGet, the .NET package repository, we found the release dates and expat versions.
SkiaSharp version |
SkiaSharp release date |
expat version |
1.68.1.1 |
December 21, 2019 |
2.1.0 |
2.88.0 |
May 22, 2022 |
2.2.9 |
2.88.3 |
October 3, 2022 |
2.4.8 |
App B is incorporating an older version of SkiaSharp, which has a cascade of older transitive dependencies and a deluge of their associated known vulnerabilities.
App C: This is what happens when you do not try
App C does not have an especially large number of vulnerabilities (85), but a quick look at the most vulnerable components in the SBOM indicate a lax attitude toward open source component management.
The three most vulnerable components are quite old.
Component |
Release date |
sqlite 3.19.0 |
|
libpng 1.2.56 |
|
lua 5.1.5 |
Components this old clearly show that the development team does not have visibility into its own SBOM and is not taking steps to keep components up-to-date or minimize known vulnerabilities.
App D: Leaving stuff inside the patient
In addition to compiling an SBOM, BDBA also looks through software for sensitive information that might have been left behind accidentally. This can include cloud service credentials, cryptographic secrets, OAuth tokens, passwords, and more. App D has an interesting finding in this category.
This does appear to be a legitimate Amazon Web Services (AWS) key. However, this particular type of key (prefixed with ASIA) is supposed to be short term and also requires a session token in order to be useful. Our further analysis of the app concluded that either the session token was missing or the key had already expired.
Nevertheless, leaving secrets like this inside a packaged and deployed app is almost certainly a mistake, and the development team for app D should be reviewing its source code and build pipelines for this type of leakage.
App E: Next to godliness
Let’s end on an upbeat note by looking at app E. At first, it appears to have just three components with known vulnerabilities.
Surprisingly, jackson-databind is contributing 69 of the app’s 71 vulnerabilities. This seems unlikely, given that the rest of the SBOM is so clean.
The question mark next to jackson-databind indicates that BDBA was unable to ascertain the exact version of the component. Without a specific version, BDBA falls back on the file timestamp to determine which vulnerabilities apply.
With Android apps, the default packaging mechanism strips out timestamp information. Thus, BDBA will assume the worst and mark all recorded vulnerabilities for a component as valid.
Based on the evidence, it seems likely that the developers of app E used an up-to-date version of jackson-databind. In BDBA, we can manually designate the component version as the latest (2.14.1 at this writing), resulting in a squeaky clean SBOM.
What does it all mean?
Evaluating risk in software is difficult. In this research, we’ve examined 10 of the most popular Android sports and betting apps through a lens of open source component security. A full security assessment of these apps would involve a broad spectrum of manual activities and automated testing.
The real question for consumers is whether these apps are safe to use. But that’s like asking a team of mechanical engineers to review an airplane’s landing gear system and avow that it is safe to be a passenger in that airplane.
One way to think about risk is assessing how hard an attacker would need to work to exploit one of these applications, and why they might want to. What do the apps do and what information do they contain that would be useful to an attacker? Would an attacker need to compromise the server-side infrastructure to make the app behave badly or can the app be controlled more simply?
Performing SCA on these apps provides some visibility into how well the development teams are managing their software supply chain. This, in turn, might reflect how well the development organization overall is incorporating security into its entire systems, including back-end servers and other software components. On the other hand, the mobile app and back-end server teams could be entirely different, with different cultures and different levels of secure software development life cycle adoption.
SCA is just one important part of a secure software development life cycle. By using a process that includes security at every step, developers can create software that is resilient, secure, and minimizes risk for both their own organization and their customers.
Continue Reading
A new identity for the Synopsys Software Integrity Group
Aug 12, 2024 / 2 min read
CyRC Vulnerability Advisory: CVE-2024-5184s prompt injection in EmailGPT service
Jun 04, 2024 / 1 min read