With official support for Windows XP set to end on April 8th, what are the biggest security fears and what should users do about it?
Windows XP is by definition an easier target for exploit developers than more modern versions of Windows. While Data Execution Prevention (DEP) was introduced in Windows XP SP2 (though its not on for most programs by default on Desktop OSes even on Windows 7), Address Space Layout Randomization, a feature that makes it more difficult for attackers to build reliable exploits was not introduced until Windows Vista. Additionally, by default Windows XP stores passwords hashed using a legacy, insecure algorithm, LM hash. If you have not been keeping your Windows XP systems patched, they may already be vulnerable to full compromise from the network with known issues in easy to use tools such as Metasploit. For enterprises that are not patching regularly and providing security oversight, the end of support for Windows XP will make no difference. These systems are vulnerable to attack today and they will vulnerable to attack tomorrow. On the other hand, if you are keeping your Windows XP installs up to date on patching as well as providing oversight for patching and security for third party programs installed such as FTP servers or client side programs such as browsers or PDF readers, your Windows XP systems may be as secure against known vulnerabilities as Windows 7 or Windows 8 systems. That’s all about to change though. With Microsoft ending support for Windows XP, any vulnerabilities that are discovered in the future will not be patched by the vendor, leaving all installs of Windows XP perpetually vulnerable.
[wp_ad_camp_4]
How big a deal is end of support for XP really going to be for enterprises that still have XP deployed but are keeping up to date with known security issues? It’s hard to say at this point. On the one hand, talented security researchers have discovered many exploitable security issues for XP during its tenure. A lot of bugs have been patched by Microsoft. It is not going to be trivial to get command execution access to Windows XP from the network. There will likely be better success with client side attacks, requiring an active user using the vulnerable system. But as seen at the recent Pwn2Own hacking contest where the latest versions of Flash, Safari, Firefox, etc. all fell victim to new exploits from researchers, with enough time and effort, it is possible to find exploitable bugs on nearly any target, even ones that use the latest and greatest security mitigations. Look at the iPhone for example. Each time an operating system update is released, Apple is throwing down the gauntlet that this time there will be no jailbreak; this version of the iPhone operating system is secure. And every time, give it a few weeks to a few months, a jailbreak is developed.
With XP losing support, it suddenly becomes a more lucrative target for bug hunters. Any exploitable bugs that are found will remain exploitable since no patch will be released. The only way to make these bugs less valuable, and thus cause bug hunters to turn their attention to another target, is decommissioning all Windows XP systems for later, more secure versions of Windows. If you use later versions of Windows in your enterprise it may seem foreign to you that anyone could still be using XP, but in my pentesting career I’m still running into XP and even Windows 2000. If you spend any time in airports you may see a Windows XP screensaver or two on by mistake as you look at flight listings and other informational screens throughout the environment. Computer labs in enterprises or universities are another culprit I see a lot.
I once worked with a client who had recently rebuilt their Windows infrastructure using Windows 2008 and Windows 7. Client side exploitation and social engineering were not in scope at this phase of the test, so I was having a bit of trouble getting access to the domain. Even password guessing wasn’t going too well for me. But then I found it, an old Windows 2000 box that used to be the domain controller. And like most Windows 2000 systems you find still running, it was trivial to get SYSTEM level access from the network. Technically I now had domain admin, albeit on a domain controller with no client machines. So my pentest was a success, right? But I hold myself to a higher standard, requiring access to sensitive data, and domain administrator privileges on all domains in the enterprise, etc. before I am satisfied with the test. This Windows 2000 box had nothing interesting on it at all. No email accounts, no sensitive data, no domain clients. However, there was one little problem. Being the domain controller this system stored the domain password hashes locally. And if you recall Windows 2000, like Windows XP stores both the legacy LM hash and the newer, more secure NTLM hash of Windows passwords. LM hash is completely reversible, regardless of how strong the password is. The domain admin password for the Windows 2000 domain was 9 characters long, had characters from multiple complexity classes, and was not based on a dictionary word, but since I had the LM hash I was able to brute force it in less than an hour. Can you guess what the domain admin password on the client’s new Windows 2008 domain was? You guessed it, the exact same password, giving me domain admin access to all those patched and hardened Windows 7 clients with email accounts, customer’s medical data, etc in plain sight. My client had done a lot right. They had updated their infrastructure to modern versions of Windows, no longer using the unsupported legacy system as a domain controller. They were using strong passwords (though I recommended to them in the future that they should not reuse passwords across domains and should change all passwords on a regular cycle.) Their main problem was that they had left the Windows 2000 system running even though it no longer served a business function. So let this tale from the crypt of pentesting be a warning to all.
Georgia Weidman | CEO, Bulb Security LLC | @georgiaweidman
To find out more about our panel members visit the biographies page.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.