Hello Scott and others.. Plesk security issue follows.

[Galactic Zero]

Hello Scott and company. I just read this thread over at the planet and tested it out on my PSA box and the exploit is there.

Basically you telnet to your mail server's smtp port ie. smtp.yourdomain.com 25 and you can send email without requiring authentication. So, how do I and others lock this up? Replace smtp with whatever your smtp is configured for.. webmail, mail, etc..

[breun]

I don't see any exploit here. SMTP will accept mail for locally configured domains, but it will not relay mail without authentication. Where is the problem?

[mary]

Our domains have been hit by this exact exploit. The problem is that it gives spammers a free pass to bombard any user who has a known email address. Spamassassin blithely accepts messages from a local domain user without filtering.

[Galactic Zero]

You don't have to login to send mail in this fashion. You just open a telnet session to mail. smtp. webmail. yourdomain.tld port 25 and you can script it to send mail out without having to login.

I have telnet disabled on the server by default so I'm wondering how to shut down telnet to this port without breaking anything else. Or is there a better way to fix this qmail security hole as it is implemented in PSA 8.x qmail.


Franklyn

[breun]

You cannot prohibit telnet clients from connecting to your SMTP server, as the server cannot distinguish between a mail client or a telnet client (or any other program sending SMTP commands for that matter) connecting to it. And yes, you can also setup a mail client to do the exact same thing, so there's nothing special about telnet here.

Yes, it's annoying that SpamAssassin can be tricked this way, but I wouldn't go and call it a security hole. It's not like someone can get access to your system because of this.

[scott]

Qmail-scanner users, in order to force spamassassin to scan from localhost you'll need to update your /etc/xinetd.d/smtp_psa and /etc/xinetd.d/smtps_psa with the QS_SPAMASSASSIN variable. Example follows:

service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = UNLIMITED
env = QS_SPAMASSASSIN="on"
server = /var/qmail/bin/tcp-env
server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}

[mary]

Scott,

Thank you very much for the QS_SPAMASSASSIN tip. That was exactly what was needed.

Galactic: If you are having only a limited number of domain email addresses being used to launch spams, you can force spamassassin to scan emails from these accounts individually, while leaving the remaining emails from your domain unscanned. The syntax in /etc/mail/spamassassin/local.cf is as follows:

# Whitelist all emails sent from our domian by default
whitelist_from *@domain.com

# Turn off whitelisting from account being used to send spam
unwhitelist_from address@domain.com

Run qmail-scanner-reconfigure after editing local.cf to save the changes.

[breun]

I don't think a full qmail-scanner-reconfigure is needed. Just restart spamassassin to pick up the config changes.

[Galactic Zero]

Hi Mary.. Thanks, I'm not having any issues atm but am always looking to close back doors that could be used to exploit a server. Granted this one may be very limited in its use however if your unlucky you may not see where spam is coming from if you didn't know that this could happen.

Franklyn

[consultant]

Hi,

I'm probably missing something here, but this isn't any kind of exploit that I can see.... it's how SMTP works?? Like Scott said, this is no different to telneting to ports 80 to check that the webserver is working, to 110 to check that the POP server is working.

If you have to authenticate to connect to the SMTP server, how would remote servers forward email? How does can Qmail possibly know the difference between an SMTP server and a telnet session??

Unfortunately Qmail, being a cobbled together piecemeal solution of dozens of patches, that (due to DJB being a bit daft) has been patched to death for the last 10+ years doesn't have some of the niceties that things like Postfix have.

On my previous mail server, I refused to use Plesk Qmail and used my own Postfix setup, it meant that users had a different GUI to do their mail stuff, so it wasn't as neat. But it supports nice stuff which helps to prevent non-SMTP hosts connecting, like:

reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_non_fqdn_hostname
reject_unauth_pipelining
reject_invalid_hostname
reject_unknown_sender_domain
reject_unknown_recipient_domain

These simple postfix rules eliminate a whole host of nonsense (especially the reject_non_fqdn_hostname because most PCs in Botnets don't resolve properly to full reverse lookups), I've been (and so have many others) been campaigning for a Postfix option (in addition to Qmail not instead of Qmail) on Plesk, so people that want to use a currently maintained MTA based on current technology and thinking, can choose to use Postfix over Qmail. In this way, anyone setting up a new mail server has the option of postfix, and anyone migrating keeps the option of Qmail.

Anyway ... in summary, it's the way SMTP works, there is no exploit here. If you fix the "security hole" you'll never receive SPAM again (or any other email for that matter)

Regarding Spamassassin the default config under Plesk (at least in 8.1.x) Qmail seems to be for SA to check everything in coming from SMTP, as you can see below, I created an email using the method outlined originally, these are the headers:

####
X-Spam-Status: No, score=5.8 required=6.0 tests=BAYES_20,MISSING_HB_SEP,
MISSING_SUBJECT,RCVD_IN_SORBS_DUL,TO_CC_NONE autolearn=no version=3.1.8
Received: (qmail 8010 invoked by uid 10014); 18 May 2007 10:42:19 +0100
Received: from 127.0.0.1 by smtp.tumtetumtedah.com (envelope-from <foo@bar.com>, uid 110) with qmail-scanner-2.01st
(clamdscan: 0.90.1/3267. spamassassin: 3.1.8. perlscan: 2.01st.
Clear:RC:1(127.0.0.1):.
Processed in 0.024611 secs); 18 May 2007 09:42:19 -0000
####

Just my 2 Cents...

Cheers

T.