Data verification is based on device time, instead of verified server time

[NiccoloSegato]

Describe the bug

In the Android application it is sufficient to modify the device date to change the validity of a certificate. For example, by anticipating the date of the device, a certificate that has already expired can be verified.

Expected behaviour

The date and time should be taken from a certified and unique source, such as a government server, rather than the device date.

Steps to reproduce the issue

From the system settings it is sufficient to change the date of the device to change the result of the verification. It was tested with a certificate issued 11 days after the first dose, therefore not yet valid by law and rightly detected as not yet valid by the app with correct device date settings. Changing the date to a later date 15 days from the dose, then from the date of entry into force of the certificate, and performing the scan again, this gives a positive result.

Technical details

Any Android device

Possible Fix

The date and time should be taken from a certified and unique source, such as a government server, rather than the device date.

[vincenzoiovino]

Addendum: some phones don't use NTP at all if the mobile provider supports NITZ. Some others sync with GNSS. To be viable, this attack requires that:

• the subject of verification (aka the person with the green pass) is aware of this, otherwise he/she can object that the date and time of the verifier app are not correct when rejected
• the verifier "person" should NOT check his/her phone screen for the correct date and time label that is in the same app view of the check result

• the attacker should be in control for all of:

  • NTP via Wi-Fi (so: rogue Wi-Fi / MITM in Wi-Fi, or Wi-Fi jammer)
  • NTP via mobile network (so: rogue illegal base station or illegal jammer)
  • NITZ (so: rogue illegal base station or illegal jammer)
  • GNSS (so: rogue illegal GNSS transmitter or jammer)
• the verifier smartphone should have at least one of these technologies active during the "hack": NTP, mobile network, GNSS
• the verifier smartphone needs to sync its clock (it can be forced only by the verifier himself/herself)
• the verifier should not open any other app that uses internet (e.g. Facebook/Instagram/Whatsapp, for instance), as these app detects that something is wrong in SSL/TLS certificate verification (which uses the current time and date)
• other "good" green pass must be checked OK, so the manipulated time and date should be in a range that is acceptable (otherwise a person in the GP check queue might be falsely rejected and the tampering will be discovered shortly)

I think that these are good assumption for a theoretical attack, but a "real-world" attack won't be viable, due to hardware costs, risks (think about GNSS and illegal BTS transmitters) and limits[1]. We're still considering a green pass check, are we?

[1] You will need to have multiple antennas (2.4/5 GHz Wi-Fi, and a very long list of frequencies for mobile networks and GNSS) and wireless beams directly pointed to the verifier smartphone, this is not something that you can hide for a long period of time, and they will be difficult to move along with you. In case of Wi-Fi, you need also to discover the current Wi-Fi password and be able to overcome the signal from the current AP, or jamming the signal directly. The same for the operator mobile network. GNSS is the easier option, as GPS is not authenticated; however you should hope that the target smartphone doesn't support Galileo as it's authenticated.

Just a last comment. The "for all" is wrong. See our paper and presentation. Notice that also many bars and restaurants are using devices without mobile data, I have many examples around me. So in this case their device cannot use nitz etc.

[Enrico204]

Moreover, as explained in the previous comment, after the new update there is a new class of attack for which the situation is worse: in fact the attacker will not be interested in manipulating the time in relation to a specific dgc but will be interested in a statistical attack. [previous comment, ndr] After the new update an attacker can do the following. The attacker is not interested in passing without a valid pass. The attacker can for instance remotely manipulate the verifier's time inducing the verifier to suspect that the verifier close to him/her is suspicious, or just make the.verifier understand that there is an ongoing attack so that the verifier will need to verify all passes more slowly and eventually call the police. In a stadium or for a big event this is a big issue, just doing the attack once will cause panic in the verifier(s) and the queue will proceed much more slowly.

I still fail to see how these attackers are supposed to manipulate the time in a pratical manner, in such kind of events.

Big events or critical assets should have certified/secure devices. If they leverage on personal smartphones without any kind of security on-board, then issues are far bigger than this app.

But let's suppose, reductio ad absurdum, that somehow the app is running on security guard's personal phones. You still need to:

• hope that the phone of the guard is not in "airplane mode" or something like that
• mask any signal from the mobile networking, jamming the network or so (hoping that local enforcement units won't notice your antennas and some state security won't look at your jamming signal)
• mask any signal from GNSS or fake it (same as above)
• break into the Wi-Fi network (so you assume to have the password somehow or to crack it, AND that the network is willing to accept you - meaning no IDS/IPS, strong signal, etc) or create a fake AP and force the security guard to connect to the new AP
• trigger the time sync
• intercept the NTP request

I argue that this is good from a theoretical prospective, but fails to be a viable attack.

We showed at CCC 2021 how this attack is practical on many phones and in which situations it is practical.

If you're referring to the video about Immuni and the COVID-19 contact tracing system in Chaos Computer Club conf, I saw your presentation. However:

• here you need to target a very specific set of phones (the smartphone of the verifiers), not random phones
• in the video you do the same assumption as your paper, which are the same that I did here: https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/88#issuecomment-897630783 . In short: that you "control" ALL network connections of the smartphone, and you can trigger a time sync, and that no one will notice that.

Over thousands people if the attacker can succeed just once, this will cause alarm and panic with many social (and also epidemiologic) consequences.

This point is exaggerated on purpose. A single "success" in a big event will trigger a stop in a single queue, a check with a technician and a smartphone replacement.

I would argue that smartphone batteries will fail more often if you use commodity smartphones for stadium gates (in fact, airport and big stadiums have different kind of devices for ticket checks).

Just a last comment. The "for all" is wrong.

To say this, you need to assume also that the attacker knows which kind of connection is supported by the target smartphone, and you need to assume also that he/she knows the priority that the smartphone is using for time source (which MIGHT be inferred by knowing: the operating system, its version and which kind of modification has been done to it by the manufacturer - you said so in your paper).

Otherwise, you need to cover all possible network that the target can use to hope for success. So yes, if you don't want to do further assumption, you need to cover all network connections.

See our paper and presentation. Notice that also many bars and restaurants are using devices without mobile data, I have many examples around me. So in this case their device cannot use nitz etc.

I saw your presentation at CCC online, and I read your paper before writing my first answer to you.

I'm not saying that your attack doesn't exists. I'm saying that mitigate your attack will be hard without creating other issues (more exploitable than this), and that your attack is not so easy as you are presenting it.