ASUS RT-AC87U WPA2 key cracked in 2 seconds

If you can connect to your router using admin/admin over telnet, then it means it's what was configured on it, since telnet authenticate using the same login used for the webui. admin/admin is the default login credentials.

Also, to access that Main_AdmStatus_Content.asp page, you had to be logged on the router, meaning you already knew the login credentials to begin with...

By the way, this little hack is nothing new - this was documented back in April 2013 as part of a device review...

The hole is still there in the latest commercial release.. as of this post - 3.0.0.41

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

sfx

RMerlin said:

If you can connect to your router using admin/admin over telnet, then it means it's what was configured on it, since telnet authenticate using the same login used for the webui. admin/admin is the default login credentials.

Also, to access that Main_AdmStatus_Content.asp page, you had to be logged on the router, meaning you already knew the login credentials to begin with...

Click to expand...

Yeah, but on the WL-330NL, one logs into WebGUI via the supervisor code - and I bypassed that completely by going to the hidden page... and better yet, on the WL-330NUL, the admin password...

can't be changed in the WebGUI...

One can change the WPA/WPA2 passphrase... at the same time, the Guest Network is open, and depends on the portal.

The design issue here is that without authentication at all - that hidden page, it's a shell interpreter... I can type in any legal command there, not just enable telnetd

In other words, broken by design...

RMerlin said:

If you can connect to your router using admin/admin over telnet, then it means it's what was configured on it, since telnet authenticate using the same login used for the webui. admin/admin is the default login credentials.

Also, to access that Main_AdmStatus_Content.asp page, you had to be logged on the router, meaning you already knew the login credentials to begin with...

Click to expand...

see?

sfx2000 said:

So, still in the same browser window, we type in the following URL (again, this is on the Guest Network)

http://router.asus.com/Main_AdmStatus_Content.asp - see below

View attachment 3786
I type in the window - telnetd, and press return...

Go back to terminal - in this case, the client IP is 192.168.2.8, so I telnet to 192.168.2.1... and here, it's not the supervisor code normally needed to access config, it's admin/admin

yes, think about that... and think about it again.

View attachment 3787

------------

That's right - I now have a command line shell on the router, running as a privleged user..

This is how Asus treats your network, the data you attach on the USB drive, VPN tunnel coming in, etc.. etc.. etc.

Really easy to break security.. and cheaper to implement right the first time

sfx

Click to expand...

Nice job sfx! That is so epic I feel so much safe...

so to fix this; again RMerlin, this isn't so hard, it's not a full rewrite at the moment, but will give folks some breathing room...

1) Don't let Guest Network run Open WiFi - make the user set at least a WPA/TKIP passphrase..

This was an issue I raised heck with Linksys on my WRT1900ac review - their Guest Networks run open - getting access to the captive portal means I have access to the built-in WebServer, then I can start peeling up edges...

They didn't get the point...

2) Remove the "hidden" page now - it's broken, and due to ASUS design, if you can get there, you've got root/admin

3) If one must run a Portal Page - make it really simple - don't identify the vendor, and certainly not the model number - having both of these - it's an internet search to check default password - heck, even here ASUS failed - as the WebGUI wants the supervisor password, but at the shell, it's not used - again, bad design, and an opportunity lost...

Seriously - that hidden page needs to just go away, there's no check for userid... it's over in a directory that is served by a daemon running as root...

At least put an .htaccess file in front of it, as for now, it's something that is very vulnerable to XSS attacks, and being that it's a command line interpreter, basically a shell, with root/admin access, this is a very bad design...

FWIW - I'm not a haxxor - I'm a developer, I've got the technical knowledge, tools, and insight into the designs - and I know where the edges can be peeled up - I make my designs robust enough, knowing that there's even more determined people out there to break things.

This was all to prove a basic point...

sfx2000 said:

see?

View attachment 3788

Click to expand...

Sorry, I thought you were hitting an actual full-featured router rather than this small embedded device that seems a few years old. What puzzles me is the fact that the Adm page is there at all on this device, I'd expect it to only be available on their full-featured routers, where access to it requires authentication.

Sounds a case where they simply reused Asuswrt, cut down on features, but failed to remove sensitive components that shouldn't be there. And based on the version number you are posting, sounds like it hasn't been updated in over three years. Wouldn't surprise me if it also ran the vulnerable version of infosvr.

What can I say. It's par for the course for all those inexpensive home gateways. But I've seen Asus try harder than most others at fixing things (*cough* DLink...)

The point I was originally making was that to achieve *COMPLETE* security the way you were mentioning (process isolation, separation of privileges, etc...) would require a complete rewrite of the firmware, and some major investments. I'm not debating the fact that security needs to improve - I've posted often enough myself in the past on this topic. I was merely stating that you will never see a 30$ router achieve the same level of security as a 3000$ one.

Heck, the actual thing would need to start with Broadcom. Their SDK isn't even designed around the concept of multiple users. The vast majority of router functions are handled by the rc daemon, which has to run as root since it has to handle everything, from HW initialization down to routing/firewall configuration.

RMerlin said:

Sorry, I thought you were hitting an actual router. What puzzles me is the fact that the Adm page is there at all on this device, I'd expect it to only be available on their full-featured routers, where access to it requires authentication.

Sounds a case where they simply reused Asuswrt, cut down on features, but failed to remove sensitive components that shouldn't be there. And based on the version number you are posting, sounds like it hasn't been updated in over three years. Wouldn't surprise me if it also ran the vulnerable version of infosvr.

Click to expand...

It is a "real router" that ASUS sells, and the firmware release date is March 2nd, 2015...



If this is the care/attention they pay to their devices - and pulling the GPL source, it's common across ARM/MIPS platforms...

Well... ain't good...

In the end, RMerlin, it's not your problem - you've done a great job at mashing some bugs, but this is general design issues, well beyond your scope.

So - my best recommendation is to report this upstream and get them to review their code across all their products.

The vulnerability is there...along with many others - so time for ASUS to step up and lean into the problems they have - they shouldn't depend on independent engineers to find/fix their bugs..

sfx

sfx2000 said:

It is a "real router" that ASUS sells, and the firmware release date is March 2nd, 2015...

View attachment 3789

Click to expand...

Odd. The version number isn't in-line with current Asuswrt code, yet it does use elements from Asuswrt (such as the Adm page), so it sounds like a complete fork, except they didn't spend much time cleaning it up.

And yes, the WL-300NUL is a corner case... but I knew this going in that it would be interesting to dig into based on it's multiple-mode functionality... in any event, corner cases expose things that developers miss..

Can't help it - engineer...

sfx

RMerlin said:

The point I was originally making was that to achieve *COMPLETE* security the way you were mentioning (process isolation, separation of privileges, etc...) would require a complete rewrite of the firmware, and some major investments. I'm not debating the fact that security needs to improve - I've posted often enough myself in the past on this topic. I was merely stating that you will never see a 30$ router achieve the same level of security as a 3000$ one.

Heck, the actual thing would need to start with Broadcom. Their SDK isn't even designed around the concept of multiple users. The vast majority of router functions are handled by the rc daemon, which has to run as root since it has to handle everything, from HW initialization down to routing/firewall configuration.

Click to expand...

In 2005, resources were more limited, and less features in the SOHO gateways... 10 years later, we have many more features, cpu and ram resources, and lay people just adding things in because some web site says it's cool to have...

and the bugs, those that have been there all along, are still there - and they're design issues for the most part...

ASUS, being a huge vendor in the recent wave of AP/Routers, is a big threat surface, and one that is rich in opportunities for black-hats to explore...

D-Link, Netgear, Linksys - similar... the one top tier OEM that does take security seriously, and develops their own SW/Board Support Platforms, is Apple in the general consumer space... folks may complain, including here in the SNB reviews, about not having an embedded WebServer to configure it, but guess what, that's one less security problem... and a big one at that.

sfx2000 said:

In 2005, resources were more limited, and less features in the SOHO gateways... 10 years later, we have many more features, cpu and ram resources, and lay people just adding things in because some web site says it's cool to have...

and the bugs, those that have been there all along, are still there - and they're design issues for the most part...

ASUS, being a huge vendor in the recent wave of AP/Routers, is a big threat surface, and one that is rich in opportunities for black-hats to explore...

D-Link, Netgear, Linksys - similar... the one top tier OEM that does take security seriously, and develops their own SW/Board Support Platforms, is Apple in the general consumer space... folks may complain, including here in the SNB reviews, about not having an embedded WebServer to configure it, but guess what, that's one less security problem... and a big one at that.

Click to expand...

Except that the only reason anyone buys an Apple Airport is because they want an Apple product. Replace the apple with an orange, and nobody would ever want to buy it.

Let's face it - the market is driven by demand. Customers demand features at a low cost above everything else. And with a 9 months turnaround from development to product launch, routers have become fast food type of products...

Personally, I think the first step manufacturers should take is getting rid of the old crud. The infosvr and networkmap services in Asuswrt (two locations that were filled to the brim with buffer overruns - I must have fixed four or five of these in the networkmap daemon alone) contain code that is over 10 years old, back in the day where nobody cared about potential buffer overruns. Same thing with Linksys: bonus point to anyone that can tell what the "Filter identd request" setting on Linksys's webui is for (it was still there as of last year). I wonder if their current firmware developers even know themselves what this setting is for. Many of them are probably not even old enough to have ever seen an identd daemon running To me, that indicate a lack of interest in actively maintaining the existing code.

Just doing such housekeeping on the existing firmware wouldn't require extensive resources, and would already resolve a lot of potential issues. Busybox 1.10 (Asus is being "modern" by being at 1.17, but only because they inherited it from Tomato), Samba 3.0.x, openssl 0.97 or 0.98, dnsmasq 2.5x... The vast majority of these manufacturers stick to 5-10 years old code, never thinking about the need to upgrade any of these. Upgrading those security-sensitive components would also be a step in the right direction, once again without the need to devote too many resources. One developer spending a few weeks could at least cover bringing these to a version that's at least less than 5 years old, and testing them for regressions.

RMerlin said:

Except that the only reason anyone buys an Apple Airport is because they want an Apple product. Replace the apple with an orange, and nobody would ever want to buy it.

Click to expand...

If it were sold under another brand, folks would rave about stability and performance -- the ding on the Airport is the '90 platform wars...

I agree with you - it's time for the tier ones to take a colonic and blow the old crap out... and do a proper design - we're at the cusp of the Internet of Things, where the house is going to become even more connected, and security is paramount there, and a very big concern...

Since we're looking at the top-tier SOHO now at the $250 dollar range, investments here, wisely done, will trickle down into the $30 product tiers as the old ones age out..

sfx