-----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----- iQEzBAEBCAAdFiEEdPSK0DAQPzUEfWzM7HvYsRM7ZKIFAl9zodYACgkQ7HvYsRM7 ZKIctgf/arovCQHSz8tbXN2yQHswk4bR1Haut5HR8wI+GG/JzCCRk7MBiCxOeQJc f/+cYUCHYD63bpk+gMoj1H2p+wniEqBYxpMOvGcEPMhPprSqGTkYLQym19OJEG7X I61LXll2gxYNkYqz+ZeWmQvZ6r52NA4IJjP5wVYMXNtbyN5rpbTL/g+avBxtP2/N Wuu9IdW8iTWQGVI8i5FoXmBaEHFjwGMOMW7HChpC5/ZKEEiCPYOyfK8Lr6J6XORa 4J2KK2GYufG/cJ74JF0/IIKcdI7/KABiP4OCiiIf70h/lg7I2qpIK7oJ5gw23y3i IPh8a0FzYDSBYkwIHK/qP+nHezLwuw== =zNdY -----END PGP SIGNATURE-----