Security by Obscurity ALONE is NOT Enough: How 10 registry settings will NOT Harden your WIndows XP box

Today I was informed of a new paper by Debra Shinder on 10 Registry Hacks for hardening Windows XP security. Now, I have read and enjoyed other pieces of work from Debra over at WindowsSecurity.com, but this one just doesn't cut it for me. I think a lot of information is missing in this paper that quite frankly, isn't really hardening XP security at all.

First a foremost, if you are going to write a paper on registry tweaks to increase the security effectiveness of Windows XP, you REALLY need to explain the benefits and drawbacks of the change. Risks need to be clearly identified from the perspective of a threat model. Simply making a change and not understanding the real underlying impact could be dangereous in any organization.

Secondly, a lot of these "security hardening" tips can easily be circumvented. As an example, in #3 where she explains that you can use the RestrictRun to limit what a user can run, you create a false sense of security stating that they can only run what is in the list. Here is a quick way to bypass this security setting. It only checks the the list by name, finding the first instance in the environment path when executed. This means that if you have access to Explorer or even Internet Explorer, you can simply rename whatever you want to execute to its name, and then be done with it. What would I do? If they allowed msword.exe to run I would copy regedit.exe to msword.exe and place it in a dir at the beginning of the PATH environment variable. Guess what? I simply run "msword.exe" and then go into this registry key and turn off this setting. Why does this work? Because no effort goes into checking the validity or path of the executable. It does it simply by name. It is possible to lock down run execution on a system, but it takes more than simply making this change.

But then again, if you recall I always state that security is about risk mitigation, not risk avoidance. As part of a plethora of other configuration changes, it is possible to control how a user uses the system. RestrictUser can be very effective when bundled with group policy and strict ACLs that prevent such actions. Everything needs to be weighed accordingly. But simply making this change is not enough.

Some settings that Debra suggests sound good in theory, but aren't so good in practice. Consider the recommendation to flush the pagefile.sys on shutdown. Great idea in theory. The pagefile holds plenty of juicy bits of privileged information that can easily be extracted with the right tools. But the benefits of this setting are simply outweighed by the drawbacks. What do I mean? Well consider this. First off, what this prevents is people seeing information from memory on the harddrive. But its only useful for inactive harddrives after shutdown. This means that the attacker would have had to have PHYSICAL access to the box to steal it. So other security measures should already be in place to prevent that. Oh, and any good computer forensic auditor will tell you that the first thing you do when seizing a machine is pull the plug on machine, keeping the pagefile intact on the harddrive. The setting does NOTHING to prevent that.

Now you might be saying to yourself... ya but what about laptops? Well first off, the pagefile only gets wiped on shutdown, and most people suspend or hibernate their machines. Secondly, as Susan so elequantly stated to me, "this is a career limiting move" since if you tried to have your CEO accept this practice, he's gonna think about firing you. Why? These days with the amount of memory in the machines, it takes an AWEFULLY long time to write out the page file. In many cases you might just have to pull the battery on the puppy. Remember, executives are running around all day. The last thing they need to do is sit and wait for their laptops to shut down.

Another thing to look at is the fact that of the 10 registry tweaks, Debra uses 4 of them in HKEY_CURRENT_USER. This means that any security setting you try to set for the user can easily be circumvented by the user by simply running regedit.exe. And that is assuming that she is using least privilege correctly and is running all accounts as "limited users". I'm not entirely sure that she is.

Why do I say that? Because if you try to access the System properties as a limited user you will find you don't have permissions to modify the very things she says this tweak will prevent! Try it. As a "limited user", you will find that you can't do a lot. Oh, and if that doesn't convince you that this setting is pretty moot, simply open up the Run box and type "control sysdm.cpl" (without the quotes) and the System panel will come up anyways. Security by obscurity alone is not enough to make a system secure. Especially when its so trivial to get access to the very things she trying to prevent.

Her suggestion of preventing null sessions is ok. But this would be better handled in a personal firewall. Why? Because you can then audit when someone TRIES to make such a connection to the machine. It's not only important that you make good security decisions to meet corporate security policy objectives, you need to be able to audit and measure these decisions accordingly. It's a much better idea to ensure you can log access violations against your security policy through these means rather than by simply blocking them with a registry setting.

Her last recommendation to hide the Security tab is something I am completely against. First off, normal limited users typically don't have that turned on by default. And Administrators SHOULD have this on so they can see the ACLs on the system. More importantly, this is so easy to circumvent as a limited user by simply opening up an explorer window, going to the "Tools" menu, selecting "Folder Options", selecting View and then unchecking "Use Simple File Sharing".

Now to be fair, I believe that Debra's registry tweaks have merit. As part of a defense in depth posture some of these settings can indeed help when deployed correctly. However, its a far cry from actually "hardening Windows XP" from users. If this document was updated to include defining the threats that the changes mitigate against, and the risks and drawbacks of making these security changes, it might make for a much better paper.

I would recommend you go check out some of Debra's other papers over at WindowsSecurity.com. This paper is uncharacteristic of her past performance, and you might find more useful information there.

YMMV.