GPU-stuffed monster cracks Windows passwords in minutes Security researchers have put together a monster number-crunching rig capable of cracking strong passwords by brute force in minutes. Jeremi Gosney (aka epixoip) demonstrated a machine running the HashCat password cracking program across a cluster of five servers equipped with 25 AMD Radeon GPUs at the Passwords^12 conference …
You're rather overselling NTLM by describing it as "crypto" I reckon :-)
As I recall from whenever one of my parents forgot their password on XP it was a case of removing a single file in the System32 folder. Their profile name with an extension but I forget which (.key, .pid, .sam?).
"Cracking" XP is about as impressive as cracking a diary's padlock.
To be fair though doing that didnt crack the password or the security. You had physical access to the file system, and you just overwrote the password file. Any stored passwords, etc that the user had as 'secrets' would not have been recoverable...
If you want to prevent such techniques when someone has physical access to the system then you just turn on Bit Locker....
There is actually a registry (or Group Policy) switch in Windows that jumps up system cryptography levels, but not many people know about it or use it (outside of US gov contractors anyway). It's the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" setting. See http://support.microsoft.com/kb/811833
Though it changes a lot of encryption defaults to AES-256 and SHA1 for hashing (or triple DES on Windows XP and older) I believe you would have to change NTLM authentication separately, like has recommended at http://support.microsoft.com/kb/147706 for over 10 years... Though disabling NTLMv2 is harder to do, rather annoyingly.
This is nothing to do with the network authentication protocols, which have their own weaknesses...
It is to do with the password hashes which are stored on disk and in memory (in the case of domain logons)...
Vista upwards stores the NTLM hash only by default, earlier versions stored LM too. As the article points out, LM is trivially weak while NTLM is also pretty weak too, and both are massively weaker than the hashing used in any unix system.
The networking protocols are another amusing issue, since there is no need to actually crack the passwords anyway. If you have the hashes, then you can authenticate against NTLMv2 and all earlier versions without knowing the plaintext (google: pass the hash).
It's also possible to man in the middle the network auth protocols (google: metasploit smb_relay).
And there are plenty of ways to obtain the hashes, you can pull them from disk, for domain logins you can pull them from memory (the plaintext is also typically stored in memory - google for mimikatz) when a user (or service account - very common for service accounts to be logged in to all kinds of machines, even with admin privs) is logged in... So your windows domain is only as secure as its very weakest member.
I found this http://davenport.sourceforge.net/ntlm.html which says:
"While newer clients support the NTLM response, they typically send both responses for compatibility with legacy servers; hence, the security flaws present in the LM response are still exhibited in many clients supporting the NTLM response"
Which I read as NTLM is better, but unless LM is turned off, it's there as well in some cases.
MSDN say to use "Negotiate" in applications so that Kerberos if supported is automatically used instead of NTLM but that NTLM "must also be used for logon authentication on stand-alone systems".
Don't mix up network negotiation with the SAM file (i.e. local password repository). I've read nothing in this article to indicate this relates to network negotiation.
The SAM file historically (it's disabled in newer versions of Windows) stores the password in two formats, the old LM format is the one that splits the password into two columns, not NTLM.
Well salt doesn't make it harder to crack at all, it just means your rainbow tables are useless.
As for how long to crack SHA-512....
Well a post on stack overflow puts it at 10^128 years, if your using a standard "desktop" - while this machine is designed specifically for these kinds of attacks, it still in no way puts a dent in the time taken to brute force a SHA-512 for now, as long as no exploits are found.
~(All figures are off the top of my head/off random pages on the net).
The time taken depends primarily on how many possible passwords have to be tried. The choice of hashing algorithm is only going to change the answer by a smallish constant factor, unless you choose a hash function that is fantastically hard to compute, which SHA-512 isn't. (You could specify that your hash function is SHA-512 applied one million times in succession, but in practice nobody does that.)
I read it more as a warning against password reuse & repetition than as a result of a direct attack on your own network. Granted, if someone has access to stored hashes on your network you have a problem larger than their ability to decrypt said hashes, more to the point, why would they even bother looking at them if you're the actual target of the attack? However, if one of your users has their work email and their work password as the login for that specialist Russian film archive they're fond of...
Password hashes are often stolen as a result of sql injections. So the attacker doesn't really have any solid access to the server, only access to the info stored in the database. So they really have to brute every hash.
If they had access to the server then they could just change the login page to log/email every password in clear text as the user logs in.
Who could possibly have thought that was a good idea? What was the reasoning behind it.
For anyone unsure of the reasoning behind - splits a 14-character password into two seven-character strings before hashing them, which means it's a good deal less secure than an eight character password - cracking two 7 digit passwords takes twice as long as cracking one 7 digit password. where as an 8digit password has all of the 7 digit passwords with each of the available characters on the end, hence there are at least 70x more and 70x longer.
Which were, in turn, probably handicapped by computational restraints present in the early 1990's.
Eh? Any machine of any era capable of running any version of Microsoft Windows had ample resources for hashing 8-character passwords. Nothing in the systems of the time excuses the braindead LM hash - certainly not "computational restraints" (by which I assume you mean "resource constraints" or similar).
Someone above made a point which seems to have been missed by most of the commentators: the old UNIX DES-based crypt(3) hash, from circa 1978, is superior to the LM hash mechanism, from c. 1990. crypt(3) is only a 56-bit hash, but LM is also restricted to ASCII, and it folds letter case - a move almost incomprehensibly stupid - so it's actually only about 43-bit. And LM is unsalted.
Moreover, Microsoft kept LM hashes around by default until Vista (GA in 2007), so they were using a known-broken, easily-crackable hash that was worse than its major competitor for nearly 30 years.
This particular demonstration isn't a new best attack against LM - Ophcrack did better on most LM hashes back in 2003, using rainbow tables. It's just another reminder that Microsoft screwed up monumentally when they created the LM authentication mechanism. Nothing about the technology of the time excuses it.
Having to set a SPN in AD for impersonation (re-vend Kerberos tickets to apply end-user access rules in n-tier scenarios) is seen as an “unacceptable risk”… but those same “consultants” were stumped by “all content is encrypted using a zero-shift Cesar cipher”
Your point is quite well made, and I agree that in isolation, there should be no problem deciding which is most secure, but quite often there are other constraints.
I suspect that many of these security consultants may have to come up with solutions that are 'good enough' while not adding significantly to the cost and complexity of the solution.
When all is said and done, the security of any environment is a compromise between risk, cost and strength, and always will be until the strongest security is also the cheapest.
Of course, if the consultants you've known only suggest NTLM+SSL, then your scorn is probably deserved.
Im of the mindset on users that we need 2-step auth. Something along the lines of a password and a DNA sample would suffice. And no not that kind of DNA sample *quit snickering in the back*, something like a pint of their blood or something each time they log on would be good. And it has the added bonus of eliminating possible holes in the network after approximately 5-6 logins.
What can I say I hate the end user.
No I'm pretty sure I spelled what I intended correctly with "snickering*"
* snickering present participle of snick·er (Verb)
Verb
1) Give a smothered or half-suppressed laugh; snigger.
2) (of a horse) Whinny.
In this case I was using the first definition of it. As much as I like you Brits I haven't fully adopted your language over here in the States.
AC icon abuse + Assuming = down vote
from wikipedia:
"NTLM version 2 (NTLMv2), which was introduced in Windows NT 4.0 SP4"
I will stop right there with my citation.
So wow. a fantastic rig can crack a over 13 year old password hash.
which has been superseeded by a new version (and many since) since NT4 SP4. in case you forgot: NT4 SP4 was the OS of choice for the Nazi's to power their enigma machines. It was also used to launch V-2's. the russians re-utilised it for their Tsjernobyl power plant. that didn't work out that great. anyway:
that's old. and now, a gigantic rig.. can crack the password hash... from before that?
oh wow. oh wow. oh wow. (to quote a great man.)
so good for you! now go crack those WinNT 4 SP3 domains!
non-news. that's what this is.
You mock, sir, but I have a Buffalo NAS (now collecting dust on my shelf) that won't accept NTLMv2 and so back in the day when I actually used it I had to degrade my other systems (Windows and Linux) to accept NTLM.
Obviously no *Microsoft* system has force the use of NTLM on me since sometime in the last millenium. Equally obviously, had the Buffalo NAS granted me full access to the FOSS software inside it then I could have fixed the problem.
Something important will be running on that Windows NT 4.0 SP4 and never upgraded because it works, the supplier went bust or the hardware is no longer supported so it cannot be upgraded without changing the hardware.
Like, maybe, Cash Point Machines.
My bank upgraded from OS2/warp ... in 2010. Now they got Vista! For 29 years!!
Can't the hashes be pulled off the network?
A security manager I was training once showed me a script kiddies tool which he plugged into our training network, arp spoofed to receive the traffic on the switched network and then slurped the fileshare traffic. The screen quickly showed the user name info of lots of people on the network then running something akin to "John" would slowly show all the guessable passwords (ie 95%)
Nearly as much fun as nfsshell
>his article would be more interesting if it explained what NTLM is used for.
In our network, NTLM is used to connect to OpenBSD servers. In the last couple of years I haven't seen any more complaints that MS 'has deliberatly broken' Open Source software by having NTLM and LM off by default, but for many years a lot of *nix systems couldn't handle NTLMv2.
Of course Linux is nice and secure, I mean Ubuntu desktop has no root password it just allows the user (with suitably crap password) to become root with sudo everywhere and the user does all the time just to get rid of the annoying nag (like on Windows).
So user with crap password gets hacked by hacker or malware that issues sudo /etc/shadow and if it's an old install upgraded (akin to the issue in this article) then it's a file probably full of MD5 hashes. Short work and passwords obtained.
Though little point anyway as there'd be one user generally on the desktop install, just like most desktop Windows installs, and the password will be crap likely with the typical user having assumed they are ultra secure in a smug manner.
I've always wondered why password-needing systems don't all use the 'fail x times and you're locked out' method.
Obviously it would add to the moron-overhead for IT admins, but wouldn't it make the attacking system's BFP (brute force power) redundant and so easily solve for this kind of attack?
When they talk about the time to brute-force a password, they are assuming you have the hashes in front of you and can therefore check each possibility yourself.
The time taken to test a password by actually presenting it to the target machine (particularly over a network cable) is many orders of magnitude greater and so you couldn't possibly brute force a machine this way.
You've always wondered why password-needing systems don't all use the 'fail x times and you're locked out' method? The answer is because that would allow anyone who knows your user name (which is often guessable or not particularly secret) to get you locked out, which could be damaging for you, or to get lots of people locked out, which could be damaging for the company that runs the system.
"...fail x times and you're locked out' method".
On the face of it a sensible approach, but it does not work as well in practice as one would hope or assume.
A previous employer had a strict password policy (8-16 characters, mix of at least one letter, number and special character, monthly changes, last 10 passwords prohibited, automatic log-out after ten minutes of no keyboard activity and only three unsuccesful logon attempts).
You will not believe the endless problems that that caused - I am sure at least one third of calls logged concerned passwords.
First and foremost was forgotten passwords (especially bad on a Monday following a password change the previous Thursday or Friday - I would be swamped by calls the moment I walked in the door (and I was usually 30 minutes early); also almost no-one could remember a password upon returning from leave or an absence of more than a week), followed by locked-out users.
Lock-outs presented an interesting problem: at one stage we suddenly had a spate of locked out accounts every weekday morning (all machines had to be left on overnight, so that security updates, virus program updates and policy changes could be run after hours). I initially suspected a problem with the scripts or the DC or maybe the AD server, but everything checked out fine. Also, it was just one building complex in my branch that had the problem.
Then one night I decided to stay after hours (I discovered from the logs that lock-outs took place between 17:30 and 18:30 every night) to see if I could catch the culprit, as I had begun to suspect that it was deliberately done, since lock-outs ran roughly sequentially in seating order, suggesting someone moving from machine to machine.
Lo and behold! In came a bevy of cleaning ladies who whipped out damp cloths and proceeded to vigourously clean each desk, keyboard and monitor! (I should mention here that usernames were automatically populated, as there were a number of complaints about having to enter both a username and a password - surely the computer can do a little bit of work as well?). So obviously, the third time the "Enter" key was hit, the account got locked out. The sudden emergence of this problem was because the business had changed their cleaning service provider and keyboard cleaning was top of their list of things to do.
Password strength was also a problem; despite the restrictions enforced, users kept using easily guessed passwords (Qwert1@3, or password1!, etc).
I eventually resorted to suggest that they use easily remembered mnemonics (and choose your own, thank you, do not use my example), like Ihhtcpem!-12, which would stand for "I hate having to change passwords every month! - xx", where xx would be the month of the year. That way they only needed to change the last character or two and still have a reasonably secure password that is easily remembered.
But yeah, despite all that a large number of users used to write theirs down and hide it under the desk blotter or the keyboard, or write it on the calendar (obviously on the date of the forced change, as everyone waited until the last day (we used to have a ten day warning period)).
Password change requests I particularly hated was for mid-month changes, when some girl broke up with her boyfriend and did not want to be reminded of him every time she needed to log on. I used to refuse to do those as punishment for ignoring my sage advice about good passwords, until we got a central Help Desk and SLA's.
<---- Paris, obviously, for the disconsolate girl being forced to enter an ex-boyfriend's name.
and have never had the kind of lockout problems you describe.
For one, it's crap security to leave usernames onscreen if you're changing passwords that frequently.
The only issue we ever had was what to do for the dweebs working on the weekend when helpdesk is 8x5. That's a simple fix too. You get x tries in 60 minutes or it locks. Once it locks, you're out for 15 to 60 minutes, at which point the account automatically unlocks again. It's enough to keep the bad guys out of the system, not so bad people can't work.
My actual nightmare is SSO with McAfee EE. Users update the EE pw thinking its an AD pw. At which point you have to reset both, login as yourself, and synch EE. About a 20 minute process per user. We have about 20 regulars. But that will be going away soon. Turning off SSO for other reasons.
> the 'fail x times and you're locked out' method.
The trouble with that is that innocent users get locked out of their accounts when those accounts come under unsuccessful attack. Someone will then have to intervene. Businesses don'tlike that sort of situation.
Exponential timeouts are a better idea,IMO.
Vic.
Other comments are very near this one....
"A 14-character Windows XP password hashed using Lan Manager can be cracked from its hash value in just six minutes."
For what purpose?
I'm confused why anyone would want to determine a local user (not domain user) account password instead of just blanking it to none and then logging in: Do a Google search for "offline nt password & registry editor" and the top or near top result links you to a site with a tool to read and just blank the local password. Knowing *what* the password is seems pointless. What does doing this achieve?
And if you just want files off the drive, plug the drive into another NT box, take recursive ownership of the directory and overwrite the ACL (change permissions to Everyone). Near instant file access.
If the computer logs into a domain, the best target becomes cached domain credentials, that do not use NTLM anyway, iirc.
And if you've got a bitlocker encrypted drive, none of this matters...
Because you fail to have a sufficiently vivid imagination.
The point is to access the system without the vic knowing he's been pwned. That way you can act as him and continue nefarious activity, possibly compromising other accounts/systems on the network. Changing the password on him might just alert folks to what you're up to. Especially in Windows shops these days, the only local user account will be the local admin. Which is nominally a well guarded secret and changes ever 30/60/90 days. So the help desk KNOWS when that's been changed away from what it is supposed to be.
In point of fact, that's exactly what got a programmer fired at a former employer's. He downloaded a Russian cracker, changed the local password, and used it to access things including his ultimate goal, the SA password on one of the live servers for the software he was developing (he was allowed full reign on test and almost full reign on Dev). One day we needed to setup his PC for a presentation elsewhere, and nobody from the HD could log in. When we did get in, we found the crack program and told the CIO. He was on paid leave until the CIO had banged on enough heads to update HR policy at which point he was summarily fired.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
