sadmind/IIS side effects

From: Denis Normand (normandat_private)
Date: Mon Jul 02 2001 - 08:36:07 PDT

  • Next message: Jeffery L. Stutzman: "THE HONEYNET PROJECT: July Scan of the Month"

    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
    normandat_private
    
    
    
    
    
    
    ----------------------------------------------------------------------------
    
    
    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
    



    This archive was generated by hypermail 2b30 : Mon Jul 02 2001 - 21:31:07 PDT