If you know anything about Windows security you will know that it is completely broken by default and there's no workarounds. I know, I know, "Citation Needed". Here you go:
> Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them.
Taken from Microsoft's own documentation: http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure!
People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password.
For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz
> For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz
The passwords it displays (using the "sekurlsa" module) are from probing the process memory of LSASS.EXE to view cached credentials. So it will only display the plaintext credentials of currently logged in users.
Consider for a moment a successful zero-day attack on a Windows workstation (say, an image vulnerability in Outlook because that actually happened):
* The attacker can immediately view the user's password or just look at the saltless hashes (if they want).
Now let's compare that to, say, a Linux desktop (where similar zero days are extremely rare):
* Attacker will have to install a keylogger (usually by messing with the user's .profile, .bash_profile, .bashrc, etc) and wait for the user to spawn a new shell process where they actually enter their password at some point. This could be a long, long time or never at all if the user doesn't use the shell much.
* Alternative: Because the shell option is unreliable (especially with more distros/businesses disabling LD_PRELOAD by default) the attacker will usually just run a program/script that prompts the user for their password. Unsophisticated users will probably just enter it but most IT professionals (the ones with privileged access) would immediately have a "WTF?" moment and that's very risky to an attacker.
I'd also like to mention that with things like SELinux and Apparmor it is very difficult for a userspace process to mess with the memory of another userspace process even when they're running as the same user. This makes it much more tricky to escalate privileges or obtain a user's password on a Linux desktop than Windows. Then there's the fact that on Linux there's a plethora of tools to detect and stop things like fiddling with LD_PRELOAD in user profiles.
...and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
The plaintext passwords may well be sitting somewhere in memory even on Linux (e.g. see [1]) but I do agree that the organised caching of such passwords in Windows is a weakness.
I'm quite surprised that LSASS.EXE is not protected in the same manner as AUDIODG.EXE [2]. Just goes to show how DRM protection is considered more important than system security.
>>> Now let's compare that to, say, a Linux desktop (where similar zero days are extremely rare):
Two fatal flaws in your assumption.
1) Linux desktops in enterprise settings are incredibly rare. Linux servers? Way more common, but I can't remember any large corporation or enterprise using Linux desktops - it just doesn't happen.
2) Zero-day exploits DO happen to Linux. Would you be surprised if I told you:
"Vulnerabilities in the Linux kernel fixed in 2012 went unpatched for more than two years on average, more than twice as long as it took to fix unpatched flaws in current Windows OSes, according security firm Trustwave.
Zero-day flaws — software vulnerabilities for which no patch is available — in the Linux kernel that were patched last year took an average of 857 days to be closed, Trustwave found. In comparison zero-day flaws in current Windows OSes patched last year were fixed in 375 days."
>>>> .and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
I actually surprised you made this point, considering its been shown multiple times where malware and rootkits have been introduced into various Linux kernels. Just because something is open source, doesn't mean everybody is going to take the time to examine the source code and make sure its clean.
"The attack attack exploits an oft-forgotten function in Linux versions 2.4 and above in order to quietly insert a rootkit into the operating system kernel as a way to hide malware processes, hijack system calls, and open remote backdoors into the machine, for instance"
"But Linux experts point out that the technique Lineberry is demonstrating at Black Hat indeed been has been deployed before with the so-called SuckIT rootkit, and as far back as the late 1990s with direct kernel-object modification (DKOM) rootkits]."
I can't speak for the guy you're quoting, but I'm sure this is relevant in the context of software you mistakenly trust executing such code. Naturally, if you're not logged in, there's less vulnerabilities to worry about. Hell, I can disconnect the power source if I'm after that kind of security.
However, this is actually an important exploit / factor to be aware of if you're considering installing software securely on a platform. Is it possible to blast through account credentials with a small method like this? I certainly wouldn't want to run any scripts on my machine if I knew that was possible on Linux, because merely being on the sudoers list would mean that my credentials are enough to damage my entire workstation. This doesn't even speak to the effect this would have if you got access to a sysadmin's account on a large network.
You're exactly right: This is a huge vulnerability in Windows and the really important part is that it's an architecture vulnerability. Meaning, to fix it would require changes to how Windows works at a fundamental level in such a way as to break backwards compatibility (which is sacrilege in Microsoft land).
Consider for a moment all the tools and mechanisms in place to synchronize Active Directory passwords across domains, realms, and even 3rd party systems. Every one of those would completely break if you were to implement simple change such as the use of a salt.
That's why I've been saying for many years now that, "if you care about security do not use Windows." There's no mechanism available to actually make it secure because you can't change how it works internally. The best you can hope for is some obfuscation/hacks/tricks in regards to hardening (e.g. rename Administrator account, use entirely different credentials for administrative tasks, disable zillions of insecure defaults, etc). Then just hope you're never targeted.
If just one workstation is compromised an attacker can elevate their privileges to that of Domain Administrator with a few simple steps:
1. Install keylogger or password-dumping tool.
2. Force workstation to unjoin from the domain or cause some other problem that requires a Domain Admin to login to correct the issue.
3. Use credentials of Domain Admin to access a Domain Controller.
4. Dump the entire password database of Active Directory.
5. Crack the password database using some GPU instances in minutes.
After step #2 the attacker basically "owns" your network and can do whatever they want. You can mitigate it by joining Windows workstations using credentials that only have the power to perform a join but this is usually just a minor setback for an attacker as there's a plethora of tools and tricks they can take advantage of to escalate to Domain Admin.
> Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them.
Taken from Microsoft's own documentation: http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure!
People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password.
For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz