RE: [Declude.JunkMail] OT: Alert: New IIS Worm
Sorry about the invalid certificate people... For some reason IMAIL has to put a ">" in front of "From NTBUGTRAQ:", and thus modifying the message. -- Regards, Terrence Koeman Technical Director/Administrator MediaMonks B.V. (www.mediamonks.nl) Please quote all replies in correspondence. smime.p7s
[Declude.JunkMail] OT: Alert: New IIS Worm
Offtopic >From NTBUGTRAQ: 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 Ok, whoa horsy, I've got lots of copies of ADMIN.DLL now thanks! Analysis is still on-going to determine precisely what the infecting files do (there are potentially two, ADMIN.DLL and README.EXE). Some people have said their boxes seem unstable. It could be because of numerous copies of TFTP.EXE in memory. At this point it might be best to disconnect any computer that appears unstable from the network, until such time as sufficient analysis has been performed to advise how best to bring the box back on-line. It is also possible for client machines to perform the attacks that we're seeing, if you have a way to filter outbound HTTP requests you should look for anything that contains "/scripts" or "tftp" in the URL and treat as suspicious. The internal threat by this one is no different (and maybe worse) than CRII. We've seen indications of WnetEnumResource calls as well as references to IPC$. There may be NetBIOS share activity associated with the worm, and if so, it will likely spread rapidly internally. More than likely you will see the biggest effect in terms of a DoS (from many source machines). This thing cares not whether you're an IIS box or not, it tries regardless. As this spreads the effects may become more severe (no, I'm not going to provide a quote on how severe). Make sure you're inbound (and preferably your outbound) router rules are restricted to only those protocols that must be present, and ideally to machine IP addresses that should have access. More as it becomes available. Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor Numerous people have reported that on IIS servers infected with w32.nimda.amm, when visitors browse to their website the visitor is offered up README.EML, which in turn downloads README.EXE to the visitor. Please, check your IIS boxes now to see if you are infected. I've had reports of IIS servers with more than 10,000 .eml files present (mostly as a result of nimda). While we don't have any conclusive disinfecting procedures yet, any IIS box that has been infected definitely shouldn't be available to clients until we do. Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor -- Regards, Terrence Koeman Technical Director/Administrator MediaMonks B.V. (www.mediamonks.nl) Please quote all replies in correspondence. smime.p7s
Re: [Declude.JunkMail] Declude crashing and taking up 99% CPU
Actually, I take that back. There might be a problem with 1.24 but not with 1.23. - Original Message - From: "Frank" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 18, 2001 9:48 AM Subject: Re: [Declude.JunkMail] Declude crashing and taking up 99% CPU > Scott, > I don't remember having any problems with 1.24. > > - Original Message - > From: "R. Scott Perry" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 17, 2001 5:13 PM > Subject: Re: [Declude.JunkMail] Declude crashing and taking up 99% CPU > > > > > > >As I've stated several times: I'm not getting an error message, no files > are > > >being created and no event log messages. (I'll double check my gigantic > log > > >files to be sure of the first..) > > > > It appears that there are 3 separate issues (you're seeing #1): > > > > [1] 100% CPU usage, that appears to have started between v1.20 and > > 1.25a. This has been narrowed down to several possible areas of code > where > > this is happening. No C:\Declude.gp? file is created. > > > > [2] A crash, where a C:\Declude.gp? file is created. This is happening > > somewhere within the spam testing section of the code, but it is hard to > > pinpoint exactly where this is happening. > > > > and > > > > [3] The known "C142" issue with user32.dll initializing, because of > the > > low "system heap" or whatever Microsoft is calling it. This one can > happen > > with just about any version of IMail, with or without Declude, because of > > IMail's architecture. There is no way to "fix" this, but we are trying to > > find a way to make this less noticeable when Declude is used with IMail, > > however. > > -Scott > > > > --- > > > > This E-mail came from the Declude.JunkMail mailing list. To > > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > type "unsubscribe Declude.JunkMail". You can E-mail > > [EMAIL PROTECTED] for assistance. You can visit our web > > site at http://www.declude.com . > > > > --- > > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". You can E-mail > [EMAIL PROTECTED] for assistance. You can visit our web > site at http://www.declude.com . > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
Re: [Declude.JunkMail] Declude crashing and taking up 99% CPU
Scott, I don't remember having any problems with 1.24. - Original Message - From: "R. Scott Perry" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 17, 2001 5:13 PM Subject: Re: [Declude.JunkMail] Declude crashing and taking up 99% CPU > > >As I've stated several times: I'm not getting an error message, no files are > >being created and no event log messages. (I'll double check my gigantic log > >files to be sure of the first..) > > It appears that there are 3 separate issues (you're seeing #1): > > [1] 100% CPU usage, that appears to have started between v1.20 and > 1.25a. This has been narrowed down to several possible areas of code where > this is happening. No C:\Declude.gp? file is created. > > [2] A crash, where a C:\Declude.gp? file is created. This is happening > somewhere within the spam testing section of the code, but it is hard to > pinpoint exactly where this is happening. > > and > > [3] The known "C142" issue with user32.dll initializing, because of the > low "system heap" or whatever Microsoft is calling it. This one can happen > with just about any version of IMail, with or without Declude, because of > IMail's architecture. There is no way to "fix" this, but we are trying to > find a way to make this less noticeable when Declude is used with IMail, > however. > -Scott > > --- > > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". You can E-mail > [EMAIL PROTECTED] for assistance. You can visit our web > site at http://www.declude.com . > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
Re: [Declude.JunkMail] ByPassing IP's
> This may be a stupid question but I can't figure it out. I would like >Declude to bypass a certain amount of IP addresses. These are mostly >feedbacks and e-mail forms coming from some web pages I host. When people >receive the forms it fails the SPAMHEADERS test and gets a note. I attempted >to put then in the WhiteLists but it doesn't do it. Am I just brain dead ( >Lately I am ) What you need to do is have a line "WHITELIST IP 127.0.0.1" (replacing 127.0.0.1 with the IP of the mail server that is connecting to IMail), placed in \IMail\Declude\global.cfg. You can have up to 100 of these lines in there. -Scott --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
