Smart homes rely on security devices. Fuzzing exposes 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 any changes around you? Take a moment to think about your home. How many connected devices can you name? The wireless router is the most obvious. Televisions and other entertainment devices are, of course, connected to the network 24 hours a day, 7 days a week. You may also have part of your home’s lighting system and some wirelessly controlled electrical outlets. But beyond comfortable lighting, you’ve probably invested in the convenience of remote heating or air conditioning, perhaps a vacuum cleaner or lawn mower. Home is a place where you want to be safe, so perhaps you have a CCTV system, a video doorbell, and a suite of wireless sensors to detect motion, temperature, leaks, and smoke detectors. If you have kids or pets, you’ve probably added other health monitoring devices to your list. How many connected devices do you have in total? A quick survey conducted by the Defensics office yielded an average of 21 devices, ranging from 5 to 60.
A smart home is a home with networked appliances and devices that can be controlled and controlled remotely. But there is no official list of smart home devices, so many people don’t really use the full power of smart devices to automate their home – even though smart smart devices still exist and the devices can be connected to the internet or other devices. devices. Typically, there are three types of connected devices in a home:
Smart devices are often connected to a device provider’s cloud, each with a smartphone app to control the device and create automation. This leads to one of the pain points of smart home automation, as devices from different vendors do not interact with each other, but with the solutions of a particular vendor. In addition, different devices communicate using different wireless protocols. This is why issues of device interoperability and reliability become more important as the network of devices within the home grows.
The choice of protocol for smart devices often depends on bandwidth, range, and topology requirements. Less bandwidth usually means less power consumption, which is critical for battery powered devices. The most widely used wireless protocols are listed here:
The Matter Smart Home Standard is the industry’s ongoing effort to create a smart home technology standard that enables secure, reliable, and uninterrupted communications between smart home devices, mobile apps, and cloud services. The standard does not define new wireless technologies, but rather standardizes at the IP layer over selected transport layers (Ethernet, WLAN, and Thread). In addition to using Bluetooth to set up Matter-enabled devices, Bluetooth LE is also likely to be enabled in the future.
You can forgive the reliability issues with the latest digital devices, but that’s not the case with light bulbs. There is a long checklist to follow when creating a secure and reliable connection on your home network, and one thing to keep in mind is that when more devices are connected in your home, the radio signals don’t stop at the wall. Even if your device does not normally communicate with your neighbor’s device for home automation reasons, the radio network may overlap. This could pose a security risk if an attacker finds a way to propagate code between overlapping networks, but it’s obviously a problem for reliable communications.
Many hardware vendors include hardware in protocol-specific certification programs to improve interoperability. Certification tests are primarily functional tests that provide valid input and compare the output against the correct or expected values. Functional tests check that everything works under normal conditions, but what if someone posts nonsense or out of order?
Fuzzing or fuzzing is an automated software testing technique that injects invalid, garbled or unexpected data into a system in order to reveal software flaws and vulnerabilities, making it an adjunct to functional testing. Fuzzing is a proven testing technique for identifying security, reliability, performance, and other quality issues in test items. When the goal is to have a secure and reliable communication device, you cannot ignore the power of fuzzing.
Our Defensics team has over 15 years of experience obfuscating wireless networks. We found and reported several vulnerabilities, but we saw even more issues where a single unauthenticated protocol message caused a test target to fail. After a crash, some devices will reboot on their own, but some require the power cord to be unplugged to resume normal operation. Smart home devices can be located in hard-to-reach places or in large numbers. For example, we’ve seen smart bulbs fall out of the mesh network due to fuzzing, so you can imagine the effort it took to restore the network for all the lights in your home. In the worst case, obfuscated data can bypass network security mechanisms and inject data into the network. In this case, attackers can easily infect wireless networks with drones from the street or from the air, and in the worst case, from one network to another. Attackers can use vulnerabilities, such as information leaks discovered through obfuscated wireless protocols, to gain access to home networks from smart devices and then provide backdoor access from the Internet.
Corrupted wireless frames can be the result of a cyberattack, but can also come from nearby devices with different interpretations of the protocol specification, coding errors, or hardware failures. The problem is caused not only by corrupted data, but also by logical errors, such as an error in the code that processes the protocol data. A model-based, protocol-aware fuzzing tool will check the minimum and maximum values of each field in the protocol with all checksums, lengths, and encrypted messages made according to the protocol specification.
Often vendor-specific data needs to be added to the protocol to provide additional functionality. Some protocols provide mechanisms for this, but sometimes provider-specific data is appended to actual protocol messages and may be added to protocol-reserved blocks or to the end of valid structures. Usually the extra data is not a problem because the other devices don’t know and don’t process the extra data, but if both providers use aliasing, they may be able to process extra data that isn’t valid for them. The same happens when the protocol specification is updated and the extra data overrides the new data area of the updated protocol specification. Even without extensions, different protocol versions and adaptation errors increase the risk of meaningless data appearing on the network.
Another example is a hardware failure. The sensors report temperature, humidity, and barometric pressure, and each value is a 32-bit number, so the message must contain all three values. Suppose the air pressure sensor suddenly stops responding. The sensor code can report 0×00000000, 0xFFFFFFFF to the network, or remove a value from the message. Is the code processing the sensor values prepared for all these possibilities? Because the air pressure should never be zero, a divide-by-zero accident can occur.
A common mistake is to use signed types for unsigned values when unsigned max leads to unexpected situations. Duplicate or missing data can also lead to unhandled situations in code. Similarly, a protocol-enabled fuzzer can check for all of these conditions before the sensors in the network break down.
The industry is currently working to ensure that all devices communicate seamlessly with each other, which is good for consumers but results in large networks containing a mixture of devices from different vendors. From a device point of view, you cannot trust the quality of devices on the same network. Imagine a situation where a well-known brand offers a lightweight gateway starter kit and a consumer expands it with another device. The branded device became unstable due to unexpected data in the protocol, while the non-branded one worked fine. It is important to make sure that the devices work in all contingencies in a network with a set of different devices.
Defensics is a comprehensive, robust, automated black box solution that supports most smart home and IoT wireless protocols, as well as over 300 other protocols. Defensics is a generational fuzzer that knows the protocol you are testing. All of our over-the-air tests can be done over-the-air (OTA) on a boxed device without access to the source code. If you’re interested in integrating fuzzing into your CI/CD pipeline, Defensics allows you to integrate headless tests with a Jenkins plugin, CLI, and REST API. All three integrated interfaces provide basic workflows for setting up fuzzers, running and tracking test progress, and exporting test reports.
If you want to implement a secure and reliable smart home device, you must include protocol fuzzing on your checklist, and with Defensics, you can tick that checklist.
*** This is a syndicated Security Blog Network blog from Kari Halkko’s Application Security Blog. Read the original article: https://www.synopsys.com/blogs/software-security/smart-home-fuzzing-defensics/
Post time: Oct-19-2022
