Pervasive vulnerabilities in SOHO routers
SO HOpelessly Broken
Home and small office networks typically place their security in the hands of an inexpensive device that serves as a router, DHCP server, firewall, and wireless hotspot. How secure are these SOHO router devices? We're glad you asked …
Small office/home office (SOHO) routers are a staple networking appliance for millions of consumers. SOHO routers are often the single point of ingress and egress from a SOHO network, managing domain name resolution, firewall protection, dynamic addressing, wireless connectivity, and, of course, routing. The heavy use of SOHO routers in the consumer market, as well as the targeted demographic of non-computer-savvy users, has not surprisingly led to some very easy-to-use turnkey solutions.
The list of known vulnerabilities for SOHO routing devices is long (Figure 1), and our research revealed 56 previously undisclosed security vulnerabilities in SOHO devices. The alarming quantity of these security problems demonstrate how the rich service and feature sets (e.g., SMB, NetBIOS, HTTP(S), FTP, UPnP, and Telnet) implemented in these routers comes at a significant cost to security. All the extraneous services running within these SOHO routers expose attack surfaces that a malicious adversary can leverage to compromise the router core and gain a foothold in the victim network.
Once compromised, any router – SOHO or otherwise – may be used by an adversary to secure a man-in-the-middle position for launching more sophisticated attacks against all users in the router's domain. The attacks could include sniffing and rerouting all network traffic, poisoning DNS resolvers, performing denial of service attacks, or impersonating servers. Worse still is that these routers are also firewalls and often represent the first and last line of defense for protecting the local network. Once compromised, the adversary has unfettered access to exploit the vulnerabilities of local area hosts that would be otherwise unreachable if the router were enforcing firewall rules as intended.
The research of an ISE security team , in which 14 routers were initially targeted, is available on our main research page.
Universal Issues Realized
Our analysis of extraneous service vulnerabilities inherent in the evaluated routers revealed that these security flaws originated from four primary categories:
- misconfiguration of network services,
- the assumption of security on the LAN,
- insecure default configurations, and
- poor security design and implementation.
Misconfiguration of services is characterized by network services that lack configuration options or utilize unnecessarily lenient permissions. The lack of configuration options could permit network services to operate in unintended ways, such as SMB allowing symbolic links to traverse into the router's root directory (Figure 2).
During our analysis of SOHO routers, we found that all of the routers studied do not utilize (or even attempt to utilize) a secure connection for sensitive data communications between the router and network clients. All of the routers' web-based configuration portals use password-based authentication over HTTP – a method that is well known to be insecure without SSL/TLS encryption.
Additionally, the routers all provided a range of services that lack secure channels or authentication mechanisms, such as FTP, Telnet, and SMB. As evidenced by this analysis, it is apparent that the high-end consumer routers are designed under the assumption that communications and machines on the (wireless) LAN are free of potential threats.
Relying upon this assumption of security, manufacturers are prioritizing ease-of-use and obtaining the highest variety of features possible, instead of finding an equilibrium between security, functionality, and ease-of-use (a.k.a., the SFE Triangle – Figure 3).
In their default configuration, all the routers we examined were found to be insecure by default, typically because of unsecured features, failure to abide by the principle of least privilege, support for outdated technologies, disabled security protections (e.g., advanced firewall), or weak or publicly known service credentials.
Routers are generally plagued by design and implementation issues, most notably evidenced by the lack of input validation. The majority of the routers were vulnerable to web-based attacks, such as cross-site scripting, cross-site request forgery (Figure 4), directory traversal, and command injection.
Lesser known network services were also found generally to have poor input security and were vulnerable to buffer overflow vulnerabilities. These configuration and optimization services with serious vulnerabilities (e.g., ACSD, HTTPD) were found running and could not be deactivated by an end user, preventing adequate security hardening of the devices.
Through successful exploitation, we obtained administrative shell or web portal access on all routers examined while in their hardened state, after the USB storage was attached. Access was gained by exploiting combinations of discovered vulnerabilities. Through rigorous analysis, we discovered buffer overflow, improper system permissions, service misconfigurations, insecure cryptographic storage, and web-based vulnerabilities on multiple routers – and often across router models from different vendors, representing common issues across the SOHO router industry at large.
SOHO routers often utilize software packages for various network features, such as WPS monitoring, FTP servers, and wireless configuration. Through dynamic and static code analysis of select software packages, we found that several routers were vulnerable to multiple buffer overflow attacks. One example is the Broadcom ACSD network service used by the ASUS RT-AC66U and TRENDnet TEW-812DRU routers. This service is used to scan for and select low-interference 802.11 channels. The ACSD service on these routers (which listens on a port open to the local network) is susceptible to multiple remote, unauthenticated buffer overflow attacks through a lack of input validation of the service's command arguments.
Another example is the HTTP server used by the ASUS RT-N56U router. This web server is used to perform web-based configuration of the router, and as such, it allows the administrator to configure additional media-based applications (e.g., cloud file access, automated torrent client). It is within this configuration process that the HTTP server is vulnerable to multiple remote, authenticated buffer overflow attacks. Since these software packages typically run with root-level privileges, as was the case with ACSD and HTTPD, a successful buffer overflow exploit provided us with full administrative control over the affected routers.
The MIPS architecture used with many SOHO router devices complicates the task of writing exploit code (see the box titled "Working with MIPS"), but attackers have strategies for working with the limitations of MIPS. In light of the MIPS architecture and calling convention, we used a technique known as Return-Oriented Programming (ROP) to exploit these buffer overflows. ROP alters the program's execution flow and redirects it to the attacker's injected code by using small instruction sequences of the program's existing code, known as ROP gadgets. We successfully leveraged ROP to exploit the buffer overflow vulnerabilities in the Broadcom ACSD and the ASUS HTTPD network service.
Working with MIPS
MIPS is a Reduced Instruction Set Computer (RISC) architecture, unlike the familiar x86, which is a Complex Instruction Set Computer (CISC) architecture. As the name implies, RISC CPU architectures have fewer available instructions than CISC CPU architectures. The simplicity offered by the reduced instruction set allows for faster execution of machine instructions and therefore better performance. The MIPS architecture also has some features that make it more difficult for a coder to create an exploit.
The MIPS instruction set is not only reduced, but MIPS instructions are fixed length. No matter the operation being performed, all instructions are either 16 or 32 bits in length. These limitations complicate exploit development, because bits and pieces of instructions are unusable while hunting for ROP gadgets. For example, x86 architecture doesn't have the byte boundary that the MIPS architecture has; one instruction can be a subset of another instruction, or the suffix of one instruction and the prefix of another can be joined to create a different, valid instruction.
Additionally, RISC instruction pipelining (see the "Common MIPS Instructions" box) leads to extra instructions being executed as the program branches (jumps) to another part of the code segment. When the CPU executes instructions that branch the execution flow (i.e., jumps and branches), the instruction following the branch is also executed. This limitation has to be taken into consideration while developing exploits, because the executed branch delay instruction could have an adverse affect on the state of CPU registers and memory. For example, when the
jalr instruction in the following sequence of MIPS instructions is executed, the instruction occupying the branch delay slot (i.e.,
ori a1,s0,0x2) will also be executed. When executed, the branch delay slot will modify the contents of the
$a1 register by performing a bitwise
OR operation and storing the result in
# move t9,s1 # jalr t9 # ori a1,s0,0x2
Finally, contrary to x86, return addresses are stored in a CPU register instead of on the programs call stack. This trait of the MIPS architecture complicates exploitation, because an exploit developer not only needs to modify the stack, but also the contents of the RA (return address) CPU register.
Common MIPS Instructions
- LUI – Load upper immediate: The constant value is shifted left 16 bits and stored in the register. The lower 16 bits are zeroes.
- ORI – Bitwise OR immediate: A register with a constant; stores the result in a register.
- SW – Store word: Stores the content of the specified register at the specified address.
- ADDI – Add immediate: Adds a register and a sign-extended constant and stores the result in a register.
- JALR – Jump and link: Jumps to the calculated address.
Today, ROP is a common method for exploiting memory corruption bugs such as buffer overflows and is a commonly used technique to bypass Data Execution Prevention (DEP). Traditional exploitation of a buffer overflow usually involves an attacker overwriting a function's return address on the program stack with a memory address that points to malicious shellcode. Conceptually, replacing a legitimate return address with an address that points to shellcode is the same as using ROP; the difference is that we instead overwrite the return address with a pointer to the first instruction of the first ROP gadget in the chain (series of gadgets). This technique allows the attacker to modify the CPU registers and various memory locations before executing shellcode stored in the program's memory.
Buy this article as PDF
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?
The new Torus distributed storage system is available under an open source license on GitHub
Juries decides Google’s use of Java APIs Was Fair Use
But if you are not using the latest Linux kernel, your system is insecure.
Home routers will give room for custom firmware but still comply with FCC rules
Frank Karlitschek will continue to lead the open source ownCloud project
“Xenial Xerus” comes with a new packages format and several improvements for the enterprise.