WPA3 something seems strange

File this under security concerns or food for thought.

Test scenario:

EA8300 v22.03.3
WPA3
802.11ac
5Ghz

When I manually connect or disconnect an iPad (or an android 10 cell phone) Kismet (running on a separate laptop) is reporting that it is capturing all 4 handshakes (and PMKID) after as few as 5-10 connection/disconnection cycles.

I only connect 1 device per AP. I turn the device on when I am using it. I turn it off when I am done. I have seen Kismet log in real time (and time stamps) this as an attack or exploit.

My neighbor's are running WPA2 and Kismet is not seeing this behaviour with those AP's compared to mine.

WPA3 claims to be harder to crack but it seems odd to me that it is bleeding handshakes like this. I don't know if this is an attack or if there is an evil twin or if Kismet is not handling WPA3 reporting correctly. I have no idea what is going on basically.

Sample Kismet message:

DEAUTHCODEINVALID EXPLOIT HIGH mm/dd/yyyy mac address transmitter A/source B/destination A Unknown deauthentication code e4 from network A
|       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 22.03.3, r20028-43d71ad93e
 -----------------------------------------------------

/etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'xxxxxxxxxxxxxxxx::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.114.1'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
	option peerdns '0'
	list dns 'xxxxxxxxx'

config interface 'wan6'
	option device 'eth1'
	option proto 'dhcpv6'
	option auto '0'
	option reqaddress 'try'
	option reqprefix 'auto'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 0'

config interface 'wg'
	option proto 'wireguard'
	option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
	list addresses 'xxxxxxxxxxxxxxx/32'
	list addresses 'xxxxxxxxxxxxxxxxxxxxxx/128'
	option peerdns '0'
	list dns 'xxxxxxxxxxxxx'

config wireguard_wg
	option description 'xxxx.conf'
	option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
	list allowed_ips '0.0.0.0/0'
	list allowed_ips '::0/0'
	option endpoint_host 'xxxxxxxxxxxxxxxxxxxxx'
	option endpoint_port '51820'
	option route_allowed_ips '1'
	option persistent_keepalive '25'


/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'
	option dnssec '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'


cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'
	option country 'CA'
	option channel '157'
	option txpower '30'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'I Love OpenWRT'
	option isolate '1'
	option wpa_disable_eapol_key_retries '1'
	option macaddr 'xxxxxxxxxxxxxxxxxxxxxxx'
	option encryption 'sae'
	option short_preamble '0'
	option key 'xxxxxxxxxxxxxxxxxxxxxxxxxx'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/a000000.wifi'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option disabled '1'

config wifi-device 'radio2'
	option type 'mac80211'
	option path 'platform/soc/a800000.wifi'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option disabled '1'

config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option ssid 'My Other AP'
	option network 'lan'
	option macaddr 'xxxxxxxxxxxxxxxxxxxxxxxxxx'
	option isolate '1'
	option encryption 'sae'
	option wpa_disable_eapol_key_retries '1'
	option key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Have a great day!

Follow up....

I tested the same router configured with WPA2 and it exhibits the same results as WPA3.

I believe this is normal because the client devices have to re-initiate a 4-way handshake to re-establish a connection on power up.

Many users just leave their client devices' wifi on all the time - which results in fewer handshakes as it has already been done.

I power my client devices off typically when not in use to reduce my surface.

Conclusion: Pebkac.

The handshake has to be transmitted somehow, so it's normal that you managed to capture something.

What's important is whether you can obtain the password from it:

It is my understanding that WPA2-PSK uses the password to generate the PMK used in the 4-way handshake. This means that if you can capture them, you can launch a bruteforce attack offline to recover the key.

WPA3 on the other hand uses the Dragonfly handshake to create the PMK. This handshake is designed to be resistant to active, passive and offline attacks, thus not a concern even if someone can sniff the handshake out. You can read more about WPA3 here.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.