Smart home under fuzzing

Smart homes rely on secure devices. Fuzz testing identifies software vulnerabilities in smart devices by fuzzing wireless and IoT protocols.

The Internet of Things (IoT) has been a buzzword for years, but have you noticed that something has changed around you? Take a moment to think about your home. How many connected devices can you name? Wireless router is the most obvious one. TV and other entertainment devices are naturally online 24 hours a day, 7 days a week. You might also have a part of your home’s lighting system and some electric sockets controlled wirelessly. In addition to the comfort lighting, though, you might have invested in convenience with remote controllable heating or air conditioning, maybe a vacuum cleaner or a lawn mower. Home is the place where you want to be safe and secure, so maybe you have a video surveillance system, a video doorbell, and a set of wireless sensors to sense motion, temperature, leakage, and smoke detectors. If you have a baby or pets, you might have added some other devices to the list to monitor their well-being. How many connected devices do you have all together? A quick poll in the Defensics office gave 21 devices on average, with a range from 5 to 60.

Home network topology

A smart home is a house that is equipped with connected appliances and devices that can be monitored and controlled remotely. But there is no official list of smart home devices, so many people aren’t actually utilizing the full capability of smart devices for home automation – the smart intelligence is still there, though, and a device might be connected to the internet or to other devices. There are typically three types of connected devices at home:

• Devices connected directly to the internet via a (wireless) router at home
• Devices connected to a smartphone, which is connected to the internet
• Devices connected to each other and to a gateway, which is connected to the internet

Together, these devices combine to form the home network topology shown in Figure 1.

A smart device is typically connected to the device vendor’s cloud, with a smartphone application from each vendor to control the device and to build the automation. This causes one of the smart home automation pain points as the devices from different vendors aren’t communicating with each other but with vendor-specific solutions. In addition, different devices use different wireless protocols for that communication. This is why device interoperability and reliability problems have become more critical with the growth of device networks inside the home.

Wireless protocols at home

Protocol selection for a smart device is typically based on needs for bandwidth, range, and topology. Smaller bandwidth usually means smaller power consumption, which is critical for battery-powered devices. The most widely used wireless protocols are listed here:

• Wi-Fi/WLAN. Wireless LAN provides an internet connection for all home devices with ultra-high-resolution video-level streaming bandwidth. If one router is not able to cover the whole house, multi-router mesh solutions are available. Most devices with high bandwidth requirements and no power constraints select WLAN for the communication protocol.
• Bluetooth. The strength of Bluetooth is that all smartphones support the protocol, thus most devices directly communicating with a mobile phone use it. There are two types of Bluetooth devices: Classic and Low Energy (LE). Bluetooth Classic is mostly used for audio use cases, like streaming music to a speaker. Bluetooth LE is more commonly found in sensors, like temperature-monitoring sensors broadcasting data for everyone or health and wearable devices connected to the smartphone. Bluetooth LE also supports mesh networks, with lighting solutions also available. It offers a smartphone-assisted method to set up and configure a device in a home network even after initial setup and the device uses different protocols on network communication.
• Zigbee. This low-cost, low-powered mesh network is widely deployed for controlling and monitoring applications like lighting, plugs, security sensors, and locks. Unlike WLAN devices (which communicate with the internet) and Bluetooth devices (which communicate with smartphones), Zigbee devices communicate with each other. A gateway device is needed to allow the devices to communicate with the internet.
• Thread. Thread protocol is used for the same purpose as Zigbee, the main difference is that Thread devices are IPv6 addressable and can speak to the internet (and each other) via native IP. For this reason, Thread is selected for low-layer transport protocol in the new Matter standard.

About the Matter Smart Home Standard

The Matter Smart Home Standard is an ongoing industry push to create a smart home technology standard that provides secure, reliable, and seamless communication across smart home devices, mobile apps, and cloud services. The standard doesn’t define a new wireless technology but rather an IP-level standardization on top of selected transport layers, which are Ethernet, WLAN, and Thread. Bluetooth LE will also most likely be included in the future, in addition to using Bluetooth to set up Matter-supported devices.

Secure and reliable communication with fuzz testing

You can forgive reliability issues with the latest digital gadget, but the same doesn’t apply to a lightbulb. There is a long checklist to go through when creating secure and reliable communication on the home network, and one thing to note is that with more and more connected devices at home, radio signals do not stop at the walls. Even if your devices don’t typically communicate with your neighbors’ devices for home automation reasons, the radio networks overlap. This might be a security risk if an attacker finds a way to propagate code between overlapping networks, but obviously this is a challenge for reliable communication.

Many device vendors are taking devices to protocol-specific certification programs to increase interoperability. The certification testing is mostly functional testing, which provides valid inputs, and the output is compared to a correct or expected value. Functional testing verifies that everything works correctly under normal circumstances, but what if someone sends inputs that make no sense or are out of order?

Fuzz testing or fuzzing is an automated software testing method that injects invalid, malformed, or unexpected inputs to a system to reveal software defects and vulnerabilities, making it complementary to functional testing. Fuzzing is a proven test method to discover security, reliability, performance, and other quality issues in the test target. When aiming to have a secure and reliable communication device, you cannot ignore the power of fuzzing.

Our Defensics team has more than 15 years of experience in fuzzing wireless networks. We have found and reported several vulnerabilities, but we’re seeing even more issues when a single, unauthenticated protocol message causes a test target to fail. After the failure, some devices restart themselves, but some need power cable removal to return to a functional state. Smart home devices might be located in places without easy access, or there might be a huge number of them. For example, we have seen smart bulbs dropping from the mesh network as a result of fuzzing, so you can imagine the effort to rebuild the network for all the lights in your house. In a worst-case scenario, the fuzz data can bypass the network protection mechanisms and inject data into the network. In such a case, a malicious attacker can easily pollute wireless networks from the street or with a drone from the air, and in the very worst case, from one network to another. The attacker can utilize vulnerabilities such as information leakage found by fuzzing a wireless protocol to get access from a smart device to the home network and then provide backdoor access from the internet.

Robustness in unexpected conditions

A malformed wireless frame can be the result of a cybersecurity attack, but it can also appear from a neighboring device that interprets protocol specifications differently, has a coding error, or has a hardware malfunction. Problems are caused not only by malformed data but by logic errors such as off-by-one error in the code handling the protocol data. A model-based, protocol-aware fuzz testing tool will test the minimum and maximum values for each field in the protocol with a message that has all the checksums, lengths, and encryption done according to protocol specification.

It is often necessary to add vendor-specific data to a protocol to provide extra functionality. Some protocols give mechanisms for this, but sometimes the vendor-specific data is piggybacked on a valid protocol message and can be added into protocol-reserved blocks or at the end of a valid structure. Usually, the additional data is not a problem as other devices are not aware of the additional data or are not handling it, but if both vendors are doing the piggybacking, they might handle additional data that isn’t valid for them. The same situation occurs when a protocol specification is updated, and the additional data overlaps with new valid data areas of the updated protocol specification. Even without extensions, different protocol versions and adaptation errors add risk to having nonsense data appear on the network.

Another example is a hardware malfunction. A sensor reports temperature, humidity, and air pressure, and each value is a 32-bit number, so one message should have all three values. Let’s say an air pressure-sensing component suddenly stops answering. A sensor code can report to network 0x00000000, 0xFFFFFFFF, or leave the value out from the message. Is the code handling the sensor value prepared for all these possibilities? There might be a divide-by-zero crash since air pressure should never be zero.

One typical mistake is to handle unsigned values with signed types when unsigned maximum values lead to unexpected situations. Repeated or missing data can also lead to unhandled situations in code. Again, a protocol-aware fuzzer can test all these conditions before there is a broken sensor in the network.

In the table below, the maximum value can cause two types of problems:

1. The value is read to a signed variable and gets a negative
2. The value is used in calculations leading to integer overflow (value=VALUE_MAX+1) or underflow (value=VALUE_MIN-1).

The industry is now making an effort to have all devices communicate seamlessly with each other, which is good for consumers but leads to large networks with a mixed set of devices from different vendors. From a device perspective, you cannot trust device quality in the same network. Imagine a situation where a well-known brand provides a light gateway starting kit, and the consumer extends it with a non-brand device. Brand devices are becoming unstable due to the unexpected data in the protocol, but the non-brand device works perfectly fine. It’s important to ensure that devices work in all unexpected conditions in a network with a mix of different devices.

Defensics fuzz testing

Defensics is a comprehensive, powerful, and automated black-box solution supporting most smart home wireless and IoT protocols, in addition to more than 300 other protocols. Defensics is a generational fuzzer that knows the protocol you’re testing. All our wireless testing can be done over-the-air (OTA) against a boxed device without the need for source code access. If you are interested in integrating fuzz testing into your CI/CD pipeline, Defensics allows headless test integration via a Jenkins plugin, CLI, and the REST API. All three integration interfaces allow a basic workflow of configuring the fuzzer, running and tracking test progress, and exporting test reports.

If you want to implement a secure and reliable smart home device, you must have protocol fuzz testing on your checklist, and with Defensics, you can add a checkmark to that list.