Previous Section  < Day Day Up >  Next Section

Active Scanning in Wireless Network Discovery

Active network discovery is implemented by Netstumbler and Mini-Stumbler, Windows tools most frequently used by casual wardrivers around the world. In fact, many mistakenly equate the terms wardriving and netstumbling (which is incorrect) and recommend Netstumbler for use by IT security professionals. As we show, this is not a good recommendation to follow.

Active scanning refers to sending a probe request frame and waiting for probe responses to come back. The received probe response frames are dissected to show the network ESSID, channel, the presence of WEP, signal strength, and supported bitrate.

Netstumbler is close source software and there was no official information about its internal workings available at the time of writing. However, H1kari from the Dachb0den Labs has investigated how Netstumbler does its scanning and implemented the same technique in dstumbler from the BSD-airtools suite.

Netstumbler appears to rely on a proprietary feature of the also proprietary hcf library provided by Lucent for Windows Hermes chipset card drivers, and apparently closed source wavelan_cs driver for Linux. Netstumbler sends a scan request to the client card, which is done by sending an inquiry command 0x11 to the card with 0xF101 as the parameter. This command instructs the card to send out probe requests and store data about hosts that respond. This method is handled asynchronously: When the 802.11 card has results, it sends an information event message "0x0080" to the interrupt handler in the driver. This is the same handler that takes care of other buffer reads such as receive or transmit. Information events are sent in a standard ltv structure made by length, code, and a data buffer, so a reverse engineer would look for ltvs with the 0xF101 code. These ltvs should have an array of structures that contain AP information resembling this:







struct wi_scan_res {

 u_int16_t  wi_chan;      /* dss channel */

 u_int16_t  wi_noise;     /* average noise in the air */

 u_int16_t  wi_signal;    /* signal strength */

 u_int16_t  wi_bssid[6];  /* mac address of the ap */

 u_int16_t  wi_interval;  /* beacon transmit interval */

 u_int16_t  wi_capinfo;   /* capability information (bits: 0-ess, 1-bss, 4-privacy [wep]) */

 u_int16_t  wi_ssid_len;  /* ssid length */

 u_int16_t  wi_ssid[32];  /* ssid (ap name) */

};

On the basis of this scheme, H1kari has concluded how a Netstumbler-like application can be written and proposed a cleaner implementation of such technique using Prism chipset cards:

  1. A scan request rid (0xFCE1) is sent to the card:

    




    

struct wi_p2_scan_req {

  u_int16_t  wi_chans;  /* channels to scan (bits: 0-chan 1, 1-chan 2, etc) */

  u_int16_t  wi_rates;    /* rate to send the probe requests at (bits: 0-1mbit, 1-2mbit,

graphics/ccc.gif 2-5.5mbit, 3-11mbit) */

};

  2. In half a second the card would be ready for the results query, readable from the scan result rid (0xFD88). The result buffer would be different because it would contain the Prism header info (ARPHRD_IEEE80211_PRISM). The frame would look like this:

    




    

struct wi_scan_res_hdr {

  u_int16_t  wi_rsvd;  /* reserved for something in the future (i think) */

  u_int16_t  wi_reason;  /* reason for the response (0 - error, 1 - response to a request

graphics/ccc.gif from the host) */

};

This is followed by an array of response frames similar to those of the Hermes / Lucent chipset cards:








struct wi_scan_res {

  u_int16_t  wi_chan;       /* dss channel */

  u_int16_t  wi_noise;      /* average noise in the air */

  u_int16_t  wi_signal;     /* signal strength */

  u_int16_t  wi_bssid[6];   /* mac address of the ap */

  u_int16_t  wi_interval;   /* beacon transmit interval */

  u_int16_t  wi_capinfo;    /* capability information (bits: 0-ess, 1-ibss, 4-privacy

graphics/ccc.gif [wep]) */

  u_int16_t  wi_ssid_len;   /* ssid length */

  u_int16_t  wi_ssid[32];   /* ssid (ap name) */

  u_int8_t  wi_srates[10];  /*  list of rates the ap supports, null terminated  (you'll

graphics/ccc.gif need to get rid of the last bit (& 0x7F) and divide by 2) */

  u_int8_t  wi_rate;        /* rate that the probe response was recieved at (0x0a - 1mbit,

graphics/ccc.gif 0x14 - 2mbit, 0x37 - 5.5mbit, 0x6e - 11mbit) */

  u_int8_t  wi_rsvd;        /* extra padding so it fits nicely into a 16-bit buffer */

};

H1kari has successfully implemented this methodology into dstumbler, even though dstumbler also supports RFMON mode sniffing. In addition, despite common confidence in Netstumbler being able to work with Lucent / Hermes chipset cards only, the latest version of Netstumbler works fine with Prism chipset cards, too. We verified this using a Netgear 802.11b PCMCIA card. Perhaps H1kari's research was taken into account by the Netstumbler developers.

Although sending a probe response frame on receiving the probe request is a normal access point behavior as described by the 802.11 standard, it is by no means necessary in terms of practical implementation. So-called closed networks would not respond to probe request frames. Besides, in some cases frames bearing ESSIDs known to be used by the Netstumbler and similar tools can be dropped or filtered out by a knowledgeable system administrator. Thus, not all networks would be properly discovered by the Netstumbler and Co. This is made worse by the fact that for a network to be discovered by the Netstumbler, it should first be reached by the probe request frame sent by the tool. This means you can only detect networks in the transmit range of your card, which is limited if compared to the range of a powerful access point linked to a high-gain antenna (did we forget to mention an amplifier?). A wardriver with Netstumbler can stay in the middle of the Fresnel zone of a long-range point-to-point link and yet not see it; the bridges are too far. Therefore, the higher the EIRP you have, the more networks you can discover with active scanning. The downsides of this are obvious:

  • You become easy to discover yourself (detection of Netstumbler users is discussed in Chapter 15 in detail).

  • You waste precious battery power and limit the time you can spend scanning.

In addition, don't forget that active scanning has nothing to do with sniffing and people calling Netstumbler a "wireless sniffer" should consider a serious review of wireless networking basics. Netstumbler or other similar tools do not log any wireless traffic, apart from the probe response frames, so they cannot be used for proper wireless traffic analysis and troubleshooting. It also means that using Netstumbler should be legal anywhere, because no traffic eavesdropping takes place and anyone can transmit in the ISM band as long as the FCC power limits are not exceeded.

For the reasons we have outlined, although convenient, easy to use, and well-interfaced with common GPS receivers, Netstumbler should not be the tool of choice for professionals or anyone who is serious about proper penetration testing and troubleshooting of wireless networks. Also, advanced Black Hats are unlikely to use any active scanning tool for 802.11 network discovery; they appreciate the value of stealth, distance, and time (battery power).

Of course, Netstumbler will and should remain a wardriving tool of choice for wireless amateurs not interested in discovering every single network in the area or providing professional wireless site surveying and security services. This is reinforced by the fact that Windows tools supporting the monitor mode and wireless protocols analysis are commercial and have a hefty price tag attached, whereas Netstumbler is free.

    Previous Section  < Day Day Up >  Next Section