Forum

For all of you who are still wondering how the Queensland attack works, here's proposed info from my ingenious friend Criss Hyde...(keep in mind that this is a shot in the dark)

On pages 134, 220, 225, and 227 of the CWAP Study Guide, we explain how the length field of the DSSS PHY header is used.

After reading these pages, note that 802.11b, section 18.2.3.5 says that the length field is a 16-bit integer. The length field is a period of time it will take to transfer the DSSS data octets. This means the maximum amount of time possible is 65,536 microseconds (~65 milliseconds).

Suppose further that you could cause a DSSS PC card to generate a frame (even an empty frame) that had a PHY header using a length field of 65 milliseconds. This would essentially be telling every station within hearing range that the medium is now busy and to defer.

The MAC addresses or data in the frame are meaningless in this scenario because the length field is part of the PHY header. You could use any MAC addresses you like and no data at all if you prefer. All that is needed is a way to generate a DSSS frame approximately every 65 milliseconds to completely shut down the RF medium within range of your transmitting PC card.

Now here's the trouble...you have to find a PC card that you can program directly. This usually requires a software development kit from the card manufacturer as I understand. Any feedback on how to implement this attack using either linux or windows would be greatly appreciated. I'm not a programmer.... :-(

Devinator

could not gather any more information than you already posted. something about a test mode-type feature that is dormant in most cards, yet can be activated for this attack. i could find nothing on how to actually turn that dormany feature on for the purposes of an attack.

More info on the QL attack....it seems that the basis of this attack stems from a diagnostics mode available in most cards. This diagnostics mode allows the mfr to set the radio to continuously transmit for the purpose of testing its output power and the like before it ships. This is purely a Quality Assurance mechanism....however, it seems that this functionality is not always removed from the firmware before shipping. Being able to access this continuous transmit feature, whether it's an 802.11a, b, or g radio, gives the user the ability to "jam" the RF medium. Last week's press release about data rates above 20 Mbps on 802.11g and all of 802.11a rates not being affected are BOGUS. It's simply not true. 802.11g radios use 802.11b rates for all kinds of things, such as fragmentation, protection mechanisms, etc. so regardless of the rate at which they attempted to transmit, they would be able to hear and understand DSSS transmissions. This would mean that they would be jammed as well. For 802.11a, it's no different. If an 802.11a radio were set to always transmit, then all other 802.11a radios in the area are jammed.

Having talked to CTOs and CEOs at two protocol analysis companies today about this, the HAL (hardware abstraction layer) is closed source code, and though it could be disassembled, this is a violation of their NDA and a big waste of time. Without being able to access commands that are part of the HAL, you cannot directly configure the transmit-only feature or the length field size in the PHY header.

I'm still digging for a loophole somewhere...stay tuned.

Devinator

All:

Please see IEEE 802.11 section 10.4.4, as modified by 802.11b and 802.11g, regarding DSSSTESTMODE.

Although ingenious, the theory I once put forward regarding the DSSS PHY length field appears to have nothing to do with the QL attack. My apology.

This DSSS "feature" will not be found in clause 17 PHYs, nor in clause 19 PHYs that use ERP-OFDM exclusively.

Thanks. /criss

You spend entirely too much time buried in the standards dude. I'll take a look at this section - I'm anxious to see what it says about this test mode. thanks for the info.

Devinator

All:

Above I said "This DSSS "feature" will not be found in clause 17 PHYs, nor in clause 19 PHYs that use ERP-OFDM exclusively."

More accurately, this DSSS feature will not be found in, nor affect in any way, clause 17 PHYs. Clause 19 PHYs will have the feature and could operate as the jammer. On the other hand, clause 19 PHYs that are configured to use ERP-OFDM exclusively will not see the DSSS jamming, and could try to transmit in spite of it, but will not likely communicate successfully.

Thanks. /criss

I've been working all day with engineers and executives in the know on this attack to implement it in Windows (because I'm not a Linux guy). The way I'm implementing the attack, I'm using a prism based card (DLink DWL-650 PCMCIA card) with the latest drivers from DLink. I've tried several other cards, and some partially work, some lock up, some do some really weird things. All of the "intermittently working" cards were Prism cards as well. I'm betting it's driver and firmware compatibility with the Prism Test Utility software I'm using to put the card in Continuous Transmit mode. The Prism Test Utility software was previously freeware, available through Intersil's website. There's still a number of available links on the web, such as at the Aerosol website, but they don't work anymore since Intersil's buyout and subsequent merge (now called Conexant). When enabling the Cont Tx feature, it completely slams the RF medium on the chosen channel by raising the noise level so high that nothing else will transmit.

When watching the attack on a protocol analyzer, you'll see beacons from your AP at first, then they slow to a crawl, then stop. The noise floor is VERY high and eventually disrupts all communication on the channel.

I'm thinking of making a .avi movie of this attack...what do you think? :-D