This repository has been archived by the owner on Nov 14, 2022. It is now read-only.
Permalink
Cannot retrieve contributors at this time
192 lines (148 sloc)
7.34 KB
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
nl-covid19-notification-app-coordination/CVEs/CVE-2020-24721.txt
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| -----BEGIN PGP SIGNED MESSAGE----- | |
| Hash: SHA256 | |
| (Corona) Exposure Notifications API | |
| for Apple iOS and Google Android | |
| risk of coercion/data leakage | |
| post notification | |
| CVE-2020-24721 / CVSS v3.1 score: 5.9 | |
| AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N/E:H/RL:U/RC:C/CR:H/IR:L | |
| AR:L/MAV:P/MAC:L/MPR:L/MUI:R/MS:U/MC:H/MI:N/MA:N | |
| 1.12 | |
| The Corona/COVID-19 Exposure Notifications API allows for the | |
| decentralised, highly (pseudo)anonymous notifcation of exposure to | |
| people that where considered (usuall based on a lab test) infectious | |
| in a certain period of time. And where both the receiver of the | |
| notification and the infected person (index) were near to each | |
| other for a sufficently long time. And both had this technology | |
| enabled on their phone. | |
| In order to prevent this technology to be used 'against' the user it is | |
| important that any implementation puts privacy, and control over, that | |
| privacy with the user. | |
| This includes protecting the users against coercion; i.e. preventing the | |
| situation were the user is put in a position where he or she is forced | |
| to reveal wether or not they have had a (recent) infection notifcation | |
| or not. | |
| As it stands - most (European) implementations in general, and the Dutch | |
| implementation specifically, are such that the user can 'swipe away' a | |
| exposure notifcation. And once this is done - the app reverts to its | |
| exact same behaviour as prior to that notification. With no evidence or | |
| data left behind that this user has had this notification (or not). | |
| However - the actual data and Exposure Notifications are not fully under | |
| control, or part of these implementations. Instead - it is handled in a | |
| closed part of either iOS or Android its private frameworks. And the | |
| respective vendors do not allow control over this (or the data) by the | |
| implementations. | |
| The result of this is that 'state' is left behind; even (or especially) | |
| when the user deletes his or her app for the phone. | |
| This means that an attacker (e.g. an employer, law enforcement, spouse, | |
| etc) can force the user to 'prove' wether he or she had (or had not) an | |
| notification. For example by insisting that the target deletes the app | |
| of their phone; re-installs it and then waits sufficently long for the | |
| app to re-download the data of the past 14 days, re-calculate wether | |
| there has been a notifcation and observe wether the person had, or did | |
| not have a notification. | |
| There are some sublte differences in how this manifests itself. | |
| a) Scenario google. | |
| When a match is made & reported by the framework; the RPI that | |
| made that match is not deleted from the private store of | |
| the OS/Framework. | |
| The prelude to an example attack is for a user that wants to hide | |
| the fact that he or she had a notification (or want hide the | |
| fact that they had none - while claiming to have had so). | |
| 1) user installs app, gets a matching TEK on that RPI on day 20 & | |
| warning that he or she was near an infected user on day 18. | |
| Users swipes warning away. | |
| Example attack scenario is then: | |
| 2) Someone with sufficent coercion powers wipes the | |
| application storage on day 20 (up to day 31). | |
| 3) App is restarted.. App auto redownloads app TEKs for the | |
| past 14 days. | |
| The RPI of day 18 is still in this window. | |
| And the app _again_ shows that warning as the RPI is | |
| still present on the phone. | |
| b) Apple Scenario | |
| When a match is made & reported by the framework; the RPI that | |
| made that match is not deleted from the private store of | |
| the OS/Framework. | |
| The prelude to an example attack is for a user that wants to hide | |
| the fact that he or she had a notification (or want hide the | |
| fact that they had none - while claiming to have had so). | |
| 1) user installs app, gets a matching TEK on the RPI | |
| on day 20 & warning that he or she was near an | |
| infected user on day 18. Users swipes warning away. | |
| 2) User wants to hides this and deinstalls the app. | |
| Example attack scenario is then: | |
| 2bis) Or attacker deinstalls the app. | |
| 3) Someone with sufficent coercion powers reinstalls | |
| the app on day 20 (up to day 31). | |
| 3) App is started.. App auto redownloads app TEKs | |
| for the past 14 days. | |
| The RPI of day 18 is still in this window. | |
| And the app _again_ shows that warning | |
| Versions affected: | |
| - - ------------------ | |
| All known versions up to and including 1.5 | |
| Resolution: | |
| - - ----------- | |
| None at this time. Possible solutions by the vendors could | |
| include deletion of the RPI upon the reporting the match (much | |
| like the TEKs need to change after upload) and/or deletion of | |
| all the received RPIs when the app is deleted. | |
| Mitigations and work arounds: | |
| - - ----------------------------- | |
| None at this time - apart from raising general awareness in the | |
| general case. For the Netherlands - specifically; the introduction | |
| of law and regulation, including sanctions; the creation of a | |
| helpdesk/enforcement team at the Justice department to go after | |
| the offenders and target information campaigns & FAQs. | |
| Credits and timeline | |
| - - -------------------- | |
| Variations of this flaw have been documented by the DP3T team in their | |
| academic paper. It was found it the Apple/Google implementations during | |
| the build of the dutch 'Corona Melder' app (https://github.com/minvws). | |
| 2020-01-18 first known description of this class of issues | |
| 2020-04-03 first paper by DP3T team published. | |
| 2020-05-06 confirmation of this issue with Google | |
| 2020-05-07 confirmation of this issue with Apple | |
| 2020-08-13 final written/formal questions sent on request (#115 | |
| and 115.bis) as a vulnerability report. | |
| 2020-08-13 confirmation vendor. | |
| 2020-08-27 CVE issues by MITRE | |
| 2020-09-13 Request vendor to provide CVE/start FD. | |
| 2020-09-15 Versions under embargo sent to google/apple. Confirmation | |
| of receipt and reference # for both received. | |
| 2020-09-15 Full disclosure timeline setting process started. | |
| 2020-09-22 Reminder to google/apple & request to submit their | |
| preferred timeline/disclosure approach. | |
| 2020-09-25 Deadline to provide timeline preferences and | |
| feedback passed. | |
| 2020-09-29 Vendor informed that public disclosure is imminent. | |
| History | |
| - - ------- | |
| 1.09 2020-09-15 version submitted to vendors. | |
| 1.10 2020-09-17 corrected 'prelude'; 'notification' rather than | |
| being an index. | |
| 1.11 2020-09-29 full public disclosure | |
| Common Vulnerability Scoring (Version 3) and vector | |
| - - --------------------------------------------------- | |
| CVSS v3.1 score: 5.9 | |
| AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N/E:H/RL:U/RC:C/CR:H/IR:L | |
| AR:L/MAV:P/MAC:L/MPR:L/MUI:R/MS:U/MC:H/MI:N/MA:N | |
| CVSS Base Score: 5.7 | |
| Impact Subscore: 5.2 | |
| Exploitability Subscore: 0.5 | |
| CVSS Temporal Score: 5.7 | |
| CVSS Environmental Score: 5.9 | |
| Modified Impact Subscore: 5.4 | |
| Overall CVSS Score: 5.9 | |
| 1.12 / : 7901 $ | |
| -----BEGIN PGP SIGNATURE----- | |
| iQEyBAEBCAAdFiEEdPSK0DAQPzUEfWzM7HvYsRM7ZKIFAl9zfqwACgkQ7HvYsRM7 | |
| ZKJsYgf4uwZzi9U1Nc4CxLFaR6pn5nCfT1CbssStivPLvaRAQuYuufY07PC1FENs | |
| xmMwmCH8WcOxM59p8uooWqdgMUQAcHrwaptl4V8iv4r8FOPCJVhJgnYCqITo46Yb | |
| 2vS84lCGd70Ha5+Q9zVjv1STQHm6221VIqF2pXeYQqa3fYt7AL4KkVqyxdHp7cbZ | |
| M3Gm+BFFH3KgaLhMgFbQEnIEhkIC5GJBA2W3YL8yh9ArJBkstRk8ZLiEpHn9Wft0 | |
| dfeWUreF9SL5kQTsLbA9vlTNQbbu/lQrNyzqZR1fNTmLcHDwArqpRmBLe6N16KW5 | |
| JulqN+b5V4FgK4qa2BOf7F3W90HA | |
| =fY0d | |
| -----END PGP SIGNATURE----- |