PCI Compliance vulnerabilities

[EKjellquist]

Folks,

Just wanted to pass on what we're seeing as far as PCI Compliance scans relative to AMS. For reference, we port-forward all the relevant AMS ports (e.g. 25, 110, 143, 465, 587, 995, 8000, 8100) from our edge router to the local IP for our AMS server, and ports 80/443 are proxied via Apache 2.4 on a different local server (also behind NAT). We're using AMS 4.2.6, which AFAIK is still using OpenSSL 1.0.2L (as it was updated but then reverted back to 1.0.2L in later AMS patches). These are the risks that showed up in my most recent scan as of this writing:

(1) Web config file exposed (port 8000/TCP) - the scanner could get to and read web.config for webmail. I can set permissions on the webmail directory to correct it, probably, not sure what the recommendation is?
(2) Port 587 / TCP over SSL - CVE-2013-2566 / CVE-2015-2808 - TLS 1.2 with RC4 128-bit ciphers supported - RC4-MD5 and RC4-SHA - this would have to be correted with updated OpenSSL version
(3) Port 25 / TCP - EHLO responds, implies AMS uses ESMTP, which uses the AUTH command. It also responds to LOGIN as one of those AUTH parameters (even though you can set AMS to only allow logins from legit accounts and require secure connections only). AMS would need to be updated to deny or not respond to LOGIN requests and completely disable plaintext / unencrypted session requests when 'require secure connection' option is specified in AMS options...
(4) Port 25 / TCP over SSL - old cipher issue, same as (2)
(5) Port 143 / TCP over SSL - old cipher issue, same as (2)
(6) Port 465 / TCP over SSL - old cipher issue, same as (2)
(7) Port 995 / TCP over SSL - old cipher issue, same as (2)
(8) Port 587 / TCP - same as (3)
(9) Port 443 / 8000 - HTTP Security Header Not Detected - AMS' web server may need the following options added for X-Frame-Options, X-XSS-Protection, X-Content-Type-Options and HSTS directives. I added what I didn't have already in my Apache config (which will clear this for me), but for others who aren't proxying, this would need to be corrected in AMS' web server. I added the following in my Apache config to clear this line item:

Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options nosniff
Header set Content-Security-Policy "default-src 'self';"

There are other things I don't get dinged on already b/c they're mitigated in other parts of my Apache config, but afaik most of these items would get cleared by an OpenSSL update.

[EKjellquist]

As a follow-up, I installed IISCrypto (as this has helped in similar situations on other servers), which you can use to limit which protocols / ciphers / hashes / etc are allowed through Windows at all. Sadly this does not actually make the PCI scan pass even after doing so because the AMS still returns that RC4-MD5 and RC4-SHA ciphers are available (even if IISCrypto would actually disallow them).

'Best Practice' settings -MD5 and -SHA hashes

IISCrypto.jpg (127.36 KiB) Viewed 29602 times

[EKjellquist]

IISCrypto Cipher 'Best Practices'

IISCrypto_ciphers.jpg (186.69 KiB) Viewed 29587 times

Here are the Cipher settings I'm using:

[Code Crafters]

Thanks for the feedback. A few times now, we've upgraded OpenSSL only to have to revert it due to some instability. The code we have to interact with this is quite complex. There is a new branch of versions that we need to switch to but as it's not a simple thing to implement, we haven't been able to do it yet. However, we definitely want to do this in a major future update. As for the web server headers, you can use the built in web server or IIS / apache etc. We will try to look at adding any missing security headers to our built in custom-built web server too.

[EKjellquist]

Just wanted to update this post as our compliance scanner changed and was finding similar, but not the same issues. I've been using Apache as a proxy for webmail for some time, which totally clears up any port 80/443 issues as connections are pretty much forced to use whatever you set there security-wise. However, I still had port 8000/8100 open (and I didn't realize I didn't NEED them open anymore), so that clears up those related issues. I couldn't make the web.config file for webmail invisible to the WAN, nor could I add the HTTP security headers to web.config in a way that worked; I'm guessing AMS ignores whatever custom stuff is user-added to the webmail base directory config file (this would be a good update recommendation as allowing it would help with some security settings).

Issues (3)-(8) persist however; even though I can use sites like CheckTLS.com to verify that connections using certain ciphers / protocols will fail, they still get detected on a PCI scan; in a future AMS (and AFS for that matter) update, it would be nice to have a checkbox in the General section to disable plaintext authentication system-wide and also eliminate that from the ELHO response. As stated before, it's pretty much critical that we get TLS 1.3 / OpenSSL 1.1.1 support eventually; can't speak for other users but we can keep going with TLS 1.2 for awhile at a minimum as long as we had the option to select which ciphers AMS will accept (a forced order of preference would also be nice), and I can knock out all those vulnerability false positives.

All that said, I was able to at least provide the ASV with CheckTLS scan screenshots using SSLv2 - TLSv11 as well as RC4-MD5 and PLAIN login attempts that show failure in order to clear those scan results. So for anyone else out there in a similar PCI predicament using AMS, you're definitely going to need to (1) proxy AMS using a more secure / current webserver for webmail, (2) enable TLS 1.2 on all your services (3) use IISCrypto on your server to eliminate any old ciphers / protocols still allowed by OpenSSL 1.0.2.

[MC9000]

Hi. I just now read this post and was wondering how you managed to proxy AMS through IIS. I had no idea this was even possible. Can you share more on this? I didn't want to force my clients to switch to something other than AMS solely because PCI issues (it's about to get much worse in December -mandating TLS1.3). I love AMS (and don't want to lose years of honed configurations)!

I have some basic experience with IIS8.5, but nothing so advanced like you obviously have.

[EKjellquist]

I'm actually doing it through Apache rather than IIS (but it can be done in any web server technically). Most of my external services point to a public IP that goes through an edge router, and just port-forwards everything. Ports 25, 110, 143, 465, 587, 993, 995 are all forwarded directly to the mail server running AMS and Ports 80, 443 to the apache web server. I use a reverse proxy from there to AMS so I can serve up Webmail. The advantage of this is you can then utilize Apache to set whatever security level you want that might be higher than what AMS has built-in. IIS Crypto doesn't actually just work with IIS specifically, it just can help to enable / disable some security options on a machine. Since I need to eliminate some of the old ciphers that have long been weak or unusable (and currently you can't set that in AMS), I use this to show the PCI folks that they are indeed disabled (because AMS will still report they are available, even if you can't actually connect).

I can't say i've used IIS to do anything as fancy as with Apache, but this might help get you some of the way there. These anonymized Virtualhost entries make it so connections are automatically redirected to secure ones, and proxied to mail.domain.com. I use shadow DNS also, so if you're in the WAN and request the IP for mail.domain.com you'll get the public IP, but a local request will get the local IP on the LAN. This makes it a bit easier if you want to avoid having to use local machine names for things or have users that are frequently in / out of your network with laptops / mobile devices.

***
<VirtualHost *:80>
ServerName mail.domain.com
Redirect permanent / https://mail.domain.com
Protocols h2c http/1.1
</VirtualHost>

<VirtualHost *:443>
ServerName mail.domain.com
ServerAdmin domains@domain.com

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

SSLEngine On
SSLProxyEngine On
ProxyPreserveHost On
SSLCertificateFile C:/Apache24/certs/mail_domain_com/mail.domain.com.crt
SSLCertificateKeyFile C:/Apache24/certs/mail_domain_com/mail.domain.com.key
ProxyPass / https://mail.domain.com/ retry=1 acquire=3000 timeout=600 Keepalive=On
ProxyPassReverse / https://mail.domain.com/
CustomLog "c:/Apache24/logs/ssl_request.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
Protocols h2 http/1.1
</VirtualHost>

[sjoram]

I'm running an older OS at this end which has a couple of vulnerabilities I'm working to mitigate as best I can until I can upgrade and I came back to looking at these issues with the older OpenSSL after running a Nessus Essentials scan.
I've tested reverse proxy functionality from within my LAN on a VM running a newer version of IIS and seems to work as expected, which is good.
Thought I would add the steps I followed for IIS here...

(Default IIS configuration is already installed and running)
Install Application Request Routing 3.0 via Web Platform Installer
Enable WebSocket Protocol via Windows Features > IIS > WWW Services > App Dev Features <-- this was not available until ARR was installed
Add new IIS site, set bindings to specific host name (for my test testwebmail.<domain>.local), so it can run on the same ports as the default site
On the new IIS site, URL Rewrite - Add Rule using Reverse Proxy template
Rule config:
IP/server name pointing to AMS (used IP 10.x.x.x in my case)
Disable SSL offloading
Create DNS CNAME record for testwebmail.<domain>.local pointing at the FQDN of the VM running IIS
From a 3rd machine, browse to "https://testwebmail.<domain>.local" - got the AMS webmail login page, logged in as a user and webmail behaved normally.

Did have a cert error as the cert loaded into the test IIS instance is using the public facing FQDN rather than the internal URL, but that was as expected and wasn't related to the reverse proxy configuration.