sadmind/IIS side effects

[Denis Normand <normand () interlink net>]

This may have been reported already, but just in case:

The first side effect of the worm has a very positive aspect: it’s doing

more to have system administrators apply security patches to their boxes

than any advisories had. At least for the Solaris boxes that were
infected and for which the sysadmin was notified, and for the IIS boxes
that were actually defaced.

The second side effect affects systems that were susceptible to the
vulnerability but were not defaced. The danger stems from the fact that
even if these system are patched after being visited once by the worm,
they may still be vulnerable, unless a complete reinstall of the server
is performed. This is not related to the service pack/patches version
issue.

While performing an assessment for a client to implement an IDS
infrastructure, I’ve noticed that their IIS servers had been visited by
the sadmind/IIS worm. By now, almost every IIS boxes on the Net must
have been visited at least once. All of the client’s servers had been
patched and the defacement were unsuccessful. There was one server
however that was not defaced and was not patched.

The worm is relying on the fact that the IIS root directory is located
on the same drive as the operating system, usually C:. The worm performs

various attempts, actually 13 variations, at executing the
\WINNT\SYSTEM32\CMD.EXE through the /scripts/ directory, which has
execute permissions on a default install. If IIS was installed on
another drive than the operating system, these will fail. Then comes the

strange 14th attempt from the worm. If the folder to which the IIS
virtual folder /msadc/ points to is located on the same drive as the
operating system, in C:\Program Files\Common Files\System\msadc\  for
instance, the worm is successful at executing a directory listing
through CMD.EXE. It then copies CMD.EXE as ROOT.EXE in the current
folder, /msadc/ in this instance. Then, strangely, the worm attempts
it’s defacement activities through the /scripts/ folder, which obviously

fails since no ROOT.EXE is found there at that point. After failing it’s

exploit the worm then goes on to it’s next victim.

> From then on, CMD.EXE, under the name of ROOT.EXE, is located in the
/msadc/ virtual folder with execute permission. This means that, without

relying on any directory traversal tricks, an intruder can easily invoke

ROOT.EXE and compromise the machine.

By the extent of IIS machines that have been visited by the worm, my
guess is that there must be a fair amount of systems with a
configuration similar to the one my client had, that were not defaced,
hence did not alert their system administrator, and now have an
extremely powerful executable at the disposal of whoever comes by, even
if these administrators have patched their systems after a first visit.
Deleting ROOT.EXE solves the problem, though the pertinence of keeping
/msadc/ in the first place should be questioned since it also represent
an easy entry point unless carefully configured. Also, as a precaution,
any such system should be rebuilt with a clean install, in case it had
already been compromised at some point in time.

Again, this issue might have been reported already, but I just wanted to

make sure that people that have a similar IIS configuration were aware
of the possible threat that this side effect of the worm introduces.


Denis Normand
normand () interlink net






----------------------------------------------------------------------------


This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see:

http://aris.securityfocus.com