By: Craig Young
Wireless routers designed for consumers often do not employ proper security practices. This topic was extensively covered in VERT’s 2014 report, “SOHO Wireless Router (In)security”. Our research revealed that 74% of the 50 top selling consumer routers on Amazon shipped with security vulnerabilities, including 20 different models where the latest firmware from the vendor was exploitable. Many people I have discussed this research with have expressed the opinion that, for one reason or another, this problem is more or less confined to the consumer sector. My suspicious was that feature wars and low profit margins could be contributing to the epidemic of insecure routers. In an attempt to determine whether this issue was limited to the consumer market, I decided it would be necessary to obtain and evaluate a wireless router designed for enterprise networks.
Naturally the first step of this research project was to pick a target. Whereas there are many brands of consumer routers and they are cheap enough that I could reasonably buy a variety of devices, enterprise equipment is not cheap, meaning that I would be limited to testing a single product family. I started by conducting some war walking with the Android Wi-Fi Analyzer app to get an idea of what brands are being installed in real-world environments. From this I found that Ruckus and Cisco seem to have a strong hold on the market. A report from Dell’Oro Group stated that Ruckus accounted for 42% of the units shipped in 4Q14 and so, with that, I decided to proceed with Ruckus.
In order to keep my comparison meaningful, I decided it would be best to limit the scope of my testing to the HTTP interface and use the same methodology I used for finding vulnerabilities in the consumer routers. This was easy because I had already established an effective testing process over the course of a few router security assessments. At a high-level, I use a combination of manual fuzz testing and partially automated querying based on information extracted from firmware and shell access where available. Earlier this year, I taught about these techniques at length during an AusCERT tutorial session titled ‘Brainwashing Embedded Systems’. I am also happy to report that I will again be sharing this knowledge in a DEF CON 24 workshop as well as a SecTor 2016 training session.
Before investing in an expensive high-end Ruckus model, I decided to start my tests with a second-hand Ruckus ZoneFlex running the latest available firmware as of 10/27/15. Within a few minutes of setting up the device, I found a command injection which is exploitable through a forged request due to a general lack of CSRF tokens. As with many of the consumer routers I had tested, the ZoneFlex offers administrators an option to perform diagnostics including a simple ping test, with apparently no input sanitization. In every case where I’ve found this flaw on a consumer router, it has been pretty devastating. Although the light-weight consumer embedded devices commonly have all processes running as uid 0 (root), I thought certainly an enterprise product would use privilege separation. The ping operation requires no special privilege so it should be running as a user with limited access. I tested this theory by crafting a ping parameter to spawn a telnet daemon and to my surprise it worked and I was granted a root shell. This was more than enough confirmation to me that it would be worth the investment in a current model.
After some Google searches, I found that I was not the only person aware of this blatant command injection. My ZoneFlex model was EOL with rather old firmware so naturally I expected that this low-hanging fruit would have been fixed in the new product. My research picked up again 12/3/2015 when I set up a Ruckus H500 access point with the latest firmware (188.8.131.52.432); I was shocked to find that the ping injection still worked! After obtaining a shell on this fully patched access point, I proceeded by creating a simple list of files contained in the web server’s document root. This is a trivial process possible from either the shell access or through firmware extraction and can be supplemented by locating possible URIs embedded within the server’s binaries. In this particular case, I limited myself just to the files visible in the firmware update. I then fed this list into a script I have for crawling an HTTP server and recording which files are accessible without authentication. As was commonly the case with consumer devices, this rather simple process exposed a few flaws:
Authentication Bypass: All requests containing a particular string received ‘200 OK’ responses. By creatively adding this string to other requests, I was able to get response data intended only for authenticated queries. This is a behavior I have observed in routers from NETGEAR, TrendNET, and Asus.
Denial of Service: There is a particular page accessible over HTTP without authentication that, when requested over SSL, causes the management interface to become unavailable. This is a serious issue as the product relies on HTTP when used as a hot spot.
Information Disclosure: The device’s serial number is exposed by the HTTP server. It is unclear whether this has any direct security impact but it may be useful to an attacker as part of a social engineering ploy. I have also observed other products where the serial number is used as a means to prove ownership of a device.
In addition to these three flaws, I also found that authenticated requests for a certain page would trigger excessive memory consumption causing the HTTP server to reload as well as possible disruption to other services. This vector is exploitable via GET requests and therefore lends itself to CSRF attacks through malicious image tags in HTML documents or emails. Over the next few weeks, I also confirmed that these vulnerabilities were present and exploitable within other Ruckus models including the Zone Director which allows centralized management of Ruckus APs.
These were not the only vulnerabilities in the Ruckus access point but at this point I reached out to the vendor. Unlike with some vendors where it takes guess work to figure out an appropriate security contact, Ruckus has a page listing a PGP key and email address for reporting vulnerabilities. While this is normally a good sign of a responsive organization, repeated attempts to email them my report resulted in bounces. In early January 2016, about a month after I first reached out to Ruckus, I emailed several other posted addresses stating my problem reaching the security contact. A webmaster contact responded letting me know that he would get the account setup but after resending the report and asking for receipt confirmation, I heard nothing. Later that month, I contacted CERT who assigned VU#974320 and confirmed that they could not get a response from Ruckus. To date Ruckus has not responded to Tripwire or CERT regarding these vulnerabilities.
The lesson from this research project seems to be that “enterprise-class” hardware does not necessarily mean enterprise quality in terms of security. My experience auditing Ruckus equipment is very similar to some of the experiences I’ve had auditing the wireless routers you might find in a local computer store. In fact, the authentication bypass and command injection are essentially the same as problems I have found on SOHO devices in the $100-$200 range. The biggest difference here is that my report to Ruckus appears to have been completely ignored. Organizations using Ruckus devices may be at risk for compromise, particularly when the access points are used to provide customers with Wi-Fi access. An intruder to one of these systems could potentially become man-in-the-middle to all other users of the wireless network allowing a wide range of exploitation opportunities. My research was performed against devices with factory default settings and not those configured to be hot spot providers. Without guidance from Ruckus, it is unclear what configurations or operating modes may mitigate the risks.
A full timeline of this disclosure process is as follows:
10/27/2015 – Initial Discovery of Command Injection on EOL ZoneFlex model
12/03/2015 – New Ruckus hardware received and multiple vulnerabilities discovered on current/supported product
12/07/2015 – Vulnerability report is written and sent (encrypted via PGP) to HYPERLINK “mailto:email@example.com” firstname.lastname@example.org
12/07/2015 – Undeliverable email report received
12/08/2015 – Second attempt to email published security contact HYPERLINK “mailto:email@example.com” firstname.lastname@example.org
12/08/2015 – Second undeliverable email report
01/05/2016 – Encrypted vulnerability report is sent to HYPERLINK “mailto:email@example.com” firstname.lastname@example.org a third time
01/05/2016 – Third undeliverable report forwarded to webmaster@, publicrelations@, and HYPERLINK “mailto:email@example.com” firstname.lastname@example.org
01/05/2016 – Vendor webmaster responds that they will be “getting to the bottom of this”
01/05/2016 – Vendor webmaster responds that the email address should work now
01/05/2016 – Resend of encrypted report to HYPERLINK “mailto:email@example.com” firstname.lastname@example.org asking for receipt confirmation
01/26/2016 – Report submitted to US-CERT and assigned tracking ID VU#974320
01/28/2016 – Joel Land of CERT/CC has forwarded disclosures to vendor and requests a copy of Tripwire’s disclosure policy
01/29/2016 – Tripwire provides information regarding the disclosure policy
02/01/2016 – CERT/CC acknowledges receipt of information
04/05/2016 – CERT/CC indicates that the vendor did not respond and suggests that Tripwire proceed with disclosure