A few months back while evaluating NETGEAR’s ReadyNAS for IP360 coverage, I found that critical flaws allow complete root access from a single, unauthenticated HTTP request. See the advisory here.
ReadyNAS is a network attached storage system (NAS) designed for business and home use. ReadyNAS is simple enough for home use while offering important enterprise support for user based access controls and a wide range of protocols.
(ReadyNAS supports side-by-side use of UNIX, Linux, Windows, and Macintosh file sharing protocols as well as web browser access.)
Based on analysis of SHODAN data, there are over 10,000 ReadyNAS with HTTP or HTTPS directly accessible from the public Internet.
Although an update was released 3 months ago, I have collected data indicating that the bulk of ReadyNAS deployments have not yet installed the update and it is easy to see why. Apart from the security fix, 4.2.24 and 4.1.12 are minor updates released on the heels of 4.2.23 which introduced several new features and important bug fixes.
Although Tripwire IP360 already reports on risk in ReadyNAS, prior to our advisory, very little information on ReadyNAS vulnerability has been made available to the general public. Without knowing the critical nature of the update, there is little incentive for customers to apply the upgrade. (I should mention that the update process causes several minutes of down time while it is rebooting the NAS.)
The most serious flaw I have uncovered in ReadyNAS exists in the Frontview HTTPS web management interface.
The vulnerability falls into the category of command injection due to a failure to sanitize user-controlled input. This instance is particularly severe because it can be triggered without authentication.
The consequence is that an unauthenticated HTTP request can inject arbitrary Perl code to run on the server. Naturally, this includes the ability to execute commands on the ReadyNAS embedded Linux in the context of the Apache web server.
Frontview is the primary user interface for ReadyNAS and as such it cannot be disabled or blocked through any configuration options, so there were no obvious mitigation strategies. The impact is partly mitigated by the fact that Apache does not run as root, however a poorly configured file system ensures that elevation of privilege is possible.
An attacker with local access to a network can use the NETGEAR provided RAIDar utility to identify all ReadyNAS on the network and then gain root access to vulnerable units in a matter of seconds.
This multicast advertising system may be helpful for setting up the device but it also presents additional risk. (This topic will be discussed further during an upcoming Google Hangout session on Tuesday October 29th at 1PM Eastern / 10AM Pacific.)
The proof-of-concept exploit code I authored can use this information to exploit vulnerable ReadyNAS with crafted HTTP requests. By using the proper payload I have demonstrated that the ReadyNAS will launch a reverse TCP root shell. To state it in less technical terms, I found that opening a web page with a very purposefully chosen name will cause the ReadyNAS to offer full access to a computer specified by the attacker.
Although the attack surface is reduced when the ReadyNAS web interface is not exposed to the Internet, there is still the potential to exploit this vulnerability through crafted web pages or even email messages. (All it takes is a image tag to trigger the bug.) Using a reverse TCP shell makes it such that a breached system can be controlled by an attacker located beyond the network perimeter.
The command injection vulnerability was tracked as CVE-2013-2751 and CVE-2013-2752 was assigned for the request forgery aspect. These issues along with numerous others were responsibly disclosed to NETGEAR starting in November 2012.
In July, NETGEAR released RAIDiator firmware 4.2.24 and 4.1.12 which I was advised ‘closes many of the issues’ I reported. The only mention of security concerns were in the firmware release notes. There’s just one line: ‘Updated Frontview to fix security issues.’ Without knowledge of the specific vulnerabilities, customers feel no sense of urgency about installing the update.
This is a serious oversight. If you are running ReadyNAS and you have not already updated, it is imperative that you do so ASAP, especially if your ReadyNAS web interface is one of the thousands that are directly accessible from the public Internet.
As of this writing, Shodan seems to indicate that there are more than 10,000 public IP addresses that match my ReadyNAS fingerprint. Based on a sample size of 2,000 hosts, approximately 73% of the Internet exposed ReadyNAS are running RAIDiator firmware prior to 4.2.24.
Triwire Security Advisory 2013-001
CVE-2013-2751 Affected Systems
Source: Shodan (2,000 ReadyNAS device sample)
Although Tripwire IP360 customers have already been alerted to this vulnerability starting with ASPL 522, VERT’s desire to help all NETGEAR customers is what ultimately prompted the release of Tripwire Security Advisory 2013-001.
The goal of this blog post is to inform end-users of the critical flaws in ReadyNAS RAIDiator firmware 4.2.x prior to 4.2.24 and 4.1.x prior to 4.1.12. As a supplement to the security advisory Tripwire will also be hosting a Google Hangout on Tuesday October 29th at PM Eastern / 10AM Pacific that will allow me to discuss these ReadyNAS vulnerabilities in detail, demonstrate my exploit code, and provide suggestions on how to harden embedded Linux platforms.
- Vulnerability: Who is Watching Your IP Camera?
- Vulnerabilities: It’s Time to Review Your ReviewBoard
- Defcon Sneak Peek: How Risky is Google Apps for Your Business?
- Why Cross-Site Scripting Always Matters
P.S. Have you met John Powers, supernatural CISO?
Title image courtesy of ShutterStock