Internet Information Server (IIS) is not renowned for its security. Though unfortunate for Microsoft, it has been good for security vendors who can sell additional security products.
WatchGuard is one such company, with its AppLock/Web product, an IIS-specific version of its ServerLock product. WatchGuard firmly believes that the point of this protection is to prevent all current and future attacks.
Some products work on a pattern-matching basis and have to be updated to keep up with cracker's latest exploits. But, if you're going to update a product, why not just update IIS when a new patch comes out? By creating a more generic protection scheme, there is more confidence that a computer can't be hacked. Unfortunately, the software failed to perform to expectations.
To test it, we installed it onto a standard Windows 2000 server running a completely unpatched version of IIS. During installation we ran into our first problem - picking a password for administration rights.
AppLock enforces a strong password policy. Only entries with upper and lower letters, numbers and punctuation are deemed good enough. However, after trying a few combinations, the console still refused to admit that the password was adequate.
Ultimately, we had to resort to a random mix of characters. This is the kind of password that will find itself written down on a Post-It note and is far less secure.
Testing time
Once this was done, we were ready to test the software. It's all managed through the console, which is accessed by a padlock-shaped icon in the system tray. This icon displays the status of the application by changing colour - green on, red off. Double-clicking it launches the control panel, which is where the software is managed.
Don't expect a full array of controls, as with products like SecureIIS, because AppLock only has one built-in measure of protection: file system.
The software scans the local hard drive looking for files that are related to the web server. These files are then marked for protection and can't be modified or deleted even by an administrator.
In addition, all the other files on the drive can be manually selected for protection, but working out what to protect and what to ignore is a very time-consuming process.
Once this is done, a button marked 'Lock Server' is used to engage the protection. To see how good this really is, we attempted a couple of basic attacks using some Perl scripts.
These scripts exploit the Unicode and ISAPI bugs that have been well documented. It was the ISAPI bug that was used to create the Code Red Trojan, which affected a lot of IIS users. Unfortunately, the Unicode and ISAPI exploits both worked correctly against our test machine, giving us command-line access to the server.
After we contacted WatchGuard we were told that the software had been updated to protect against Code Red and associated threats, and we should update our software by downloading the new version off the website.
This created a problem, as AppLock didn't show up in our installed program list, so we could not uninstall it. We decided to try and download the new version of the software anyway. On installation it stopped part way through and told us to get the patch.
This is easier said than done, however, as you have to have a LiveSecurity registration to get any patches. This takes a while to set up, but once done, all patches for the software become available. After downloading version 1.0.1 and entering our impossible to remember password, we were ready to try again.
Unfortunately, the software still failed to protect against these attacks.
The only thing that it managed to do properly was protect those website files it had found. This did mean that we were unable to modify any content.
However, we don't feel that this is enough. We still had full reign of the machine and only a specific subset of the file system was protected for modification. Even in these circumstances we were able to view the contents of the files. This is particularly dangerous as we could look inside scripts.
As a lot of websites are set up to login to SQL databases to retrieve content, we could conceivably get hold of the passwords - and you'd be surprised to know how many scripts contain the administrator username and password.
With this information we no longer needed to get access to the web server to play around with content. There could be other confidential information on the website, such as credit card numbers.
Poor protection
Looking further at the software, we found more problems with the way it worked. By default, the software will only protect those web server files that it knows about. We realised from our exploits that this allows new files to be created.
But these files are now not protected by the application. This is true even if an administrator creates the files. So, if an update to the website was put in that place, additional files on the server could be modified or deleted.
We tried this by turning on protection and then creating a new HTML file. By telneting to the machine via the Trojan we had installed earlier, we could modify this file without the software even blinking.
We don't think this software is good enough to be used in a production environment. While it can stop files from being modified or deleted, it doesn't prevent anything else. A cracker could easily use one IIS machine as an entry-point into other unprotected machines.
Eventually, the only thing that AppLock successfully protected itself against was being uninstalled so that an alternative could be used!
Contact
WatchGuard: 0118 902 2521 www.watchguard.comALTERNATIVES
AppLock/Web left a lot to be desired, so we turned to our backlog of reviews to find something that in our opinion works better. We found two suitable products: SecureIIS and Entercept.
Both products are designed to protect file systems in much the same way as AppLock/Web. However, both products also provide multiple levels of protection. For example, SecureIIS will block generic buffer overflow attacks and look for shell commands in requests.
Entercept is capable of looking for directory traversal requests. Both products are much more capable and, more importantly, block the kinds of attacks that you are likely to see with a IIS machine.






Do you agree?
Have your say on this article