3 ms·

Funnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I wou

by utopiah 2mo ago

Funnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I would just type it thinking "Hmmm weird" but still want to proceed forward ¯\_ (ツ)_/¯

lrvick 2mo ago
Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root. Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
- utopiah 2mo ago
  I'm missing something then, are you talking about the code your shared or an another slightly more complicated one you are just imagining now?
  - lrvick 1mo ago
    A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target. You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command. You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS. In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
    - utopiah 1mo ago
      Right but that's my point, since 99.99% of users don't rely on U2F I doubt it would be covered or even be rational to cover such edge cases and thus most likely wouldn't work. I'm not saying it's a magical perfect solution, only that being outside of the most popular flow is in itself a protection for the most automated attacks.

by utopiah 2mo ago

lrvick 2mo ago

Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root. Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.

utopiah 2mo ago
I'm missing something then, are you talking about the code your shared or an another slightly more complicated one you are just imagining now?
- lrvick 1mo ago
  A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target. You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command. You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS. In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
  - utopiah 1mo ago
    Right but that's my point, since 99.99% of users don't rely on U2F I doubt it would be covered or even be rational to cover such edge cases and thus most likely wouldn't work. I'm not saying it's a magical perfect solution, only that being outside of the most popular flow is in itself a protection for the most automated attacks.