Now that Microsoft has pruned Windows of its most serious remote-access holes, its time Redmond fixes the local vulnerabilities too.
Microsoft certainly is aware of this issue. In fact, it was probably a design decision.
Looking back, the company has indeed made notable progress in the security of its software. Windows XP SP2 is a significant achievement, and Gates reported that over 170 million people have downloaded the update. The low-hanging fruit of millions of insecure Windows machines is rapidly falling from the tree.
But we're not out of the woods yet. If you can gain any user access to a Windows system, it is still surprisingly easy to completely own that box. So far, these problems have been overshadowed by the countless remote holes we've seen in recent years, but privilege escalation by authorized users is an important issue today that is still too easy to exploit.
Take, for example, the way that Windows handles file paths with spaces. Suppose that you want to run the following command:
C:\Program Files\Internet Explorer\iexplore
One cool thing about Windows is that although the path contains a space, it still runs the application fine, even if you don't place quotes around the entire command and even if you don't use the executable extension for iexplore.exe.
But how does Windows know where the program path ends and the program's command line parameters begin? How does it know that the user isn't trying to run a program named "C:\Program.exe" with the parameter "Files\Internet Explorer\iexplore?"
The problem is that it doesn't know. It just starts at the beginning and tries finding an executable until it finds a match. So in this case, it will try these files every time you run the command:
C:\Program.exeYou might see where I'm going with this: if you place an executable named program.exe in the root directory, it will probably end up running quite a bit. In fact, it will run anytime Windows launches a Program Files executable that does not have quotes around the path.
C:\Program Files\Internet Explorer\iexplore.exe
Microsoft certainly is aware of this issue. In fact, it was probably a design decision at some point. If you run Windows XP, try placing an executable named program.exe and reboot your system. When it restarts, Windows will warn you about the complications of having that file there.
Here's the problem: there are thousands of paths in the registry that do not have quotes around them, and many Windows systems have weak NTFS permissions that allow any user to write to the root directory. This is bad. As an experiment, I created a small program that simply logged every time it ran and under what user context. I rebooted and checked my Event Log. It turned out that on my system it ran eight times, twice under the context of the SYSTEM account and the rest as my own administrative account.
Of course, I got the message box warning of the file, so I made a slight modification to my program.exe. It turns out there is a registry key that you can set to turn off this warning. I simply change that setting every time my program runs. Since the first couple instances executed before I even logged in, there was no warning at all. And of course, there are plenty other executable name variations that Windows does not check.
Criminals Get Smarter
This could be a serious issue, and it's not the only one. Another weakness is all the batch files and scripts that administrators use. Sure, scripts are convenient, but you must take care to protect these files. Too many administrators leaving them laying around in directories where Everyone has write access to the files. All an attacker with low-privileged access needs to do is add their code of choice to the end of your script and it runs under your security context the next time you use the script.
Fortunately, Windows allows you to enforce script signing policies, but there is no way to enforce signing of a batch file. You must also protect files such as .reg, and .inf that an attacker might exploit. If you use scripts on your servers, make sure they have strong NTFS permissions.
Then there's the issue of poorly secured server applications. In my experience, third party Windows mail servers are particularly vulnerable. Some let you run code based on an e-mail message, use executable auto-responders, and execute external virus and filtering applications. But what happens if the user is able to run any application of choice?
I have seen many, many mail server directories that allow all users full control over the files in that directory. Sometimes it's the mail server installer that does this and sometimes it is the administrator's fault. Some mail servers even require loose permissions for some user features to work properly.
This means that regular users can modify these settings and send themselves an e-mail to get executables running in the context of the mail server's service -- which is often the SYSTEM account. Obviously, I'm oversimplifying what's involved here, but take a close look at the file permissions for your server applications. Can users get the server to run their code?
Depending on your server, you should even consider denying all access to any account besides the service account. Too many server applications store user passwords using weak encryption and all an attacker might need is Read access to that file. Many of these flaws are well known, and there are many more that are still not publicly known. Most users do not need Read access to these files.
So far, I have only scratched the surface. There are problems with FTP client apps storing passwords, browser issues, auto run issues, and of course, the serious problems of physical server access. We have raised the bar some, but we are nowhere near done. If you have any access to a system, you can likely gain administrative access.
Sure, Microsoft is eliminating the low-hanging fruit. But what happens when there is no more low-hanging fruit? Crime doesn't stop because it is harder. Criminals get smarter. The question is, will we be ready when that time comes?