CVE-2019-5035
An exploitable information disclosure vulnerability exists in the Weave PASE pairing functionality of the Nest Cam IQ Indoor, version 4620002. A set of specially crafted weave packets can brute force a pairing code, resulting in greater Weave access and potentially full device control. An attacker can send specially crafted packets to trigger this vulnerability.
Nest Labs Nest Cam IQ Indoor version 4620002
https://store.nest.com/product/nest-cam-iq/NC3200US
9.0 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-307: Improper Restriction of Excessive Authentication Attempts
The Nest Cam IQ Indoor is one of Nest Labs’ most expensive and advanced devices. The surveillance camera integrates with Google Assistant, contains facial recognition technology and even has the ability to act as an 6lowpan hub for other less powerful internet-of-things devices. The main protocol that is used for setup and initial communications of Nest devices is Weave, a protocol designed strictly for IoT devices, which can run over TCP, UDP, Bluetooth and 6lowpan.
Before going into the details of the bug itself, a quick overview of the Weave protocol and terminology is needed, so for brevity, here’s a packet dissection of a sample weave packet that will be relevant later on:
--------TCP Message Layer----------- //[1]
Mesage_Length : 0x0146
Message Version : 0x1
Message_Id : 0x00000004
Message_Flags : 0x0300 : [ Dstnode|Srcnode ]
Src_Node : 0000000000000002
Dst_Node : 0000000000000001
Encryption : None
--------Exchange Layer----------- //[2]
Exchange Ver|Flag : 0x11 : [ Initiator ]
Exchange MsgType : 0x1 : kMsgType_PASEInitiatorStep1 //[3]
Exchange ExchangeID : 0x70e3
Exchange ProfileID : 0x00000004 : kWeaveProfile_Security //[4]
--------Data Layer----------- //[5]
kMsgType_PASEInitiatorStep1
controlHeader: 0x8011213f
sizeHeader: 0x01070e0e
ProtocolConfig: 0x235a0004
AltConfig[0]: 0x235a0001
gx: 0xe, zkpxgr: 0xe, zkpxb: 0x7
step1.p1.gx: \x26\x79\x13\xe9\x91\x07\xd8\x95\xd2\xda\xa5\xb9\xc3\x63\x69\xb3\x63\xfa\x8f\x8a\x38\x96\x44\xd3\x60\x7e\x39\xbc\x3b\xc9\xb0\x1f\x0d\x3a\x56\x0a\x9f\x45\x83\x40\x26\x56\x0a\x8c\x1b\xbf\xba\x0e\xed\x61\x7a\x98\xc1\x60\x68\x22
step1.p2.gx: \x9e\x61\x2e\xc7\x06\x33\x48\xb6\xbd\xfd\xc1\x60\x85\xed\x3f\xa1\x25\xc1\x91\x9c\x6b\xe9\x7e\xd6\x06\x5c\x66\x3b\xe3\x36\x23\x45\xaa\xea\x6e\x12\x87\x68\xa4\x43\x0d\xa5\xd3\x42\x72\x28\x04\x25\x34\x5b\x0a\x30\x41\x00\xa5\x22
step1.p2.zkpx.gr:
\x1e\x22\x9a\x94\x67\x36\x88\xc4\x29\xa3\x57\xd3\xbd\xb7\x6a\xee\xba\x17\xc8\x19\xaf\x11\x89\xa3\xc1\x7d\x08\xff\xe5\x65\xd0\x74\xc3\x26\x8d\x20\x83\xe0\x81\x9a\x69\x7e\x67\xe6\x40\xc1\xcc\x83\xe7\x55\x27\x63\x63\x0f\x71\x7d
step1.p2.zkpx.b: \x38\x07\x74\x4e\x85\x3e\x9a\x2c\x97\x31\x16\xf7\x88\x86\xd8\xa4\x81\x70\xaf\x9b\x72\xf8\x56\x5a\x67\xc4\x15\x7d
step1.p2.zkpx.gr: \xd3\x0d\x93\x9e\x3b\xe1\x2f\x33\xf2\x80\xb9\x27\x78\x74\xf4\xda\xdf\x90\xeb\x5a\xee\x77\x86\x9b\x44\x37\x13\x55\x83\x9d\x35\x01\x49\xb5\xa7\x61\x06\xa8\x9d\x47\x4b\x76\xca\xbc\xf5\x97\xc4\x83\xf2\x93\x93\x7f\xb1\xec\x16\x27
step1.p2.zkpx.b: \xeb\xe9\x8c\x3a\x99\x5a\x61\x5f\xe0\x76\x5c\xae\x06\x55\xda\x5c\x45\xca\xc5\x54\x55\xd3\x22\x74\x85\x76\xdd\x0e
Weave messages consist of three layers: message, exchange and data. The message layer [1] and exchange layer [2] are both variable sized and consist of little-endian fields as listed above. The Data Layer [5] is strictly dependent on the MessageType [3] and ProfileId [4], and every combination thereof generally has a unique message structure, which can be seen from all the parsed fields below [5]. The ProfileID is fittingly used to determine which Weave “Profile” to talk with, and likewise, the MessageType is essentially the opcode for the given Profile.
Turning back now to the vulnerability, when initially setting up any Nest device, the owner typically looks for a QRcode or a six-digit/letter code somewhere on the device which is then used as a shared secret for JPAKE authentication in the pairing process. Normally, due to the processing time required to do a single round of JPAKE authentication, the fact that JPAKE must be done online, and also the key space of six alphanumeric characters, it would be unreasonable to brute force this process, even though there is no tracking of failed authentication attempts.
Interestingly though, it turns out that the six-digit codes used by Nest are actually Verhoeff base32 checksum values. This allows a device owner to know if they typed their code in wrong, as their phone will quickly check to see if the code is a valid Verhoeff number. Regardless, this takes the key space down from 1073741824 (32^6) possible entries to 33554432 (32^5), a factor of 32 and a slightly more reasonable runtime.
When benchmarking this process, by utilizing the default WeaveDeviceManager’s PASE pairing in a loop, we can get ~100 iterations per 1.3 seconds against the device, which would allow for a full key space brute force in around one month. By writing a python implementation of the PASE pairing setup, we were able to speed up runtime, as the WeaveDeviceManager sends extra identification packets that were not necessary. Interestingly though, it seems that the main bottle neck to this is actually the Nest Camera itself, as it can only process network packets in a single threaded manner.
While needing to communicate with a device for three to four weeks might be unreasonable for brute forcing, the pairing code will stay the same for a given device across reboots, and also, if the device is ever in a non-configured state when the code has been discovered, an attacker can emulate the pairing process and add the device to their own Nest account, granting full access.
If the device is already in a paired state when an attacker authenticates with the pairing code, it is dependent on a device-to-device basis on what types of weave requests the attacker would now be authenticated to send.
2019-04-18 - Vendor Disclosure
2019-05-20 - Vendor completed analysis
2019-06-18 - Follow up with vendor
2019-07-02 - 90 day notice; Vendor advised updates scheduled for release mid-July
2019-07-18 - Vendor advised fix will release end of July and be tested in the field
2019-07-26 - Extended disclosure date to 2019-08-15
2019-08-19 - Public Release
Discovered by Lilith Wyatt and Claudio Bozzato of Cisco Talos.