Re: Sender Spoofing via SMTP

[Tomasz Nidecki <tonid () hakin9 org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Friday, November 11, 2005, 3:21:20 PM, Devdas Bhagat wrote:

> > I don't think there is a product on the market that would implement
> > such a strategy [I wish there was... maybe I'll write one some time
> > in the future? 8], which would have the following strategy applied:

> Almost any MTA available today allows for this kind of policy.

I disagree. Not directly. Not MTA. This is usually scriptable and can
be achieved using an MDA such as Procmail. But not in a way that you
"turn on one option" in your MTA and it does all that I've described.

> > 2. For an UNAUTHENTICATED user:
> > 2.1. Check the domain in MAIL FROM against a list of your local
> >      domains
> > 2.2. DENY the mail if it matches, since there should be no such case
> >      where an unauthenticated user is sending mail with your MAIL
> >      FROM.

> Clue: .forward

.forward is MDA-level, not MTA. Additionally, how would you suppose to
check using .forward, whether the user has authenticated or not, if
most MTAs add no headers to inform the MDA or MUA that the user has
indeed authenticated? Besides - why receive the whole message, queue
it and use up all the resources, if this can be done BEFORE the
message is received, at envelope level?

> > 2.3. Additionally, if possible, also check the domain in From: header
> >      in the DATA section, before queueing it, and do the same as
> >      above.

> Clue: Mailing lists.

The fact that they use such a technique does not mean it can directly
be used in the MTA before accepting the mail.

> > 3. For an AUTHENTICATED user [SMTP AUTH]:
> >
> > 3.1. Check whether the username given in the SMTP AUTH dialogue
> >      matches the username given in MAIL FROM and later From: headers.
> >      If it doesn't, deny mail. This might be problematic, if you have
> >      for example a user who wants to send mail as boss () yourdomain com,
> >      whilst the account name is johndoe () yourdomain com [boss is an
> >      alias], therefore an alternative method could be used:

> I can think of a few dozen reasons to use different addresses
> legitimately (clue: role accounts).

Hence the alternative for those who must use those different
addresses.

> > 3.2. Replace the MAIL FROM header with the true account name and valid
> >      domain for that account name, and possibly add a separate header
> >      [or at the end of the From: header] stating "(Authenticated as
> >      johndoe)". This will then make it clearly visible, who actually
> >      sent the mail [because that person must have authenticated].

> Exposing internal username information, allowing easier attempts at
> bruteforcing passwords. You might want to dump this to syslog only.

Clue: most MTAs these days allow for using different usernames and
passwords in the SMTP AUTH dialogue. It's enough to set up uniquely
identifying usernames for all your users and give them different
passwords, and this strategy will not expose anything.

- --
Tomasz Nidecki, Sekr. Redakcji / Managing Editor
hakin9 magazine            http://www.hakin9.org
mailto:tonid () hakin9 org      jid:tonid () tonid net

Do you know what "hacker" means?
http://www.catb.org/~esr/faqs/hacker-howto.html

Czy wiesz, co znaczy slowo "haker"?
http://www.jtz.org.pl/Inne/hacker-howto-pl.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUAQ3ryTkR7PdagQ735AQE9wwP+N5Nfmbf8LYHJNZq5XvZOUHAcSixncL1l
iBdI9tLArdB5p+18FS3AmF6zG+w6RBUDhOlyMa4qvm+kOQkjvvKAkRbO2ixr3qAv
Z1MEvHNQllwdkXhh4R/t+710s044TusWTR5zqxquKIcDRni2Ktaa1H3bfnljoLED
aIufFu19JtU=
=YlPl
-----END PGP SIGNATURE-----