Windows provides the best platform for security solutions. So I said.
Now, let’s imagine the perfectly secure enterprise. Everyone is using smart cards to log on to the systems – user passwords aren’t used at all. AD, Kerberos and SSL where applicable. What can go wrong?
A lot. Because backward compatibility is a big issue. For example, you are a smartcard-only Windows user. You don’t use a password – but you still have a password. Really long and random – if you get a NTLMv2 hash and try to brute force it, you are likely to come across a collision before getting the true password (pure speculation on my side). But NTLM (v2 – whatever) still exists in this ecosystem. It may be used in remote administration and service account scenarios.
Marcus Murray, a security MVP, and his colleagues of Sweden’s Truesec, came up with a spectacular technique of using NTLM hashes instead of logon credentials in NTLM-based environment (which is every Windows environment, for now). Here’s a video of the attack. Marcus is blogging – in English – about the attack as I type this.
So opportunity is there. All that is required is owning (as in: 0wn1ng, or having local system-equivalent rights) a workstation in an enterprise, and getting a privileged domain user, or a domain service account, to log on to the workstation – and then I can account of those, with all the privilege, in the entire domain.
There are ways to mitigate the risk. You can make it really hard to compromise a workstation – full disc encryption is a very good first step. You can limit the scenarios of remote logons to the workstations – using technology and process.
But the right approach would be phasing out NTLM. Mark Russinovich of Sysinternals fame, a MS Technical Fellow, told me they are working on that but couldn’t provide details. Just like we can disable LM and NTLM, we should be able to do same with NTLMv2. I guess it’s possible to create a rootkit that will do just that – but we want that coming from Microsoft. Something to do in Windows “7”. Generally, it’s a good idea to include backward compatibility as a feature. But software vendors should provide an option to turn off legacy protocols. As long as we are in control and can to testing and plan migration, that would be the right balance.