Quelltext der Seite GPN18:U2Fishing: Potential Security Threat Introduced by U2F Key Wrapping Mechanism

Ein Vortrag von Wang Kang auf der [[GPN18]].

More details 
------------

Basically, it's because FIDO standard allows Key Wrapping Mechanism.  So that the U2F device can only keep a master secret when secure storage capacity has a limit.

https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html#allowing-for-inexpensive-u2f-devices

My attack scenario is: 

1. The attacker extracts the master key during the manufacturing process of an open-source U2F key, in my case is U2F Zero. 
2. Attacker clone this U2F key. (In my case, I integrated it with a software U2F implementation.)
3. Attacker gives this U2F key to a victim.
4. assume the victim use this U2F key to register with Google. 
5. Attacker gets to know the password from another source. (such as social engineering, or other ways of password phishing)
6. Login.

You can find my PoC here:

https://github.com/scateu/U2Fishing/blob/master/03-key-wrapping.py

In fact, this attack can be detected when an anti-clone counter is well checked, because:

1. It's needed that attacker chooses a bigger counter number so that it's bigger than the last counter number that victim used to login. The best luck of the attack is choosing a counter number only 1 bigger than the counter number in the victim's device.
2. The next time when the victim login, his counter number is smaller than the number recorded on the website.
3.1 Maybe the victim think it is just a matter of network issue, and ignore it. And try again (the counter will increase by 1), and login successfully. In this case, the attacker will not be noticed.
3.2 When the counter number chosen by the attacker is much bigger, the victim will never login to the website again. Because the victim has to press the button on the U2F device a lot of times to make the counter bigger than the last success counter recorded on the website.
3.3 Another chance is that the website doesn't check the counter at all.

After some investigation, I found out that when a counter number revert incident occurs:

1. Some website like Gmail doesn't give a prompt, the webpage doesn't even blink. I don't think a victim will notice anything when this happens.
2. Worse, my email provider Fastmail.com doesn't check the counter at all. That means, at first victim login with a counter number (say 123), then the attacker login with a bigger counter number (say 9999) to pass the counter check, then victim login with a counter number plus one (this time, 124). Fastmail.com will not check. I have already written to them, and get confirmed.


A quick view of my experiment on youtube: 
https://www.youtube.com/watch?v=axKrtrOTfcY

Yubikey doesn't offer secret key regeneration.  You can see an official answer from https://forum.yubico.com/viewtopic.php?f=33&t=2484

As for other U2F keys, https://github.com/hillbrad/U2FReviews provides a glance at Yubico U2F Security Key, Thetis U2F Security Key, Feitian ePass, Bluink, KEY-ID FIDO U2F Security Key, HyperFIDO Mini, HyperFIDO U2F Security Key, Plug-Up Card Key, Fidesmo Card, SurePassID TapID Card, Feitian MultiPass and VASCO DigiPass SecureClick. At least none of them allegedly supports secret key regeneration.

== Links ==



{{Navigationsleiste GPN18:Vorträge}}