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