Impact
Identification and deanonymization of COVID-19 positive users that upload Radar COVID TEKs to the Radar COVID server.
Description
This vulnerability enables the identification and de-anonymization of COVID-19 positive users when using Radar COVID. The vulnerability is caused by the fact that Radar COVID connections to the server (uploading of TEKs to the backend) are only made by COVID-19 positives. Therefore, any on-path observer with the ability to monitor traffic between the app and the server can identify which users had a positive test.
Such an adversary can be the mobile network operator (MNO) if the connection is done through a mobile network, the Internet Service Provider (ISP) if the connection is done through the Internet (e.g., a home network), a VPN provider used by the user, the local network operator in the case of enterprise networks, or any eavesdropper with access to the same network (WiFi or Ethernet) as the user as could be the case of public WiFi hotspots deployed at shopping centers, airports, hotels, and coffee shops.
The attacker may also de-anonymize the user. For this additional stage to succeed, the adversary needs to correlate Radar COVID traffic to other identifiable information from the victim. This could be achieved by associating the connection to a contract with the name of the victim or by associating Radar COVID traffic to other user-generated flows containing identifiers in the clear (e.g., HTTP cookies or other mobile flows sending unique identifiers like the IMEI or the AAID without encryption). The former can be executed, for instance, by the Internet Service Provider or the MNO. The latter can be executed by any on-path adversary, such as the network provider or even the cloud provider that hosts more than one service accessed by the victim. The farther the adversary is either from the victim (the client) or the end-point (the server), the less likely it may be that the adversary has access to re-identification information.
The vulnerability has been mitigated with the injection of dummy traffic from the application to the backend. Dummy traffic is generated by all users independently of whether they are COVID-19 positive or not. To ensure that dummy and real communications are indistinguishable, the following measures have been implemented:
- Dummy uploads are scheduled according to a Poisson distribution with an average of 5 days. A privacy analysis of this mechanism can be found here.
- Dummy and real uploads have the same size and require the same processing time.
- Dummy and real uploads result in the same logging behavior.
There is an additional risk associated with running the backend server in the cloud. The cloud service provider can implement a man-in-the-middle attack between the apps and the backend. This attack would enable the provider to inspect the content of the communication and therefore distinguish dummy from real requests, resulting in a risk of identification of COVID-19 positive users. This risk is assumed as low given the contractual obligations of the cloud provider, the GDPR provisions (that would result in severe fines for the provider), and the impact on public image that such an attack could entail. Therefore, it is not mitigated from a technical perspective.
Coordinated Disclosure Timeline
09/16/2020 - Initial contact with the Radar COVID team reporting the vulnerability and possible solutions.
09/25/2020 – The Radar COVID team designs, implements, and adds to the development branches a solution that schedules dummy traffic following a uniform distribution in the range of [180, 360] minutes.
10/09/2020 – The version with uniform dummy traffic becomes part of the main branch and it is published in the app stores (iOS v1.0.8, Android v1.0.7). The backend is upgraded to ensure that processing time is the same for real and dummy updates.
10/12/2020 – Second contact with the Radar COVID team, including a first videoconference, to report vulnerabilities of their solution using a uniform distribution. Proposal of an exponential scheduling backed up by a formal privacy analysis. Agreement to adopt the exponential, incorporate it to the next release, and publicly disclose the steps of the process.
10/30/2020 – The version with exponential dummy traffic becomes part of the main branch and it is published in the app stores (iOS v1.1.0, Android v1.1.0).
11/13/2020 - The vulnerability is reported to GitHub and published as a security advisory.
Patches
The issue was fixed:
- iOS in version 1.0.8 (uniform distribution), 1.1.0 (exponential distribution)
- Android in version 1.0.7 (uniform distribution), 1.1.0 (exponential distribution)
- Backend in version 1.1.2-RELEASE
References
For more information
If you have any questions or comments about this advisory:
Credits
These issues were discovered and reported by (in alphabetical order):
Carmela Troncoso, carmela.troncoso@epfl.ch
EPFL, http://carmelatroncoso.com/
Juan Tapiador, jestevez@inf.uc3m.es
UC3M, https://0xjet.github.io
Linus Gasser, linus.gasser@epfl.ch
EPFL, https://www.linkedin.com/in/ineiti/
Narseo Vallina-Rodriguez, narseo.vallina@imdea.org
IMDEA Networks / ICSI / AppCensus, http://narseo.com/
Wouter Lueks, wouter.lueks@epfl.ch
EPFL, https://wouterlueks.nl/
The design and development of the mitigations were a collaborative effort between Radar COVID development team and the aforementioned researchers.
Impact
Identification and deanonymization of COVID-19 positive users that upload Radar COVID TEKs to the Radar COVID server.
Description
This vulnerability enables the identification and de-anonymization of COVID-19 positive users when using Radar COVID. The vulnerability is caused by the fact that Radar COVID connections to the server (uploading of TEKs to the backend) are only made by COVID-19 positives. Therefore, any on-path observer with the ability to monitor traffic between the app and the server can identify which users had a positive test.
Such an adversary can be the mobile network operator (MNO) if the connection is done through a mobile network, the Internet Service Provider (ISP) if the connection is done through the Internet (e.g., a home network), a VPN provider used by the user, the local network operator in the case of enterprise networks, or any eavesdropper with access to the same network (WiFi or Ethernet) as the user as could be the case of public WiFi hotspots deployed at shopping centers, airports, hotels, and coffee shops.
The attacker may also de-anonymize the user. For this additional stage to succeed, the adversary needs to correlate Radar COVID traffic to other identifiable information from the victim. This could be achieved by associating the connection to a contract with the name of the victim or by associating Radar COVID traffic to other user-generated flows containing identifiers in the clear (e.g., HTTP cookies or other mobile flows sending unique identifiers like the IMEI or the AAID without encryption). The former can be executed, for instance, by the Internet Service Provider or the MNO. The latter can be executed by any on-path adversary, such as the network provider or even the cloud provider that hosts more than one service accessed by the victim. The farther the adversary is either from the victim (the client) or the end-point (the server), the less likely it may be that the adversary has access to re-identification information.
The vulnerability has been mitigated with the injection of dummy traffic from the application to the backend. Dummy traffic is generated by all users independently of whether they are COVID-19 positive or not. To ensure that dummy and real communications are indistinguishable, the following measures have been implemented:
There is an additional risk associated with running the backend server in the cloud. The cloud service provider can implement a man-in-the-middle attack between the apps and the backend. This attack would enable the provider to inspect the content of the communication and therefore distinguish dummy from real requests, resulting in a risk of identification of COVID-19 positive users. This risk is assumed as low given the contractual obligations of the cloud provider, the GDPR provisions (that would result in severe fines for the provider), and the impact on public image that such an attack could entail. Therefore, it is not mitigated from a technical perspective.
Coordinated Disclosure Timeline
09/16/2020 - Initial contact with the Radar COVID team reporting the vulnerability and possible solutions.
09/25/2020 – The Radar COVID team designs, implements, and adds to the development branches a solution that schedules dummy traffic following a uniform distribution in the range of [180, 360] minutes.
10/09/2020 – The version with uniform dummy traffic becomes part of the main branch and it is published in the app stores (iOS v1.0.8, Android v1.0.7). The backend is upgraded to ensure that processing time is the same for real and dummy updates.
10/12/2020 – Second contact with the Radar COVID team, including a first videoconference, to report vulnerabilities of their solution using a uniform distribution. Proposal of an exponential scheduling backed up by a formal privacy analysis. Agreement to adopt the exponential, incorporate it to the next release, and publicly disclose the steps of the process.
10/30/2020 – The version with exponential dummy traffic becomes part of the main branch and it is published in the app stores (iOS v1.1.0, Android v1.1.0).
11/13/2020 - The vulnerability is reported to GitHub and published as a security advisory.
Patches
The issue was fixed:
References
RadarCOVID/radar-covid-ios@2d1505d
RadarCOVID/radar-covid-android@09d00e5
RadarCOVID/radar-covid-android@9627f4d
RadarCOVID/radar-covid-android@7fdc7de
RadarCOVID/radar-covid-android@ea0c4cc
RadarCOVID/radar-covid-android@8e5d14e
RadarCOVID/radar-covid-android@5325277
RadarCOVID/radar-covid-android@91dcfff
c37f816
6d30c92
For more information
If you have any questions or comments about this advisory:
Credits
These issues were discovered and reported by (in alphabetical order):
Carmela Troncoso, carmela.troncoso@epfl.ch
EPFL, http://carmelatroncoso.com/
Juan Tapiador, jestevez@inf.uc3m.es
UC3M, https://0xjet.github.io
Linus Gasser, linus.gasser@epfl.ch
EPFL, https://www.linkedin.com/in/ineiti/
Narseo Vallina-Rodriguez, narseo.vallina@imdea.org
IMDEA Networks / ICSI / AppCensus, http://narseo.com/
Wouter Lueks, wouter.lueks@epfl.ch
EPFL, https://wouterlueks.nl/
The design and development of the mitigations were a collaborative effort between Radar COVID development team and the aforementioned researchers.