Sunday, April 15, 2018

Aircrack-ng 1.2

It's been way too long since the last stable release.

Compared to the last stable, 1.1, almost 8 years ago, this release has a huge amount of improvements and fixes. The changelog since 1.1 is almost 300 lines long (1200+ commits). Code quality has improved, in parts thanks to Coverity Scan. We now switched to GitHub completely and have a few buildbots (including one for Windows) to test building and run the test suite on a different platforms.

The build system has switched to autotools, which fixes and improves building on a number of different platforms, CPUs and compilers (gcc, clang and Intel).
Aircrack-ng is now a lot faster on recent CPUs (up to 3 times) and a trampoline binary automatically chooses the best executable for your CPU instructions. There is no need to change any of the commands, it is done transparently. Both those changes will make distro package builder's task easier and they won't have to worry about how to build it to be compatible with the most CPUs.

Continuing with Aircrack-ng, it can also output WPA hashes to EWSA and hashcat format for processing with those tools.

There is 802.11 support in airodump-ng with HT40+/HT40- channels and it now displays the rate correctly for 802.11n or 802.11ac Access Points. For those using GPS, it now supports the recent version of GPSd with JSON.

Airmon-ng itself has a number of improvements in chipset/driver detection. The most notables improvements, on top of new chipset/driver detection, is the support for FreeBSD and on Linux, the support for Nexmon driver (monitor mode driver) on the Raspberry Pi 3 (and 0 Wireless) using Kali. Airtun-ng now supports WPA/2.

For the folks following our release candidates, this doesn't bring much compared to rc5, just a few small fixes and adds UTF8 ESSID support in airodump-ng and aireplay-ng. So, if you are already running 1.2rc5, update is merely advised, otherwise, it is highly recommended.


Changelog from rc5:

  • General: Fixed compiling Windows binaries and updated README.md/INSTALLING.
  • General: Fixed commands to install dependencies on Debian/Ubuntu and FreeBSD.
  • General: Added command to install dependencies on Fedora/CentOS/RHEL.
  • General: Removed packages/ directory.
  • General: Added Alpine Linux and Kali Linux buildbots.
  • General: Fixed configure with --with-libpcap-include=/somewhere/include and --with-libpcap-lib=/somewhere/lib.
  • General: Fixed search for ethtool when running as a non-root user.
  • General: Various fixes.
  • Airmon-ng: Fixed mktemp on Alpine Linux.

Tuesday, April 3, 2018

Aircrack-ng 1.2 Release Candidate 5

On top of tons of fixes and improvements everywhere (and on multiple platforms), this release switched to autotools which allows compiling on more platforms. A trampoline binary has been added for Aircrack-ng to automatically select the fastest version for your CPU features. It will also help package maintainers greatly.

A few other notable mentions:
  • Airodump-ng supports setting HT40+/HT40- channels and now displays 802.11n and 802.11ac rates.
  • Created WPA Enterprise WPE patches for HostAPd and Freeradius
  • Support to export to HCCAPx for Hashcat v3.6+
  • Added Airventriloquist-ng, a tool from Caesurus.
  • Airmon-ng supports setting Nexmon devices in/out of monitor mode on Kali


Changelog

  • General: Switching to autotools which allows compiling on more plateforms.
  • General: Updated README.md and INSTALLING files.
  • General: Fixed compilation on a lot of platforms.
  • General: Fixed compilation warnings across platforms and compilers.
  • General: Fixed typos in the tools and in manpages.
  • General: Replace %d/ld with %u/lu for unsigned printf parameters.
  • General: Added option to disable stack protector.
  • General: Improved makefile to get reproducible builds.
  • General: Fixed compilation with OpenSSL 1.1.0.
  • General: Updated radiotap parsing code.
  • General: Updated all URLs to use HTTPS.
  • General: Fixed compilation with libreSSL.
  • General: Added WPS 2.0 test PCAP.
  • General: Do not use stackguard on Windows.
  • General: Fixed warnings on GCC7.
  • General: Improved code quality using Coverity Scan.
  • General: Added badges for Coverity scan and Intel compiler buildbot
  • Aircrack-ng: Use trampoline binary to automatically select fastest executable depending on the CPU
  • Aircrack-ng: Fixed missing include for linecount.
  • Aircrack-ng: Fixed concurrency issues when reading multiple WEP PCAP.
  • Aircrack-ng: Added support for creating HCCAPx file format.
  • Airodump-ng: Get the channel from HT information.
  • Airodump-ng: Detect WPS 2.x.
  • Airodump-ng: Also check current directory for OUI file.
  • Airodump-ng: Fixed writing ESSID to CSV, Kismet CSV and Kismet NetXML files when ESSID gets decloaked and cloaked length was 1.
  • Aireplay-ng: Added deauthentication reason code option.
  • Aireplay-ng: Increase amount of AP to test when running injection test.
  • Airodump-ng: Fixed 802.11a channel hopping list.
  • Airodump-ng: Fix creation of .xor files.
  • Airodump-ng: Added support for HT channels (HT20/HT40-/HT40+).
  • Airodump-ng: Now displaying correct rate for 802.11n or 802.11ac AP.
  • Airmon-ng: Fixed checking for processes.
  • Airmon-ng: Fixed display of "cannot access '/sys/class/ieee80211/': No such file or directory".
  • Airmon-ng: Fixed bashisms.
  • Airmon-ng: Fixed display of specific drivers.
  • Airmon-ng: Fixed display of cards on the sdio bus.
  • Airmon-ng: Now supports nexmon driver on RPi 3 (and 0 Wireless) using Kali Linux.
  • Airmon-ng: Added identification for another realtek chipset and generic Ralink/MT.
  • Airmon-ng: Handle 2 types of rfkill commands and updated unblock text.
  • Airmon-ng: more portable modinfo usage.
  • Airmon-ng: remove grep -P references upon request.
  • Airmon-ng: Do not replace driver name by ?????? when driver is valid.
  • Airgraph-ng: Removed irrelevant comment in README.
  • Airgraph-ng: Handle SSID with double quotes.
  • Airgraph-ng: Fixed parsing OUI file.
  • Airdrop-ng: Updated lorcon2 installation instructions.
  • Besside-ng: Fixed 'wi_read(): No child processes' error.
  • Airdecloak-ng: Fixed segfault due to NULL pointer dereference.
  • osdep: Remove wi_set_channel(1) on open wifi interface (cygwin).
  • osdep: Fixed RAW socket resource leak.
  • Patches: Created WPE patches and documentation for current HostAPd and Freeradius versions.
  • Airodump-ng: Fix incorrect if conditions which always are false.
  • Airodump-ng: Remove useless not NULL check.
  • Airventriloquist: New tool from https://github.com/Caesurus/airventriloquist/
  • dcrack: Fixed indentation.
  • TravisCI: Fixed compilation on OSX.
  • AppVeyor: Added support for AppVeyor, CI for cygwin builds.

Sunday, March 11, 2018

Migration to GitHub

We have been wanting to migrate to GitHub for quite some time. We already had subversion to GitHub synchronization, so some of the work was already done. What was left were tickets.
We now finally migrated completely to GitHub.


It was a lot more complicated than what it sounds because we had tickets on trac and issues + pull requests on GitHub. One of the key migration goals was to replicate the data in such a way
as to near perfectly clone it; all while not bothering our entire user base with GitHub notifications.

Joe Benden did most of the work. The same person who helped us migrating to autotools. I did not expect such a level of professionalism and perfectionism in the work. We probably had a total 10 to 15 test-runs, each taking 1 to 2 days to complete and a lot of discussions to find the best solutions to issues/limitations we came across. Each test run was followed by review and feedback to improve it on the next run.


All the trac tickets are correctly linked to each other and have their attachments. We had some ticket numbers skipped in trac, due to spam some time ago. Luckily, GitHub API allows to skip issues numbers. A lot of fine tuning was done to do it the way we wanted. One of the item was linking tickets that was sometimes done in different ways (#123 or https://trac.aircrack-ng.org/tickets/123 or sometimes hxxp:// trac.aircrack-ng.org/tickets/123). Even URLs were corrected where needed. Along with a bunch of other small details.


Attachment was a big issue since we wanted to keep them and GitHub pretty much only allows text files or pictures in issues. Anything else is out of question. The best solution we could think about was to store them in a repository, GitHub only limiting large attachments which wasn't a problem in this case. On the filesystem, trac doesn't organize them neatly in directories, by names. Instead, it uses some kind of hashing algorithm and it is necessary to look up in the trac database to match them with the tickets and create a script to batch rename them.


Surprisingly, migrated trac tickets look much better than migrated GitHub issues. They look OK but that is due to GitHub API limitations.


One of the decisions was to avoid spamming people with notifications, so all the tickets are created with the Aircrack-ng account. GitHub doesn't allow to set the creation date or the author (there is a mix or email addresses, anonymous author or just username looking reporters) and with almost 2000 tickets, the best solution was to write down the author and date/time in the issues themselves.


Pull requests is tricky, they can't be migrated from one repo to another, period, even when using the API. So, we now have a copy of the existing ones, without link to the code change. So, if anybody who had a PR in the old repository, if you can recreate it in the new one, it would be great. GitHub API has also some kinds of limitation regarding closed PR/issues.


The reason why we decided to create another repository has to do with importing trac tickets and numbering. Matching would have been way too complicated if we appended to the existing repository. On top of that, if it failed somehow, we had no way of going back. It would also have complicated testing significantly.


Finally, while doing the migration, we noticed that the paid accounts don't have as much rate-limiting as the free accounts and the migration went a lot faster than expected. Just a few hours vs 2 days.


We kept the old repository and renamed it aircrack-ng-archive in case we need to look back at some issue/PR history.

Monday, October 16, 2017

KRACK WPA Vulnerability - Key Reinstallation AttaCK

TL;DR at the end.

Short summary

It is a new vulnerability in the WPA handshake implementation that allows in certain cases to decrypt a lot/all the WPA traffic without knowing the key (and it won't reveal the key).

Most devices are affected but Linux and Android are most affected. Patching will fix the issue.

The attack works if you are connecting to a legitimate access point, which means the attacker has to be in range of both devices. If you are far away from your legitimate AP (such as traveling), it won't affect you.

Proof of concept code (to test the vulnerability) hasn't been published yet.

Who needs to worry?

Businesses and governments are more likely at risk due to (trade) secrets and personal information they handle.

Even though your device(s) are most likely vulnerable, there is no reason to worry. It is a bad flaw but the chances of having it exploited is rare, especially considering the PoC hasn't been published yet.

To put it in comparison, there are still WEP access point around but that doesn't mean they are attacked all the time. However, it isn't a reason to keep vulnerable stuff around, fix (or replace) them.

More details please


CVEs

  • CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
  • CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
  • CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
  • CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
  • CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
  • CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
  • CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
  • CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
  • CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
  • CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

CWE

  • CWE-323: Reusing a Nonce, Key Pair in Encryption

You might also want to check out Ars Technica (even though their title is a bit dramatic in my opinion), US CERT advisory which includes some affected vendors and the FixKrak website.

How to test it?

Mathy Vanhoef, the author of this vulnerability, posted tools on his GitHub to test AP/client vulnerability.

How to fix it?

Update (or patch) your systems when updates are available, plain simple (and keep them up to date).

Some vendors as well as some Linux distributions already provided a fix and if you keep your devices up to date, then they should already be patched. For other devices, you are dependent on the vendor to provide a patch.

If your (vulnerable) device is End of Life, it might be a good time to replace it (it is probably not be the only vulnerability in it).

A list of vendor responses is available here and here.

TL;DR

Don't worry, another day, another vulnerability. Just patch/update your stuff (computers, cellphone/tablets, AP/routers, IoT) and keep them updated. Businesses/governments should contact their vendors for a patch/press release regarding the vulnerability (devices are not always vulnerable) and if you are running an EoL device, it might be a good time to replace it.

Tuesday, August 15, 2017

On drivers, rtl8812au, WN722N, monitor mode, QCA6174, other news and status of linux-backports aka compat-wireless

When discussing in the forum/IRC, it feels that I'm repeating the same things again and again.

I deal with Wi-Fi, play with packets and develop around it every day so all that stuff is fairly easy for me but I realize it is not always obvious. Some of it is because a quick search in THE Google ;) or the Aircack-ng forums or Kali forum would give you the answer.

So here is a summary of some of the things I can think of.

Using another driver

I sometimes see questions or statements like this "This Broadcom driver doesn't work in AP/monitor mode, can I use ath9k for my (Broadcom) card?" or "Can I just use the Airpcap driver to get monitor mode in Windows?"
The answer to both of those is no. Drivers are made for a specific chipset (which is integrated on a wireless card) or a bunch of them that behave similarly.

Some will say this is wrong and they are partially correct: the only choice you have is pretty much VENDOR_DRIVER or open source driver. Where the VENDOR_DRIVER doesn't support monitor mode, so it is out of question. Yes, VENDOR_DRIVER sometimes can be made to support monitor mode, but they won't do it out of the box. Spoiler alert: manufacturers don't care about monitor mode.

You can't just use another driver because the other work better. If you look at the internals in the code, you will see they all are very different. Some of them even require a firmware (and even a specific version) to be loaded so they can work.
Most firmwares are closed source, so if a card behave badly or crashes, the only thing that you can do is bother the manufacturer to fix it, Linux kernel driver developers often can't do much about it.

If you feel adventurous, start developing or fixing bugs in the wireless drivers, Linux kernel developer always need help. If you can't, search and report bugs and provide useful information.

Driver not working for card

This issue got exacerbated recently with rtl8812au and newer cards being released. If you look at drivers, you'll notice that they contains a list of USB IDs (or PCI ID if it's linked to the PCIe bus) for the known cards using the driver.
When a card is plugged on the system, the kernel read its ID and matches it with the appropriate driver.

Developers have a limited set of cards they can test stuff on and new cards with different IDs get released from time to time. So, a driver, even though it will work with a specific card will not be loaded and attached to the card because it doesn't have the IDs. Even if you force loading the driver (modprobe/insmod), it will not work.

An update of that ID table is required to support the new card as well as the driver to be recompiled.

rtl8812au support

The driver, from astam, which is also built as a package for Kali, supports monitor mode and injection.

This driver, as is, will most likely never be supported by airmon-ng. The reason is that it is kind of a Frankenstein driver and it doesn't behave the same way any other driver does. It mixes the old ieee80211 stack and the newer mac/cfg80211 stack.

Aircrack-ng tools can be used with it as long as it is in monitor mode but putting it in monitor mode is done in an usual way (check out the README.md on their GitHub for details in the link above).

Embedded chipsets

Those are tricky and most of them won't support monitor mode and even injection. The reason behind it is those need to use as little power as possible, so your phone can last longer.

With a few exceptions though:
  • Raspberry Pi 3 or zero Wireless using Nexmon drivers: monitor mode and injection. For those who played with Kali images with the NexMon driver, if you download the current version of airmon-ng (in our subversion repository), it helps putting the card in monitor mode (even though it's an easy command, it's one less command to remember.
  • Nokia N900: Capture and injection in 802.11bg (no n). With a 5000mAh battery and capturing 802.11 frames, the battery will last at most 4 hours and the chip emits a decent amount of heat. That 5000mAh battery usually gives 4-5 days in normal use.
  • G1 (I think): same driver as N900 AFAIK.
  • ESP8266 (and similar): they seem to support 802.11n in monitor mode (and limited injection?) but those are Arduino-type boards with a 802.11n chip.
So, to sum it up, your Android will most likely not have monitor mode (if you want it, you'll need to use NetHunter and a compatible card).
If you're using iOS, forget it, Apple doesn't care about it, that will never happen.

Monitor mode

We often see people wondering why they can't catch a handshake or data or see any traffic even though their device is connected. What happens is that the card you have probably doesn't support capturing in the mode your connected device is using. Some card that advertise 802.11n/ac capabilities sometimes cannot capture in that mode (and you are limited to 802.11bg), this is either a limitation of the driver/firmware.

802.11n/ac adds some more complexity: it might also not have enough streams (remember those 2x2, 1x1, 3x3?) to capture it: If the station is using 2 stream to send/receive data to the Access Point and your capture card is 1 stream, assuming it can capture in n or ac, will not be able to see the traffic.

There are other possible issues but those are the most common explanations.

QCA6174 (ath10k)

In summary, that card is a PoS. Firmware crashes very often (even for normal operations that would work with any other card) and it is very unlikely it will be fixed. It supports monitor mode but will not give a single packet.

The firmware being closed source, kernel developers are pretty much giving up on that specific chipset.

Ath10k, most of the time, work fine but this specific chipset is doomed. Throw it away and switch to ath9k compatible card, you won't regret it (or just use a supported USB card).
Or if you want to stick with it, you can bother Atheros (now Qualcomm) about it.

TP-Link WN722N

TP-Link recently released a new version of the card (with a different chipset, some Realtek IIRC) and when you buy this card, you don't get the AR9170 chipset (ath9k_htc) anymore.

For those using it in AP mode (as well as any other card using ath9k_htc driver), it has a limitation in the number of stations it can handle (between 5 and 8). It is a physical limitation, not the driver.

Linux-backports, aka compat-wireless

People also misname it to combat-wireless which is pretty funny.

Linux-backports is the latest name and is supposed to bring the latest updates to drivers for pretty much any kernel so you don't have to recompile the whole kernel. Recompiling a kernel is a daunting task, especially if you want to do it right (keep updated with security updates, making sure stuff still work, not breaking other stuff in your distro).

So, when you download, let's say linux-backport-4.1, it will bring the latest updates in the wireless drivers from kernel 4.1. The numbers here refer to the kernel version.

Unfortunately, due to lack of time, they haven't been updated in a long time. If you are able to compile them (most likely not due to the amount of changes), you will downgrade your wireless drivers.

TL;DR: DON'T USE COMPAT-WIRELESS/LINUX-BACKPORTS ANYMORE.

So, any more good news? 

  • ath9k works fine in all modes. If you want to create a cheap attack box, look into the PCEngines APU.
  • Some Ubiquiti 802.11ac AP can be used to capture in 802.11ac mode (with 3 or 4 streams depending on the unit you buy). Either out of the box or when flashed with OpenWrt.
  • If you do a lot of GPU cracking and like AWS, Kali released instances ready to be used with hashcat. No need to install drivers or anything.
  • Kali now has a book called Kali Revealed, you can either read it online or buy a hard copy on Amazon.

Wednesday, August 9, 2017

Lesser known feature of aircrack-ng: interactive mode and keys

Airodump-ng has an interactive mode and all the keys are detailed in the wiki. We'll go through some of them here.

The spacebar is probably the most useful as it can pause the display of airodump-ng such as when you notice something on the screen.
Don't worry, only the display is paused and it keeps capturing, saving all the files in the background. When hitting the spacebar again, it will go back to normal and refresh the screen with the current data.

Let's explore some of the interactive parameters (excerpt from the wiki):



The screen refresh can be adjusted with the '--update' parameter. So if you want it refreshed every 5 seconds instead of the 1 second default, use add '--update 5' to your airodump-ng command.


Now let's scroll through the access points list using Tab. Use the arrows UP and DOWN to navigate in the list.

The most useful feature in my opinion is the coloring one: 'm'. Once you hit that key, it will color the AP selected. To switch to other colors, keep hitting 'm'. You will notice that the associated stations will be have the same color as the access point.

Another key is 's'. It will change the sorting. Be careful, sorting can sometime be out due to the list of Access Points changing. In order to reset sorting (to the default 'Power'), use the 'd' key.

If you can't remember what they keys are, remember that every tool in the suite has a corresponding manual page. In this case 'man airodump-ng'. Look for "INTERACTION" in that page.

Monday, March 27, 2017

Lesser known features of Aircrack-ng

I recently received an email suggesting to adding features to aircrack-ng. Even though most of the stuff can be found in the documentation, it might be worth talking about.

Reading from compressed wordlist

Aircrack-ng can read words from a pipe, which is very convenient and you can use pretty much any program to generate words and display them on the screen (each line will be considered a word) and pass them to aircrack-ng.

About compressed files, there are tools to decompress files on the fly and display the output on the screen such as zcat who takes care of gzip compressed files (there are others and most compression/decompression tools have a feature to display decompressed output to the screen).

Here is how it would look like:

zcat file.gz | aircrack-ng pcap_to_crack.pcap -w -

In this example, it decompress file.gz and 'cat' the result to the screen, then we pipe it to aircrack-ng. Aircrack-ng reads wordlists files using -w and in order to tell it to get it from a pipe (to be technical, stdout from the previous command became stdin in aircrack-ng), you have to use the '-' as parameter for -w.

Rainbow tables

airolib-ng can generate tables (in SQLite format) or import them from cowpatty's format. Once the table is generated, use -r in aircrack-ng to read them (instead of a wordlist).

Distributed cracking

There is a tool in the script/ directory to do that called dcrack.py. As a matter of fact, check out that entire directory, there are a few useful scripts in there.

Running the script will give you a help screen. Here is what the architecture look like to better understand the different parameters:



The different clients represent the cracking systems, the server coordinates everything based on the performance of each client. Each client joining the server will have its performance assessed and when a wordlist is uploaded, it will be split according to each client's performance so they all take the same amount of time to process the dictionary.

The laptop (you) send commands to the server to upload dictionary, to upload capture files, to start the cracking process and obtain the status of the cracking process (as well as the key).

When uploading a PCAP  file, it is highly recommended to clean it up and just leave a beacon as well as the 4 EAPoL packets (or less if you have less) of the 4-way handshake or you'll risk aircrack-ng choosing the wrong packets when cracking. There is a tutorial about it in the wiki.