Airtun-ng is a virtual tunnel interface creator. There are two basic functions:
In order to perform wIDS data gathering, you must have the encryption key and the bssid for the network you wish to monitor. Airtun-ng decrypts all the traffic for the specific network and passes it to a traditional IDS system such as snort.
Traffic injection can be fully bidirectional if you have the full encryption key. It is outgoing unidirectional if you have the PRGA obtained via chopchop or fragmentation attacks. The prime advantage of airtun-ng over the other injection tools in the aircrack-ng suite is that you may use any tool subsequently to create, inject or sniff packets.
Airtun-ng also has repeater and tcpreplay-type functionality. There is a repeater function which allows you to replay all traffic sniffed through a wireless device (interface specified by -i at0) and optionally filter the traffic by a bssid together with a network mask and replay the remaining traffic. While doing this, you can still use the tun interface while repeating. As well, a pcap file read feature allows you to replay stored pcap-format packet captures just the way you captured them in the first place. This is essentially tcpreplay functionality for wifi.
Airtun-ng only runs on linux platforms and does support WDS if you have a pretty recent version (svn rev 1624?).
Usage: airtun-ng <options> <replay interface>
WDS/Bridge Mode options:
Repeater options (the following all require double dashes):
The first scenario is wIDS. Start your wireless card in monitor mode then enter:
airtun-ng -a 00:14:6C:7E:40:80 -w 1234567890 ath0
The system responds:
created tap interface at0 WEP encryption specified. Sending and receiving frames through ath0. FromDS bit set in all frames.
You notice above that it created the at0 interface. Switch to another console session and you must now bring this interface up in order to use it:
ifconfig at0 up
This interface (at0) will receive a copy of every wireless network packet. The packets will have been decrypted with the key you have provided. At this point you may utilize any tool to sniff and analyze the traffic. For example, tcpdump, wireshark or snort.
The next scenario is where you want to inject packets into the network. Do exactly the same steps as in the first scenario except define a valid IP address for the network when you bring the at0 interface up:
ifconfig at0 192.168.1.83 netmask 255.255.255.0 up
You can confirm this by entering “ifconfig at0” and checking the output.
at0 Link encap:Ethernet HWaddr 36:CF:17:56:75:27 inet addr:192.168.1.83 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::34cf:17ff:fe56:7527/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:192 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:25113 (24.5 KiB) TX bytes:516 (516.0 b)
At this point you can use any tool you want and send traffic via the at0 interface to wireless clients. Please note by default the FromDS flag is set. Meaning packets are flagged as going to the wireless clients. If you wish to communicate via the AP or wired clients, specify the option “-t 1” when you start airtun-ng.
IMPORTANT NOTE: The normal rules apply to injection here as well. For example, being associated with the AP, having the wireless card MAC match the injected source, etc. You have to remember to also set the at0 MAC address.
An interesting use of this scenario is that it allows you to use a WEP encrypted network with a driver that supports injection, but no WEP encryption, as not all drivers support 256bit wep or 512bit WEP keys or WPA (once it is implemented) and so on.
The next scenario is where you want to inject packets into the network but do not have the full WEP key. You only have the PRGA obtain via a chopchop or fragmentation attack. In this case you may only inject packets outbound. There is no way to decrypt inbound packets since you do not have the full WEP key.
Start your wireless card in monitor mode then enter:
airtun-ng -a 00:14:6C:7E:40:80 -y fragment-0124-153850.xor ath0
Notice that the PRGA files was specified via the “-y” option.
The system responds (notice it correctly states “no reception”):
created tap interface at0 WEP encryption by PRGA specified. No reception, only sending frames through ath0. FromDS bit set in all frames.
From here you can define a valid IP address for the network when you bring the at0 interface up:
ifconfig at0 192.168.1.83 netmask 255.255.255.0 up
You can confirm this by entering “ifconfig at0”. Again, at this point you can use any tool you want and send traffic via the at0 interface to wireless clients.
The next scenario is connecting to two wireless networks at the same time. This is done by simply starting airtun-ng twice and specifying the appropriate bssid MAC for each. If the 2 APs are on the same channel, then everything should be fine. If they don't share one channel, you can listen with airodump-ng on both channels (not simultaneously, but switching between only the two channels). Assuming the two APs you want to connect to are on on channels 1 and 11, enter “airodump-ng -c 1,11 ath0”.
So you'll get two tunnel interfaces (at0 and at1), each pointing to another AP. if they don't use the same private subnet range, then you can use them at the same time. IE You are connected to more than one AP. In theory, you could do this for even more then two APs, but the quality of the link would be even worse when hopping on 3 channels.
The next scenario is copying packets from the optional interface. The -i <wireless interface> is just like the aireplay-ng -i parameter. It is used for specifying a source to read packets from, other than the given injection interface (ath0 in the examples above). A typical use is to listen with a very sensitive card on one interface and to inject with a high power adapter, which has a lower sensitivity.
This scenario allows you to repeat all packets from one wireless card to another. This would allow you to extend the distance by which you could listen to the access point communication. The cards may also be on different channels which provides additional flexibility.
Prior to running the following command, you must use airmon-ng to put each card into monitor mode on the the appropriate channels:
airtun-ng -a 00:14:6C:7E:40:80 --repeat --bssid 00:14:6C:7E:40:80 -i ath0 wlan0
The system responds:
created tap interface at0 No encryption specified. Sending and receiving frames through wlan0. FromDS bit set in all frames.
At this point, any packets for the AP (00:14:6C:7E:40:80) from the ath0 interface will be repeated and sent out on the wlan0 interface.
You can replay any previous capture. The capture must have been stored in pcap format.
You enter the command:
airtun-ng -a 00:14:6C:7E:40:80 -r ath0one-01.cap ath0
The system responds:
created tap interface at0 No encryption specified. Sending and receiving frames through ath0. FromDS bit set in all frames. Finished reading input file ath0one-01.cap.
Please note that the file contents are transmitted exactly as is. You may ignore the message “FromDS bit set in all frames”. The flags nor any other field are modified while transmitting the file contents.
If you use a recent version of airtun-ng, you can use its WDS support to inject traffic into WDS networks and WiFi bridges. Bridges are pretty secure since traffic may be sniffed, but it is impossible to connect with them to send data into the networks. This is where airtun-ng comes into the game. With airtun-ng you can impersonate either of the two endpoints to interact with the other one. Lets assume you can only see one node of the bridge, this is how you can check if an attacker could inject traffic into this side of the network:
This is how to setup airtun-ng for this scenario:
airtun-ng -t 1 ath0 -h BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0
If you are able to see both sides of a WDS/Bridge network, you can enable bidirectional mode. This enables communication with both endpoint's networks. Be aware that bidirectional mode keeps track of clients behind each node in a list in memory, since it needs to know to which of the two endpoints it needs to send a packet to reach a certain client. If you use an embedded system, or there are large amounts of clients connected, this may slow down your machine.
airtun-ng -t 1 ath0 -h BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0 -f
WDS mode is fully compatible with WEP encryption, so you can use the -w and -y flags as usual. However, Repeater Mode hasn't been tested with WDS.
This tool is extremely powerful and utilizes advanced concepts. Please make sure you have built your knowledge and experience with the other tools in the aircrack-ng suite prior to using it.
You can also inject management and control frames. This can be done by putting a PCAP file together of frames to be sent, or just using a capture you made before and by replaying the whole file using airtun-ng.
Windows platforms - “I can't find the airtun-ng tool!”. Answer: airtun-ng only runs on linux.
When you run airtun-ng, you get a message similar to “error opening tap device: No such file or directory”.
Make sure you have the OpenVPN package installed and run:
This loads the “tun” module. You can confirm it is loaded by running “lsmod | grep tun”. If it does not load or there are problems, running “dmesg” and reviewing the end should show errors, if any.
See the following FAQ entry.