Feeds

MS and security: good effort but no cigar

Issues remain

  • alert
  • submit to reddit

3 Big data security analytics techniques

Last week I watched the webcast of Bill Gates speaking at the RSA conference in San Francisco. He talked about Microsoft's plans to build upon the progress it's already made in security. These plans included better protection against spyware and spam. Gates also announced Microsoft's intention to release Internet Explorer 7, complete with a number of security improvements, by the end of this year.

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.exe
C:\Program Files\Internet.exe
C:\Program Files\Internet Explorer\iexplore.exe

You 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.

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 email 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 email 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?

Copyright © 2004, SecurityFocus logo

Mark Burnett is an independent researcher, consultant, and writer specializing in Windows security. He is the author of Hacking the Code: ASP.NET Web Application Security (Syngress), co-author of the best-selling book Stealing The Network: How to Own the Box (Syngress), and co-author of Maximum Windows 2000 Security (SAMS Publishing). He is a contributor and technical editor for Special Ops: Host and Network Security for Microsoft, UNIX, and Oracle. Mark speaks at various security conferences and has published articles in Windows IT Pro Magazine (formerly Windows & .NET Magazine), Redmond Magazine, Information Security, Windows Web Solutions, Security Administrator and various other print and online publications. Mark is a Microsoft Windows Server Most Valued Professional for Internet Information Services.

Related stories

Gates: security concerns propel IE7 launch
Banking Trojan disables MS Anti-Spyware
Microsoft posts record 13 patches

SANS - Survey on application security programs

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.