Re: Exchange SMTP Hole?
From: Michele (mmagni_at_tiscalinet.it)
Date: 11/11/03
- Previous message: Chris Lynch: "RE: Exchange SMTP Hole?"
- In reply to: Tom Burns: "Exchange SMTP Hole?"
- Next in thread: Mark Norman: "RE: Exchange SMTP Hole?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: <focus-ms@securityfocus.com> Date: Tue, 11 Nov 2003 21:35:07 +0100
Maybe authenticated SMTP using some weak credentials?
Enable security auditing (success). Note that nothing is logged in SMTP logs
when authenticated SMTP is used (just mail accepted with code 250-OK).
See article below, hope it helps.
Bye,
Michele
==== 1. Commentary: A New Kind of Attack ====
by Paul Robichaux, News Editor, exadmin@winnetmag.com
A worrisome new kind of attack is making the rounds on the
Internet. This new threat isn't a worm like SoBig or Slammer, and it
isn't a virus like Swen--it's an insidious spam attack that victimizes
innocent Exchange Server systems. And this attack is succeeding far
more often than it should.
Spammers are scanning the Internet looking for SMTP servers. These
spammers use retrieved banner information to identify Exchange
servers, then use the SMTP service to mount brute-force
password-guessing attacks against well-known accounts on those
servers. That's right: Instead of attacking the increasingly
well-defended Windows remote procedure call (RPC) services that most
organizations use for logon authentication, this attack sends a
barrage of SMTP AUTH LOGON commands until one succeeds.
"But wait a minute," you say. "Exchange Server 2003 and Exchange
2000 Server have relaying turned off by default!" Yes, they do--for
unauthenticated users. But if a spammer manages to snag an
authenticated user's credentials, the spammer can authenticate to your
server and use it to blast out millions of spam messages. As a
consequence, your server (and possibly your entire IP block) will
likely end up on a variety of blacklists--and you'll probably receive
a flood of angry messages from irate spam recipients. To make matters
worse, all this activity probably will fill your queues and
transaction logs, slowing your server's performance.
This attack's dastardly nature is worsened by the fact that the
attack is mostly invisible unless you've turned on auditing for
account-access events. The SMTP log that the Microsoft IIS SMTP
component maintains doesn't record the use of SMTP AUTH, so you can't
look for a sudden spike in the number of AUTH requests to indicate
that you're under attack. Your first warning sign might be that your
server starts getting waves of spam-generated nondelivery reports
(NDRs). Fortunately, protecting your servers against this attack is a
simple process.
First, make sure that your administrator accounts have strong,
complex passwords with more than 15 characters that are a mix of
letters, numbers, and symbols. (When a password has 16 or more
characters, Windows can't locally store the password's easily-cracked
LM hash.) Other user accounts also should have complex passwords, but
protecting your privileged accounts against brute-force password
guessing is especially important.
Second, if you don't allow relaying, consider turning it off
completely on all external-facing servers. If you do allow relaying, I
suggest you reconsider your decision. For example, if you allow
relaying to support external POP users, consider whether you could
accomplish this task another way (e.g., by using the users' ISPs).
Third, consider disabling both basic and Windows integrated
authentication on any SMTP virtual server that faces the Internet.
Doing so prevents password-guessing attacks, but it also prevents
users from authenticating before sending email. If you must leave this
feature enabled, make sure that you also enable account-object
auditing and regularly monitor the Windows event logs for long series
of event ID 528, which failed logon attempts generate.
Fourth, if you use an Intrusion Detection System (IDS), configure
it to watch for failed SMTP authentication requests (i.e., tell it to
look for the text "535 5.7.3 Authentication unsuccessful" at offset 54
in packets on TCP port 25). This warning will alert you to an
attempted attack.
Microsoft knows about this type of attack and will probably take
measures to protect against it at some point. Until then, keep a
careful eye on your servers to make sure they aren't being attacked.
(And thanks to Andy Webb, who first brought this subject to my
attention.)
====================================
----- Original Message -----
From: "Tom Burns" <tburns@torcausa.com>
To: <focus-ms@securityfocus.com>
Sent: Tuesday, November 11, 2003 2:59 PM
Subject: Exchange SMTP Hole?
Good morning all,
I have an exchange server that's been running for quite some time (over
a year) and had it locked down to prevent relay (spam). It is patched
all the way up to 3a.
I checked my queues yesterday and got slammed by spam relaying.
Is there a security hole that MS does not know about yet in SMTP?????
The only way I resolved this was to block connection from 219.x.x.x,
218.x.x.x, 211.x.x.x, etc.
This server has been testing aginst ORDB.ORG and shown to NOT be an open
relay.
If anyone has any suggestions, please let me know.
Thomas A. Burns
System Administrator
Torca Products Inc.
Auburn Hills, MI 48326
248-373-8300 x186
---------------------------------------------------------------------------
Network with over 10,000 of the brightest minds in information security
at the largest, most highly-anticipated industry event of the year.
Don't miss RSA Conference 2004! Choose from over 200 class sessions and
see demos from more than 250 industry vendors. If your job touches
security, you need to be here. Learn more or register at
http://www.securityfocus.com/sponsor/RSA_focus-ms_031027
and use priority code SF4.
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Network with over 10,000 of the brightest minds in information security
at the largest, most highly-anticipated industry event of the year.
Don't miss RSA Conference 2004! Choose from over 200 class sessions and
see demos from more than 250 industry vendors. If your job touches
security, you need to be here. Learn more or register at
http://www.securityfocus.com/sponsor/RSA_focus-ms_031027
and use priority code SF4.
---------------------------------------------------------------------------
- Previous message: Chris Lynch: "RE: Exchange SMTP Hole?"
- In reply to: Tom Burns: "Exchange SMTP Hole?"
- Next in thread: Mark Norman: "RE: Exchange SMTP Hole?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
