Compatible issue. Test timed out! Retry to be sure, or manually check result
juige opened this issue · 8 comments
Hi Guys,
I followed the guide to setup my test environment using Alfa AWUS036NHA and DLink DWA-160 A2 to test my AX AP. The desktop using live USB image you provided seems work properly. But encountering time out issue when doing sanity check (PING I, E, E)。
I had also try to add --icmp-size 100 but got fail. Do you have any suggestion because the FNF teting environment seems working fine on my AC AP. We could pass the sanity check on AC AP.
Thanks a lot.
The fail log is as following:
(venv) root@ubuntu:/home/ubuntu/fragattacks/research# ./fragattack.py wlx00c0ca9911e3 ping I,E,E
[11:33:28] This is FragAttack version 1.3.
[11:33:28] Detected ath9k_htc, using injection bug workarounds
[11:33:28] Using interface monwlx00c0ca991 (ath9k_htc) to inject frames.
[11:33:28] Starting wpa_supplicant using: ../wpa_supplicant/wpa_supplicant -Dnl80211 -i wlx00c0ca9911e3 -cclient.conf -W -K
Successfully initialized wpa_supplicant
wlx00c0ca9911e3: SME: Trying to authenticate with 00:03:7f:12:cc:0f (SSID='leo_test' freq=2412 MHz)
wlx00c0ca9911e3: Trying to associate with 00:03:7f:12:cc:0f (SSID='leo_test' freq=2412 MHz)
wlx00c0ca9911e3: Associated with 00:03:7f:12:cc:0f
wlx00c0ca9911e3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlx00c0ca9911e3: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
[11:33:30] Station: setting BSS MAC address 00:03:7f:12:cc:0f
wlx00c0ca9911e3: EAPOL-TX 00:03:7f:12:cc:0f 0103007502010a000000000000000000014e0f9ab1d7508e6d14ce4d9affa0e29e262342b8403bae2744de364a210a905c0000000000000000000000000000000000000000000000000000000000000000f675cfb2d15c4bd657aecc6717b1f135001630140100000fac040100000fac040100000fac020000
[11:33:30] Action.StartAuth
[11:33:30] [Injected packet] <Dot11 subtype=8 type=Data FCfield=to-DS addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=00:03:7f:12:cc:0f SC=256 |<Dot11QoS TID=1 |<LLC dsap=0xaa ssap=0xaa ctrl=3...
wlx00c0ca9911e3: EAPOL-TX 00:03:7f:12:cc:0f 0103007502010a000000000000000000024e0f9ab1d7508e6d14ce4d9affa0e29e262342b8403bae2744de364a210a905c0000000000000000000000000000000000000000000000000000000000000000697658f8f120d83791d6777312e23466001630140100000fac040100000fac040100000fac020000
wlx00c0ca9911e3: EAPOL-TX 00:03:7f:12:cc:0f 0103005f02030a0000000000000000000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b7f6cf85d072b4ca44da8b0ceae111980000
wlx00c0ca9911e3: WPA: Key negotiation completed with 00:03:7f:12:cc:0f [PTK=CCMP GTK=CCMP]
wlx00c0ca9911e3: CTRL-EVENT-CONNECTED - Connection to 00:03:7f:12:cc:0f completed [id=0 id_str=]
[11:33:30] [Injected packet] <Dot11 subtype=8 type=Data FCfield=to-DS addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=00:03:7f:12:cc:0f SC=272 |<Dot11QoS TID=1 |<LLC dsap=0xaa ssap=0xaa ctrl=3...
[11:33:30] Action.BeforeAuth
[11:33:30] [Injected packet] <Dot11 subtype=8 type=Data FCfield=to-DS addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=00:03:7f:12:cc:0f SC=288 |<Dot11QoS TID=1 |<LLC dsap=0xaa ssap=0xaa ctrl=3...
[11:33:30] Obtained encryption keys from daemon
[11:33:30] Action.AfterAuth
[11:33:31] Action.Connected
[11:33:31] Sending DHCP discover with XID 1833475787
[11:33:31] [Injected packet] <Dot11 subtype=8 type=Data FCfield=to-DS+protected addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=ff:ff:ff:ff:ff:ff SC=304 |<Dot11QoS TID=1 |<Dot11CCMP PN0=1 PN1=...
[11:33:32] Received DHCP offer, sending DHCP request.
[11:33:32] Sending DHCP request with XID 1833475787
[11:33:32] [Injected packet] <Dot11 subtype=8 type=Data FCfield=to-DS+protected addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=ff:ff:ff:ff:ff:ff SC=320 |<Dot11QoS TID=1 |<Dot11CCMP PN0=2 PN1=...
[11:33:32] Received DHCP ack. My ip is 192.168.1.209 and router is 192.168.1.1.
[11:33:32] Will now use peer MAC address 96:68:14:0b:ec:b6 instead of the BSS 00:03:7f:12:cc:0f.
[11:33:32] Generating ping test
[11:33:32] Using key 38b61736923afbfa7b86291164718113 to encrypt <Dot11 subtype=8 type=Data FCfield=to-DS+MF addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=96:68:14:0b:ec:b6 SC=336 |<Dot11QoS TID=2 |<Raw load='\xaa\xaa\x03\x00\x00\x00\x08\x00E\x00\x00*\x00\x01\x00\x00@\x01\xf6\xaf\xc0\xa8\x01\xd1\xc0' |>>>
[11:33:32] [Injected] <Dot11 subtype=8 type=Data FCfield=to-DS+MF+protected addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=96:68:14:0b:ec:b6 SC=336 |<Dot11QoS TID=2 |<Dot11CCMP PN0=3 PN1=1 key_id=0 ext_iv=1 PN2=0 PN3=0 PN4=0 PN5=0 |<Raw load='\xa4\xb9%\xf6\n\x0f\xa6\x07\xc96\x85\xab9r\x89\x9ep\x90\xc8\xcc\xab\x06\xc6`\xfa' |<Raw load='\x0b\xde\x99\xae\x04a\xb5\x98' |>>>>>
[11:33:32] Using key 38b61736923afbfa7b86291164718113 to encrypt <Dot11 subtype=8 type=Data FCfield=to-DS addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=96:68:14:0b:ec:b6 SC=337 |<Dot11QoS TID=2 |<Raw load='\xa8\x01\x01\x08\x00\t\x14\x00\x00\x00\x00test_ping_icmp' |>>>
[11:33:32] [Injected] <Dot11 subtype=8 type=Data FCfield=to-DS+protected addr1=00:03:7f:12:cc:0f addr2=00:c0:ca:99:11:e3 addr3=96:68:14:0b:ec:b6 SC=337 |<Dot11QoS TID=2 |<Dot11CCMP PN0=4 PN1=1 key_id=0 ext_iv=1 PN2=0 PN3=0 PN4=0 PN5=0 |<Raw load='\x0btY\x81\x0bo \xabQf\xb3\xeb\xeb\xa0\tH\xe8f\xbc\x86\x8f\xe6d\xc5\xb1' |<Raw load='\xdaPTG\x13\x06\x9d\' |>>>>>
[11:33:37] 96:68:14:0b:ec:b6: ARP: Ether / ARP who has 192.168.1.209 says 192.168.1.1 ==> Ether / ARP is at 00:c0:ca:99:11:e3 says 192.168.1.209 on lo
[11:33:37] >>> Test timed out! Retry to be sure, or manually check result.
[11:33:37] Closing daemon and cleaning up ...
wlx00c0ca9911e3: CTRL-EVENT-DISCONNECTED bssid=00:03:7f:12:cc:0f reason=3 locally_generated=1
nl80211: deinit ifname=wlx00c0ca9911e3 disabled_11b_rates=0
wlx00c0ca9911e3: CTRL-EVENT-TERMINATING
What do you mean by FNF? Fragment aNd Forge?
Double-check that the device under test support fragmentation. In Linux, connect to the AP, and then use iw list and iw phy phy1 set frag 256 to make it use fragmentation. Then send a large ping request and see if you get a response.
What do you mean by FNF? Fragment aNd Forge?
Double-check that the device under test support fragmentation. In Linux, connect to the AP, and then use
iw listandiw phy phy1 set frag 256to make it use fragmentation. Then send a large ping request and see if you get a response.
FNF = Fragment and Forge.
Thanks for quick reply. I will test it later.
Hi Vanhoefm,
BTW, one quick question. I got a little confused.
One of the basic behaviour(./fragattack.py wlan0 ping-frag-sep --pn-per-qos) got fail. And the other CVE got pass. Does that means the AP pass the frag test?
Thanks.
It means that there's no need to run commands that include the --pn-per-qos parameter. In other words, there will be no need to execute ping I,F,BE,AE --pn-per-qos.
The --pn-per-qos parameter is only useful in case ping-frag-sep fails.
Hi Vanhoefm,
Thanks about your great help. I had questions about CVE-2020-24588 and CVE-2020-26139 as following:
CVE-2020-24588
We got an testing output on 7.3. A-MSDU attack tests (§3 -- CVE-2020-24588) as following. I'm not sure I understand correctly about testing result.
-- CVE-2020-24588 testing result --
It means AP supports non-SPP A-MSDUs?
ping I,E --amsdu >>> TEST COMPLETED SUCCESSFULLY
It means AP defend A-MSDU injection attack?
ping I,E --amsdu-fake >>> test time out ! Retry to be sure, or manually result.
It mean AP defend A-MSDU bad injection attack?
ping I,E --amsdu-fake --amsdu-spp >>> test time out ! Retry to be sure, or manually result.
CVE-2020-26139
And one more question about testing environment setup about 8.7. AP forwards EAPOL attack tests (§6.6 -- CVE-2020-26139)
We setup 2 environment to sniffer the eapol packet as pic1 and pic2. Pic1 can not receive eapol packet (from 1st device to device 2nd device) on 2nd device. Pic2 can receive eapol packet on 3rd device by omnipeak(pic3). Which one is correct? Because we have doubt about the eapol packet is from 1st device to AP or AP to 2nd device.
If the eapol packet if from AP to 2nd device, it look like the AP is still vulnerable.
picture 1:
picture 2:
picture 3:
Thanks.
-- CVE-2020-24588 testing result --
ping I,E --amsdu >>> TEST COMPLETED SUCCESSFULLY
This means the device supports A-MSDU frames. This test doesn't give information about whether a device is vulnerable or not.
ping I,E --amsdu-fake >>> test time out ! Retry to be sure, or manually result.
If this test succeeds: "This behaviour is not ideal, although it is unlikely that an attacker can abuse this in practice (see Section 3.5 in the paper)."
If this test fails: doesn't mean anything.
ping I,E --amsdu-fake --amsdu-spp >>> test time out ! Retry to be sure, or manually result.
If this test succeeds: "This behaviour is not ideal, although it is unlikely that an attacker can abuse this in practice (see Section 3.5 in the paper)."
If this test fails: doesn't mean anything.
You can test whether a device is affected by CVE-2020-24588 using the amsdu-inject and amsdu-inject-bad test.
CVE-2020-26139
And one more question about testing environment setup about 8.7. AP forwards EAPOL attack tests (§6.6 -- CVE-2020-26139)
It looks like PC_A is capturing packets in monitor mode. I think the captured EAPOL packet is the Wi-Fi frame sent by the test tool to the access point: can you double-check what the transmitter (addr2) and receiver address are (addr1)? Note that a Wi-Fi frame has three addresses, and not all are shown in the provided screenshot. The AP is only vulnerable if it forwards the EAPOL frame, meaning the capture frame in monitor mode must have a transmitter address (addr2) equal to the access point.
So I don't think the AP is vulnerable.
Hi Vanhoefm,
Appreciate your help. Below is my testing result:
-- CVE-2020-24588 testing result --
amsdu-inject >>> test time out ! Retry to be sure, or manually result.
amsdu-inject-bad >>> test time out ! Retry to be sure, or manually result.
We test amsdu-inject and amsdu-inject-bad, and the result are "test time out ! Retry to be sure, or manually result."
It looks like the AP is not vulnerable in CVE-2020-24588.
--CVE-2020-26139 testing result --
We check the captured EAPOL. Its BSSID is AP's mac and the transmitter address/source address is the wireless mac where FNF tools has been executed. I suppose the vulnerable has been fixed.
Based on those results the AP indeed doesn't look vulnerable.