Data verification is based on device time, instead of verified server time #88
Comments
|
A possible solution is to force the connection to internet the first time and syncronize a variable with the server. |
|
How is this a bug of this app? This is part of how offline certificate verification works. If I change the date of my computer backwards I can also browse on websites with expired SSL certificates, duh. The threat model for this app involves trusting the person executing the check. Otherwise, even taking the current date "from a certified and unique source" would be useless. A malicious checker could just use an altered version of the app that skips any verification and accepts/rejects any certificate. |
|
@NiccoloSegato I don't think this is really an issue imho. It is in the best interest of the checker that the app works as intended (with the time correctly set) as it is the only way for them to ensure that, in the case of a restaurant or a gym for example, they can't get in trouble for letting people without a valid Covid Certificate in. Moreover, as @jacopo-j pointed out if a checker really wanted to "maliciously" let people with unvalid certificated in while still appearing to be checking with the app (to show other clients of the restaurant that they are checking the DCCs, for example) it would be easier for them to use a modified version of the app because by changing the time of the smartphone you would probably invalidate equally as many actually valid DCC's as you would make non valid ones look valid (think of the DCC's for a COVID test that only last for 48h). I hope i have been useful ;) |
|
Can we please stop spreading misinformation and false bugs on Github and elsewhere? Pretty please? This is clearly not a bug and does not violate the threat model at all. Assuming both the certificate owner and the verifier are accomplices and want to fake the checks does not make sense, as they could do it in a billion ways with no official app at all. A few online newspapers are already spreading the "news" about this "bug", scaring away non-tech-savvy users and reducing trust in the digital certificate. By the way this "bufala" has been around for a few days already. https://mobile.twitter.com/EnricoBassetti/status/1418935571691548685 |
|
I reported the bug right here on Git to avoid confusion, bringing it to the attention of developers and the development community. |
|
Sorry if it seems that I am targeting only your report specifically, but this is the last straw of a too exhausting series of misinformation on the Green Pass that originates from a lack of understanding of how offline verification should work (and the threat model). First, there was Italian Tech with an invented "flaw" (they then amended the title, but still): https://www.italian.tech/2021/07/31/news/il_sistema_del_green_pass_ha_un_buco_di_sicurezza_la_scoperta_swascan-312372691/ And now this GitHub issue, which has already been exploited by Punto Informatico to create a fake news about a "severe bug": https://www.punto-informatico.it/green-pass-verificac19-app-grave-bug/ (for instance, I indeed discovered this issue because of the fake news article by Punto Informatico) |
|
Well, this is a bug that is not acceptable on a SW that should be certified as a medical device and it can not because the undergoing HW device is not certifiable at all (being any smartphone). Apart that, the solution is very simple. Considering that the app should work at least 24h offline is sufficient to synchronize the system time using the internal GPS every N minutes. So, to assure that the verifier does not alter the system time, should be implemented this procedure:
|
|
@aiotech-pub this is not a bug, stop spreading misinformation. A evil verifier will use a false app to scan the green pass, if ever. There is no improvement in the threat model if you force a time sync like that. The verifier can use another app with a similar screen. Or it can ignore the verification at all. Also, this is not a software for a medical device, or any sensitive device. Those devices are already protected. |
What in the name of... Are you talking about? It's a reader app, it needs to read something. If the user does not want to care about the correctness of what is read they can simply avoid reading it all together. Moreover, it is not a medical device even by the broadest definition you could possibly invent. |
|
I am not inventing anything I have more than 25 years experience in R&D of medical devices and I know their regulations. A SW that manages health data shall be certified following the MDD 93/42 and this type of SW falls inside the definition at article 2 point (a). And for the same article the SW and the device where it is installed is a "medical device" so it has to be certified. And, considering that the app may be installed in any Android and iOS smartphones on the market it is IMPOSSIBLE to obtain the certification so this SW should be retired by the market because is not MDD 93/42 compliant and its use without the certification is illegal. In the next days I will inform the regulatory boards asking for urgent seizure of this SW. Laws and regulations have to be valid for everyone there are too many similar cases of similar SW stopped by MDD 93/42 art. 2-a. |
|
Second... is available a QR code just for testing? I mean a fake but working QR to test the app with a reference QR? Or do you havea test SW to make fakes QR for testing? If you don't have them how did you test that the app is working properly? And is available the app testin plan? |
|
What about the hardware? Shouldn't it be certified as well? spoiler: no. It's not a medical device. In Any means. Full Stop. |
|
Please read better what I wrote and then read the MDD 93/42 art. 2-a and you will learn something. I am not alone thinking that and in any case the regulatory board will decide not you. Who are you to say it is not a medical device? Are you an expert on MDD 93/42? Do not say me full stop, you can't. Right? |
|
Ok you just need to make a certification on all the hardware. Good luck. ...and... "full stop" 🤣 |
In order to understand this you would need some experience in software development and information security. |
No. This is the MDD 93/42 article 2 point (a):
See https://www.salute.gov.it/imgs/C_17_pagineAree_1636_listaFile_itemName_1_file.pdf Let's see if this software falls in these categories:
|
|
If, and only if, this app will ever be able to "diagnose, prevent, control or cure" the SARS-Cov-2 disease, then it will be a medical device. However, this app is not (and never will be) able of doing that. The only feature of this app is to pick a signed QR code and verify the signature (and the expiration). |
|
Enrico204: first of all the valid text of MDD 93/42 is in English, so the word is "monitor" that does not means - exactly - "controllo" the nearest translation is "tenere sotto controllo" meaning a form of control during a period of time. So this is an app to monitor the state of disease, because the QR comes from (also) a result of a diagnostic test (green pass) and certifies if a person is negative or not to the test, the test is a system to say if a person is or not infected by covid so because the app reports the result of a test it is part of a monitor system. For this reason IT IS a medical application that has to be certified. Not so difficult to understand. |
|
The proccess which is used to emit a certificate is certified.
|
|
Guys, please, not be offensive without knowing who I am. My name is Massimo Manca, I am a well known consultant also in the field of cybersecurity, payment systems (certified by NXP for R&D using secure microcontrollers, NFC, secure memories and security components in the foeld of payment, ATM and credit cards) so I think to have just alittle more experience, practice and know-how you supposed i may have. If you have not used any fake QR code to test this app you can not be defined "professional", you have no idea about how serious has to be the testing procedure of a sw application and at this point I can understand why so many people contacted me saying that they are not able to use the app just using some of the QR they have (their personal QR and that of some relatives, friends and so on). Guys, have you any idea that if they will document that the app sometimes works and sometimes no (and this will affect their income) how many claims for damages will opened on the courts in few days? |
Do you mean the Professor of Latin Literature at Ca' Foscari University of Venice, or the one who has got a website accessible in plain HTTP? Nevertheless:
Feel free to test as many QR codes as you wish. The codes are digitally signed by the Ministry of Health and the specification is freely available, also documented on various websites (example). The production version of VerificaC19 uses the official certificates to verify the signature, but for testing purposes you might as well build your own version using testing/development keys.
LOL this thread has seen participation by several software developer, but whatever. If you think you have found a way to break the standard cryptographic routines that are used by the app, or proved that P=NP, you should go and claim your well-deserved prize. |
Can you please share a link with the original text, as I did?
No, the app NOT is meant for monitor the disease, and you said so:
That is the point. The green pass MAY come from a diagnostic test. However, this app won't differentiate between green pass done with tests or green pass done for whatever other reason. And, most important, the app won't check the "health-related" data of the test. In fact, this app checks only the QR code signature. Which may come for whatever reason the certificate emitter think is possible. The MDD 93/42 covers medical devices. This is a signature checking app. This app won't emit certificates.
I'll just skip commenting this part.
Why you think that we didn't do any test? Also: have you read the documentation? The underlying technologies are very battle-tested and standards. Literally the whole internet works thanks to those technologies.
If you have any reproducible case of issue reading the QR code, you can open an issue. This issue is relative to the data verification "problem" (which is not a problem at all) |
|
because it may come from a diagnostic test it is mandatory to follow the MD 93/42 and the app needs to be certified. That's all, may is sufficient. |
|
This is an original copy, go to page 5 and 6: https://da4284glbbt4.cloudfront.net/Directives/MDD%20Directive%2093_42.pdf |
|
User testing is an essential part of testing. If you don't test the app against what it is supposed to test you are not a professional, you are just playing. I am used to develop SW and HW on critical medical devices and other fields where errors and bugs as well are not accepted. I/we are used to develop assuring "zero errors against requirements", I understand this app is very far from this situation if nobody test the app against a set of different QR codes (also if they are fakes) simply because you can not demonstrate to had tested afgainst them that is very very very stupid. |
|
No. The certificate is coming from the diagnostic test, not the app result. The app verifies of validity of the green pass document, not the validity of the test. From the document you linked:
This app won't do a diagnostic test, won't prevent, won't treat and won't alleviate the disease. The app checks only the signature of the green pass. The app don't check that the green pass data are "correct" from a clinical point of view. The app checks only that the signature of the document is valid.
Again, why you say that? Do you have any proof that the authors of this app didn't test the app with any user? If so, please post them here.
This is not a medical device.
You're accusing someone that they didn't test the app. However these are false claims, because authors send you a reply with details about app testing material that they use for testing: #94 . So, testing is part of the development process. Also, another user replied to you with details about testing material from official authorities here: #88 (comment) |
Please correct me if I'm wrong, but the app does differentiate between Vaccination, Recovery and Test certificates as this is reqired to check whether the DCC is still valid from a temporal stand point. This "date of expiry" is not present in the json data (AFAIK) but has to be be inferred from the type of certificate. If the app only checked the signature every DCC ever issued by trusted party would always be marked as valid |
Correct. However this is only for the expiration. What I meant is that the outcome "OK/KO" is not based on a health-related information, and the app doesn't validate the type of certificate from a clinical point of view. So the app is not a medical device. |
|
|
Pro-tip: facts are not true or false based on what you like to write on Github. There is no "ipse dixit" approach in software development, especially when "ipse" is a user who appeared out the blue demonstrating they did not study the functioning of the app nor the threat model. |
By reading the DGC SPEC 1.0.5 and the JSON Schema Specification you can see there are two expires:
I might be wrong and I let @Lazza or @Enrico204 chime in on the correctness of my assertions, it looks like they have been working on these specs for a while. I just started looking into this and to be honest I am amazed that the EU, the same authors of the Cookies Consent Banner, this time used some battle tested de-facto standard technologies instead of training all of us to click "Accept" buttons without reading what we are doing like Pavlov's dogs :-) Just kidding! |
|
There are many flaws in data and time management in this app. May be interesting for a user to move the system data behind or beyond the real depending what he needs to do, just checking the certificate emission date (certificate valid from) the problem may be reduced but not solved, so it is essential to guarantee that the user can not move the system date. The problem born because this app is a fork of the EU app that as written in the specifications will be used by sanitary and airport/port security personel, instead in Italy it will be used by private persons. |
|
@aiotech-pub I have mixed feelings about your point of view. First of all, I wonder if a medical-grade ultrasound scanner that I believe should honor MDD 93/42, does checks for its correct date-time by calling an NTP server and validates its time zone. The last I saw was running Windows 95 (10 years ago), and it had a time drift of some hours. But that's really not the point. That machine function is to check if babies are doing fine and not to validate a certificate :-) I am not a legal expert, and I let legal offices do their work. However, I believe that private citizens should have the same moral obligations as "sanitary and airport/port security personnel". But I see what you mean. For example, one could be in charge of checking people getting into a party, see someone in the queue that doesn't want in, and by temporarily putting the date a year in the future will make this app report the pass as invalid. From an engineering point of view, this is not a bug. The first requisite to verify if something is expired is to have a correct date-time set in the device checking that. This is where the UI conversation comes in. Try to put your laptop three years into the future and browse the internet. If you can reach your browser because I have experienced that all the app I was running started to report errors. This is what Chrome reports. The browser is doing that extra step to tell the user what is wrong.
So while I disagree that this is a flaw of any sort, I believe you have a point, and this is a valid feature request. A feature request that the owner of this repo should consider because, on the one hand, there are a few lines of code, and on the other hand overcoming the unjustified skepticism that already exists in our Country regarding this green pass. |
I repeat, the app doesn't validate the type of certificate from a clinical point of view. This is a fact. To verify this fact, please open the source code of the app and check yourself. After that, please tell me the part where the app is checking from a clinical point of view the certificate. Please link those lines of code here.
An airport security officer will not use his/her personal smartphone to verify EU green pass. The airport security authority is providing locked and certified devices to all personnel for this kind of verification. If a local administrator fails to lock and certify a device, then the user can manipulate the device in every possible way. An app can't do anything. This is a basic cybersecurity principle. Also, an evil verifier (I mean, "an evil person") simply:
This is in the threat model. There is no way for this app to protect from these actions. |
I'm not the maintainer of this repo, so it's not up to me to decide. However, I think that the proposal of checking the local time is not feasible, and it will change a lot of the architecture for a little gain. Let make an example: if you use the simple-yet-useful solution of checking time via (s)NTP, then you might add these issues in the threat model:
Let's say that you use GNSS (satellite location):
As you can see, there are a number of problems choosing this approach. And basically all approaches won't block an evil verifier that modifies the app, or install another app, or simply skip the whole green pass check. Currently, the app is showing the date and time of the scan (meaning, the current date/time). For a non-evil verifier using a "manipulated" phone is ok (he/she is supposed to verify the person ID data) |
|
@Enrico204 thank you for your feedback As I understand, the app periodically (every 24 hours?) calls back the backend to fetch the updated list of public keys and the business rules that determine if the pass is valid, like Here is the code I am referring to: Here the documentation: https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#appendix-a---trust-management If we store a hypothetic Furthermore we could also check the the HTTP I know it's not perfect, and there are edge cases, but at least it is helping the user to repair a misconfigured device while assuming good intention. |
Wait, are you assuming that a malicious actor that wants to alter GP checks will kindly obey to a friendly warning? |
|
Hi @Lazza If the person checking these green passes (let's call them the concierge) doesn't allow someone in, the evil concierge must show that the pass is not valid. If the app instead reports a date-time warning, I think that is valid feedback for the victim too. At this point the victim can kindly ask the concierge to fix the date of the phone or call the police. I also envision a genuinely misconfigured device as I said by assuming good intentions. |
Or the bad guy could just use a custom fork of the app that shows "OK" or "invalid" depending on an arbitrary choice, a parameter, the press of a button or whatever. |
|
@Lazza sure. You are totally right. What seriously worries me is that as of today, a concierge of a venue can discriminate and exclude people. What is needed is two phones both running the official app from Ministero della Salute. One with a system date a year in the future. One in each pocket. A year in the future is enough to invalidate all QR-codes out there by The phone with the date in the future will report that the green-pass is not valid and the guest will not be admitted. I agree this kind of discrimination is a crime no matter what, but I believe we could send a better message to the green-pass skeptics by implementing a check that the device can actually validate those QR codes and some sort of EDIT: authentication and authorisation do not solve the scenario of a custom fork of the app that shows "OK" or "invalid" depending on button or whatever as @Lazza pointed out. The problem is the authenticity of the scanning app. EDIT 2: I am honestly having a hard time finding a solution to guarantee the authenticity of the scanning app and rule out the problem where a concierge has one that looks identical to the official but gives green or red depending on whether the volume up or down button is pressed during the scan. It is a counterfeiting problem similar to a fake but perfectly reproduced ATM that holds my card just after I have punched in my pin. My 2 cents. |
Actually, the app is already showing the current date and time (the date and time when the scan happened), and the last update in the main view (iirc at the bottom of the view). So it's pretty easy to check those values (both for the verifier and the user) in case of issues. Anyway, I think that your suggestion is good and can be implemented without issues. However I still think that an evil verifier will not use the original app (or an evil "owner of device", in case the person that checks GP is not aware of the device tampering).
Actually, as @Lazza said, the "simpler" solution for an evil verifier is to ask his/her cousin (i.e. the one that is "good with computers", "an hacker, whatever this means") to create a fork with custom actions and answers.
I think that this check is not needed, because:
So it can be done, however I don't see any real advantage in this check. Setting Thanks everyone for your ideas! |
|
@Enrico204 I haven't noticed before but I can confirm that the app actually reports the scanning date. Thanks! p.s. the time validation I am talking about is not the "after the swab result" but the one defined on |
|
For what it is worth, I vote in favor of closing this issue. This conversation already happened ~2500 years ago with Plato and later Giovenale "Quis custodiet ipsos custodes?” |
|
Thank you all for the comments, explanations and implementation ideas that have emerged 🙏🏼 |
|
Hi, Disclaimer: This thread was very long, I did not read it all so I apologize if somebody already discussed this earlier. Kind regards |
I suggest you to read the whole issue before writing anything else. These problem that you are rising have been already discussed. TL;DR the (original) verifier app shows the current time and date, so:
So, when using the "original" app, this issue has been already mitigated. If you consider the possibility of a fake app or evil verifier, there is nothing that anyone can do currently, of course (as the green pass check might not occur at all). Also: some solutions has been discussed above: #88 (comment) and #88 (comment) . Also (2): this app is meant to be used by non-critical sector operators. Airport security, military, etc, they should already have proper hardened smartphones (or devices, in general). |
|
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:
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. |
Ok. I see you already discussed this. But it is worthy to point out the above reference for me since they regard the same class of attacks to another project of National interest so it is more surprising to see that this attack again affects another project and you did not take in account previous known literature and issues. I had seen the update of 9th of August. |
We showed at CCC 2021 how this attack is practical on many phones and in which situations it is practical.
You just point out 1) and I do agree. I also point out 2). 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. |
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. |
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:
I argue that this is good from a theoretical prospective, but fails to be a viable attack.
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:
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).
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.
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. |
and others
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.
The text was updated successfully, but these errors were encountered: