Slashdot Mirror
NTLM 100% Broken Using Hashes Derived From Captures
New submitter uCallHimDrJ0NES writes "Security researcher Mark Gamache has used Moxie Marlinspike's Cloudcracker to derive hashes from captured NTLM handshakes, resulting in successful pass-the-hash attacks. It's been going on for a long time, probably, but this is the first time a 'white hat' has researched and exposed the how-to details for us all to enjoy. 'You might think that with all the papers and presentations, no one would be using NTLM...or, God forbid, LM. NTLMv2 has been around for quite some time. Surely, everyone is using it. Right? Wrong! According to the last data from the W3 Schools, 21% of computers are running XP, while NetMarketShare claims it is 39%. Unless someone has hardened these machines (no MS patches do this), these machines are sending LM and NTLM responses!' Microsoft has posted a little guidance for those who need to turn off NTLM. Have fun explaining your new security project to your management, server admins!"
NTLM stands for Windows NT Lan Manager. Is was used in earlier Windows from NT 3.1 (yes THAT old) up til Win 2K3 IIRC.
Users would authenticate their login credentials to the system. NTLM is the sub-system that does that authentication.
For more details see wikipedia: http://en.wikipedia.org/wiki/NTLM
I distinctly remember using NTLMv2 in both NT 4.0 and Win2K, for a product I was developing for those platforms. NTLMv2 was an option. You could also choose whether the negotiation could downgrade to NTLM if the other side didn't support NTLMv2, or if the negotiation would insist on NTLMv2. But NTLMv2 didn't become the default until Vista -- the first version of Windows that strongly emphasized security.
If you knew this well enough, XP - a significantly deployed OS - sends these hashes anyway. It takes a Registry Change through group-policy to change the behavior.
You want fun? Sit on the corp net of any silicon valley company with Wireshark. It's still XP heaven out there... And all the SAMBA servers? Easy pickings, Kerb5 or not.
"Flyin' in just a sweet place,
Never been known to fail..."
The Microsoft article http://support.microsoft.com/kb/2793313 referenced above points to http://technet.microsoft.com/library/cc960646.aspx
You can also use Group Policy:
http://technet.microsoft.com/en-us/library/cc738867(v=ws.10).aspx
By default, XP allows inbound NTLMv2 authentication from remote clients but does not use it outbound to authenticate to remote servers. The same setting that makes XP refuse LM/NTLM also enables outbound NTLMv2.
Once in either version (I'd do it from the global group policy settings from the AD admin level), follow this down thru the left-hand side pane tree items:
Security Settings -> Local Policies -> Security Options
Then, in the right-hand pane, go to Network Security grouped section.
There, use the "LAN Manager Authentication Level" & set it to NTLMv2 (refuse others, ONLY IF you don't have a "mixed mode" type domain setup, meaning machines or servers that MUST use NTLMv1).
There's about 10 others in that group too (In Windows 7 that is, I don't recall THAT many in earlier models, but that's just me operating on memory alone though & it's been YEARS since I even used Server 2003 or XP).
So - depending on the version of Windows you're doing this on?
It varies!
( & iirc, it got MORE 'stringent & complex' in each version, but all the NTLM stuff is RIGHT THERE in them all - in Windows 7/Server 2008 onwards, you can even set 'exception machines' up too).
APK
P.S.=> Of course, there's also the EASY WAY OUT, via the "FixIt Tool" Microsoft put out today as well, here -> http://support.microsoft.com/kb/2793313 which give a GOOD RUNDOWN of what's going on in it too...
... apk
I'd say this affects Linux too - a bunch of machines with Samba are quite possibly vulnerable, and need a different settings change than what Windows does.
At a minimum, the following in the smb.conf
[global]
client ntlmv2 auth = yes
lanman auth = no
ntlm auth = no
For winbindd, a recompile might be required.
Also, some (almost all?) ODBC and database servers send passwords in the clear.
Many database servers allow encrypted passwords, but there are surely a lot of database installations that don't take advantage of it. In PostgreSQL you can use SSL for the client network connection, which ODBC passes through. Setup SSL as the only way to connect, and encryption has to happen before it hits the wire. MySQL has a similar trick. Both are just using the OpenSSL library under the hood to encrypt the network traffic.
On the commercial side, Oracle does the same thing with ORA_ENCRYPT_LOGIN. SQL Server has client and server settings that enforce encryption. Basically, if your database traffic isn't encrypted, it's more likely because someone didn't think that was important than because it was impossible. It's a simple checkbox to add to database selection requirements, and it's not hard to find a DBMS that has the capability.
I find people who just stuff user passwords into the database (which can be the same passwords as other services) rather than putting password encryption into their application can also leak data. In PostgreSQL using the built-in pgcrypto makes that easy. You also have to be careful to use the same network encryption approach for any replication client, or it's possible to just sniff that instead to get the data. In Postgres those connect with the same encryption possible options as any other client. Most of the tutorials on setting up replication don't cover this though.