Investigating in Isolation: WeMo

Like the rest of the world, I'm confined to my house in isolation until this pandemic passes. At first it looked like I'd have all of this newfound free time on my hands, no longer commuting round trip for 1.5 hours each day. But then the world realize that they can reduce the void caused by social distancing with a bounty of Zoom conferences. Alas.

Before I entered my Zoom Cocoon™ I thought about how I could put this additional time on my own home network to better use. Being a networking nerd, I struck upon the idea of deep diving into the various IoT devices I have strewn about the house, to learn more about their behaviors and to give me the opportunity for adding additional layers of security. Today's focus is the WeMo family of devices by Belkin.

The Method

A few days ago, I put a capture-filter on my home router, isolating it to a single WeMo device; in this case, it was a three-way light switch. I let it soak for a few days, pulled down the capture, and picked through it to see the different varieties of network traffic that it generates and transmits. Because I captured this at my router, obviously I'm only going to see the traffic to the internet, broadcast traffic, and multicast traffic... but for my purposes this is perfectly adequate for now.

I also pulled down all of the DNS records from my local DNS server (Pi-hole, natch, which I've written about before) to correlate to those outbound IP addresses. (A necessary step, since my DNS server is on my LAN and doesn't go through the router, either.)

I also found some excellent prior art in this area that was very helpful in confirming my findings and shedding light on some items that I was not particularly interested in digging into myself. (Here's another good source.)

The Findings

There are five main categories of traffic that are initiated by the WeMo device and sent out to the LAN/internet. They are:

• STUN packets. Having spent a decade in the Voice over IP industry I'm very familiar with STUN (Session Traversal Utilities for NAT). This is how each WeMo device communicates my network's public IP address and maintains a connection to a cloud service, to allow inbound signals to the device. This is how the WeMo cloud service tells my lights to switch on and off when I'm using the mobile app away from home.
• NTP packets, for clock synchronization.
• SSDP packets. This is the Simple Service Discovery Protocol. This is how the WeMo application on a phone discovers and controls the local WeMo devices on a WiFi network. There's a great blog from 2014 demonstrating how to control the devices using SOAP.
• mDNS packets. This one's a bit of a puzzler. mDNS is part of the "Zeroconf" (a.k.a. Rendezvous) suite of protocols that Apple, among others, use for fast tracking common home/small enterprise workflows. Things like printer discovery, locating fileservers, media sources, etc. My data capture was filtered on one particular WeMo host, not on the mDNS multicast address (224.0.0.251), so I only saw half of the conversation. This will come in a future phase.
• DNS packets, used to find the destinations for the STUN and NTP servers – and WeMo's own cloud-based Command and Control systems.

DNS queries

The WeMo routinely sent out DNS queries for the following destinations:

• api.xbcs.net
• fs.xbcs.net
• nat.wemo2.com (as well as recursive requests for other *.wemo2.com addresses); note: older devices may use nat.xbcs.net
• heartbeat.lswf.net
• heartbeat.xwemo.com
• *.openwrt.pool.ntp.org

STUN messages

The WeMo is sending STUN messages to nat.wemo2.com, which is hosted in Amazon AWS. Each STUN reply indicates the TTL of the STUN session, which in my device's case is 330 seconds. Every 310 seconds the device sends another STUN message. It's not clear to me whether this time is hardcoded or negotiated; the NAT TTL on my router is well over 330 seconds – I have it currently set to 3600 seconds, in fact – but it may be due to some device upstream of me. Because of this, I'll reduce my STUN session timer to 360 seconds:

admin@labsystem1.fiedler# config auth session-type STUN timeout 360000
admin@labsystem1.fiedler# show config candidate auth session-type STUN

config

    authority

        session-type  STUN
            name           STUN
            description    "Session Traversal Utilities for NAT"
            service-class  LowPriorityData
            timeout        360000

            transport      udp
                protocol    udp

                port-range  3478
                    start-port  3478
                exit
            exit

            transport      tcp
                protocol    tcp

                port-range  3478
                    start-port  3478
                exit
            exit
        exit
    exit
exit

There's no need to have those STUN sessions lingering around longer than necessary.

On my to-do list is to find a clever way of catching these DNS requests and caching them, so that all of the WeMo systems are using more or less the same servers. This way it'll be much easier to secure all of them at once. More to come on this in the future.

NTP synchronization

It seems to be a common complaint that WeMo devices do not honor the NTP servers they receive in their DHCP response. My home network issues out my router's IP address, and my router clocks off of public NTP servers. Based on DNS, it's clear that these WeMos are based on an OpenWRT derivative and hardcoded to use openwrt.pool.ntp.org servers. While I don't have too much of a problem with these WeMo systems using public NTP, it does represent unnecessary internet traffic. I'll redirect that to my local router.

SSDP and mDNS

Since these are both local to my LAN, there's no external surface area to secure. (My edge router most assuredly does not allow for UPnP.) These service advertisement and discovery protocols will be a subject for some future research.

Conclusion

With a little bit of edge router tuning I've reduced the outbound communication between WeMo and their mothership, and identified a few more areas for further investigation. I have about a dozen WeMo devices in several locations, before I'm done with WeMo my goals are:

• Bridge two WeMo bastions together using Secure Vector Routing, for the holy grail of controlling two homes' worth of WeMos with one app
• Consolidate and secure the outbound STUN (etc.) traffic for all WeMos to a small number of internet-based targets
• Ensure consistent behavior among all WeMo devices (the device I scrutinized here is a modern, three-way light switch; I also have a bunch of Gen1 WeMo devices that may behave differently)
• Study the SSDP/mDNS behavior to see if there's anything clever I can do with service discovery techniques in the 128T router at home

Thanks for reading!