Netgear Vulnerability - Disclosure Notification

Today the members of the Bugtraq mailing list received a notification about an email in a Netgear DG623 router. The text of this email reads as follows:

Product Name: Netgear DG632 Router
Vendor: http://www.netgear.com
Date: 15 June, 2009
Author: tom@tomneaves.co.uk
Original URL: http://www.tomneaves.co.uk/Netgear_DG632_Remote_DoS.txt
Discovered: 18 November, 2006
Disclosed: 15 June, 2009

I. DESCRIPTION
The Netgear DG632 router has a web interface which runs on port 80. This allows an admin to login and administer the device's settings. However, a Denial of Service (DoS) vulnerability exists that causes the web interface
to crash and stop responding to further requests.

II. DETAILS
Within the "/cgi-bin/" directory of the administrative web interface exists a file called "firmwarecfg". This file is used for firmware upgrades. A HTTP POST request for this file causes the web server to hang. The web server will stop responding to requests and the administrative interface will become inaccessible until the router is physically restarted.

While the router will still continue to function at the network level, i.e. it will still respond to ICMP echo requests and issue leases via DHCP, an administrator will no longer be able to interact with the administrative web interface.

This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router.

Affected Versions: Firmware V3.4.0_ap (others unknown)

III. VENDOR RESPONSE
12 June, 2009 - Contacted vendor.
15 June, 2009 - Vendor responded. Stated the DG632 is an end of life product and is no longer supported in a production and development sense, as such, there will be no further firmware releases to resolve this issue.

IV. CREDIT
Discovered by Tom Neaves

This posting elicits so may comments that I don't really know where to start so I've tried to break things down a bit to make the discussion easier to follow.

Vulnerability Severity
First I'd like to address the perceived severity of this vulnerability. It is a denial of service attack against a platform that is most commonly used in the home or SOHO environments. This combination means that most mid sized or larger organizations will likely pay little attention to it. This is a mistake for a few reasons. First, and speaking to small, medium and large organizaiton, you may not used SOHO devices but your users do and they, in turn, connect to your network. This may be via VPN (through the SOHO router), directly using various protocols, or simply by bringing ther laptop from their vulnerable home environment to your "protected" work environment. In short, problems with these devices affect you directly.

Now you may say that this is "just" a DoS problem and isn't going to have an effect. At a minimum, it can effect the productivity of your users. Let's consider an extremely situation - you have a user who is working on a proposal that needs to be turned in on a specific date and time. If their router gets nailed it may delay the proposal causing you to lose the business. From a more day-to-day perspective, many organizations allow teleworking. If they cannot connect to the business network, their productivity will be impacted costing your organization money. If your corporate network, or even a single switch on that network, went down, you'd ensure the problem was addressed ASAP. From the perspective of a teleworker, a DoS attack against their SOHO router are exactly the same as the loss of a corporate switch.

Finally, DoS attacks have a way of turning into other types of attacks - possibly allowing the attacker to gain control over the SOHO router. if that happens, it results in a whole new set of problems for business with users who rely on these systems.

Vulnerability Disclosure
OK, now that we've covered the fact that we should care about this kind of problem, I want to talk a bit about vulnerability disclosure. In this case, that problem was identified in November of 2006 and was posted on Bugtraq on June 15th of 2009 - 2 years and 7 months later. This means that people have been using vulnerable equipment for all that time without knowing it or having any ability to do something about it. That, to me, is a problem. Even now, becuse the product is "end of life" there is not patch available but purchasing a new box - again, a scary situation.

I don't want to come across as an alarmist. The issues affecting this particular device are unlikely to represent a significant security risk to any organization but this problem of vulnerability disclosure is multiplied throughout the industry on virtually every singel technology in existence making it a situation that is relevant to everyone. Now comes the point where I outline a bunch of questions with few answers:

Security researches spend time "hacking" technology. By hacking, I'm referring to the term in the original context, not the media driven "attacker" definition. These researches hack technology for a variety of reasons. It may be part of an authorized penetration test or they may work for a company with a vested interest in vulnerability identification (e.g. a security product vendor, etc.). Often, they just do it for fun. In any case, they discover a vulnerability. This leads them to the first question. Do they notify the vendor, disclose the problem to the public, sell it to the highest bidder......?

If they notify the vendor, they may get a positive response. They may also get brushed off and ignored. They may get critisized or, in rare situations, they may be the target of legal actions or "illegal reverse engineering" or similar "crime". In any of these cases, vendor notification resulting in positive, short term actions by the vendor are not the majority leaving the users of the technoloy vulnerable and ignorant.

If they decide to publish the problem on the Internet making it available to the public the will likely be contacted by the vendor, and/or the vendor's lawyers. The public may be able to, if they are made aware of the problem, implement some controls to reduce their risk level but the security researcher is also putting their discovery in the hands of the bad guys also. In effect, they take off the white hat and put on the grey one.

There are also organizaitons out there who will buy vulnerabilities. This puts some money in the pockets of the reseachers but comes really close to "black hat" work.

This is a bit of a sticky situation and gets more so when you look at the concept of pay. Many vulnerability researchers are either independent consultants or do this type of work as a hobby in addition to their normal 9-to-5. They spend countless hours performing quality analysis for some vendor for free. When they do identify something and turn it in to the vendor, the vendor in turn has the opportunity to make their product better. Shouldn't the researches receive some compensation for the QA work that should have been done by the vendor in the first place? Like I said, this is a sticky subject.

Attack Vectors
The last thing I want to talk about is the way this vulnerability can be attacked. According to the article - "This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router." This seems to imply that if "Remote Management" has not been enabled, this attack is not exploitable from the Internet. While I haven't tested it, I would suspect that Cross-site scripting (XSS) and Cross-site request forgery (CSRF) attacks may also be used to attack the system even of the direct external access is not possible.