Belkin IoT Smart Plug Flaw Allows Remote Code Execution in Smart Homes

An unpatched buffer overflow flaw allows remote attackers to completely take over the device and enter the home network.

A vulnerability in a popular Wi-Fi–connected electric outlet for smart homes would allow a remote attacker to take over smart TVs and other devices, as well as execute code – potentially exposing tens of thousands of consumers to cryptomining, ransomware, information disclosure, botnet enslavement and more.

Belkin’s Wemo Insight Smart Plug.

The Belkin Wemo Insight Smart Plug has a standard buffer overflow in its libUPnPHndlr.so library, according to McAfee’s Advanced Threat Research team. It can be used to bypass local security protection via crafted HTTP post packets.

At the most basic level, the flaw (CVE-2018-6692) would allow a malefactor to switch the plug on and off – not much of an impact beyond being a nuisance. However, by design these smart plugs are meant to be connected to the home Wi-Fi network; the plug is used in home-automation scenarios, allowing homeowners to remotely turn lights or anything else plugged into it on and off, via an app or a home-hub dashboard.

“If the plug is networked with other devices, the potential threat grows,” said McAfee researcher Douglas McKee, in an overview today of the flaw shared with Threatpost. “The plug could now be an entry point to a larger attack.”

For instance, after the plug is compromised, an attacker could use the built-in Universal Plug and Play (UPnP) library to “poke a hole in the network router,” McKee explained; the Wemo listens on UPnP ports TCP 49152 and 49153.

“This hole creates a backdoor channel for an attacker to connect remotely, unnoticed on the network,” he explained. “With the attacker having established a foothold on the network and able to open arbitrary ports, any machine connected to the network is at risk. Because attacks can be conducted through the Wemo and the port mappings generated using this exploit are not visible from the router’s administration page, the attacker’s footprint remains small and hard to detect.”

In one scenario, researchers were able to use a remote shell to control a TCL smart TV connected to the network: “The Roku API implementation on the TV uses simple unencrypted HTTP GET/POST requests to issue commands and does not authenticate the machine sending these commands, making remote control trivial,” the researchers said. “Using the Wemo as a middleman, the attacker can power the TV on and off, install or uninstall applications, and access arbitrary online content. Smart TVs are just one example of using the Wemo to attack another device.”

Other dangers include executing remote code to implant malware on connected devices on the network.

“An attacker could drop malware through this vulnerability,” McKee told Threatpost. “This vuln mainly gives the attacker a pivot point into a network. The threat from here would depend on the rest of a network’s security, but could allow further attacks to take place remotely of business servers, personal laptops, network devices etc., which are not normally accessible externally.”

He added, “There is no personal information stored on the Wemo itself, however this could lead to the release of personal information on from other devices.”

To start hunting for bugs, researchers used the Wemo phone application to set up the smart plug, then cracked open the hardware to examine the on-board chips. The flash chip discovered on the board was a Maxronix MX25L12835F, which is supported by flashrom, a well-known open-source tool for extracting firmware. The researchers were thus able to extract and analyze the firmware (using Binwalk, an open-source binary analysis tool), eventually extracting the file system.

From that extracted file system, the researchers then uncovered that Wemo runs the embedded Linux system OpenWRT, with user account information held in either the standard /etc/passwd or /etc/shadow files. Using the ability to read the aforementioned flash chip, they were able to replace the /etc/passwd file with a known password and gain root access to the Wemo to fully analyze it.

The analysts also found universal asynchronous receiver-transmitter (UART) pads amidst the hardware; after deciding to fuzz the open UPnP ports listening on the local network (because “the network or remote vulnerabilities are more dangerous than local flaws,” McKee said), the team saw a crash on the UART interface. This turned out to be a standard buffer overflow, which overwrites data onto the stack.

Upon further inspection, the researchers found that a segmentation fault occurred at address 0x2AC15B98, caused by a UPnP packet.

“From the memory layout from the Linux ‘proc’ directory, we determined his memory address resides in library libUPnPHndlr.so,” explained McKee. “As the function copies data onto the stack, it eventually copies over the address for the original buffer. Once this address is overwritten, the function attempts to write the next byte at the new value, in this case is an invalid address. This overflow gives an attacker two exploitable vectors: a write-what-where condition allows an attacker to write data to an arbitrary location in memory; by continuing to overwrite data on the stack, an attacker can overwrite the $RA register or return address for the calling function, providing the attacker control of the execution flow.”

To exploit the flaw, the researchers examined how much of the payload makes it onto the stack if they repaired the address overwritten on the stack with a valid address: the answer was only 91 bytes. They also noticed that only ASCII characters can make it onto the stack.

“Before the vulnerable code is executed, the packet is parsed by the open-source XML parser ‘mxml,'” said McKee, adding that the vulnerable library “follows the standard of allowing only ASCII and Unicode characters to exist between tags. This standard is very problematic for both shellcode and return-oriented programming (ROP) techniques because both memory address and shellcode tend to use mostly nonreadable characters.”

To get around the limitations, the team used functions that are already loaded into memory to build the exploit.

“One method that does not require extensive shellcode is to use a ‘return to libc’ attack to execute the system command,” McKee said. He explained that because the Wemo does not use address space layout randomization, if an exploit uses ROP it would be theoretically possible to make a call to system without needing to pass additional shellcode through the XML filter.

After studying the memory layout, the team discovered that libuClibc-0.9.33.2.so sits at a memory location with addresses that can perform the bypass. From there, the researchers used a custom tool to “pull out all possible ROP gadgets with usable memory addresses;” The result was the creation of an ROP chain consisting of three gadgets that can bypass the XML filter, which easily fit in the stack space provided by the buffer overflow.

An attacker could then craft malicious HTTP post packets to be sent over the internet to one of the open UPnP ports; McKee explained that the ROP chain that calls system requires the use of write-what-where to handle extra instructions in one of the ROP gadgets, meaning that two packets are required to execute the exploit: one to write the parameter for system into memory, and a second to make the call to system.

Once successful, “because system executes as root, we can gain complete control of the device” – from there pivoting to other devices on the network or executing code.

The team also found additional dangers lurking within the smart plug.

“An attacker could also call wget [a Linux command] from system to download and execute any script,” McKee said. “[And] we explored further for installed applications and found NetCat, which could allow an attacker to write a script to create a reverse shell. An attacker could download a script using wget, and execute the script containing a NetCat command to create a reverse shell. We tested and proved this is one simple, effective method, opening a reverse shell as root.”

The difficulty level for exploitation is medium, McKee told Threatpost.

“The attacker would need to understand MIPS architecture, stack based buffer overflows and XML character filters,” he told us. “The attacker also needs access to the same wireless network the device is on initially, but this is generally not hard to obtain. The attacker could find the device with a network scan.”

The CVE-2018-6692 flaw is just the latest security issue found in the home automation footprint. Just last week, it was uncovered that misconfigured DIY smart-home hubs for home automation could allow attackers to track owners’ movements, see if smart doors and windows are opened or closed, and even open garage doors. And in July, researchers found 20 flaws in Samsung’s SmartThings Hub controller – opening up supported third-party smart home devices to attack.

The Wemo itself has been found to be vulnerable before as well: In 2014, researchers at IOActive found serious flaws that would enable attackers to gain remote control of connected devices, provide malicious firmware updates and gain access to the internal LAN.

“These devices run operating systems and require just as much protection as desktop computers,” McKee said. “A vulnerability such as we discovered could become the foothold an attacker needs to enter and compromise an entire business network.”

McAfee reported the issue to Belkin on May 21; a patch is not yet available.

“I would say in the scope of home automation, this is normal for what we are seeing with these types of devices,” McKee told Threatpost. “Security is being seen as a secondary concern for home automation and therefore, we see a continued large number of flaws. Smart-home devices need to be treated the same way laptops, desktop, servers etc have been treated for years. These need to have security reviews and implement industry best security practices.”

 

Suggested articles