Code replay attack on the myGovID Scheme | Hacker News Reader

Code replay attack on the myGovID Scheme

thinkingcybersecurity.com

99 pointsshakna39 comments

Of course it's a student who has Vanessa Teague as an advisor. For reference, the Australian government leaned heavily on a major Australian university for her to be fired: https://www.theguardian.com/australia-news/2020/mar/08/melbo... as retribution for showing that 'deanonymised' data was absolutely not truly anonymised.

Thank god we don't have electronic voting.

Reading the article you've linked to, although the government department doesn't come off well, I can't see the part where "the Australian government leaned heavily on a major Australian university for her to be fired".

“The letter hints strongly at negative consequences for the university as a whole, particularly if I notified the affected journalist. The university did pass on that pressure, quite unambiguously, but I can’t really blame them.”

I suppose they 'hinted' which is what you do in all good threats. In general, the government in Australia is fairly hostile to cryptographers and security researchers that find problems with governmental projects.

After a lost decade of ineptitude and corruption, we've finally had a change of government. Fingers crossed.

The pressure was trying to influence the type of work being undertaken.

It may not be good but there's no suggestion there they were pressuring the place to fire her.

Not specifically in that article, but it was understood by her that continued employment was untenable if she actually wanted to keep doing what she was doing, which is why she quit. Remember that for some people actual integrity and honesty is simply part of who they are and they won't accept being muzzled.

For what it's worth, here's the letter: https://www.righttoknow.org.au/request/6092/response/16930/a...

I think what's most evident and bizarre is they act like there's actually significant research going on here: the researchers in question just pointed out how easy something was, basically (see https://pursuit.unimelb.edu.au/articles/the-simple-process-o...), and the university got this letter in response.

See https://twitter.com/VTeagueAus/status/1235067612318449664 with the indication the reason she resigned was entirely due to all of this plus some other stuff.

Fair point if you want to still argue they didn't directly have to fire her, I'll walk that back a bit and say that that was pre-empted and we lack the counterfactual of what the Department of Health would have actually done in terms of pressure had she continued.

> We strongly believe that instead of inventing their own authentication protocol, they should migrate to an open standard

Also

> We notified the Australian Government of this problem, and were told by the Australian Tax Office that they do not intend to make the recommended changes to their protocol. [1]

Aust Govt breaks multiple web-security 101 rules, bears no cost nor responsibility for it, and the cherry on top: they refuse to do anything about it.

[1] https://www.youtube.com/watch?v=TgPdVbUbtBM&t=311s

Isn’t this just a phishing attack? Almost any MFA service is vulnerable to this, but it’s not at all insurmountable if the user is sufficiently trained during the onboarding process. They even have an app which can leverage to help train users around the risks.

App-based OTP and push seems like a reasonable middle ground, short of supplying everyone with FIDO keys. It’s still better than SMS or email - or no second factor at all.

Is it a second factor? The article makes it sound as though the MyGovID authorization is all that's needed to log in, and the official site (https://www.mygovid.gov.au/) says it's used "instead of usernames and passwords."

The app is ‘something you have’, which you can only use after you authenticate into your phone with ‘something you are’ (biometrics), or ‘something you know’ (a PIN/passphrase).

I’m fairly sure the app does require you to enter a password after a set period or reboot - exactly like apple’s iCloud implementation (which IMO, is pretty good, or at least good enough for most individuals’ use cases).

Things are getting a bit confused lately though, as some models require that factors can’t exist on the same device, and there’s questions around keeping physical (‘have’)factors separated for different accounts and functions.

I don't know how it goes these days, but for a while only a few years ago, there were departments in Defence reading their email via HTTP (not httpS) webmail (IIRC it was Squirelmail).

It seems like the matter is a "won't fix" since september 2020.

>Responsible disclosure history

>This problem was disclosed on 19th August 2020 to the Australian Signals Directorate, with an indicative expectation of a 90-day disclosure period. ASD communicated it to the ATO. At a meeting on 18th September 2020, ATO told us they did not intend to change the protocol, at which point we immediately informed them that we would make a warning to users public on Monday 21st September.

From UI/UX point of view, it even got slightly worse since 2020: The user no longer needs to type the code. Instead, the same code is prompted and the user just needs to click "Accept" or "Decline", with "Accept" being emphasised.

It wasn't entirely clear if this is a disclosure I missed on 21st September 2020, or if they agreed to publish then sat on it for a year and a half. I think the answer is the former - the Youtube has a publish date from September 2020.

I couldn't spot a date on the article itself (perhaps it could be added to the HN post title); in case others are curious, wayback machine first scanned it 21 Sept 2020.

https://web.archive.org/web/20200101000000*/https://www.thin...

I have a bigger concern with myGovID. It pushes a notification, with "accept" or "decline". What happens if you accidentally hit "accept" when it wasn't you that logged in? There is no way to end a session/revoke a token from the app.

This occurs (occurred?) in practice for the Swedish e-ID system (BankID). There are examples of companies that don't want to pay to verify identities, and so will instead replay the codes to log directly into the Swedish tax agency website as the user to read their information from there.

News article about it, in Swedish: https://www.svd.se/a/yvMvle/skatteverket-utfardar-bank-id-va...

In Belgium they use https://www.itsme-id.com/ i don't think it's sensitive to this kind of attack.

It's great but it's kind of strange to depend on a private entity to log in on government websites.

https://geeko.lesoir.be/2022/06/28/les-belges-pourront-obten...

I think it's a UX friendly wrapper around the poor UX super annoying official 'e-id'. I don't think it's me would have space in the market if the official e-id was as easy to use and reliable as the official one.

They (belgian govt) are working on an alternative.

https://tweakers.net/nieuws/198482/belgische-overheid-werkt-... (in dutch)

yeah they first buy a 20% stake in the company. A year later some otherwise useless minister thinks the best course of action is to spend more money to build an app that does the same.

easy when you don't need to spend your own money!

you mean that same government that has the largest stake (20%) in the company?

Worked on something very similar and we chose not to move ahead with this kind of feature because of the phishing risk, without redefining the problem (like webauthn, Fido etc) it is very easy to dupe a user / replay attack. Most users don’t pay that much attention and friction hurts adoption.

Kind of funny the govt shipped the feature even with the spam risk and our more commercially oriented competitor product didn’t. You’d Hope they would be raising the bar for security not lowering it.

Am I missing something or is this just a run-of-the-mill phishing attack? If it is, then every website under the sun that doesn't use a FIDO or WebAuthn is susceptible to it. How is this any different?

In fact, Google has a very similar 2FA option where you can simply press a Yes/No on a mobile device you are already signed into, in order to authenticate another device. None of the this PIN stuff is going to do much to reduce the odds of phishing.

Yeah but Google requires you to also input a password, this does not. It only needs your email.

What I find problematic with MyGovId is how easy is to steal someone's identify. All you need are two documents like your Medicare card and driver licence.

These are documents that most people carry around in their wallet. Just gaining access for a few seconds to someone's wallet and take a couple photos to these documents, is all you need to impersonate this person through myGovId.

There are even night clubs where they make a copy of your driver licence as a requirement for entry.

In addition, as usual with any software system related to the Australian Governement, MyGovId simply does not work very well. For example, mine stopped receiving the 4-digit verification codes after an Android upgrade. After countless hours of resetting the application, re-entering the identity data, etc. I had to end up using my wife's phone.

Bit rich calling it code or even attack. Its a fake login portal? There are much worse problems on aus gov sites which all look and function like a hobbyists early project for the first job.

is this still relevant? the article is 2 years old, was the flaw addressed?

Not only was the flaw unaddressed, the decision was made to make it harder to see who is requesting the code - the app now only shows the user an accept/reject button. The replay attack can be done entirely passively, without any awareness that it has taken place, even by a user who is paying attention.

Reads for me like making trouble out of nothing.

Maybee I overread anything, but in general a Man-in-the-Middle is everytime possible when the user is not able to check if his communication partner is trustworthy.

The 'Analysis of impact' only bespokes the probability, but not what can happen and what besides of vandalism can be done with a login. And which goal a attacker could have that is valuable enough to justify the effort. Maybee nothing?

The mitigations beside 'Short term - for users' are all reading for me like bullshit. Displaying the URL in the App will not change anything, when the user didn't understand what he see in the browser, why should he understand it in the app? Clearly, with a private/public key infrastructure, this could be fixed, but unrolling a thing expensive like this is questionable for a simple Man-in-the-Middle attack with this little impact.

Sure, the mitigation isn't perfect. But I think the wider point is that as usual, the Australian government have implemented a shit scheme, full of obvious and rookie mistakes, when they should have just used a well known open standard.

Spelling out the very simple flaw is a means of underlining how poor this system is.

Reads like you know more than I. They use (more) than the state of the art security of Amazon, eBay, Facebook, Steam, Paypal and so on. Is the impact bigger than the impact that can happen on this platforms? And if yes, what is it?

Which impact can happen on Amazon, eBay, Steam? An attacker can steal your account and some hundreds of dollar of your money.

I wasn't aware of steam/amazon/ebay acting as an identity provider to login to other websites.

https://steamdb.info/login/

Steam does, Amazon I don't think so (just a pay via Amazon button I think)

I'm not convinced a well known standard would be any better against what basically comes down to "users might get phished". OAuth phishing against Microsoft accounts is a massive thing, I'm seeing it just as much as password phishing these days. It's regularly successful.

"Users might get phished" is not a binary. Some people will always get phished. However the more obvious that you make it that you're getting phished, the fewer people will get phished.

The current scheme apparently does not make it very obvious that you're being phished.

> Some people will always get phished

https://krebsonsecurity.com/2018/07/google-security-keys-neu...

Use WebAuthn. It is technically possible that your users are like "Well, the nice man needed my unique physical authenticator, so he sent a bike courier and I handed it over" but in practice that doesn't happen.

The authors point out:

> In the short term, the easy mitigation is to update the (phone) app to tell users where they're logging into. https://www.youtube.com/watch?v=TgPdVbUbtBM&t=4m25s

Reply on news.ycombinator.com