Merlin Vulnerabilities?

[panhead20]

Asus has release new firmware with several security fixes,

- Fixed CVE-2015-6949 buffer overflow issue, special thanks for Elvis Collado at Praetorian.
- Fixed Web server Accept-Language buffer overflow, special thanks for Elvis Collado at DVLabs.
- Fixed Web server URL handler buffer overflow, special thanks for Elvis Collado at DVLabs.
- Fixed CSRF and XSS vulnerability.

http://www.asus.com/us/Networking/RTAC66R/HelpDesk_Download/

Does the current Merlin firmware, 55, have these vulnerabilities?
If so, expected time frame for new release 56?

 

[hggomes]

Yes, if you dont have webui exposed to internet you should be fine.

 

[sfx2000]

- Fixed CSRF and XSS vulnerability.

A bit of concern is this one, as it may be exploited from inside the LAN interface if one is already authenticated into the Router WebGUI...

Cross Site Request Forgery
Cross Site Scripting

As hggomes suggests, don't expose WebGUI to the public WAN side, and I would also suggest ensuring that one is logged out of WebGUI when finished (and perhaps even quit/restart the browser).

 

[XIII]

I was thinking about this as well.

Does the vanilla Asus firmware support ssh & jffs so that I can install a stand-alone version of DNSCrypt? Or should I stick to a Merlin firmware for that?

 

[RBJ32]

(Coming from green novice)
How exactly does one expose their webui to internet?

Also is it of any real value to change your router's default IP to try and prevent Cross Site Request forgery? Some say it takes time to script this others say not so much to stop the attack. I also read that DHCP will give anyone (including the bad guys) connecting to your network the router LAN address as part of the host configuration.

 

[skeal]

(Coming from green novice)
How exactly does one expose their webui to internet?

Also is it of any real value to change your router's default IP to try and prevent Cross Site Request forgery? Some say it takes time to script this others say not so much to stop the attack. I also read that DHCP will give anyone (including the bad guys) connecting to your network the router LAN address as part of the host configuration.

By allowing web access from WAN on the System page.

 

[skeal]

Don't do it use a vpn for remote access.

 

[RBJ32]

Don't do it use a vpn for remote access.

Oh you mean by setting the router to "Remote Access" or "Enable Web Access from WAN" etc. Thanks, at first it went right over my head.

On the other CSFR is it any real deterrent to change a router's default IP?

 

[skeal]

Oh you mean by setting the router to "Remote Access" or "Enable Web Access from WAN" etc. Thanks, at first it went right over my head.

On the other CSFR is it any real deterrent to change a router's default IP?

I don't think its an issue. You just have to keep things straight yourself. Gateway and all that.

 

[RBJ32]

I noticed on my router even though remote web access is set to OFF, from a computer within my local LAN in a Browser with my PUBLIC (not local) IP, I could bring up my router's interface, and with the password could log in to the router's setup. I surmise if I were outside my local LAN this would not be possible without remote access being ON?

 

[thelonelycoder]

I noticed on my router even though remote web access is set to OFF, from a computer within my local LAN in a Browser with my PUBLIC (not local) IP, I could bring up my router's interface, and with the password could log in to the router's setup. I surmise if I were outside my local LAN this would not be possible without remote access being ON?

This answers why and how you should test it:
https://www.snbforums.com/threads/where-is-ping-response-coming-from.55856/#post-476658

 

[RBJ32]

This answers why and how you should test it:
https://www.snbforums.com/threads/where-is-ping-response-coming-from.55856/#post-476658

Thanks for that!