Two-factor authentication

Posted Sep 1, 2011 20:15 UTC (Thu) by ebirdie (guest, #512)
In reply to: Two-factor authentication by Cato
Parent article: kernel.org compromised

In case of a trojaned ssh-client does any authentication really help?

The trojan may grap unlocked ssh-key from ssh-agent and grap the key password, if ssh-key is unlocked with -i switch.

In the case PAM and a two-factor authentication is used the trojan may quietly wait until all the connection authentication hoopla is done. The hoopla does not reveal any passwords, OTP or whatever to the attacker yet, but all the attacker needs through the trojaned ssh-client is an authenticated ssh-connection to the target system.

At the target system, while it has a spooky terminal connection via ssh to it, all the attacker need is to wait for terminal with root privileges. From there it is only couple seconds that the target system has rootkit. If all goes well, the rootkit does not crash the system, reveal itself and lets the attacker in.

One can't trust the terminal attached to the ssh-connection, no matter how well the connection was authenticated. Sudo at the target machine can't come to client machine to verify that the calling terminal weren't spooky.

Does this make sense?

to post comments

Two-factor authentication

Posted Sep 1, 2011 23:16 UTC (Thu) by slashdot (guest, #22014) [Link] (5 responses)

Indeed, that method only foils a passive keylogger.

The only truly secure and somewhat practical method is to acquire a cheap low-end machine (preferably with hardware trusted execution path verification) which is exclusively used as a ssh terminal, and blocks all incoming traffic not related to an outgoing tcp connection.

Of course compromise of the server through the services it exposes is still possible.

Two-factor authentication

Posted Sep 2, 2011 7:59 UTC (Fri) by dugsong (guest, #79624) [Link] (3 responses)

Nothing's perfect, but a practical defense is to use your smartphone for out-of-band verification.

Disclaimer: Our company, Duo Security, provides this for free to open-source projects. Because it's the right thing to do!

As an aside, PAM and pubkey auth in OpenSSH are mutually exclusive. We work around this with a simple login_duo utility that doesn't require sshd restart, or even root access.

Two-factor authentication

Posted Sep 2, 2011 18:12 UTC (Fri) by slashdot (guest, #22014) [Link] (2 responses)

As far as I can tell ebirdie's objections apply to your solution as well.

In short, the issue is that a compromised client has full control of the connection after the authentication is done, regardless of whatever fancy mechanism you use to authenticate.

If you don't care about detection, it doesn't even require a compromised client: just software that detects authentication being successfully completed and simulates some keyboard/mouse input that gives the attacker full control of the server and shuts out the administrator from it.

Two-factor authentication

Posted Sep 2, 2011 23:12 UTC (Fri) by jonoberheide (guest, #71029) [Link]

Actually, our Duo Push authentication allows you to approve/deny individual transactions as you see fit, preventing the sort of session-riding attack that you're referring to.

For example, in the follow screenshot, you can see the exact command that an attacker is attempting to execute:

http://blog.duosecurity.com/wp-content/uploads/2011/04/pu...

Obviously, you would deny the attacker's attempted "rm -rf" here. ;-)

Regards,
Jon Oberheide

Two-factor authentication

Posted Sep 5, 2011 10:36 UTC (Mon) by sitaram (guest, #5959) [Link]

Disclaimer: I am the author and maintainer of gitolite.

If we make the assumption that all 448 users really do not need an actual *shell*, and that they will be mostly doing git push or putting files in some designated area using rsync, you can actually use gitolite to limit what they can do quite handily.

They don't get a shell, their access are limited to whatever repos they've been given access to, and even the rsync command can be access controlled using the same software, limiting users write access to specific directories only.

I've kinda lost track if they found the actual *escalation* vector involved but I'll bet it needed shell on the server.

Two-factor authentication

Posted Sep 2, 2011 8:22 UTC (Fri) by Cato (guest, #7643) [Link]

A lower cost way of having a "separate PC as SSH terminal" might be Qubes, which uses multiple VMs with differing levels of trust - could use one VM for general web browsing, one for shopping/banking, and one for SSH access.
https://lwn.net/Articles/385213/

The problem is that this requires significant work to set up for the owner of the client PC, and it's hard to mandate this setup. However, cutting the number of SSH users from 448 to a handful would make this more practical for kernel.org.