November 2008

You are currently browsing the monthly archive for November 2008.

PCI 1.2 and Anti-virus Software Requirements

November 20, 2008 in PCI DSS

Last month the PCI Security Standards Council released version 1.2 of the PCI DSS. There were a number of updates and changes to the standard, most of which I have already written about. I want to revisit Requirement 5 of the PCI DSS which relates to the use of anti-virus software on all systems in the cardholder data environment. Version 1.1 states the following:

Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers) Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.

Version 1.2 changes the requirement as follows:

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Notice that they removed the note defining which types of systems are not typically affected by viruses. I attended a seminar recently by David Wallace, a noted PCI DSS expert and someone who is very involved with the PCI SSC. His explanation was that the council wants remove the “pass” that Unix and Linux systems had for not deploying anti-virus software. There have been a number of viruses released in recent years that affect Unix-based operating systems. Also, there are several vendors that now sell anti-virus products for various flavors of Unix and Linux including Red Hat Linux, Solaris and MacOS. These vendors include Trend Micro, McAfee and ClamAV.

The best way to meet this requirement is to install anti-virus software on any system within scope for which a solution exists. Obviously, systems such as IBM’s I-Series and Mainframes would be excluded. But systems running Solaris or RH Linux should have anti-virus software installed if one exists for the particular version you are running. Furthermore, there really is not a compensating control for this requirement. If anti-virus software exists for the system in question, it must be installed. I cannot think of a compensating control that provides a “similar level of defense” as the original requirement.

New Attacks on Wireless Encryption

November 12, 2008 in Cryptography, Wireless

Two graduate students in Germany have successfully against the WPA wireless encryption protocol. WPA was developed as a stop-gap measure when it was discovered that WEP, the original wireless encryption protocol, was deeply flawed and offered virtually no protection from eavesdropping on wireless traffic. Tools have been available for many years that can crack a WEP encrypted wireless network in seconds. If you are still using WEP, stop.

WPA offered many improvements over WEP even though it used the same cypher (RC4). The primary improvement was frequent rekeying that made the WEP hack useless against WPA. However, with this new attack published this week, WPA encrypted networks may now be vulnerable. Many enterprises and home users adopted WPA because it did not require a hardware upgrade; it could be implemented with fairly simple software updates. But the days of WPA providing adequate security are quickly coming to and end. Even though the attack published this week is limited in its scope, the writing is on the wall. Once a significant attack is developed against a protocol or cypher, it doesn’t usually take long before better ones are developed or the same one is made better through faster processing power (think DES and WEP).

The solution is to implement WPA2 which uses AES as its cypher. AES is the gold standard of encryption cyphers and as a result, WPA2 is not vulnerable to this or any other known attack. It comes in two flavors: WPA2-Personal (sometimes called WPA2-PSK) and WPA_Enterprise. The primary difference is that the personal implementation uses a preshared key, or password, and is designed for home use. The enterprise version requires a RADIUS authentication server and is designed for larger, corporate environments. Most newer wireless clients support WPA2, although some older ones do not. In fact one of my home laptops (about 4 years old) doesn’t which is preventing me from upgrading my wireless network to pure WPA2. It looks like that laptop will be getting replaced soon, thanks for two graduate students from Germany :) .

Protocol Fuzzing With the Mu-4000

November 4, 2008 in Security Testing

I recently had a demonstration of the Mu-4000 Service Analyzer by . This device provides the type of security testing capabilities difficult to duplicate with any other single product (hardware or software). The Mu-4000 is an appliance that integrates the testing capabilities and methodologies of a Spirent or Ixia solution with the fuzzing, vulnerability testing and DoS capabilities typically only found in specialized software applications. I will focus on the Mu-4000′s protocol fuzzing capabilities, since this is the most interesting to me.

The Mu-4000 supports over 50 protocols including the basic ones you would expect (HTTP, FTP, SSH), but more interesting and less well known ones as well (SIP, VRRP, DHCPv6). For any protocol, the Mu-4000 can attack a device with thousands and even millions of different mutations in a effort to find weaknesses in the protocol’s implementation on the targeted device. Let’s take a look at HTTP as it is fairly simple and familiar to most.

The goal of any protocol fuzzer is to examine how a device responds to unexpected input. As we all know, the bad guys do not always play by the rules and will take advantage of any weakness they can find in a system. And many times these weaknesses are the result of incorrect error handling of unexpected inputs. This is why fuzzing is useful to a security practitioner. It helps you find those weaknesses before the bad guys do.

A typical HTTP client request looks something like below:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/
jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE
5.01; Windows NT)
Host: www.example.com
Connection: Keep-Alive

The Mu-4000 will send many different mutations for each variable in the protocol transaction in an effort to deliberately break the device. Frequently, these mutations violate the protocol by sending more data than is allowed or sending a different type of data than is allowed. If the protocol calls for a 8 bits, the Mu will send 9 to see how the device responds. Occasionally, this type of protocol fuzzing will uncover an error in the way the device handles anomalous input and this is the value that this type of testing brings to the table. By finding the weakness before the system is put into production, you eliminate the need to fix it after the system is put into production when it is much more costly to do so. And additionally, you make the system more resistant to those with malicious intent.

Copyright © 2011 InfoSecStuff.com — All Rights Reserved