CVE-2017-5521: Bypassing Authentication on NETGEAR Routers
Home routers are the first and sometimes last line of defense for a network. Despite this fact, many manufacturers of home routers fail to properly audit their devices for security issues before releasing them to the market. As security researchers, we are often disappointed to rediscover that this is not always the case, and that sometimes these vulnerabilities simply fall into our hands during our day-to-day lives.
Such is the story of the two NETGEAR vulnerabilities I want to share with you today:
It was a cold and rainy winter night, almost a year ago, when my lovely NETGEAR VEGN2610 modem/router lost connection to the Internet. I was tucked in bed, cozy and warm, there was no way I was going downstairs to reset the modem, "I will just reboot it through the web panel" I thought to myself. Unfortunately I couldn't remember the password and it was too late at night to check whether my roommates had it.
I considered my options:
- Get out of bed, go downstairs and freeze as I reboot the router.
- Be lazy, stay in bed, and since I am a security researcher, try to hack it :)
Needless to say, I chose the latter. "So… where do I start?" I thought to myself, "Well, it has a web interface and I need to bypass the authentication somehow, so the web server is a good start."
I started manually fuzzing the web server with different parameters, I tried "../.." classic directory traversal and such, and after about 1 minute of fuzzing, I tried "…" and I got this response:
Fig 1: unauth.cgi
"Hmm, what is that unauth.cgi thingy? and what does that id number mean?", I thought to myself.
Luckily for me the Internet connection had come back on its own, but I was now a man on a mission, so I started to look around to see if there were any known vulnerabilities for my VEGN2610. It turned out that there are none. :<
I started looking up what that "unauth.cgi" page could be, and I found 2 publicly disclosed exploits from 2014, for different models that manage to do unauthenticated password disclosure. Booyah! Exactly what I need. (link 1 & link 2)
Those two guys found out that the number we get from unauth.cgi can be used with passwordrecovered.cgi to retrieve the credentials.
I tested the method described in both, and voila - I have my password, now I can go to sleep happy and satisfied.
I woke up the next morning excited by the discovery, I thought to myself: "3 routers with same issue… Coincidence? I think not". Luckily, I had another, older NETGEAR router laying around; I tested it and bam! Exploited.
I started asking people I knew if they have NETGEAR equipment so I could test further to see the scope of the issue. In order to make life easier for non-technical people I wrote a python script called netgore, similar to wnroast, to test for this issue.
I am not a great programmer. I am aware of that and that is why I don't work as a full time programmer. As it turned out, I had an error in my code where it didn't correctly take the number from unauth.cgi and passed gibberish to passwordrecovered.cgi instead, but somehow it still managed to get the credentials!
"Wait… what is going on here?" I thought to myself. After few trials and errors trying to reproduce the issue, I found that the very first call to passwordrecovered.cgi will give out the credentials no matter what the parameter you send. This is totally new bug that I haven't seen anywhere else. When I tested both bugs on different NETGEAR models, I found that my second bug works on a much wider range of models.
A full description of both of these findings as well as the python script used for testing can be found here. The vulnerabilities have been assigned CVE-2017-5521 and TWSL2017-003.
The Responsible Disclosure Process
This is where the story of discovery ends and the story of disclosure begins. Following our Responsible Disclosure policy we sent both findings to NETGEAR in the beginning of April 2016.
In our initial contact, the first advisory had 18 models listed as vulnerable, although six of them didn't have the vulnerability in the latest firmware. Perhaps it was fixed as part of a different patch cycle. The second advisory included 25 models, all of which were vulnerable in their latest firmware version.
In June NETGEAR published a notice that provided a fix for a small subset of vulnerable routers and a workaround for the rest. They also made the commitment to working toward 100% coverage for all affected routers. The notice has been updated several time since then and currently contains 31 vulnerable models, 18 of which are patched now, and 2 models that they previously listed as vulnerable, but are now listed as not vulnerable. In fact, our tests show that one of the models listed as not vulnerable (DGN2200v4) is, in fact, vulnerable and this can easily be reproduced with the POC provided in our advisory.
Over the past nine months we attempted to contact NETGEAR multiple times for clarification and to allow them time to patch more models. Over that time we have found more vulnerable models that were not listed in the initial notice, although they were added later. We also discovered that the Lenovo R3220 router is powered by NETGEAR firmware and it was vulnerable as well.
Luckily NETGEAR did eventually get back to us right before we were set to disclose these vulnerabilities publicly. We were a little skeptical since our experience to date matched that of other third-party vulnerability researchers that have tried to responsibly disclose to NETGEAR only to be met with frustration.
Two changes helped sway our opinion. The first was that NETGEAR committed to pushing out firmware to the currently unpatched models on an aggressive timeline. The second change made us more confident that NETGEAR was not just serious about patching these vulnerabilities, but serious about changing how they handle third-party disclosure in general. That change was their commitment to Bugcrowd (https://bugcrowd.com/netgear), a popular third-party vendor that helps to vet research, provides oversight for the patching process and provides bug bounty rewards to help to motivate third-party researchers. We fully expect this move will not only smooth the relationship between third-party researchers and NETGEAR, but, in the end, will result in a more secure line of products and services.
Why Is This Vulnerability So Critical?
For starters, it affects a large number of models. We have found more than ten thousand vulnerable devices that are remotely accessible. The real number of affected devices is probably in the hundreds of thousands, if not over a million.
The vulnerability can be used by a remote attacker if remote administration is set to be Internet facing. By default this is not turned on. However, anyone with physical access to a network with a vulnerable router can exploit it locally. This would include public wifi spaces like cafés and libraries using vulnerable equipment.
As many people reuse their password, having the admin password of the router gives us an initial foothold on the network. We can see all the devices connected to the network and try to access them with that same admin password.
With malware such as the Mirai botnet being out there, it is also possible that some of the vulnerable routers could be infected and ultimately used as bots as well. If running a bot is not possible, the DNS can be easily changed to a rogue one, as described by Proofpoint, to further infect machines on the network.
We recommend that all users of NETGEAR equipment check the Knowledge Base Article for instructions to test if you are vulnerable and how to apply patched firmware if you are.