SECURITY: LAN-side security hole - mitigation

[RMerlin]

There's currently a security hole in all known versions of Asuswrt and Asuswrt-Merlin that can allow a LAN user to execute a command on the router without requiring authentication.

LATEST UPDATE:
Asus resolved the issue with firmware updates released on January 12th for all models. If using the stock firmware then make sure you update to the latest version released on or around January 12th.

Also, the "brute force" fix I applied in 376.49_5 will most likely be the fix I will stick with (unless Asus's fix involves additional fixes, of course). The code that I disabled is only used at manufacturing time, so there is no point in leaving any of this section of code enabled for production use.

UPDATE:
If you are running my firmware, please installe 376.49_5, which has the vulnerable feature of infosvr disabled. Note that this is just a brute force solution where I completely disabled the code responsible for allowing remote code execution. It could have unforeseen consequences, possibly with Asus's Device Discovery tool, or their printer sharing option. It's impossible to say, as I have no real idea what infosvr does exactly.

This is just a temporary fix, as once Asus comes up with a more appropriate fix, it will most likely replace the current one.

If you are using the stock firmware, or for some reason cannot update your router, then you can still use the mentioned mitigation tricks posted below.

Original mitigation trick:
Unfortunately, someone already publicly disclosed the details on how to exploit this security hole before Asus even had a chance to fix it, so I've decided to post a mitigation method here to allow people to secure their network. I won't post the details of the security hole in public until Asus has had a chance to fix it, and I will moderate any post here that provide any additional detail that could help people to actively exploit the security issue.

Use one of the two following methods:

1) If you have JFFS enabled, simply create a firewall-start script with the following:

#!/bin/sh
iptables -I INPUT  -p udp --dport 9999 -j DROP

Then, restart your firewall:

service restart_firewall

2) If you don't (or won't) enable the JFFS partition, then you will have to telnet/SSH into your router, and manually run that command:

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

Note that this rule will disappear anytime you reboot your router, or do any configuration change that leads to the router re-configuring its firewall.


The security hole is *ONLY* exploitable from the LAN, so if you trust everyone on your LAN, then it isn't too serious.

Again, until Asus publishes an official fix, please don't post any additional detail if you happen to find any. I will actively edit any post that contains any additional information as to how this security hole can be exploited.

 

[Nullity]

Does disabling access to this port cause any side-effects?

 

[RMerlin]

Does disabling access to this port cause any side-effects?

It might potentially affect some particular features unrelated to its core routing functionality (so anything related to Internet or LAN traffic should be totally unaffected). I'm not really familiar with that particular service so I can't say for sure as to what can be affected by this change, sorry. Otherwise I would have actually patched the issue rather than issuing this temporary workaround.

 

[SO333]

The security hole is *ONLY* exploitable from the LAN, so if you trust everyone on your LAN, then it isn't too serious.

I don't agree. Although the exploit data packet must be send from the LAN, this could also be triggered externally!
Think of an evil Java Applet, Chrome Extension, ActiveX Control (do they still exist?) or whatever can send UDP.

So even if you can trust your LAN users ("they don't even know what a router is") you are susceptible to external attacks ("unfortunately, they click on every link they see" ;-)

 

[sinshiva]

I don't agree. Although the exploit data packet must be send from the LAN, this could also be triggered externally!
Think of an evil Java Applet, Chrome Extension, ActiveX Control (do they still exist?) or whatever can send UDP.

So even if you can trust your LAN users ("they don't even know what a router is") you are susceptible to external attacks ("unfortunately, they click on every link they see" ;-)

that's still triggered internally and in cases like you've mentioned, you'd likely NOT be trusting the users on your lan implicitly. regardless; yes, this vuln sucks. The real tragedy here though, imo, is like RMerlin states;

Unfortunately, someone already publicly disclosed the details on how to exploit this security hole before Asus even had a chance to fix it

I guess that 5 minutes of fame is hard to resist

 

[BWR]

I'm not really familiar with that particular service so I can't say for sure as to what can be affected by this change, sorry.

Which service uses that UDP port?

 

[john9527]

Which service uses that UDP port?

http://www.speedguide.net/port.php?port=9999

 

[sinshiva]

Which service uses that UDP port?

it appears to be some kind of device discovery service, perhaps specifically for finding other asus products. I've actually had this port blocked for a few months and not noticed it impact anything in the router or the web interface.

[edit/]
RMerlin took a look at the affected code and mentioned it being some ancient cruft. It has never been exposed WAN side and was meant to serve some basic purpose, so I doubt it's there for any malicious reasons like the database john9527 linked suggests, nor is it named like anything in there. Just some garbage that either needs to be dropped or patched.

 

[Nullity]

http://www.speedguide.net/port.php?port=9999

Does that information apply to this situation?

I was assuming that the service that is listening on the router would be some proprietary Asus or Broadcom thing.

 

[jamestx10]

This is my first firewall-start script so I am wanting to verify that it is working. Should I see something in the logs?

 

[john9527]

Does that information apply to this situation?

I was assuming that the service that is listening on the router would be some proprietary Asus or Broadcom thing.

Like a lot of ports, some ports can be used by different apps for different things. I like the speedguide listings as a general reference to see 'who may be doing what with what'. For most ports, if you look them up you'd probably be surprised at the number of exploits and apps that have been found to use a given port. When I looked at that list, to me it looked the only 'legitimate' users were a couple of games which could possibly be affected by the mitigation.

As sinshiva said, there is also a reference to the port being used by Asus internally in the firmware, and is very likely where the exploit exists.

 

[sinshiva]

This is my first firewall-start script so I am wanting to verify that it is working. Should I see something in the logs?

no, however, after creating the script you also need to do;

chmod a+rx /jffs/scripts/*

 

[john9527]

This is my first firewall-start script so I am wanting to verify that it is working. Should I see something in the logs?

After you reboot....telnet/ssh to the router and

iptables -L

and you should see the rule with port 9999 in the input section

 

[jamestx10]

Looks like it is working then. Thanks

Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP udp -- anywhere anywhere udp dpt:9999

 

[RMerlin]

rather than firewalling port 9999, I killed the process that was listening on it. So far I haven't noticed any breakage, but I pretty much only use the router to, um, route (as opposed to using it for a file or application server) so I may not be a very good test case. While I was at it I got rid of the process listening on 9998 too.

admin@RT-AC66U-3D70:/tmp/home/root# lsof |grep 999
infosvr 409 admin 4u IPv4 1840 0t0 UDP *:9999
ots 419 admin 4u IPv4 1857 0t0 TCP *:9998 LISTEN
admin@RT-AC66U-3D70:/tmp/home/root# killall infosvr
admin@RT-AC66U-3D70:/tmp/home/root# killall ots
admin@RT-AC66U-3D70:/tmp/home/root# netstat -na|grep 999
admin@RT-AC66U-3D70:/tmp/home/root#

I'm not sure it won't get restarted at some point, so I'd suggest also creating the firewall script.

 

[seth_space]

This is the culprit ( no disclosure)
ASUSWRT version 3.0.0.4.376_1071 suffers from a remote command execution vulnerability. A service called "infosvr" listens on port 9999 on the LAN bridge. Normally this service is used for device discovery using the "ASUS Wireless Router Device Discovery Utility",

 

[noric]

Does this affect every firmware version? Pre-376 too?
Thanks.

 

[Vandergraff]

The security hole is *ONLY* exploitable from the LAN, so if you trust everyone on your LAN, then it isn't too serious.

So I assume the LAN includes Guest Network(s) in this case?

 

[dualm]

I have my second router in "AP Mode". Is this also affected?
I ran the "iptables -L" on this and it looks "empty" before I apply the firewall rule. Is this normal?

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

 

[coldwizard]

I have my second router in "AP Mode". Is this also affected?
I ran the "iptables -L" on this and it looks "empty" before I apply the firewall rule. Is this normal?

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Yes to both questions. Normal for AP mode empty rules, and firewall needed since infosvr is running.

If in doubt, run "netstat -na | grep 999" and if you see port 9999 listening, you need to block access to it to protect that Asus device.