An exploitable denial of service vulnerability exists in Insteon Hub running firmware version 1012. Leftover demo functionality allows for arbitrarily rebooting the device without authentication. An attacker can send an UDP packet to trigger this vulnerability.
Insteon Hub 2245-222 - Firmware version 1012
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-489: Leftover Debug Code
Insteon produces a series of devices aimed at controlling and monitoring a home: wall switches, led bulbs, thermostats, cameras, etc. One of those is Insteon Hub, a central controller which allows an end-user to use his smartphone to connect to his own house remotely and manage any other device through it. The Insteon Hub board utilizes several MCUs, the firmware in question is executed by a Microchip PIC32MX MCU, which has a MIPS32 architecture.
The firmware uses Microchip’s “Libraries for Applications” as core for the application code. Its functionality resides on a co-operative multitasking loop, which continuously executes all the existing tasks: the library already defines several tasks, e.g. for reading and sending network packets and calling the relative callbacks. Custom applications building on this library simply need to add new functions at the end of the loop, taking care of executing tasks as quickly as possible, or splitting them in several loop cycles, in order to let other tasks running smoothly.
One of the default tasks defined by Microchip’s “Libraries for Applications” is called “RebootTask”: this is a simple demonstrative tasks that checks for incoming UDP messages on port 69 and reboots the device when any packet is received.
An attacker can exploit this vulnerability by continuously sending UDP packets on port 69, keeping the device always unreachable.
The following proof of concept shows how to reboot the device.
$ echo | nc -u $INSTEON_IP 69
2017-11-27 - Vendor Disclosure
2017-11-28 - Vendor Acknowledged
2018-01-02 - 30 day follow up with vendor for status
2018-01-18 - Vendor advised issues under evaluation
2018-02-12 - 60 day follow up with vendor
2018-03-09 - Vendor advised working on course of action
2018-04-06 - Follow up with vendor on fix/timeline
2018-04-12- Vendor advised issues addressed & plan for beta testing
2018-04-20 - Public disclosure
Discovered by Claudio Bozzato of Cisco Talos.