Forum

Hi:

I have a somewhat unique wireless analysis problem: We have an AirDefense wireless IDS. It was picking up Lucent APs on our network. The only problem is that we don't have any Lucent APs on our network. As it turned out, the problem was with a Cabletron/Enterasys RoamAbout wireless card that was sending out an incorrect BSSID. The AirDefense system mistakenly identified this device as a Lucent AP, when it's actually a Cabletron/Enterasys device. The NIC card it uses is actually a rebranded Lucent/Orinoco/Agere, so that's why it has that vendor code: It's an anachronism in the firmware on that card.

Now I'm trying to identify the offending device. We have Cabletron/Enterasys RoamAbout APs in this facility, but the MAC address of this misbehaving device does not match any of the Cabletron APs we have in production. This leads me to believe that it is possibly a client NIC card.

Sometimes AirMagnet thinks it's an AP, and sometimes it thinks it's a station. What I do know about it (according to AirMagnet and Airopeek) is that it

a) Doesn't send out any beaons
b) Only responds to probe requests
c) Its BSSID doesn't match its MAC address
d) The BSSID changes (increments) randomly.

Someone told me that this incrementing BSSID is ad-hoc station behavior according to the 802.11 spec.

I've tried to use my AirMagnet to locate the thing. The problem is that it doesn't talk much. It only sends out PROBE responses once in a while in response to PROBE requests. In any case, it's not enough to get a lock on it using the signal strength meter. It's probably a PCMCIA card in someone's laptop who doesn't regularly use wireless. The device goes away every night, and comes back every morning.

I need a way to force layer 2 traffic at it at a sustained rate, forcing it to respond so that I can use the signal strength meter on the AirMagnet to track it down. Kind of like a layer 2 PING.

I've looked into using Airopeek NX to craft a custom PROBE request that I could send it, but Airopeek doesn't allow you to generate command and control frames, only data.

Is there some tool that would allow me to do this?

Thanks.

Hi Mark:

Have you captured any one of the elusive probe response frames?

What is the transmitter MAC address and one or more of the BSSID's you have observed?

Thanks. /criss

I've captured a number of probe responses from this device:

Its MAC address is always

00:E0:63:50:80:06

While the BSSID always has a vendor prefix of

00:60:1d:*:*


Here is the actual packet:


802.11 MAC Header
Version: 0
Type: %00 Management
Subtype: %0101 Probe Response
Frame Control Flags: %00000000
0... .... Non-strict order
.0.. .... WEP Not Enabled
..0. .... No More Data
...0 .... Power Management - active mode
.... 0... This is not a Re-Transmission
.... .0.. Last or Unfragmented Frame
.... ..0. Not an Exit from the Distribution System
.... ...0 Not to the Distribution System

Duration: 258 Microseconds
Destination: 00:0B:CD:5C:42:27 Compaq:5C:42:27
Source: 00:E0:63:50:80:06 Cabletron - Yago Sys:50:80:06
BSSID: 00:60:1D:09:3B:00 Lucent:09:3B:00
Seq. Number: 3805
Frag. Number: 0
802.11 Management - Probe Response
Timestamp: 1920088267633 Microseconds
Beacon Interval: 100
Capability Info: %0000000000010001
x....... ........ Reserved
.x...... ........ Reserved
..0..... ........ DSSS-OFDM is Not Allowed
...x.... ........ Reserved
....0... ........ Robust Security Network Disabled
.....0.. ........ G Mode Short Slot Time [20 microseconds]
......x. ........ Reserved
.......x ........ Reserved
........ 0....... Channel Agility Not Used
........ .0...... PBCC Not Allowed
........ ..0..... Short Preamble Not Allowed
........ ...1.... Privacy Enabled
........ ....0... CF Poll Not Requested
........ .....0.. CF Not Pollable
........ ......0. Not an IBSS Type Network
........ .......1 ESS Type Network

SSID
Element ID: 0 SSID
Length: 7
SSID: xxxxxxx

Supported Rates
Element ID: 1 Supported Rates
Length: 4
Supported Rate: 1.0 (BSS Basic Rate)
Supported Rate: 2.0 (BSS Basic Rate)
Supported Rate: 5.5 (Not BSS Basic Rate)
Supported Rate: 11.0 (Not BSS Basic Rate)

Direct Sequence Parameter Set
Element ID: 3 Direct Sequence Parameter Set
Length: 1
Channel: 6

Agere Proprietary
Element ID: 128 Agere Proprietary
Length: 6
OUI: 0x00-0x60-0x1D
Number of clients: 9
Value: 0x3B00

FCS - Frame Check Sequence
FCS (Calculated): 0x6A621926

Mark:

To answer your first question about generating frames to provoke this volunteer device to produce enough probe responses to follow with AirMagnet, is not Netstumbler a producer of probe requests that would do the job here?

Could your volunteer be participating in an ad hoc network of peers without your IDS flagging the other peers? The probe response indicates this is not an IBSS, and the BSSID does not have the "locally administered" bit set (2nd least significant bit in the first octet) so this does not look like one peer in an ad hoc network.

Your observation about coming and going in sync with business hours is interesting. Might this be AP software running on a laptop? If operating correctly I would expect to see regular beacons from it.

It claims nine clients! Considering your IDS reports and the SSID of "xxxxxxx" can this be true?

I am sure someone else can find some still more useful detail in your data.

Thanks. /criss

Criss:

Thanks for your replies: I thought about using NetStumbler to try to provoke some response, since, as you point out, NetStumbler sends out Probe requests to locate APs. The problem is that NetStumbler does not see this device as an AP! All the expected APs in my area show up in NS, but not this device. AirMagnet lists it as an AP (sometimes). It could be that I'm physically too far away from the device when running NS, or that it just doesn't respond to NS Probe requests. The SSID of xxxxxx is my editing of my corporate SSID. The part about the 9 clients is really puzzling. It never has any stations associated with it. I've never seen it send out a beacon.

This is a specific instance of a more general problem I've encountered. Many times I'm trying to locate clients on the WLAN that AirMagnet flags as being misconfigured: No WEP key set. Wrong WEP key set. Wrong SSID set. No SSID set. All these stations generate traffic and set off security and performance alarms, but they generate so little traffic that they are impossible to physically locate using just a signal strength meter. There must be a technique or tool to find these misconfigured clients.

Thanks,
Mark

Mark:

Reminds me of the time I announced to my class that the live protocol analysis capture we were observing on the overhead would never show a value in the Address4 field because we had no Wireless Distribution System in place. Almost as soon as our attention was placed on that blank column a value popped up on one line, and then another a few screens later.

When we stopped and drilled into several of these packets we discovered that they were nonsense created by the analyzer as a best effort to decode corrupted frames!

Maybe your IDS is doing the same thing to you, creating phantom devices out of corrupted frames.

There must be someone else on the forum who has worked with such IDS deployments to confirm or deny this theory.

Thanks. /criss

I've requested that Tamosoft port their Traffic Generator function from CommView to CommView for WiFi as soon as possible. They said they'd look into it. That would be a slick tool for security audits, finding nodes, etc.

Check this website:

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.802.11b.html

It might offer some insight into this issue. It's a big webpage but has specifics on driver capabilities and ancestry.

Joel

I may be wrong, but it appears as though the below method would allow communications with an adhoc client and sustain this long enough using special ping or probe requests from the command line:

What I have seen via protocol analysis is that the RTS/CTS is a half duplex function. What I mean is that you can enable it on a single machine and the other machines will respond automatically with the CTS with no configuration involved. Thus only the machine with it configured will be able to reserve the carrier. I always thought you had to configure a pair of machines for RTS/CTS to function. Maybe for best performance for replies but that of course is determined on the app or error condition you are trying to overcome.

So, when I have RTS/CTS set on only one machine and send a ping to another in an ad hoc config. the sending(RTS/CTS configured) machine sends out the RTS and the non configured machine responds with a CTS, then the packet is sent, then the ACK.

Now when the non configured machines send back the ping reply it uses normal CSMA/CS DCF. No RTS for the return trip obviously because that machine is not configured for RTS/CTS.

I ran this test against two workstations in ad hoc mode one using a Cisco adapter(configured for RTS/CTS) and the non configured machine is using an Oronico Gold card.

I am presuming the same behavior happens with an AP in between for the RTS/CTS function seems more client MAC based in behavior.

You are right about the client thing being an on/off deal but it is also a packet size funciton also.

everything you said was accurate.

Devinator