Asus router firmware security

[fr33z0n3r]

I have just decided to do my first nessus scan of my router and found the issues to be concerning.

Device: RT-AC68U
Firmware: RT-AC68U_3.0.0.4_374.43_2 (Merlin build)

I know this isn't Merlins issue, but I wanted to make sure that folks were aware of how bad things look at the device if any of the related ports was exposed over the internet.

If you even consider opening up SMB (microsoft sharing) for any reason you are toast. I am usually careful to ensure that this port is not used, but I must have forgotten all the boxes in the last reset.

And this scan isn't even complete yet. I'll update the pic if it is useful.

I do not have any of the various services enabled. (except this SMB service of course UPDATE: Found where I left "Set as WINS server" on.)

 

[RMerlin]

Samba will be an issue for the vast majority of routers or low-end devices. Newer versions of Samba are flat out unusable on those devices, because after version 3.3/3.4, it's become ridiculously large. Back when I was working with the wdlxtv project, I remember that Samba 3.5 was taking nearly 20 MB of flash space. It took quite some acrobatics for me to fit it in the current firmware partition.

Considering the higher-end Asus routers currently have a rootfs partition size of 32 MB, you can see how this ridiculous bloat is unusable, and Asus is forced to use a much older version.

Until the Samba team can cut down on the bloat and provide with a solution that's usable for small embedded devices, it will remain a problem. I doubt they will ever have any solution, so that means we'll just have to wait for manufacturers to start using larger NAND chips, and add more RAM.

 

[fr33z0n3r]

any idea if the fact that SMB is active on my AC68U is a bug? (unless there is some odd place to disable SMB I think I got them all shutdown)

I saw the old thread from early this year about the WAN access to 445. Could this be a similar issue?

NEVERMIND: "Set as WINS server"

 

[Chrysalis]

what tool did you use for that scan?

in my view if asus cannot put on a secure version of samba then they shouldnt put it on at all.

 

[RMerlin]

what tool did you use for that scan?

in my view if asus cannot put on a secure version of samba then they shouldnt put it on at all.

You probably skipped my post, because as I explained, if router manufacturers did what you suggested, there wouldn't be a single router out there right now that would have USB sharing...

Some vulnerabilities that are only exposed LAN-side are tolerable. If you have a client that can exploit your router, then you already have a more serious problem with your LAN IMHO.

 

[Chrysalis]

or there would be but with the larger flash storage as you also suggested.

another thing I noticed is after I had hardened the ciphers in my ssh client I had to weaken again for the router. On asus code that is 2014 based.

if someone enables wan access, does the router popup informing the user the code is vulnerable and shouldnt enable?

 

[RMerlin]

or there would be but with the larger flash storage as you also suggested.

another thing I noticed is after I had hardened the ciphers in my ssh client I had to weaken again for the router. On asus code that is 2014 based.

I added ECDSA support to Asuswrt, so you can go down that route if you want to increase security without hitting a performance wall due to the router's CPU.

if someone enables wan access, does the router popup informing the user the code is vulnerable and shouldnt enable?

Wan access to what? SSH? No, because it's certainly secure enough for a home device. If you need military-grade or corporate-grade security, you shouldn't be using a home router running a cut-down SSH server such as Dropbear IMHO, with a CPU that has no hardware-accelerated AES support.

As for Samba, there is no option to allow WAN access to it.

 

[fr33z0n3r]

what tool did you use for that scan?

This is using nessus from Tenable. They have a free Home edition.

 

[fr33z0n3r]

FYI, one of the potentially concerning issues that could easily be exploited from a browser is the generic XSS issue.

The request string used to detect this flaw was :

/scripts/<script>cross_site_scripting.nasl</script>.pl

The output was :

HTTP/1.0 200 OK
Server: httpd
Date: Tue, 09 Sep 2014 17:13:57 GMT
Content-Type: text/html

 

[Builder71]

FYI, one of the potentially concerning issues that could easily be exploited from a browser is the generic XSS issue.

+1

If I remember correctly, I have seen this fixed on a changelog before.
Guess not.

When I run Nessus, it doesn't give me all the Samba crap.
But I'm not using SMB.
It does give me a bunch Infos and a few Medium and Low risks.

See pic.

Edit: Nice find fr33z0n3r, "Set as WINS server -> Yes" gives me a critical.
"Samba 'AndX' Request Heap-Based Buffer Overflow".
Switched it off again as it was in the first place.

 

[RMerlin]

+1

If I remember correctly, I have seen this fixed on a changelog before.
Guess not.

XSS is just a general technique. You can fix one specific XSS-based exploit, and still have another different one still possible.

 

[Chrysalis]

merlin perhaps you can persuade asus to upgrade the current obselete sshd daemon, I am having to use old hmac's to login to my router.

 

[Builder71]

XSS is just a general technique. You can fix one specific XSS-based exploit, and still have another different one still possible.

Hmmm, weird, why fix a few XSS exploits and leave some other still exist?

Doesn't make sense to me.

 

[wouterv]

Hmmm, weird, why fix a few XSS exploits and leave some other still exist?

Doesn't make sense to me.

Probably the other exploits are not fixed because they are not discovered yet.
Software is anyway vulnerable to bugs, a famous phenomenon is that fixing one or a few bugs will cause one or more new bugs.
Bugs can only be solved once they are discovered and a fix is found (preferably without breaking other features).
No matter in how many ways you lock and secure your home, a new way to enter can be found.
Time and money are usually the contributing factors.

 

[john9527]

merlin perhaps you can persuade asus to upgrade the current obselete sshd daemon, I am having to use old hmac's to login to my router.

ssh is provided by 'dropbear'....

What problem are you having?

 

[RMerlin]

merlin perhaps you can persuade asus to upgrade the current obselete sshd daemon, I am having to use old hmac's to login to my router.

Asus isn't even using dropbear in their firmware. As for my firmware, it's already using the latest release of dropbear.

 

[Chrysalis]

I already said I am having to use obselete hmac's to login via ssh to my router.

Lately I configured my client to only use modern ciphers and hmac's and I had to readjust for the router.

It doesnt support sha2-256 or sha2-512

 

[Chrysalis]

Asus isn't even using dropbear in their firmware. As for my firmware, it's already using the latest release of dropbear.

ok thanks, I guess I need to get on to the dropbear dev then, I didnt know it wasnt a seperate package for routers.

 

[RMerlin]

Hmmm, weird, why fix a few XSS exploits and leave some other still exist?

Doesn't make sense to me.

As I said, XSS is just a type of security issue. Just because they found a few specific cases that were resolved doesn't mean they can find every single case that exists. It's like saying "they fixed a few security issues, why didn't they fix ALL security issues?".

 

[RMerlin]

ok thanks, I guess I need to get on to the dropbear dev then, I didnt know it wasnt a seperate package for routers.

Dropbear does support these, they just ain't enabled. I don't know however if it's because they have to be manually enabled, or because the linked OpenSSL doesn't have these cryptos enabled in it.

merlin@mint-dev ~/asuswrt/release/src/router/dropbear $ grep HMAC options.h
#define DROPBEAR_SHA1_HMAC
#define DROPBEAR_SHA1_96_HMAC
/*#define DROPBEAR_SHA2_256_HMAC*/
/*#define DROPBEAR_SHA2_512_HMAC*/
#define DROPBEAR_MD5_HMAC