What's new

Asus RT-AC68 firmware 3.0.0.4.385_20630 update

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

joltdude

Regular Contributor
ASUS RT-AC68U Firmware version 3.0.0.4.385.20630
Security update
- Fixed CVE-2020-12695 (CallStranger)
- Fixed Reflected XSS vulnerability.
- Fixed Directory traversal vulnerability.
- Fixed CVE-2017-15653.

The update server transport layer security was upgraded and the old protocol was removed.
If your router firmware version is lower than 3.0.0.4.385.20253, please refer to the "Update Manually" section in https://www.asus.com/support/FAQ/1008000 to update the firmware.

Please unzip the firmware file first then check the MD5 code.
MD5: 011ea1c128d797ec7968f4b3fa94a1df
https://dlcdnets.asus.com/pub/ASUS/...45.431737785.1593618554-1582604579.1593618554
 
Last edited:
ASUS RT-AC68U Firmware version 3.0.0.4.385.20630
Security update
- Fixed CVE-2020-12695 (CallStranger)
- Fixed Reflected XSS vulnerability.
- Fixed Directory traversal vulnerability.
- Fixed CVE-2017-15653.

The update server transport layer security was upgraded and the old protocol was removed.
If your router firmware version is lower than 3.0.0.4.385.20253, please refer to the "Update Manually" section in https://www.asus.com/support/FAQ/1008000 to update the firmware.

Please unzip the firmware file first then check the MD5 code.
MD5: 011ea1c128d797ec7968f4b3fa94a1df
https://dlcdnets.asus.com/pub/ASUS/...45.431737785.1593618554-1582604579.1593618554
Hmmm:
Fixed CVE-2017-15653
Was that file lost under the carpet?
 
Seriously? Wasn't this CVE-2017-15653 fixed in January 2018 with the release 3.0.0.4.382.50010? Did Asus manage to re-insert the vulnerability in the meantime, only to fix it again now?
 
I found a reference that ASUS fixed CVE-2017-15653 in 3.0.0.4.382.18495 version.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15653

My document of history changes for the RT-AC68U router show:
  • 3.0.0.4.380.7743 included the vulnerability released on 6/16/2017.
  • 3.0.0.4.382.18547 was the next release for this router on 11/10/2017 but the release notes did not mention CVE-2017-15653 specifically. However, the release notes had the descriptions from this link. https://seclists.org/fulldisclosure/2018/Jan/63
    • Fixed predictable session tokens, logged user IP validation, Logged-in information disclosure (special thanks for Blazej Adamczyk contribution)
 
I found a reference that ASUS fixed CVE-2017-15653 in 3.0.0.4.382.18495 version.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15653

My document of history changes for the RT-AC68U router show:
  • 3.0.0.4.380.7743 included the vulnerability released on 6/16/2017.
  • 3.0.0.4.382.18547 was the next release for this router on 11/10/2017 but the release notes did not mention CVE-2017-15653 specifically. However, the release notes had the descriptions from this link. https://seclists.org/fulldisclosure/2018/Jan/63
    • Fixed predictable session tokens, logged user IP validation, Logged-in information disclosure (special thanks for Blazej Adamczyk contribution)
I concluded the same.
It seems they forgot to implement the fix for the RT-AC68U.
Usually I would have assumed it was forgotten to show in the remarkable list of security fixes for 3.0.0.4.382.18547.
As they list it now as fix you can only conclude it was somewhere forgotten in the dust.
 
Very odd indeed, as Asus also lists the same "new" fix as included in the equivalent (same number) "new" firmware for the 88U router. Really hard to believe that this fairly publicized security issue wasn't corrected over two years ago. Calling @RMerlin for any insight here.
 
Based on the link below, we should have explicitly seen the following CVEs in the history release notes:

https://seclists.org/fulldisclosure/2018/Jan/63

CVE-2017-15653 - Not sufficient logged user IP validation
CVE-2017-15654 - Highly predictable session tokens
CVE-2017-15656 - Password stored in plain text

The only CVE explicitly listed is CVE-2017-15653 in the current firmware release.

However, in the 3.0.0.4.382.18547 version, ASUS did list the above CVEs descriptions but not the CVE numbers.
  • Fixed predictable session tokens, logged user IP validation, Logged-in information disclosure (special thanks for Blazej Adamczyk contribution)
Strange ASUS did not explicitly list the three CVEs in the 3.0.0.4.382.18547 version release notes and now they release CVE-2017-15653 possibly for the second time.
 
Any feedback on the performance & stability of this firmware?
I'm still on 20490, which has been pretty solid.
 
Any feedback on the performance & stability of this firmware?
I'm still on 20490, which has been pretty solid.
Uptime 2 days 1 hour(s) 11 minute(s) 50 seconds and rock solid, did the upgrade manually, without (hard-)reset.
My usage is pretty straight forward, the most fancy part is the USB stick in the USB 2.0 port as intermediate network storage, all additional features are disabled.
 
Password encryption is something that is already part of their AX models. They added it to the SDK 7.14 devices (RT-AC88U/AC3100/AC5300) a few months ago, and are going to add it to the RT-AC86U next (I have a beta with it enabled).
 
Looking for help. I updated to this firmware a week ago. Did the factory reset after the firmware upgrade, and put back all my settings. Things initially worked well, but for computers after being up for a few days, would randomly not be able to access some websites. Router has also been up the whole time. Then after a while it all starts working again.

In the router, I specify 1.1.1.1 and 8.8.8.8 as my WAN DNS servers. Other than that, all other settings are default other than basic things like SSID, passwords, admin account/password, etc..

The following is a progression as I was trying to investigate/fix the problem.

I am in a state where computers can access some sites (Google, Bing, Netflix), but cannot access others like snbforums.com, downdetector.com, nordvpn.com, and others that I had a tab open to and had been using. Rebooting the computer didn't help. Ping from the computer says it cannot resolve the site names. Ping from the router's network tools, for sites that work get the normal ping responses. But the sites that aren't working, I get:

www.downdetector.com:
ping: bad address 'www.downdetector.com'

downdetector.com:
ping: bad address 'downdetector.com'

snbforums.com:
(blank - nothing)

I was able to connect to a VPN (Nord VPN) and validate the target sites are up and running.

Back in the router network tools page, after having hit the ping diagnose button a few times, snbforums.com somehow starts working. Doing the test with downdetector.com now also works, from both the router network tools page, and from computers, although the computer could maybe have that DNS cached after being connected to the VPN.

What would cause the router to have DNS resolution issues? It was working fine before updating the firmware. The old firmware was possible the original firmware it shipped with: 3.0.0.4.380_7378-g7a25649

Looking for any advice. Anything I should look at in the router logs? Thank you for sharing your knowledge.
 
Looking for help. I updated to this firmware a week ago. Did the factory reset after the firmware upgrade, and put back all my settings. Things initially worked well, but for computers after being up for a few days, would randomly not be able to access some websites. Router has also been up the whole time. Then after a while it all starts working again.

In the router, I specify 1.1.1.1 and 8.8.8.8 as my WAN DNS servers. Other than that, all other settings are default other than basic things like SSID, passwords, admin account/password, etc..

The following is a progression as I was trying to investigate/fix the problem.

I am in a state where computers can access some sites (Google, Bing, Netflix), but cannot access others like snbforums.com, downdetector.com, nordvpn.com, and others that I had a tab open to and had been using. Rebooting the computer didn't help. Ping from the computer says it cannot resolve the site names. Ping from the router's network tools, for sites that work get the normal ping responses. But the sites that aren't working, I get:

www.downdetector.com:
ping: bad address 'www.downdetector.com'

downdetector.com:
ping: bad address 'downdetector.com'

snbforums.com:
(blank - nothing)

I was able to connect to a VPN (Nord VPN) and validate the target sites are up and running.

Back in the router network tools page, after having hit the ping diagnose button a few times, snbforums.com somehow starts working. Doing the test with downdetector.com now also works, from both the router network tools page, and from computers, although the computer could maybe have that DNS cached after being connected to the VPN.

What would cause the router to have DNS resolution issues? It was working fine before updating the firmware. The old firmware was possible the original firmware it shipped with: 3.0.0.4.380_7378-g7a25649

Looking for any advice. Anything I should look at in the router logs? Thank you for sharing your knowledge.
I had weird issues this afternoon accessing a variety of sites and I think it was due to an outage at Cloudflare. How long has this been going on for you?
 
Only had 68U for 4 days and it updated to current firmware on initial config. So far seems pretty stable despite me re-config'ing wireless a few times. I had other cheaper models and they kept losing PPP session and reconnecting. This one seems rock solid for nearly 5 days.
 
I had weird issues this afternoon accessing a variety of sites and I think it was due to an outage at Cloudflare. How long has this been going on for you?

It happened Thursday night, for my phone and another computer. And again today, Friday, around 5:30pm Eastern Time for another computer.

I've gone to the admin > system tab > set the ping target to be downdetector.com at a 10 minute interval. I would have thought something like that would register in the system log, but not seeing anything there for it.
 
Looking for help. I updated to this firmware a week ago. Did the factory reset after the firmware upgrade, and put back all my settings. Things initially worked well, but for computers after being up for a few days, would randomly not be able to access some websites. Router has also been up the whole time. Then after a while it all starts working again.

In the router, I specify 1.1.1.1 and 8.8.8.8 as my WAN DNS servers. Other than that, all other settings are default other than basic things like SSID, passwords, admin account/password, etc..

The following is a progression as I was trying to investigate/fix the problem.

I am in a state where computers can access some sites (Google, Bing, Netflix), but cannot access others like snbforums.com, downdetector.com, nordvpn.com, and others that I had a tab open to and had been using. Rebooting the computer didn't help. Ping from the computer says it cannot resolve the site names. Ping from the router's network tools, for sites that work get the normal ping responses. But the sites that aren't working, I get:

www.downdetector.com:
ping: bad address 'www.downdetector.com'

downdetector.com:
ping: bad address 'downdetector.com'

snbforums.com:
(blank - nothing)

I was able to connect to a VPN (Nord VPN) and validate the target sites are up and running.

Back in the router network tools page, after having hit the ping diagnose button a few times, snbforums.com somehow starts working. Doing the test with downdetector.com now also works, from both the router network tools page, and from computers, although the computer could maybe have that DNS cached after being connected to the VPN.

What would cause the router to have DNS resolution issues? It was working fine before updating the firmware. The old firmware was possible the original firmware it shipped with: 3.0.0.4.380_7378-g7a25649

Looking for any advice. Anything I should look at in the router logs? Thank you for sharing your knowledge.

Seems Cloudflare has been having a bad week with the sites you mention going down tonight. Currently Cloudflare is trending on Twitter. According to the Cloudflare status Friday's outage was because a router was handing out incorrect routes which is now fixed.
 
It happened Thursday night, for my phone and another computer. And again today, Friday, around 5:30pm Eastern Time for another computer.
I think today's outage is the same, because that's when things got weird here. I couldn't access this site, but I could access other sites. I don't use cloudflare for DNS, so I may have had less impact than you. Can't say Thursday's problems were related though.

https://www.bleepingcomputer.com/ne...own-discord-bleepingcomputer-and-other-sites/
 
Thanks everyone for the input. Feeling like maybe I should remove cloudflare from my DNS and just use googles. Will give that a shot and see how the next week goes.
 
Last edited:
Thanks everyone for the input. Feeling like maybe I should remove cloudflare from my DNS and just use googles. Will give that a shot and see how the next week ago.

Also consider Quad9:
https://www.quad9.net/

9.9.9.9 and 149.112.112.112

OE
 
I adopted quad9 and prior to this I had the Trend Micro catching malicious attacks. Now since quad9 I don't have any. Which either means it's not detecting any attacks or quad9 catches them before it gets any further down the line. Seems ok so far
 
I have noticed something with this version.

Jul 21 19:35:59 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind B0:FC:0D:89:09:87, status: 0, reason: Disassociated due to inactivity (4)
Jul 21 19:37:53 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth B0:FC:0D:89:09:87, status: Successful (0)
Jul 21 19:37:53 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc B0:FC:0D:89:09:87, status: Successful (0)

The device disconnected due to inactivity was an Amazon speaker and was in use at the the time playing an audio stream which just cut out. Anyone else seeing this disconnect error in their logs? I see from the beta thread that it is a feature of the 386 firmware too.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top