Live data from Hacker News

Netgear 0-day vulnerability analysis and exploit

blog.grimm-co.com

11–20 of 102 posts

Re: Netgear 0-day vulnerability analysis and exploit

#11
I noticed there's a gap in some of the affected lists. (Mainly the MediaTek/Ralink mipsel hardware) They don't appear to have the same httpd binary talked about here. (Instead they have a mini_httpd?)

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.

Re: Netgear 0-day vulnerability analysis and exploit

#12
post #6

The worst part is this isn't even just going to affect folks that would never think to update their router firmware. The firmware they do push out is frequently a massive downgrade. 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 f…

Another brand i vouch for is AVM, their routers are all over Germany and they're reliable workhorses for years...

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...

Re: Netgear 0-day vulnerability analysis and exploit

#13
post #9
post #2

It's another reason once you bought a router to reflash it with alternative firmwares as OpenWRT or DD-WRT

The last time I looked into OpenWRT/DD-WRT (years ago), it seemed disadvantageous to switch to them because they would be slower than stock firmware due to missing some kind of hardware support. Is this still the case these days? 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.

It's faster in my scenario. YMMMV.

Re: Netgear 0-day vulnerability analysis and exploit

#15
https://github.com/grimm-co/NotQuite0DayFriday/blob/master/2...

>* 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?

Re: Netgear 0-day vulnerability analysis and exploit

#16
post #9
post #2

It's another reason once you bought a router to reflash it with alternative firmwares as OpenWRT or DD-WRT

The last time I looked into OpenWRT/DD-WRT (years ago), it seemed disadvantageous to switch to them because they would be slower than stock firmware due to missing some kind of hardware support. Is this still the case these days? 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.

Not in the specific models I looked at.

I personally use a Linksys WRT3200ACM.

https://openwrt.org/toh/linksys/linksys_wrt3200acm

Re: Netgear 0-day vulnerability analysis and exploit

#17

https://github.com/grimm-co/NotQuite0DayFriday/blob/master/2... >* 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?

There is a much longer list within the comments of exploit.py

It appears they may have scraped the Netgear site and run all the images through binwalk + objdump to make the list.

Re: Netgear 0-day vulnerability analysis and exploit

#19
post #14

Why is this a big deal since you can exploit the vulnerability only when you are connected to the local network? (I've seen some of these exploits used to replace the installed firmware with openwrt)

In general, this is not a safe assumption to make -- for example, due to DNS Rebinding attacks.

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.

Post reply on HN