Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Download and install IISCrypto from HERE
Run it and view what it says and then act on the recommendations.
Much better than trying to follow MS recomended settings!
Run it and view what it says and then act on the recommendations.
Much better than trying to follow MS recomended settings!
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..
I tried IISCrypto and it broke my exchange. SSLv3 and TLS 1.0 are needed for exhange. I will dispute the case
Premium Content
You need an Expert Office subscription to comment.Start Free Trial