Scapy attacks (IOCTL / Netlink) issue [W.I.P]

[kimocoder]

@ZerBea

Tested with hcxdumptool and some other Scapy test tools (wiphy, scan and connect). Could you do some test, as I really don't know much about Scapy atm

[ZerBea]

As shown in the right screenshot, there are no hits. That means we do not inject packets. None of the APs respond to our proberequests and we must assume that packet injection isn't working. Left screenshot showing that scapy run libpcap and libpcap run NETLINK: NL80211_CMD....

[ZerBea]

Next step is to test which kind of packets we received to determine that we have a "full monitor". hcxdumptool -i interface --enable_status=95 -o test.pcapng test.pcapng should contain BEACON, AUTHENTICATION, ASSOCIATION, EAP, PROBEREQUEST and PROBERESPONSE frames from APs and CLIENTs. If not, we must assume that we have not full monitor capabilities, too. We should not receive an ERR after 1 minute.

[ZerBea]

I have only an 8811 device, here, But I'll to some tests.... Cheers Mike

[kimocoder]

Basic packet injection, eg with wifite and other tests works.. ? I don't understand this Scapy thing :P I noticed that I actually have to put my card up with "ip link set wlan# up" (or iwconfig wlan# up) before hcx and the other tests actually would run, that's a easy fix.. been diving into both IOCTL and the frame injection code the past 24 hours :+1:

I just ran the 8814au and a 8811au (8821au) together..

[kimocoder]

Just hit me up with your knowledge.. know where to find the IOCTL/IWMODE code now at least :1st_place_medal: some basic understanding of it, but it's great to investigate again :100:

[ZerBea]

I don't use scapy, because it use libpcap.

...have to put my card up with "ip link set wlan# up" (or iwconfig wlan# up) before hcx and the other tests actually would run -> normally not. hcxdudmdptool bring interface down, set monitor mode and bring interface up by ioctl() system calls. It is done in the same way like ip link and iwconfig doing this.

[ZerBea]

ok, compiled 5.7.0. hcxdumptool is not able to set monitor mode, running ioctl() system calls: $ sudo hcxdumptool -m wlp0s20f0u3 failed to set monitor mode, ioctl(SIOCSIWMODE) not supported by driver: Operation not permitted failed to init socket hcxdumptool need full and exclusive access to the adapter as well as write permission for the dumpfile that is not the case try to use ip link to bring interface down/up and iw to set monitor mode

if we use iw to set NETLINK monitor: Interface wlp0s20f0u3 ifindex 10 wdev 0x700000001 addr 4a:44:41:20:69:61 type monitor wiphy 7 txpower 12.00 dBm

$ sudo hcxdumptool -m wlp0s20f0u3 interface is already in monitor mode setting interface wlp0s20f0u3 to monitor mode

everything is looking fine, but it isn't. Device can only be used by NETLINK socket. Packet injection isn't working. BTW: aireplay should work fine, because it run NETLINK, too.

[ZerBea]

Now we do the same, using the internal PCIe card: 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac PCIe Wireless Network Adapter we are able to set monitor mode.

$ sudo hcxdumptool -m wlp3s0
setting interface wlp3s0 to monitor mode

packet injection is working, too:

$ sudo hcxdumptool -i wlp3s0 --do_rcascan
---------------------------------------------------------------
 BSSID         CH COUNT   HIT ESSID                 [19:48:39]
 609620259315   9     2     1 test.net
 609620259303   9     2     1 test1.net

Both test nets respond to our request.

[kimocoder]

Ok, won't give up anyway.. have a couple of weeks to smash bugs anyway :1st_place_medal: Here's my run in a country side environment:

Adapter: 8814AU Driver: v5.7.0 Kernel: v5.4 (Kali)

19:35:34   3 e4f0428b3ce2 5ce28c23dcb0 Telenor2406dyp [EAPOL:M1M2 EAPOLTIME:7145 RC:0 KDV:2]
19:35:34   3 e4f0428b3ce2 5ce28c23dcb0 Telenor2406dyp [EAPOL:M3M4ZEROED EAPOLTIME:2053 RC:1 KDV:2]
19:36:00   1 ERROR:0 INCOMING:17856 OUTGOING:321 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:36:18   9 b8a386906729 54bad6833dd6 Telenor4G-833DD6 [ASSOCIATION]
19:36:40   1 b8a386906729 54bad6833dd6 Telenor4G-833DD6 [AUTHENTICATION]
19:37:00   1 ERROR:0 INCOMING:19115 OUTGOING:361 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:38:00   1 ERROR:0 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:50:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:51:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:52:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:53:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:54:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:55:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:56:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0
19:57:00   1 ERROR:1 INCOMING:21531 OUTGOING:440 PMKIDROGUE:0 PMKID:1 M1M2ROGUE:0 M1M2:4 M2M3:3 M3M4:0 M3M4ZEROED:3 GPS:0

[ZerBea]

BTW: is aireplay-ng --test still working, when compiled without libnl (disable-libnl) running 8812au driver?

Adapter used for latest test here: ID 7392:a812 Edimax Technology Co., Ltd Edimax AC600 USB Realtek RTL8811AU

[ZerBea]

Now running/testing aireplay-ng compiled with --disable-libnl Additional iw is compiled without libnl, too:

Looks like we have a full monitor mode:

Interface wlp0s20f0u3
    ifindex 37
    wdev 0x2200000001
    addr aa:76:dc:d9:9c:75
    type monitor
    wiphy 34
    txpower 12.00 dBm

here we go:

$ sudo ./aireplay-ng --test wlp0s20f0u3
20:14:35  Trying broadcast probe requests...
20:14:36  No Answer...
20:14:36  Found 0 APs

as expected, packet injection isn't working

CH  0 ][ Elapsed: 0 s ][ 2020-03-17 20:17 
 BSSID              PWR  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID
 BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes

Quitting...
free(): double free detected in tcache 2

and airodump-ng isn't working, too:

BTW: Also, it looks like we are running into an airodump-ng issue here: free(): double free detected in tcache 2

Conclusion: Everything is fine, if NETLINK is in use, but we run into trouble on pure ioctl() system calls. That applies to both drivers (8812au and 8188eus) in the same way. Running NETLINK, we have much overhead:

Netlink messages consist of a byte stream with one or multiple nlmsghdr headers and
associated payload. The byte stream should be accessed only with the standard
NLMSG_* macros. See netlink(3) for further information.

In multipart messages (multiple nlmsghdr headers with associated payload in one byte
stream) the first and all following headers have the NLM_F_MULTI flag set, except for
the last header which has the type NLMSG_DONE.

https://www.systutorials.com/docs/linux/man/7-netlink/

[ZerBea]

This issue could be related to one mentioned above: https://github.com/ZerBea/hcxdumptool/issues/227 Interesting is that setting a frequency by iwconfig only works after the device was init by iw via NETLINK: iwconfig was able to set the channel (init was done by iw before): https://github.com/ZerBea/hcxdumptool/issues/227#issuecomment-1216326555 After a reboot and a fresh plug in, the settings by iwconfig (and hcxdumptool, too) are ignored completely (without an ERROR): https://github.com/ZerBea/hcxdumptool/issues/227#issuecomment-1216452614

I suspect a driver problem, because iwconfig is affected in the same way like hcxdumptool.