Message-Id: CVE-2020-24721-78975@webweaving.org
Date: Tue, 29 Sep 2020 23:06:33 +0200 (CEST)
From: Dirk-Willem van Gulik <dirkx@...weaving.org>
To: fulldisclosure@...lists.org
Subject: [FD] CVE-2020-24721: Corona Exposure Notifications API: risk of
	coercion/data leakage [vs]

-----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-----

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists