Category: PCI

PCI Vulnerability Scans – Part II: PCI and Wireless

In my  previous PCI blog post we discussed risk level of vulnerabilities for PCI. In this blog post I will go over wireless requirements and how to detect rogue APs.

11.1 Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis.
Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.

11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

11.1.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points, including at least the following:

_ WLAN cards inserted into system components

_ Portable wireless devices connected to system components

(e.g., by USB, etc.)

_ Wireless devices attached to a network port or network device

11.1.c Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities.

11.1.d If automated monitoring is utilized (e.g., wireless IDS/IPS, NAC), verify the configuration will generate alerts to personnel.

11.1.e Verify the organizationʼs incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.

PCI wants you to detect rogue access points. However there is a flaw here. PCI doesn’t require you to monitor your network for rogue access points. It just want you detect them quarterly…

Well, what if attacker deploy an AP after you run your quarterly scan? You will be vulnerable lots of networking attack for a 3 more months and you will think you’re secure since you have PCI certification… This is another example of why you should not think you are secure just because you have a certification…

Anyway, let’s return our subject. So we need to determine rogue AP quarterly. Himm. Let’s see. We can do this by scanning all wireless APs and comparing the BSSIDs (mac address) of the APs that have same SSID with our APs. If we see any AP that has our SSID but not in our asset, that AP is a rogue AP.

A. Windows

Go to Start, type powershell, on the blue screen of power shell run these two following commands:

Netsh wlan show networks mode=bssid -> To get all BSSIDs

Netsh wlan show networks mode=ssid-> To get all SSIDs

B. MAC

KisMAC is a free, open source wireless stumbling and security tool for Mac OS

You can download it at http://kismac-ng.org/

After you run the KisMAC, click Start Scan in the bottom right corner.

C. Linux

Kismet is an 802.11 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring

mode, and can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic (devices and drivers permitting).

Linux users can download Kismet at http://www.kismetwireless.net

Note: Please read the full manual, but for the quick starters, here is the bare minimal instruction to operate Kismet:

• Download Kismet from http://www.kismetwireless.net/download.shtml

• Run “./configure”. Pay attention to the output! If Kismet cannot find all the  headers and libraries it needs, major functionality may be missing. Most notably, compiling Kismet yourself will require the development packages and headers, usually called foo-dev or foo-devel.

• Make sure that all the functionality you need was enabled properly in configure. Almost all users will need pcap and libnl support for proper operation.

• Compile Kismet with “make”.

• Install Kismet with either “make install” or “make suidinstall”.

Note: you must read the “suid” installation and security” section of the Readme or your system may be insecure.

• If you have installed Kismet as suid-root, add your user to the “kismet” group

• Run “kismet”. If you did not install Kismet with suid-root support, you need to start it as root in nearly all situations. This is not recommended as it is

less secure than privsep mode, where packet processing is segregated  from admin rights.

• When prompted to start the Kismet server, choose “Yes”.

• When prompted to add a capture interface, add your wireless interface. In nearly all cases, Kismet will autodetect the device type and supported

channels. If it does not, you will have to manually define the capture type   (as explained later in this README).

• Logs will be stored in the directory created when you started using Kismet, unless it changed via the “logprefix” config file or “–log-prefix” startup option.

• READ THE REST OF THIS README. Kismet has a lot of features and a lot of configuration options. To get the most out of it, you must read all of

the documentation.

 

With these tools you can get all SSIDs and BSSIDs on your area (It is good idea to capture packets in different areas of your buildings so that you have better chance to detect any existed rogue APs.

 

Update: I have received couple of e-mail about PCI scope on wireless. Here is what PCI says about it:

“Wireless
If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, “line-busting”), or if a wireless
local area network (WLAN) is connected to, or part of, the cardholder data environment (for example, not clearly separated by a firewall), the PCI
DSS requirements and testing procedures for wireless environments apply and must be performed (for example, Requirements 1.2.3, 2.1.1, and
4.1.1). Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider
deploying wireless technology only for non-sensitive data transmission.”

I believe it is pretty straight forward.  If there is no separation of wired/wireless networks with a firewall on your cardholder data environment you cannot think wireless network is out of your scope…

PCI Vulnerability Scans – Part I : Severity Levels (Risk Rankings)

PCI requires you to have both external and internal vulnerability scans. We will discuss them in detail later. Today I will focus on the risk rankings that PCI uses for vulnerabilities.

PCI DSS requirement 6.2: Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

Notes:

Risk rankings should be based on industry best practices. For example, criteria for ranking “High” risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as “critical,” and/or a vulnerability affecting a critical system component.

The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.

6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities, and that a risk ranking is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as “High.”

6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information.

Himm, as you see with PCI version 2 there is a change in the vulnerability severity categorization. Now PCI asks us to use CVSS and telling that CVSS will be a standardized severity level for PCI vulnerability scans after June 30, 2011.

The table above should give you a very clear idea of which severity category that a vulnerability will be assigned.  For example a vulnerability that has CVSS score of 5 will be a medium level vulnerability that should be fixed to pass PCI compliance.

In order to pass PCI compliance all the vulnerabilities should have 3.9 or less CVSS. There are four exceptions for this rule:

1. The vulnerability is not included in the NVD (National Vulnerability Database): If it is a new vulnerability you have a chance that you don’t have the vulnerability in the NVD.

You can still use CVSS system to calculate the risk ranking score. PCI also asks you to reference to other external resources of information about the vulnerability.

2. You disagree with the CVSS score noted in the NVD: Sometimes the CVSS score may not make sense for your organization for a specific vulnerability. In this case PCI asks you to provide followings:  Score in the NVD, your score, and why you are disagree with the score provided in the NVD.

3. It is a denial of service (DoS) vulnerability:  If it is a purely DoS type of vulnerability you have found, you can ignore it regardless of CVSS score since it is not in the scope of PCI compliance.

4. It is one of the “automatic failure” type of vulnerability: Like DoS vulnerability, you will not care CVSS score (this time it is other way around, the CVSS score is lower than 4.0 but due to the nature of the vulnerability system cannot be PCI compliant)

Here are the all automatic failures:

  • Operating system has no longer supported by the vendor
  • There is an open access to database from internet
  • Built in accounts (OS, DB, Web, Application, Network, etc…)
  • Unrestricted DNS zone transfer
  • SQL injection, XSS, director traversal, HTTP response splitting/header injection
  • The presence of well-known, remotely detectable backdoor applications installed on the servers.
  • If server supports SSL 2.0 or older, or SSL 3.0 with 128-bit encryption

In my next PCI post, I go over wireless requirements and how to detect rogue APs.