Post Fri Jul 17, 2009 2:47 pm

Skillz February 2009 Winning Entry - Technical

Brian Hart


1. What SSID is used for the kids' rogue AP?

I loaded the dump file into AirSnort to reveal the SSID of boondoggle.
boondoggle  (MAC 01:1A:70:FC:C0:6F) on Channel 11

2. How were the kids able to access Greg's rogue access point even though it was not detected during Mr. Phillips PCI compliance assessment?

Well according to PCI DSS 1.2, as a minimum, you only need to check for rouge APs once a quarter.  While Phillips Design, Inc. is clearly only trying to meet the letter of compliance as mentioned in section 11.1, one could argue that this is not the true spirit of PCI.  So, in this case it seems the PCI consultants only checked for a time-span of 28 minutes and whether or not they stayed in one location or roved the building(s) premises, both inside and out, during their assessment time is unknown in this story and potentially a moot point.  Also, PCI 11.1 still doesn’t specify what channels and frequencies to scan nor does it imply that you have to check from multiple locations therefore it is plausible that some signals will go undetected.  Nonetheless, I had a hard time trying to figure this question out as I saw a few possibilities which may mean I am missing or not correlating some obvious information in the story.  All I can count on is the fact that since Peter is using a directional antenna from the parking lot, I can rule out a laptop/mini using a mobile broadband card.  Anyway, below are some of the possibilities that could explain how detection was avoided:

• Greg could have built a Faraday cage of sorts that only allowed the signal to escape out a window in Mike’s office is unlikely, but plausible.  A more realistic effect could be applied by replacing any Omni directional antenna(s) found on most AP’s with a directional antenna that pointed into the parking lot.  Also, changing the beacon interval and transmit power to low will help curb detection.

• Another possibility is that the rouge AP is not a Wi-Fi router as most would assume, but possibly a laptop/mini with a long range Bluetooth enabled USB dongle whose range could be as far as 100 meters.  This kind of signal would not be picked up by KISMET, but would be seen  by a spectrum analyzer or using programs like BTSCAN or hcitool.  Or could it indeed be a hacked Wireless Router AP with the Wi-Fi signal turned off and one of these Bluetooth-bad-boys installed in the routers USB Port.
http://www.anycom.com/products/bluetoot ... ab=support

• Without Wi-Fi probes constantly running.  Rouge APs could pop up at anytime.  For example, some of the newer Wi-Fi routers like the D-Link 655 allow the Wi-Fi radio to be scheduled thus allowing you to turn the AP On/Off during the hours when most PCI consultants and IT staff have long gone home.  A similar effect could be achieved by writing a tool to turn on and off the wireless radio on a laptop/mini running AP emulation software like hostap.  Below is way to do script the enable/disabling of the wireless radio for an Apple Airport Extreme.
http://forums.macosxhints.com/showthread.php?t=93014

• While it appears the boondoggle AP is using channel 11. This is noteworthy that in the US and Canada, channels 1-11 are the only channels permitted for use by the FCC.  However, channels 12, 13 (Europe) and 14 (Japan) also exist.  Since the PCI compliance auditors are probably from a US firm and they seemed to only use Kismet. It should be noted that channels 12-14 are not scanned for by default.  However, to scan these channels you could edit the kismet.conf file to include those channels and you may need to change the driver version of you Wi-Fi card from US to say JP for Japan.

• While I would hope this is not the case, I suppose the PCI consultants Wi-Fi card might only be 802.11 b/g capable.  This means they would not be picking up any 802.11a (5GHz) signals.

• Also the AP could be a hacked router running OpenWRT with wknock-ng where the AP is configured not to respond or wakeup unless the right sequence of port knocking triggers it to come alive.  However, in this case the AP could be broadcasting but not responding to anything on the wire.  However, the PCI consultant should have seen this, triangulated the signal and tracked this down to Mikes Office.

Lastly, onto my educated guess since I have to pick one.  In this case, I believe the most plausible based on the storyline is that the open AP called NETGEAR is a Trojan horse so to speak.  Let me explain.  I believe the rouge access point was set to be cloaked by the real NETGEAR AP during the PCI Consultants visit.  I believe the rouge AP was set to have a very low transmit power and was setup to clone the existing NETGEAR SSID and MAC address whose higher transmit power seemingly overtook the PCI scan.  However, I reviewed the MAC address for SSID boondoggle and that device did not resolve to any vendor which is a cause for suspicion.  So I would have to assume that the rouge AP was subsequently changed to the SSID “boondoggle” and the MAC address “01:1A:70:FC:C0:6F” which is clearly spoofed.

3. How did Peter compromise the target system? (hint: no previously undisclosed exploits were used; remember, this was 1973, which would have made it a -12775-day exploit)

(you got me here… however my guess based on the dump)

It seems they attacked by first launching an ARP poisoning attack possibly using the following ettercap command which will redirect all request to the rogue AP 172.16.0.6 for sniffing.

ettercap –i eht0 –T –M arp:remote /172.16.0.99/ /172.16.0.6/ > dump.txt

I believe at some point they attacked Mr. Phillips desktop using the Metasploit Framework with a payload that targeted an OpenSSH vulnerability found in Ubuntu 7.1.  I think they then injected an installation of VNC server which is how they accessed his machine but did not confirm this.



Congrats,
Don
CISSP, MCSE, CSTA, Security+ SME