386.14_2 Hacked? 'Unrecoverable' Guest network issue

[ColinTaylor]

Is GT-AX6000 equally susceptible to 0.0.0.0 Day as RT-AC66U-B1?

Neither router is susceptible as this is a (non-Windows) client browser issue.

Side note: It's interesting to see 0.0.0.0 now being classed as an "issue" when for many years it's been a common practice for host-based adblockers to use that address as a black hole. Example: https://docs.raspap.com/adblock/#custom-blocklist

 

[ColinTaylor]

I've been away for a few days leaving freshly restored RT-AC66U-B1 to get griefed again. 5GHz GN1 stopped working. LG WebOS TV could connect to the AP, but no DNS, so no digital networks.
View attachment 64784

I turned on DNS director and set DNS to Quad9. This fixed the smart TV apps.
View attachment 64785
Turning OFF DNS director resulted in broken smart TV apps again. Turning it back ON fixed the TV again.

This is consistent with the idea that something is messing up the router DNS configuration for guest networks. I do not know what might be causing that, but I would like to be confident that I'm not spending £200 on a new GT-AX6000 only to find it has the same issue. The 3006 codebase is improved from 3004 in respect of guest networks, right?

Who is your ISP?

 

[Natty]

Who is your ISP?

Virginmedia.

Since the last restore, there were no 'possible DNS rebind attack' events reported in the event log, though the malfunction had returned. Maybe the malfunction has nothing to do with that, but it does seem to relate to DNS, and to corruption of configuration settings.

Before I turned on DNS Director (set to Quad9) today, LAN DHCP server DNS was already set to 9.9.9.9 & 149.112.112.112, and WAN -> Internet Connection -> DNS Server is set to Service Name: Quad9-1. Guest networks were working reliably until around 2 weeks ago.

The bad GN issue persists through nightly scheduled restarts and through manual power cycling. Time will tell if turning on DNS director keeps the issue at bay. Before retiring the router, I would like to understand what is causing the issue, to avoid repeating any mistakes on the new router.

 

[ColinTaylor]

Go to System Log - General Log and set Log only messages more urgent than = all. Next time the problem occurs post the complete System Log here (or send it to me by direct message) so we can review it and look for anything unusual.

 

[Natty]

Thanks @ColinTaylor. That is now set. The default log level is currently set to notice. Is that ok or do we need more detail such as info or debug?

 

[ColinTaylor]

Thanks @ColinTaylor. That is now set. The default log level is currently set to notice. Is that ok or do we need more detail such as info or debug?

The default log level is fine as it is. It's the setting you changed which defines what information is shown.

 

[st3v3n]

So I think @st3v3n you are saying the EULA popup that started in 386.14 is due to the router being hacked? In which case mine has been compromised since that started popping up multiple times last summer. I used @Yota's u-block origin rule to ignore it. My Guest Networks continued to work just fine for many months, until now.

Release - Asuswrt-Merlin 386.14 is now available for AC models

Asuswrt-Merlin 386.14 is now available for all supported AC models. The focus of this release is the merge of an updated GPL, possibly the last GPL merge for the 386 series before support is dropped at the end of 2024. 17-Nov-2024: 386.14_2 is now available. 386.14_2 (17-Nov-2024) -...

www.snbforums.com

I'd still like to understand the GN DNS question of post #32 to be sure my GN issue is not simply bad DNS configuration, if someone could please educate me on that?

In our case, the continuously, repeating Asus 'privacy' is not a one-time problem, where you can simply click OK after reading and then have it 'be gone' as one might expect. This particular issue isn't the same as you've been used to over the years, by reading and agree to accept the agreement/policy, and never see it again. No, this time (for us) was an altered noice/bug/malware, part of what took down our ISP. With every change within a tab or to the next tab/area while logged in, this was as if the devil of malware was poking at us. In the entire time we ran version V386.14 to 386.14.2 on two identical routers, this bug/hack never appeared prior to that time, nor since. Only with more testing of the Merlin builds up to 386.14.2 and the newer Asus stock FW released in March, will the truth of what occured here will be known, or not. It's been made very clear in the past that niether Asus nor Merlin will extend any assistance past January 1, 2025, so, it'e going to be a case of many folks having either retire their older Asus routers or try to protect them in use as wireless APs behind a different setup. Many owners find themselves unable to justify/afford the high cost of a new, generation of Asus units with quad-core CPUs and more RAM, so they must decide if they can tolerate the exposure in this situation. If you can use one of these older models behind an IPS, Pi-hole or older PC/Lunux/Mac computer perhaps running OPNSense, you don't have to learn everything at once to to get decent protection but there's a learning curve with every new platform. There are plenty of quality videos to help you. Good luck and hang tough, St3v3.

 

[Natty]

Apr  6 04:12:59 wan_up: Restart DDNS
Apr  6 04:12:59 dhcp_client: bound XX.YY.34.AAA/255.255.240.0 via XX.YY.32.1 for 453510 seconds.
Apr  6 04:12:59 disk_monitor: Finish
Apr  6 04:13:02 disk_monitor: be idle
Apr  6 04:13:02 dnsmasq-script[775]: json_object_from_file: error opening file /jffs/nmp_vc_json.js: No such file or directory

Is the dhcp_client message normal and expected? (XX.YY appears to be part of the WAN address, hopefully anonymised here)
is the dnsmasq-script[775] message indicative of something that needs fixing?

 

[ColinTaylor]

Apr  6 04:12:59 wan_up: Restart DDNS
Apr  6 04:12:59 dhcp_client: bound XX.YY.34.AAA/255.255.240.0 via XX.YY.32.1 for 453510 seconds.
Apr  6 04:12:59 disk_monitor: Finish
Apr  6 04:13:02 disk_monitor: be idle
Apr  6 04:13:02 dnsmasq-script[775]: json_object_from_file: error opening file /jffs/nmp_vc_json.js: No such file or directory

Is the dhcp_client message normal and expected? (XX.YY appears to be part of the WAN address, hopefully anonymised here)
is the dnsmasq-script[775] message indicative of something that needs fixing?

Those are normal messages you would see if the connection between the router and the ISP modem was restarted or certain changes are made in the router's webUI. Without seeing the complete log and knowing the circumstances it's impossible to say whether this indicates a problem or not.

 

[Natty]

Since enabling DNS Director and changing GN passwords there has been no repeat of bad guest network Wi-Fi, and nothing untoward in the syslog. The guest clients that may have been involved in things going bad have had ample opportunity to repeat the trick.

This suggests to me that if DNS Director is OFF, the (now unsupported) 386 firmware is vulnerable to the guest network being griefed by unknown cause, and when such griefing happens, the guest network DNS is irreversibly compromised until a known good config backup is restored. Others may conclude that nothing an be concluded. Was the 'bad GN' caused by an 'attack' directly from the WAN or indirectly from the LAN via a client? I have no way of knowing. I am reporting this observation to the forum because *if* it is due to a vulnerability in guest network DNS handling, then this may also be relevant to other related firmware that is still supported.

A new GT-AX6000 is waiting to replace the RT-AC66U-B1, though not until early May due to time constraints. Immediately before making the upgrade I'll switch off DNS director to try to provoke recurrence and see if anthing interesting is logged.