PCI Compliance - Disable SSLv2 and Weak Ciphers

According to section 4.1 of the the Payment Card Industry Data Security Standard (PCI-DSS) v1.2, merchants handling credit card data are required to “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

What does this mean? In order to validate your PCI DSS compliance in this area you will need to ensure that your relevant server(s) within your PCI environment are configured to disallow Secure Sockets Layer (SSL) version 2 as well as "weak" cryptography. You are also required to have quarterly PCI security vulnerability scans conducted against your externally facing PCI systems. Without disabling SSLv2 and weak ciphers you are almost guaranteed to fail the scans. In turn this will lead to falling out of compliance along with the associated risks and consequences.

The SSLv2 Conundrum

Does your server support SSLv2?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -ssl2 -connect SERVERNAME:443

If the server does not support SSLv2 you should receive an error similar to the following:

# openssl s_client -ssl2 -connect SERVERNAME:443

CONNECTED(00000003)

458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

How to configure Apache v2 to not accept SSLv2 connections:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLProtocol -ALL +SSLv3 +TLSv1

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

How to configure Microsoft IIS to not accept SSLv2 connections:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

"Enabled"=dword:00000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

Those Pesky Weak SSL Ciphers

Does your server support weak SSL ciphers?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers you should receive an error similar to the following:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

CONNECTED(00000003)

461:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:

How to configure Apache v2 to not accept weak SSL ciphers:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted.

How to configure Microsoft IIS to not accept weak SSL ciphers:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]

"Enabled"=dword:0000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted..

At this point have your Approved Scanning Vendor (ASV) scan your external facing PCI environment to validate. Making the above changes should cause the ASV scans to not tag and fail you on the following vulnerabilities:

• SSL Server Supports Weak Encryption
• SSL Server Allows Cleartext Encryption
• SSL Server May Be Forced to Use Weak Encryption
• SSL Server Allows Anonymous Authentication

Steve

###

Forensics: Blackberry Curve 8310 and Incorrect EXIF Time Stamp

While working on a forensic investigation that involved a Blackberry 8310 I ran into an issue that just didn't settle right with me. I wanted to ensure that, beyond a reasonable doubt, the EXIF time stamp embedded within a photo taken by the Blackberry device was written accurately by the device. Before signing off on the validity of the EXIF time stamp, something just didn't seem right. After digging around and doing countless tests, I was surprised that I was able to consistently recreate a failure whereby the incorrect time stamp was written to the original date/time EXIF field. Here are additional details:

DEVICE: Blackberry Curve 8310 smartphone (EDGE)

VERSIONS: v4.5.0.55 (Platform 2.7.0.68) & v4.5.0.110 (Platform 2.7.0.90)

PROVIDER: AT&T

DATE/TIME SOURCES: Blackberry & Network

ADDITIONAL ENABLED SETTINGS WORTH NOTING:

• PASSWORD (options | security options | general settings | password)
• BACKLIGHT TIMEOUT value of 30 seconds (options | screen/keyboard | backlight timeout)
  
• SECURITY TIMEOUT value of 1 minute (options | security options | general settings | security timeout)

OBSERVED BEHAVIOR:

The EXIF original date/time embedded within a photo taken by the Blackberry 8310 had the incorrect time stamp. Consistently and repeatedly I was able to have the Blackberry device write the incorrect time stamp to the EXIF field. The EXIF original date/time was inconsistent with the actual date/time that the photo was taken in addition to the “Last Modified” time displayed by the Blackberry device.

SCENARIO REPRODUCING THE PROBLEM:

1. I take a photo with the Blackberry at 0600 on 1/22/2009. The image name is IMG00001. Using the Blackberry and looking at the properties of photo IMG00001 I see the correct “Last Modified” date and time of “Jan 22, 2009 6:00AM”. Emailing the photo to my email address I then view the EXIF data of the photo on a separate forensics system and see the correct original date/time of “2009:01:22 06:00:00”.
2. An hour passes. I delete IMG00001 from the Blackberry and then take a photo at 0700 on 1/22/2009. The image name is IMG00002. Using the Blackberry and looking at the properties of photo IMG00002 I see the correct “Last Modified” date and time of “Jan 22, 2009 7:00AM”. Again, I email myself the photo and view the EXIF data of the photo on a separate forensics system. However, this time I see the incorrect original date/time. The EXIF field shows “2009:01:22 07:02:00”.
3. [update: 1/23/2009] - I can also reproduce this EXIF incorrect time stamp issue without deleting photos. This issue presents itself only with the first photo taken after the phone has automatically locked, requiring a password to unlock before the said photo with the incorrect EXIF time stamp can be taken by the device. Subsequent photos taken before the security timeout locks the device have the correct EXIF time stamps.

IMPLICATIONS:

An assumption is made that the Blackberry device is writing the correct date/time within the EXIF data when a photo is taken with the device. EXIF data within photos could potentially be used as evidence to support what an individuals recorded statement (e.g., whereabouts at a given time). From my tests there’s reasonable doubt that the EXIF time stamp of a photo taken by a Blackberry 8310 device (and perhaps others) may be incorrect. Therefore, EXIF time stamps from photos used as evidence becomes highly questionable and ultimately, and likely, could be rendered irrelevant.

ADDITIONAL NOTES & QUESTIONS:

• Blackberry and RIM have been contacted to investigate and confirm the issue.
• I was able to reproduce this issue on a single Blackberry Curve 8310 which was initially running v4.5.0.55 (Platform 2.7.0.68). I was also able to reproduce the failure after upgrading the same Blackberry Curve 8310 to v4.5.0.110 (Platform 2.7.0.90).
• I viewed the EXIF data on a Mac using both “EXIF Viewer” and “Preview”. I viewed the EXIF data on a Windows XP system using “InfranView” with the EXIF plugin installed.
• Can others reproduce the same issue on 8310’s running similar and/or different firmwares?
• Can others reproduce the same issue on non-8310 Blackberry devices?
• [update: 1/23/2009] - Could this be a residual artifact of the security lockout feature? (will need to test after disabling the security timeout)
  

Steve

###

Microsoft out-of-band security bulletin for October 2008

Microsoft recently issued an out-of-band security advisory for a vulnerability in the server service that could allow remote code execution (MS08-067). Due to the criticality of the vulnerability, Microsoft has released a fix out-of-band (i.e., not on the regular Patch Tuesday).

It is strongly recommended that patches be tested and applied to all vulnerable systems you administrate as soon as possible. According to one source, targeted attacks using this vulnerability to compromise fully-patched Windows XP and Windows Server 2003 systems have been seen.

Advisories

MS08-67

SecurityFocus

Additional Information

Technet Blog

Steve
###