Persistence of Vulnerabilities

The vulnerabilities described in this article, as well as several others from our research study, cannot be disabled by the user as a mitigation measure. The ACSD and HTTPD services cannot be disabled by the user, and in other cases, attacks against required services (e.g., cross-site scripting or cross-site request forgery attacks) can be used to re-enable user-disabled services, once again exposing them. Because administrators have no way of removing or disabling these services entirely, they will remain vulnerable indefinitely or until a firmware patch is released by the manufacturer.

Adding to the persistence of these issues is that all of the routers we assessed have very cumbersome, and unlikely to be enacted, update capabilities. By default, none of the routers update automatically; most of the routers do not provide a notice to administrators when updates are available, and all of the routers require an administrator to log in manually and embark specifically on a multistep firmware flashing process that is not always intuitive or understandable by the average consumer. For this reason, it is likely that these vulnerabilities will persist even after the manufacturers have provided the necessary fixes.

Finally, once a SOHO router has been compromised, the device should be decommissioned. The minimal actions that can be taken by the consumer to attempt to reset a device's firmware are insufficient to guarantee a firmware upgrade has been successful. An adversary in full control of the router should be capable of preventing or emulating a successful reset or upgrade.

YIKES! What Can You Do?

Unfortunately, consumers have few options for stopping these exploits, but a few best practices will substantially decrease the likelihood of exploitation. First and foremost, standard hardening steps should be taken, such as disabling unused services, enabling protocol encryption, and using strong passwords for administration interfaces and network services. Developers should be vigilant about following their own best practices to help thwart buffer overflow attacks, refrain from using unsafe functions (e.g., strcpy, sprintf memcpy, gets), and perform bounds checking before copying user input to a fixed-length buffer. Additionally, the use of compile and link-time protections (e.g., ASLR, DEP, canary/stack cookies, Windows safeSEH) will greatly complicate exploitation should an overflow exist. Finally, and most importantly, consumers should take a proactive stance against SOHO router vendors by demanding that security be a priority. All too often, manufactures choose to ignore security because consumers don't demand it; until consumers demand more from manufacturers, it is unlikely they will change their tune.