Enterprise access point maker Ruckus once again patched up command injection vectors that could completely compromise both the ZoneDirector controller, as well as the Unleashed AP. One of the vulnerabilities is in fact strikingly similar to an issue in another Ruckus Web-GUI I disclosed last year.

While vulnerability is essentially an inevitable fact of life for any sufficiently complex software, there are several mitigating factors that can often greatly reduce the impact of a successful exploit.

In the year 2017, there is no reason for some of these design failures to be happening in product after product. It is time that we as security professionals start expecting more from vendors.

With this in mind, I have compiled a list of some security practices we should consider as part of a baseline of security.

1. STOP RUNNING EVERYTHING AS ROOT!

Perhaps in the early days of embedded Linux, resource constraints drove developers to drop the traditional user-based security model and do everything as root. Today, there is no excuse for having web servers running with full uid 0 permissions.

By default, management interfaces should be running with reduced privileges and only have the ability to perform a limited set of privileged operations. If Ruckus had taken the time to employ any form of privilege separation, it is unlikely that any of the vulnerabilities I’ve reported to them could be directly used for a complete compromise.

2. ANTI-CSRF TOKENS SHOULD BE EVERYWHERE!

Cross-site request forgery (CSRF) is one of the most ubiquitous security defects that I see in embedded devices. This is compounded by the fact that most IoT products are designed to blindly trust the local network or simply fail to properly validate authentication tokens.

If Ruckus had implemented CSRF protections after my last disclosure to them, these new vulnerabilities would be effectively limited to insider threat. As it stands, however, it is not hard to write JavaScript capable of locating a device on the local network and relaying attacks to it.

3. ENABLE EXPLOIT MITIGATIONS!

Defensive technologies have come a long way in recent years, but it is rare to find embedded devices making use of them. Many of the devices I’ve examined fail to use things like address randomization (ASLR), position independent executables (PIE), or NX. While this is not a vulnerability in itself and these technologies are not perfect, they do definitely raise the bar required for reliable exploitation of memory corruption issues.

It would also, of course, be great to see vendors make use of newer technologies like control flow integrity (CFI) or even certain runtime sanitizers, but there is simply no excuse for not making use of security features that have been available in Linux for more than 15 years.

4. AUTHENTICATE REQUESTS!

All too often, I find that the default behavior of a device is to treat any requests from the local network as authenticated. For example, the Belkin WeMo will allow anyone on your home network to take control and become associated with your home account. The Mios Vera home automation controller requires the user to dig through settings to enable any form of authentication, and doing so makes the device inoperable if there is an Internet service outage.

Meanwhile, Control4’s system requires authentication to login to their app, but devices will accept commands over an XML based protocol without any tokens or passwords. Weak or missing authorization schemes have a compounding effect with CSRF by allowing malicious web pages to directly manipulate devices without requiring that the victim has previously authenticated with the device.

5. STOP USING SO MUCH HTTP!

Even if you don’t access a device through a web browser, there is a good chance it is running a web server anyway. Web management interfaces for things like routers and smart home controllers are typically the biggest attack surface for a device. Although the management page of something like a router is used only very rarely, the HTTP server runs all the time just waiting for requests.

The use of an HTTP server means that an attacker hosting malicious web content (malvertising perhaps) has the ability to direct requests to the server. Even if CSRF mitigation is in place, vulnerabilities in the web server implementations themselves can often be lethal. As an example, several models of NETGEAR router that make use of a timestamp-based CSRF protection for all administrative functions could be trivially exploited through cross-site request forgery due to a ridiculous bug in the web server.

Ideally, I would like to see most device communication move away from HTTP to other more purpose-built protocols like MQTT, which should be generally immune to cross-site and cross-protocol exploitation attempts. In some cases like a configuration page, it may be the case that HTTP/HTTPS is the best option, but there is no reason for these systems to run all the time when they are only used very rarely.

An easy solution to this would be to require a button press (or some other non-HTTP trigger) to start the management interface and then have it automatically disable itself again after some specified timeout.

CONCLUSION

These five relatively simple strategies are certainly not a complete list, but I do believe implementing them does a lot to reduce attack surface. With real-world IoT attacks on the rise with Mirai and now IoT Reaper, it is increasingly critical that we curtail the proliferation of Internet-connected devices lacking basic security controls.

via:  tripwire