What's new

SECURITY: LAN-side security hole - mitigation

  • 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!

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.

Thanks for your answer.

But are the instructions in post #1 valid for a router in "AP mode"? It looks like the firewall-start is not executed in this mode. Right?
Or is it just me?
 
Last edited:
Thanks for your answer.

But is the instructions in post #1 valid for a router in "AP mode"? It looks like the firewall-start is not executed in this mode. Right?
Or is it just me?

You are correct. I just blindly created the firewall-start without checking a reboot.

Now I have moved it to the file services-start (merlin can you confirm this the best place)

The logger command puts an entry into the system log to tell me the file was executed.

Code:
#!/bin/sh
logger -t $0 "args $1"
iptables -I INPUT  -p udp --dport 9999 -j DROP
 
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.

I have the following output if I issue that command:
Code:
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:*
Do I need to block anything?
Thanks
 
That service (infosvr) was already killed in my setup via bootscript, like some other services and firewall rules used by default on the FW (PControls) that are not used/needed by anyone 99% of the times.
 
Last edited:
That service (infosvr) was already killed in my setup via bootscript, like some other services and firewall rules used by default on the FW (PControls) that are not used/needed by anyone 99% of the times.

So your saying this is not a issue with your fork firmware ?
 
No, it's still there, all my fork changes are described in my thread.

I had already reported this security hole to ASUS when it was released, so it's a matter of time so they fix it.

What i ment was that i configured my routers (after the FW flashed) to kill infosrv and other services not used, aswell some rules that are by default applied by the FW.
 
Last edited:
Has anyone heard any official word when Asus plans to patch this issue ? Do they even consider it high priority ? I would have thought they would have done something this cant be to difficult to fix.
 
I've reported already that to ASUS networking support, lets wait for a fix, my fix by now is this:

killall -9 infosrv
 
Last edited:
OFF TOPIC - "Cat's Out of the Bag"

Okay this is off-topic so please read on at your peril. Does anyone know what the saying "Cat's Out of the Bag" origin and original meaning are without looking it up? Spoiler alert! Answer below:

























Its origins are in reference to mid-evil England marketplace scams. People, especially butchers, would go to marketplaces in order to purchase pork. Well unscrupulous vendors would pull a bait and switch. A pig would be shown to the customer but a live cat would be bagged in the canvass bag used to get the purchase back home or whatever.

Of course, the jig would be up when the customer opened the bag once at home when it would be too late to confront the "merchant". So at that point, "the cat would be out of the bag" and the deception exposed. As you were.

PS: Sorry Tim and Eric. Feel free to delete this post.
 
Last edited:
My company has a software product that runs on ASUS routers. We've released an update that automatically works around this vulnerability for our users (on stock ASUS firmware) - you can read about it here:
https://www.aterlo.com/blog
 
Fixing in an init script on stock firmware

This is a slight tangent, but an article I wrote a couple of weeks ago describes a way to set a persistent init script in the stock firmware. Stock firmware has /JFFS enabled but doesn't (afaik) support the firewall-start script.

Setting the nvram script_usbmount value is a workaround (as long as you have a usb device plugged in to trigger running this script).

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.
 
Last edited:
SLoach, the NightShift product sounds creative, and it is nifty that you are taking advantage of the fact that your software is already autostarting on the router...thus you can also auto-start something like the security loophole mitigation.
 
Has anyone heard any official word when Asus plans to patch this issue ? Do they even consider it high priority ? I would have thought they would have done something this cant be to difficult to fix.

All I know is that their development team did have an actual meeting to discuss how best to address the issue, so obviously they are taking this seriously - we're talking about remote code execution after all.
 
Last edited:
I uploaded 376.49_5, which has the vulnerable section of infosvr disabled, as well as an additional security fix applied.

Note that these builds have received about no real testing beside flashing the AC87U build on my main router and re-testing the vulnerability. However since there are no other changes over 376.49_4, it _should_ be fine.
 
Last edited:
I uploaded 376.49_5, which has the vulnerable section of infosvr disabled, as well as an additional security fix applied.

Note that these builds have received about no real testing beside flashing the AC87U build on my main router and re-testing the vulnerability. However since there are no other changes over 376.49_4, it _should_ be fine.

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

Code:
$ 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
 

Sign Up For SNBForums Daily Digest

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