Release ASUS RT-AC66U B1 Firmware version 3.0.0.4.386.45987

[gdp416]

Version 3.0.0.4.386.45987

2021/12/16 92.52 MBytes

ASUS RT_AC66U_B1 Firmware version 3.0.0.4.386.45987

Fixed XSS vulnerability
Fixed SQL injection vulnerability
Fixed PLC path traversal vulnerability
Fixed Stack overflow vulnerability
Thanks to HP of Cyber Kunlun Lab

 

[gdp416]

The size of the firmware image is back down to 92 MB, down from the 144 MB of the previous release.

 

[jplw]

Firmware 3.0.0.4.386.45956, which was released in November for the 86U, fixes over 30 vulnerabilities.
Firmware 3.0.0.4.386_45898, which was released in October for the 88U, fixes those same vulnerabilities.

This version just released for the 68U/66 B1 (Version 3.0.0.4.386.45987), has a higher release number than both of the above, but does not fix all those vulnerabilities (nor did a previous version for the 68U/66U B1). Does this mean that:

1. those vulnerabilities do not exist in the 68U/66U B1, or
2. ASUS does not plan to fix them, or
3. ASUS already fixed them without saying so, or
4. ASUS will fix them in the future?

 

[RMerlin]

Firmware 3.0.0.4.386.45956, which was released in November for the 86U, fixes over 30 vulnerabilities.
Firmware 3.0.0.4.386_45898, which was released in October for the 88U, fixes those same vulnerabilities.

This version just released for the 68U/66 B1 (Version 3.0.0.4.386.45987), has a higher release number than both of the above, but does not fix all those vulnerabilities (nor did a previous version for the 68U/66U B1). Does this mean that:

1. those vulnerabilities do not exist in the 68U/66U B1, or
2. ASUS does not plan to fix them, or
3. ASUS already fixed them without saying so, or
4. ASUS will fix them in the future?

Any fix in 45898 or 45956 are already present in 45987.

 

[jplw]

.I upgraded to this version from 43129. On 43129,I could access the rtsp stream from my doorbell camera on Guest Network 1 from the main network. After the upgrade, I cannot. Is this a bug in this version, or was it sabug in 43129?

If it was a bug in 43129, is there anything I can do in this version to restore access? Guest Network 1 does not have LAN access. I do not want it's devices to be able to initiate connections to the main lan, but I do want to be able to connect to them from the main lan.

 

[RMerlin]

Try using GN2 instead, as GN1 has a different architecture meant for AiMesh node synchronisations.

 

[jplw]

Great thought, but the camera is still not accessible from the intranet when conected to GN2.

 

[PlayaSucia]

Does this address the Log4Shell vulnerability that everyone is talking about?

 

[RMerlin]

Does this address the Log4Shell vulnerability that everyone is talking about?

Asuswrt does not use any Java code.

 

[RMerlin]

Great thought, but the camera is still not accessible from the intranet when conected to GN2.

Did you set the "Access Intranet" to "enable"?

 

[jplw]

Did you set the "Access Intranet" to "enable"?

No, I do not want the camera to be able initiate access to the intranet, but I do want the intranet to be able initiate access to it. This worked in the older firmware on GN1, and I know that a firewall can allow this. i just do not know how to cause the Asus firmware to configure it.

 

[RMerlin]

No, I do not want the camera to be able initiate access to the intranet, but I do want the intranet to be able initiate access to it.

It's either within the same network, or it's not. You can't have it both ways...

 

[jplw]

It's either within the same network, or it's not. You can't have it both ways...

That does appear to be true in the current firmware, but for 3.0.0.4_386_43129 this is not true. With that firmware, I had a cloud-connected doorbell camera on GN1 with GN1 intranet access disabled. I tested with my Mac connected to GN1, and could not access the intranet, as desired. However, when I initiated an rtsp connection from the intranet to the camera, using its 192.168.101.xx ip address, the stream worked.

It does not work in the current firmware.

In my opinion, the way 3.0.0.4_386_43129 worked was better from a security perspective, because a hacked IOT device on GN1 cannot connect into the intranet, but an intranet device can make a connection to, and receive data from, the IOT device. With the current firmware, I have to put the camera on the intranet, so if it is hacked it has access to everything. As with many IOT devices, it must be cloud-connected to keep working, so I cnnot block its internet access.

For another project, I configured a Ubiquity EdgeRouter and the command-line level, and it has a standard feature to allow cross-vlan connectons only if initiated from the vlan you specify, so I know that routers can do this! I believe that Asus uses a different vlan fo GN1 (to spread it to nodes), so what 3.0.0.4_386_43129 should be possible and would be a nice option.

 

[s0x]

That does appear to be true in the current firmware, but for 3.0.0.4_386_43129 this is not true. With that firmware, I had a cloud-connected doorbell camera on GN1 with GN1 intranet access disabled. I tested with my Mac connected to GN1, and could not access the intranet, as desired. However, when I initiated an rtsp connection from the intranet to the camera, using its 192.168.101.xx ip address, the stream worked.

It does not work in the current firmware.

In my opinion, the way 3.0.0.4_386_43129 worked was better from a security perspective, because a hacked IOT device on GN1 cannot connect into the intranet, but an intranet device can make a connection to, and receive data from, the IOT device. With the current firmware, I have to put the camera on the intranet, so if it is hacked it has access to everything. As with many IOT devices, it must be cloud-connected to keep working, so I cnnot block its internet access.

For another project, I configured a Ubiquity EdgeRouter and the command-line level, and it has a standard feature to allow cross-vlan connectons only if initiated from the vlan you specify, so I know that routers can do this! I believe that Asus uses a different vlan fo GN1 (to spread it to nodes), so what 3.0.0.4_386_43129 should be possible and would be a nice option.

Not on RT-AC66U, but on a XT8, I've resorted to removing the 5th rule on the ebtables, broute table, BROUTING chain, making the connection from the Intranet to the guest network possible again.

Show rules:

ebtables -t broute -L BROUTING

The 5th rule should be the one to remove.

This change won't survive a reboot, so I have this running every 5 min using crontab on a Linux server.

IMO, ASUS should allow more flexibility regarding these configurations.

#!/usr/bin/env bash

if ssh <router> "ebtables -t broute -L BROUTING" | grep -q "\-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP"; then
    ssh <router> "ebtables -t broute -D BROUTING 5";
fi

exit $?

 

[jplw]

Not on RT-AC66U, but on a XT8, I've resorted to removing the 5th rule on the ebtables, broute table, BROUTING chain, making the connection from the Intranet to the guest network possible again.

Show rules:

ebtables -t broute -L BROUTING

The 5th rule should be the one to remove.

This change won't survive a reboot, so I have this running every 5 min using crontab on a Linux server.

IMO, ASUS should allow more flexibility regarding these configurations.

#!/usr/bin/env bash

if ssh <router> "ebtables -t broute -L BROUTING" | grep -q "\-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP"; then
    ssh <router> "ebtables -t broute -D BROUTING 5";
fi

exit $?

Very, very clever! Thanks!! I am guessing that 192.168.50.0/24 is your intranet? I changed mine to 192.168.1.0/24. My 5th entry is:

-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

my 8th entry is:

-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP

So..I would delete the 8th? Is wl0.2 vs wl0.1 documented somewhere?

 

[jplw]

Not on RT-AC66U, but on a XT8, I've resorted to removing the 5th rule on the ebtables, broute table, BROUTING chain, making the connection from the Intranet to the guest network possible again.

Show rules:

ebtables -t broute -L BROUTING

The 5th rule should be the one to remove.

This change won't survive a reboot, so I have this running every 5 min using crontab on a Linux server.

IMO, ASUS should allow more flexibility regarding these configurations.

#!/usr/bin/env bash

if ssh <router> "ebtables -t broute -L BROUTING" | grep -q "\-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP"; then
    ssh <router> "ebtables -t broute -D BROUTING 5";
fi

exit $?

I found the ebtables documentation.. Doesn't deleting rule 5 allow unfettered access from the GN1 to the intranet?

 

[jplw]

Not on RT-AC66U, but on a XT8, I've resorted to removing the 5th rule on the ebtables, broute table, BROUTING chain, making the connection from the Intranet to the guest network possible again.

Show rules:

ebtables -t broute -L BROUTING

The 5th rule should be the one to remove.

This change won't survive a reboot, so I have this running every 5 min using crontab on a Linux server.

IMO, ASUS should allow more flexibility regarding these configurations.

#!/usr/bin/env bash

if ssh <router> "ebtables -t broute -L BROUTING" | grep -q "\-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP"; then
    ssh <router> "ebtables -t broute -D BROUTING 5";
fi

exit $?

OK...I figured it out. I had GN2 defined. I deleted that, now it is my 5th entry,. Thanks for the tip!

 

[s0x]

Very, very clever! Thanks!! I am guessing that 192.168.50.0/24 is your intranet? I changed mine to 192.168.1.0/24. My 5th entry is:

-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

my 8th entry is:

-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP

So..I would delete the 8th? Is wl0.2 vs wl0.1 documented somewhere?

Yes, I kept the default Asus subnets when configuring, so intranet is .50.0/24, GN 1 is 101.0/24, GN2 is 102.0/24.

Without the rule removed looks like this:

# ebtables -t broute -L BROUTING
Bridge table: broute

Bridge chain: BROUTING, entries: 10, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP

Deleting, in my case, the 5th rule will cause the packets to be bridged instead of routed (due to the BROUTING policy of Accept), on that interface. br0 is the default bridge, where .50.0/24 exists, and 101.0/24 is br1. If the packets weren't bridged it would not reach the other network on the br0 intf.

I found the ebtables documentation.. Doesn't deleting rule 5 allow unfettered access from the GN1 to the intranet?

It shouldn't :crossfingers:

OK...I figured it out. I had GN2 defined. I deleted that, now it is my 5th entry,. Thanks for the tip!

No problem. Just adapt the instructions to your specific situation.

 

[jplw]

Yes, I kept the default Asus subnets when configuring, so intranet is .50.0/24, GN 1 is 101.0/24, GN2 is 102.0/24.

Without the rule removed looks like this:

# ebtables -t broute -L BROUTING
Bridge table: broute

Bridge chain: BROUTING, entries: 10, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP

Deleting, in my case, the 5th rule will cause the packets to be bridged instead of routed (due to the BROUTING policy of Accept), on that interface. br0 is the default bridge, where .50.0/24 exists, and 101.0/24 is br1. If the packets weren't bridged it would not reach the other network on the br0 intf.


It shouldn't :crossfingers:


No problem. Just adapt the instructions to your specific situation.

Brilliant. I tried it. Camera is now accesible, but intranet is not otherwise accesible from the guest network! Thanks again.