SECURITY: LAN-side security hole - mitigation

[dualm]

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?

 

[coldwizard]

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.

#!/bin/sh
logger -t $0 "args $1"
iptables -I INPUT  -p udp --dport 9999 -j DROP

 

[noric]

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:

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

 

[hggomes]

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.

 

[jim769]

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 ?

 

[hggomes]

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.

 

[thiggins]

Cat's out of the bag guys

http://arstechnica.com/security/201...someone-on-your-network-can-probably-hack-it/

 

[RMerlin]

http://arstechnica.com/security/201...someone-on-your-network-can-probably-hack-it/

I saw. The odd thing is the CVE ID they refer to doesn't seem to exist, so no idea how much has been disclosed yet.

 

[jim769]

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.

 

[hggomes]

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

killall -9 infosrv

 

[DaveMishSr]

OFF TOPIC - "Cat's Out of the Bag"

http://arstechnica.com/security/201...someone-on-your-network-can-probably-hack-it/

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.

 

[sloach]

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

 

[dnlongen]

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.

 

[RussellInCincinnati]

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.

 

[RMerlin]

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.

 

[RMerlin]

I'll try to get 376.49_5 out tonight with the vulnerable portion of infosvr disabled (without disabling the whole service).

For those who are in a hurry, there is a separate branch on Github:

https://github.com/RMerl/asuswrt-merlin/commits/376.49_5

 

[RMerlin]

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.

 

[sinshiva]

http://it.slashdot.org/story/15/01/...can-be-exploited-by-anyone-inside-the-network

 

[RMerlin]

http://it.slashdot.org/story/15/01/...can-be-exploited-by-anyone-inside-the-network

Oh noes.

Tim, is your server beefed up enough to sustain being slashdotted now?

Last year when the AiCloud issue came to light, my website was mentioned on Slashdot. My website traffic on that day either doubled or tripled, if I recall.

 

[M1ch43lk]

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

$ 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