Security Breached. SMTP without password can send using qmail!

[[email protected]]

I have tried this on the Plesk control panel:

From the Server->Mail, choose "authorization is required:" for Relaying option and ensure that SMTP and POP3 are enabled.

Next I created an Email account in a new profile in Outlook Express that uses one of the domains in Plesk. For example, I created an email account, "[email protected]" where domain.com exists in the Plesk machine and the account, "[email protected]", existed in domain.

I have not entered any password in that email account in Outlook Express.

I tried to send out an email to anyone without any form of authenication with great success!

This means that we can use "[email protected]" to SPAM using the Plesk machine.

Is there anything that I did wrongly? Please help!

Thanks

Ng Cher Choon

 

[alex042]

Have you tried sending with pop3 authentication off? With pop3 authentication turned on, if you check email on any other account on that server and then try to send email, it would allow you to send email without smtp authentication for the default time of 30 minute from the time you checked mail with the other account.

 

[[email protected]]

To test the SMTP only, I did not even tried to receive any emails using POP3. To ensure that, like I have said, I did not even enter any password in the POP3 receiving in Outlook Express.

As such, I will be prompted for entering a password if I wanted to receive an email using the POP3 with the email account. I would ignore by cancelling. Then I tried to send out an email using the SMTP, it did went through with all the settings in the server explained earlier.

What went wrong?

Thanks

Ng Cher Choon

 

[imiles]

Same experience. I tested your findings, I sent messages using a completely fake user ID but using an existing mail server name. I did not use a password. Messages were accepted for email addresses of existing users on the same server.

For instance, using a user ID "faketest" and NO password and using mail.abc123.com as a mail server, I was able to send messages to [email protected]. Both abc123.com and def456.com are domains on the same server and [email protected] is a valid email address.

Messages sent were not only accepted but they were also delivered.

In all my tests, I made sure I used a totally different ADSL line to the server so that the server did not "recognize" me from previous sessions.

Conclusion: turning on "authorization required" or not did NOT make a difference. Just like you, I did not check mail before sending the message.

Other problem: if you check the raw maillog file, you discover that there are just a few lines that show that a new message was accepted but the log does not include the source IP address so that can be traced and perhaps shutdown.

Considering we were the target of a spam attack last week and that it has been impossible to locate the source of the attack, this is an important issue. Is qmail really that safe, is it a Plesk setting that is wrong, I don't know. I just wish someone would verify why Plesk does not take the 'authorization required" into account.

BTW, I'm running 7.5.2 on all my servers.

 

[steve0]

If you are sending an email to a domain that is on the server then of course it will be accepted and delivered - that is not relaying through the server to an outside domain it is just local delivery, if we required authentication for local delivery no one would recieve any email.

Try your experiment with a domain you do not host you should recieve an error from qmail complaining that the domain is not in the control locals file or something to that effect - that means authentication failed and so qmail will refuse to relay.

 

[imiles]

That's true, the domain needs to be local.

But it does not take away the fact that an administrator cannot trace the origin of a message since the maillog file does not contain any indication where it is coming from. As you know, sometimes the (spam) problems come from within; I mean, a spammer can also be a customer. Maybe the customer has a virus/worm on a PC and maybe that is generating the spam. So a few more hints in the log files would be nice.

 

[steve0]

Originally posted by imiles
That's true, the domain needs to be local.

But it does not take away the fact that an administrator cannot trace the origin of a message since the maillog file does not contain any indication where it is coming from. As you know, sometimes the (spam) problems come from within; I mean, a spammer can also be a customer. Maybe the customer has a virus/worm on a PC and maybe that is generating the spam. So a few more hints in the log files would be nice.

Agreed, although there are plenty of tools available to work with qmail it would be very nice if SWSoft could incorporate 1 or 2 of the better ones to make life easier ..

You never know they may have plans for this in a future release, only time will tell.

 

[[email protected]]

In the other word, our servers can be used for SPAMMING if the hacker just need to know what domains existed in our servers as there is no authenication needed.

Isn't that a breach of security?

Then why is there an option in Plesk to perform an authorization for SMTP. What is the effect on that? If there is no effect, why place it there?

I think this is really a serious breach and our servers are not spare from SPAMMERS.

If it is our customers who had worms, then it is a different story, at least the delivery is being authenicated by the SMTP sever first before it is being sent!

As far as I understand on the POP3 and SMTP authoization from the Plesk control panel, it means that POP3 will authorize the userID and password before the emails of the respective user can be received. For the next 20 to 30 mins, depending on the Plesk settings, SMTP server will not seek for any authenication. If the time has spanned over that period, the SMTP will then seek for a new session by asking for userid and password. But this is not so in this case.

Our servers are at RISKS!

Ng Cher Choon

 

[jamesyeeoc]

Originally posted by [email protected].s In the other word, our servers can be used for SPAMMING if the hacker just need to know what domains existed in our servers as there is no authenication needed.

They cannot be used for relaying spam out to other domains. Anyone can find out an IP address and Host/Domain name, not just spammers. Just looking around on Google or other search engines and Forums, you can get lots of domain names. Looking up an IP for the domain can be as easy as doing a PING or DIG or NSLOOKUP command from Linux or Windows, etc. There are other ways to find out what domains are hosted on a given IP. This is not a 'fault' of Plesk.

Then why is there an option in Plesk to perform an authorization for SMTP. What is the effect on that? If there is no effect, why place it there?

This allows valid mail users to send outbound emails to other domains, if they are authorized.

I think this is really a serious breach and our servers are not spare from SPAMMERS.

Preventing incoming SPAM is another matter, that's why products such as Spamassassin exist. Anyone can send emails to an email server as long as you know the domain name. Unless you want to lockdown your email server to only accept email from a pre-defined list of other domains (which would defeat the purpose of running an email server).

If it is our customers who had worms, then it is a different story, at least the delivery is being authenicated by the SMTP sever first before it is being sent!

That is a different story, since the emails would be relayed from your server. However, most of todays worms have their own SMTP engine built in.

As far as I understand on the POP3 and SMTP authoization from the Plesk control panel, it means that POP3 will authorize the userID and password before the emails of the respective user can be received. For the next 20 to 30 mins, depending on the Plesk settings, SMTP server will not seek for any authenication. If the time has spanned over that period, the SMTP will then seek for a new session by asking for userid and password. But this is not so in this case.

Normally you do not need to enable the POP authorization as long as you have the SMTP auth checkmarked. I would not have the time value set for more than a minute or two. The email client will re-auth the next time they send/receive.

Our servers are at RISKS!

Not meant to offend, but the risk is usually from improper setup/config of the server, inadequate security setup by the admin, etc. Plesk has a basic configuration, it is up to the hosting admin to go through *all* options and settings to make sure it is setup to their own needs. Not all hosts want everything setup exactly the same. I certainly don't.

These are my 2 cents, and I don't care if anyone agrees or not...

 

[[email protected]]

Basically, if anyone has performed the test I have mentioned, you will realized that the authorization for SMTP in Plesk do not work. You can happily send out an email to anyone, whether the domain is local or remote. As a result, SPAMMER can use our server SMTP to deliver their emails out as long as they know any of our domains that exist in our machine.

Moreover, finding what domains existed in your machine isn't that a big problem and can be done quite easily as what jamesyeeoc has mentioned.

Since the SMTP authorization fails to work in Plesk, why is there such an option in the control panel?

This is really a high security breach.

Ng Cher Choon

 

[jamesyeeoc]

From the Server->Mail, choose "authorization is required:" for Relaying option and ensure that SMTP and POP3 are enabled.

Yes, I did this.

Next I created an Email account in a new profile in Outlook Express that uses one of the domains in Plesk. For example, I created an email account, "[email protected]" where domain.com exists in the Plesk machine and the account, "[email protected]", existed in domain.

I did this also, exactly as you stated.

I have not entered any password in that email account in Outlook Express.

I left the password blank as well, in OE, but obviously not on the server .

I tried to send out an email to anyone without any form of authenication with great success!

I created a new email (tried sending to [email protected], [email protected], etc.) and as I would expect, since there was no password in the OE account info, when I tried to send, OE gives me the error

There was a problem logging onto your mail server. Your Password was rejected. Account: ..... Response: '-ERR USER/PASS required.' ....... Server Error: 0x800CCC90, Error Number: 0x800CCC92

This is exactly the result I would expect. I repeated the test using 2 different workstations, 2 different servers, 2 different mail names, all the same settings as you described in your original post. Unless you can give more information or double check your OE settings, I don't know what else to say....

By the way, this was one of the things I tested thoroughly with the new 7.5.3 version when it was first released, so I didn't really expect any other result.

 

[[email protected]]

This is actually what I wish to see in qmail in Plesk responding back to OE if there is no password set in SMTP nor POP3.

But in our cases, we didn't get the response as what you got. We are using FC1 and Plesk 7.53. imiles is also facing the same problem.

What has went wrong in our configuration?

Thanks

Ng Cher Choon

 

[jamesyeeoc]

There could be a number of things, but lets narrow down some of them:

Check your Outlook Express and make sure there are *no other* mail accounts defined. If there is a valid email account (other than the one you created to do the test), then OE could be using that other account to send the email out.....

Take one of your test messages which made it through and check the headers to verify that it shows your [email protected] as being the From or Reply-to address....

Turn off POP3 auth, leave only SMTP auth with a checkmark. Restart Qmail.

Check log files for errors or verification that it accepted and delivered the email messages in question:
/var/log/messages
/usr/local/psa/var/log/maillog (and others)
/home/httpd/vhosts/domain.name/statistics/logs/

In the maillog, if it accepted and then delivered the test email message(s) then there will be log entries showing both the accepting and the delivering to the external domain's SMTP server.

Check the contents of the Qmail control files located in:

/var/qmail/control/
(such as rcpthosts, locals, etc)

You can try turning off SMTP, saving it, then turn it on again and save it again. This may force it to reset the database value (if it's messed up).

There are many other things, but I'm too tired right now to go further with this. My point was that a Plesk server itself normally does not allow unauthorized relaying.

From imiles post, what he was able to do is normal email delivery to existing domains on his server. This is normal behavior for any standard SMTP server, to accept email from outside the server for the hosted domains.... This is *not* relaying.

 

[alex042]

We just disable the pop3 option altogether because it's just too easy for the server to 'appear' to be an open relay. And ever since we've turned that option off, it seems like we've always been prompted for a login id and password for smtp authentication.