4 ms·

Relaying Yubikeys

26 points by popcalc 4y ago

i_am_proteus 4y ago
There's no obvious link, but there's a Part 2: https://cube0x0.github.io/Relaying-YubiKeys-Part-2/ https://cube0x0.github.io/Relaying-YubiKeys-Part-2/
stavros 4y ago
Wait, how does this work without the key flashing and needing to be touched?
- etskinner 4y ago
  Presumably you would trick the person into touching the key. Similar to getting someone to put their password in with a phishing attack.
- pelagicAustral 4y ago
  I was thinking the same thing. I guess you would need some sort of XSS to get the user to touch the key. I've seen the web dialogues on Beef and they can be quite convincing, but still doubt this will work with any significant sample of victim/users.
- g_p 4y ago
  This appears to be using the PIV "smartcard" applet. I believe one option on each certificate in the PIV applet is whether or not a "button press" is required for its use. I believe it is recommended that the device attestation certificate at least is not guarded by the button press. The threat model for yubikeys is to prevent the key being cloned - if it's in your pocket, it's safe. If you plug it in, and authenticate by PIN to the PIV applet, and push the button when prompted, someone may be able to generate a signature.
- michaelt 4y ago
  The fancier Yubikeys have multiple functions - not just the basic U2F. One function is 'PIV' - acting as a 'smart card'. When you create or load a key, you can choose whether you want to require a button press or not [1]. They strongly recommend requiring a button press. No physical button press = an attacker with root can sign things at will. [1] https://docs.yubico.com/yesdk/users-manual/application-piv/pin-touch-policies.html https://docs.yubico.com/yesdk/users-manual/application-piv/p...
  - fmajid 4y ago
    I tend to get the U2F-only Yubikeys (a.k.a "Yubico Security Key", they are blue instead of black) because I don't want to inadvertently start relying on Yubico proprietary functionality, and they are cheaper. This is just one more reason to do so.
- anecdotal1 4y ago
  It's not realistic for the attacker to trick you into keep pressing the button so it's not a real threat anyway. If you choose to not require touch for your Yubikey it's user error Yubikeys work great if used as designed.
firefoxkekw 4y ago
Part 2 is a very dumb take. The objetive of fido2 is to avoid phishing in the scenario of a third party actor trying to authenticate from a terminal that isn't the origin of the token emission, since it has origin binding. So obviously if the third party actor is acting from a compromised terminal with access to the fido2 key, they can be the origin of the request. Sources & more info to educate yourself in the matter: Lawrence systems TLDR version: https://www.youtube.com/watch?v=F_E2LZK-bFk https://www.youtube.com/watch?v=F_E2LZK-bFk RSA conference: https://www.youtube.com/watch?v=aMo4ZlWznao https://www.youtube.com/watch?v=aMo4ZlWznao Fido alliance: https://fidoalliance.org/specs/u2f-specs-master/fido-u2f-overview.html https://fidoalliance.org/specs/u2f-specs-master/fido-u2f-ove...
FiloSottile 4y ago
This is a mildly interesting observation/tool presented in the most overblown and irresponsible way. WebAuthN is meaningfully phishing-safe. You can’t replay a login for attacker.com to example.com. What part 1 is demonstrating is that if you compromised the victim’s machine you can arbitrarily use a token for as long as it’s connected. What part 2 is demonstrating is that if you choose server-side to allow subdomains (it’s an option!) and then an attacker takes control of https://subdomain.example.com https://subdomain.example.com, they can replay a subdomain login against example.com. Needless to say, your average phisher doesn’t have control over the victim’s machine or one of the target’s subdomains. It’s still interesting because you might encounter a combination of server-side misconfiguration and user controlled subdomains (like the deprecated user.github.com), but far from an indictment of WebAuthN. Arguing that calling WebAuthN phishing-safe is a “scam” or that 100% phishable TOTP or MFA over Signal (??) is better is detached from reality and harmful. I wish InfoSec didn’t reward these antics.
Komodai 4y ago

26 points by popcalc 4y ago

There's no obvious link, but there's a Part 2: https://cube0x0.github.io/Relaying-YubiKeys-Part-2/ https://cube0x0.github.io/Relaying-YubiKeys-Part-2/

stavros 4y ago

Wait, how does this work without the key flashing and needing to be touched?

etskinner 4y ago
Presumably you would trick the person into touching the key. Similar to getting someone to put their password in with a phishing attack.
pelagicAustral 4y ago
I was thinking the same thing. I guess you would need some sort of XSS to get the user to touch the key. I've seen the web dialogues on Beef and they can be quite convincing, but still doubt this will work with any significant sample of victim/users.
g_p 4y ago
This appears to be using the PIV "smartcard" applet. I believe one option on each certificate in the PIV applet is whether or not a "button press" is required for its use. I believe it is recommended that the device attestation certificate at least is not guarded by the button press. The threat model for yubikeys is to prevent the key being cloned - if it's in your pocket, it's safe. If you plug it in, and authenticate by PIN to the PIV applet, and push the button when prompted, someone may be able to generate a signature.
michaelt 4y ago
The fancier Yubikeys have multiple functions - not just the basic U2F. One function is 'PIV' - acting as a 'smart card'. When you create or load a key, you can choose whether you want to require a button press or not [1]. They strongly recommend requiring a button press. No physical button press = an attacker with root can sign things at will. [1] https://docs.yubico.com/yesdk/users-manual/application-piv/pin-touch-policies.html https://docs.yubico.com/yesdk/users-manual/application-piv/p...
- fmajid 4y ago
  I tend to get the U2F-only Yubikeys (a.k.a "Yubico Security Key", they are blue instead of black) because I don't want to inadvertently start relying on Yubico proprietary functionality, and they are cheaper. This is just one more reason to do so.
anecdotal1 4y ago
It's not realistic for the attacker to trick you into keep pressing the button so it's not a real threat anyway. If you choose to not require touch for your Yubikey it's user error Yubikeys work great if used as designed.

firefoxkekw 4y ago

Part 2 is a very dumb take. The objetive of fido2 is to avoid phishing in the scenario of a third party actor trying to authenticate from a terminal that isn't the origin of the token emission, since it has origin binding. So obviously if the third party actor is acting from a compromised terminal with access to the fido2 key, they can be the origin of the request. Sources & more info to educate yourself in the matter: Lawrence systems TLDR version: https://www.youtube.com/watch?v=F_E2LZK-bFk https://www.youtube.com/watch?v=F_E2LZK-bFk RSA conference: https://www.youtube.com/watch?v=aMo4ZlWznao https://www.youtube.com/watch?v=aMo4ZlWznao Fido alliance: https://fidoalliance.org/specs/u2f-specs-master/fido-u2f-overview.html https://fidoalliance.org/specs/u2f-specs-master/fido-u2f-ove...

FiloSottile 4y ago

This is a mildly interesting observation/tool presented in the most overblown and irresponsible way. WebAuthN is meaningfully phishing-safe. You can’t replay a login for attacker.com to example.com. What part 1 is demonstrating is that if you compromised the victim’s machine you can arbitrarily use a token for as long as it’s connected. What part 2 is demonstrating is that if you choose server-side to allow subdomains (it’s an option!) and then an attacker takes control of https://subdomain.example.com https://subdomain.example.com, they can replay a subdomain login against example.com. Needless to say, your average phisher doesn’t have control over the victim’s machine or one of the target’s subdomains. It’s still interesting because you might encounter a combination of server-side misconfiguration and user controlled subdomains (like the deprecated user.github.com), but far from an indictment of WebAuthN. Arguing that calling WebAuthN phishing-safe is a “scam” or that 100% phishable TOTP or MFA over Signal (??) is better is detached from reality and harmful. I wish InfoSec didn’t reward these antics.

Komodai 4y ago