SSH Keys That Call You Back!
The "Dude" writes in response to our duo_unix announcement:
Of course, security never really seems necessary until you're being stomped on by nihilists...
In an era of commodity exploit kits, drive-by malware, and crimeware-as-a-service, a second login factor isn't excessive. It's basic blocking & tackling to protect even user accounts (e.g. Google, Facebook, Paypal, World of Warcraft, etc.), much less administrative access.
We have been involved in cloud incident response before, and I have never seen a violation of multi-tenant technologies used effectively by an attacker. What I have seen is poor protection of extremely powerful credentials leading to attacks by insiders as well as privilege escalation by attackers who gain a foothold on one hosted instance and use locally stored secrets to take over the entire infrastructure.If you manage any Unix systems, you're likely doing it via SSH and pubkey auth (since nobody shares root passwords these days... right?). But SSH keys (and SSL certs) are just another secret that can be lost, stolen, or shared – and potentially even harder to revoke! Some issues we've seen:
Worry about the security of your own application and the underlying operating systems (if you control them). Then worry about where you are storing all of your cloud credentials and who can access them. Think about how you will fire a sys admin and how much trust is given to your least trustworthy system.
- Private keys on bastion hosts used to control network-wide administrative access (hence, global service providers 0wned from a single Linux box)
- Shared admin keys lost, or stale/backdoor authorized_keys left behind when someone gets hacked/fired/leaves
- Hijacked private key use via ssh-agent forwarding to compromised hosts (are you using ssh-add -c + $SSH_ASKPASS?)
- Drive-by browser exploits and remote access trojans leading to exfiltrated private keys
- Private keys sniffed (and cracked) from NFS homedir mounts