Shared-key authentication (aireplay-ng -1) doesn't work with certain access points and certain cards after upgrade to aircrack 1.6

[dsuder]

Issue type

• Defect - Incorrect value displayed/received/stored

System information

• OS: Kali 2020.2a with GNOME Terminal (problem occurs in any terminal)
• CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
• Wireless card and chipset (if relevant): AWUS036NHA / AR9271 and AWUS036AC / RTL8812AU

Aircrack-ng version

• Version: 1.6
• Commit Revision hash: 87bf572

Defect

How to reproduce the issue

After deauthentication (-0) attack on a station using WEP SKA I am unable to perform shared-key authentication for one of my access points from testing lab. In airodump-ng version 1.4 that problem wasn't exist.

Problem occurs only, to the best for my knowledge, only in certain combinations of access point and wireless card. I've already tested:

TP-Link TL-WR841N v14 and RTL8187 - works Netgear DGN1000 and RTL8187 - works TP-Link TL-WR841N v14 and AR9271 - works Netgear DGN1000 and AR92717 - doesn't work TP-Link TL-WR841N v14 and RTL8812AU - works Netgear DGN1000 and RTL8812AU - doesn't work

On aircrack-ng 1.4 all combinations work perfectly. On aircrack-ng 1.5.2 problem also occures.

[root:~] 2s # aireplay-ng -1 60 -a 20:4E:7F:E0:91:02 -y ntgr-03-20-4E-7F-E0-91-02.xor wlan2mon
No source MAC (-h) specified. Using the device MAC (00:C0:CA:97:60:D1)
11:05:54  Waiting for beacon frame (BSSID: 20:4E:7F:E0:91:02) on channel 6

11:05:54  Sending Authentication Request (Shared Key) [ACK]

11:05:56  Sending Authentication Request (Shared Key) [ACK]

11:05:58  Sending Authentication Request (Shared Key) [ACK]

11:06:00  Sending Authentication Request (Shared Key) [ACK]

11:06:02  Sending Authentication Request (Shared Key) [ACK]

11:06:04  Sending Authentication Request (Shared Key) [ACK]

11:06:06  Sending Authentication Request (Shared Key) [ACK]

11:06:08  Sending Authentication Request (Shared Key) [ACK]

11:06:10  Sending Authentication Request (Shared Key) [ACK]

11:06:12  Sending Authentication Request (Shared Key) [ACK]

11:06:14  Sending Authentication Request (Shared Key) [ACK]

11:06:16  Sending Authentication Request (Shared Key) [ACK]

11:06:18  Sending Authentication Request (Shared Key) [ACK]

11:06:20  Sending Authentication Request (Shared Key) [ACK]

11:06:22  Sending Authentication Request (Shared Key) [ACK]

11:06:24  Sending Authentication Request (Shared Key) [ACK]
Attack was unsuccessful. Possible reasons:

    * Perhaps MAC address filtering is enabled.
    * Check that the BSSID (-a option) is correct.
    * Try to change the number of packets (-o option).
    * The driver/card doesn't support injection.
    * This attack sometimes fails against some APs.
    * The card is not on the same channel as the AP.
    * You're too far from the AP. Get closer, or lower
      the transmit rate.

Related issues

I've discovered the problem when dealing with that issue: https://github.com/aircrack-ng/aircrack-ng/issues/2173

[dsuder]

Sorry for misinformation. On aircrack-ng 1.4 all combinations work perfectly. On aircrack-ng 1.5.2 problem also occures.

[jbenden]

May I ask what the firmware version is running on the AR9271? The one I have is:

[    6.842195] usb 1-9: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[    7.094163] ath9k_htc 1-9:1.0: ath9k_htc: HTC initialized with 33 credits
[    7.362258] ath9k_htc 1-9:1.0: ath9k_htc: FW Version: 1.4
[    7.362258] ath9k_htc 1-9:1.0: FW RMW support: On
[    7.362259] ath: EEPROM regdomain: 0x833a
[    7.362259] ath: EEPROM indicates we should expect a country code
[    7.362260] ath: doing EEPROM country->regdmn map search
[    7.362260] ath: country maps to regdmn code: 0x37
[    7.362261] ath: Country alpha2 being used: GB
[    7.362261] ath: Regpair used: 0x37
[    7.367023] ieee80211 phy2: Atheros AR9271 Rev:1

I'm researching the possibility of the firmware causing injected packets to have their sequence numbers rewritten, along with outgoing control frames being re-transmitted waiting for an ACK, and other issues.

I'd appreciate the data on your AR9271; so I can compare it.

Thanks, -Joe

[dsuder]

On Kali 2020.2a and aircrack-ng 1.5.2:

[   72.390252] usb 1-1: new high-speed USB device number 2 using ehci-pci
[   72.779405] usb 1-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08
[   72.779407] usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[   72.779408] usb 1-1: Product: UB91C
[   72.779409] usb 1-1: Manufacturer: ATHEROS
[   72.779410] usb 1-1: SerialNumber: 12345
[   72.801437] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   72.801597] cfg80211: Loaded X.509 cert '[email protected]: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   72.801743] cfg80211: Loaded X.509 cert '[email protected]: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   72.801916] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   72.802407] platform regulatory.0: firmware: direct-loading firmware regulatory.db
[   72.802755] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s
[   72.831721] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[   72.832233] usbcore: registered new interface driver ath9k_htc
[   72.833418] usb 1-1: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[   73.178927] usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51040
[   73.444397] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[   74.146318] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.4
[   74.146319] ath9k_htc 1-1:1.0: FW RMW support: On
[   74.146320] ath: EEPROM regdomain: 0x833a
[   74.146321] ath: EEPROM indicates we should expect a country code
[   74.146321] ath: doing EEPROM country->regdmn map search
[   74.146322] ath: country maps to regdmn code: 0x37
[   74.146323] ath: Country alpha2 being used: GB
[   74.146323] ath: Regpair used: 0x37
[   74.176262] ieee80211 phy0: Atheros AR9271 Rev:1

On Kali 2018.4 and aircrack-ng 1.4:

[   97.684321] usb 1-2: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08
[   97.684327] usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[   97.684331] usb 1-2: Product: UB91C
[   97.684335] usb 1-2: Manufacturer: ATHEROS
[   97.684339] usb 1-2: SerialNumber: 12345
[   97.769493] usb 1-2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.dev.0.fw requested
[   97.770594] usbcore: registered new interface driver ath9k_htc
[   97.772023] usb 1-2: firmware: direct-loading firmware ath9k_htc/htc_9271-1.dev.0.fw
[   98.130988] usb 1-2: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.dev.0.fw, size: 51008
[   98.436767] ath9k_htc 1-2:1.0: ath9k_htc: HTC initialized with 33 credits
[   99.716788] ath9k_htc 1-2:1.0: ath9k_htc: FW Version: 1.4
[   99.716790] ath9k_htc 1-2:1.0: FW RMW support: On
[   99.716791] ath: EEPROM regdomain: 0x833a
[   99.716791] ath: EEPROM indicates we should expect a country code
[   99.716792] ath: doing EEPROM country->regdmn map search
[   99.716793] ath: country maps to regdmn code: 0x37
[   99.716794] ath: Country alpha2 being used: GB
[   99.716794] ath: Regpair used: 0x37
[   99.759139] ieee80211 phy0: Atheros AR9271 Rev:1

[jbenden]

Are you willing to experiment?

• Take that firmware file ath9k_htc/htc_9271-1.dev.0.fw and xfer it to the 2020 Kali, inside /lib/firmware/ath9k_htc.
• Next create the modeprobe.d configuration file, with the contents:

options ath9k_htc use_dev_fw=1

• Rebuild initramfs.
• Reboot.
• Finally, rerun some of the tests.

If it works out, we'd have proof that the new firmware is to blame. I can then work on properly patching the firmware and making updated firmware available.

PS: If you don't want to, that's OK. I'll try to find this older firmware and run the experiment.

Thanks, -Joe

[dsuder]

Of course I will do that. When I spotted the difference I have started to making the change. Both of these systems are virtual and I have backups of them so this is no problem for me to do such experiments.

One moment please. :)

[jbenden]

Thanks!

You might need to add a modprobe.d configuration with:

options ath9k_htc use_dev_fw=1

[dsuder]

Ok, I've check that fw file with new Kali and new (1.6) aircrack-ng. Shared authentication still doesn't work, regardless of option you provided.

One more thing. I really don't know how I had tested aircrack-ng 1.5.2 yesterday but now I've check it again against shared authentication mode and works fine. Maybe yesterday I've forgotten to restart the machine after some changes and something had been broken that way.

Both fw files attached: htc_9271.zip

[dsuder]

And a new discover here. When I use fw file from the new Kali distribution (version 1.4.0) AND options ath9k_htc use_dev_fw=1 in modprobe.d shared auth works with aircrack 1.6.0 (tested with Aireplay-ng 1.6 rev 048e434b).

I've probably forgotten about that parameter when I have been upgrading my system.

Thank you so much for your help!

[dsuder]

Huh. I've discovered new behavior. Regardless of options ath9k_htc use_dev_fw=1 presence, if I start Kali with aircrack-ng 1.6 and plug card in, the shared-key authentication doesn't work. But if I remove module (modprobe -r ath9k_htc), load it again (modprobe ath9k_htc), disconnect and connect card again, change mode to monitor and then check shared-key auth - it work.

use_dev_fw=1 does make nothing because driver dev version is not present by default on this (Kali 2020.2a) system:

[  262.582947] usb 1-1: Manufacturer: ATHEROS
[  262.582948] usb 1-1: SerialNumber: 12345
[  262.585682] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.dev.0.fw requested
[  262.585976] usb 1-1: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
[  262.585979] usb 1-1: Direct firmware load for ath9k_htc/htc_9271-1.dev.0.fw failed with error -2
[  262.585983] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[  262.586007] usb 1-1: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[  262.911184] usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008

It doesn't make sense to me.

[jbenden]

Did you remake initramfs?

[dsuder]

No.