Archer C6 V2.0(EU) Packet Drop or Ping Loss Issue on Wireless and LAN clients [possible bug in router firmware] #246
Comments
|
The segmentation fault is caused by the driver (NETLINK) in combination with Wireshark Unfortunately the ALFA AWUS036AC is running a Realtek Chipset (RTL8812AU) and the driver depend on NETLINK.
$ sudo hcxdumptool -o router_ddos.pcapng -i wlan0 --active_beacon --enable_status=15 |
|
The following options deactivate attacks against an AP: |
|
I forgot to mention that DDoS attacks are not implemented in hcxdumptool. |
|
I did the same test on my old Ralink2870/3070 with the driver rt2800usb, and I still got accidental DDoS against my router, my desktop pc is connected via cable and I couldn't even access my router home page for smthn about 20-30s, and to be even funnier there is nothing in the router's logs, idk maybe this router is just garbage, but again hash was correctly captured: However, I assume that this capture was done using the old method hence the EAPOL being mentioned. |
|
Please run: This |
|
If the router is not going down please do the next step: If the router is not going down please do the last step: |
|
Sorry for torturing you but I have encountered some additional issues with filters. and while doing ie |
|
Are you sure that your router crashed? Your PC was not longer able to connect to your router via wired eth0. Your command line is ok: Please notice that: It is important to understand that this kind of filtering (filtermode + filterlist) is active only on transmission branch. If you want to filter transmission branch and reception branch or reception branch only it is mandatory to add a BPF! This behavior is mentioned in --help: in contrast to the kernel filter (BPF): |
|
Example As you can see: Some more information about filtering (hcxdumptool use the same technique): The MAC addresses are explained here: BTW: This avoid a warning of hcxpcapngtool (missing frames) when converting a BPF filtered dump file. |
ZerBea
changed the title
|
You encountered and reported three problems. second: you can't connect to your router third: misunderstanding of filtering techniques (transmission filter, capture filter, display filter) This is bug tracker and none of the three reported bugs is a hcxdumptool bug. So I'm going to close this report. BTW: |
|
Thank you for your help to understand this, you are a jedi. Although, i'm not sure if this is entirely true (because I have eth0 down after deauth even with rtl2800usb), |
|
Looks like you're not the only one having a problem on 6.0.0-kali6-amd64. |
|
I think that crappy router software is also a separate issue. My other PC connected to the router with Ethernet cable was unable to connect to the router again. I'm quite sure that router software is just buggy because this shouldn't disable any router, AFAIK, hcxdumptools was basically just sniffing frames between an android phone and router and this router got disabled for a few minutes from just that. |
|
--disable_deauthentication doesn't disable attacks on an AP |
|
At the moment I'm trying to reproduce it. |
|
Added an old FRITZ!BOX Fon WLAN 7270 as second target to the test environment. |
|
Anyway, I can reproduce DDoS for all the other devices in the network every single time with ``--enable_status=15```, here is the pcapng from both the laptop and the desktop while this is happening I don't think I can do much more with it, maybe you should try to check this particular router if you will have your hands on ArcherC6v2. Cheers. |
|
You disabled deauthentications, but not ap_attacks. As a results, a REASSOCIATION attack was performed by hcxdumptool. If you don't want this you have to add --disable _ap_attacks If you don't want that hcxdumptool transmit you have to use the option --silent. Now the important parts: This is far behind of the timestamps of the first dump file. You pinged 1.1.1.1 (in www) and not the local IP of your router. The REASSOCIATION was done at 16:50:18.136695000 BTW: |
|
Timeframe is ok, but there is 4m26s difference between my notebook(+) and my desktop. So this time with pinging the router itself, and third interface monitoring, all raw unfiltered (with some garbage too, and still with 4m26s difference): If that time difference is so important then I can sync it and conduct the test yet again, honestly idk if that monitoring is done properly because it was done by internal laptop interface which are not always working with the monitor mode properly, but maybe you can read something from it. |
|
Thanks. This is helpful. There is another MAC d2:32:e5:62:b7:57 related to your AP Is this a guest network? There are 5 DEAUTHENTICATION frames coming from hcxdumptool. Both BSSID are attacked There are 4 DISASSOCIATION frames recorded coming from your AP (cc:32:e5:62:b7:57) There is one REASSOCIATIONREQUEST coming from hcxdumptool This attack was successful: followed by a 4way handshake Depending on your command line options this attack on the AP doesn't look very intrusive. Additional there is a successful attack on the CLIENT to get its M2: Depending on your command line options this attack on the CLIENT doesn't look very intrusive. Please take a look at this dump files: 32 seconds run time and 3401 DEAUTHENTICATON frames injected. Analysis of eth0 will follow.... |
|
BTW: |
|
Over the entire time the CLIENT (1.3.3.243) was connected to the ROUTER (1.3.3.7). packet 9151 CLIENT requested internet address 1.1.1.1 looks like the CLIENT have a problem packet 9203 CLIENT requested internet address 239.255.255.250 Also I double checked the timestamps from the ROUTER: and there is no indication that the ROUTER went down. |
|
I also checked the timestamps of the BEACON field of the ROUTER. This is the up time of the router. ... The timestamps are increasing from 11736985984 to 11828941184 (as expected). No indication that the router went down. Now I'm running out of ideas. All dump files looking fine for me. |
|
The entire analysis took several hours and now I'm really tired. A way too many IP addresses and MAC addresses blinded me and perhaps I have overlooked something. |
|
I believe the commandline for this attack was:
When I look on the desktop_eth.pcap I see that from I still have a lot to learn, but I could bet everything that it is not a client issue at all, I have another router connected to this TP_LINK, and every time when network is down its LED turns orange instead of green, I also lose the network connection on all my phones when this happens, I have encountered this bug for first time over a year ago, but I thought that maybe upgrading router firmware will help and it didn't. I think I have played with aircrack and wifite many times while using that router and only hcxdumptools got this issue, so the old attack mode is not triggering this. Does this even makes a sense that I have Wireshark running on the destination host, and I see in the Wireshark that the destination is not reachable, lol? Like, isn't this thing standing on a wrong side of a gun to claim such things? Good thing is that I've learned a lot already thanks to your analysis, I think I will be back to this issue when I'll get an idea how to get deeper into that router because the frames are kinda lying or not telling the whole story at least, but I feel like maybe you shouldn't waste your valuable time on this because it can be a potentially dead end or an extremely marginal case. PS. Thanks for all the help, you are awesome! |
|
I forgot to attach the analysis of hcxpcapngtool on the monitor dump file: No indication of a DDoS attack. |
"There was a connection issue that lasted almost 2 minutes." Your CLIENT produce heavy internet traffic between to internet addresses. That make the router going BUSY. BTW: |
|
I can't tell if there are more or less disconnections on windows pc, there is nothing like dmesg there, so maybe you should refer to the .pcapng from today with this. |
|
If you still can't believe it, please add the WiFi key of your network to Wireshark settings and it will decrypt and show you the traffic after the REASSOCIATION: |
|
Regarding this: This might be helpful, too (looking similar to your comment): |
|
Conclusion: Everything is pointing to the TP-Link Archer, but you still believe the trouble is caused by hcxdumptool running kind of a DDoS attack on the router. In that case we have to do some more investigations. |
|
Just did the old school attack with aircrack-ng without any issues: Part of it, yes, but remember we have already tested it on my old ralink too! No, no, there is nothing random about these disconnections. I play mutliplayer games with 5-10ms ping on this pc and this router. Yes and no, I use high quality fine and expensive cables, they are all short so all my routers have to stand very close to each other, but I'm sure of these cables. But what bugs me the most, is why it all occurs at once every time I use hcxdumptools with Well, potential DDoS is in the scope, we are talking about a bug, but someone may use it offensively too. If you really don't believe me, and we can't figure out something else to prove that bug is legit here, then I can send you this router for the tests. I think I need a safer and more reliable router anyway. Let me know what do you think, If I can test it in some other ways and prove it to you somehow, or maybe you want your own hands on that router. |
|
I'm interesting to figure out what happened. |
|
hcxdumptool.c.zip This version will print an information that it will perform a REASSOCIATION attack, but it doesn't transmit the packets. |
|
The old school attack (send a DEAUTHENTICATION like aircrack-ng) remains untouched on the modified version, |
|
This are the changes of the modified hcxdumptool.c: On all thre cases, hcxdumptool will enter the function of the attack. Than it print a message and return without executing the rest of the function. |
|
|
|
hcxdumptool.c.zip |
|
hcxdumptool.c.zip |
|
hcxdumptool.c.zip We are now on the same level as an ACCESS POINT. |
|
All good at first shot, no crash. Also no issues with |
|
Ok, thanks. |
|
Ok, inside the phase 1 dumpfile I can't see a REASSOCIATIONRESPONSE coming from your router. That is expected, because we disabled it. Now we enable the REASSOCIATION attack as follows: Do not transmit REASSOCIATIONREQUESTs using a BRADCAST MAC as source address (ffffffffffff) Explanation: BTW: |
|
hcxdumptool.c.zip Now hcxdumptool transmit a REASSOCIATION using the BROADCAST MAC. BTW: |
ZerBea
changed the title
|
I changed the headline again. case2: REASSOCIATION frames coming from MAC CLIENT tested: Perhaps we discovered a bug in the firmware which possible caused this: BTW: |
|
A got two more APs: |
|
I commented this on hashcat forum, too: |
|
I got the first response: |
|
I received some more links facing this problem: Looks like a simple REASSOCIATIONREQUEST is enough to cause a packet drop. |
|
BTW: |
|
I received some more responds reporting ACCESS POINTs that are not affected, e.g. this linksy ACCESS POINT: Before we proceed with the next steps (I'm still interested in what caused that exactly), may I ask a question (because I don't know how to handle your bug report): What do you now expect me to do - shall I unarm hcxdumptool so that it is no longer able to detect such weak points? But anyway, your bug report reminded me to add more information on start of hcxdumptool: |
I thought it has some effect like capturing some additional frames cause I had more crashes with Also, when it downs to your code, just cause of curiosity - why do you prefer I think I've consumed enough of your time already. My goal here was basically just to learn from that and maybe report it to the Tp-Link. I keep learning something new with every your next post so I'm very thankful for all your responses, and at this point you can just recommend me some good books about wireless protocols or and its security or just something to help me troubleshooting that issue further on my own and leave me with it, or you can plan some next tests so we can collect all the results in your way and then inform Tp-Link with a solid case. |
|
No, you neither have waste my time nor you have consumed enough of my time. Problem is that it is hard to detect that the router went down. Some good links are here: You may have noticed that hcxdumptool/hcxtool is a little bit different to other tools. Running default options it tries everything possible to find a vulnerability as quickly as possible. But there is no "AI" inside to analyze it. Coding this is far beyond my scope. |
|
I mentioned above that an impact on the target is not a hcxdumptool bug. Based on you report, hcxdumptool now print a message to inform the user about that, immediately after starting the program. |
I am using ALFA AWUS036AC, router TP-Link Archer C6
Pardon me my lack of required knowledge, I'm just a noob trying to learn some wifi security in my home lab, and doing simply
Is causing my router to crash and reboot 8/10 times, I guess it's somewhere about 1673779734.092722
router_ddos.zip
I've noticed also some segfault in dmesg:
I'm not sure what to think about this, this new mode should be non-intrusive, right? Interface is in monitor mode just listening, so I should be kinda invisible to the router, so how can it derail my router so bad?
The text was updated successfully, but these errors were encountered: