Cwa-app-android: [BSI][20200807] App Snapshots Reenabled

Created on 7 Aug 2020  Â·  15Comments  Â·  Source: corona-warn-app/cwa-app-android

Rating: Medium

Description:
In the most recent version of the Android app, app snapshots have been enabled again.
When the app is sent to the background, Android takes a snapshot of the latest view of the application and saves it without encryption on the file system. Therefore, the snapshot should not contain any confidential data.
On Android, the snapshot is stored in a system directory. Access to this location requires an attacker to have root privileges. Such an attacker can access these snapshot images and capture the disclosed data. Additionally, users are probably not informed about this risk and can accidentally impact confidentiality.

Proof of Concept:
The following screenshot shows that the contents of the app screen are visible in the snapshot:
Android App Snapshot

Recommended Controls:
It is recommended to deactivate the snapshot functionality. This functionality can be disabled by setting the FLAG_SECURE attribute in the display class of the application.
The following links provide more information regarding the FLAG_SECURE attribute:


Internal Tracking ID: EXPOSUREAPP-2052, EXPOSUREAPP-2613, EXPOSUREAPP-2612

bug mirrored-to-jira on hold security

Most helpful comment

I think that any complication of current implementation, either by adding some additional switches for enabling screenshots, or disabling screenshots all-together, should be weighted against other existing threats. The unfortunate truth is that the basic architecture of this contact tracing system inherently does not guarantee the privacy of user's exposure status - and attacker does not even need to gain root privileges. A simple malicious app which is just listening to received Bluetooth beacons would be able to infer exposure status (no root, just location access). This attack vector is orders of magnitude more likely and less complicated than any attack which targets screenshots - but still the probability of it seems to be sufficiently low. Disabling screenshots will just make users more frustrated and hinder reporting of the errors.

All 15 comments

This issue reiterates #9 from back in the pre-release days.

The ability to take screenshots has been re-enabled after it has been widely requested cf. e.g. https://github.com/corona-warn-app/cwa-app-android/issues/516.

Also: this is a functionality which has always been available for iOS, but wasn't under Android until now.

Given that root access is needed to grab those automatic snapshots I personally don't see how this could be widely abused.

Also, with root access, an attacker could come up with the same risk status like the app itself. So disabling screenshots does not help a lot against disclosing the risk status.

Well if the attacker gains root privileges then screenshots can be simply enabled with:

Java.perform(function () {
  var FLAG_SECURE = 0x2000;
  var Window = Java.use("android.view.Window");
  var setFlags = Window.setFlags;
  setFlags.implementation = function (flags, mask) {
    flags &= ~FLAG_SECURE;
    setFlags.call(this, flags, mask);
  };
});

but no functionality of taking screenshots can make error reporting more difficult for users.

If 'BSI' is, what I'm thinking it is, 'TF' is task force, and @BSI-TF-CWA is actually a member (and not hijacking abbreviations for her/his username) then this 'bug' report is possibly the fastest way of communication to the developers...
https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2020/Corona_Warn_App_160620.html

If you're only looking from the security perspective on this issue, then this bug report is a 'must do'. I believe, the functional perspective intentionally stayed unfocused here.

From the functional perspective, personally I'm with you all.

@vaubaehn this is real BSI, they also opened the original issue #9 😉

If you're only looking from the security perspective on this issue, then this bug report is a 'must do'.

I don't see how tbh: what kind of threat model are we envisioning? As @mh- and @kbobrowski stated: as soon as you have root access (which is required to access the system dir with the snapshots) it's game over anyway, the additional protections will not help against an attacker with such privileged access.

If we're otoh talking about a non-rooted phone: I don't see the security risk in this scenario, as an attacker has no access to the dir with the snapshots in the first place.

@daimpi , I'm completely with you. :)
But if you are a member of BSI (or in any other job in IT security), then it's purely your job to always give highest attention to security, even if you need to handle with very low risks in practice. Functionality comes second, if ever...

I guess the TF created some risk scenarios.. If only a very small percentage of users root their phones, and if only one of them gets somehow malware downloaded to it, a stupid script kid gains remote access to that device, and that kid posts some taken screenshots as a proof of concept or for whatever publicly, then the whole project has a very bad (reputational) problem, even the practical damage is peanuts.

And we're handling here with sensitive medical data ('high infection risk', uploaded positive test...), according to Art. 9 – EU-DSGVO – Verarbeitung besonderer Kategorien personenbezogener Daten that need to be protected especially. Illegal root access + fetching some data to identify device owner + these sensitive CWA data = worst case scenario.

in addition to @daimpi

as soon as you have root access (which is required to access the system dir with the snapshots) it's game over anyway, the additional protections will not help against an attacker with such privileged access.

Right, but until now there are no snapshots at least of CWA. So there may be damage, but not related to CWA. That changes, when there are also snapshots with sensitive data available...
And all other local storage data of CWA is well protected, see 'Error 9002' ;)

Right, but until now there are no snapshots at least of CWA. So there may be damage, but not related to CWA. That changes, when there are also snapshots with sensitive data available...

I don't think that's quite right: as described by @kbobrowski above: you can simply overwrite the screenshot protection with root privileges and take screenshots no matter what protection CWA has in place.

@daimpi ha, here you go. Right!
But in that case, at least RKI/CWA/BSI can tell, it was not their fault and from their side eveything possible for security had been done.

@ all
is it possible for CW-app to set FLAG_SECURE during the onboarding? And can the status rooted/non-rooted phone be checked by any ordinary app?
If yes, then flags could be set depending on the status rooted/non-rooted accordingly... Screenshots for unrooted devices, owners of rooted devices need to set their flags on their own with https://github.com/corona-warn-app/cwa-app-android/issues/987#issuecomment-670525906 ;)
That might be a good compromise, if it works. Keeping stakeholders free from the legal aspects, giving functionality to whom it needs (non-nerds).

Edited:
OR - if it is technically possible to set the flags anytime from inside CWA (which I guess it is):
Add a switch to the 'settings' screen to allow for screenshots. Schedule a job to automatically turn switch/screenshots off again after 10 minutes. This would allow users to take screenshots at least with reproducable bugs ;)
And to address one additional issue shown by BSI-TF-CWA in their description above

Additionally, users are probably not informed about this risk and can accidentally impact confidentiality.

When turning on the screenshot switch, a short message about the (practically low) privacy risk may be prompted where user gives informed consent by clicking 'ok' (or declines by 'cancel'). Then everything is covered: lower risk by screenshot-on-demand, informed consent.
Would this be a way to go, @BSI-TF-CWA ?

I think that any complication of current implementation, either by adding some additional switches for enabling screenshots, or disabling screenshots all-together, should be weighted against other existing threats. The unfortunate truth is that the basic architecture of this contact tracing system inherently does not guarantee the privacy of user's exposure status - and attacker does not even need to gain root privileges. A simple malicious app which is just listening to received Bluetooth beacons would be able to infer exposure status (no root, just location access). This attack vector is orders of magnitude more likely and less complicated than any attack which targets screenshots - but still the probability of it seems to be sufficiently low. Disabling screenshots will just make users more frustrated and hinder reporting of the errors.

Just an FYI. I've already proposed a solution in https://github.com/corona-warn-app/cwa-app-android/pull/619 that just disables the screenshots for the Tan entry screen, however unfortunately it got overlooked for some reason.

Hello @R4md4c,

tanks for sharing. I will point the right guys in that direction.
@pwoessner can you please check that PR: https://github.com/corona-warn-app/cwa-app-android/pull/619?

Thanks,
LMM

Corona-Warn-App Open Source Team

This issue has been marked as obsolete and will be closed now.

Hello community,

we will be tracking this issue from now on with this ids:

  • EXPOSUREAPP-2613

  • EXPOSUREAPP-2612

The thread will be reopened.

Thanks,
LMM

Corona-Warn-App Open Source Team

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ironjan picture ironjan  Â·  3Comments

Diapolo picture Diapolo  Â·  3Comments

michaelwingender picture michaelwingender  Â·  3Comments

Alestrix picture Alestrix  Â·  3Comments

wmertens picture wmertens  Â·  3Comments