On 1/5/2012 6:53 AM, Johnny Hughes wrote:
> On 01/04/2012 07:47 PM, Bennett Haselton wrote:
>> On 1/4/2012 1:59 PM, Lamar Owen wrote:
>>> [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.
>> I acknowledged that the first time I replied to someone's post saying a
>> 12-char password wasn't secure enough. I hypothesized an attacker with
>> the fastest GPU-driven password cracker in the world (even allowing for
>> 100-factor improvements in coming years) and it would still take
>> centuries to break. I understand about brute-forcing the hash vs.
>> brute-forcing the login, but some others had posted about brute-forcing
>> the login specifically and I was commenting on how ridiculous that was.
>>
>>> 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.
>> Well yes, on average, password-authentication is going to be worse
>> because it includes people in the sample who are using passwords like
>> "Patricia". Did they compare the break-in rate for systems with 12-char
>> passwords vs. systems with keys?
>>
>> I have nothing in particular against ssh keys - how could anybody be
>> "against ssh keys"? :) My point was that when I asked "How did
>> attackers probably get in, given that the password was a random
>> 12-character string?" people pounced on the fact that I was using a
>> password at all, and kept insisting that that had a non-trivial
>> likelihood of being the cause (rather than the
>> less-than-one-in-a-billion it actually was), even to the point of making
>> ridiculous statements like Mark saying that an attacker trying
>> "thousands of times per hour" would get in "sooner or later". This was
>> to the exclusion of what was vastly more likely to be the correct
>> answer, which was "Apache, sshd, and CentOS have enough exploits that
>> it's far more likely an attacker got in by finding one of those (and
>> tools like SELinux help mitigate that)."
>>
>> Again, if I hadn't stood behind the math on the issue of long passwords
>> vs. keys, I probably never would have gotten the answer that was
>> actually useful.
>>
>> Do you think it's possible that people focused so much on the use of a
>> "password" as a possible cause, vs. the existence of exploits, despite
>> the former being literally about 1 billion times less probably than the
>> latter, because the former puts more of the blame on the user? (Not
>> that anyone is "to blame" that CentOS and Apache have bugs -- everything
>> does -- but that password security would be an issue even with a perfect
>> operating system.)
>>
>>> 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.
>> Well I disagree that that's a "safe assumption". If you think that
>> 12-character passwords are within striking distance, try 20-char
>> passwords -- 1^36 possible values to search, so with a botnet of over 1
>> billion infected computers each checking 10 billion passwords per second
>> (both orders of magnitude beyond what's in play today, and
>> unrealistically assuming that every resource in the world is focused on
>> this one password), it would take on the order of 10 billion years to crack.
> Then we get back to rainbow tables and hashes that have been generated
> by someone else (with super computer access) and published for "X" sized
> passwords (you pick the size: 8,12,20,24,etc). Then they don't need to
> calculate anything, just do a sql lookup against a database with what
> they get from the shadow file. Someone else already cracked all "X"
> size logins for all possible iterations.
But if the system adds a salt to the password before taking the hash,
then the size of the precomputed rainbow table grows exponentially,
because it has to store the hash of all possible passwords to test, with
all possible salts. If a 12-char random password (72 bits of
randomness) is salted with a 32-bit salt you now have to precompute
10^31 values in your rainbow table instead of "only" 10^21.
Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
