asked on
Failed PCI Scan - Exchange 2010 OWA
Hi,
I ran a Trsutwave PCI scan on my environment after I had just implemented a new Exchange Certificate SHA-2. I have 2 CAS and 2 DAG Exchange 2010 Std servers. I noticed my 2 DAG and 1 CAS Exchange Servers have IE 9 and 1 of my CAS servers have IE 8. not sure if this is why the scan failed? Also, will upgrading my IE to 11 on all four Exchange servers affect anything?
Below are the details of the failed scan.
#1 Vulnerability SSLv3 Supported
Note to scan customer:
SSL v3.0 violates PCI DSS and is considered an automatic failing
condition.
Port: tcp/443
This service supports the use of the SSLv3 protocol. The SSLv3 protocol
has known cryptographic weaknesses that can lead to the compromise
of sensitive data within an encrypted session. Additionally, the PCI SSC
and NIST have determined that the SSLv3 protocol no longer meets the
definition of strong cryptography.
CVE: CVE-2014-3566
NVD: CVE-2014-3566
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#2 Vulnerability TLSv1.0 Supported
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database. TLS v1.0 violates PCI DSS and is considered an automatic
failing condition.
Port: tcp/443
This service supports the use of the TLSv1.0 protocol. The TLSv1.0
protocol has known cryptographic weaknesses that can lead to the
compromise of sensitive data within an encrypted session. Additionally,
the PCI SSC and NIST have determined that the TLSv1.0 protocol no
longer meets the definition of strong cryptography
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#3 Vulnerability SSL/TLS Weak Encryption
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database
Algorithms
Port: tcp/443
The SSL-based service running on this host appears to support the use
of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no
authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
Please note that this vulnerability CANNOT be disputed using a Risk
Mitigation and Migration plan. This is a separate finding and must be treated as such.
CVE: CVE-2013-2566, CVE-2015-2808
NVD: CVE-2013-2566, CVE-2015-2808
CVSSv2: AV:N/AC:M/Au:N/C:P/I:N/A:N
Service: microsoft:iis
Any suggestions on how to remedy this?
Thanks!
I ran a Trsutwave PCI scan on my environment after I had just implemented a new Exchange Certificate SHA-2. I have 2 CAS and 2 DAG Exchange 2010 Std servers. I noticed my 2 DAG and 1 CAS Exchange Servers have IE 9 and 1 of my CAS servers have IE 8. not sure if this is why the scan failed? Also, will upgrading my IE to 11 on all four Exchange servers affect anything?
Below are the details of the failed scan.
#1 Vulnerability SSLv3 Supported
Note to scan customer:
SSL v3.0 violates PCI DSS and is considered an automatic failing
condition.
Port: tcp/443
This service supports the use of the SSLv3 protocol. The SSLv3 protocol
has known cryptographic weaknesses that can lead to the compromise
of sensitive data within an encrypted session. Additionally, the PCI SSC
and NIST have determined that the SSLv3 protocol no longer meets the
definition of strong cryptography.
CVE: CVE-2014-3566
NVD: CVE-2014-3566
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#2 Vulnerability TLSv1.0 Supported
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database. TLS v1.0 violates PCI DSS and is considered an automatic
failing condition.
Port: tcp/443
This service supports the use of the TLSv1.0 protocol. The TLSv1.0
protocol has known cryptographic weaknesses that can lead to the
compromise of sensitive data within an encrypted session. Additionally,
the PCI SSC and NIST have determined that the TLSv1.0 protocol no
longer meets the definition of strong cryptography
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#3 Vulnerability SSL/TLS Weak Encryption
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database
Algorithms
Port: tcp/443
The SSL-based service running on this host appears to support the use
of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no
authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
Please note that this vulnerability CANNOT be disputed using a Risk
Mitigation and Migration plan. This is a separate finding and must be treated as such.
CVE: CVE-2013-2566, CVE-2015-2808
NVD: CVE-2013-2566, CVE-2015-2808
CVSSv2: AV:N/AC:M/Au:N/C:P/I:N/A:N
Service: microsoft:iis
Any suggestions on how to remedy this?
Thanks!
ExchangeVulnerabilitiesSSL / HTTPSEncryptionSecurity
Last Comment
Albert Widjaja
Before you start making changes to the Exchange server, you need to read this article posted on the Exchange team blog.
http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx
It goes through exactly what you can and cannot disable for Exchange to work correctly.
You should install Internet Explorer 11 and then any subsequent updates for Windows and Exchange using Microsoft Update to keep the server secure. While you shouldn't browse from the server, the browser is so heavily integrated it needs to be kept up to date.
Simon.
http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx
It goes through exactly what you can and cannot disable for Exchange to work correctly.
You should install Internet Explorer 11 and then any subsequent updates for Windows and Exchange using Microsoft Update to keep the server secure. While you shouldn't browse from the server, the browser is so heavily integrated it needs to be kept up to date.
Simon.
way out is to disable sslv3 first (esp due to poodle vulnerability) but as of tls1.0, you may not want to disable that as there are many reported cases that after tls1.0 is disabled, the owa and errors may starts popping out. so kill off the sslv3 first and rescan to see remaining vulnerabilities surfaced first.
e.g. Exchange uses TLS 1.0 and doesn't support 1.1 and 1.2 http://support.microsoft.com/kb/2709167 According to the article here you can't use TLS 1.1 or TLS 1.2 with SMTP. Also if you enabled SSL 3.0 and it worked, disabled ssl 3 and enabled tls 1.0 and it worked with that. So it would work with either SSL 3.0 or TLS 1.0. SSL 3 was required by our Outlook 2011 clients, and TLS 1.0 was being used for EWS
using IISCrypto (like select the FIPS preset button) as stated is handy to use the best practice and go specific to disable the weak crypto. Note that any change you make to schannel (MS's crypto provider), needs a reboot to apply and until you reboot Exchange will be pretty broken. The tools is actually touching the schannel registries as stated in https://support.microsoft.com/en-us/kb/245030
In short, the weak encryption issue likely relates to SSL 2.0 or 3.0 being enabled, as they are for default Windows Server/IIS Installs. Exchange minimally relies on TLS 1.0, so that needs to be enabled and do disable tls1.0. Need to seek Trustwave to accepted and approved your dispute with a mitigation plan since appl breaking is not viable for running. Otherwise fronting a appl delivery controller such as F5, or haproxy in a way is virtual patching to get through trustware scan but not solving the actual problem..
e.g. Exchange uses TLS 1.0 and doesn't support 1.1 and 1.2 http://support.microsoft.com/kb/2709167 According to the article here you can't use TLS 1.1 or TLS 1.2 with SMTP. Also if you enabled SSL 3.0 and it worked, disabled ssl 3 and enabled tls 1.0 and it worked with that. So it would work with either SSL 3.0 or TLS 1.0. SSL 3 was required by our Outlook 2011 clients, and TLS 1.0 was being used for EWS
using IISCrypto (like select the FIPS preset button) as stated is handy to use the best practice and go specific to disable the weak crypto. Note that any change you make to schannel (MS's crypto provider), needs a reboot to apply and until you reboot Exchange will be pretty broken. The tools is actually touching the schannel registries as stated in https://support.microsoft.com/en-us/kb/245030
In short, the weak encryption issue likely relates to SSL 2.0 or 3.0 being enabled, as they are for default Windows Server/IIS Installs. Exchange minimally relies on TLS 1.0, so that needs to be enabled and do disable tls1.0. Need to seek Trustwave to accepted and approved your dispute with a mitigation plan since appl breaking is not viable for running. Otherwise fronting a appl delivery controller such as F5, or haproxy in a way is virtual patching to get through trustware scan but not solving the actual problem..
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy
ASKER
Would I only need to run the IISCrypto on the CAS Exchange servers? Not the DAG?
ASKER CERTIFIED SOLUTION
Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a questionASKER
I tried IISCrypto and it broke my exchange. SSLv3 and TLS 1.0 are needed for exhange. I will dispute the case
tls1.0 minimally is needed for exchange as mentioned in my past post. hope it is running fine as of now
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Hi,
Is there any outage or email flow disruptions when disabling the SSLv3 ?
As far as I know and have tried upgrading the IE on the OS doesn't affect the exchange server 2010 functionality.
Is there any outage or email flow disruptions when disabling the SSLv3 ?
As far as I know and have tried upgrading the IE on the OS doesn't affect the exchange server 2010 functionality.
Run it and view what it says and then act on the recommendations.
Much better than trying to follow MS recomended settings!