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

DDoS Analysis Process

http://isc.sans.edu/diary/DDoS_Analysis_Process/10408

Remote Captures using Wireshark and rpcapd (by Tony Fortunato)

Befriending Windows Security Log Events

When a call starts off with "I think we've had an incident" or "something isn't right" actual proof of an event or incident has really occurred is a must*. If it's some odd happening on Windows, then it's time to look at the Windows event logs. Windows has three standard event logs: application, system and security. The one most security folks need to keep an eye on is the security event log.

Some questions to ask or ponder about your Windows security logs

• Do you review or monitor them?
• How big are the log files?
• What happens when the log file are full?
• Do you know if security audit policies in place?
• Do you have different audit policies for certain systems?
• Are all your machines using the same time reference?
• Can you recognize the event ID that could mean trouble?

Each company has its own policies and procedures on how their systems are designed built, configured and managed, but as incident responders we should know these basic details about the security event log.

A common stumbling block for security teams is actually viewing the security logs on other computers. Access to the security logs, by default, is only to a user with local admin right on the machine. There is a nifty way to allow security staff to view them, while not give them full admin access to the remote machines and is recommended by Microsoft [1]. This avoids upsetting the Windows admin team - who are by now still deploying the latest Ms patches and thus pretty busy.

Microsoft has produced a number of helpful guides on how to configure and apply polices [2 & 3] and there are a large number of other references out there. Working with the Windows admin team help them identify some of the warning signs that appear in the security logs, such as multiple account lock outs, brute force account guessing attacks and what certain event ID are [4]

Let's say you have all the right audit policies in place and can view the security logs, but you're attempting to piece together an attack over 50 machines. Just viewing that many separate Windows event logs will make you go crazy. Jason Fossen, author of SANS Windows track, has a wonderful script [5] to convert event logs in to CSV files. Use tools, such as trusty old Ms Excel, to parser the data from CSV files and correlate them in to events timelines. This makes spotting trends, events or incidents much easier as you can look at the combined data and even turn it in to graphs.

By having the correct information logged and access to the security logs it should take the guessing out of whether a dozen accounts have been locked out is a co-incidence or an actual security incident.

If you have any other suggestions or advice on using the Windows security logs, please feel free to add a comment.

[1] How to set event log security locally or by using Group Policy in Windows Server 2003 for non-admins to access them:

http://support.microsoft.com/kb/323076

[2] Configuring Audit Policies Windows 2000/2003:

http://technet.microsoft.com/en-us/library/dd277403.aspx

[3] Advanced Security Auditing in Windows 7 and Windows Server 2008 R2:

http://social.technet.microsoft.com/wiki/contents/articles/advanced-security-auditing-in-windows-7-and-windows-server-2008-r2.aspx

[4] My favourite place to find what Security Event ID mean:

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx

[5] Dump Windows Event Logs to CSV Text Files

http://blogs.sans.org/windows-security/2009/06/30/dump-windows-event-logs-to-csv-text-vbscript/

Recommended Event Logs sizes in windows:

http://support.microsoft.com/kb/957662

How Not to Respond to a Security Incident

Finding out that your organization's computer defenses has been breached is a stressful experience. Many are unprepared to deal with such situations, and some have a false sense of security as the result of impractical incident response plans.

Having read about the recent PlentyofFish.com security incident, as described by its founder and a more measured perspective from Brian Krebs, I was inspired to create this short list of what not to do when responding to a security incident:

• Don't drive the incident response (IR) team to work for several days without sleep. People's ability to conduct cognitive tasks is severely diminished when they are sleep-deprived. You may need to pull a one-nighter initially, but after that, stagger people's response tasks so they can get some rest.
• Don't make rush decisions when deciding upon the initial incident response steps. It is OK to take some time to assess the situation before taking action to avoid making mistakes. Of course, you need to balance this with waiting too long before making decisions regarding the next steps.
• Don't immediately attribute the source of the breach to people, companies or countries without conducting a thorough investigation. In particular, don't assume that the entity who notified you of the breach of a vulnerable condition is the entity responsible for the incident.
• Don't attempt to hire the entity who notified you of the breach to assist with incident response, unless there's truly no one else qualified for the job. They might not be responsible for the breach, but it's best to control the situation where you might accuse them of extortion. Also, there's no reason to encourage ambulance-chasing practices.

For more recommendations on what not to do when someone reports an incident, as well as for tips on what to avoid doing when reporting an incident, see our earlier diary Incident Reporting - Liston's "How-To" Guide.

In addition, here are a few Emergency Incident Response steps from Mandiant, which are a good starting point for responding to a security incident. I also put together a few incident response cheat sheets:

• Initial Security Incident Questionnaire for Responders
• Network DDoS Incident Response Cheat Sheet
• Security Incident Survey Cheat Sheet for Server Administrators
• Critical Log Review Checklist for Security Incidents

-- Lenny Zeltser http://blog.zeltser.com/