Unable to disable PLAIN login

[georgedi]

Hello,
Our security scan revealed that we allow cleartext on our Zimbra (8.8.7.GA.1964.UBUNTU16_64 FOSS) on port 465. Sure enough, checking the logs I see:

Jul 1 13:23:02 mymailserver postfix/smtps/smtpd[21999]: DFD0D1F4278: client=pool72964.fredfc.fios.verizon.net[xx.xx.xx.xxx], sasl_method=PLAIN, sasl_username=george

Looking at my configuration, my settings look right:
zimbraMtaSaslAuthEnable: yes
zimbraImapCleartextLoginEnabled: FALSE
zimbraPop3CleartextLoginEnabled: FALSE
zimbraMtaTlsAuthOnly: TRUE
zimbraMtaSmtpSaslSecurityOptions: noplaintext,noanonymous

but reading the Wiki (https://wiki.zimbra.com/wiki/Outgoing_S ... entication), it says that I should change
zimbraMtaSmtpSaslSecurityOptions: noplaintext,noanonymous TO zimbraMtaSmtpSaslSecurityOptions: noanonymous

using zmprov ms <server name> zimbraMtaSmtpSaslSecurityOptions noanonymous

But doing so, has no effect, zimbraMtaSmtpSaslSecurityOption even after a restart, remained:
zimbraMtaSmtpSaslSecurityOptions: noplaintext,noanonymous

I am pressed to ensure that I disable PLAIN login from port 465 on the server.

Any assistance will be greatly appreciated.

Thank you,
George

[zimico]

Hello,
Normally, I do not use port 465, we use port 587 (smtp submission) and pop3s, imaps and configure firewall to only allow those ports for client access.
Best regards,
Minh.

[georgedi]

Hello,
Normally, I do not use port 465, we use port 587 (smtp submission) and pop3s, imaps and configure firewall to only allow those ports for client access.
Best regards,
Minh.

Thank you Minh, but why does changing the port make a difference, couldn't I firewall 465 and achieve the same result? Wouldn't 587 also suffer from the same problem of the cleartext Zimbra configuration?

If having the port changed to 587 will do the trick, is there a zmprov command to make the port change or is it a postfix file change?

Thank you for your help!
George

[L. Mark Stone]

George,

Two things:

First 8.8.7 is long past end of life and has a known security exposure to a bitcoin mining exploit. You should upgrade to 8.8.12 (or 8.8.15, due out soon) with urgency, at your earliest opportunity. More about that here: viewtopic.php?t=65932

Second, the variable that controls smtp-auth security is zimbraMtaTlsAuthOnly. I suspect it is set to TRUE. If so, then no plain text smtp auth is possible over an unencrypted connection. My experience has been that for many softwares, the exchange of data is done in plain text, but the tunnel/channel etc. over which such data exchange is done is encrypted, and the channel/tunnel must be set up successfully first before the software will allow any data exchange at all.

You may want to review the Zimbra Security Best Practices wiki -- after you get your Zimbra upgraded to a secure version: https://wiki.zimbra.com/wiki/SecureConfiguration

Hope that helps,
Mark

[georgedi]

George,
Two things:
First 8.8.7 is long past end of life and has a known security exposure to a bitcoin mining exploit. You should upgrade to 8.8.12 (or 8.8.15, due out soon) with urgency, at your earliest opportunity. More about that here: viewtopic.php?t=65932
Second, the variable that controls smtp-auth security is zimbraMtaTlsAuthOnly. I suspect it is set to TRUE. If so, then no plain text smtp auth is possible over an unencrypted connection. My experience has been that for many softwares, the exchange of data is done in plain text, but the tunnel/channel etc. over which such data exchange is done is encrypted, and the channel/tunnel must be set up successfully first before the software will allow any data exchange at all.
You may want to review the Zimbra Security Best Practices wiki -- after you get your Zimbra upgraded to a secure version: https://wiki.zimbra.com/wiki/SecureConfiguration
Hope that helps,
Mark

Thank you Mark, it helps.
I plan on upgrading to 8.8.12 (better yet wait for 8.8.15) but I am not in a terrible hurry because as far as I understand the vulnerability can only be exploited via the web interface and I don't allow any HTTP/HTTPS access (blocked both on host and network firewall). I wish there was a way to completely shutdown the Web service on Zimbra rather than having to keep it running and resorting to firewall blocking.

Yes, my zimbraMtaTlsAuthOnly was set to TRUE but scanners still saw that someone can use cleartext credentials. I found via my Admin GUI (Configure>Server>) that both IMAP and POP had the "Enable clear text login" enabled. So I disabled those. I also blocked port 465 and now all SMTP traffic is going through 587 with STARTTLS. Unfortunately, I have no way to test if this now does the trick. All openssl s_client commands seem to focus on encrypted authentication and I am interested on encrypting the channel before the authentication step....

Followed the SMTP section of the Zimbra Security Best Practices wiki, and when I tried to set my zimbraMtaTlsSecurityLevel from may to encrypted, I got an error that it is not a valid option despite being a valid level (http://www.postfix.org/postconf.5.html# ... rity_level). Looking at the Zimbra admin guide zimbraMtaTlsSecurityLevel doesn't even exist.

So I remain a bit at a loss and waiting to see if the combination of the above (removing the cleartext logins from the GUI, changing port) forces encrypted data transmission.

[maxmouse37]

Hi George,

I'm hitting the same issue on 8.8.12 and have tried the same things you mentioned above to no avail. Did you ever find a solution that worked? This is the exact message that OpenVAS is giving me:

"The remote host is running a POP3 daemon that allows cleartext logins over
unencrypted connections.

"The remote POP3 server accepts logins via the following cleartext authentication mechanisms over unencrypted connections:

SASL PLAIN

The remote POP3 server supports the 'STLS' command but isn't enforcing the use of it for the cleartext authentication mechanisms.

[georgedi]

Hi George,

I'm hitting the same issue on 8.8.12 and have tried the same things you mentioned above to no avail. Did you ever find a solution that worked? This is the exact message that OpenVAS is giving me:

"The remote host is running a POP3 daemon that allows cleartext logins over
unencrypted connections.

"The remote POP3 server accepts logins via the following cleartext authentication mechanisms over unencrypted connections:

SASL PLAIN

The remote POP3 server supports the 'STLS' command but isn't enforcing the use of it for the cleartext authentication mechanisms.

Hello,
Unfortunately, I never did and I had to resort to a heavy-handed server port block of the service. So it is still running but not practically accessible. But if you are using this port/service (POP3) I don't know how to deal with this... I wish that we had an easier or better-documented way to deal with these protocol issues.

[barrydegraaff]

It is recommended you disable the use of POP3 via a host firewall, in case you want to use POP3 anyway, disable the unencrypted sending of username and password and force the use of encryption with the following command:

Code: Select all

zmprov ms `zmhostname` zimbraPop3CleartextLoginEnabled FALSE

Verify that TLS is required for POP3 via Zimbra Proxy, the setting should be `only` which is default.

Code: Select all

zmprov gs `zmhostname` zimbraReverseProxyPop3StartTlsMode
zimbraReverseProxyPop3StartTlsMode: only

With the above setting the Zimbra POP3 implementation requires the client to issue the STLS command. This command will switch from cleartext to encrypted communications.

If the STLS command is not issued, any command the client sends such as AUTH or USER to Zimbra will result in an error and the client will not try authentication. This means the password is not send without encryption. In addition email contents and attachments are also transmitted using encrypted communication.

False positives in OpenVAS and warnings in email clients such as Thunderbird

Email clients and vulnerability scanner can send some commands in plain text to Zimbra, such as CAPA (to list capabilities) and Zimbra will respond to these without encryption. This will make vulnerability scanners such as OpenVAS believe POP3 is enabled for unencrypted connections. This is however not the case. The false positive will look like this:

The remote host is running a POP3 daemon that allows cleartext logins over unencrypted connections.

For the same reason you can add your Zimbra account with POP3 to Thunderbird (and other clients) and select `Connection security: none` this will trigger a warning, saying your credentials will be transmitted without encryption. In reality the communication between the client and Zimbra will halt because of errors before authentication unless TLS is used.

You can verify the above with Wireshark.