Are my lightbulbs phoning home?

      5 Comments on Are my lightbulbs phoning home?

Just lately I’ve been getting into home automation. No, not with ESP8266s and lots of soldering and programming – that comes next. I mean the easy way, by buying smart lightbulbs and switches.

We have an old, dark house, which means we use a lot of lamps. Every morning, in the living room alone, we’d go around switching on seven lamps or power strips. During the day, some of these would need to go off for various situations – watching the TV, reading in the evening etc – and then back on. Then they’d all need turning off at night.

To a geek, that’s an insultingly manual procedure. So I went for a bunch of smart lightbulbs, a smart power strip and some smart switches – all HomeKit compatible – and an Apple HomePod Mini. We now have smart lighting in three rooms, and it works great.

But…

As someone whose day job is in cyber-security, I got to wondering about whether these devices were talking behind my back – phoning home to their robot masters. I’m of the opinion that what happens in my house, stays in my house (And yes, Siri, blah blah … but you can’t have everything perfect.)

Assigning IPs

Well, there’s an easy way to find out. My first step was to use the DHCP server on my Netgate SG-2100 router/firewall to assign IPs to these devices within a specific range.

My home network operates on a 10.0.0.0/16 network. I assigned IPs to the smart devices in the range 10.0.120.0/24 – ie, only smart devices would have 120 as the third octet.

You’ll notice that the devices are all from either LiFX or Meross. That wasn’t deliberate – it just happened that way. LiFX is an interesting company in that it publishes detailed information about the cloud-based and LAN-based APIs for its products. You can find plenty of Python libraries on GitHub to take advantage of these if you want to control the devices with your own software. But that’s a subject for another day.

Sniff the packets

The Netgate router is connected to a Netgear smart switch. This allows you to assign one of the Ethernet ports to do ‘mirroring’. In other words, you can tell it that all packets passing through port X should also be sent to port Y.

I have an Odroid H2+ acting as a server in my ‘datacentre’ (two shelves in the spare room). One nice feature about this machine is that it has two gigabit Ethernet ports. I hooked the spare one, enp3s0, to the mirroring port on the switch. That interface on the Odroid could then see every packet that was going through the firewall.

The ‘datacentre’. Top shelf (L-R): Netgate SG-2100 router/firewall; Odroid H2+ server; Netgear 16-port smart switch. Bottom shelf (L-R): Netgear AP; home-made power supply; rack with three Raspberry Pi servers & one SSD; Orange Livebox 4 ADSL router.

Next step:

sudo apt install tshark

As you may know, tshark is the command line version of Wireshark, the famous packet analysis tool.

Next, I issued the command:

tshark -q -a duration:3600 -i enp3s0 -f "net 10.0.120.0/24 and not broadcast and not multicast" -F pcapng -w ~/captures/iot.pcap &

This captured all the traffic on Ethernet interface enp3s0 that was coming to or from the subnet 10.0.120.0/24, other than broadcast and multicast packets, and saved it in pcapng format to a file. It did this for one hour (3600 seconds). The result was 1401 packets!

Although that’s a lot of traffic to contemplate, it quickly became apparent that it was all from the Meross devices – nothing from the LiFX lightbulbs. Also, the IPs the devices were talking to were Amazon Web Services (AWS) servers and the traffic was TSL encrypted.

Weirdly, all of this TCP traffic was from just two of the smart switches. If I filtered out 10.0.120.21 and 10.0.120.23, then there was no TCP traffic.

Filtering out TCP packets, plus DHCP and ARP (which only go across the local network anyway) I was left with the above – the switches carrying out NTP queries – checking the time, for whatever reason.

I’ve decided to block TCP traffic through the firewall for the 10.0.120.0/24 range to see if it has any effect on how the devices function. I’ll let you know what happens with updates to this post.

 

 

 

 

5 thoughts on “Are my lightbulbs phoning home?

  1. Paul M

    What DNS lookups are the devices doing? That might give a clue to the purpose of these connections

    Reply
    1. Machina Post author

      The DNS lookups are purely for the NTP server: time2.aliyun.com. So it’s using UDP for DNS and NTP connections. But then it makes TLS 1.2 connections over TCP and exchanges some data which, obviously, I can’t make sense of because it’s encrypted.

      Currently I have my firewall set to allow the DNS and NTP queries. But there seem to be a surprising amount of them, so I may block them too. I was blocking them earlier and so far have not seen any change in the behaviour of the devices.

      I’m surprised that the LiFX bulbs aren’t showing any activity. After all, the firm makes a big deal (and is very open about) its cloud interface. One interesting thing I found that that those bulbs seem to have a built-in web-server – at least, they respond on port 80 with an HTML 404 page.

      Reply
    2. Machina Post author

      Hmm. Also seems that DNS queries are going to mqtt.meross.com and mqtt-alter.meross.com.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.