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 …
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
