Archive for the ‘Wireless’ Category

Filed Under (Conferences, Wireless) by Michael Dahn on June-29-2008

AirDefense and Motorola have partnered to hole an executive dinner on wireless security in NYC on July 17th, 2008.  They invited us to present and I’ll be talking about wireless security as it relates to PCI DSS compliance.  I’ll also be discussing the difference between compliance and validation as it pertains to current data compromises.

If you’re in the NYC area and care about wireless security, you should register for the event and attend.  I’ve always said that it’s better to have more tools in your toolbox.  Attending this session will broaden your understanding of the standard and help you maximize your security capital by focusing on day-to-day security while saitsfying your compliance needs.

I knew a company once that reverse engineered their database system so they could extract the encryption/decryption keys just so they could print them out and store them under “dual control” in two different safes.  That company successfully increased the risk to cardholder data just to meet a perceived compliance need.

I’d like to help you better understand the standard, especially those surrounding wireless security, so you can be more effective in securing your infrastructure.

Popularity: 6% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI DSS, Wireless) by Michael Dahn on March-15-2008

wireless.jpgMany people think that Wireless only applies to three requirements within the PCI DSS (1.3.8, 2.1.1, 4.1.1) and that it only applies to companies that have implemented wireless, but this is not the case.

The latest Aegenis whitepaper / FAQ on wireless within PCI DSS clarifies much of the confusion.  The FAQ also raises some important points for companies that do not have wireless, but need to adhere to requirement 11.1.b.

This was made available in the latest Aegis newsletter.

Popularity: 31% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Merchant, Wireless) by Michael Dahn on November-26-2007

60min.png60-Minutes has a segment called “Hi-Tech Heist” that details how wireless insecurity can lead to credit card compromises.  While I agree that wireless, remote access, and insecure integrated POS (IPOS) machines are a great risk to merchants, I strongly disagree with the NRF perspective.

Again, merchants are not required to retain the PAN, or any other cardholder data, after settlement.  (Please read that sentence over and over.)

Merchants need to be aware that in-store wireless is considered a “public network” and needs to be segmented off or properly protected.

Although the 60-Minutes segment showed cracking WEP as simple there was no way to know if the wireless networks were connected to the credit card networks.  Either way, it should be a warning to merchants to upgrade their wireless infrastructure or to segment it from the rest of the corporate network.

Another hot tip it to segment each store such that an attacker that compromises one store cannot “hop” (or traverse) from one store location to another.  Traffic can flow from the corporate network to a store location (for administrative purposes) but should not be permitted from one store directly to another.

Links:

Popularity: 30% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Credit Card Fraud, Wireless) by Michael Dahn on November-18-2007

wireless.jpgThe Associated Press covered the AirDefense study showing that many retailers are susceptible to data compromise.  I have been saying this for many years now that the greatest risks to retail merchants are: insecure POS systems, remote management, and insecure wireless networks.

It seems that there is also a new threat in town, MPack (wiki).  This is custom commercial malware with anti-virus like updates.  Read an interview with the developer, coverage by The Register.

Popularity: 37% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI DSS, Third-Parties, Wireless) by chitchcock on August-14-2007

NIST released 800-48-Rev1 on 2007.08.02. Given events some recent events, the relevance of wireless security to PCI is unquestionable.

If you’d like to submit comments on 800-48, they’re due by 2007.09.14. Simply send an e-mail to 800-48comments@nist.gov with “Comments SP 800-48″ in the subject line.

Read the rest of this entry »

Popularity: 29% [?]



Filed Under (PCI DIY, Wireless) by chitchcock on June-12-2007

wireless.jpgIn addition to poorly protected wireless access points — ala TJX — rogue access points can be of great concern to a network administrator. Due to administration overhead, many environments are relatively lax in the preventative measures that would disallow employees from bringing in such devices and plugging them into the network. So how do we tell the difference between that test machine that Joe Engineer has under his desk and an unauthorized wireless access point? Luckily, rogue WAPs can be located over not one, but two mediums: the wireless network and the wired network. Given that most — if not all — ASVs focus on the wired side, we’ll explore techniques to locate rogue WAPs from an ASVs point of view.

HTTP Banner Grabbing
Many WAPs ship with embedded web-servers that are used for administration purposes. Fortunately, we can sometimes glean information from the web-server that allows us to identify the device as a WAP. For a quick-and-dirty way to grab HTTP banners for a particular IP range using nmap and netcat:

for i in $(nmap -sL -n 10.10.10.1-100 | grep -v finished | grep -v nmap | awk '{print $2}'); do echo -e "GET / HTTP/1.0\r\n\r\n" | nc -v -n -w 2 $i 80; done > http_output.txt

Some versions of echo don’t support the -e flag (which properly executes \r\n as carriage-return and line-feed respectively), in which case, create an input file with a well-formed HTTP request:

GET / HTTP/1.0
Host: 10.10.10.10

Remember to hit Enter twice at the end of the file, so that it has two carriage-returns. The new command will be:

for i in $(nmap -sL -n 10.10.10.1-100 | grep -v finished | grep -v nmap | awk '{print $2}'); do cat input.txt | nc -v -n -w 2 $i 80; done > http_output.txt

Look through the output at the Server header, WWW-Authenticate header (basic authentication is often enabled), and the HTML source for relevant keywords (e.g., Linksys, WRT54, DD-WRT, D-Link, etc). It’s a good idea to build up a keyword file and use it to search through your output file :

for i in $(cat wap_keywords.txt); do grep $i http_output.txt; done > danger.txt

Sample Output from a Netgear WGT624:

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="WGT624"
Content-type: text/html

<html>
<head><title>401 Unauthorized</title></head>
<body><h1>401 Unauthorized</h1>
<p>Access to this resource is denied; your client has not supplied the correct authentication.</p></body>
</html>
Connection closed by foreign host.

Of course, not all access points (Cisco Aironets for example) give-up useful HTTP banner information.

FTP Banner Grabbing
Many WAPs also have FTP enabled by default. Banner grabbing with nmap and netcat is similar to HTTP:

for i in $(nmap -sL -n 10.10.10.1-100 | grep -v finished | grep -v nmap | awk '{print $2}'); do echo "quit" | nc -v -n -w 2 $i 21; done > ftp_output.txt

The output might be something like the following (note that VxWorks is an OS that is common to embedded devices):

Connection to 10.10.10.100 21 port [tcp/*] succeeded!
220 VxWorks (5.4.2) FTP server ready.
221 Goodbye.

Banners for just about any plaintext protocol are similarly trivial to mine for useful information, provided that the request is well formed.

SNMP SysDescr
SNMP is another great source of information for locating rogue WAPs — for devices with SNMP enabled that is. Net-SNMP is easily installed on most Linux machines. Simply do so and use snmpwalk to search for WAPs:

for i in $(nmap -sL -n 10.10.10.1-100 | grep -v finished | grep -v nmap | awk '{print $2}'); do snmpwalk -v 2c -c public $i sysDescr; done > snmp_output.txt

Output might be something like:

SNMPv2-MIB::sysDescr.0 = STRING: BT Voyager 2000 Wireless ADSL Router

Advanced Techniques
While the above techniques are useful for one-off checks, it’s certainly not very scalable. There are many tools that contain built-in fingerprint databases that aid in identifying common WAP services. For example, nmap will look up MAC addresses:

Host 10.10.10.100 appears to be up ... good.
Interesting ports on 10.10.10.100:
PORT STATE SERVICE VERSION
23/tcp closed telnet
MAC Address: 00:06:25:6D:6E:8F (The Linksys Group)

P0f (a passive fingerprinting tool) and nmap both do stack fingerprinting, which involves looking at specific packet options and matching them to a known fingerprint. Here are a few p0f fingerprints:

0:32:0:40:.:.:Xylan:OmniSwitch / Linksys WAP11 AP (dropped)
S2:64:0:44:M32728:A:D-Link:DSL-500
8192:64:0:44:M1460:A:Cisco,Nortel,SonicWall,Tasman:Aironet,BayStack Switch,Soho,1200
2048:255:0:44:M1400:A:Netgear:MR814

Network Awareness
The most effective technique is simple network awareness. Log new devices that get plugged into switches and routers. Control the use of DHCP (many WAPs, incidentally, serve DHCP requests by default). Map your network periodically and diff the results.

Though rogue APs may or may not be within the scope of your PCI effort, they should certainly be within the scope of your overall security effort. One measure of your ASVs thoroughness should be their accuracy in detecting wireless access points over the wired network.

Popularity: 34% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Credit Card Fraud, Merchant, Third-Parties, Wireless) by chitchcock on May-8-2007

wireless.jpgThe WSJ reports:

The biggest known theft of credit-card numbers in history began two summers ago outside a Marshalls discount clothing store near St. Paul, Minn.

There, investigators now believe, hackers pointed a telescope-shaped antenna toward the store and used a laptop computer to decode data streaming through the air between hand-held price-checking devices, cash registers and the store’s computers. That helped them hack into the central database of Marshalls’ parent, TJX Cos. in Framingham, Mass., to repeatedly purloin information about customers.

The $17.4-billion retailer’s wireless network had less security than many people have on their home networks, and for 18 months the …

More information here and here.

Popularity: 35% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]