Linksys WiFi Gateway Remote Attack Risk Discovered

Glenn Fleishman writes "According to InternetNews.com, a tech consultant discovered that even if you turn the remote administration feature off on a Linksys WRT54G -- the single bestselling Wi-Fi device in the world -- you can still remotely access it through ports 80 and 443. Linksys sets the HTTP username to nothing and password to 'admin' on all of its devices by default. Web site scanning from anywhere in the world to devices that have routable Internet-facing addresses would allow script kiddie remote access, at which point you could flash the unit with new firmware, extract the WEP or WPA key, or just mess up someone's configuration and change the password."

Comments

2 points

[millahtime]

1) 90% of the people that buy these are your basic at home user. They don't ever change the default settings. It's just a setup and go. There are 5 such ones in my apartment alone in range of my apartment

2) 99% of people aren't going to update the firmware when it comes out so this bug will be floating around for some time.

The average joe 6 pack needs to be forced to use the security with it. If you give it as an option then it many times will be ignored. Security needs to be made part of the setup and updates need to be easy to install.

Bugtraq submission

[mrgrey]

Manufacturer: LinkSys (a division of Cisco)
Product: Wireless-G Broadband Router
Model: WRT54G
Product Page:
http://www.linksys.com/products/product.asp ?grid=3 3&scid=35&prid=601
Firmware tested: v2.02.7

In a recent client installation I discovered that even if the remote
administration function is turned off, the WRT54G provides the
administration web page to ports 80 and 443 on the WAN. The implications
are obvious: out of the box the unit gives full access to its administration
from the WAN using the default or, if the user even bothered to change it,
an easily guessed password.

I reported this to LinkSys (along with a number of other non-security
related issues) on April 28. I received no reponse addressing this, and no
updated firmware has yet appeared on their firmware page
http://www.linksys.com/download/firmware.asp ?fwid= 201

To work around this, you can use the port forwarding (irritatingly renamed
to Games and whatever) to send ports 80 and 443 to non-existant hosts. Note
that forwarding the ports to any hosts -- inluding listening ones if you are
actually running servers -- will override the default behavior.

On a personal note, there are a number of reasons for which I am thoroughly
disappointed with LinkSys since the acquisition by Cisco. For the sake of
what was once a rock-solid product and great brand name, I hope things
change soon.

--
Alan W. Rateliff, II : RATELIFF.NET
Independent Technology Consultant : alan2@rateliff.net
(Office) 850/350-0260 : (Mobile) 850/559-0100

[System Administration][IT Consulting][Computer Sales/Repair]

NOT

[Merlin42]

I have one such router(HW revision 1.0, firmware 2.02.7) so I gave it a guick check (again ... I tested it when I bought it) and I can't get the remote administration page on the WAN. Currently, I only forward port 22 and I disabled the DMZ.

Re:port fowarding

[mccalli]

What happens if you are fowarding port 80 to an internal box?

From the article:

"As a workaround until a firmware upgrade is issued, Rateliff recommends the use of port forwarding send ports 80 and 443 to non-existent hosts. "Note that forwarding the ports to any hosts -- including listening ones if you are actually running servers -- will override the default behavior," he explained."

So you're ok. As am I, or at least as I will be after I've just finished forwarding 443...

Cheers,
Ian

Additional info on WRT54G administration page

[alanxyzzy]

This BUGTRAQ article has some interesting observations made by the original reporter of this vulnerability.

I have made the effort to grab three additional units, all v2 hardware, off-the-shelf, and here is what I have found: Two of three units came with the firewall enabled, while one of the three came with it disabled. The packaging leaves no evidence as to whether any of these items were previously opened and returned.

Interestingly, all three units from local resalers came with v2.02.2 firmware, while the second unit from CDW I tested in March came with v2.02.7. BOTH of the units which came off-the-shelf with v2.02.7 behaved as previously described in my original notice; I do not have records of the firewall setting of the units from March, although they both did behave as predicted after a factory reset.

I would like to assume that the one-of-three v2.02.2 firmware units which came with the firewall disabled was an anomoly, and possibly a customer return. Nicely, flashing these units to v2.02.7 retains all settings, including the firewall status.

Now the catch. In v2.02.7 with the firewall disabled and remote admin turned off, the admin page becomes available on ports 80 and 443 on the WAN. This works whether the unit is in DHCP or PPPoE mode.

Port State Service
80/tcp open http
443/tcp open https
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20

So part of the original notice is valid, with the exceptions noted. I don't have any more v2.02.2 units to test as they have all now been flashed with v2.02.7, I have no more unmolested v2.02.7, and I am out of petty funds to purchase more :)

So, I will eat some crow on the original notice. To sum up, the admin page is most definitely available to the WAN if the firewall is disabled, regardless of the remote admin setting. And at best the potential for getting a unit off-the-shelf with this behavior is somewhat like an Easter egg hunt. I have received an even mix of responses positive and negative to the original notice, so others are reproducing this OTS.

Some thoughts...

It could be resonable that units which come v2.02.2 OTS then flash to v2.02.7 may not experience this behavior due to stored factory settings from original v2.02.2 system carried over to v2.02.7. That would explain the exception of the OTS behavior of the v2.02.7 units received in March.

Now I am also aware that other LinkSys items I have received have come with firmwares not yet available on the website -- most recent example, a WPS54GU2 which came with firmware 6032 while only 6031 was available on the website. It may be more reasonable that since the firmware v2.02.7 is dated March 17, my order for the WRT54G was placed on March 23, maybe a pre-release of the firmware? I cannot imagine that there would be such a diverse distribution of this product direct from LinkSys?

Re:How is this different from normal?

[mccalli]

Unlike Netgear, Linksys routers have no way to stop broadcasting the SSID

Mine does - I've got a "Wireless SSID Broadcast: Enable/Disable" option on the Wireless page. I'm running firmware 2.02.2

Cheers,
Ian

Re:Only 'moderately' critical ?

[VC]

Its not that bad... The thing is a linux box, with an admin password.

If you did the right thing and changed you admin password, then what you've really got is a linux box on a wan, with a hard to guess password.

Besides which, your running the Sweadish firmware anyway arn't you. :-)

Re:How is this different from normal?

[Ath]

You cannot disable the SSID broadcast on the Linksys WRT54G? Funny. When I change the radio button in the admin page to "Disable SSID Broadcast", it stops broadcasting the SSID.

Please make sure you either clarify such statements or don't make them when they are false (as in the current situation).

Re:The reason the risk is "moderate" is...

[Ath]

This problem is specific to one version of firmware.

I should correct this because some people with the 2.02.07 version that this guy claimed to be using are reporting they cannot reproduce the problem.

This could be basic user error. By the way, the remote admin function is disabled by default in the WRT54G firmware.

What gets me is that if you want to bitch about the WRT54G firmware, there are plenty of better reasons than this apparently bogus one. Only the hacked firmwares really make this hardware shine (and have all functions plus new ones work properly).

Re:Only 'moderately' critical ?

[southpolesammy]

Yes, this is only moderately critical because (a) the overwhelming majority of owners of these devices have them either directly or indirectly behind a NAT'ing cable modem or DSL connection, and (b) the "exploit" (if it can even be called that) is a known entity that any owner of one of these devices (myself included) should have realized the possibility of from day 1 and changed that password immediately, possibly before even connecting it to the cable modem.

This doesn't rate a critical or severe like the script kiddies' worms that keep coming out because short of installing a custom firmware version, there's not much that can be done with the device once owned other than to screw with its owner's networking.

Re:How is this different from normal?

[southpolesammy]

This is so not true. My WRT54G has had an enable/disable toggle for SSID broadcasting included in the firmware since the day I purchased it about 18 months ago. Perhaps you're referring to an old version of firmware, but most anything purchased from Linksys since the WAP boom began has had this option.

Re:How is this different from normal?

[mivok]

Strange, thats exactly opposite to my experience - my linksys WRT54G can turn off SSID brodcast (and has WPA support incidentally), whereas the netgear access point (WG502) that I replaced with the linksys was pathetic with respect to security, providing only WEP (with a broken promise of upgrade to WPA), and not allowing me to hide the SSID.

There are backdoored firmware available.

[acz]

Most of slashdot readers already know that there are a bunch of modified firmwares for the wrt54g such as this one. You should also be aware to realise that they are already backdoored/rootkit version (custom version of teso's adore of the wrt54g which will hide specific clients, processes, mac address and connections. It should also be noted that vulnerable linksys access point are trivial to detect using kismet (runs on linux, *bsd, zaurus, wrt54g) or kismac (runs on Mac OS X).

not not .... well sorta

[Merlin42]

Actually I was able to reproduce the 'problem' It is not mentioned in the article, but you can access the admin page from the WAN port if 'firewall protection' is disabled.

In hind sight this sort of makes sense ... although it is NOT at all obvious at first glance.

In any case I wouldn't consider this to be a HUGE problem since 'firewall protection' is on by default and 'Joe 6pack' is unlikely to turn it off since the general perception amoung nongeeks (at least in my experience) is that Firewalls are magical good things that block bad stuff (for varying definitions of bad).