exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Corona Exposure Notifications API Data Leakage

Corona Exposure Notifications API Data Leakage
Posted Sep 30, 2020
Authored by Dirk-Willem van Gulik

It appears that the corona virus Exposure Notifications API for iOS and Android may have a data leakage issue.

tags | exploit, virus, info disclosure
systems | ios
advisories | CVE-2020-24721
SHA-256 | 8e18dbc56574e080e742895300d9e809339058ef58eb5d6a3369cb6d7a66780a

Corona Exposure Notifications API Data Leakage

Change Mirror Download
-----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-----


Login or Register to add favorites

File Archive:

June 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    0 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    18 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    57 Files
  • 7
    Jun 7th
    6 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    12 Files
  • 11
    Jun 11th
    27 Files
  • 12
    Jun 12th
    38 Files
  • 13
    Jun 13th
    16 Files
  • 14
    Jun 14th
    14 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close