|
The first goal is detection. Can we tell when someone powers on a card within range of
the local network? This can be done with off-the-shelf components and free software.
The Cisco Aironet driver included with the more recent Linux kernels supports "RF
Monitor" mode, which permits promiscuous monitoring of 802.11 packets -
specifically, monitoring raw 802.11 frames to detect if there are any telltale frames
broadcast by a rogue access point or card.
As outlined in the original 802.11 specification, there are three classes of 802.11
frames. With the goal of detecting rogue access points and unauthorized wireless
ethernet cards, we are primarily interested in class 1 and 2 frames. Class 1 frames are
the only frames allowed in state 1, the unauthenticated state, and are largely
management frames used for authentication, beacons, and probe requests. Class 2
frames are allowed in both states 1 and 2, and are used for association and
reassociation. From access points, we would expect to see a large number of beacon
frames (Class 1). From unassociated Ad-hoc clients scanning in active mode, we would
expect to see a large number of probe requests (also Class 1). To test this hypothesis, a
method of monitoring all 802.11 management frames is needed, which the Cisco card
and Linux driver are capable of in "RF Monitor mode."
Setup
To put the card into RF Monitor mode, any BSS (use "Mode: r" for plain RF monitor
mode):
# echo "Mode: y" > /proc/driver/aironet/eth0/Config
#
Then, start logging packets with tcpdump, saving them to a file for later analysis with
ethereal:
# tcpdump -i eth0 -s 0 -w capturefile
#
Unauthorized Ad-hoc network
The first test was to confirm the ability to detect a WLAN card being powered on. A
Lucent Orinoco card was configured in Ad-hoc mode on a Win2k laptop, and turned on
to find out if there were any characteristic frames sent out by the Orinoco card when it
was put into Ad-hoc mode.
After the card initialized, tcpdump was stopped, ethereal started, and the capture file
opened. A large number of probe requests from the Orinoco card were found,
confirming that it was indeed possible to detect when someone within close range had
powered up a wireless ethernet card in ad-hoc mode.
The dissected frame was as follows:
IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0x0040
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode
(To DS: 0 F .... .0.. = Fragments: No fragments
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source address: 00:02:2d:1b:51:ca (Agere_1b:51:ca)
BSS Id: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Fragment number: 0
Sequence number: 118
IEEE 802.11 wireless LAN management frame
Tagged parameters (19 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 15
Tag interpretation: roguepeertopeer
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
0000 40 00 00 00 ff ff ff ff ff ff 00 02 2d 1b 51 ca @.......-.Q.
0010 ff ff ff ff ff ff 60 07 00 0f 72 6f 67 75 65 70 ..`...roguep
0020 65 65 72 74 6f 70 65 65 72 01 04 02 04 0b 16 eertopeer...
Indeed, it is possible to tell if someone starts an actively scanning card in ad-hoc mode,
and quite a bit of useful information can be gleaned from a single frame. Most relevant
are the SSID and the MAC address, since they can be used to track down a particular
card and/or person.
Unauthorized Access Point
The next test was to confirm the possibility of detecting a rogue access point. A
tcpdump session was started, and then a Cisco Aironet 340 access point was turned on.
After the access point had finished booting, the dump was examined with ethereal, and
a large number of beacon frames sent out by the access point were found. Following is
one such frame, again dissected by ethereal:
IEEE 802.11
Type/Subtype: Beacon frame (8)
Frame Control: 0x0080
Version: 0
Type: Management frame (0)
Subtype: 8
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode
(To DS: 0 From DS: 0) (0x00)
.... .0.. = Fragments: No fragments
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source address: 00:40:96:36:88:23 (Telesyst_36:88:23)
BSS Id: 00:40:96:36:88:23 (Telesyst_36:88:23)
Fragment number: 0
Sequence number: 0
IEEE 802.11 wireless LAN management frame
Fixed parameters (12 bytes)
Timestamp: 0x0000000000019274
Beacon Interval: 0.102400 [Seconds]
Capability Information: 0x0021
.... ...1 = ESS capabilities: Transmitter is an AP
.... ..0. = IBSS status: Transmitter belongs to a BSS
...0 .... = Privacy: AP/STA cannot support WEP
..1. .... = Short Preamble: Short preamble allowed
.0.. .... = PBCC: PBCC modulation not allowed
0... .... = Channel Agility: Channel agility not in use
CFP participation capabilities: No point coordinator at AP (0x0000)
Tagged parameters (31 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 18
Tag interpretation:
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0(B) 2.0(B) 5.5 11.0 [Mbit/sec]
Tag Number: 3 (DS Parameter set)
Tag length: 1
Tag interpretation: Current Channel: 11
Tag Number: 5 ((TIM) Traffic Indication Map)
Tag length: 4
Tag interpretation: DTIM count 1, DTIM period 2, Bitmap control 0x0,
(Bitmap suppressed)
0000 80 00 00 00 ff ff ff ff ff ff 00 40 96 36 88 23 ........@.6.#
0010 00 40 96 36 88 23 00 00 74 92 01 00 00 00 00 00 .@.6.#..t....
0020 64 00 21 00 00 12 00 00 00 00 00 00 00 00 00 00 d.!..........
0030 00 00 00 00 00 00 00 00 01 04 82 84 0b 16 03 01 .............
0040 0b 05 04 01 02 00 00 .......
Unauthorized Client
The final tested condition was unauthorized clients.
The first scenario considered (the more likely scenario), is that someone brings a
foreign card and powers it up with the wrong SSID. If the card was actively scanning,
probe requests would be seen from this card as it attempted to find an access point.
The second scenario is that someone brings a foreign card and powers it up with the
correct SSID. This one turns out to be a little more problematic to detect, in that there
will be only a few 802.11 management frames to trigger an alert, and then more
"normal" traffic. This is problematic primarily because of the way RFMON_ANYBSS
mode on the Cisco card works - despite its name, the card cannot receive packets
simultaneously from all BSS's in range, especially if those BSS's use different
frequencies.
The consequence is that it takes some manual intervention to sniff traffic from a
particular BSS - see the section below on "Problems and Complications" for more
details on this problem and how to work around it.
This problem was ignored and instead the focus was on the few 802.11 management
frames that do show up readily in the sniffer - both scenarios turned out to produce
similar probe requests, so both scenarios are treated as identical.
The dissected probe request sent out by this card:
IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0x0040
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode
(To DS: 0 From DS: 0) (0x00)
.... .0.. = Fragments: No fragments
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source address: 00:02:2d:1b:51:ca (Agere_1b:51:ca)
BSS Id: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Fragment number: 0
Sequence number: 1
IEEE 802.11 wireless LAN management frame
Tagged parameters (13 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 9
Tag interpretation: roguehost
Tag Number: 1 (Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
0000 40 00 00 00 ff ff ff ff ff ff 00 02 2d 1b 51 ca @.......-.Q.
0010 ff ff ff ff ff ff 10 00 00 09 72 6f 67 75 65 68 ......rogueh
0020 6f 73 74 01 04 02 04 0b 16 ost......
Problems and Complications
A few problems came to light with the Cisco card and driver that need to be
mentioned.
The first problem is that the Cisco card, by default, even in RFMON and
RFMON_ANYBSS modes, does not actively scan for traffic on all channels at all
times. The following are the conditions under which it will rescan for BSS's:
- When the card is first inserted.
- When the interface enters or leaves promiscuous mode.
- When synchronization with the current BSS is lost (due to interference, moving out
of range, or anything else that would cause the loss of a few beacon frames).
- When the /proc entry /proc/driver/aironet/eth0/BSSList is opened for writing ("touch
/proc/driver/aironet/eth0/BSSList" will do the trick).
All of these conditions will "kick" the card into rescanning. To build a practical
detection device, the card should be kicked at regular intervals, perhaps every minute.
A simple script to touch the BSSList file every minute will do the trick.
Second problem: Not all the BSS's in range showed up reliably in the file
/proc/driver/aironet/eth0/BSSList.
When the card is put into RFMON mode, transmitting is disabled, so the card cannot
scan actively for BSS's by sending out probe requests. Therefore, the card must use
passive scanning. Instead of sending out probe requests, the card listens for beacons.
Passive scans use a timer—the card will listen for beacon frames until the timer expires
and then move to another channel. The problem with the Cisco card is that this timer is
set too low. The default value is 40ms, which was insufficient on our test network to
notice all BSS's, regardless of the range or relative signal strength of the access points.
The solution was to add this line to the card initialization routine, setup_card, in airo.c:
cfg.beaconListenTimeout = 120;
Tripling this timeout made BSS detection work reliably. Consequently, all of our
access points showed up in BSSList, all the time.
Third problem: Despite its name, even putting the card in RFMON_ANYBSS mode did
not cause the card to receive traffic from all of our access points, which were all using
different frequencies and were probably synchronized differently.
The card itself chose a BSS to synchronize to base on its own algorithm (probably on
its assessment of the relative signal strength). The problem with this is that we want to
see traffic from all BSSs in range, not just those that happen to have the strongest
signals. A way could not be found to disable this feature on the Cisco card, but there is
a workaround - the Linux driver provides a /proc interface to set a preferred AP. Once
the list of BSSs in range of the scanner is found (/proc/driver/aironet/eth0/BSSList),
choose the one to monitor and enter the MAC address in the file
/proc/driver/aironet/eth0/APList. This will force the card to synchronize with that BSS
and switch to that channel, after which traffic from that BSS can be received and used
for signal strength assessments or monitoring for suspicious activity.
Conclusions
These simple tests confirm that there are 802.11 frames that are characteristic of
typical rogue access points and unauthorized ad-hoc networks, and that these frames
can be detected and analyzed using off-the-shelf components and free software.
Using these concepts along with a database of trusted access points and cards and the
fingerprints of suspicious frames, ethereal could be used as a fundamental building
block in a full-blown 802.11 intrusion detection system. | 
Disclaimer
