trendmicro claims that only a reformat and reinstall will completely remove nimda.
we block all exe attachments at our mail gateway. Steve Spence Subscribe to the Renewable Energy Newsletter: http://www.webconx.com/subscribe.htm Renewable Energy Pages - http://www.webconx.com Mirror Site http://www.webconx.dns2go.com/ [EMAIL PROTECTED] (212) 894-3704 x3154 - voicemail/fax We do not inherit the earth from our ancestors, we borrow it from our children. ----- Original Message ----- From: "Newton, Daniel A" <[EMAIL PROTECTED]> To: <biofuel@yahoogroups.com> Sent: Tuesday, September 25, 2001 10:51 AM Subject: RE: [biofuel] The Flood - unlurking with answers > Un-lurking. > > This may help shed some light on what is going on. More information can be > found at www.mcaffee.com The worm is most likely W32.Nimda which started > propagating 9/17/01 and is still an issue "Out-in-the-Wild" and affects > Microsoft operating systems. Mcaffee has a cleaning solution using their > 4.5 scan engine with Service Pack1 and 4162 dat files. > > "Mcaffee: > VirusScan 4.03 and VirusScan 4.50 will detect the W32/[EMAIL PROTECTED] virus > if > utilizing the correct engine and dat files in all cases, except when the > virus comes on to a machine across a network share. VirusScan 4.03 and > VirusScan 4.50 intercept calls made on the system to open files, read files, > write files, etc. when made from the local machine. VirusScan 4.03 and > VirusScan 4.50 do not intercept these calls when they are being made via a > remote machine as happens when W32/[EMAIL PROTECTED] infects machines via > network > shares. > > In order to resolve this issue computers must be updated to a minimum of > VirusScan 4.50 Service Pack 1, current engine, and current Dats and also > ensure that all machines on the network are running virus protection that > will detect and clean this virus. The ability of the virus to travel via > network shares is due to unprotected machines on the network." > > More detailed information enclosed below. > > Thanks, > Daniel Newton > Systems Administrator > MCSE SCSA CNA > > P.S. I'm looking to brew my first batch for my tow vehicle, a 6.2 diesel > Suburban. Thanks for the wealth of information and keep up the good work. > > > <snip> > -----Original Message----- > From: Russ [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 18, 2001 11:21 AM > To: [EMAIL PROTECTED] > Subject: Alert: Some sort of IIS worm seems to be propagating > > > -----BEGIN PGP SIGNED MESSAGE----- > > There have been numerous reports of IIS attacks being generated by > machines over a broad range of IP addresses. These "infected" > machines are using a wide variety of attacks which attempt to exploit > already known and patched vulnerabilities against IIS. > > It appears that the attacks can come both from email and from the > network. > > A new worm, being called w32.nimda.amm, is being sent around. The > attachment is called README.EXE and comes as a MIME-type of > "audio/x-wav" together with some html parts. There appears to be no > text in this message when it is displayed by Outlook when in > Auto-Preview mode (always a good indication there's something not > quite right with an email.) > > The network attacks against IIS boxes are a wide variety of attacks. > Amongst them appear to be several attacks that assume the machine is > compromised by Code Red II (looking for ROOT.EXE in the /scripts and > /msadc directory, as well as an attempt to use the /c and /d virtual > roots to get to CMD.EXE). Further, it attempts to exploit numerous > other known IIS vulnerabilities. > > One thing to note is the attempt to execute TFTP.EXE to download a > file called ADMIN.DLL from (presumably) some previously compromised > box. > > Anyone who discovers a compromised machine (a machine with ADMIN.DLL > in the /scripts directory), please forward me a copy of that .dll > ASAP. > > Also, look for TFTP traffic (UDP69). As a safeguard, consider doing > the following; > > edit %systemroot/system32/drivers/etc/services. > > change the line; > > tftp 69/udp > > to; > > tftp 0/udp > > thereby disabling the TFTP client. W2K has TFTP.EXE protected by > Windows File Protection so can't be removed. > > More information as it arises. > > Cheers, > Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor > > -----BEGIN PGP SIGNATURE----- > Version: PGP Personal Privacy 6.5.2 > > iQCVAwUBO6dmcRBh2Kw/l7p5AQHJCgQA1JHwqF5RjJX+QVMMDUChVqn6yReQXqEH > Tm8Ujms5+6ia0tcT1qmZWJV48eHYNzV3+AyyO6Gn8ds/NVYJUupDHB1Yy1DY/po6 > iycY2qnARDJP6KNmHI0bAdBUBtsnVo5P9itElIoqKbAorQjamKI2eqd4TdE0yfIO > hSW7yN2lhJc= > =YAwc > -----END PGP SIGNATURE----- > > > -----BEGIN PGP SIGNED MESSAGE----- > > Its been an exhaustive couple of days, for you all I'm sure. > > The Problem > - ----------- > I've just gotten off the phone with numerous experts from the major > companies (including AV experts and CARO members) in an effort to > answer the question; "Is it possible to trust a cleansed server?" > > See, due to the things Nimda does, it may well leave your machine > open to easy access. Even if the virus/worm components have been > removed/cleansed, if another attack occurs that exploits the open > shares (for example) who knows what the attack might do or leave > behind. The effects of such an attack are not going to be obvious to > an AV product. > > Basically, cleansers available now do not address some of the more > insidious components of Nimda; > > - - Guest account being enabled. In the case of an infected Domain > Controller, this means the account is enabled in the Domain. > > - - Guest account being added to the Administrators group. Again, on > DCs the Guest user is added to the Domain Admins group. > > - - Modification to registry keys. Some reports say that values under > LanManServer\Parameters are deleted, in an effort to remove any > AutoShareServer value that might prevent the availability of C$, > etc...), while other reports talk only of the creation of new shares > (C$, D$, etc...) under that key. > > - - Numerous critical system files are modified, including files in the > dllcache directory, and its questionable whether or not these can be > restored to good health by an untested cleanser (the suggestion that > SSL functionality might not work after cleansing.) > > Then there is the question as to whether or not all of the effects of > Nimda have actually been determined. With its buggy operation, its > possible it might do other things inconsistently, in a way that might > leave cleansers lacking. > > Testing we performed today suggested that cleansers that were > available all did a reasonable job of disinfecting an infected file, > but the testing was limited to that since cleansing infected systems > would require an extremely wide variety of installations. > > Additional Threats > - ------------------ > > With the open shares available, it would be possible for an attacker > to gain entry to your system and retrieve or deposit other tools or > data (like copying your SAM). These effects will be undetectable as > part of AV Nimda cleansing, and could only be uncovered as a result > of an extensive forensic effort. > > You should seriously consider the possibility that this has already > happened to machines which might hold sensitive information if you > have left them connected, or reconnect prior to a comprehensive > cleansing and inspection. > > Decision Time > - ------------- > > The bottom line folks is that as of the time of writing, you have to > make a decision; > > a) I need the system up and running now! > > Fine, disconnect it from infection vectors, restore it from tape or > reformat and install fresh, patch it. Restore the data (even if its > infected), run the currently available cleanser, and scan it again > with your AV product. If it passes, reconnect it to the 'net and > carry on. > > b) I can leave the machine turned off until Friday. > > Better, wait for a comprehensive cleanser from your AV Vendor > (assuming they make one.) McAfee may already have one available and > Symantec will have one shortly. Other AV Vendors may/will probably > also produce one. The complexity of this thing has been such that > multiple versions of cleansers have been required in order to do it > "right". The same may be true of these additional cleansers. > > The Problem with Rebooting > - -------------------------- > > We noticed in our testing one cleanser that only worked if the > machine was rebooted. Problem is that with a fully infected system, a > reboot is not likely to bring up a live system. Depending on which > files have been infected, a system might fail a reboot completely, > partially, or succeed completely. Its probably safe to assume that > rebooting an infected server is going to lead to a complete system > failure and cause to re-install the OS. > > Without rebooting it may not be possible to cleanse all of the files > that might cause re-infection. McAfee's recommendation is to stop IIS > and all running applications and install patches, many of those > patches require a reboot to install. > > So you see the Catch-22. > > Definitions > - ----------- > > For the purposes here, an infected system is one where Admin.dll or > readme.exe has actually run locally. In the case of servers, this is > most likely an IIS box infected from the network via one of the IIS > vulnerabilities. It may, unfortunately, be the result of surfing the > web or reading email from a server (really dumb things to do). I've > had reports of Exchange Servers, Outlook Web Access Servers, IIS > Servers, SQL Servers, Proxy Servers, SMS Servers, Domain Controllers, > and File and Print Servers all being infected. > > If the box is actively TFTP'ing (inbound or outbound), issuing > numerous HTTP requests (when you're not surfing), or if your AV > product says you're infected, then you are. If the box has Admin.dll > in the /scripts or root directory, has an enabled Guest account, or > has Guest in the Administrators group (or Domain Admins group), then > you're infected. > > The simple presence of .eml/.nws files, or copies of readme.exe, does > not in and of itself indicate an infected machine. If the files are > put there because of an infected client through a file share, they > may not have been run on the server yet. > > Summary > - ------- > > More than a few people have offered perl scripts and other small > programs designed to clean out the javascript from altered web pages. > While this might seem like a good idea, the fact is that an infected > web server can/will quickly re-add the code back to those pages if > its still infected. Because of the virus behavior of Nimda, if you > don't remove it completely there's not much you can do to prevent > such re-infections. Obviously its not just a matter of removing > files. > > I apologize for the delay in getting more information to those > hundreds of you who have been pleading for help in cleansing your > systems. I had hoped that the AV cleansers made available today would > have solved the problems, but as the day wore on it became clearer > that this wasn't going to happen as quickly as we all want. > > Cheers, > Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor > > -----BEGIN PGP SIGNATURE----- > Version: PGP Personal Privacy 6.5.2 > > iQCVAwUBO6lXDRBh2Kw/l7p5AQHrPQQAxbgWKP8rGiVfHFJVTokzJMzGi851/hOt > At1JKz8e+cTB1iLdfNb7KspV9VpbByBaI+dwZkoZe63pq4OGs1tuBB4PG9h8D4uw > A/iH7Y/OkamrPM9mm4603xougdBs7n4cxwbMvE67kmK39849LWi7SkRGZq9obfKN > dEB3tg6kYws= > =9OVI > -----END PGP SIGNATURE----- > > </snip> > > > -----Original Message----- > From: greg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 25, 2001 7:12 AM > To: biofuel@yahoogroups.com > Subject: Re: [biofuel] The Flood > > > it works for me > ----- Original Message ----- > From: "steve spence" <[EMAIL PROTECTED]> > To: <biofuel@yahoogroups.com> > Sent: Tuesday, September 25, 2001 5:58 AM > Subject: Re: [biofuel] The Flood > > > > that doesn't work either.... > > > > Steve Spence > > Subscribe to the Renewable Energy Newsletter: > > http://www.webconx.com/subscribe.htm > > > > Renewable Energy Pages - http://www.webconx.com > > Mirror Site http://www.webconx.dns2go.com/ > > [EMAIL PROTECTED] > > (212) 894-3704 x3154 - voicemail/fax > > We do not inherit the earth from our ancestors, > > we borrow it from our children. > > > > > > Biofuel at Journey to Forever: > http://journeytoforever.org/biofuel.html > Please do NOT send "unsubscribe" messages to the list address. > To unsubscribe, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> FREE COLLEGE MONEY CLICK HERE to search 600,000 scholarships! http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/FGYolB/TM ---------------------------------------------------------------------~-> Biofuel at Journey to Forever: http://journeytoforever.org/biofuel.html Please do NOT send "unsubscribe" messages to the list address. To unsubscribe, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
