[CentOS] an actual hacked machine, in a preserved state

Wed Jan 4 21:59:21 UTC 2012
Lamar Owen <lowen at pari.edu>

[Distilling to the core matter; everything else is peripheral.]

On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote:
> To be absolutely clear: Do you, personally, believe there is more  
> than a
> 1 in a million chance that the attacker who got into my machine, got  
> it
> by brute-forcing the password?  As opposed to, say, using an  
> underground
> exploit?

Here's how I see it breaking down:

1.) Attacker uses apache remote exploit (or other means) to obtain  
your /etc/shadow file (not a remote shell, just GET the file without  
that fact being logged);
2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer  
on 10,000,000 machines against your /etc/shadow file without your  
knowledge;
3.) Some time passes;
4.) Attacker obtains your password using distributed brute forcing of  
the hash in the window of time prior to you resetting it;
5.) Attacker logs in since you allow password login.  You're pwned by  
a non-login brute-force attack.

In contrast, with ssh keys and no password logins allowed:

1.) Attacker obtains /etc/shadow and cracks your password after some  
time;
2.) Attacker additionally obtains /root/.ssh/*
3.) Attacker now has your public key.  Good for them; public keys  
don't have to be kept secure since it is vastly more difficult to  
reverse known plaintext, known ciphertext, and the public key into a  
working private key than it is to brute-force the /etc/shadow hash  
(part of the difficulty is getting all three required components to  
successfully reverse your private key; the other part boils down to  
factoring and hash brute-forcing);
4.) Attacker also has root's public and private keys, if there is a  
pair in root's ~/.ssh, which may or may not help them.  If there's a  
passphrase on the private key, it's quite difficult to obtain that  
from the key;
5.) Attacker can't leverage either your public key or root's key pair  
(or the machine key; even if they can leverage that to do MitM (which  
they can and likely will) that doesn't help them obtain your private  
key for authentication;
6.) Attacker still can't get in because you don't allow password  
login, even though attacker has root's password.

This only requires an apache httpd exploit that allows reading of any  
file; no files have to be modified and no shells have to be acquired  
through any exploits.  Those make it faster, for sure; but even then  
the attacker is going to acquire your /etc/shadow as one of the first  
things they do; the next thing they're going to do is install a  
rootkit with a backdoor password.

Brute-forcing by hash-cracking, not by attempting to login over ssh,  
is what I'm talking about.

This is what I mean when I say 'multilayer metasploit-driven attacks.'

The weakest link is the security of /etc/shadow on the server for  
password auth (unless you use a different auth method on your server,  
like LDAP or other, but that just adds a layer, making the attacker  
work harder to get that all-import password).  Key based auth is  
superior, since the attacker reading any file on your server cannot  
compromise the security.

Kerberos is better still.

Now, the weakest link for key auth is the private key itself.  But  
it's better protected than any password is (if someone can swipe your  
private key off of your workstation you have bigger problems, and they  
will have your /etc/shadow for your workstation, and probably a  
backdoor.....).  The passphrase is also better protected than the  
typical MD5 hash password, too.

It is the consensus of the security community that key-based  
authentication with strong private key passphrases is better than any  
password-only authentication, and that consensus is based on facts  
derived from evidence of actual break-ins.  While login-based brute- 
forcing of a password that is long-enough (based upon sshd/login/ 
hashing speed) is impractical for passwords of sufficient strength,  
login-based brute forcing is not the 'state of the art' in brute- 
forcing of passwords.  Key-based auth with a passphrase is still not  
the ultimate, but it is better than only a password, regardless of the  
strength of that password.

If your password was brute-forced, it really doesn't matter how the  
attacker did it; you're pwned either way.

It is a safe assumption that there are httpd exploits in the wild,  
that are not known by the apache project, that specifically attempt to  
grab /etc/shadow and send to the attacker.  It's also a safe  
assumption that the attacker will have sufficient horsepower to crack  
your password from /etc/shadow in a 'reasonable' timeframe for an MD5  
hash.  So you don't allow password authentication and you're not  
vulnerable to a remote /etc/shadow brute-forcing attack regardless of  
how much horsepower the attacker can throw your way, and regardless of  
how the attacker got your /etc/shadow (you could even post it publicly  
and it wouldn't help them any!).