In 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.
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]](http://slashdot.org/favicon.ico)
![[Digg]](http://digg.com/favicon.ico)
![[Reddit]](http://reddit.com/favicon.ico)
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif)
![[Facebook]](http://www.facebook.com/favicon.ico)
![[Technorati]](http://technorati.com/favicon.ico)
![[Google]](http://www.google.com/favicon.ico)
![[StumbleUpon]](http://www.stumbleupon.com/favicon.ico)
If you’re interested in learning how to test the security of your network by attacking it, 
The newest revision to 
You’re vulnerable.
This is the first of what will — hopefully — be many posts that will deal with the technical aspects of PCI compliance. The intention is to provide substantive information for validating commonly encountered vulnerabilities — which is also useful for comparing ASVs — with a quick-start guide style of presentation. In keeping with the spirit of my