|
|
All of the techniques mentioned so far have been focused on hacking into networks. Rogue APs take a different approach. Instead of actively attacking a network to get to the users, you wait for the users to come to you. Why attack the castle when you can just build your own right next to it?
Until recently, most rogue APs were fairly unsophisticated tools. An attacker would set up a Linux box with a high-powered antenna, use a driver that allowed the card to look like an AP, and set the SSID to something ubiquitous such as T-Mobile or Linksys. An unsuspecting user would then connect to the cleverly named AP, whereupon the attacker would give them an IP address and refer them to his own captive portal. Once a user logged in to the fake portal, either she would be given an error message or the AP would start forwarding packets, hoping to collect more upper-layer credentials. A tool called KARMA by Dino Dai Zovi and Shane Macaulay (K2) upped the ante significantly.
KARMA's features really make it stand out. The biggest improvement is that whenever KARMA sees a client send out a probe request, it sends back a probe response immediately. No longer does an attacker have to guess a good SSID (such as T-Mobile); instead he can create networks on the fly that respond to the user's settings. In order to understand why this is such a debilitating attack, a little background on what Windows does when a user is looking for wireless networks helps.
Windows maintains a list of networks that the user is known to utilize. This is called the preferred network list. You have probably seen it when you click the Wireless Networks tab of a wireless network connection. Whenever a Windows machine is looking for wireless networks (because either the card was just enabled or the user clicked the Refresh Network List button or so on), it sends out probe requests in the order in which the networks are found in the preferred network list. If Windows receives a response with the correct security settings, Windows associates with that network. This means that if a user has any unencrypted networks in the preferred networks list, if Windows sends out a probe request looking for it, Windows will be tricked by a KARMA-based rogue AP in the area.
An interesting question to ask is, What does Windows do when it doesn't find a preferred network? One guess would be that it just turns off the card and tries again in a few minutes. This makes the most sense, especially from a security perspective.
The correct answer, however, is that it tells the card to connect to a network with a randomly generated SSID. A minute later it will rescan for the user's preferred network. It should be mentioned that old airport cards did something similar on OS X. Most likely, the reason developers do this is to avoid inconveniencing the user by disabling and reenabling the wireless card, which could cause noticeable delay when looking for networks.
Windows counts on network names not being a long string of random bytes. If someone happens to have such a network nearby, Windows actually connects to it, even though that is not what it was intending to do. Perhaps the most impressive thing about this is that Windows will report that the wireless card is not connected.
You can verify this by placing a Windows machine with an empty preferred network list within range of a KARMA rogue AP. There are two reasons the preferred network list has to be empty for this to work. If the list contained an encrypted network as the last entry, Windows would want the random network to be encrypted in the same way because Windows doesn't reset the security properties of the card before it attempts to connect to the random network; it was never expecting to find it anyway. If the list contains an unencrypted network before the last entry, then KARMA succeeds and Windows connects to that network. When Windows is fooled into connecting to an unencrypted network in the client's list, Windows informs the user they are connected as usual.
Though KARMA's current technique of responding to all the probe requests is very effective, there is no reason it couldn't be modified to respond only to the random networks Windows looks for. KARMA would be less likely to catch users, but every user KARMA did get would have no idea they were on a network at all.
Aside from the very impressive low-level work KARMA has done to increase the likelihood of a rogue AP attracting users, it has a number of other application layer features as well. KARMA currently includes the following rogue servers:
A POP3 server
An FTP server
An HTTP server
When a user is connected to a KARMA rogue AP, KARMA sets all the DNS queries to return to the attacker. KARMA then takes advantage of this to get the victim to connect to one of the servers just listed. For example, if a user is connected to a KARMA rogue AP and he attempts to FTP into http://www.ftp.importantworkstuff.com, he will be redirected to KARMA's rogue FTP server. KARMA's ftp server will log the victim's username and password and then tell him the attempt has failed.
The biggest motivation for having the rogue application layer servers for unencrypted traffic is not to steal the user's passwords, but to present the attacker with the ability to launch reliable client-side exploits. For example, you could provide a juicy Internet Explorer exploit to KARMA, and as soon as a victim attempts to load a web page, the victim is redirected to your page. Currently, KARMA requires that you bring your own client-side exploits.
|
Popularity: |
6 |
|
Simplicity: |
7 |
|
Impact: |
8 |
|
Risk Rating: |
7 |
In the following example, a Windows laptop has been configured with an empty preferred networks list to illustrate Windows silently connecting to one of its randomly generated SSIDs. Remember, if KARMA tricks Windows into connecting to one of its normally unencrypted networks, Windows will inform the user that she is connected as usual.
The first step to launching this attack is to get KARMA installed and working. For KARMA to do its probe request magic, it needs to use a patched madwifi-old driver. Currently, KARMA uses the same driver that was recommended in Chapter 4.
Wireless security moves quickly, however, and by the time you read this, KARMA may recommend a different driver, so be sure to check. Assuming you have installed the patched MadWifi driver and compiled KARMA, the following commands should launch the program. If monitor-mode.sh gives an error regarding iwconfig, you may need to create a link from /sbin/iwconfig to /usr/sbin/iwconfig or modify the script.
[root@phoenix:/home/johnycsh/karma]$ ./bin/monitor-mode.sh ath0 [root@phoenix:/home/johnycsh/karma]$ ./bin/karma ./etc/karma.xml Starting KARMA... Loading config file ./etc/karma.xml ACCESS-POINT is running DNS-SERVER is running DHCP-SERVER is running POP3-SERVER is running FTP-SERVER is running [2006-05-14 15:31:31] INFO WEBrick 1.3.1 [2006-05-14 15:31:31] INFO ruby 1.8.2 (2004-12-25) [i386-linux] [2006-05-14 15:31:31] INFO WEBrick::HTTPServer#start: pid=10946 port=80 HTTP-SERVER is running CONTROLLER-SERVLET is running EXAMPLE-WEB-EXPLOIT is running Delivering judicious KARMA, hit Control-C to quit.
At this point, KARMA has successfully started; let's see what happens when an unsuspecting Windows box comes into range:
DhcpServer: 00:0d:29:02:44:b8 discover DhcpServer: 00:0d:29:02:44:b8 (A1307) <- 169.254.0.254 DhcpServer: 00:0d:29:02:44:b8 (A1307) <- 169.254.0.254 DNS: 169.254.0.254.1033: 40252 IN::A time.windows.com
At this point, the victim is connected, and Windows doesn't even tell the user. We can verify the SSID the user was looking for by checking the log file:
[root@phoenix:/home/johnycsh]$ tail -n 1 /var/log/messages May 14 16:54:49 phoenix KARMA: Node [00:0d:29:02:44:b8] associating to ssid [0x091c0e150d18140b161c12010d04101212031f170c1a1117091503120f131503]
If the victim tries to use the network, he'll be redirected to the rogue application layer servers. For example, this output was generated by KARMA when I attempted to FTP to http://www.boring.workstuff.com from the Windows machine:
DNS: 169.254.0.254.1033: 46641 IN::A boring.workstuff.com FTP: 169.254.0.254 im/pwned
Rather than just sit around and wait for the user to connect to a rogue server, you can be a little more proactive. The following output shows a successful Nmap scan against the victim:
[root@phoenix:/home/johnycsh]$ nmap 169.254.0.254 Starting nmap 3.81 (http://www.insecure.org/nmap/) at 2006-05-14 16:52 UTC Interesting ports on 169.254.0.254: (The 1660 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds
Finally, just to drive the point home, here is a picture of the Network Connection status window. Though you can't see it in Figure 6-2, there is currently a little red X over the network connection in the corner. The only way a user would know the wireless card is doing anything is if he tried to use the network and found, surprisingly, that it worked, or he noticed the wireless card lights blinking.
KARMA has increased the likelihood of attracting clients to a rogue AP tremendously. It has even facilitated the discovery of vulnerabilities in the way Windows handles looking for networks. OS X uses a similar algorithm to look for networks, but it leaves out the "connect to randomly generated SSID for a minute" step. OS X also doesn't look for a user's preferred networks continuously, making it harder for KARMA to catch a probe request to respond to.
|
Popularity: |
1 |
|
Simplicity: |
2 |
|
Impact: |
7 |
|
Risk Rating: |
3 |
Running KARMA on a Linux laptop is very effective, but what if you have more long-term penetration goals? Maybe you want to drop off a real rogue AP at a location, plug it in somewhere, and let it gather passwords or other traffic for a few weeks. Considering the price of many APs makes them almost disposable, even if someone finds your box, you might be out only $40.
Airsnarf Rogue Squadron is an alternative firmware for the Linksys WRT54g AP. When Linksys first released the WRT54g, they based the firmware on Linux, forcing them to release the code once people realized it. Releasing the code in turn spawned an entire community devoted to increasing the amount of features available in the ubiquitous little blue boxes.
Though nobody really knows if it was to push Linux alternatives out or just market pressure (probably a little of both) Linksys started "upgrading" the WRT54g to less and less flash and RAM. Minimizing the amount of memory put the squeeze on the more feature-packed alternative firmware. The real killer, however, was the release of version 5; the operating system was changed from Linux to VxWorks. Most alternative firmwares can't be coaxed to run on the version 5 hardware. Currently, the only alternative known to work on version 5 is dd-wrt micro. Apparently Linksys didn't want to squash the alternative Linux firmwares too badly because they also released WRT54GL (the L is for Linux), which is really version 4 with a different name.
The moral of the story is if you are interested in modding a 54g for any reason, be sure to check the status of the latest versions. There are a few popular firmwares available (HyperWRT, eWRT, OpenWRT, and so on). Different versions have varying hardware requirements. Rogue Squadron is based on eWRT, which only works with versions up to 2.2.
Assuming that you have an older model that can be upgraded to Linux easily, the process is straightforward. Just download the firmware file (typically .bin), browse to the Upgrade Firmware menu, and give it a try. Different firmwares vary on the details (some want to use tftp instead of the web interface), but most suggest not upgrading from the wireless interface and waiting at least five minutes before touching the router.
Though Rogue Squadron is easy to install, it lacks many of KARMA's features. If you are seriously interested in creating a rogue AP out of a WRT54g, the OpenWRT firmware might be a better starting place. OpenWRT comes with its own simple package-management utility, allowing you to install various Linux utilities fairly easily. It's not hard to imagine a WRT54g running OpenWRT, discreetly plugged in at a coffee shop and using dsniff to capture all the users' higher-level passwords and shipping them off to a gmail account every night. Finally, if you are willing to spend a few hundred dollars on your rogue AP setup, you could install KARMA on an embedded box from Soekris, combining all of the power of KARMA with the benefits of a real rogue AP.
The most effective line of defense against rogue APs is to use WPA/WPA2 in enterprise mode with some sort authentication type that provides mutual authentication. For example, when using EAP-TLS, the attacker setting up a rogue AP will not be able to fool the victim because she won't possess the authentication server's private key. WPA-PSK can be an effective countermeasure as well, as long as an attacker doesn't recover the PSK. If authentication can't be used, such as at a hotspot, other defensive measures can be taken.
One approach is to position sensors around the network to detect other APs. There are many products designed to work in this way, such as AirMagnet and AirDefense. As you can imagine, this approach is expensive, as it requires both the hardware (sensors) and the software to talk to them. Most products with this sort of setup have other features as well, including real-time displays of traffic and signal strength. Such a setup at a hotspot is unlikely; simply running a wireless scanner once a day would at least detect rogue APs that had been dropped off, assuming the user knows what he is looking for.
Another technique is to equip user stations with software that attempts to detect suspicious wireless activity, such as rogue access points. AirDefense has a free product that runs on end-user stations. It will also integrate into their more expensive enterprise product. The Shmoo group released a tool to do this as well, called the Hot Spot Defense Kit. The OS X version seems to function well; however, the XP version looks like it could use some maintenance.
If you are concerned about your data when using a public hotspot, the best thing you can do is to use a VPN for all of your traffic.
|
|
