CVE-2018-3834
An exploitable permanent denial of service vulnerability exists in Insteon Hub running firmware version 1013. The firmware upgrade functionality, triggered via PubNub, retrieves signed firmware binaries using plain HTTP requests. The device doesn’t check the kind of firmware image that is going to be installed and thus allows for flashing any signed firmware into any MCU. Since the device contains different and incompatible MCUs, flashing one firmware to the wrong MCU will result in a permanent brick condition. To trigger this vulnerability, an attacker needs to impersonate the remote server “cache.insteon.com” and serve a signed firmware image.
Insteon Hub 2245-222 - Firmware version 1013
http://www.insteon.com/insteon-hub
8.7 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
CWE-284: Improper Access Control
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.
To enable remote interaction via the Internet, Insteon Hub uses an online service called PubNub (https://www.pubnub.com/). End-users install the “Insteon for Hub” application on their smartphone. Both the smartphone application and Insteon Hub include the PubNub SDK, which allows for a bi-directional communication using PubNub’s REST API.
Using the phone application, an user can decide to force an update. In this case, the phone will first retrieve the latest firmware for a given device using an HTTP GET request:
# phone --> connect.insteon.com:443
GET /HubService/Firmware?HubID=112233 HTTP/1.1
# connect.insteon.com:443 --> phone
[{"FW":"FW","Url":"cache.insteon.com\/software\/insteon\/hub2\/prod\/PROD_FW_03_33_1013.hex","Version":"1013","DevCat":"03","SubCat":"33"},{"FW":"PLM","Url":"cache.insteon.com\/software\/insteon\/hub2\/prod\/PROD_PLM_03_33_A3.hex","Version":"A3","DevCat":"03","SubCat":"33"}]
The answer contains the URL for the firmware in Intel HEX format. In this case there are 2 of them: one for the main PIC32MX MCU (“FW”) and one for the “PLM”.
The phone will then communicate with the device via PubNub, asking to perform a firmware update using the FW URL.
# phone --> pubsub.pubnub.com:443
GET /publish/pub-c-a415cc66-b0ca-4d1d-8d9e-947390b35df3/sub-c-e1c54032-1685-11e4-b69f-02ee2ddab7fe/0/112233-ad/0/{"u":"\/software\/insteon\/hub2\/prod\/PROD_FW_03_33_1013.hex","msgid":"1234567890-3","cmd":"up_firm","ser":"4","h":"cache.insteon.com"}?&auth=11223344556677889900AABBCCDDEEFF
# pubsub.pubnub.com:443 --> phone
[1,"Sent","1234567890"]
When the device receives this message, it will fetch the firmware using a plain HTTP request to “http://cache.insteon.com/software/insteon/hub2/prod/PROD_FW_03_33_1013.hex”.
The device will then perform a signature check on the firmware, and if this check passes, the firmware will be flashed.
There is no check on the kind of firmware (“FW” or “PLM”) that is going to be flashed: both the “FW” and the “PLM” .hex files are signed with the same private key, and thus the signature check can’t help with discerning between the two. No further checks are performed on the firmware image, which is saved on an external SPI flash.
So, if the “PLM” firmware is served in place of the “FW” one, the device will not notice it and it will try to flash the “PLM” firmware into the PIC32MX MCU. Upon reboot, if a firmware is ready to be flashed from the SPI, the internal flash will first be erased and then the firmware will be written. Since the addresses specified in the “PLM” firmware are not compatible with the PIC32MX MCU, the flashing routine will exit, leaving the main MCU in a completely erased state.
An attacker which is able impersonate the HTTP server for “cache.insteon.com” (e.g. via MITM) would be able to serve any “PLM” firmware image when a “FW” firmware is requested, effectively bricking the device permanently.
2018-01-16 - Vendor Disclosure
2018-01-18 - Vendor advised issues under evaluation
2018-02-12 - 30 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-06-19 - Public disclosure
Discovered by Claudio Bozzato of Cisco Talos.