airtun-ng
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
airtun-ng [2007/01/29 21:48] – better wep key example darkaudax | airtun-ng [2010/03/07 23:36] – Fixed typo darkaudax | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Airtun-ng ====== | ||
===== Description ===== | ===== Description ===== | ||
- | Airtun-ng is a virtual tunnel interface creator. | + | Airtun-ng is a virtual tunnel interface creator. There are two basic functions: |
+ | * Allow all encrypted traffic to be monitored for wireless Intrusion Detection System (wIDS) purposes. | ||
+ | * Inject | ||
+ | \\ | ||
+ | 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 [[http:// | ||
- | In order to perform wIDS data gathering, | + | Traffic injection can be fully bidirectional if you have the full encyption |
- | Traffic injection can be two bidirectional if you have the full encyption key. | + | Airtun-ng also has repeater and tcpreplay-type functionality. |
- | Airtun-ng only runs on linux platforms. | + | Airtun-ng only runs on linux platforms |
===== Usage ===== | ===== Usage ===== | ||
Line 13: | Line 18: | ||
| | ||
- | *-x nbpps : maximum number of packets per second (optional) | + | *-x nbpps : maximum number of packets per second (optional) |
- | *-a bssid : set Access Point MAC address (mandatory) | + | *-a bssid : set Access Point MAC address (mandatory) |
- | *-i iface : capture packets from this interface (optional) | + | *-i iface : capture packets from this interface (optional) |
- | *-y file | + | *-y file : read PRGA from this file (optional / one of -y or -w must be defined) |
*-w wepkey : use this WEP-KEY to encrypt packets (optional / one of -y or -w must be defined) | *-w wepkey : use this WEP-KEY to encrypt packets (optional / one of -y or -w must be defined) | ||
- | *-t tods | + | *-t tods : send frames to AP (1) or to client (0) (optional / defaults to 0) |
+ | *-r file : read frames out of pcap file (optional) | ||
+ | *-h MAC : source MAC address | ||
+ | *-H : Display help. Long form --help | ||
- | ===== Usage Examples ===== | + | Repeater options (the following all require double dashes): |
+ | *- -repeat : activates repeat mode. Short form -f. | ||
+ | *- -bssid <mac> : BSSID to repeat. | ||
+ | *- -netmask < | ||
- | ==== wIDS Scenario | + | ===== Scenarios ===== |
- | The first scenario is wIDS. Start your wireless card in monitor mode then enter: | + | ==== wIDS ==== |
- | airtun-ng -a 00: | + | The first scenario is wIDS. Start your wireless card in monitor mode then enter: |
- | Where:\\ | + | |
+ | | ||
+ | |||
+ | Where: | ||
*-a 00: | *-a 00: | ||
* -w 1234567890 is the encryption key | * -w 1234567890 is the encryption key | ||
*ath0 is the interface currently running in monitor mode | *ath0 is the interface currently running in monitor mode | ||
+ | \\ | ||
The system responds: | The system responds: | ||
| | ||
Line 38: | Line 52: | ||
| | ||
- | You notice above that it created the "at0" | + | You notice above that it created the **at0** interface. Switch to another console sesssion and you must now bring this interface up in order to use it: |
| | ||
- | This interface (at0) will receive a copy of every wireless network packet. | + | This interface (at0) will receive a copy of every wireless network packet. The packets will have been decrypted with the key you have provided. |
- | ==== WEP Injection Scenario | + | ==== WEP injection |
- | The next scenario is where you want to inject packets into the network. | + | 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: |
| | ||
Line 61: | Line 75: | ||
RX bytes:25113 (24.5 KiB) TX bytes:516 (516.0 b) | 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. | + | 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. | + | **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 | + | 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 |
- | ==== PRAGA Injection Scenario | + | ==== PRGA injection |
- | 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 PRAGA obtain via a [[korek_chopchop]] or [[fragmentation]] attack. | + | 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 [[korek_chopchop|chopchop]] or [[fragmentation]] attack. |
Start your wireless card in monitor mode then enter: | Start your wireless card in monitor mode then enter: | ||
- | | + | |
- | Notice that the PRAGA files was specified via the " | + | Notice that the PRGA files was specified via the " |
- | The system responds (notice it correctly states "no reception": | + | The system responds (notice it correctly states "no reception" |
| | ||
WEP encryption by PRGA specified. No reception, only sending frames through ath0. | WEP encryption by PRGA specified. No reception, only sending frames through ath0. | ||
Line 86: | Line 100: | ||
| | ||
- | You can confirm this by entering " | + | You can confirm this by entering " |
- | ==== Connecting to Two Access Points | + | ==== Connecting to Two Access Points==== |
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, | 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, | ||
Line 94: | Line 108: | ||
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. | 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. | ||
- | ==== Copy Packets | + | ==== Copy packets |
The next scenario is copying packets from the optional interface. | The next scenario is copying packets from the optional interface. | ||
+ | |||
+ | ==== Repeater Mode ==== | ||
+ | |||
+ | This scenario allows you to repeat all packets from one wireless card to another. | ||
+ | |||
+ | Prior to running the following command, you must use airmon-ng to put each card into monitor mode on the the appropriate channels: | ||
+ | |||
+ | | ||
+ | |||
+ | Where: | ||
+ | * -a 00: | ||
+ | * - -repeat specifies that inbound packets from the -i interface be repeated on the output interface. | ||
+ | * - -bssid 00: | ||
+ | * -i ath0 is input interface from which packets are read. | ||
+ | * wlan0 is the output interface. | ||
+ | |||
+ | The system responds: | ||
+ | |||
+ | | ||
+ | No encryption specified. Sending and receiving frames through wlan0. | ||
+ | | ||
+ | |||
+ | At this point, any packets for the AP (00: | ||
+ | |||
+ | ==== Packet Replay Mode ==== | ||
+ | |||
+ | You can replay any previous capture. | ||
+ | |||
+ | You enter the command: | ||
+ | |||
+ | | ||
+ | |||
+ | Where: | ||
+ | * -a 00: | ||
+ | * -r ath0one-01.cap in the name of the pcap file to be replayed. | ||
+ | * ath0 is the output interface. | ||
+ | |||
+ | The system responds: | ||
+ | |||
+ | | ||
+ | No encryption specified. Sending and receiving frames through ath0. | ||
+ | | ||
+ | | ||
+ | |||
+ | Please note that the file contents are transmitted exactly as is. You may ignore the message " | ||
+ | |||
+ | ==== Tunneling traffic into WDS networks or WiFi Bridges ==== | ||
+ | |||
+ | 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: | ||
+ | |||
+ | * There are two nodes AA: | ||
+ | * Your attacking client can only send to and receive from node A. | ||
+ | * In this case you will only see packets with Transmitter = A and Receiver = B on your interface. | ||
+ | * If you impersonate node B, you could inject traffic into the network behind node A. | ||
+ | |||
+ | This is how to setup airtun-ng for this scenario: | ||
+ | |||
+ | | ||
+ | |||
+ | If you are able to see both sides of a WDS/Bridge network, you can enable bidirectional mode. This enables communication with both endpoint' | ||
+ | |||
+ | | ||
+ | |||
+ | 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. | ||
===== Usage Tips ===== | ===== Usage Tips ===== | ||
- | This tool is extremely powerful and utilizes advanced concepts. | + | 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. |
- | ===== Usage Troubleshooting ===== | + | ==== Injecting Management Frames |
+ | You can also inject management and control frames. | ||
+ | |||
+ | ===== Usage Troubleshooting ===== | ||
+ | ==== I can't find the airtun-ng tool! ==== | ||
Windows platforms - "I can't find the airtun-ng tool!" | Windows platforms - "I can't find the airtun-ng tool!" | ||
+ | |||
+ | ==== Error opening tap device: No such file or directory ==== | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | ==== Error creating tap interface: Permission denied ==== | ||
+ | |||
+ | See the following [[faq# | ||
airtun-ng.txt · Last modified: 2015/04/12 23:15 by mister_x