Skip to main content

Assessing the Security of COVID-19 Apps

Many governments around the world are starting to look to technology to help them open up their economies again, often through the use of mobile phone applications which aim to assist with traditional contact tracing. These applications use short-range communication, such as Bluetooth, to connect to other nearby devices running the same application (or a compatible one), sharing identifiers that can later be used as part of a contact tracing process if someone is diagnosed with COVID-19.

Of course, privacy and security considerations must be balanced against the need to support healthcare and facilitate the economy — challenges faced by almost every country right now. In this regard, the European Commission has published a call for using a common approach and has published  guidelines related to the realization of contact-tracing applications with the objective of constituting a pan-European approach for officially recognizing COVID-19 mobile applications, allowing people to freely move inside its transnational space.

The major mobile operating system (OS) vendors are also working on integrating contact tracing into their systems, with a focus on attempts to ensure a higher level of privacy and security. It is likely that many of the existing applications will be migrated to this framework once released. This is made more likely by the fact that the applications currently developed appear to have operational issues with using Bluetooth in the background (or when the screen is off) on some of their targeted platforms.

However, even with the new application programming interface (API) frameworks under development, these solutions will still rely on third-party applications to use the new functions of the OS, and these applications are being produced rapidly in a difficult situation due to quarantine measures in place in many countries, and the economic and health pressures driving the need. What does this mean for the security of the apps themselves? UL downloaded and tested 17 different COVID-19-related mobile applications from around the world and examined these with an eye to security best practices.

Screenshots from Malicious Apps

Although many of the applications do not do more than provide contact tracing signals, some applications (including quarantine, telemedicine and questionnaire applications) still ask for personal information, including contact information and health information. Approximately 13 out of 17 of the applications do not implement countermeasures against external screenshots being taken by other applications, which could expose personal and sensitive information entered by the app user. Given the large scale uptake, which implies a very large install base, the lack of such privacy controls here is a concern.

Insecure Storage

As many as 10 out of 17 of the applications tested use the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permission. This is not advised for security sensitive data, as other applications may be able to access data in these locations. Perhaps equally concerning, given the potential for changes to use the Google/Apple framework in the future, the data which is stored in these locations may not be deleted when the application is uninstalled.

In addition, we found that 11 out of 17 applications use an SQLite Database, execute raw SQL queries and store the data without local encryption (relying solely on the security of the platform to protect the file, which is a concern due to the use of external storage as noted above). More attention should be paid to securing the sensitive data they contain.

Insecure Communication

More than half of the applications (nine of 17) were found to not implement (or not implement securely) certificate pinning to protect communications to backend systems. This opens the sensitive communications of data between the user device and the backend to potential compromise — either exposing the data or even allowing for manipulation of the data being transmitted through “In The Middle” attacks.

Insecure Authentication

Of those applications where a password was implemented (11 out of 17), we found that almost half (five of those 11) did not store those passwords securely, using direct storage rather than storing the password in a form that allows only for matching, and not direct recovery (such as through secure password-hashing functions).

Insufficient Cryptography

Dealing with data under the radar of the General Data Protection Regulation (GDPR) means data that may lead to identification (PII) and tracking to individuals should be protected. However, in terms of cryptography, only five out of 17 applications studied were considered to be aligned with the best practices in terms of use of cryptographic controls. Often weak algorithms subject to well-known attacks were used, like SHA1 or MD5. Moreover, it has been observed that on three out of 17 applications some hardcoded keys were easily found, due to the lack of obfuscation, making the encryption useless.

Row Labels

Number of occurrences

ECB used for encryption.

2 out of 17
(the same two also use weak hash functions)

SHA-1 or MD5 used as hash function.

12 out of 17


Over-Permissive Apps

Looking at the permissions requested by the applications, we found the following:


Number of Apps



3 out of 17

Allows an app to access location in the background.


5 out of 17

Access coarse location sources, such as the mobile network database, to determine an approximate phone location, where available. Malicious applications can use this to determine your approximate location.


7 out of 17

Access fine location sources, such as the Global Positioning System on the phone, where available. Malicious applications can use this to determine your location and may consume additional battery power.


6 out of 17

Allows an application to view configuration of the local Bluetooth phone and to make and accept connections with paired devices.


6 out of 17

Allows an application to configure the local Bluetooth phone and to discover and pair with remote devices.


14 out of 17

Allows an application to create network sockets.


1 out of 17

Unknown permission from Android reference.


1 out of 17

Allows an application to read all of the contact (address) data stored on your phone. Malicious applications can use this to send your data to other people.


12 out of 17

Allows an application to read from SD card.


5 out of 17

Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and so on.


2 out of 17

Allows an application to show system-alert windows. Malicious applications can take over the entire screen of the phone.


12 out of 17

Allows an application to prevent the phone from going to sleep.


12 out of 17

Allows an application to write to the SD card.


1 out of 17

Allows an application to modify the system's settings data. Malicious applications can corrupt your system's configuration.


There are a number of overlapping permissions in the list above, and many applications (seven out of 17) were found to use redundant permissions, such as requesting ACCESS_FINE_LOCATION when also asking for ACCESS_COARSE_LOCATION. These apps also asked for Bluetooth permissions, including BLUETOOTH_ADMIN for some of them. The BLUETOOTH permission enables the app to perform Bluetooth communication, such as requesting a connection, accepting a connection and transferring data. Along with the ACCESS_FINE_LOCATION permission, Bluetooth scan can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities.

The BLUETOOTH_ADMIN permission is more invasive, as it allows the discovery and pairing of a new Bluetooth device nearby (with the agreement of the user) and is not required for the purpose for which these applications are deployed.

Code Tampering and Reverse Engineering

None of the applications were found to use any anti-tampering security mechanisms, such as Google SafetyNet. This allows for the potential of modified apps to be redistributed through other app stores, but where the modifications are implemented to collect additional data on the user or provide vectors for malware onto the user phone.

Only one out of 17 apps was found to implement robust protections against reverse engineering. Another 10 out of 17 implemented some form of reverse engineering protection, but this was found to be weak and insufficient against any realistic attempts to bypass the implemented controls. Use of obfuscation and reverse engineering protections are sometimes controversial, and we do not make a stance on if this should be done or not, except to say that if the decision is made to protect against reverse engineering, it should at least be effective.



Overall, the applications we looked at would not meet the standards normally expected of an application handling sensitive health data installed on the majority of mobile devices in a specific region. We firmly believe these applications can play an important role in the recovery of the COVID-19 crisis as part of a more robust and extensive contact tracing process, but equally believe that the risks of these applications must be carefully mitigated through a full security development and review process. This is especially true in light of the need to convert existing applications from their current implementation to the Google/Apple framework when it is fully released. How is historic data on the app managed? How is the security of the app implemented? How do we ensure these systems provide the value they are being relied on to provide? The goal we all need to be focused on is managing these apps in the most secure way possible.