|
|
The tools you use are only as good as the hardware they are running on, but the best wireless card and chipset in the world is useless if the driver controlling it has no idea how to make it do what you want.
This section introduces you to the currently available drivers, the chipsets that they control, and the cards that have the chipsets in them. There is a strong emphasis on Linux drivers, because this is where most of the development is currently happening. Before getting into the nitty gritty details of chipsets and drivers, some information on why drivers and chipsets are so important in wireless hacking is needed.
The most unique aspect of wireless hacking is that it happens at layer two (the link layer) in the OSI model. Today, you don't hear about people coming up with new attacks against Ethernet (another link-layer protocol). Nor do you ever hear anyone say, "Man, you gotta go get this new Ethernet card. It receives 30 percent more packets." Currently, 802.11 is the only link-layer standard being studied for new security problems-and being at such a low layer on the stack causes a frustrating situation to occur. Certain tools and techniques can become inextricably tied to certain chipsets. Understanding the reasons for this will help you choose a chipset/card that is right for you, and also help you identify tools that won't break when the next best chipset gets released.
The 802.11 standard is complicated. Very complicated. Just consider for a moment that 802.11 is a layer two protocol that has its own built-in-retransmission and fragmentation support (not even mentioning the optional power-savings mode). Pushing all this complexity down into layer two has created some design issues that have never come up before in commodity networking hardware-namely, where to draw the line between hardware and driver and where to draw the line between driver and OS proper. Where these lines are drawn has very real impact on what you can persuade a chipset to do that it might not otherwise do.
When your operating system wants to send an Ethernet packet, the kernel forms a simple 14-byte Ethernet header, prepends it to the layer three packet (IP in most cases) and hands it off to the Ethernet hardware to put it on the wire. In the worst case scenario, the Ethernet card causes a collision (or two), backs off randomly, and transmits until it succeeds.
Now what happens when your operating system wants to send out an 802.11 data packet? Well, the kernel might create the 802.11 header itself, pass it off to the card along with the payload, and forget about it. But what happens then? A lot. There are 126 pages of state transition diagrams inside the 1999 revision of the 802.11 standard describing exactly what should happen if you're curious, but here are a few highlights.
First, the card/driver needs to ensure that the media is not physically busy at the time the sender wishes to transmit. This is the easy part and is called a clear channel assessment in the standard.
Second, the card/driver also is responsible for keeping track of various other state information related to media access control. One example is to make sure that it doesn't step over another client's Clear To Send (CTS) window. Once the card has decided it's okay to transmit, it needs to switch the radio into transmit mode (recall the cards are half-duplex) and send the packet. Immediately after transmission, the card switches back into receive mode. If the card/driver does not receive an acknowledgment (ACK), then it needs to back off and retransmit. There are other factors it must consider as well (Request To Send (RTS) thresholds, fragmentation, and so on) but this should get the point across.
The question remains, however: who is responsible for all that overhead related to media access control, the driver (software) or the chipset (hardware)? If the answer is software, then you might be able to bypass as much of the protocol as you would like and transmit arbitrarily crafted packets (forged deauthentication packets, for example). If the answer is hardware, you are generally at the mercy of the chipset as to what you may or may not transmit. If all you want to do is get a card into monitor mode, this may not be such a big deal. As soon as you want to start injecting packets (and many new techniques that take advantage of this are surfacing), it becomes very important. If the chipset itself (hardware) is responsible for generating control or management packets, it might not let you send them yourself.
This whole section can be summarized as follows. When you tell an Ethernet card to send a packet, you are telling it to send the packet. It's not going to examine the packet to see if it likes what you are trying to send, and it's not going to wait around very long to transmit. When you tell a wireless card to transmit, you are suggesting it start transmitting at its soonest possible convenience, assuming it agrees with your payload. If you're reading this book, you probably want a wireless card you can boss around, one that's going to turn a blind eye to anything mischievous you might want to put into the air. To find out which wireless cards these are, read on.
Every card has a chipset. While there are hundreds of unique cards on the market, there are only a handful of chipsets. Most cards that share a chipset can (and usually do) use the same driver. Different cards with the same chipset look pretty much identical to software. The only real difference is what sort of power output the card has or the type and availability of an antenna jack. Deciding what chipset you want is the first step in deciding which card to buy. It should be mentioned that most of these technical details are of little concern to Windows users, since the best they can hope for is to get a card that supports monitor mode. There is very limited support on Windows for packet injection, let alone anything more subtle. The following chipsets are listed in (roughly) chronological order of introduction.
The Hermes, prism, and prism2.5 chipsets are all very similar. Each of these can be used under Linux with either the host-ap driver or the wlan-ng driver. These chipsets are very popular in older cards and only support 802.11b. If you have an older Orinoco Silver or similar card, one of these chipsets is in it. These cards are very stable and support monitor mode as well as packet injection; the only downside is the lack of 802.11g support.
When it comes to prism chipset version numbers, do not assume that bigger means better. Though it seems every driver that supports prism2 also supports prism2.5, such is not the case with the prism3. prism3 is a prism2.5 with more hardware cut out. Though most drivers that support the prism2/2.5 can and do work with a prism3 card, you can't assume they will work. In particular, Kismac's passive drivers have trouble recognizing and using prism3 chips.
Symbol Spectrum24 chipsets are based on prism2. They are less prolific than their prism2 counterparts, and unless you have a particularly old card you probably don't have one. Again, these are limited to 802.11b. Symbol cards offer no real advantage over prism2 cards. If you have one of these cards lying around, however, you can use it with the host-ap driver to obtain monitor mode support.
The Cisco line of 802.11b Aironet cards are also based on the prism2 chipset with some changes. The changes are extensive enough to preclude stock prism2 drivers from working with the chipset. These cards are known for their excellent sensitivity and can generally be found with desirable antenna configurations. Different models/driver combinations support monitor mode, but none have support for packet injection. In the past, these were pretty desirable cards, but there are currently better solutions. If you are solely interested in a card with great (802.11b) reception though, consider one of these.
Cisco also sells an a/b/g card with the Aironet brand, usually called Aironet a/b/g. Currently, most a/b/g cards on the market use an Atheros chipset, and this is no exception. While this card has a very high quality built-in antenna, it lacks an antenna jack. If you are looking for a high-end a/b/g card and are willing to spend the kind of money Cisco wireless equipment costs, go check out the Ubiquiti Networks SuperRange Cardbus a/b/g 300mW card instead.
PrismGT is a follow-up chipset to the popular prism line. This version supports 802.11g. The level of support for this chipset under Linux is nowhere near its 802.11b counterparts, largely due to money-saving techniques implemented by various card vendors to push responsibility for MAC into software. (Think cheap $20 reincarnated software-based modems.) Pushing functionality into software isn't necessarily a bad idea, it just seems like this time it was poorly done as the driver writers had a hard time implementing it.
There is a native Linux driver available, called prism54, and it does offer support for monitor mode and packet injection. Unfortunately, it currently only works with PCI and USB cards (not PCMCIA). If you already have a USB card with this chipset, you may be in luck. Despite its monitor mode support and its packet injection capabilities, this is one of the last chipsets I would seek out if I were buying a new card for use in Linux. On the upside though, Kismac and GTDriver support it on OS X.
Broadcom was one of the first vendors to market with an 802.11g chipset, allowing them to gain quite a foothold in the market. This is unfortunate, because these chipsets are totally proprietary and Broadcom easily deserves the "least useful to open-source driver developers" title. The most likely Broadcom chip you will run across is the popular bcm4318. If you have a new laptop and it doesn't have a Centrino (aka Intel pro wireless) chip inside, odds are it's a Broadcom chip. Apple's airport extreme card on PowerPC platforms uses a Broadcom chip. Broadcom chips are also used in PCMCIA devices, but you are unlikely to get one without knowing it, as they are fairly rare. One easy way to tell if a PCMCIA card uses a Broadcom chip is if it advertises some sort of 125 Mbps technology featuring Broadcom's "standard-plus" technology.
A native Linux driver for these chips does exist (bcm43xx), but it very hard to get it working. The driver seems to be under heavy development and maturing, but it is unlikely that even then this chipset will be much use to anyone interested in wireless security. Don't buy a card with a Broadcom chipset. Even if your laptop has one built in, buy a different card.
Atheros has created an extremely popular software-defined 802.11 chipset. This means the card's behavior can be tightly controlled with software. Unlike the prismGT case, which seems to have caused driver writers quite a bit of frustration, this time the software was well implemented, largely due to Atheros' support.
Atheros has been pretty friendly toward open-source developers. However, by law they are required to keep certain aspects of their product secret since it is a software-defined radio. If you know how, you could violate FCC specs with this chipset just by programming it correctly. This closed-source layer is called the Hardware Abstraction Layer (HAL). On top of this a very usable Linux driver has been created called MadWifi. Atheros chipsets have very solid support across all the major operating systems and support monitor mode and injection. On OS X, Kismac also has support for passive scanning with Atheros cards.
Ralink is one of the smaller 802.11 chipset manufacturers. I have never run across a laptop with a Ralink chipset built in. This is unfortunate because Ralink has excellent open-source support and the cards I have used seem to be very stable. Ralink has quite a few families of chipsets. The one most people are interested in, however, is the rt2500b/g family. The rt2500 family of chips has solid support under Linux for monitor mode and is one of only two drivers that supports packet injection unpatched. USB-based devices with an rt2570 make a good choice for a second injection-only interface on Linux. This is one of the few hassle-free USB-based cards that you can come by easily.
Centrino (or IPW) chipsets are currently only available in mini-PCI cards. If you have one, it's probably because it came with your laptop. The 2100 family is b only, 2200 is b/g, 2915 is a/b/g, and 3945 is a/b/g. Drivers for these chipsets all contain support for monitor mode and seem to be stable. Support for injection is unavailable and probably not expected any time soon. One feature unique to the 2200 and 3945 is something that Kismet calls livetap. Basically, you can be connected to an AP, but still see all the packets on the current channel as if you were in monitor mode.
If you have a Centrino chipset built in and don't plan on using any attacks that require packet injection, you may be able to get by with one of these. Intel does support the Linux driver projects and is responsible for one (of the unfortunately many) 802.11 stacks for the Linux kernel. These cards are generally well supported under Linux, and Intel deserves some credit for helping with the driver development; they just aren't well suited to wireless hacking.
So which chipset should you get? If you are looking for a card that is (relatively) future proof and that supports injection, a chipset from Atheros is never a bad idea. While there are few known attacks that require modification to the card's MAC, it is a good bet that more attacks are on the way. Atheros cards have the most exposed dials to tweak, and for hacking this can never be a bad thing. Ralink comes in a close second here; only time will tell if anything that can be done with an Atheros chipset can also be done with a Ralink. If you have an old prism2 card lying around, or you get a good deal on a used one, they are still useful. As more advanced techniques based around timing and bending the rules of the MAC become well known, prism2 cards will start to show their age.
Now that the chipsets have been laid out and you have selected one, it's time to determine which card to get. One of the most frustrating processes involved in purchasing wireless cards is to do all the research, find just the right card, order it, and then discover you've got a slightly different hardware revision with an entirely different chipset. In fact, the only similarity between the card in the box and the piece of hardware you paid for is the flashy vendor sticker on the outside.
Unfortunately, this happens all the time, and there is very little you can do about it (except order from a store with a no-hassle return policy.) There are various websites that attempt to track these things, and they can be used as a good starting point. One of the most useful is a list of cards that are known to have Broadcom chipsets in them. This is a good list of cards to avoid and is always worth double-checking before buying a card. The maintainer of this list (at broadcom.rapla.net) also seems to keep lists of other popular chipsets as well. Two other lists are maintained by SeattleWireless and AbsoluteValue systems (the maintainers of the wlan-ng driver). The AbsoluteValue systems list is a little out of date but still useful. The SeattleWireless list is very large, but sometimes inaccurate, and the quality of information varies from month to month because it is implemented as a wiki. The rapla.net lists, however, seem to be accurate and well maintained. Following are the URLs of a few of these lists:
http://www.broadcom.rapla.net/ (Broadcom list, cards to avoid)
Browsing these lists is a good starting point for selecting a card. Before shelling out your hard-earned dollars on a card that someone else says works great, keep reading to see what makes one card stand out from the rest.
Transmit (Tx) power, of course, refers to how far your card can transmit and is usually expressed in milliwatts (mW). Older Orinoco silvers measured in at 30 mW (+14.8 dBm). High-end Senao's can be found at 200 mW (+23 dBm). There is even a very high-end Atheros-based card with 300 mW (+24.8 dBm) of Tx power. While Tx power is important, don't forget to consider it along with a given card's sensitivity.
A common mistake is to go out and buy the card with the highest Tx power number you can find. If you have a card that is significantly mismatched, you will end up being able to transmit packets over a distance considerably greater than that over which you can hear the return traffic. Generally speaking, you are more interested in receiving data than transmitting it (though there are special cases where you may only want to transmit data as far as possible).
One reason that sensitivity is overlooked is that reliable sensitivity data for a given card can be very hard to come by. Sometimes vendors don't mention it at all. Quite often the best you can do is determine that card X is more sensitive than Y, which is more sensitive than Z, but putting hard numbers on sensitivity can be difficult. That said, if you can get hard numbers on sensitivity, here are some things to remember.
Sensitivity is usually measured in dBm (decibels relative to 1 mW). The more negative the number the better (–90 is better than −86).
Typical values for sensitivity in average consumer-grade cards are −80 dBm to −90 dBm.
Each 3 dBm change represents a doubling (or halving, if you are going the other direction) of sensitivity. High-end cards get as much as −90 to −96 dBm of sensitivity.
If you find you need to convert milliwatts into dBm, don't be scared. Power in dBm is just ten times the base 10 logarithm of the power in milliwatts. Here's the formula:
10 x log 10(Mw) = dBm
The last thing to consider when deciding which card to purchase is antenna support. What sort of antenna support does it have and do you need an antenna to begin with? If you simply want to poke around your neighborhood, you may be able to get by without an antenna. If you are seriously interested in seeing what is going on around you though, an antenna is a very smart investment. If your job is to secure or audit a wireless network, you will definitely want to get one or two, so you can accurately measure how far the signal leaks to outsiders.
Cards come either with zero, one, or two antenna jacks. While two jacks might seem excessive at first, two jacks allow the useful combination of an omnidirectional antenna with a directional antenna (more on these in the "Antennas" section). Cards are connected to antennas via cables called pigtails. The pigtail's job is simply to connect whatever sort of jack exists on your card to whatever sort of jack exists on your antenna.
Unfortunately, there are more than a few connection types. What's worse is that this problem is multiplied if your antennas have different interfaces. Consider the scenario where you have two cards with different jacks and two antennas with different connectors. You will need a total of four pigtails to be able to connect each card to each antenna.
Fortunately, most antennas come with a particular connector, called the N-type. In particular, antennas usually have a female N-type connector. This lets friends loan each other antennas without worrying about cables to convert between different antenna types. There are other antenna connection types (RP-TNC is also fairly popular among AP vendors), so be sure to check before you assume an antenna has an N-type connector. Details on different antenna types and various connector standards will be covered in the "Antennas" section. Figure 4-4 gives an example of a typical pigtail setup.
The individual connector type on a given card is fairly unimportant. As long as a card has a jack of some type, you will be able to find a pigtail to connect it to an antenna. If you are going to buy more than one card, however, it may be worth trying to standardize on a particular connection type.
Drivers are the code that bridges the gap between the operating system and hardware. Drivers are tied to chipsets. Most drivers can drive more than one chipset. This is because chipsets (like software) are oftentimes released with different revisions or versions. A set of similar chipsets is generally called a chipset family. Examples of chipset families are RT2500 and bcm43xx.
There are three very desirable features for any wireless driver. Clearly, the most important of these is monitor mode (discussed previously in the "Passive Scanning" section). Two other features that require driver cooperation are prism headers and packet injection. Packet injection refers to the ability to transmit (mostly) arbitrary packets. This ability is what allows you to replay traffic on a network, speeding up statistical attacks against WEP. It is also what allows you to inject deauthentication packets, packets that are used to kick users off an AP. We'll discuss packet injection first.
Packet Injection Packet injection was first made possible some time ago with a tool released by Abaddon called AirJack. AirJack is a driver that works with prism2 chips and a set of utilities that make use of it. In the few years since AirJack's invention, quite a few patches for other chipsets have surfaced, and now most drivers can be coaxed into injecting your packets as well. aircrack (a tool to attack WEP-encrypted networks) maintained a set of relevant patches for some time. Very recently, however, a much better tool called LORCON (Loss Of Radio CONnectivity) came along.
LORCON is a library that any C/C++ program on Linux can use to inject packets. Tools that use LORCON to inject packets are insulated from any quirks of the device driver/chipset being used. Tools that use LORCON will also not need to be modified if an improved chipset comes out that supports injection. LORCON currently comes with a set of patches for host-ap, wlan-ng, prism54, MadWifi, rt2500/rt2570, and rtl8189. Tools that use LORCON for packet injection will be useful for much longer than those that don't.
Prism Headers Prism headers are a clever way some drivers allow you to view "out-of-band" data about a given packet. For example, there is no field in an 802.11 packet labeled signal-strength. However, that is exactly what you may need to know. Drivers that support prism headers will prepend a fixed-length structure to the real packet before pushing it out to the user. Tools that know how to read this data can gather useful statistics about each packet. A quick way to check if the driver you are using supports prism headers is to run tcpdump on the interface while it is in monitor mode. If you see something similar to the following, your driver is prepending prism headers:
[root@phoenix:/home/johnycsh]$ tcpdump -i wlan0 tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type PRISM_HEADER (802.11 plus Prism header), capture size 96 bytes
Wireless Extensions Another feature worth mentioning with regards to Linux wireless drivers is the support of wireless extensions. Drivers that use wireless extensions can all be configured by the generic iwconfig / iwpriv commands. Drivers that don't come with wireless extensions each come with their own quirky tools requiring a different set of commands. Most modern drivers use wireless extensions; there are some stragglers, however, that opt not to (wlan-ng, for example). MadWifi-ng also uses a special tool for most of its configuration.
 |
Currently, I use the Linux 2.6.11 kernel with SMP, APIC, and Preempt all turned off for my wireless needs. The explicit disabling of these features makes the wireless driver's life easier. The choice of 2.6.11 might seem odd since it is neither the most recent nor the older 2.4 branch. There are two reasons for this. In the 2.6.13 version of the kernel, the PCMCIA architecture changed significantly. Previous to this version, PCMCIA support was never well integrated, and the motivation was to finally bring PCMCIA into the fold. Though I'm sure this is better in the long run, it made for some hard-to-track-down issues when working with patched wireless drivers. It also required the installation of two different (but similar) userland PCMCIA tool packages.
In the 2.6.15 version, support was added for a generic 802.11 stack. The idea is to help all the 802.11 device driver writers by providing a set of debugged, driver-agnostic code to help out with certain things all drivers need (such as encryption and authentication). The problem that arises is that there are now three incompatible stacks: the original stack included in the 2.6.15 kernel, an extended version of the original stack called SoftMAC, and an external stack called devicescape. Note that SoftMAC is used in the bcm43xx driver and that devicescape is maintained outside the main kernel tree but includes most features.
Of course, merely having the code included in the kernel doesn't cause any harm unless it's actually compiled and turned on. But by using a kernel that doesn't even support this, you can avoid accidentally enabling it for a driver and falling into the trap of keeping track of which driver needs what version.
To make matters worse, there is currently little consensus as to which stack to use in the future. Though the long-term plans currently seem to be to move everyone onto the devicescape stack, this is going to take awhile, and not everyone is happy about it. Currently, almost every wireless device driver has its own stack. If there is ever a single stack to rule them all, I would suggest embracing it enthusiastically. Such a state is probably years away though. Until this issue is all settled, the last thing you want to do is keep track of it; therefore, I propose the following solution.
Until a single 802.11 stack exists, use a 2.6 kernel previous to 2.6.13 with one of the three drivers detailed in the following sections. A kernel from 2.4 should work, but there are no guarantees. The three drivers discussed in this section provide all the functionality you will need (monitor mode, prism headers, and injection support) across any desirable chipset. They also have support from LORCON.
|
host-ap provides support for many older cards in the prism2 family. host-ap was the first driver that let you use a laptop as an access point. Despite the AP in its name, host-ap supports managed mode as well as ad-hoc mode. If you have to use a prism2 or closely related chipset, I recommend this driver. LORCON has patches for quite a few versions, but 0.3.9 has been very stable for me. Releases of host-ap can be found at http://www.hostap.epitest.fi/releases/.
This driver is for the USB version of Ralink's popular rt25xx line of chips. If you want a USB-based card, get one with this chipset. The D-Link DWL-G-122 seems to have this chipset inside most times, but be sure to double-check. Unfortunately, the current beta release of this driver (v1.1.0-b1) doesn't support injection unpatched. You might want to see if there is a newer release; if there is, it will probably include support for injection. All of the recent CVS snapshots support injection out of the box, so you can always use one of these. In order to inject packets, you will probably need to issue the following command as root: iwpriv rausb0 rfmontx 1. Currently, the daily snapshot is available at http://www.rt2x00.serialmonkey.com/rt2570-cvs-daily.tar.gz.
MadWifi is the driver for Atheros 521x chipsets under Linux. There are currently two versions: -ng (next generation) and -old. All of the examples in this book use the -old branch. The -ng branch of MadWifi, while maturing quickly, is still more crash prone than the -old branch. The -old branch is also easier to configure. This specific version (20060124) of -old also doesn't require any patching for injection support, while other versions of -old do.
The easiest way to get this version of the driver is from subversion:
[root@phoenix:/root/drivers/madwifi]$ svn checkout -r '{20060124}'
http://svn.madwifi.org/branches/madwifi-old madwifi
By the time you read this, the -ng branch may have surpassed the -old branch, both in terms of features and stability. Fortunately, both branches have excellent support for monitor mode and injection (with LORCON). If you would rather try out the new features in -ng, it may not be a bad idea. If -ng turns out to be to unstable, you can always fall back on the -old branch.
Regardless of which branch you choose, this driver/chipset is definitely the most desirable combination. The biggest reason for this is that Atheros chipsets are software-defined radios. That makes these chips the obvious platform of choice for any advanced driver-patching techniques.
One of the more interesting projects related to MadWifi is the OpenHAL project. OpenHAL is attempting to reverse engineer a compatible HAL for Atheros cards. There are rumors that if you look at OpenHAL you can come up with a quick hack for MadWifi that will let you ignore many rules of the MAC. One obvious application of such a patch would be to inject packets at a much faster rate. If you hear about other new techniques that require hardware/driver cooperation, there's a very good chance that it will happen with this driver.
As mentioned previously, LORCON is the way forward for any tools that want to do packet injection on Linux. The cross-driver API is every wireless hackers dream come true. It has already been wrapped up for use in the development version of Metasploit (3.0) and will probably be ported to Windows. You can most likely expect every tool that needs to inject wireless packets to use LORCON in the future.
This section gives you a complete walkthrough on downloading LORCON and getting it to work with the madwifi-old driver. Currently madwifi-old is the most widely used driver for packet injection and is the driver used by most of the Metasploit developers as well. Before you attempt this, you should be able to download, compile, and install a stock kernel without help from your favorite distributions package manager. Though the following steps may work fine if you use your distribution to manage your kernel, usually they just get in the way. If you can't download and set up a 2.6.11 (or similar) kernel manually, you probably won't be able to diagnose any problems if the following steps go wrong.
First, you will need to delete any other copies of MadWifi you have installed. In this case, the kernel version I happen to be installing MadWifi on is 2.4.27. The same commands should work fine until you start getting into kernels with 802.11 stacks (starting with 2.6.13):
[root@phoenix:/home/johnycsh]$ rm /lib/modules/2.4.27/net/ath_* [root@phoenix:/home/johnycsh]$ rm /lib/modules/2.4.27/net/wlan_*
The previous commands will delete any modules that begin with ath_ and wlan_. It is probably safe to assume that no other drivers will use the same prefix as MadWifi does. If one did, however, the previous command would delete it. With that out of the way, it's time to install our own version of MadWifi.
First, you need to download a copy of the madwifi-old driver using the command referenced previously:
[root@phoenix:/home/johnycsh/drivers]$ svn checkout -r '{20060124}'
http://svn.madwifi.org/branches/madwifi-old madwifi
A madwifi/ath_hal
A madwifi/ath_hal/Kconfig
A madwifi/ath_hal/Makefile.kernel
A madwifi/ath_hal/Makefile
....
Once this is done, all you should need to do is cd into the MadWifi directory and type make. If you get an error at this point, either you don't have kernel sources installed, or your installed version of the Linux kernel is too old or too new.
| Caution |
Many people who are new to rolling their own Linux kernels forget to update the /usr/src/ linux symlink. This doesn't cause any problems until you start trying to compile kernel modules that are outside the Linux tree (such as MadWifi). The /usr/src/linux symlink should be a link to the kernel that you are trying to compile against. This is probably the kernel that you boot into by default. For example, if you want to inject packets using the MadWifi driver on a 2.6.11 kernel, make sure /usr/src/linux is a symlink to /usr/src/linux-2.6.11. |
[root@phoenix:/home/johnycsh/drivers]$ cd madwifi
[root@phoenix:/home/johnycsh/drivers/madwifi]$ make
Checking if all requirements are met... ok.
mkdir -p ./symbols
for i in ./ath_hal ./net80211 ath_rate/sample ./ath; do \
make -C $i || exit 1; \
done
make[1]: Entering directory '/home/johnycsh/drivers/madwifi/ath_hal'
...
If you don't get any error messages, then you have successfully built the MadWifi driver. The final step is to install it. A simple make install should suffice:
[root@phoenix:/home/johnycsh/drivers/madwifi]$ make install
for i in ./ath_hal ./net80211 ath_rate/sample ./ath; do \
make -C $i install || exit 1; \
done
make[1]: Entering directory '/home/johnycsh/drivers/madwifi/ath_hal'
...
make[1]: Leaving directory '/home/johnycsh/drivers/madwifi/ath'
At this point, you can insert your Atheros-based PCMCIA card and load the MadWifi driver. The system should recognize it.
[root@phoenix:/home/johnycsh/drivers/madwifi]$ modprobe ath_pci
[root@phoenix:/home/johnycsh/drivers/madwifi]$ iwconfig ath0
ath0 IEEE 802.11 ESSID:""
Mode:Managed Frequency:2.412 GHz Access Point:
00:00:00:00:00:00
Bit Rate:0 kb/s Tx-Power:20 dBm Sensitivity=0/3
If you get similar output from iwconfig (and no error messages from modprobe), you have successfully installed the correct version of MadWifi.
Downloading and Installing LORCON Getting the correct version of MadWifi installed is only half the battle. The next thing you need to do is download and install LORCON. This should be pretty easy, as LORCON is just a library like any other. The first step is to get a recent copy of it:
[root@phoenix:/home/johnycsh/drivers/madwifi]$ cd .. [root@phoenix:/home/johnycsh/drivers]$ svn co https://www.nycccp.net/svn/tx-80211
After that, a simple make, make install should get the job done:
[root@phoenix:/home/johnycsh/drivers]$ cd tx-80211/trunk [root@phoenix:/home/johnycsh/drivers/tx-80211/trunk]$ ./configure && make && make install
As usual, no error messages means it worked.
Downloading and Installing Airbase With a working driver as well as LORCON installed, it's time to try it out. The easiest thing to do is transmit a saved packet capture back into the air. To do this, you'll use pcap2air (a tool included in Airbase):
[root@phoenix:/home/johnycsh]$ wget http://www.802.11mercenary.net/code/airbase-stable.tar.gz [root@phoenix:/home/johnycsh]$tar -zvxf ./airbase-stable.tar.gz ./airbase-release-2.01/ ./airbase-release-2.01/ChangeLog ...
Once the tarball has been decompressed, it's time to build Airbase. Airbase actually consists of a single C++ library (airware) and a lot of programs that make use of it. First, you need to build the library:
[root@phoenix:/home/johnycsh]$cd airbase-release-2.01 [root@phoenix:/home/johnycsh/airbase-release-2.01]$cd libairware [root@phoenix:/home/johnycsh/airbase-release-2.01/libairware]$make && make install g++ -I./include -O3 -fno-strict-aliasing -c ./src/pcap-packet.cpp -o pcap-packet.o g++ -I./include -O3 -fno-strict-aliasing -c ./src/packet80211.cpp -o packet80211.o ...
Once the library has been built, it will be installed to /usr/local/lib/ libairware.a. Now you can proceed to build the rest of Airbase. In particular, pcap2air resides inside the tools directory. You can build all the tools as follows:
[root@phoenix:/home/johnycsh/airbase-release-2.01/libairware]$cd ../tools; [root@phoenix:/home/johnycsh/airbase-release-2.01/tools]$./build.sh && ./install.sh Building airware-test/ g++ -g -c -Wall -I../../libairware/include -Wno-deprecated airware-test.cpp -o airware-test.o ...
Airbase tries install as uninvasively as possible. This means all of the binaries end up inside /usr/local/bin/airbase, which probably isn't in your $PATH. You can either add it to your path or type out the full path to the executables. Following is an example of adding it to your path. You may want to place this in a startup script, such as ~/.bashrc.
[root@phoenix:/home/johnycsh$] PATH=$PATH:/usr/local/bin/airbase; export PATH
With that done, you can finally run the tools included in Airbase with ease. Let's start with pcap2air.
Testing with pcap2air Now that you have a driver installed that supports injection (MadWifi), as well as a library that assists in packet injection (LORCON), and a set of tools to take advantage of it (Airbase), let's see if everything is working. For now, you want to test your ability to transmit arbitrary packets. The easiest way to do this is to try to replay a saved packet capture. As you may have guessed, pcap2air does this.
The tricky thing about verifying packet injection is that it really takes another card (or a victim computer) to test it. Some versions of drivers act like they support injection, but really don't. This means if you run your injection program (pcap2air) on an interface like ath0 and run tcpdump on the same interface, tcpdump will see the packets but they won't actually hit the air, which can be very frustrating. Before you start trying to use any tools that support injection, you definitely want to verify that the packets are hitting the air.
There are two ways to do this. One is to run a sniffer on another box (or another interface in the same box, assuming you have more than one). Alternately, you can inject packets that would disconnect a box under your control and see if anything happens. For simplicity's sake, you are going to use pcap2air to launch a simple DoS against any networks on channel 1, just to see if it is working.
You will double-check that your victim machine (who is associated to a network on channel 1) loses connectivity. If he does, then everything is working, and you can use your new driver and toolset to do more interesting things.
Airbase contains a set of premade pcap files that can be useful to inject. These include Request To Sends (RTSs), Clear To Sends (CTSs), and so on. Let's change back into the root airbase directory for easy access to these files:
-i --interface Specify an interface name -r --driver Driver type for injection -f --filename Specify a pcap file contents for injection -c --channel Channel number -n --count Number of packets to send ...
It looks like pcap2air wants an interface on which to inject, a driver to use, as well as a filename and channel. As mentioned previously, the goal is to disrupt a network on channel 1, so you can verify the packets are really hitting the air.
The reason pcap2air needs to know the driver to use is because it can use any number of drivers supported by LORCON. In this case, the driver is MadWifi, and the interface is ath0. You are going to inject a Clear To Send (CTS) packet, which you'll get from the dist-pcaps directory of airbase. Doing this causes all of the stations on a given channel to wait for the target of the CTS packet to transmit, causing an effective DoS:
[root@phoenix:/home/johnycsh/airbase-release-2.01]$pcap2air -i ath0 -c 1 -r madwifi -f ./dist-pcaps/ctrl/cts.pcap -n 1 wrote -1 bytes: Error tx'ing packet. Is interface up?
Doh! We forgot to enable the interface first. Let's try again.
[root@phoenix:/home/johnycsh/airbase-release-2.01]$ifconfig ath0 up [root@phoenix:/home/johnycsh/airbase-release-2.01]$ pcap2air -i ath0 -c 1 -r madwifi -f ./dist-pcaps/ctrl/cts.pcap -n 1 pcap2air <johnycsh@gmail.com> wrote 10 bytes: Pcap:Length 10 DLT: IEEE802_11
Ctrl:ToDS:0 FromDS:0 retry:0 power_mgmt:0 more_data:0 Wep:0 order:0 subtype: CTS (0xC) [RA 00:0A:95:F3:2F:AB] [root@phoenix:/home/johnycsh/airbase-release-2.01]$
Looks like it worked this time. In order to make it a real DoS, you need to send a lot more than one packet though. Let's send 10,000 for now.
[root@phoenix:/home/johnycsh/airbase-release-2.01]$ pcap2air -i ath0 -c 1 -r madwifi -f ./dist-pcaps/ctrl/cts.pcap -n 10000
Output from running ping on a victim computer (one that happens to be on channel 1) is shown next. It should be very obvious when the DoS kicks in.
I:\Documents and Settings\Jon>ping -n 100 google.com Pinging google.com [64.233.187.99] with 32 bytes of data: Reply from 64.233.187.99: bytes=32 time=26ms TTL=241 Reply from 64.233.187.99: bytes=32 time=29ms TTL=241 Reply from 64.233.187.99: bytes=32 time=24ms TTL=241 Request timed out. Request timed out. Hardware error. Hardware error. Destination host unreachable.
Once the CTS packets quit transmitting, the victim will be able to transmit again. Looks like the packet injection is working. If you are interested in the details of why this particular DoS works, please see Chapter 6. Another fun thing to do with injection capabilities is to launch exploits against wireless drivers. Details on how to launch one of these attacks is covered in Chapter 11.
Sniffing Injected Packets It's important to remember that when you are injecting packets on an interface, the results you get when reading it really can't be trusted. It's quite possible that pcap2air told the driver to transmit 10,000 CTS packets, and if you were to run tcpdump on the attacking machine on the injecting interface, that's exactly what you would see. Another computer with an independent card in monitor mode, however, might see significantly less. You simply can't trust that every packet you send will hit the air, even if you read it back.
With that warning aside, it is certainly educational to peek at the packets you are injecting. To do this correctly, it's important to know how madwifi-old implements packet injection. There are actually two interfaces, ath0 and ath0raw. Although you specify ath0 to all LORCON-enabled tools, they are really using ath0raw under the hood.
tcpdump, however, doesn't know about this little quirk, so you need to keep this in mind when running it. If you were to run tcpdump on ath0 while pcap2air was transmitting its CTS packets, you might see something like this:
[root@phoenix:/tmp]$tcpdump -s 0 -c 10 -i ath0 02:13:12.541020 Acknowledgment RA:00:14:a4:2a:9e:58 02:13:13.070112 00:16:b6:16:a0:c7 sap 26 > 00:14:a4:2a:9e:58 sap c5 I (s=78,r=42,P) 02:13:13.420753 Probe Request () [1.0 2.0 5.5 11.0 18.0 24.0 36.0 54.0 Mbit] 02:13:13.421445 Probe Request () [1.0 2.0 5.5 11.0 18.0 24.0 36.0 54.0 Mbit] 02:13:13.861062 Acknowledgment RA:00:14:a4:2a:9e:58
The thing to notice is that there are no CTS packets mentioned in the output. This doesn't seem right, but ath0 doesn't see any of the packets that you inject. If you try using ath0raw, you get the anticipated results:
[root@phoenix:/tmp]$tcpdump -s 0 -c 10 -i ath0raw 02:20:51.081960 Clear-To-Send RA:00:0a:95:f3:2f:ab 02:20:51.084271 Clear-To-Send RA:00:0a:95:f3:2f:ab 02:20:51.089779 Probe Request () [1.0 2.0 5.5 11.0 18.0 24.0 36.0 54.0 Mbit] 02:20:51.090103 Clear-To-Send RA:00:0a:95:f3:2f:ab ...
The moral of the story is that if you want to get a capture of the packets that absolutely hit the air while you are injecting, you're going to need a second card. If you are just poking around to see what probably hit the air, you can sniff on ath0raw and see all the packets that you inject as well as anything else in the air. Sniffing on ath0 won't show you any of the packets that you inject.
There is no lack of drivers on Windows, just a lack of interesting ones. For a driver to be considered "interesting," it must do something other than get you online. The most useful thing is monitor mode, followed up by packet injection support. This section lists three interesting drivers. There are more hacked-up prism2 drivers out there as well, but the newer chipsets these drivers cover are more useful.
Unfortunately on Windows, there is pretty much a one-to-one relationship between programs and drivers. With the exception of AirPcap from CACE, every driver mentioned here was created with a single program in mind. The only example of a third-party program using one of these is the Windows version of aircrack. Hopefully, more programmers will start to take advantage of these drivers in the future; however, licensing agreements may interfere with this.
WiFiME rt2560 Custom Driver This driver is unique among the Windows drivers because a company selling a product did not create it. In fact, it was created much to the chagrin of a very large corporation (Nintendo). Nintendo DSs have integrated support for wireless, but they are not Wi-Fi or 802.11 compliant. That means they play by the rules only enough to get by and talk to other wireless devices.
It also means that to get a DS's attention (for example, to upload a game), you need to be able to transmit raw packets. The WiFiMe driver was created to let Windows users upload game demos to their DSs using a Ralink rt2500/2560 chipset. The author of this driver, Tim Schuerewegen, has published an example program showing how to send raw packets, but nobody else has used it to develop any other tools. Note that this driver currently does not support popular rt2570 USB-based devices.
WildPackets Atheros Driver WildPackets sells a product called AiroPeek (which is detailed in Chapter 5). It comes bundled with a driver that allows you to place an Atheros card in monitor mode and inject packets. The version of aircrack for Windows can use this driver.
TamoSoft Atheros Driver TamoSoft sells a product similar in scope to AiroPeek. It too comes with a driver that will let you place an Atheros card in monitor mode and inject packets. The TamoSoft application (CommView for Wifi) even supports crafting of arbitrary packets. The reason that aircrack supports the WildPackets' driver instead of this one is probably because AiroPeek is a more well-known product.
CACE Technologies AirPcap CACE recently released a USB dongle with drivers on Windows that support 802.11 monitor mode. CACE has gone out of their way to get support for this driver on various open-source tools, including Wireshark and Kismet. The only downside to using this is that you need to buy a specific adapter (from CACE) that is supported by the driver. Currently these adapters cost almost $200, which makes a Linux box look much more economical.
Though there is no code to take advantage of it available yet, support for packet injection is well on its way. Once the driver is released with packet injection available, LORCON will add support for it. Once LORCON has support, all sorts of utilities previously available only to UNIX platforms will be able to work on Windows with little modification.
Finally, it should be mentioned that with the release of Windows Vista, the networking stack was significantly reworked under the hood. It seems reasonable to expect that drivers supporting packet injection may start appearing on Vista fairly soon.
There are quite a few different types of 802.11 antennas on the market. If you have never purchased or seen one before, all the terminology can be quite confusing. Before getting started, there are some basic terms to cover. An omnidirectional antenna is an antenna that will extend your range in all directions. A directional antenna is one that lets you focus your signal in a particular direction. Both types of antennas can be quite useful in different situations.
If you have never used an antenna before, don't go out and buy the biggest one you can afford. A cheap mag-mount omnidirectional antenna can yield quite useful results for $20 or $30. If you can, borrow an antenna from a friend to get an idea of how much range increase you need; that way, you'll know how much money to spend.
If you are mechanically and electrically inclined, you can build cheap waveguide antennas out of a tin can for just a few dollars. The Internet is full of stories of rickety homemade antennas getting great reception. It's possible that yours will, too. Of course, it's just as likely you'll spend hours in the garage with nothing to show for it except a tin can with a hole in it and 1 or 2 dBi of gain with a strange radiation pattern. However, if this sounds like a fun hobby, there are plenty of guides out there.
Finally, a reminder on comparing antenna sensitivity: Antenna sensitivity is measured in dBi. Doing casual comparisons of dBi can be misleading. Don't forget: an increase of 6 dBi in antenna gain is the same as doubling the antenna's effective range. An antenna with 15 dBi of gain will increase your range to about twice that of an antenna with 9 dBi of gain.
There are quite a few different types of antennas, and entire PhD dissertations are regularly written on various techniques to improve them. This is not one of them. This section is designed to give you practical knowledge to choose the correct antenna for the job at hand.
Antennas are not magic, nor do they inject power into your signal. Antennas work by focusing the signal that your card is already generating. Imagine your card generating a signal shaped like a 3D sphere (it's not, but just pretend). Omnidirectional antennas work essentially by taking this spherical shape and flattening it down into more of a circle, or doughnut, so your signal travels farther in the horizontal plane, but not as far vertically. More importantly, the higher the gain of the omnidirectional antenna, the flatter the doughnut. Directional antennas work in the same way; you sacrifice signal in one direction to gain it in another. An important idea to remember is that the theoretical volume of your signal remains constant; all an antenna can do is distort the shape.
As already mentioned, omnidirectional antennas increase your range in a roughly circular shape. If you are driving down the street looking for networks, this is probably the best tool for the job. In some cases, you might want the ability to direct your signal with precision. This case is when a directional antenna is handy. The range a directional antenna covers is measured in beamwidth. Some types of directional antennas have a tighter beamwidth than others. The tighter the beamwidth on a directional antenna, the more focused it is (just like a flashlight). That means it will transmit farther, but it won't pick up a signal to the side of it. If the beamwidth is too narrow, it's hard to aim. Examples of directional antennas include grids, yagis, and waveguides. Typical beamwidths for grid antennas are 5–12 degrees. Beamwidths for yagis and waveguides are commonly 30.
Every wireless hacker needs at least one omnidirectional antenna. These come in basically two flavors, 9–12 dBi base-station antennas and magnetic mount antennas with 5 or 6 dBi of gain. The magnetic mount antennas are designed to stick to the top of your car, the base-station antennas are designed to be plugged into an AP.
The base-station antennas usually come in white PVC tube and are usually 30 or 48 inches in length. The longer the antenna, the higher the gain, and the more expensive it is. When war driving, the magnetic mount type generally gives better reception than the base-station antennas, despite the lower gain, because they aren't in the big metal box that is your vehicle. If you want to use an omnidirectional antenna in an office building, however, the 12 dBi gain base-station type will give significantly better results.
Next on your list should be some sort of directional antenna. By far the most popular are cheap waveguide antennas (sometimes called cantennas). A typical cantenna gets 12 dBi of gain. A step up from the average waveguide antenna is a yagi. Yagis are easy to find in 15 and 18 dBi models, though they tend to cost significantly more than a waveguide antenna.
One of the easiest places to lose a signal is in the pigtails. The longer the cable, the more signal it is going to lose. More important than length, however, is the quality of the cable and the connection it makes with the card. Basically, don't buy cheap pigtails. There's not a lot to these things. If somebody can sell the same pigtail for half the price as the other guy, they are probably skimping on cable quality, workmanship, or both. If you are looking for a place to get quality pigtails, both http://www.jefatech.com and http://www.fab-corp.com always seem to provide quality products.
A list of common connector types and the vendors that use them is in the next table. Just because vendor X generally uses connector Y, however, doesn't mean they always do or will. Vendors have been known to switch out entire chipsets without changing the model number of a card. So don't think that they wouldn't change the antenna connector as well. If a vendor seems to consistently favor one connector, just a name is given. If a vendor uses more than one, more details are provided. Of course, just because a vendor is listed doesn't mean every card they manufacture supports an external antenna.
|
Connector Type |
Vendor |
|---|---|
|
MC |
Buffalo, Dell, IBM, |
|
MCX |
Apple (Power Mac G5 only, not the laptops) |
|
MMCX |
Cisco Aironets: AIR-LMC35X, 3CRWE747A |
|
U.FL |
Engenius: NL-2511MP, NL-3054CB, NL-3054MP |
|
RP-MMCX |
SMC: SMC2555W-AG, SMC2532W-B, SMC25122-B |
The vendor is your best source for determining what sort of connector a particular card has. However, if you are trying to search for a card given a specific connection type (maybe because you already have a few pigtails to match), most vendors' websites are useless. In these cases. many of the online wireless stores that sell antennas, pigtails, and so on, maintain databases that can be conveniently searched.
RF amplifiers are pretty exotic tools and are outside the budget of the casual war driver. Often, it's more efficient to use a directional, high-gain antenna. If that's not enough, or if you are looking to spend a few hundred dollars on some wireless gear, here are the basic ideas to remember.
Amplifiers increase RF signal power by converting DC energy into RF energy, which means that they (a) require a power source, and (b) can be used in conjunction with high output cards and directional antennas to violate FCC regulations. Don't do this. If you aren't sure how to tell if you are within FCC regulations when using an amplifier, don't use one.
Put succinctly, there are transmit amplifiers (used for transmitting signals at high power) and receive amplifiers (used for amplifying weak signals). By themselves, these amplifiers can be used only for their stated purpose. In other words, if a transmit amplifier is connected to your setup, all you can do is transmit (because the amplifier by itself can't run backward). Sometimes amplifiers configured like this are called directional.
It is possible to purchase amplifier configurations that automatically switch between transmit and receive amplifiers depending on whether the wireless card is transmitting or receiving. These amplifiers are obviously more useful and almost definitely the type you would be interested in. Amplifiers that behave this way are called bidirectional. Any amplifier labeled as 802.11-compatible is probably bidirectional.
Finally, it should be mentioned that amps can be fixed or variable gain. Fixed-gain amps provide you with a constant boost in power. Variable gain amps let you change the amount of gain. For auditing purposes, variable gain is more desirable because you can figure out the smallest possible amp an attacker would need in order to pick up your network.
Many 802.11-scanning tools can make use of a GPS receiver. This allows the tools to associate a longitude and latitude with a given access point. If you are interested in finding that interesting network you picked up a week ago, this can be invaluable. If you are just a casual wardriver, or an IT administrator checking out his local turf, it can be overkill. One of the pleasant surprises of GPS receivers is that almost any receiver that can be hooked up to a computer will be able to talk a standard protocol called NMEA (National Marine Electronics Association). This means that if you get a GPS device that can talk through a serial cable, it will work across multiple operating systems without needing a device driver.
This section covers considerations to keep in mind when trying to choose GPS hardware. The details of various mapping utilities and integration into scanning tools is covered in the next chapter.
There are two categories of GPS receivers, mice and handhelds. A GPS mouse is a GPS receiver with a cable sticking out the back. A mouse can only be used with something else, like a laptop or PDA. Some GPS mice are weatherproof and designed to be attached to the roof of a car. Others are designed for less rugged use inside the vehicle. Typically, a GPS mouse has a USB connector, though other options including PS2 and Bluetooth are available. If you are considering a Bluetooth mouse, keep in mind that Bluetooth operates in the 2.4-GHz spectrum as well. Depending on antenna types, multipath, and all that other nondeterministic hoopla that makes wireless so fun, your mouse may interfere with your war driving. So I wouldn't recommend it.
Also, don't forget that if your GPS device has a USB interface, you will need some sort of driver to talk to it. If it has a generic serial port interface, you won't. If your laptop doesn't have a serial port (and who does anymore), the safest thing may be to get a GPS device with a plain-old serial out and USB-to-serial converter that is known to have quality drivers. This ensures you will be able to use your GPS receiver across any platform that your converter supports. If you only plan on using one operating system, however, make sure it supports your GPS device.
A receiver is what most people think of when they think of GPS-a little handheld (or dash-mountable) device that displays your location, preferably on top of a map. Receivers vary greatly in terms of features. Low-end receivers come with monochrome LCD screens and have few bells and whistles. High-end receivers are generally dash-mountable, have high resolution full-color displays, and come with navigation software and maps. Receivers vary in price from approximately $100 to as much as $1000. Mice tend to cost approximately $60. Most receivers do not come with a cable for connecting to your computer. Cables cost approximately $20, depending on devices and vendors.
As mentioned previously, if you are using USB to talk to your GPS receiver, you need a driver of some sort. If you have a Garmin GPS mouse, you probably need to compile-in support for it as a module. If you use a USB-to-serial converter, you need a driver for it as well. On a 2.6 kernel, both of these drivers are found under Device Drivers | USB | USB Serial Converter Support. Assuming you have configured everything correctly (see Figure 4-5), you should end up with some sort of character device in /dev from which you can read GPS information (for example, /dev/TTYUSB0 for KeySpan converter).
Getting your GPS device set up on Windows should be as easy as inserting the driver CD that your GPS mouse or USB-to-serial converter came with into your CD drive. For example, if you use a KeySpan USB-to-serial converter, your GPS device will show up on a COM port, as shown in Figure 4-6.
Getting GPS on Macs to work is easy if you use a USB-to-serial converter with supported drivers. After installing the drivers bundled with the same KeySpan converter used in the previous section, a new device is created in /dev whenever the converter is plugged in:
[ johnnycache@galadriel:~ ]$ ls -l /dev/tty.KeySerial1 crw-rw-rw- 1 root wheel 9, 6 Mar 14 21:23 /dev/tty.KeySerial1
Now that your GPS hardware is configured, it's time to start using the software that talks to it.
|
|
