Regarding pop3 vernablities

[chandu]

I am using zcs 4.5.10 in production for two customer on RHEL5 64 bit

Our security team has findout the below vernablity, please suggest whether
these vernablilities exist in zimbra pop3 also and if not plase give any reason




Regards,
chandu

[chandu]

pop3 vernablilities

1) All mails on POP3 would be visible as it flows over the Internet as there is no encryption.

2) The passwords will be visible over the Internet.

3) When mails are accessed a copy is left behind on the machines from which it was accessed. In case of an environment of shared resources, these mails left behind can be accessed by any user.

4) The POP daemon does not log failed login attempts, nor does it disconnect after a number of invalid attempts. This leaves open the possibility of cracking passwords by sending repeated user XXXXXX pass XXXXX commands to the POP3 daemon. The amount of network overhead here is negligible for the attacking host and the receiving host and there are several hack tools out to do this already.

5) The POP3 client is vulnerable to a format string attack in the UIDL command server response string (the unique-id of a message). The unique-id of a message is an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E, which uniquely identifies a message within a mail-drop and which persists across sessions as described in RFC 1939. By the insertion of format strings as part of a UIDL response message, the POP3 client can be forced to execute arbitrary commands

6) The POP3 client is vulnerable to a 16-bit sign overflow in the "Subject" field of e-mail headers. The length of the "Subject" field is stored in a 16-bit (short) signed integer, allowing an attacker to send a malicious e-mail along with a long "Subject" field of around 33k octets overflowing the sign of the variable and causing a negative value. This attack results in the client throwing a self-unhandled exception, crashing the client

7) The POP3 client is vulnerable to a 16-bit sign overflow in the "Date" field of e-mail headers. The length of the "Date" field is stored in a 16-bit (short) signed integer, allowing an attacker to send a malicious e-mail along with a long "Date" field of around 32k octets overflowing the sign of the variable and causing a negative value. This attack results in the client throwing a handled exception, instantly closing the client by sending a malformed e-mail header to a vulnerable client.

8) The POP3 protocol does not provide a way to choose nodal relationships, i.e. permission to send or receive to or from a node. This allows anyone to consume network resources without providing a means of guaranteeing a denial of connectivity. Subsequently, spam is ultimately impossible to stop because filters cannot distinguish precisely whether the message being filtered is truly unwanted. Filters become a problem for organizations when wanted mail does not get through, while unwanted mail still inundates inboxes.

[tgx]

Originally Posted by chandu

pop3 vernablilities

1) All mails on POP3 would be visible as it flows over the Internet as there is no encryption.

Upgrade to newer version POP3 has support for SSL encryption.

3) When mails are accessed a copy is left behind on the machines from which it was accessed. In case of an environment of shared resources, these mails left behind can be accessed by any user.

Implement IMAP instead of POP.

4) The POP daemon does not log failed login attempts, nor does it disconnect after a number of invalid attempts. This leaves open the possibility of cracking passwords by sending repeated user XXXXXX pass XXXXX commands to the POP3 daemon. The amount of network overhead here is negligible for the attacking host and the receiving host and there are several hack tools out to do this already.

No idea on this one. Check your COS default settings under the Advanced Tab there is a section for Failed Login Policy.

5) The POP3 client is vulnerable to a format string attack in the UIDL command server response string (the unique-id of a message). The unique-id of a message is an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E, which uniquely identifies a message within a mail-drop and which persists across sessions as described in RFC 1939. By the insertion of format strings as part of a UIDL response message, the POP3 client can be forced to execute arbitrary commands

6) The POP3 client is vulnerable to a 16-bit sign overflow in the "Subject" field of e-mail headers. The length of the "Subject" field is stored in a 16-bit (short) signed integer, allowing an attacker to send a malicious e-mail along with a long "Subject" field of around 33k octets overflowing the sign of the variable and causing a negative value. This attack results in the client throwing a self-unhandled exception, crashing the client

7) The POP3 client is vulnerable to a 16-bit sign overflow in the "Date" field of e-mail headers. The length of the "Date" field is stored in a 16-bit (short) signed integer, allowing an attacker to send a malicious e-mail along with a long "Date" field of around 32k octets overflowing the sign of the variable and causing a negative value. This attack results in the client throwing a handled exception, instantly closing the client by sending a malformed e-mail header to a vulnerable client.

8) The POP3 protocol does not provide a way to choose nodal relationships, i.e. permission to send or receive to or from a node. This allows anyone to consume network resources without providing a means of guaranteeing a denial of connectivity. Subsequently, spam is ultimately impossible to stop because filters cannot distinguish precisely whether the message being filtered is truly unwanted. Filters become a problem for organizations when wanted mail does not get through, while unwanted mail still inundates inboxes.

If you follow my response to solving problem number three, these remaining issues are irrelevant, although worth noting. Personally I'd disable POP3. Kind of antiquated tech, but these issues should be addressed if ZImbra doesn't want a bad rep as an insecure system. My 2 cents.

[administrator]

Please note that this thread contains unverified security concers.

Per our security policy, this thread will be moderated pending a response.

Further posts on this topic will also be moderated.

You will receive this email, but will not be able to see the thread. Please review Zimbra's security policies.

Reporting Security Issues - Zimbra :: Wiki

[mmorse]

#1 & 2
zimbraPop3SSLServerEnabled TRUE & zimbraPop3CleartextLoginEnabled FALSE
Those can be set on global or server level via CLI or admin console (server overrides global).

su - zimbra
zmprov ms `zmhostname` zimbraPop3SSLServerEnabled TRUE
zmprov ms `zmhostname` zimbraPop3CleartextLoginEnabled FALSE
zmmailboxdctl restart

Then configure your thick-client accordingly.
If you want only SSL externally, just block POP port 110 access at your firewall.
Or you can take it a step further and do:
zmprov ms `zmhostname` zimbraPop3ServerEnabled FALSE

#3
This is not Zimbra's problem, these are your local security policies. You could do IMAP though most clients automatically download/keep at least the message headers in a cache (sometimes configurable), but retrieving/storing the full message body for every message offline is optional on pretty much every IMAP client. Again this is a thick-client issue.

#4
Upgrade to 5.0.9+ and you'll get warnings in audit.log Bug 29680 - POP3 Server Does Not Log IP Addresses of Failed Logins

I just checked on 5.0.10, while it doesn't disconnect the client after x tries, (we could implement that) but it only slows them down a little as they can just reconnect - an RFE to block IP's after x tries would be better.

For now the best option is auth lockout as POP access still respects these COS/user values:
zimbraPasswordLockoutEnabled
zimbraPasswordLockoutDuration
zimbraPasswordLockoutMaxFailures
zimbraPasswordLockoutFailureLifetime

Easily set in admin console gui > COS > advanced tab or:
zmprov mc COSname zimbraAttribute value

#5
ZCS's current UIDL generation will never trigger this. You should plan an upgrade into the 5.0.x series sometime though as we didn't pull up old 4.5.x code to check.

# 6 & 7
We're currently discussing if it should be the server's job to mangle messages to play defense for clients that can get burned by this. (If we create an RFE I'll post the # - or you can go ahead and create one.) What thick-clients are you testing, might be good to discuss in their forums/bug trackers as well.

#8
Just sounds like you're describing the limitation of POP in general.
IP blocking RFE?

If you want to mark something as spam just fowrard the mail as an attachment to spam.#@domain.com or ham.#@domain.com (you can rename these along with zimbraSpamIsSpamAccount/zimbraSpamIsNotSpamAccount values.

If you want to view the junk folder via POP you can tweak the login username: userid{folder:Inbox folder:Junk}

openssl s_client -host IP -port 995
+OK server Zimbra POP3 server ready
USER user@domain.com{"in folder:Inbox"}
+OK hello user, please enter your password
PASS password
+OK server ready

Or something like user@domain.com{"tag:name"}

Also note:

Originally Posted by mmorse

In ZCS 5.0.1 and earlier, user filters were run before the spam filter check was run. This meant that if the user filtered mail into a folder, spam would not be identified and sent to the Junk folder.
Beginning with 5.0.2, spam check is completed first and messages identified as spam are moved to the Junk folder. With this change, users cannot write a filter to move false positive spam out of the Junk folder.

Two options:

A) If you prefer ZCS 5.0.2+ to use the spam filter function as it works for 5.0.1 and earlier, you can set the zimbraSpamApplyUserFilters option to True.

This can be done by COS:
zmprov mc COSname zimbraSpamApplyUserFilters TRUE
or for individual accounts:
zmprov ma user@domain.com zimbraSpamApplyUserFilters TRUE

B) You can create a spam white list for individual accounts that allows an account to identify email addresses that should not be marked as spam: zmprov ma user@domain.com +amavisWhiteListSender someone@example.com
RFE to bring this into the end-user UI: Bug 6953 - Per user white & black lists in the UI

[mmorse]

Un-moderated, please see my above post discussing options for securing your server & RFE's that could be filed.

[tgx]

I just checked on 5.0.10, while it doesn't disconnect the client after x tries, (we could implement that) but it only slows them down a little as they can just reconnect - an RFE to block IP's after x tries would be better.

Traditionally a user would be disconnected after three attempts and a timer set on that account to disallow further attempts for a user specified time period. Even better there would also be options to lock an account after X failed attempts. This code is already present in the COS, just needs to be applied to POP access.

[mmorse]

Originally Posted by tgx

Even better there would also be options to lock an account after X failed attempts. This code is already present in the COS, just needs to be applied to POP access.

? 5.0.10_GA_2609/2638 > POP > connect with valid password > try X times per your zimbraPasswordLockoutMaxFailures within the zimbraPasswordLockoutFailureLifetime using a bad pass > then try the valid pass & you shouldn't be able to login to POP/IMAP/ZWC > account is marked as 'lockout' until the zimbraPasswordLockoutDuration expires.

As for disconnecting the client communication/ending the thread, that's thought of as a 'slow down the attacker' technique, has merit - but affords little protection (not that hard to send a reconnect command). Feel free to file that as an RFE, we could certainly do it & just base the values off of the zimbraPasswordLockout attributes rather than creating zimbraLoginRetryDisconnect entries.

Another RFE to block attempts from an IP after X tries would add more protection. (It would also serve to keep the end user from being locked out repeatedly from password spammers - those who never get in, but still create annoyance by hitting the lockout values and disrupting the end-user's workflow.)

[tgx]

As for disconnecting the client communication/ending the thread, that's thought of as a 'slow down the attacker' technique, has merit - but affords little protection (not that hard to send a reconnect command). Feel free to file that as an RFE, we could certainly do it & just base the values off of the zimbraPasswordLockout attributes rather than creating zimbraLoginRetryDisconnect entries.


Another RFE to block attempts from an IP after X tries would add more protection. (It would also serve to keep the end user from being locked out repeatedly from password spammers - those who never get in, but still create annoyance by hitting the lockout values and disrupting the end-user's workflow.)

Enhancements 32395 and 32396, realistically I put it in for Version 6.
I only have 1 pop user, but it only takes 1 compromised POP account to make your day bad.