The proliferation of Internet of Things (IoT) devices has undoubtedly transformed our lives, providing convenience and connectivity across multiple domains. As the utility of these devices increases, so does the amount of data exchanged between embedded systems and the infrastructure that supports them. Securing these communication channels is generally considered "table stakes" from a security perspective, but RedSquall continues to see IoT devices that are susceptible to Man-in-The-Middle (MiTM) attacks.
The Mbed TLS library is one of the most common cryptographic frameworks we see in IoT devices to establish TLS connections. Mbed TLS supports certificate verification as part of the TLS handshake, but we continue to see it implemented incorrectly. This article will detail our observations of the misuse of this library leading to MiTM vulnerabilities.
Mbed TLS Primer
Mbed TLS is an open-source C library implementing multiple cryptographic protocols, including SSL/TLS and X.509 certificate handling, which will be the focus of this article. Mbed TLS is frequently utilized in IoT devices, embedded systems, and applications that demand secure communication and cryptographic operations. Its popularity stems from its open-source design, reliable functionality, and emphasis on resource efficiency, making it an ideal option for implementing secure communication in resource-constrained products.
Using Mbed TLS to establish secure connections requires quite a bit of initialization; the following guide provides a great tutorial.
The specific function we want to examine is mbedtls_ssl_conf_authmode.
void mbedtls_ssl_conf_authmode(mbedtls_ssl_config * conf,int authmode)While mistakes in other parts of the initialization workflow could undoubtedly result in insecure connections, this function has been the primary reason MiTM is possible in our observations. This function is where the TLS session's certificate verification mode is configured. The function takes 2 arguments, the second being "authmode," which can be one of three values:
MBEDTLS_SSL_VERIFY_NONE: peer certificate is not checked
MBEDTLS_SSL_VERIFY_OPTIONAL: peer certificate is checked; however, the handshake continues even if verification fails
MBEDTLS_SSL_VERIFY_REQUIRED: peer must present a valid certificate; the handshake is aborted if verification fails.The necessary certificate trust chains must be installed on production IoT devices to allow them to validate a peer certificate chain. The MBEDTLS_SSL_VERIFY_REQUIRED argument should always be used by devices when creating a TLS session. If this option is not used, that session is susceptible to MiTM Attacks. Though this seems straightforward, let's explore why this issue routinely appears in IoT penetration tests.
Why do we see this?
The most common scenario we see in devices vulnerable to MiTM from insecure "authmode" settings is when the device communicates with mixed infrastructure for multiple services. As an example, let's use a hypothetical consumer-grade security camera. Suppose the device has four main interfaces:
The device receives commands from an MQTT topic hosted in the manufacturer's back-end infrastructure.
The device sends logs to a managed logging service not hosted by the manufacturer.
The device uses a SIP server to facilitate Voice over IP so users can speak from their mobile device through the camera.
The device pulls Over-The-Air firmware upgrades from some cloud-based storage.
More often than not, when a device is vulnerable to MiTM, it is enforcing peer certificate validation on some, but not all, of these interfaces. The primary reason is that implementing sound certificate management is hard. Aside from the actual roll-out of an entire PKI infrastructure, backward compatibility with devices from previous firmware or even hardware versions presents unique challenges.
Additionally, we sometimes see debug and test code make its way into production systems. The MBEDTLS_SSL_VERIFY_OPTIONAL flag is often used in test environments to avoid maintaining certificate chains for test infrastructure. If an organization's build workflow misses this, the device will be vulnerable to MiTM, even if proper certificate chains are maintained.
IoT Man-in-The-Middle Damage
Often, we find that product teams underestimate the damage from a MiTM vulnerability in IoT devices. The initial intuition is that the vulnerability only impacts a single device or customer, making the scope of damage fairly low. While this may be true initially, the access to proprietary information a successful MiTM can provide may be far more consequential to a company.
Take, for example, the scenario where an adversary conducts a MiTM of an OTA update. This is one of the easiest ways for security researchers to recover compiled firmware for reverse engineering. Once the firmware is recovered, hardcoded secrets, configs, token generation algorithms, etc. are exposed. While extracting firmware from devices via physical debug headers like JTAG may be possible, doing so over a network-based MiTM is achievable with open-source tooling in minutes.
Another reason MiTM traffic is so beneficial to adversaries is that it provides insight into the back-end API used by the device. On multiple occasions, we have identified vulnerabilities in back-end infrastructure solely from the traffic captured during a MiTM attack.
Static Code Analysis is the answer
First and foremost, IoT product teams should consider implementing PKI to support certificate verification if they haven't already done so. Once this is done, teams should incorporate checks into their build pipeline to catch non-compliant flags for the function described in this article. These checks are often performed by whatever SAST tool the team uses, provided they support custom rules. Specifically, looking for any calls to mbedtls_ssl_conf_authmode with an argument other than MBEDTLS_SSL_VERIFY_REQUIRED should stop a build from proceeding. RedSquall also highly recommends incorporating MiTM testing into your dynamic application security testing process. DAST in IoT can be tricky due to the hardware component but well worth it.
In conclusion, MiTM is one of the most well-documented attacks in security, but it continues to surface in IoT. The misuse of a single flag in firmware source code can lead to the first step in complex attack chains. Engineering teams can prevent these vulnerabilities by knowing what to look for and creating processes to ensure these mistakes do not make it through their build pipeline to production.