COVID-19 Tracking Application

Most of the countries around the world are in a more or less hard lockdown. In Europe, some countries are gradually starting to allow certain sports outings, visiting family or opening certain stores. An important fear is a possible second wave of contamination. To prevent that, some governments provide a mobile application to track the virus spreading.

The concept is simple. A user installs the application in his mobile device and answers some questions about his health condition. After that, the application tracks the user's location. The goal is to be able to detect if a potentially contaminated person has been close to other people. In this case, the application can advise the healthy person he potentially was in contact with a sick person. Another possibility is the information is sent to the user's doctor (or special COVID-19 service) who contact his patient directly to advise him.

It is legitimate to wonder whether these applications are secure and where the personal information of users is stored (health, location data, etc.). In Europe, the GDPR requires strict management of personal data. It is not true in China for example.

Tracker applications in Europe

There are some countries that have developed their own application: Spain (Madrid and Catalonia), Czech Republic, Italy, Bulgaria and Poland. A GitHub repository regroups a lot of Covid-19 tracker applications.

In this article, we will analyze the Catalonia application as an example. We won't go too deeply in the technics. The idea is to put in light some points.

AndroidManifest

The first step in the analysis is to look inside the AndroidManifest file to see what are the permissions required by the application. .

Some of these permissions are interesting:

• Access_coarse_location: uses Wi-FI and/or cells data to locate the device.
• Access_fine_location: uses Wi-Fi, cells data and GPS to locate the device.
• Wake_lock: allows the application to work in the background
• Receive_boot_completed: allows the app to launch right after boot
• C2D_message: allows the application to receive messages from the cloud (Cloud to Device).

Decompile application

The second step is to decompile the application. Here, the application is obfuscated. This makes the analysis much more difficult.

The name of the classes, methods, fields were replaced by letters just before compilation. It is difficult to understand the goal of the functions.

Run application

To understand how works the application, the easiest way is to run it on a device or on a simulator. In this case, the application doesn't work completely on an Android virtual machine. We ran it on a real mobile device.

The application asks the user to identify himself. It is possible to do it with a Passport number. The application doesn't check if the number is valid. Then, the application asks for a phone number. Again, the application doesn't check if the number exists.

The application asks also to have access to the location of the device. The user can answer a small survey about his health condition. In the end, the application provides some basics advises.

Dynamic analysis

It is interesting to know the domain names with which the application communicates. To do that, we set BurpSuit as an https proxy server. This method doesn't work directly. Indeed, most of the Android applications use the SSL pinning mechanism. SSL Pinning is a technique that we use in the client-side to avoid man-in-the-middle attack by validating the server certificates again even after SSL handshaking. The developers embed (or pin) a list of trustful certificates to the client application during development, and use them to compare against the server certificates during runtime.

Fortunately, there are technics to by-pass this security mechanism. Frida framework is one of these technics. It allows code modification at runtime. With Frida, it is easy to bypass the SSL pinning security mechanism.

We are now able to intercept all communications between the application and the different domains. We observe these domains:

• mmm.mubiquo.com
• api.backendcovid19.net
• location.backendcovid19.net
• s3.amazonaws.com/lottusse-live.mubiquo.net/gencat/covid19/1.0

All these servers are Amazon servers and are located in the USA. The domain backendcovid19.net has been registered by Mubiquo.

By analyzing more precisely the exchanges with the servers, we notice that the application will look for several json files. These files are used for the text content of the application. The questionnaire is therefore not hardcoded in the app. This allows you to change the questions without an application update.

Here the answer after a GET request to the URL s3.amazonaws.com//lottusse-live.mubiquo.net/gencat/covid19/1.0/EN/translation_timestamp.json

We can find another address for a json file in this answer. This second file contains the survey questions.

We also note that the user location is sent to three of the four domains: mmm.mubiquo.com, api.backendcovid19.net, location.backendcovid19.net. The health data are sent only on api.backendcovid19.net.

It is important to note that Mubiquo is a Mobile Marketing Solutions company. You may wonder why a digital marketing company is involved in a tracking application with very sensitive user data.

Interesting point

Another point we noted during our analysis. The json files are stored on the URL s3.amazonaws.com/lottusse-live.mubiquo.net/gencat/covid19/1.0. Removing gencat/covid19/1.0/ in the URL conduct to an XML page with a lot of contents including the content for the Tracking application. .

It is likely that all this content refers to other applications that Mubiquo would have developed.

Conclusion

The usage of an application to prevent a second wave of COVID-19 is a commendable idea, but it is important to measure and manage the risks of a data leak. Recently, an Android application specialist found big issues in the Indian tracking app. It was possible to look in a specific location if some people were sick!

This blog post is licensed under CC BY-SA 4.0