RE: ESTMP Exploits & Security

["JTH" <jth () visi com>]

> -----Original Message-----
> From: Jeff McLaughlin [mailto:JMclaughlin () springsgov com]
> Sent: Wednesday, March 10, 2004 9:50 AM
> To: security-basics () securityfocus com
> Subject: RE: ESTMP Exploits & Security
>
> I'm looking for info on exploits and security of ESMTP when you telnet
> into
> port 25.  I understand how to telnet in and send email via the command
> line
> but trying to understand the security implications of being able to do
> this.
> I am currently looking at this on Exchange 5.5.
>
> Does ESMTP from the command line need to be "accessible" for the apps to
> work or enabled to troubleshoot?
>
> Are their DDOS attacks or hacks against ESMTP?
>
> Is there a best practice to secure ESMTP
>
> I've been able find info about ESMTP (commands) but not much info on the
> potential security risks.
>
> Also, exploits with telnetting to 110 i.e., POP3 ??

Warning, this rambles, and I haven't had much coffee. ;)

I'd like some information on this as well. From what I understand, 25 must
be open and accept incoming mail without any sort of authentication. The
risk of being an open relay is mitigated by only accepting mail for the
local domain. However, no checking is ever done (that I have seen) to
determine if the sender of a message is _also_ from the local domain.

This is nice from a penetration testing aspect, because I can get an email
from my client, write an email that looks like he or she wrote it, send it
through the _client's_ SMTP server, and if I asked employees to do
something, more often than not, they will. For example, I've sent a
security "survey" out that requested the user go to a website and login to
fill out the survey. From what I've seen, users will use their network
credentials in this situation. This (from what I've read) is how the
Beagle viruses (and probably others) have propagated.

This has been the biggest hole I have identified, but it doesn't seem to
be considered a hole. And I haven't seen any way to prevent this from
happening, either. 

I've heard mention of a postfix SMTP gateway, but that's not a very good
solution for many of my clients. 

An alternative has been to try to find a configuration change to make. Is
there a way to filter incoming email based on the FROM: header? If so, I
could deny incoming mail with an internal FROM: address. Another solution
I've heard of is third-party software that behaves similarly.

I've also seen mention of enabling/requiring SMTP AUTH, effectively
breaking the mail server, as most servers do not use this.

Another solution is to utilize public-key cryptography, but for many of my
clients this is an administrative and educational nightmare. In this vein,
perhaps an integrated public-key crypto email server solution is better,
where the keys, signing & verification are performed on the server. This
may keep internal mail internal.

So what do you all think. Have you seen solutions, are you even aware of
this [apparent] design flaw in SMTP?


---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off 
any course! All of our class sizes are guaranteed to be 10 students or less 
to facilitate one-on-one interaction with one of our expert instructors. 
Attend a course taught by an expert instructor with years of in-the-field 
pen testing experience in our state of the art hacking lab. Master the skills 
of an Ethical Hacker to better assess the security of your organization. 
Visit us at: 
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------