Bugtraq mailing list archives
Re: MailSweeper for SMTP Security Problem
From: "Gordon, Paul" <Paul.Gordon () GETRONICS COM>
Date: Wed, 28 Mar 2001 17:56:31 +0800
From the look of Russ' e-mail, the problem has nothing to do with mail
relay, but instead with applying the correct scenario. When Mailsweeper receives a message, it checks all scenarios for a match. If the (supposed) sender is JoeBloggs () mydomain com and the receiver is user () mydomain com, matches will be generated for both the Incoming and Outgoing scenarios. So which scenario does Mailsweeper apply? Now it comes down to scenario priority. If the scenarios are: Incoming: *@* --> *@mydomain.com Outgoing: *@mydomain.com --> *@* then they both will have the same priority. This is because both scenarios contain a fully wildcarded and an explicit entry. So since both scenarios have the same priority, which scenario does Mailsweeper apply? Now it comes down to the scenario folder's position in the scenario hierarchy. The Outgoing scenario would only be applied if this scenario appeared above the Incoming scenario in the hierarchy. This processing is applied regardless of whether the sender's address is spoofed or not. Regards, --------------------------------------------------------- Paul Gordon Getronics Solutions (S) PTE LTD Security Consultant 1 International Business Park The Synergy Ph: +65 890 2828 #02-14/15 Fax: +65 890 2888 Singapore 609917 Email: paul.gordon () getronics com --------------------------------------------------------- -----Original Message----- From: Hugo van der Kooij [mailto:hvdkooij () VANDERKOOIJ ORG] Sent: Wednesday, 28 March 2001 2:04 To: BUGTRAQ () SECURITYFOCUS COM Subject: Re: MailSweeper for SMTP Security Problem On Tue, 27 Mar 2001, Russ Hayward wrote:
There appears to be vulnerability with Mail Sweeper for SMTP email by Content Technologies. (Tested on Version 4.19, others may be vulnerable) My test system is - Windows NT 4 Service Pack 5 MailSweeper for SMTP version 4.1.9
Version number 4.1_9 is assumed here.
I have two separate incoming and outgoing policies scenarios, I trust (!)
my
users and allow all internal users to send what they like (no restrictions) but restrict incoming emails with virus checks, text analysis, exe file checks etc.. etc.. The Incoming scenario applies to this address list *@* --> *@mydomain.com and the Outgoing Scenario applies to *@mydomain.com --> *@* The SMTP relay restrictions ensure that only mail destined for the local domain are forwarded. The problem occurs when an attacker spoofs an email so the sender appears
to
be a user within my domain i.e. JoeBloggs () mydomain com and the recipient is the intended
victim
i.e. user () mydomain com MailSweeper will apply the OUTGOING scenario (i.e. nothing) and forwards
the
mail internally to the intended victim. This email could contain any content.
The problem here is not in the software but the configuration. Outgoing mail should be restricted to the internal mailserver(s) and a properly configured systems passes al the email relay tests. I've installed about half a dozen systems with mailsweeper and none of them allow relaying. All of them have been tested externally for all variants of email relay including bangpath variants. Some were tested by the ISP as well as one was installed in a rush to stop an email relaying problem that is present in v3 of the MailSweeper for SMTP product and can not be fixed in the configuration. Hugo. -- Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ Maasland hvdkooij () vanderkooij org http://hvdkooij.xs4all.nl/ Alle email is gebonden aan de regels beschreven op mijn homepage. All email send to me is bound to the rules described on my homepage. Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger.
Current thread:
- MailSweeper for SMTP Security Problem Russ Hayward (Mar 27)
- Re: MailSweeper for SMTP Security Problem Hugo van der Kooij (Mar 27)
- <Possible follow-ups>
- Re: MailSweeper for SMTP Security Problem Martin O'Neal (Mar 27)
- Re: MailSweeper for SMTP Security Problem Gordon, Paul (Mar 28)