The secret public IP addresses anyone can use

When I set up Google's free DNS service for my home network, I wanted to be able to use any public DNS to look up my home machines.  For example, if my coffee maker is called coffee.dammitly.net, I wanted to be able to type that address into the web browser on my phone.

My plan was to just use one of the private IP spaces like 192.168.0.0/16 or 10.0.0.0/8 to number my home network, and have Google DNS resolve my office light bulb to one of these addresses.

Unfortunately, Google's free DNS service won't let you enter private IP address A records into its database.  I would need to use public IP addresses.  The problem was, those are impossible to get now with ipv4 address exhaustion.

Sure, I could re-number my entire network using the new ipv6 standard and then set up SLAAC or DHCP, but that's a lot of work for my small network.

I decided to go searching to see if there were any public IP blocks I could poach for my home network.  A little research turned up the 44.0.0.0/8 subnet, assigned to Amateur Radio's AMPRNet.  This is a block of 16 million public addresses for Amateur Radio devices to use.  More research showed that most of these weren't even assigned to routable devices.

In other words, a person could use this public IP block on any local network with little concern for preventing their users from accessing other important services.  If you know your users will not be connecting to amateur radio devices (and most probably won't), you've got a free block of 16 million addresses.

The best part, Google's free DNS service allows you to create Address (A) Records with these addresses.  I can now look up my thermostat's IP address from anywhere, and I didn't have to set up my own DNS server.

IOT Security is in a Frightful State

An IOT front porch light

If you read my previous post on Philips IOT (Internet of Things) light bulbs, you already know most manufacturers put little thought into IOT device security.

Traditional devices now come in IOT versions.  These include the obvious ones like security cameras, routers and thermostats, as well as the less obvious ones like TVs, baby monitors, light switches and bulbs, weather stations, and doorbells.  This is not to mention industrial control devices for water and power utilities.

Each of these is a vulnerability exposure that a malicious hacker can use to attack you.  If these devices get compromised, it can open you up to identity theft, or worse.

Examples of these vulnerabilities include the VPNFilter router worm.  This was a remote exploit affecting major brands of wifi routers from companies like Linksys, Netgear, D-Link and TP-Link.  The exploit allowed hackers to monitor your internet traffic for things like banking passwords.  It was sophisticated enough to survive a device restart, and could only be stopped by a manufacturer-supplied firmware update.

Many device manufacturers are slow to issue fixes vulnerabilities, if they do at all.  TP-Link's series of "Kasa" wireless power switches shipped with weak encryption that was quickly broken.  Using a simple hack, someone cloud turn your lights, coffee maker, or refrigerator on/off if these were plugged in to the HS100.

The poor security of these devices can sometimes make them more useful to us.  A light switch that doesn't require a phone app to operate is more useful for a DIY home automation enthusiast.  The trick is to devices in a safe manner where the device's built-in security (or lack thereof) is not relied upon.  I will list several ways to protect your home network from these devices while still enabling their use.

1. Block the device from talking to the internet.  Using MAC-based firewall rules it is possible to block a device from reaching out to the larger internet.  Some devices nefariously "phone home," sending your data off to some overly-curious entity on the internet.  If the device is filtered, it can't do this.  Research iptables for more information on how to block device internet access.
2. Put all IOT devices on their own VLAN.  A VLAN is like a virtual network inside your physical network.  Devices connecting to a VLAN cannot see or talk to other devices on your network unless you allow it.  It is possible to put IOT devices on a VLAN such that the device can only talk to or see one other host. 
   
   An example would be a weather station that can only communicate with a web server on your network where you view the weather data.  By restricting which hosts a device can talk to, you reduce your threat exposure.  Research VLANs and trunk networks for more information.
3. Favor open-source, open-firmware devices.  Open source allows thousands of people to scrutinize the code running on a manufacturer's device.  This increases the odds of detecting vulnerabilities, and of getting them fixed in a timely manner.  The flip-side, security by obscurity, has been proven to be less secure.
4. Research a company's CVE list before buying a product.  The CVE list shows the vulnerabilities identified in a manufacturer's products.  Lots of CVEs isn't necessarily bad as long as the manufacturer has quickly supplied security fixes.  Avoid manufacturers with lots of CVEs and very few fixes issued.  Research CVEs here.
5. Finally, learning to use basic networking tools will help you find problems others haven't found.  An example is the program tcpdump, which I used in a previous post to find problems with an IOT device.  These tools are advanced, but can be learned if you're willing to put in the time.

This is not a complete list of ways to secure your network, by any means.  Taking these initial steps will help increase your protection against many of the most common IOT security exploits.

Monitor Kids' Web Browsing Using a RaspberryPi

A RaspberryPi computer

We have a child who is approaching his teen years.  As such, his need to access the internet for school and general use is growing.  We wanted a way to monitor and filter the sites he visits.

My first thought was that we'd maintain a list of "bad" sites we don't want him visiting, and filter these out.  It quickly became apparent this solution was not scalable because there is an unlimited list of sites not suitable for children.

It was clear we'd need to go the opposite direction:  maintain a small list of "safe" sites he could use.  It would include things like Khan Academy and Google Classroom.  This is referred to as a "whitelist" in technology jargon.

Some quick research showed that the widely-available package dnsmasq was suitable for the job.  dnsmasq is a popular system for resolving DNS names and for assigning IP addresses to devices on your network.  It's probably most often used for the latter purpose, but we really needed its DNS capabilities.

DNS provides the name-to-number mapping that lets you simply type "blog.dammitly.net" instead of a long string of numbers when browsing.  By listening for DNS traffic, I could tell if someone on my network was trying to visit a site I consider unsafe.

dnsmasq's whitelisting feature comes from its ability to redirect searches for a name to an alternate DNS server.  That server can then be set to not resolve the name, resulting in the inability to visit the site using a name.  Someone could still access the site if they could find the IP address some other way, but we'll worry about that later.

Using this feature, I set up a dnsmasq server on my local network, running on a RaspberryPi (pictured).  The Pi is a cheap Linux machine available online for as little as $35.

I set my son's computer to use this dnsmasq server to resolve all DNS queries.  Within dnsmasq's configuration, I identified the list of appropriate sites and set them to resolve normally using Google's public DNS (8.8.8.8).  Here is the configuration:

# /etc/dnsmasq.conf
domain-needed
bogus-priv
log-queries
log-facility=/var/log/dnsmasq.log
no-resolv
no-dhcp-interface=eth0,wlan0
interface=eth0

# List of "safe" websites
server=/google.com/8.8.8.8
server=/drive.google.com/8.8.8.8
server=/classroom.google.com/8.8.8.8
server=/edu.google.com/8.8.8.8
server=/accounts.google.com/8.8.8.8
server=/apple.com/8.8.8.8
server=/ntp.org/8.8.8.8
server=/debian.org/8.8.8.8
server=/ubuntu.com/8.8.8.8
server=/gmail.com/8.8.8.8
server=/pbskids.org/8.8.8.8
server=/khanacademy.org/8.8.8.8
server=/hourofcode.com/8.8.8.8
server=/cnn.com/8.8.8.8
server=/dictionary.com/8.8.8.8
server=/svwh.net/8.8.8.8
server=/pi-top.com/8.8.8.8
server=/raspberrypi.org/8.8.8.8

I will go through the list of options, explaining what each one means.

domain-needed:  Do not forward DNS lookups that don't include a full domain with dots.

bogus-priv:  Do not forward private IP space reverse address lookups.

log-queries and log-facility:  Log all queries to the specified log file.  This lets you see what sites a network client is trying to visit.

no-resolv:  Do not resolve any DNS lookups.  This makes the DNS server not resolve host names as its default behavior.  In other words, it won't resolve a name unless it's in the whitelist.

no-dhcp-interface:  Don't serve IP addresses to clients.  I used this because I already have a DHCP server on my network.

interface=eth0:  This is the network interface you want dnsmasq to listen on.  If omitted, it will use all available interfaces.

server=/google.com/8.8.8.8:  This tells dnsmasq to send lookups for google.com to Google's public DNS server, 8.8.8.8.  Google's DNS will resolve the name and make it so the DNS search succeeds.  Only add the sites you want to enable here.

And that's it.  Restart dnsmasq and be sure to point the client computer (or phone) DNS to the address of the host running dnsmasq.  You should see that non-whitelisted sites will fail to load, while the safe ones will load.

Is this a complete, bulletproof solution?  No.  There are ways for an advanced user to get around this.  DNS over https would allow the user to funnel DNS queries through an encrypted connection to the outside world, if they had that outside server's IP address.

The user could also simply look up the unsafe site's IP address using Google, or change the DNS server used inside their operating system.

To further secure the system I set up firewall rules on my Linux firewall to intercept DNS queries to the outside world.  These iptables rules will redirect all port 53 DNS queries to the localhost:

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 127.0.0.1:53

iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 127.0.0.1:53

This would prevent users from attempting to use another DNS server by intercepting their queries, as long as the queries go out on the standard port 53. Again, this would not prevent users from simply entering the site's numeric IP address if they happened to know it.

To summarize, this is not a full solution to the problem of restricting internet usage. There are many ways to get around these measures, as I detailed above. This will stop most novice users, and users who do not have administrative access to their machines.

Cheap, Hackable IOT Light Bulbs (or, Philips Bulbs Have No Security)

I was looking for a multi-color light bulbs, and most of what I found was kind of pricey, required bluetooth, or needed a crappy phone app to work. 

My three year old daughter has been waking us up around 5AM recently, and I wanted a simple way for her to know if she should stay in her room or get up for the day.  A color-changing bulb which I could schedule with simple Linux cron jobs would be ideal. 

With cron I could schedule the bulb to turn green when it's ok for my daughter to get up.  I could also set the brightness to the lowest level so it wouldn't wake her up if she was still asleep.

I didn't want to keep a dubiously insecure phone app just for this reason.  I also didn't want to buy a sleep training clock just for this purpose.



I found these inexpensive ($14.97) Philips 60w wifi LED bulbs at Home Depot and picked one up. These Internet of Things (IOT) devices seem to use the popular ESP series of wifi-enabled IOT SOCs, based on the hostname the device reports to DHCP.

After provisioning the bulb with the Wiz phone app, I did some snooping on the traffic between the phone app and the bulb.  Before going further, I should first explain that the Wiz app bulb setup required absolutely no authentication with the bulb you are setting up.  The only requirement is that the bulb be power-cycled so it enters discovery mode.

Anyone in wifi range could turn your bulb off and on, and set it up in whatever way they like.  If you're using the light with a timer or daylight detector, your neighbor could wait until it turns on in the evening and reconfigure your front porch light, for example.

Sniffing for traffic

Using tcpdump on my dd-WRT router, I found the traffic was mainly on UDP port 38899:

tcpdump -i br0 udp -vv -A       0x0000:  4500 00d3 00d1 0000 ff11 5593 2c14 0648  E.........U.,..H 

Most of it looked something like this:

       0x0010:  2c14 0646 c004 97f4 00bf 5be0 7b22 6d65  ,..F......[.{"me
       0x0020:  7468 6f64 223a 2273 796e 6350 696c 6f74  thod":"syncPilot
       0x0030:  222c 2269 6422 3a31 3033 2c22 656e 7622  ","id":103,"env"
       0x0040:  3a22 7072 6f22 2c22 7061 7261 6d73 223a  :"pro","params":
       0x0050:  7b22 6d61 6322 3a22 6138 6262 xxxx xxxx  {"mac":"0xdeadbe
       0x0060:  xxxx 3338 222c 2272 7373 6922 3a2d 3735  eeef","rssi":-75
       0x0070:  2c22 636e 7822 3a22 3031 3031 222c 2273  ,"cnx":"0101","s
       0x0080:  7263 223a 2275 6470 222c 2273 7461 7465  rc":"udp","state
       0x0090:  223a 7472 7565 2c22 7363 656e 6549 6422  ":true,"sceneId"
       0x00a0:  3a30 2c22 7222 3a32 3535 2c22 6722 3a30  :0,"r":255,"g":0
       0x00b0:  2c22 6222 3a31 342c 2263 223a 302c 2277  ,"b":14,"c":0,"w
       0x00c0:  223a 302c 2264 696d 6d69 6e67 223a 3130  ":0,"dimming":10
       0x00d0:  307d 7d                                  0}}

All the traffic was unencrypted and in plain text! Given the terrible state of IOT device security, I half expected some poor encryption or authentication scheme, but not a complete lack of security.  There was also no authentication scheme, such as a one-time hash that changes for each transaction. 

Examining the traffic, it was obvious what the light settings were right off the bat. "state" was the on/off switch, and "r", "g" and "b" were the light color RGB values. "dimming" was the light intensity. Wow, this was too easy. I wrote up a quick bash script to send the json payload with the values I wanted through netcat:

echo '{"method":"setPilot","id":527,"env":"pro","params":{"mac":"0x:de:ad:be:ee:ef","rssi":-75,"cnx":"0501","src":"udp","state"
:true,"sceneId":0,"r":0,"g":255,"b":4,"c":0,"w":0,"dimming":100}}' | nc -u 10.20.6.73 38899

The bulb returned a successful result and the light turned on with the color green.  Going further, I wondered if I could trick the Wiz app into changing its known state for a given bulb.  The app relies on once per 5 second heartbeat UDP packets from the bulb to know the power state and color the bulb is currently in.  It turns out this is trivially easy by just sending json to the app's IP address on port 38900:

echo '{"method":"syncPilot","id":126,"env":"pro","params":{"mac":"0xdeadbeef","rssi":-76,"cnx":"0C01","src":"hb","mqttCd":-2,"state":true,"scene

The Wiz app quickly registered the bulb's state change to purple.

Given how easy these were to work with, I picked up a few more.  Using cron, I could easily schedule the bulb to turn on and off and change its color, and I could delete the sketchy Wiz app from my phone.  These bulbs were exactly what I wanted.

Don't get me wrong, I care about security.  However, I keep the bulbs on a separate VLAN with no internet access and I block their MAC addresses from the internet at my firewall.  I also block internet access to the Wiz phone app, and I only installed it on an old phone I no longer use.

When first provisioned with the phone app, the bulbs appear to fetch a firmware update.  It's possible that by the time you read this the vendor will have updated the firmware to eliminate the security holes.  I doubt it will happen, but if you want to keep the old, vulnerable firmware you might want to block internet access on your provisioning subnet.

Phoning Home

These bulbs try to "phone home" to a host called "taolight.helpshift.com".  Taolight seems to be the firmware maker for these Philips-branded bulbs. I haven't fully analyzed the TCP traffic, but it seems the bulbs need to register with the outside network to enable things like Alexa communication (which I don't need).

The bulb also does regular DNS lookups on the host "mqtt.wiz.world."  I assume it's sending data to this host about its state and looking for new commands from services like Alexa.

21:39:56.662791 IP (tos 0x0, ttl 255, id 624, offset 0, flags [none], proto UDP (17), length 60)
    10.20.6.75.49153 > dns.google.53: [udp sum ok] 0+ A? mqtt.wiz.world. (32)
E..<.p....v.,..K.......5.(...............mqtt.wiz.world.....

A strategy to avoid phoning home is to add these hosts to your local DNS server's host lookup section (if using dnsmasq, for instance) and set them to resolve as 0.0.0.0.  For this to work you'd need to intercept DNS queries.

While I find the bulbs very useful for my purposes and I hope to be able to keep buying them, I also think Philips should do the responsible thing and address these wide-open security vulnerabilities.  At the very least the packaging should include a warning that the device can easily be taken over by a novice hacker.  It is brazen that a company would release an internet-connected product with absolutely no effort at security.

For more information on protecting yourself against untrusted devices, see my other article on IOT Device Security.

Update 11/4/2019

I've submitted a CVE request for this product to hopefully get an official bulletin about these vulnerabilities.

This image is from the company's website.  The site tries hard to make it appear as if these products are secure.  The most comical part is the bit about each bulb having its own unique password.

That may well be true, but passwords do fuck-all good if there's no authentication, as is the case here.  I'm willing to bet these passwords are a simple hash based on the bulb's MAC address.

The device contains an Espressif IOT Module ESP WROO M02D, for which the manual is located here.

During the manual Wiz app discovery and configuration process the device creates a wifi access point with the name WiZConfig_abcd where the last 4 characters are the last 4 bytes of the main wifi MAC address.  This AP appears with a different MAC than the device uses when it connects to an access point.  You can put the light into manual pairing mode by turning it on and off 5 times.

I'm attempting to capture traffic between the app and the light bulb to see how the setup API works.  The WiZConfig access point assigns an address like 192.168.56.100 to a connecting device, and gives 192.168.56.1 to the bulb itself.  A scan of the bulb shows port 80 is open, but I have not been able to find any endpoints there yet.  It's possible the bulb accepts UDP traffic as well, but I haven't verified this.

Update 11/25/2019 - CVE Created

When I initially found these vulnerabilities in early October, I immediately contacted the vendor at their publicly listed security email address (available on their website).  I waited several weeks and, upon getting no response, I submitted a CVE request.

The CVE has been published here.