4 ms·

Just tried this $ ssh whoami.filippo.io and it prints this You have SSH agent forwarding turned (universally?) on. That is a VERY BAD

by xaduha 4y ago

Just tried this $ ssh whoami.filippo.io and it prints this You have SSH agent forwarding turned (universally?) on. That is a VERY BAD idea. For example, right now this server has access to your agent and can use your keys however it likes as long as you are connected. ANY SERVER YOU LOG IN TO AND ANYONE WITH ROOT ON THOSE SERVERS CAN LOGIN AS YOU ANYWHERE. but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards.

BlackLotus89 4y ago
> but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards. What? This server pulls your public key from github and allows your client to connect to it. If you have forwarding turned on this server can INDEED connect to every server you are connected to.
- xaduha 4y ago
  No it cannot, not until I touch my security key. I'm not a novice in these matters and I just tested it again. To connect to one server I have to touch my security key and then to connect to another one from it immediately afterwards I need to touch my security key again. Otherwise nothing happens and it just times out. Even when using something like ssh -J user@server1 user@server2 I need to touch it two separate times.
  - BlackLotus89 4y ago
    Ah "security key" as in hardware token. Sorry thought you were referencing to your key file and not your usb-key. Misunderstanding that's all :)
tialaramex 4y ago
Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always asks for UP) to allow the signature to proceed immediately without a presence check so long as they don't set the UP bitflag in their signed response. I think Fillipo's server can tell the client "I want UP" to check this, but I'm not sure and if few people do that I bet somebody already made a client which gets it wrong. [[ Because the flags are signed, even though UP is a single bit flag you can't forge it ]]
- xaduha 4y ago
  For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post ControlMaster auto ControlPath ~/.ssh/github.sock ControlPersist 999999999s ServerAliveInterval 0 without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference since they can add it if they want. A paranoid answer to that is to use something like /usr/bin/ssh -F /dev/null -A user@fqdn.example.org everytime without an alias, of course. And only plugging in your security key when you need it.
  - tialaramex 4y ago
    Your description is very confusing, either I don't understand your explanation or you misunderstood. ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it. I also don't see how this is relevant anyway. My point was that although you will probably be asked to touch your FIDO token to authenticate to SSH servers, that's actually not technically the default, cheap tokens figured since WebAuthn is the majority use of FIDO, and since they're allowed to volunteer UP which WebAuthn wants, they can just ignore the UP flag on the request side and always do user presence testing. But the FIDO design does not require this, and so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.
    - xaduha 4y ago
      What I described there is a current, practical way to bypass subsequent presence checks in my particular security key (Google Titan NFC) which I tried out too. What you're talking about is that some hardware implementations might be lax about user presence checks which is true, but doesn't affect any particular user (e.g. me) if they know that their key doesn't allow logging in without it. > so we can't know whether some/ all/ most tokens in say ten years time have this behaviour. I've used some U2F applets like this one https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F which bypass presence checks, so yes I'm aware it's not a requirement, but it basically has to be a vulnerability on the hardware/applet level. So I guess don't use NONAME hardware is your advice, is that it?

by xaduha 4y ago

BlackLotus89 4y ago

> but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards. What? This server pulls your public key from github and allows your client to connect to it. If you have forwarding turned on this server can INDEED connect to every server you are connected to.

xaduha 4y ago
No it cannot, not until I touch my security key. I'm not a novice in these matters and I just tested it again. To connect to one server I have to touch my security key and then to connect to another one from it immediately afterwards I need to touch my security key again. Otherwise nothing happens and it just times out. Even when using something like ssh -J user@server1 user@server2 I need to touch it two separate times.
- BlackLotus89 4y ago
  Ah "security key" as in hardware token. Sorry thought you were referencing to your key file and not your usb-key. Misunderstanding that's all :)

tialaramex 4y ago

Probably filippo should update this software to notice if the only identities presented were from FIDO authenticators and, if so, modify this message to explain the reduced risk Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always asks for UP) to allow the signature to proceed immediately without a presence check so long as they don't set the UP bitflag in their signed response. I think Fillipo's server can tell the client "I want UP" to check this, but I'm not sure and if few people do that I bet somebody already made a client which gets it wrong. [[ Because the flags are signed, even though UP is a single bit flag you can't forge it ]]

xaduha 4y ago
For something like that to work an attacker would have to add into ~/.ssh/config (on each intermediate server) lines mentioned in another recent post ControlMaster auto ControlPath ~/.ssh/github.sock ControlPersist 999999999s ServerAliveInterval 0 without me noticing to sort of cache presence check. In which case they have access to my account already and presence or absence of 'ForwardAgent yes' makes no difference since they can add it if they want. A paranoid answer to that is to use something like /usr/bin/ssh -F /dev/null -A user@fqdn.example.org everytime without an alias, of course. And only plugging in your security key when you need it.
- tialaramex 4y ago
  Your description is very confusing, either I don't understand your explanation or you misunderstood. ForwardAgent is a decision for your client, so an attacker's change to some intermediate can't cause your client to set ForwardAgent. Lots of modern SSH users do not have ForwardAgent, at all, it's just not necessary for them, so an intermediate server doesn't have the opportunity to do anything with it. I also don't see how this is relevant anyway. My point was that although you will probably be asked to touch your FIDO token to authenticate to SSH servers, that's actually not technically the default, cheap tokens figured since WebAuthn is the majority use of FIDO, and since they're allowed to volunteer UP which WebAuthn wants, they can just ignore the UP flag on the request side and always do user presence testing. But the FIDO design does not require this, and so we can't know whether some/ all/ most tokens in say ten years time have this behaviour.
  - xaduha 4y ago
    What I described there is a current, practical way to bypass subsequent presence checks in my particular security key (Google Titan NFC) which I tried out too. What you're talking about is that some hardware implementations might be lax about user presence checks which is true, but doesn't affect any particular user (e.g. me) if they know that their key doesn't allow logging in without it. > so we can't know whether some/ all/ most tokens in say ten years time have this behaviour. I've used some U2F applets like this one https://github.com/tsenger/CCU2F https://github.com/tsenger/CCU2F which bypass presence checks, so yes I'm aware it's not a requirement, but it basically has to be a vulnerability on the hardware/applet level. So I guess don't use NONAME hardware is your advice, is that it?