[19907] in bugtraq
Re: MailSweeper for SMTP Security Problem
daemon@ATHENA.MIT.EDU (Gordon, Paul)
Wed Mar 28 14:17:25 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <471A371A1A7B2C4793E8A744FDD49B7A1B500A@exchkhk102.asia.unity>
Date: Wed, 28 Mar 2001 17:56:31 +0800
Reply-To: "Gordon, Paul" <Paul.Gordon@GETRONICS.COM>
From: "Gordon, Paul" <Paul.Gordon@GETRONICS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
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.