AIRBASE-NG(8) | System Manager's Manual | AIRBASE-NG(8) |
airbase-ng - multi-purpose tool aimed at attacking clients as opposed to the Access Point (AP) itself
airbase-ng [options] <interface name>
airbase-ng is multi-purpose tool aimed at attacking clients as opposed to the Access Point (AP) itself. Since it is so versatile and flexible, summarizing it is a challenge. Here are some of the feature highlights:
- Implements the Caffe Latte WEP client attack
- Implements the Hirte WEP client attack
- Ability to cause the WPA/WPA2 handshake to be captured
- Ability to act as an ad-hoc Access Point
- Ability to act as a full Access Point
- Ability to filter by SSID or client MAC addresses
- Ability to manipulate and resend packets
- Ability to encrypt sent packets and decrypt received packets
The main idea is of the implementation is that it should encourage clients to associate with the fake AP, not prevent them from accessing the real AP.
A tap interface (atX) is created when airbase-ng is run. This can be used to receive decrypted packets or to send encrypted packets.
As real clients will most probably send probe requests for common/configured networks, these frames are important for binding a client to our softAP. In this case, the AP will respond to any probe request with a proper probe response, which tells the client to authenticate to the airbase-ng BSSID. That being said, this mode could possibly disrupt the correct functionality of many APs on the same channel.
By using the "-f disallow" option, this reverses selection and causes airbase-ng to ignore the clients specified by the filters.
The "auto" option is to allow airbase-ng to automatically set the flag based on context of the other options specified. For example, if you set a WEP key with -w, then the beacon flag would be set to WEP.
One other use of "auto" is to deal with clients which can automatically adjust their connection type. However, these are few and far between.
In practice, it is best to set the value to the type of clients you are dealing with.
In ad-hoc mode airbase-ng also sends beacons, but doesn't need any authentication/association. It can be activated by using "-A". The soft AP will adjust all flags needed to simulate a station in ad-hoc mode automatically and generate a random MAC, which is used as CELL MAC instead of the BSSID. This can be overwritten by the "-a <BSSID>" tag. The interface MAC will then be used as source mac, which can be changed with "-h <sourceMAC>".
The packet structure is rather simple: the ethernet header (14 bytes) is ignored and right after that follows the complete ieee80211 frame the same way it is going to be processed by airbase-ng (for incoming packets) or before the packets will be sent out of the wireless card (outgoing packets). This mode intercepts all data packets and loops them through an external application, which decides what happens with them. The MAC and IP of the second tap interface doesn't matter, as real ethernet frames on this interface are dropped anyway.
There are 3 arguments for "-Y": "in", "out" and "both", which specify the direction of frames to loop through the external application. Obviously "in" redirects only incoming (through the wireless NIC) frames, while outgoing frames aren't touched. "out" does the opposite, it only loops outgoing packets and "both" sends all both directions through the second tap interface.
There is a small and simple example application to replay all frames on the second interface. The tool is called "replay.py" and is located in "./test". It's written in python, but the language doesn't matter. It uses pcapy to read the frames and scapy to possibly alter/show and reinject the frames. The tool as it is, simply replays all frames and prints a short summary of the received frames. The variable "packet" contains the complete ieee80211 packet, which can easily be dissected and modified using scapy.
This can be compared to ettercap filters, but is more powerful, as a real programming language can be used to build complex logic for filtering and packet customization. The downside on using python is, that it adds a delay of around 100ms and the cpu utilizations is rather large on a high speed network, but its perfect for a demonstration with only a few lines of code.
The soft AP will send an "authentication method unsupported" rejection to any open system authentication request if "-s" is specified.
"-x <pps>" sets the number of packets per second to send when performing the caffe-latte attack. At the moment, this attack doesn't stop, it continuously sends arp requests. Airodump-ng is needed to capture the replies.
This attack works especially well against ad-hoc networks. As well it can be used against softAP clients and normal AP clients.
This manual page was written by Thomas d'Otreppe. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL.
aireplay-ng(8)
airmon-ng(8)
airodump-ng(8)
airodump-ng-oui-update(8)
airserv-ng(8)
airtun-ng(8)
besside-ng(8)
easside-ng(8)
tkiptun-ng(8)
wesside-ng(8)
aircrack-ng(1)
airdecap-ng(1)
airdecloak-ng(1)
airolib-ng(1)
besside-ng-crawler(1)
buddy-ng(1)
ivstools(1)
kstats(1)
makeivs-ng(1)
packetforge-ng(1)
wpaclean(1)
airventriloquist(8)
January 2020 | Version 1.6.0 |