search

corona-warn-app / cwa-app-ios

Native iOS app using the exposure notification framework from Apple. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
1.68k stars 284 forks source link

[BSI][20200831]Plausible Deniability Flaw #1100

Closed BSI-TF-CWA closed 2 years ago

BSI-TF-CWA commented 4 years ago

Rating: Low

Description: The iOS and Android apps implement a playbook that includes multiple fake request on each valid request. The goal of this measure is to prevent attackers in privileged network positions, that can observe encrypted TLS traffic, from inferring which actions were taken in the app. However, this implementation on iOS is partially flawed. Each valid request leads to two additional requests. If, for example, a QR code is scanned, leading to the device registering itself, at least 6 requests, as opposed to 3, are sent. This fact can be used to infer that a user has added a QR code. Due to the unavailability of valid TeleTANs, it was not possible to check if they induce the same behavior. Depending on whether they do, an attacker could either infer that a user has recently been tested or that a user has recently been tested or is infected. Nonetheless, the core issue that an attacker could easily infer that a user is infected is mitigated by the introduction of these fake requests as individual requests to the submission server are not useful to an attacker anymore.

Proof of Concept: A script was developed that records TLS connections to the verification and submission backend. The script is attached below. In the following, the output of this script is given for a set of different activities, showing the resulting requests:

Using an arbitrary (unknown) TeleTAN:

Adding an arbitrary (unknown) QR Code:

Update Test:

Adding the same QR code (which should have an invalid UUID now):

Recommended Controls The playbook should be adapted such that, regardless of the action taken in the app, the network requests look the same. A possibility, for the QR code related requests would be to add a delay between the two real requests. This would lead to two individual triples of requests instead of six at a time. In this case an attacker would observe the following request sequence:

– Server: Verification Server (real request) – Server: Verification Server – Server: Submission Server

– Server: Verification Server (real request) – Server: Verification Server – Server: Submission Server

Instead of the current sequence:

– Server: Verification Server (real request) – Server: Verification Server (real request) – Server: Verification Server – Server: Verification Server – Server: Submission Server – Server: Submission Server

Which would look more like the other playbook sequences.

Internal Tracking ID: EXPOSUREAPP-2314, EXPOSUREAPP-2354

Ein-Tim commented 4 years ago

Somewhat related: #1076

Ein-Tim commented 3 years ago

@dsarkar Maybe you would like to check if this Issue is still here in 1.7.1?

@jstohner already stated 4 months ago that this will be solved by 1.3.0.

dsarkar commented 3 years ago

@Ein-Tim, thanks. Added link to this issue to Internal Tracking ID: EXPOSUREAPP-2314. Best, DS

Corona-Warn-App Open Source Team

Ein-Tim commented 3 years ago

Any updates on this issue?

Ein-Tim commented 3 years ago

I think this has been solved in the version 1.3.0 release.

See PR #1004 & #1031.

Could you clarify this @GisoSchroederSAP (mentioning you because you‘re assigned)

Edit: The PRs I linked to were merged before this issue was opened, so probably this issue is about the functionality which has been implemented with #1004 & #1031. I'm a bit irritated by the issue #1076 where @jstohner stated that 1.3.0 will fix this.

heinezen commented 3 years ago

@Ein-Tim

No, the ticket is still valid, but there aren't any updates so far.

See PR #1004 & #1031.

I believe the mentioned PRs introduce the plausible deniability feature, while this issue is here because the feature does not fulfill all requirements of the BSI under specific circumstances.

Corona-Warn-App Open Source Team

Ein-Tim commented 3 years ago

Okay @heinezen, thanks for the clarification!

Ein-Tim commented 2 years ago

We have not seen any new BSI reports here on GitHub in the last months, I guess they now report security issues directly to the project team, without creating publicly visible issues here.

There seems to be no process on this issue, the "To Be Reviewed" label is applied here since nearly 2 years. If it was already reviewed, please remove the label. It it was decided not to fix this, please close this issue. If this issue was fixed, please also close this issue.

svengabr commented 2 years ago

I have just checked the linked Jira issue.

Jira Ticket is flagged as: Resolution: Wont Fix Status: Obsolete

Developer comment:

Requirements captured in story EXPOSUREAPP-2354 - will be realized depending on RKI prioritization - bug is set to obsolete.