F-Secure

Connections initialized by the AWS IoT Device SDK v2 did not verify server certificate hostname during TLS handshake when overriding Certificate Authorities (CA) in their trust stores on Windows. This issue has been addressed in aws-c-io submodule versions 0.9.13 onward.

Connections initialized by the AWS IoT Device SDK v2 did not verify server certificate hostname during TLS handshake when overriding Certificate Authorities (CA) in their trust stores on MacOS. This issue has been addressed in aws-c-io submodule versions 0.10.5 onward.

The issue arises from the AWS IoT Device SDK v2 appending a user-supplied Certificate Authority (CA) to the root CAs instead of overriding it on Unix systems. This allows TLS handshakes to succeed if the peer can be verified from either the user-supplied CA or the system's default trust-store. Attackers with access to a host's trust stores or who can compromise a certificate authority already in the host's trust store may use this to bypass CA pinning, potentially spoofing the MQTT broker and dropping or responding with attacker's data. However, they cannot forward this data to the MQTT broker without the user's private keys.

The AWS IoT Device SDK v2 for Java, Python, C++, and Node.js appends a user-supplied Certificate Authority (CA) to the root CAs instead of overriding it on macOS systems. Additionally, SNI validation is also not enabled when the CA has been "overridden". This allows attackers with access to a host's trust stores or who can compromise a certificate authority already in the host's trust store to bypass CA pinning. An attacker could then spoof the MQTT broker, drop traffic, and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker.