4 ms·

You'd have to elaborate a bit on your theoretical attack here. 1. A request and its signed response can only be used for a specific login attempt by SSH design

You'd have to elaborate a bit on your theoretical attack here. 1. A request and its signed response can only be used for a specific login attempt by SSH design. 2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods. 3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user. 4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval. If you want to trick the user to accept your request by firing it simultaneously with a legitimate one, you first have to steal pairing data from the machine the user is logging in from. Then, you'd either have to auth against the very same host as the user, or have the request say that the host is unknown (sticks out, seeing that the legitimate request is also there). There would also be two requests in a row, which might warn the user. The other attack vector I can think of would be trying to accept a random request done by an attacker, either by tricking the user (clickjacking-style) or by using an exploit on the device. A yubikey-like device with a screen displaying request information and a hardware approval method would be better than an arbitrary android device, but I would argue that the model presented by this piece of software isn't as bad as you make it sound.

baldfat 9y ago
> s yet, there are no known exploitable vulnerabilities in SSH2, though information leaked by Edward Snowden in 2013 suggests the National Security Agency may be able to decrypt some SSH traffic. http://searchsecurity.techtarget.com/definition/Secure-Shell http://searchsecurity.techtarget.com/definition/Secure-Shell I really don't understand how people continue to state wrong information about ssh. Is it because of Heart Bleed? SSH is 22 years old and is still a solid tool. The only bad thing about ssh is key management which this company is addressing.
- fidget 9y ago
  There are other bad things about ssh. Tofu sucks balls and ssh users are far too comfortable with it.
  - voltagex_ 9y ago
    Had to look it up. https://en.wikipedia.org/wiki/Trust_on_first_use https://en.wikipedia.org/wiki/Trust_on_first_use What would you replace it with?
    - transitorykris 9y ago
      Signed keys. Here's an example of how to do it from Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea...
  - arghwhat 9y ago
    Well, feel free to come up with a better solution. 3rd party trust roots are way worse.
  - madmulita 9y ago
    The server key can be signed by a trusted authority, no need to trust on first use.
gruez 9y ago
>1. A request and its signed response can only be used for a specific login attempt by SSH design. >3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user. >4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval. So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host. >2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods. Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.
- arghwhat 9y ago
  > Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned. Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one. > So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host. I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour"). If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem. If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on. Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.). With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).
hstern 9y ago
>2. The app, through some nasty hacks, receive the host auth blob from the server to verify. What do you mean here? is the host auth blob coming from the third party service you are trying to auth to (e.g. Github), or from the initial client making the auth request (e.g. "Request from Macbook")?
- arghwhat 9y ago
  It puts a little nc-like tool as ProxyCommand, parsing all traffic for host-auth like packets coming from the target machine. It then sends it to the app, so that it can verify the signature of the remote host before prompting you for approval.

baldfat 9y ago

> s yet, there are no known exploitable vulnerabilities in SSH2, though information leaked by Edward Snowden in 2013 suggests the National Security Agency may be able to decrypt some SSH traffic. http://searchsecurity.techtarget.com/definition/Secure-Shell http://searchsecurity.techtarget.com/definition/Secure-Shell I really don't understand how people continue to state wrong information about ssh. Is it because of Heart Bleed? SSH is 22 years old and is still a solid tool. The only bad thing about ssh is key management which this company is addressing.

fidget 9y ago
There are other bad things about ssh. Tofu sucks balls and ssh users are far too comfortable with it.
- voltagex_ 9y ago
  Had to look it up. https://en.wikipedia.org/wiki/Trust_on_first_use https://en.wikipedia.org/wiki/Trust_on_first_use What would you replace it with?
  - transitorykris 9y ago
    Signed keys. Here's an example of how to do it from Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea...
- arghwhat 9y ago
  Well, feel free to come up with a better solution. 3rd party trust roots are way worse.
- madmulita 9y ago
  The server key can be signed by a trusted authority, no need to trust on first use.

gruez 9y ago

>1. A request and its signed response can only be used for a specific login attempt by SSH design. >3. The app has an internal known hosts list, so it denies attempts to just replicate hostname to trick the user. >4. The app has to be paired with each machine that can authenticate, or the key material must be stolen off a paired machine. "Timed" acceptance is per pairing basis, so abuse of that only works if you steal the right pairing. The app shows the name of the pairing when requesting approval. So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host. >2. The app, through some nasty hacks, receive the host auth blob from the server to verify. If you skip this, the request will be labelled as from "unknown" to "warn" the user. Such request are never auto-accepted during "accept for 1h" periods. Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned.

arghwhat 9y ago
> Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned. Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one. > So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host. I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour"). If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem. If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on. Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.). With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).

hstern 9y ago

>2. The app, through some nasty hacks, receive the host auth blob from the server to verify. What do you mean here? is the host auth blob coming from the third party service you are trying to auth to (e.g. Github), or from the initial client making the auth request (e.g. "Request from Macbook")?

arghwhat 9y ago
It puts a little nc-like tool as ProxyCommand, parsing all traffic for host-auth like packets coming from the target machine. It then sends it to the app, so that it can verify the signature of the remote host before prompting you for approval.