[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!).
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
