SECURITY: LAN-side security hole - mitigation

[RMerlin]

Thanks for fixing this!

Is there an easy way to verify that it's not vulnerable? or do you have to test with the exploit for this CVE?

I just updated to the 376.49_5 but noticed that the ports are still open

$ netstat -ln | grep 999
tcp        0      0 0.0.0.0:9998            0.0.0.0:*               LISTEN      
udp        0      0 0.0.0.0:9999            0.0.0.0:*  

$ netcat -z -v -u 192.168.1.1  9999
Connection to 192.168.1.1 9999 port [udp/*] succeeded!

//Michael

You have to specifically test the exploit (that's how I tested with the Python proof-of-concept). The service still listens to 9999/udp, however the specific packet command that allowed to run a program has been disabled. The rest of the device discovery capabilities are untouched.

 

[paleolithic]

Merlin mailing list?

Kudos to the developer for providing a patch so quickly! I already liked this firmware a lot but seeing that kind of on the ball response to a security issue makes me even more of a fan

I was wondering what the best way is to stay informed about future vulnerability and patch announcements for the Merlin firmware. Is there a mailing list for that?

 

[dnlongen]

Automatable fix for stock firmware

See http://dnlongen.blogspot.com/asuswrt-samba for an example of this in action. It would be easy to add Merlin's iptables and firewall commands to a script called in this manner.

Here's specific instructions for killing the vulnerable service automatically at boot time using a script_usbmount script on stock firmware: http://dnlongen.blogspot.com/CVE-2014-9583

 

[john9527]

I uploaded 376.49_5, which has the vulnerable section of infosvr disabled, as well as an additional security fix applied.

Just an FYI... I have also posted an update to the stable release of my 'Merlin Fork 374.43' (Update-06E) that contains a backport of Merlin's infosvr fixes.

Thanks Merlin!

 

[bluepoint]

The Famous Merlin

http://www.pcworld.com/article/2867...-routers-to-be-hacked-from-local-network.html

 

[sinshiva]

http://www.pcworld.com/article/2867...-routers-to-be-hacked-from-local-network.html

that article indicates that installing third party firmware on Asus routers voids warranties; not true.

 

[RMerlin]

that article indicates that installing third party firmware on Asus routers voids warranties; not true.

The problem is, nobody knows for sure. Even manufacturers themselves seem to give contradictory information, as their frontline tech support usually doesn't know the answer, so he considers it as a "device modifications will void your warranty" type of situation.

 

[bluepoint]

that article indicates that installing third party firmware on Asus routers voids warranties; not true.

His statement is more on the cautious side just in case.

 

[DaveMishSr]

Meh. Many props to Eric though!

I thought it was a pretty tame article. It was kind of difficult to keep from yawning as I read it. However, once I got to the section about our very own Merlin I was enraptured and on the edge of my seat!

 

[Stefan1200]

@ RMerlin: In case you don't know this page: https://github.com/jduck/asus-cmd

 

[kvic]

I've reported already that to ASUS networking support, lets wait for a fix, my fix by now is this:

killall -9 infosrv

This rings a bell. 'cos I did something similar in one startup script.
I believe it's one of the elegant workarounds

I could actually leave the hole not patched as "infosvr" only listen on "br0" which is LAN & WLAN. Most home users should not be terribly worried about the issue.

Given that said, I patched the hole anyway on my AC56. My justification is that there might be other unknown holes. Together could possibly be exploited by people from Internet and get root access to my router. Though no such evidence in public domain at the moment.

 

[hggomes]

infosrv should be running only on the LAN interface, even its closed to the outside (WAN) when running on the br0 interface.

 

[RMerlin]

@ RMerlin: In case you don't know this page: https://github.com/jduck/asus-cmd

I know, and I've also been in touch with him.

 

[RMerlin]

This rings a bell. 'cos I did something similar in one startup script.
I believe it's one of the elegant workarounds

I could actually leave the hole not patched as "infosvr" only listen on "br0" which is LAN & WLAN. Most home users should not be terribly worried about the issue.

Given that said, I patched the hole anyway on my AC56. My justification is that there might be other unknown holes. Together could possibly be exploited by people from Internet and get root access to my router. Though no such evidence in public domain at the moment.

A malicious website that you visit could, in theory, use Javascript to access your router, do any kind of nefarious activity, and report it back to the website.

So while the issue isn't as serious as if it was exposed on the WAN (since human intervention is needed), it's still a very serious hole which MUST be plugged.

 

[noric]

As a temporary workaround, should we prefer

iptables -I INPUT  -p udp --dport 9999 -j DROP

or

 killall -9 infosrv

?
Thanks.

 

[hytekj]

As a temporary workaround, should we prefer

iptables -I INPUT  -p udp --dport 9999 -j DROP

or

 killall -9 infosrv

?
Thanks.

I'm no expert but with killall -9 something could simply restart the service.

 

[hggomes]

The service can only be restarted after a reboot, so if you add that line to your boot script it will kill it always when restart happens.

 

[gregwee]

Blocking port 9999 causes an issue with Macbook Air's and Pro's to be unable to get the correct IP addresses from my AC66U while connecting through Wifi. The DHCP on my AC66U is set to give out 192.168.9.*, but with port 9999 blocked, it seemed that the Macbooks get the IPs in the 192.168.1.*, resulting in no connections.. Restarting and turning Wifi off/on the Macs don't seem to resolve this issue. The only way is to go to the "Network" settings and click on the "Renew DHCP Lease" button to get the correct IP. Removing port 9999 blocking resolves this issue.

I'm using "killall -9 infosrv" instead.

 

[RMerlin]

Blocking port 9999 causes an issue with Macbook Air's and Pro's to be unable to get the correct IP addresses from my AC66U while connecting through Wifi. The DHCP on my AC66U is set to give out 192.168.9.*, but with port 9999 blocked, it seemed that the Macbooks get the IPs in the 192.168.1.*, resulting in no connections.. Restarting and turning Wifi off/on the Macs don't seem to resolve this issue. The only way is to go to the "Network" settings and click on the "Renew DHCP Lease" button to get the correct IP. Removing port 9999 blocking resolves this issue.

Technically, that doesn't make any sense. Blocking port 9999 has absolutely nothing to do with DHCP, which is on ports 67 and 68. If your clients are getting a lease in the wrong subnet then it means something else is running on your network that allocates IPs in that subnet.

What might be happening is you had a typo in your block rule, which prevented the firewall from properly be configured, and you might be having your modem running a DHCP server suddenly being exposed to your LAN.

 

[octopus]

I have updated to latest 49_5 and I can se traffic on port 9999, my INPUT drop rule take care of it.

knhaddock@KNHADDOCK:/tmp/home/root# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 match-set Hammer_ips src,dst
9 492 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpts:11000:11030
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9998
24 12960 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9999
211K 28M ACCEPT all -- tun21 * 0.0.0.0/0 0.0.0.0/0
216K 45M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
85 4692 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
4503 592K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
474 51534 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
4557 683K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
8 400 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1212
0 0 SSHBFP tcp -- vlan10 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3232 state NEW
40429 5105K DROP all -- * * 0.0.0.0/0 0.0.0.0/0