This is Part 2 of a 3-part series on IoT Wireless Security Vulnerabilities & Solutions. See a video overview here. A significant portion of this series originates from a white paper published earlier this year with technical contributions from security researcher colleague RJ Brownlow. The white paper was expanded upon and customized for a technical paper and presentation for the 2016 SCTE/ISBE conference and is highlighted in the video link above.
- Part 1 – Introduction, IoT Impacts, and Technology Briefs
- Part 2 – Attack Vectors and Scenarios (below)
- Part 3 – Tools and Combating Security Vulnerabilities
Security Attack Vectors & Scenarios
For an introduction and technology briefs be sure to view the link to Part 1 above. The following post will dive right in to highlight 3 potential attack scenarios based on key manipulation. These scenarios represent attack vectors, or methods used by criminals to exploit IoT devices. While these methods require some expertise and time to execute, they are representative of the degree common home systems can be compromised. Note that I have blurred sensitive areas on photos and have omitted some detailed descriptions to avoid adding to the problem.
1. Executed Attack Scenario 1: Network Authentication Key Establishment
The use of pre-installed keys can be manipulated by the host/controller sending key manipulation data over the air (OTA) without actually dispensing keys. This works by each node on the network having a copy of several keys (32 being standard) with a key manipulation algorithm also being inherent to each node. The controller then sends the key manipulation data to each device with both the controller and node executing the command simultaneously. The final step is for the controller to check the value produced by the node against its own and authorize communication.
Figure 6 – Disassociation/De-authorization attack diagram
This key establishment scheme can be easily manipulated by the use of a De-Authorization attack. The node being detached is programmed to accept the network key established by the gateway.
Once disconnected, the node will attempt to reestablish connection with the designated host but in many cases will default to the first host it finds.
Figure 7 – Z-Wave node attempting to connect with host/controller
As seen above, the node also sends the data associated with its last known host. Although encryption is in place, it’s possible (but ineffective due to timing constraints and the use of low power transmissions) to simply record the key set message and extract the key from there. Due to the used encryption, it is also possible and feasible to calculate all necessary keys from captured packets
Once connected to the host (in this scenario, a laptop spoofing the controller) it will accept the key and any subsequent commands from its new host. In the screenshot below, the attacker uses this to send Set Key and Unlock commands to the door.
Figure 8 – Attacker sending commands to override the door
2. Executed Attack Scenario 2: Physical Key Extraction via Device Firmware
By default, keys are stored in every node of the network and can be extracted from the factory firmware by way of the debugger interface. In this exercise, a Z-Wave thermostat (manufacturer withheld), common of the shelf (COTS) flash programmer, factory development kit software tools and jumper wires are used to dump the firmware with a Serial to universal serial bus (USB) interface.
Figure 9 – Opened thermostat with debug access and USB debugging tool
Once accessed and dumped, the manufacturer’s development kit can be used to decode the firmware code into plain text as seen below (keys blurred intentionally).
Figure 10 – Screenshot of the IDE displaying the encryption key in plain text
3. Executed Attack Scenario 3: OTA Key Transport Interception
In this authorization scheme, keys are transported directly to devices over-the-air requesting to access the controller. The node sends a beacon broadcast to all devices in range (seen in red below), essentially looking for any network to join. The responding controller sends an acknowledgement and confirmation of availability (green). The node acknowledges receipt and requests a key to access the controller as a network resource (yellow). The controller responds with the network key and the node is added to the network (white-cropped out intentionally). This entire transaction is sent in clear text and can easily be extracted by wireless sniffing methods.
Figure 11 – The network coordinator sends the key in plain text to devices looking to join the network. Once acknowledged, all subsequent communication is immediately encrypted
As you can see, serious hackers have been able to exploit modern wireless connected solutions using several common methods that have been in use for years. Hackers look for the easiest targets with the highest payout so they may or may not take the time to exploit new connected solutions. One thing is clear though, there is significant exposure to potential data theft, compromised devices, unwanted break-ins, and possible physical harm. It’s important for all parties in the ecosystem to collaborate on end-to-end solution security and to include it in early design to prevent catastrophe.
Stay tuned for Part 3 – Tools and Combating Security Vulnerabilities of this 3-part series. The final segment will deep dive into off the shelf tools used by security researchers and professionals to diagnose and prevent attacks. The final segment will also offer methods for reducing risk, an example case study, and wrap up with a point of view.