Ruckus Raucous: Finding Security Flaws in Enterprise-Class Hardware

Image

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 suspicion 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 affordable consumer routers, enterprise equipment is not cheap and my budget meant I would most likely 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.

METHODOLOGY

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.

FIRST IMPRESSIONS

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.

ANALYZING THE RUCKUS HTTP INTERFACE

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 when I set up a Ruckus H500 access point with the latest firmware (100.1.0.0.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.

THE FINDINGS

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.

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

RUCKUS’ RESPONSE

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. Ruckus did not acknowledge receipt of any vulnerability reports until Tripwire’s Chief Research Officer, David Meltzer, reached out directly to Ruckus executives over LinkedIn. After that I received a forwarded copy of my encrypted report from January with a request for receipt confirmation. During a follow-up call I was told that they had not been able to decrypt my message and had therefore ignored it. I was also told that they had no knowledge that CERT had attempted to contact them. I have been advised by Ruckus that these vulnerabilities present in the HTTPS interface are not exposed unless the product is running in standalone mode. I have yet to validate these claims or to perform a full security audit on any Ruckus product.

LESSONS LEARNED

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 problems I have found on SOHO devices in the $100-$200 range. The biggest difference here is that my report to Ruckus appears was completely ignored for many months and required ‘Executive-to-Executive’ communication before the report was acknowledged. 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. Ruckus has advised that only standalone APs would be affected but I have not had a chance to evaluate this claim and do not know how prevalent the standalone mode is. The bulk of the security research described in this article was performed in a single evening, so in my opinion it would be foolish to think that there are not more issues lurking or that the other operating modes are necessarily any more secure. Discover how to help protect your embedded devices better by reading this article, "Five Security Tips to Protect Embedded Devices". A full timeline of this disclosure process is as follows:

Image

Save Save Save Save Save Save