Shaking Hands with Wolves - The wolfSSL CVE-2020-24613 Vulnerability

Leo Dorrendorf  August 26, 2020

Yesterday, NCC Group reported a new vulnerability in the wolfSSL library which threatens embedded devices, mobile phones, or other products using the library to communicate over the network via the Transport Layer Security (TLS) 1.3 protocol. Although the vulnerability, designated CVE-2020-24613, is yet to receive a CVSS score from NVD, we believe it is critical, as the affected devices are at risk of complete data exposure and/or remote takeover.

The issue: a vulnerable handshake

wolfSSL is an open-source library with commercial support. It implements the TLS protocol and all the necessary cryptographic functions, and is written in the C language, with support for bindings from other languages. The library is supported on a variety of platforms, and is widely used in embedded devices.

The vulnerability occurs in the set-up phase of a TLS session, called a "handshake", which involves the client and server exchanging several predefined messages in order to identify themselves and agree on cryptographic keys and functions to use during the session.

The threat: as big as it gets

An attacker who's capable of intercepting the client's attempt to contact a server using TLS 1.3 can respond with invalid packets during the TLS handshake phase. This is not so far-fetched, as there are many techniques which allow an attacker to redirect a client's packets to a host they control, including DNS poisoning and BGP protocol manipulations. Once there, the attacker can bypass the server authentication step using the vulnerability disclosed by NCC - by sending a Finished message earlier than expected during the TLS handshake.

Following this, the attacker will be able to impersonate the server for all possible purposes, including exposure of any information sent by the client, and taking control of the client if it receives any commands or software from the server. The attacker can also impersonate the client to the server, creating a separate connection while potentially using any legitimate messages sent by the client. In effect, this is a complete Man-in-the-Middle attack.


The importance of using well-maintained libraries for security

When choosing a library for cryptography or TLS (or for any other purpose, really) to incorporate into connected products, it's crucial to take into account the maintenance level of the library (libraries in active development are obviously preferable to abandoned and deprecated software). The security track record of its maintainers should also be evaluated. For wolfSSL this information is public, but if not, it can be determined from the contents of the source code repository and issue tracker.

In the case of CVE-2020-24613, according to the NCC Group disclosure timeline and the wolfSSL security vulnerabilities page, it took just about two days for the maintainers to fix the issue. It took a little longer if you count the time from the original contact to the final publication, but overall still less than a month. This is exemplary handling for a security issue, in line with wolfSSL's record of timely security fixes.

Guidance for resolving the issue

The best approach is to upgrade wolfSSL to version 4.5.0 (or later) as fast as possible. That will completely eliminate the vulnerability. The maintainers have included many other bug fixes and security fixes in the current release, so it's always recommended to update when feasible.

If a version upgrade is not possible, there are two mitigating steps you can take:

  • Apply the original patch and rebuild wolfSSL from source. This is not an official fix, and not as good as updating the whole library, but it should solve the current issue.

  • Configure wolfSSL to remove support for TLSv1.3. This is done by removing the --enable-tls13 configuration option from the build settings (it is disabled by default) and rebuilding wolfSSL from source. This will also solve the current issue, but has other downsides - forcing the library to work with older TLS versions, which might cause other issues with security and performance.

There is another option for mitigating the vulnerability without modifying the device code: configuring the server to enforce TLS client authentication. This will force the client to authenticate using a certificate. As a result, the attacker will not be able to impersonate the client to the server (the attacker can still impersonate the server to the client). This can help mitigate the attack somewhat, but assumes the client devices already have certificates, and all the necessary Public Key Infrastructure for that is already in place.

Start with quickly identifying impacted devices

As explained above, this issue highlights the importance of choosing the right libraries for your product. Having full support for software updates is necessary for fixing this vulnerability on devices in the field. Another very important aspect for connected device vendors is the ability to quickly discover if and where the problem exists, to enable fast and efficient response.

An embedded device vendor who uses wolfSSL in their products would have to examine all their relevant device models' components down to the firmware level, to determine which ones include vulnerable versions of this library. This information in itself, however, is not enough to assess the cybersecurity risk arising from the vulnerability. If the library is present but not used in any network-related code (for example, if only its cryptographic functions are ever called), removing it is just a hassle. The same is true if a non-vulnerable version of the library is used, if a patch was applied, or if TLSv1.3 is disabled. This is where advanced automated device security analysis comes handy.

With the Vdoo Platform, we work to enable fast detection of issues such as the wolfSSL vulnerability in connected devices, typically within 24 hours after the vulnerabilities are published, via automated analysis of the device firmware images. Beyond detecting the wolfSSL library and version via software composition analysis, binary scanners built into the platform determine if the library was indeed compiled with TLSv1.3 support, making it vulnerable; and whether the library is used with network functionality. For other vulnerabilities, different automated scans are performed to identify mitigations (including firewall rules, software configurations, and more) which prevent exploitation. By directing our customers to the specific devices that are impacted by the issue and providing background information on the problem and possible resolutions, we help them to concentrate their attention on the issues that really matter.

Share this post
Leo Dorrendorf, Security Researcher

Leo Dorrendorf

Security Architecture Team Leader

Leo Dorrendorf is a security researcher with experience in the academy and the industry, including a diversity of topics from reverse-engineering and breaking to designing and implementing connected systems. Currently part of the Vdoo security team, Leo deals with creating engines for automated threat modeling, binary scanning, and requirement generation which incorporates a growing number of standards from the world of embedded security.

Our latest updates