search

ZerBea / hcxdumptool

Small tool to capture packets from wlan devices.
MIT License
1.83k stars 395 forks source link

Not attacking and deauthenticating clients #121

Closed fa1rid closed 4 years ago

fa1rid commented 4 years ago

Hi ZerBea,

Thanks for the nice tool. The tool is working fine when a device connects to the AP and I can capture the handshake, however if clients are already connected there's no de-authentication happening. I tried both 2.4GHz and 5Ghz. How can I disconnect clients so I can capture the handshake?

Thanks for help!

ZerBea commented 4 years ago

I closed that issue report, because the new scan lists are implemented. The driver issues are reporter on kernel.org and we have to wait for a fix. You can still ask your questions here.

fa1rid commented 4 years ago

Nice! I understand many things now. Also by trying and testing by myself I learn a lot by observing the behavior every run. You didn't tell me about M3M4zeroed. When I see:

M1M2
M2M3
M3M4ZEROED

as I know wen need only M2M3. How's it different then if we don't see zeroed mentioned?

Please explain the use case of hcxpcapngtool with option --all with example, how is it useful and when to use it?

Thank you.

fa1rid commented 4 years ago

BTW, do you know how to install OpenCL runtime for Intel CPUs on Debian based machines? I'm struggling with that. I have 2X Xeon® E5-4667 v3 with 64 cores in total, it's a waste not to use with hashcat.

ZerBea commented 4 years ago

We distingush 2 M4 EAPOL frames: M4 with SNONCE (f283f5f0db28c7202635acc196ce0a2db6378e7181cbfcb76de18e68cedb7dd5) M4 with zeroed SNONCE (0000000000000000000000000000000000000000000000000000000000000) From the first one, we can recover the PSK (in combination with an M1 or M3 from the AP). From the second one, it is not possible.

hcxpcapngtool convert only the best handshake for an ESSID - MAC_AP -MAC_STA. That keeps the hash file small. hcxpcapngtool --all convert all handshakes. This is mainly for analysis purpose on M1M2 pairs

examples: $ hcxpcapngtool -o best.22000 .pcapng $ hcxpcapngtool --all -o all.22000 .pcapng

Compare both hash files (best.22000 and all.22000) and you'll notice that all.22000 contain more records.

This is the upstream of intel compute runtime: https://01.org/compute-runtime

or via Debian packet manager: https://packages.debian.org/source/sid/intel-compute-runtime https://packages.qa.debian.org/i/intel-compute-runtime.html

ZerBea commented 4 years ago

Please notice: I try to fix reported issues, very soon. But in 99,9% this issues are related to the device driver (driver doesn't support ioctl system calls or driver doesn't support full monitor mode) or a misconfigured system (crda, NetworkManager/wpa-suplicant running, virtual interface wlanXmon instead of physical interface). Due to high density attacks, the hardware requirements of hcxdumptool are much higher than running e.g. aircrack. The same applies to the user's knowledge. There is no simple script to get hcxtools/hcxdumptool work. The user must know what she/he is doing. Otherwise the results are not as expected.

fa1rid commented 4 years ago

Yes I understand your points.

So for the EAPOL, if I get this it means PSK is not recoverable (Is it called unauthenticated handshake?) :

M1M2
M2M3
M3M4ZEROED

but if I get this it means it's recoverable, right?

M1M2
M2M3
M3M4
ZerBea commented 4 years ago

Not 100% correct:

M1M2 (challenge = not authorized) M2M3 (confirm AP = authorized) M3M4 (confirm CLIENT = authorized) M1M4 (confirm CLIENT = authorized)

M1M2 (challenge = not authorized) M2M3 (confirm AP = authorized) M3M4ZEROED (confirm CLIENT = authorized but you can't calculate the PSK from this message pair due to zeroed SNONCE) M1M4ZEROED (confirm CLIENT = authorized but you can't calculate the PSK from this message pair due to zeroed SNONCE)

A valid PSK is recoverable from every NONZEROED message pair (one message from the AP M1 or M3 the other message from the CLIENT M2 or M4). Some of them are challenges (M1M2) = not authorized = CLIENT can belong to a different network Some of them are confirmations (M2M3, M3M4 M1M4) = authorized = CLIENT belong to this network

fa1rid commented 4 years ago

Here's an example from my network scan:

15:10:28   6 ffffffffffff 101xxxxfc479 MyBSSID [BEACON]
15:10:43   5 507xxxx1d6dd 008xxxx35459 MyBSSID-5G [ROGUE PROBERESPONSE]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M1M2 EAPOLTIME:3320 RC:4 KDV:2]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M2M3 EAPOLTIME:8947 RC:5 KDV:2]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M3M4ZEROED EAPOLTIME:2836 RC:5 KDV:2]
15:11:29   6 4c1xxxxdd479 008xxxx3545a MyBSSID [ROGUE PROBERESPONSE]
15:11:29   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [PROBERESPONSE]
15:11:30   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [AUTHENTICATION]]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M1M2 EAPOLTIME:3807 RC:3 KDV:2]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M2M3 EAPOLTIME:7494 RC:4 KDV:2]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M3M4ZEROED EAPOLTIME:3408 RC:4 KDV:2]

Why did I get EAPOL handshake two times from the same client? and why I have [AUTHENTICATION] one time only and I have two handshakes? what does all that mean please? Thanks again for your effort.

ZerBea commented 4 years ago

hcxdumptool is an attack tool. In case of a successful attack, you will receive the EAPOL messages. But hcxdumptool is also a passive dumper. In case of a transmitted EAPOL message, it will show you the message and it will store it. That means, every time your CLIENT connect to your network, hcxdumptool will receive it and store it.

ZerBea commented 4 years ago

To avoid spamming the real time waterfall display, hcxdumptool print some information only once at first occurrence. It is described in --help:

--enable_status=<digit>            : enable real-time display (waterfall)
                                     only incomming traffic
                                     only once at the first occurrence due to MAC randomization of CLIENTs
ZerBea commented 4 years ago

Some examples: EAPOL frames and EAP frames are important. So hcxdumptool will print every detected message pair. Authentications and associations are not important. So only the first one is shown. Beacons are useless. So only the first one is shown.

fa1rid commented 4 years ago

Aha, that's why, you are hiding them. Alright fine, thanks for letting me know :)

fa1rid commented 4 years ago

Can you please elaborate on authenticated handshake and unauthenticated handshake. I once captured unauthenticated one but I don't remember what was the message showing in hcxdumptool output.

fa1rid commented 4 years ago

Okay I found the unauthenticated one

SSID.......: MySSID
MAC_AP.....: 302xxxxxf871 (unknown)
MAC_CLIENT.: 0ccxxxxx5482 (unknown)
VERSION....: 802.1X-2001 (1)
KEY VERSION: WPA2
REPLAYCOUNT: 64590
RC INFO....: NC not required
RC INFO....: ROGUE attack / NC not required
MP M1M2 E2.: challenge
MIC........: 1bf4b24878a84f59336ae7c526d05756

Is the PSK recoverable from this?

ZerBea commented 4 years ago

Yes, you can recover a PSK from this message pair. The recovered PSK will belong to the network shown as MySSID.

ZerBea commented 4 years ago

Please convert your example from here: https://github.com/ZerBea/hcxdumptool/issues/121#issuecomment-655455607 $ hcxpcapngtool --all -o all.22000 test.pcapng and $ hcxpcapngtool -o best.22000 test.pcapng

Than compare both files. You'll notice that you have much more handshakes to choose when running $ hcxhashtool -i all.22000 --info=stdout than running $ hcxhashtool -i best.22000 --info=stdout

fa1rid commented 4 years ago

Please convert your example from here: #121 (comment) $ hcxpcapngtool --all -o all.22000 test.pcapng and $ hcxpcapngtool -o best.22000 test.pcapng

Than compare both files. You'll notice that you have much more handshakes to choose when running $ hcxhashtool -i all.22000 --info=stdout than running $ hcxhashtool -i best.22000 --info=stdout

What does that mean? I mean what's the point you are telling me?

ZerBea commented 4 years ago

Running by default, hcxpcapngtool choose and convert only the best message pair for a hashcat/JtR task. Running --all, hcxpcapngtool convert all message pairs. Now, you can choose (running hcxhashtool) the best handshake for a hashcat/JtR task. That is a big difference!

fa1rid commented 4 years ago

hcxhastool -i test.22000 --essid-group

I prefer if you can make it output ESSID name next to the hex in the file name, so it will be something like this:

416e64....-ESSID_name.22000

It's difficult now to know which essid is which by looking at the hex Also it's time consuming to look at the info with --info and extract what you want.

ZerBea commented 4 years ago

No. We decided HEX because an ESSID can contain characters from 0x00 to 0xff: "The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters" https://en.wikipedia.org/wiki/Service_set_(802.11_network) Using this characters can destroy your file system and printing this characters can destroy your terminal. Conversion from HEX to ASCII can be done in an easy way, running bash scripts and bash tools, pearl scripts or whoismac -x

fa1rid commented 4 years ago

hcxdumptool still capturing handshakes and PMKIDs from access points that are different than the specified in the list. Why?

ZerBea commented 4 years ago

That behavior is explained here: https://github.com/ZerBea/hcxdumptool/issues/121#issuecomment-655463332 In every case, hcxdumptool is a passive dumper. It captures everything on the channel. The Filterlists (filterlist_ap and filterlist_client) are only in the transmit branch. Depending on filtermode, entries are protected or will be attacked. If you don't want this behavior, you must set the Berkeley Packet Filter (BPF).

--bpfc=<file>                      : input Berkeley Packet Filter (BPF) code
                                     steps to create a BPF (it only has to be done once):
                                      set hcxdumptool monitormode
                                       $ hcxumptool -m <interface>
                                      create BPF to protect a MAC
                                       $ tcpdump -i <interface> not wlan addr1 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
                                       recommended to protect own devices
                                      or create BPF to attack a MAC
                                       $ tcpdump -i <interface> wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 -ddd > attack.bpf
                                       not recommended, because important pre-authentication frames will be lost due to MAC randomization of the CLIENTs
                                      use the BPF code
                                       $ hcxumptool -i <interface> --bpfc=attack.bpf ...
                                     see man pcap-filter for a list of all filter options
ZerBea commented 4 years ago

By latest commit: https://github.com/ZerBea/hcxdumptool/commit/90a0e0b317a4c7cd7d2da14d78530c0d52883e7f I added this to help menu:

affected by filter: incoming and outgoing traffic

--bpfc=<file>                      : input Berkeley Packet Filter (BPF) code
                                     affected: incoming and outgoing traffic
                                     steps to create a BPF (it only has to be done once):
                                      set hcxdumptool monitormode
                                       $ hcxumptool -m <interface>
                                      create BPF to protect a MAC
                                       $ tcpdump -i <interface> not wlan addr1 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
                                       recommended to protect own devices
                                      or create BPF to attack a MAC
                                       $ tcpdump -i <interface> wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 -ddd > attack.bpf
                                       not recommended, because important pre-authentication frames will be lost due to MAC randomization of the CLIENTs
                                      use the BPF code
                                       $ hcxumptool -i <interface> --bpfc=attack.bpf ...
                                     see man pcap-filter for a list of all filter options

read more, here: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter and here: https://biot.com/capstats/bpf.html The BPF is a very powqerfull and fast filter.

affected by filter: outgoing traffic

--filtermode=<digit>               : mode for filter list
                                     mandatory in combination with --filterlist_ap and/or --filterlist_client
                                     affected: only outgoing traffic
                                               in every case, hcxdumptool is a passive dumper and it will capture the whole traffic on the channel
                                     0: ignore filter list (default)
                                     1: use filter list as protection list
                                        do not interact with ACCESS POINTs and CLIENTs from this list
                                     2: use filter list as target list
                                        only interact with ACCESS POINTs and CLIENTs from this list
                                        not recommended, because some useful frames could be filtered out
fa1rid commented 4 years ago

I got one PKMID on 5G band but hcxpcapngtool says it useless PKMID, why?

ZerBea commented 4 years ago

Like zeroed M4 messages, PMKIDs and PMKs can be zeroed, too. You can't recover the PSK from them. hcxdumptool and hcxpcapngtool detect this an inform you.

fa1rid commented 3 years ago

Any update on 5GHz chipsets that can de-authenticate connected users? Anything supports full monitor mode?

ZerBea commented 3 years ago

This one is working fine (README.md): ALFA AWUS036ACM, ID 0e8d:7612 MediaTek Inc. MT7612U 802.11a/b/g/n/ac Wireless Adapter As well as the devices which are based on RT5572 chipset, e.g.: CSL 300MBit 300649, ID 148f:5572 Ralink Technology, Corp. RT5572 Wireless Adapter

Both drivers are part of the mainline kernel. MT7612U driver mt76x2: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/mediatek/mt76/mt76x2?h=v5.14.9 RT5572 driver rt2x00: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/ralink/rt2x00?h=v5.14.9

Please notice: Regulatory domain must be set to allow to transmit on 5GHz. Explained here: https://hashcat.net/forum/thread-10378-post-53719.html#pid53719

fa1rid commented 3 years ago

I have difficulties finding the mentioned models for sale online. Do you know where can I buy them?

How about the RTL8814AU (ALFA AWUS1900)?

ZerBea commented 3 years ago 
Not recommended WiFi chipsets (README.md):
Intel PRO/Wireless (due to MICROCODE issues)
Broadcom (neither monitor mode nor frame injection)
Realtek RTL8811AU, RTL8812AU, RTL 8814AU (due to NETLINK dependency)

There is no RTL 8814AU mainline kernel driver and you have to install the driver from here: https://github.com/aircrack-ng/rtl8814au Beside the NETLINK dependency, there are lot of problems: https://github.com/aircrack-ng/rtl8814au/issues

Please notice that hcxdumptool doesn't support NETLINK, because NETLINK communication is very much asynchronous. Instead it use ioctl() system calls, which are purely synchronous. The difference is explained here: https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls?share=1

BTW: This adapters (both mt76 chipsets) are working fine, too: TP-LINK Archer T2UH, ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter) ASUS USB-AC51, ID 0b05:17d1 ASUSTek Computer, Inc. AC51 802.11a/b/g/n/ac Wireless Adapter [Mediatek MT7610U] The driver is part of the mainline kernel and well maintained: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/mediatek/mt76/mt76x0?h=v5.14.9

fa1rid commented 3 years ago

Oh I didn't see the RTL 8814AU because there is space after RTL Yes I found the TP-LINK Archer T2UH. I also found Netgear A6210 on Amazon, it should have the MT7612U. It's better than the MT7601U I guess?

ZerBea commented 3 years ago

MT7612U is not better than MT7601U, but it is much newer. All mt76 drivers are fantastic and well maintained. Latest Linux kernel is mandatory! I purchased two TP-LINK Archer T2UH, before they are sold out. Both of them are running fine on 2.4 and 5GHz. The same applies to the ASUS USB-AC51.