Universal 2nd Factor (U2F) is an open authentication standard that strengthens and simplifies two-factor authentication and has been used by Facebook, Google, Github etc. The keys stored in U2F tokens with secure element chips are considered impossible to be extracted. However, the capability of key pairs storage is limited by secure element chips, FIDO U2F standard allows a key wrapping mechanism which enables unlimited key pairs with limited storage. It's considered safe, but not with an evil manufacturer.
In this talk, we will give a real-world example of U2F phishing attack by retrieving the master secret from an open source U2F token during the manufacturing process and then give that U2F token to a victim user. Then we can clone that U2F token by implementing the same key wrapping mechanism with the master secret recorded. We will give a demo that Github, Gmail, Facebook can be affected using this kind of U2Fishing method.
Some countermeasures will be discussed. Investigating some websites that provide U2F as a two-factor authentication method, we found out that some of them haven't implemented cloning detection function which is recommended by FIDO Alliance so that U2Fishing victims will not be aware of when the attack is started.
This attack will still work even if cryptography secure element chip such as Atmel ATECC508A is used by U2F token with key wrapping mechanism. It's recommended that end users should at least do a master secret regeneration process when given a new U2F token with key wrapping mechanism. It's currently unavailable for Yubikey.
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.