Microsoft confirms IIS bug gives complete server control
But only if ...
Microsoft has confirmed a vulnerability in its Internet Information Services webserver and spelled out the conditions under which it can be exploited to give an attacker complete control of the server on which it runs.
The good news: As previously reported, remote execution of malicious code can be triggered only in limited cases, and even then, it's relatively easy to change settings that close that possibility. Even then, exploits can still touch off denial-of-service attacks that completely shut down file transfer protocol.
Proof-of-concept code exploiting the vulnerability was released Monday. Microsoft said it will release a fix as soon as it's ready.
The vulnerability can be exploited only if IIS is configured to allow FTP and untrusted users have the ability to create their own directories. Users of IIS on Windows 2000 and Windows Small Business Server 2003 face the biggest threat because FTP is
enabled installed by default, Microsoft said here (under mitigating factors). But even then, users aren't given write access unless settings have been changed.
In that case, or in cases where users of version 5.1 have turned on FTP and write access, attackers can gain complete control over servers by listing directories with specially manipulated names that trigger a buffer overflow in the application.
Users of IIS6 also face the possibility of DoS attacks, but because the application was built using a compiler setting that automatically terminates applications that have been attacked, remote execution is a much more remote possibility, Microsoft said. IIS7, because it runs on the more secure Vista and Server 2008 versions of Windows, is not vulnerable.
For those at risk, Microsoft recommends the following workarounds until a patch is released:
- Turn off FTP if it's not needed
- Disable the creation of new directories
- Disable the ability for anonymous users to write using IIS settings
Microsoft said its working with providers of intrusion prevention systems so they can identify attacks. Definitions for the open-source Snort system are already available here. Admins can also detect attacks by reviewing log files.
FTP is *not* on by default on an SBS2003 server.
AND anyway i let anon upload to my site in places !!! !
just need to monitor those folders carefully !!!!!
If you're running a proper system, then the events (as they happen) are shipped elsewhere. If you've got a public facing FTP server, then (unless it's getting the throughput of something like sourceforge) you should have all commands sent to a machine that has no other link to the system in question, and have automated processes monitoring this constantly.
I believe (although I only looked in passing, I'm not using IIS) that the bug is triggered by accessing a specific named directory - therefore looking for that name in the logs will find the attempt.
No, this is not a good solution, since it detects it after it has been attempted - however, anyone that has this setup can now look back to make sure that they have not been hacked already.
Other than that, you're faced with just assuming that your machine has been hacked, and if anyo of your systems are vulnerable doing a full reinstall.
Not everyone is in the same situation. For some companies, anonymous FTP is how they receive bug reports (including things like core files that are too big to be HTTP uploaded through most business proxies). Therefore there are a lot of very "clever" admins out there that have still got anon FTP enabled. Obviously, they tend not to be running IIS for this, but it's still something to be aware of.