Netgear 0-day vulnerability analysis and exploit
blog.grimm-co.com
blog.grimm-co.com
About a year ago, I tried to update the firmware on my Netgear router. It was the exact model from the article, the R7000. I assumed "new update" for router firmware would involve some critical security updates, and maybe some stability fixes, but it basically rendered the router unusable. It would crash every few hours with normal usage. I googled around and turns out it was a known issue, the only recommended fix was "roll back to version x.x.x (2 versions prior). I found this fix months after it had been posted, and there had still been no new patch released to fix the issue.
When my relatives call me to fix their wifi, I now have to think twice about updating the firmware. These days I recommend the google wifi mesh router(s), because they just involve the least maintenance effort. They have less fine-tune controls and the wifi speed is slightly slower when you start approaching gigabit speeds (vs other high-end consumer routers), but it's definitely worth the trade off for me. Plus, anyone calling me to help with their wifi won't notice either of those things :)
Just make sure you use the 2600AC as the primary router, the 2200s can technically function in that role but are pretty under-powered.
This is a contradiction. The whole point of DFS is "if you detect radar on this frequency you must stop transmitting on it". This is typically followed by a change of channel to avoid an outage of the Wi-Fi, hence "dynamic frequency selection".
As far as I can tell, there isn’t even a way to perform auto DFS selection on my current router.
Maybe, just maybe, someone should start a list with vendors that put out shitty software on their devices, never deliver firmware updates and have stupid exploits...
You might as well just list every vendor, the exceptions are rare and don't always last.
I don't disagree, but perhaps it would be better to list the vendors that push bad software and whose hardware doesn't let you run a better firmware. After all, if the hardware is decent and can run OpenWRT or such, who cares how bad the stock firmware is?
It started with the lack of ability to have an open guest wifi... Like - it's for my guests, I want anyone to be able to connect, and I don't want to be faffing with passwords or guests having to ask me... I have to name my network "My House - Password Is password"
Then every month it seemed to do some kind of update and disconnect wifi devices... Sure - it's only for 30 seconds, but a disconnection is a disconnection. Thats going to boot you off whatever game you are playing...
And now I've got the trouble that as you have a bunch of mesh points, you can't walk between them without glitches in a video call... Like seriously - I should be able to start facetime and walk round my house without random freezes for 5 seconds while it reconnects to a different mesh point.
Google Wifi has been out for years now, and not a single one of these bugs is any better than it was at launch. Not really acceptable for a $400 router setup!
Almost every router supports some form of remote management (or just put TeamViewer on their machine). Most also support dynamic DNS so you can set up a ping check for the "its down" notification.
"Google Wifi and Nest Wifi devices do not track the websites you visit or collect the content of any traffic on your network."
The name-calling is really not necessary. Why not make your point on its own merits?
The doc[0] you're quoting continues to list a bunch of things they do collect, including some with no opt-out. Way to cherry-pick.
Even the part you quoted does not exclude traffic metadata.
Before I bought the Google mesh wifi, I already had android, chrome, project Fi, and Google's DNS (router level) at various levels of my request stack. That's not even counting search, gmail, and calendar. If Google are playing shady games with my network traffic, whatever marginal gain they get from having software on my router is negligible. Especially compared to the awful PR backlash they'd get once somebody hooks some monitoring gear up to their hardware and exposes it.
I agree. I gave that example because I personally use it, but would prefer to move to a self-hosted or inexpensive paid solution. I've always assumed the free version has sufficient business value as a lead-generator for the enterprise version, but there's no reason to assume they don't also monetize usage data.
> I already had android, chrome, project Fi, and Google's DNS ... whatever marginal gain they get from having software on my router is negligible.
That's a totally fair way of looking at it, and I'd probably use Google Wifi with little hesitation if I were you. But this isn't the case for everyone. IMHO tech folks need to be mindful of privacy implications when recommending tech to non-tech folks, because we have the benefit of understanding those implications. FWIW, my immediate family would be displeased if I installed a Google router for them and they later figured out Google's conflict of interest for themselves.
That said, I agree TeamViewer in a position to collect & monetize my usage by nature of being cloud-dependent & closed-source. I'd rather use an open-source self-hosted option. Haven't found a good one yet, but that doesn't mean we should ignore privacy hazards where they can be easily avoided.
I even run nginx as a name-based proxy on mine, with load balancing! Works like a champ.
I worked there a bit over 10 years ago, so things may have changed, but honestly I wouldn't expect them to change all that much. For that kind of hardware (SOHO stuff), Netgear didn't have any software developers in-house. It was all outsourced to dev shops in Asia. The software was usually whatever generic thing the dev house had built, with customization for branding and enabling/disabling features Netgear wanted or didn't want. Occasionally they would pay to add features that didn't exist.
Netgear usually didn't get source code, and would only get changelogs for new releases (which weren't all that detailed). There were often many regressions, and all bug testing and feature verification was black-box. When something was wrong, it was often a fight to get the dev house to prioritize it, especially if they didn't think it was a critical bug (declaring a bug a shipping showstopper was usually effective, but you can't cry wolf all the time, and that only works for pre-release products, not updates).
I imagine things are better now; at the very least I expect these developers to have at least a little more awareness of common security issues and how to avoid them (definitely was not the case in the 00s), but I assume it's still a mixed bag. On the plus side, most of the current-gen hardware is beefy enough to run Linux, which a lot more developers are familiar with (IIRC a lot of the stuff back then was running vxWorks), which hopefully makes it easier to hire better developers.
If you want high-quality software on your networking gear, go with a company that you know is actually a software company, and not an outsourced hw/sw company. Products that are based on OpenWRT or Tomato or something like that are probably safer, assuming they haven't broken it with their customizations... but don't expect updates to new major releases. Having said that, I still buy Netgear switches and other stuff that's internal to my network and are generally relatively "dumb". They're usually pretty reliable and reasonably priced.
D-Link isn't any better, many of their firmwares to fix KRACK were in Beta for 4 years and many are still in Beta.
What will it take for me to be able to purchase a microkernel driven router/access-point with audited drivers (or Rust based)? I would settle for mediocre performance (ie no gigabit) if I could have some strong security guarantees.
Can I setup Redox or seL4 as home network hardware at this point? Or would the pain threshold still be quite high?
I don't have the gateway my ISP gave me on my LAN for this reason. I do have to laugh a little bit about people who use a VPN to hide requests (DNS? Because most of the web is HTTPS, now) from their ISP when their ISP has a device on their network.
Also most of these vulnerabilities (as the article points out) are in the web server. If the web server isn't exposed,it isn't of much practical security concern.
I've also run DD-WRT for years with excellent results. Per the usual benefits of open source and active maintainers, it is generally going to (a) have the trivial stuff already addressed (b) keep up to a reasonable extent with security patches.
I would have said the same some time ago, working in networking in a world largely made up of Cisco.
But then a few major vulnerabilities later and blog posts disclosing vulnerabilities that they refused to acknowledge when contacted. Then I'm not sure paying for enterprise equipment is a solution anymore.
- Put a wireless card in the router, but a lot of them are crap (limited features, not dual band, require closed firmware, not compatible with *BSD...)
- Buy an access point appliance, but most of them are as secure as the Netgear devices of the fine article.
1. The AP isn't directly exposed to inbound traffic from the internet.
2. You can put the AP's management interface on a VLAN without internet access and/or use firewall rules to the same effect.
I'm way less worried about the security posture of my AP than my internet-facing router.
EDIT: It sounds like the situation for my router (R7000) is quite the opposite now, apparently being almost twice as fast due to new hardware acceleration features.
I personally use a Linksys WRT3200ACM.
"DD-WRT has a license agreement and NDA in place with Broadcom that allow usage of better, proprietary, closed source wireless drivers (binary blobs) which they are not allowed to redistribute freely."
They do appear however to be still very vulnerable to CVE-2020-8597 (no PIE or stack cookies, probably RWX stack) and for the one device I took a look at (R6700v2), the firmware image hasn't been updated since last September.
Oh well.
Can anyone recommend an awesome wireless router that works great off the shelf? I don't want to have to learn how to flash it with DD-WRT.
I visited them a few months later and noticed it, so I asked about it.
They had kind of forgotten about it. There were zero problems setting it up and zero problems since. They said they thought it was kind of pricey.
If I remember right, it was $50 more than the cheapest (but terrible) one with similar specs. It was $100 less than an expensive, terrible and comparable one.
I can’t imagine a more favorable review of consumer networking gear. :-)
Also, I have had zero issues with the Ubiquiti access point I use at home. I have a pcengines apu2 OpenBSD router, so I can’t say much about their routers.
The house they just moved into had a strange audio LAN wired through the house when it was built. The audio LAN had a couple CAT-5E ports for "expansion" (presumably?) on each floor just about perfectly located for WiFi AP backhaul. So I worked with my parents on a plan to try three of Amplifi's routers rather than one AP and two "Satellites".
This seemed to work alright. The Amplifi phone app wasn't great about setting up a multi-AP mesh of that sort just yet (as opposed to the focused use case of one router/AP and several "satellites") and didn't always have the best experience (in navigation/details), but other than UX complaints, the system just works as expected.
However, my parents then discovered that there were "hidden" components also wired to the Audio LAN somewhere between the primary Audio LAN router and the "expansion ports", which meant that some of the system's speakers stopped operating. (It would have been great to have a wiring diagram of the whole LAN. We did a lot of trial and error discovery on this.)
So my parents decided to "turn off" the backhaul by reconnecting it to the Audio LAN. There was angsty confusion that they "broke" the WiFi because they ignored/forgot my explicit instructions to disconnect the router's WAN cables on the house ports that were now again Audio LAN ports. As I had expected, once disconnected from the confusing (to people and devices alike) Audio LAN, the Amplifi Routers straightened themselves out and switched to a more traditional bridged mode ("wireless backhaul") as if they were mere "satellites".
According to the math I did, my parents paid a lot less for that experiment with all Amplifi routers than if they'd tried it with "full" routers of any of the other brands we'd comparison shopped (and none of them seemed to offer an ala carte buying experience similar to Amplifi's section of Amazon), though obviously more than if they'd bought only one router and two satellites of any of the other brands in the first place. The extra LAN port on the Amplifi router is still critical to them on one of the floors (a home office VOIP system that "requires" a wired connection) and they couldn't easily swap at least one of the routers for a Satellite anyway.
Other than the crazy backhaul experiment confusion, my parents haven't had any problems. I don't think we could have ran that experiment with any of the other brands. My parents seem happy with the purchase and the quality of their WiFi on all three floors, which was the important thing for them, and I get the feeling they were happy with the price despite "over-paying" a tad due to the experiment.
Specifically I would recommend the TP-Link EAP line as a wireless AP (the $50 EAP225v3 is very good). Extremely simple to configure. Routers that perform well require configuration unfortunately, especially economical ones like the Microtik ($50). It lacks out of the box settings for port forwarding and hairpin NAT, though it has the simplest secure VPN setup I have ever seen. The only router that competes with its performance (ie can route gigabit Internet at full speed) with easy config is the Cisco RV340, which costs $220 and is 3 years old.
Apple discontinued its wireless routers because they were bad. Apple routers run an ancient and naturally no longer patched version of NetBSD. They have terrible wireless performance on the worst Broadcom chipset with awful quirks. They mix with non Broadcom wireless devices extremely poorly (typically Atheros is the high performance pick). They are extremely slow, not at all suitable for gigabit Internet. If you update the port forwarding they must restart, and take down your internet. However, they are basically purpose built for correct macOS and iPhone multi-AP WiFi hand-off. There are things they do that not even enterprise hardware does right or may ever do right, simply because Apple does not document the magic that makes it possible. Or because Apple uses such bad chipsets with so many quirks, that only those quirks all working together do things go right. If I were you, I’d eBay away your 7 year old Airport Express to some greater fool, and use that surprisingly large amount of money to buy good stuff.
Anyway, most people shove their wireless AP into a bookshelf, taking at least 30% of their internet bill worth of performance and lighting it on fire. People use mesh networking wireless, like the Eero, something so abjectly bad it boggles the mind, because they’d rather spend $300 once to only use 50% of their internet’s monthly value than $10 once on Ethernet cable to get 100% of it. Sometimes they buy Ubiquiti hardware, which is ancient and overpriced at this point, and wind up paying for some internet configuration license that makes no sense. I really pity the people paying a monthly fee for mesh wireless configuration. This stuff is extremely marketing driven, it is in reality just the same exact commodities (two possible wireless chipsets and Linux) remixed into whatever crap Google thinks will convince people to let them gather home networking telemetry.
But configuring a Microtik is not easy. So there you go.
Also, why do you dislike Eero? Someone else on this thread recommended them, and they do have many glowing reviews.
See the installed system as "example installation to demonstrate functioning". Like HP with the bundled Crapware on PCs.
Just install OpenWrt as soon as you did a basic function test. And only buy hardware you know to be compatible.
Which rules out OpenWrt on some of the lower-spec pieces if you have a faster WAN connection (Ie. 1gbit), as I don't believe they have support for these on many platforms. (MT7621 is referenced as supported, and Qualcomm's "SFE" being supported in community builds)
it's ruled out in any case as of now, because the current releases require (or at least strongly recommend) 64 MB of RAM, which surprisingly in 2020 is a problem in the networking world (for the cheapest -under 70$- devices)
Wireless is still lagging as the IPQ8064 has two NSS packet processing cores which, amongst other things, also accelerate crypto, including WPA.
I've got an R7800 running router duties on OpenWRT and then a Netgear Orbi RBK50 set running in AP mode which works well for my needs.
There IS a community effort to port the NSS acceleration (which accelerates qdisc and therefore traffic shaping with SQM) from the QSDK sources, but it's slow going.
The IPQ40xx devices tend to be well supported, though. Be sure to refer to the hardware list to see if a device is really supported before buying it.
In SOHO devices like the R7000, the web server must parse user input
from the network and run complex CGI functions that use that input.
Furthermore, the web server is written in C and has had very little testing,
and thus it is often vulnerable to trivial memory corruption bugs.
Let's not going to that debate. It's a good start to improve security postures, regardless how you spin it.
But more importantly, my point is why are they doing CGI at all?
BTW quality of embedded webappa is mostly sucks.
I don't think they are low power devices. My bet would be they're relatively normal hardware running a light linux. It takes quite a bit of power to route gigabit ethernet or ac wifi.
Sometimes, certainly:) However...
> I don't think they are low power devices. My bet would be they're relatively normal hardware running a light linux. It takes quite a bit of power to route gigabit ethernet or ac wifi.
It doesn't take much compute to handle high-end eth/wifi if you offload it to hardware, and even doing it on-CPU (which I don't think is actually common) probably wouldn't impact RAM/storage, so you could still manage with a stronger CPU and comically tiny memory.
It offered an optional "cloud" account system for remote administration (such as giving guest access when you are away or rebooting your mesh from your phone when your guest complains about the network not working, and so forth), but did not require it.
(a) 99%+ of people buying these things do not know or care about security, aside from someone stealing their WiFi bandwidth (b) the manufacturer does not care because of (a).
As follows, all they care about (WRT to the web server) is that they are easy enough for non-technical people to setup such that they don't end up on a tech support call or returning the device for a refund. That is it.
If you are the 1% that cares about security on your home network, it is far less stressful to simply conclude these products are not for you and move on with your life. You should be looking at enterprise hardware, open source router firmware, or rolling your own.
In any case, what surprises me is that over time the router manufacturers haven't simply built up a single, relatively patched-up, web server implementation that they re-use. Even without aligned incentives, you would think over years and years of development they'd have something at least as good as what you can clone out from from github for free.
The article also mentions that the exploit is working remotely:
> As the vulnerability occurs before the Cross-Site Request Forgery (CSRF) token is checked, this exploit can also be served via a CSRF attack. If a user with a vulnerable router browses to a malicious website, that website could exploit the user’s router. The developed exploit demonstrates this ability by serving an html page which sends an AJAX request containing the exploit to the target device.
Also, if you're replacing the firmware, the new firmware can create an outgoing root shell to a destination of your choice. There's no internal limitation here.
>* R6300v2 version 1.0.3.6CH, 1.0.3.8, and 1.0.4.32
>* R6400 version 1.0.1.20, 1.0.1.36, and 1.0.1.44
>* R7000 versions 9.88, 9.64, 9.60, 9.42, 9.34, 9.18, 9.14, 9.12, 9.10, 9.6, and 8.34
Strange, my Netgear R6700 is not on the list. Does that mean it's unaffected, or they simply didn't have that model on hand to test against?
It appears they may have scraped the Netgear site and run all the images through binwalk + objdump to make the list.
Still prevents the most casual attacks; obscurity is sorta technically better than nothing. (Or worse, of course, if it gives the incorrect appearance of actual security...)
I also own a UDM Pro, and this is an understatement.
Technically someone somewhere make a electronic plate and sold some elements on it.
But difference is who is wrote a software on top.
Who wrote a software (and designed and sold the whole thing) is some difference, much better than nothing, but the "electronic plate" can still be filled with backdoors and other gimmicks...