Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeout problem with RT3570 Wireless card #303

Open
mtnsec opened this issue Feb 6, 2020 · 34 comments
Open

Timeout problem with RT3570 Wireless card #303

mtnsec opened this issue Feb 6, 2020 · 34 comments

Comments

@mtnsec
Copy link

mtnsec commented Feb 6, 2020

This problem only occurs with RA5370 (driver rt2800usb, I have two of these made by different manufacturers and both have the same problem) wireless cards (I have more than one, and they all exhibit this behavior). I have success with rtl8812au cards. I went through your troubleshooting guide here: https://github.com/t6x/reaver-wps-fork-t6x/wiki/Troubleshooting

My results are below:

First, info about my setup:

Kali 2020.1 on a Raspberry Pi4, kernel info:

root@kali:~# uname -a
Linux kali 4.19.93-Re4son-v8l+ #1 SMP PREEMPT Tue Jan 7 22:53:24 UTC 2020 aarch64 GNU/Linux

Wireless card driver info:


phy1	wlan0		rt2800usb	Ralink Technology, Corp. RT5370

I had previously been trying to use wifite2, and the WPS tests with reaver have been failing so I'm now working directly with reaver and not wifite. Here is the error/problem (I'm using -N because I saw in an older issue here that Ralink cards require it. All adding -N did was increase the amount of time before it times out and fails):

root@kali:~# reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

Reaver v1.6.5 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <[email protected]>

[+] Switching wlan0 to channel 3
[+] Waiting for beacon from D8:0D:17:14:2F:6E
[+] Received beacon from D8:0D:17:14:2F:6E
[+] Vendor: RalinkTe
WPS: A new PIN configured (timeout=0)
WPS: UUID - hexdump(len=16): [NULL]
WPS: PIN - hexdump_ascii(len=8):
     31 32 33 34 35 36 37 30                           12345670        
WPS: Selected registrar information changed
WPS: Internal Registrar selected (pbc=0)
WPS: sel_reg_union
WPS: set_ie
WPS: cb_set_sel_reg
WPS: Enter wps_cg_set_sel_reg
WPS: Leave wps_cg_set_sel_reg early
WPS: return from wps_selected_registrar_changed
[+] Trying pin "12345670"
send_packet called from deauthenticate() 80211.c:333
send_packet called from authenticate() 80211.c:364
[+] Sending authentication request
[!] Found packet with bad FCS, skipping...
send_packet called from associate() 80211.c:417
[+] Sending association request
[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
send_packet called from resend_last_packet() send.c:161
...<snip>...
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred

Here is the aireplay injection test result:

root@kali:~# aireplay-ng -9 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E wlan0 00:36:41  Waiting for beacon frame (BSSID: D8:0D:17:14:2F:6E) on channel 3
00:36:41  Trying broadcast probe requests...
00:36:41  Injection is working!
00:36:43  Found 1 AP 

00:36:43  Trying directed probe requests...
00:36:43  D8:0D:17:14:2F:6E - channel: 3 - 'TP-Link_2F6E'
00:36:43  Ping (min/avg/max): 1.291ms/2.915ms/6.190ms Power: -23.20
00:36:43  30/30: 100%

Here is the association test result:

root@kali:~# aireplay-ng -1 0 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E -h 1c:bf:ce:90:1e:8a wlan0 
00:50:30  Waiting for beacon frame (BSSID: D8:0D:17:14:2F:6E) on channel 3

00:50:30  Sending Authentication Request (Open System)
00:50:30  Authentication successful
00:50:30  Sending Association Request [ACK]
00:50:30  Association successful :-) (AID: 1)

The next step says to take a packet capture and determine if there is a reply to the EAPOL messages. I've attached my capture, I see the router responding but not the same way that it does in a successful attack.

Also for your reference, I'm attaching a packet capture of the same attack against the same router using a rtl8812au wireless card. This attack succeeds, so it rules out the problem at the router. I have tested both of these cards against multiple WPS-enabled routers with the same results.

For your reference for filtering the captures:

Router MAC = d8:0d:17:14:2f:6e
RA5370 MAC = 1c:bf:ce:90:1e:8a
rtl8812au MAC = 00:c0:ca:96:67:27

captures.tar.gz

@rofl0r
Copy link
Collaborator

rofl0r commented Feb 6, 2020

[!] Found packet with bad FCS, skipping...

this suggests the driver generates bad packets. it would be interesting to know which exact packet caused this.

[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)

this is interesting, i can't see an association response in the ra3570.pcap

@mtnsec
Copy link
Author

mtnsec commented Feb 6, 2020

this is interesting, i can't see an association response in the ra3570.pcap

The pcap I uploaded was taken during the attack, I can take one during the aircrack association test if you need it?

Editing to attach new pcap: rt5370_assoc.pcap.gz

@rofl0r
Copy link
Collaborator

rofl0r commented Feb 6, 2020

reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

The pcap I uploaded was taken during the attack, I can take one during the aircrack association test if you need it?

i assumed you used reaver for the association step, since your command line lacks -A parameter

@mtnsec
Copy link
Author

mtnsec commented Feb 6, 2020

That's correct, I did not use -A with reaver. The first pcap I uploaded is from the failed reaver commandline you quoted above:

root@kali:~# reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N

The rt5370_assoc.pcap is from the aircrack association test using this commandline:

aireplay-ng -1 0 -a D8:0D:17:14:2F:6E -e TP-Link_2F6E -h 1c:bf:ce:90:1e:8a wlan0 

@rofl0r
Copy link
Collaborator

rofl0r commented Feb 6, 2020

please checkout git commit fd5dc95
recompile reaver, then use reaver without -A and record a pcap in parallel, as well as use -O foo.pcap option to write an additional pcap with faulty packets (please also provide reaver output from that session)

@mtnsec
Copy link
Author

mtnsec commented Feb 6, 2020

Edited - correct pcaps are attached. Thanks --

pcap from newly compiled reaver with -O:
reaver_output.pcap.gz

pcap from concurrent tcpdump:
reaver_tcpdump.pcap.gz

Thanks!

@mtnsec
Copy link
Author

mtnsec commented Feb 6, 2020

Reaver output:

root@kali:~/reaver-wps-fork-t6x/src# ./reaver --interface wlan0 --bssid D8:0D:17:14:2F:6E --channel 3 -vvv --pixie-dust 1 -N -O reaver_output.pcap

Reaver v1.6.5-git-9-gfd5dc95 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner <[email protected]>

[+] Switching wlan0 to channel 3
[+] Waiting for beacon from D8:0D:17:14:2F:6E
[+] Received beacon from D8:0D:17:14:2F:6E
[+] Vendor: RalinkTe
WPS: A new PIN configured (timeout=0)
WPS: UUID - hexdump(len=16): [NULL]
WPS: PIN - hexdump_ascii(len=8):
     31 32 33 34 35 36 37 30                           12345670        
WPS: Selected registrar information changed
WPS: Internal Registrar selected (pbc=0)
WPS: sel_reg_union
WPS: set_ie
WPS: cb_set_sel_reg
WPS: Enter wps_cg_set_sel_reg
WPS: Leave wps_cg_set_sel_reg early
WPS: return from wps_selected_registrar_changed
[+] Trying pin "12345670"
send_packet called from deauthenticate() 80211.c:337
send_packet called from authenticate() 80211.c:368
[+] Sending authentication request
[!] Found packet with bad FCS, skipping...
send_packet called from associate() 80211.c:421
[+] Sending association request
[+] Associated with D8:0D:17:14:2F:6E (ESSID: TP-Link_2F6E)
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
send_packet called from resend_last_packet() send.c:161
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
send_packet called from send_eapol_start() send.c:48
[+] Received deauth request
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
send_packet called from resend_last_packet() send.c:161
^Csend_packet called from send_termination() send.c:142

[+] Nothing done, nothing to save.

@rofl0r
Copy link
Collaborator

rofl0r commented Feb 6, 2020

the FCS checksum thing was a red herring. it's been fixed in the very next commit:
6191595

i guess a 1.6.6 release is really due...

the tcpdump capture is interesting. we have the first assoc request packet immediately followed by EAPOL start, as if reaver would misinterpret one of the authentication success packets as an association success one.

@mtnsec
Copy link
Author

mtnsec commented Feb 6, 2020

I just compiled the latest commit and tested. It still fails but the errors are much different now. Attaching console output and pcaps:

reaver_g6191595_console.txt
reaver_g6191595_output.pcap.gz
reaver_g6191595_tcpdump.pcap.gz

@rofl0r
Copy link
Collaborator

rofl0r commented Feb 7, 2020

you need -N, its omission caused the premature abort you're seeing

@mtnsec
Copy link
Author

mtnsec commented Feb 7, 2020

Thanks! I added -N back, and at first saw the same errors as previous builds. After crtl-C and restarting reaver 3 times, I had success.

After rebooting the router to repeat the tests, it appears that I need to stop and restart reaver multiple times before it succeeds, so the success is intermittent. I started taking pcaps again until I could get a second success. It took 10 tries, with the 10th one being the success. I've attached all 10 related pcaps and the output from the 7th try through the successful one (My buffer cut off all of failures before I thought to copy and paste them all, but the errors prior to success are all the same). Any ideas how I can get more consistent results?

reaver_with-N_1-10.pcaps.tar.gz
reaver_10th_Try.txt

Thank you!!

@mtnsec
Copy link
Author

mtnsec commented Feb 21, 2020

Good morning! Just wondering if you have any suggestions for how to get more consistent results with the ra5370 wireless card?
Thanks!

@mtnsec
Copy link
Author

mtnsec commented Mar 3, 2020

Just came to update that it appears to be any card that uses the rt2800usb driver. I have also tested a ra5372 card with the same inconsistent results. Approx 10% success rate against known, vulnerable APs.

100% success rate against the same networks with cards that use rtl8812au drivers.

Unfortunately, I can't just use the known good card. My use case requires the cards that use the rt2800usb driver.

Any updates would be most appreciated! Thanks!

@masharia-john
Copy link

have you guys tried null pin.....so far all TP LINK's routers have been a pain,especially the vendors RalinkTe and AtherosC

@masharia-john
Copy link

@mtnsec if you have 2 adapters try attacking a TP LINK router at the same time, for one of the terminals specify the argument -p as (-p '') without the brackets and include the quotation marks.....the TP LINK router should give up the pin.

@masharia-john
Copy link

Though this is out of topic.........is there a way you can Crack a captured PMKID offline from a router....using the same consept as the pixiewps employs without the time consumption in hcxdumptools and hashcat and the possibility of a trillionth passphrase actually getting to work.

@mtnsec
Copy link
Author

mtnsec commented Mar 6, 2020

@masharia-john

The problem happens only with wifi cards that use the rt2800usb driver. The exact same attacks against the exact same networks succeed with wifi cards that use the rtl8812 driver. I'll double check null pin attacks, but I vaguely remember that particuar attack fails against the targets we're testing regardless of whether we're using a Ralink or Realtek wifi card? I have other WPS targets (not TP-link) that we can test and the results are consistent.

The Ralink cards have about a 10% pixie dust success rate when the Realtek cards have a 100% success rate.

What we really need is a solution for the Ralink cards, because we don't have the option to buy enough Realtek (or other working chipset) cards for this project. :(

@masharia-john
Copy link

Okay...lemme see if i can find a method to help.

@masharia-john
Copy link

send me your Ralink specs i.e range,version number...etc. I need to buy the exact one(s) your using.

@kcdtv kcdtv changed the title Timeout problem with RA3570 Wireless card Timeout problem with RT3570 Wireless card Mar 9, 2020
@mtnsec
Copy link
Author

mtnsec commented Mar 10, 2020

@masharia-john
Copy link

got it....i've already ordered the tenda and panda.....will get back to you if i find a solution.

@mtnsec
Copy link
Author

mtnsec commented Mar 11, 2020

I appreciate the help!

@1yura
Copy link

1yura commented Mar 26, 2020

mtnsec, try this patch
https://0x0.st/iBeF.tgz
for this release
https://github.com/t6x/reaver-wps-fork-t6x/releases/download/v1.6.6/reaver-1.6.6.tar.xz
cd reaver-1.6.6/src
patch -p2 < reaver-1.6.6-ralink.patch

@rofl0r
Copy link
Collaborator

rofl0r commented Mar 29, 2020

@1yura

                        case 4:
-                               ret = process_authenticate_associate_resp(0);
+                               ret = process_authenticate_associate_resp(1);

this looks like (0) was an oversight to begin with, and we should apply it generally, don't you think?

@1yura
Copy link

1yura commented Mar 29, 2020

Yes.
And tracking de-authentication packets is generally useful.

@mtnsec
Copy link
Author

mtnsec commented Mar 30, 2020

Thanks! The patch provided by @1yura fixed it for me. :)

@rofl0r
Copy link
Collaborator

rofl0r commented Apr 5, 2020

@1yura any chance you could get the patch into an upstreamable form ?
i already tested the (1) change and it works OK for me.

@1yura
Copy link

1yura commented Apr 5, 2020

Of course )

@masharia-john
Copy link

@1yura Thanks man....@mtnsec i guess the issue is fixed

@mtnsec
Copy link
Author

mtnsec commented May 5, 2020

Just checking in to see if there's a plan to incorporate this patch into the official release? I have multiple devices to install, and I've been holding off waiting for the ability to just clone and build, instead of clone, patch and build...

@rofl0r
Copy link
Collaborator

rofl0r commented Jul 9, 2020

i was hoping that @1yura prepares a PR with commits explaining the single changes he made and without //HACK comments, i.e. "upstreamable"

@1yura
Copy link

1yura commented Jul 10, 2020

This patch was created several versions ago. Now I discovered it is enough just

diff -rup reaver-wps-fork-t6x-1.6.5/src/80211.c reaver-wps-fork-t6x-1.6.5-patched/src/80211.c
--- reaver-wps-fork-t6x-1.6.5/src/80211.c	2018-05-11 20:11:29.000000000 +0300
+++ reaver-wps-fork-t6x-1.6.5-patched/src/80211.c	2020-07-10 06:29:12.805079597 +0300
@@ -299,7 +299,7 @@ int reassociate(void)
 				state++;
 				break;
 			case 4:
-				ret = process_authenticate_associate_resp(0);
+				ret = process_authenticate_associate_resp(1);
 				if(ret) state++;
 				else return 0;
 				break;

And use -N option.

rofl0r added a commit that referenced this issue Jul 12, 2020
bug was introduced in 488f2e7.
the second call to the new function was always meant to use 1 as parameter,
but i typo'ed. thanks to @1yura for the patch.

addressing #303
@rofl0r
Copy link
Collaborator

rofl0r commented Jul 12, 2020

@1yura: thanks. is there a specific reason you use 1.6.5 and not 1.6.6 ?

@mtnsec: i pushed @1yura's fix to master, could you please try if current git version works for you without the patch ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@rofl0r @masharia-john @1yura @mtnsec and others