How to fix CVE-1999-0512 vulnerability on CentOS Postfix?

13 posts / 0 new
Last post
#1 Mon, 10/21/2013 - 15:56
yngens

How to fix CVE-1999-0512 vulnerability on CentOS Postfix?

Hi All,

Trustwave detected this http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0512 vulnerability on one of our servers and recommends:

Configure the SMTP server to prevent open relaying of messages. It is often preferable to enforce authentication as well.

I found this little bit controversial solution http://serverfault.com/questions/422468/postfix-open-relay-how-to-config... and wonder what would be the best recommended by Virtualmin solution?

Thanks!

Mon, 10/21/2013 - 17:20
andreychek

Howdy,

Hmm, Postfix shouldn't be able to act as a mail relay by default... can you paste in the output of the command "postconf -n"?

-Eric

Fri, 11/01/2013 - 18:41 (Reply to #2)
yngens

We haven't changed anything on this server lately and it would pass the test before just fine, but the last time Trustwave found this vulnerability. The "postconf -n" command gives:

postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = ns1.mywebsite.com, ns1, localhost
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
Mon, 10/21/2013 - 19:25
yngens

By the way, Virtualmin on this system still shows version 4.01, 'yum update" gives:

root@my:/etc/yum.repos.d#
yum clean all
Loaded plugins: fastestmirror, presto
Cleaning repos: base virtualmin
Cleaning up Everything
Cleaning up list of fastest mirrors
0 delta-package files removed, by presto
root@my:/etc/yum.repos.d#
yum update
Loaded plugins: fastestmirror, presto
Determining fastest mirrors
* base: linux.mirrors.es.net
base                                                                            | 3.7 kB     00:00    
base/primary_db                                                                 | 3.4 MB     00:00    
virtualmin                                                                      | 1.2 kB     00:00    
virtualmin/primary                                                              |  29 kB     00:00    
virtualmin                                                                                       95/95
Setting up Update Process
No Packages marked for Update
root@my:/etc/yum.repos.d#
yum update
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
* base: linux.mirrors.es.net
Setting up Update Process
No Packages marked for Update

Strange enough - why I can't upgrade Virtualmin to 4.03 here?

Tue, 10/22/2013 - 18:57 (Reply to #4)
yngens

[virtualmin-universal] was disabled, re-enabling it allowed to upgrade to 4.03. However, subject matter is still there.

Tue, 10/22/2013 - 22:15
andreychek

Howdy,

Well, the vulnerability they're mentioning suggests that your server is an open relay... and at first glance, your config doesn't appear to allow that.

The config has to be changed significantly from the default in order to turn a server into an open relay.

Out of curiosity, if you input your system's hostname or IP address into the form here, does it detect any problems:

http://mxtoolbox.com/diagnostic.aspx

Wed, 10/23/2013 - 18:10 (Reply to #6)
yngens

The only warning was that id does not support TLS:

SMTP TLS Warning - Does not support TLS. More Info
SMTP Reverse Banner Check OK - aa.bb.cc.ddd resolves to aa.bb.cc.ddd.in-addr.arpa, my.website.com
SMTP Reverse DNS Mismatch OK - Reverse DNS matches SMTP Banner
SMTP Connection Time 0.889 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 3.058 seconds - Good on Transaction Time
Session Transcript:
Connecting to aa.bb.cc.ddd

220 my.website.com ESMTP Postfix [827 ms]
EHLO please-read-policy.mxtoolbox.com
250-my.website.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN [671 ms]
MAIL FROM: <supertool@mxtoolbox.com>
250 2.1.0 Ok [718 ms]
RCPT TO: <test@example.com>
554 5.7.1 <test@example.com>: Relay access denied [671 ms]

MXTB-PWS3v2 3916ms

However, since couple days I've been changing lot's of configurations, so probably the issue is not there already, so I need to have Trustwave's robot to scan the server once again. Thanks and I'll report again if the issue persists after the second scan.

Wed, 10/30/2013 - 17:40
yngens

Today Truswave replied back denying our request to make an exclusion to this policy. Their findings are below:

We have denied this dispute based upon manual investigation of this finding.

Manual Investigation:
telnet xx.xx.xx.xx 25
Trying xx.xx.xx.xx...
Connected to my.website.tld (xx.xx.xx.xx).
Escape character is '^]'.
h220 my.website.tld ESMTP Postfix                                                                             helho scan_css_util
502 5.5.2 Error: command not recognized
helo secure.server.com
250 my.website.tld
MAIL FROM:(>
250 2.1.0 Ok
rcpt to: root@[xx.xx.xx.xx]
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
From: "Bob" <bob@example.org>
To: "Alice" <alice@example.com>
Date: Today

Hello Alice.

This is a test message.

Bob
.
250 2.0.0 Ok: queued as 62B381A39F
quit
221 2.0.0 Bye
Connection closed by foreign host.

Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage, processing, and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).

Please review the scan report and follow the suggestions found underneath the “Remediation” column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report.

If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.

Could anyone please help me to sort this out? Thanks!

Wed, 10/30/2013 - 23:35
andreychek

Howdy,

Hmm, I'm confused as to why they're raising an issue -- what's described in the test they performed doesn't appear to be any sort of security issue.

It's simply sending an email to the root user on that server, with a fictional "from" and "to" address.

The issue "CVE-1999-0512" describes a security issue where a server is an open relay, meaning it accepts email from spammers, and sends them to any server on the Internet.

I'm not seeing anything that suggests that your server is an open relay -- and the test they performed isn't checking to see if your server is an open relay, it's just delivering an email locally.

Also, since the mxmailbox site didn't discover anything either -- I suspect what they're seeing is some sort of false positive.

-Eric

Fri, 11/01/2013 - 01:17 (Reply to #9)
yngens

Let me conduct this to Trustwave. I hope this time will change their stance. Thank you very much Eric!

Fri, 11/01/2013 - 18:44 (Reply to #10)
yngens

Unfortunately, Trustwave denied again saying:

We have denied this dispute based on the information provided. By confirming that "root@[LOCALIP]" and/or "postmaster@[LOCALIP]" are valid addresses is saying that any Spammers delivering email by using MAIL FROM:(> (hiding source address) have the ability to eat up bandwidth with an overabundance of unsolicited messages. As such, we have denied this dispute.

Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage, processing, and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).

Please review the scan report and follow the suggestions found underneath the "Remediation Action" column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report. If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.

Also, please be advised that we cannot grant current disputes using information contained in previous or other disputes (or information contained within emails or phone calls as well); all applicable information must be included in the most current dispute so please include all pertinent information within your disputes.

I am now lost how should I address this issue...

By the way, cite doesn't work in comments. I generally find markup on virtualmin.com's forums terrible. Why don't you install some kind of WYSWIG here?

Fri, 11/01/2013 - 22:19
andreychek

Unfortunately, I don't feel what they're saying makes sense, or has anything to do with the security issue they're mentioning.

They're suggesting that simply knowing a local email address is a security issue because someone can send lots of email to it.

That doesn't make sense to me :-)

The security issue they're claiming (CVE-1999-0512) is related to being an open relay -- but that has nothing to do with what they're describing. They have not shown that you are an open relay.

There are a number of email addresses that every domain is supposed to have -- such as "hostmaster@domain.tld".

Since every domain should have these email addresses -- of course someone could send email to it... that's not a security issue, that's where bad emails should be stopped with anti-spam software and RBL's.

Off the top of my head, I'm not sure how one might prevent what they're describing without causing problems with legitimate emails to the root user. Are they providing an example of how they would configure Postfix to prevent the issue they have?

-Eric

Sat, 11/02/2013 - 16:10
Locutus

I also have no idea why it should be a security issue to allow the address root@[ip-address]. My system accepts that address too. Just as root@host.domain.tld. Don't those addresses exist on about every Linux system?

Topic locked