FTC Dings ASUS For Selling 'Secure' Routers.

[Patricia]

If someone came to me today, told me he needed a totally secure router and which one to buy, my answer would probably be "None currently sold". Even business-class routers were recently put into the light, with companies such as Mikrotik, Juniper and Cisco having their fair share of security problems.

The ideal (not always realistic however) solution would be to run a Linux or BSD-based solution of your own. Not only will you fully control the code (as it will be 100% closed-source), but when a security flaw appears in, say, OpenSSL, you can update it almost on the same day as the patch is available. With manufactured devices, you have to wait days, weeks (if not forever) to get an updated firmware.

The second best alternative would be OpenWRT, as it's fully open-sourced, and actively developed.

These aren't always realistic however, so the next best thing is to go with a router that gets either a) frequent AND long-term firmware updates, or b) good open-source/third party support. And disable any cloud or remote access service. If you need remote access, stick to a reliable VPN solution, either OpenVPN or IPSEC-based. Ideally, it should be the only open port on your WAN side (beside your conntracked connection, obviously).

Right, nothing will likely have perfect security. What I meant earlier was the first step to fixing a problem is to stop being in denial about it. Then to formulate a plan to make things better. What this translates to is having a reasonable SLA for addressing security issues and having a channel to securely report issues.

Custom softwares, whether its wrt or something else will always have more security issues. More code translates to more flaws, it's just how software is. It should have its own channel for receiving vulnerability reports from partners or customers.

 

[RMerlin]

Custom softwares, whether its wrt or something else will always have more security issues. More code translates to more flaws, it's just how software is. It should have its own channel for receiving vulnerability reports from partners or customers.

Companies already have to provide privacy disclosure for their products and services. It wouldn't be asking for too much indeed to also have them include in these a point of contact/procedure to contact them about security-related issues.

 

[sfx2000]

If someone came to me today, told me he needed a totally secure router and which one to buy, my answer would probably be "None currently sold". Even business-class routers were recently put into the light, with companies such as Mikrotik, Juniper and Cisco having their fair share of security problems.

Microtik, Juniper, Cisco, and the FOSS sources - they have their issues, should note they respond quickly, and their scope is generally limited in any event as a threat surface - they generally don't do "cloud" services...

In this case, it was the value add along with general security issues that perhaps were introduced by upstream - in any event, Asus was in front of the bus when the least expected...

AiCloud and other services - this is something that Asus can fix, right now, as this has nothing to do with the Router/AP code now - they'll have to deal with issues on that shortly...

While Asus flew a little bit close to the sun, other vendors need to examine closely what they've done and implemented... who is next in line for a fair woodshed beating?

Basically - the more stuff one puts into the Router/AP - the higher risk it's going to be..

The ideal (not always realistic however) solution would be to run a Linux or BSD-based solution of your own. Not only will you fully control the code (as it will be 100% closed-source), but when a security flaw appears in, say, OpenSSL, you can update it almost on the same day as the patch is available. With manufactured devices, you have to wait days, weeks (if not forever) to get an updated firmware.

The second best alternative would be OpenWRT, as it's fully open-sourced, and actively developed.

I wouldn't put 100 percent trust in that either...

Anyways - I'm still of the belief that the ASUS woodshed beating/thrashing is going to be a good thing for them - short term pain, longer term gain as we see higher quality drops...

 

[TexasFlood]

As I understand it, Asus "fixed" the security issue about two years ago. The fix was to update the firmware so users had to set a password. Really? Apparently so...

Sent from my SCH-I535 using Tapatalk

 

[RMerlin]

As I understand it, Asus "fixed" the security issue about two years ago. The fix was to update the firmware so users had to set a password. Really? Apparently so...

There were numerous issues pointed at. There was AiCloud that wasn't properly secured, FTP defaulting to allowing anonymous access over WAN, etc... A lot of these could indeed be resolved by the user carefully configuring his router security rather than accepting the unsafe defaults.

But that's beside the real issues that also happened these past few years, such as infosvr allowing root access to any LAN user, Samba being exposed to WAN, various XSS vulns, etc...

 

[TexasFlood]

There were numerous issues pointed at. There was AiCloud that wasn't properly secured, FTP defaulting to allowing anonymous access over WAN, etc... A lot of these could indeed be resolved by the user carefully configuring his router security rather than accepting the unsafe defaults.

But that's beside the real issues that also happened these past few years, such as infosvr allowing root access to any LAN user, Samba being exposed to WAN, various XSS vulns, etc...

Guess it's good I've just used mine as a basic router since getting an Asus and not enabled external access. A little googling based on your post led me to the CVE database do I can catch up.

Thanks for the info Eric...

 

[Patricia]

Guess it's good I've just used mine as a basic router since getting an Asus and not enabled external access. A little googling based on your post led me to the CVE database do I can catch up.

Thanks for the info Eric...

I need to see if they fixed this but it used to be possible to turn remote on when it was off from the Internet.

Also keep in mind, most attacks can use your browser as a bridge to proxy malicious request from Internet to appear as if it's from the local Intranet... Hint, it's spec'ed behavior. Thus bypassing your external access setting by design. I found atleast a dozen vulns I can exploit this way when I last looked as a hobbyist.

The vulns allowed me to turn cloud on, change the wifi password, etc. and I too had my router configured to disable pretty much everything. As Merlin hinted many of these issues transcended configuration issues.

 

[Nullity]

I need to see if they fixed this but it used to be possible to turn remote on when it was off from the Internet.

Also keep in mind, most attacks can use your browser as a bridge to proxy malicious request from Internet to appear as if it's from the local Intranet... Hint, it's spec'ed behavior. Thus bypassing your external access setting by design. I found atleast a dozen vulns I can exploit this way when I last looked as a hobbyist.

Are you referring to CSRF attacks?

 

[TexasFlood]

One bad habit I used to have was to stay logged into my routers after accessing them as I didn't realize that was a vulnerability. Quit doing now that but used to all the time.

Sent from my SCH-I535 using Tapatalk

 

[Patricia]

One bad habit I used to have was to stay logged into my routers after accessing them as I didn't realize that was a vulnerability. Quit doing now that but used to all the time.

Sent from my SCH-I535 using Tapatalk

Good way to raise the bar but it doesn't protect you from things like command injections and memory corruption flaws which may not do auth in time. At any rate, I think the FTC gave all vendors a nice wake up call. A great step in the right direction for consumers.

 

[Nullity]

Good way to raise the bar but it doesn't protect you from things like command injections and memory corruption flaws which may not do auth in time. At any rate, I think the FTC gave all vendors a nice wake up call. A great step in the right direction for consumers.

If you are referring to exploitable browser flaws that can run arbitrary commands on the local machine, well... it's game over regardless of what router you have.

Can you more precisely explain what you are talking about? Security information is useless when it's ambiguous.

 

[Patricia]

If you are referring to exploitable browser flaws that can run arbitrary commands on the local machine, well... it's game over regardless of what router you have.

Can you more precisely explain what you are talking about? Security information is useless when it's ambiguous.

Your asuswrt had web end points to initiate things like tracert, pings, etc. the uri for the endpoint looked like this (Simplified explanation to approximate the issue): http://router_ip/command.ext?cmd=ping&arg=dest_ip. The router then just concatenated the cmd and arg and called system on "ping dest_ip". Bad actors could inject commands by crafting a uri that had additional commands in the dest parameter. E.g. 1.1.1.1 && injected_cmd. This uri in turn could be embedded as a src for an img at a forum like this. Then everyone who views this forum would end up running arbitrary commands on their router. Reverse shell anyone?

Anyways, that's just one class of issues out of many.

If you're interested in learning more about security try going to your local sec meet ups. OWASP usually has monthly meet ups depending on where you live.

 

[Nullity]

Your asuswrt had web end points to initiate things like tracert, pings, etc. the uri for the endpoint looked like this (Simplified explanation to approximate the issue): http://router_ip/command.ext?cmd=ping&arg=dest_ip. The router then just concatenated the cmd and arg and called system on "ping dest_ip". Bad actors could inject commands by crafting a uri that had additional commands in the dest parameter. E.g. 1.1.1.1 && injected_cmd. This uri in turn could be embedded as a src for an img at a forum like this. Then everyone who views this forum would end up running arbitrary commands on their router. Reverse shell anyone?

Anyways, that's just one class of issues out of many.

If you're interested in learning more about security try going to your local sec meet ups. OWASP usually has monthly meet ups depending on where you live.

I think they removed the command-via-HTTP functionality long ago.

Are there other command injections or memory corruption flaws you know of that are applicable to the current AsusWRT?

 

[Patricia]

I think they removed the command-via-HTTP functionality long ago.

Are there other command injections or memory corruption flaws you know of that are applicable to the current AsusWRT?

They need to pay someone to do this job . Besides, if there are 0-days it would do more harm than good posting this in a public forum.

I did hear from my friends that custom wrts have additional features in this area that stock wrt doesn't. So it's probably worth digging into that. But lately I only participate in paid bounties. Mind as well work on stuff that pays right?

 

[Nullity]

They need to pay someone to do this job . Besides, if there are 0-days it would do more harm than good posting this in a public forum.

I did hear from my friends that custom wrts have additional features in this area that stock wrt doesn't. So it's probably worth digging into that. But lately I only participate in paid bounties. Mind as well work on stuff that pays right?

I thought you could perhaps share a CVE or write-up of prior vulns, preferrably related to AsusWRT and login authentication.

I was only looking for a bit of proof that proactively logging out of the router does not protect from "command injections and memory corruption flaws which may not do auth in time". The statement is potentially true, but without proof of concept, the statement is no more informative than saying "security is imperfect", which is not that helpful.

 

[Patricia]

I thought you could perhaps share a CVE or write-up of prior vulns, preferrably related to AsusWRT and login authentication.

I was only looking for a bit of proof that proactively logging out of the router does not protect from "command injections and memory corruption flaws which may not do auth in time". The statement is potentially true, but without proof of concept, the statement is no more informative than saying "security is imperfect", which is not that helpful.

Not trying to be mean but you're some random dude on the Internet. I'd be happy to prepare a shiny deck and PoC to give you a crash course on past CVEs, non-public vulns fixed without CVEs, walk through the exploits with step by step explanation, and also educate you on how the severity ratings were calculated. But you'd have to make it worth my time.

Or you can dig into the code or pay someone to do it for you. Whether the impacted code is open source or private, you should be able to read the dissaesembly. If you're incapable of doing this then I'd argue it's not my problem.

 

[TexasFlood]

This is all making me lean towards putting the Linksys LRT214 on my WAN and wireless access points behind it.

 

[Patricia]

This is all making me lean towards putting the Linksys LRT214 on my WAN and wireless access points behind it.

Not sure if that helps as all brands suck when it comes to securing their router firmware. It's a bit ridiculous exploits that stopped working in the 90s stills work on many routers.

I hope the FTC or whoever has the authority cracks down on all vendors. If they need to make an example out of asus for this to happen then so be it.

 

[TexasFlood]

Not sure if that helps as all brands suck when it comes to securing their router firmware. It's a bit ridiculous exploits that stopped working in the 90s stills work on many routers.

I hope the FTC or whoever has the authority cracks down on all vendors. If they need to make an example out of asus for this to happen then so be it.

That may be but I'm not seeing a lot of reports of issues with the lrt214. Now that might just be because there aren't enough sold to justify looking at it, hah, I don't know.

 

[Nullity]

Not trying to be mean but you're some random dude on the Internet. I'd be happy to prepare a shiny deck and PoC to give you a crash course on past CVEs, non-public vulns fixed without CVEs, walk through the exploits with step by step explanation, and also educate you on how the severity ratings were calculated. But you'd have to make it worth my time.

Or you can dig into the code or pay someone to do it for you. Whether the impacted code is open source or private, you should be able to read the dissaesembly. If you're incapable of doing this then I'd argue it's not my problem.

Fair enough, but most of us are "random dudes on the internet". Until we prove our claims those claims are hot air. I made no claims, you did. Call me skeptical, but I do not believe everything I read on the internet. I only criticized your claims, not you personally, so please try to do the same.

Just like the well-respected Wikipedia, cite your source.

Apologies if you are some well-established security researcher that I am unaware of. Do you have a link to past CVEs, write-ups, PoCs, etc, that you have published?