We are as surprised as anyone to report that another month has flown by. And, though it passed quickly, August was full of security news. This month we’ll be taking a look at:
- Internet of Things Vulnerable via Insecure Communication Protocols
- China Blocks TLS 1.3 and ENSI
- wolfSSL Vulnerability Discovered
- Version Three of OASIS Standard PKCS#11 Released
Internet of Things Left Open Through Insecure Communication Protocols
Over 3.7 million IoT (Internet of Things) devices have been left open to attack through two insecure peer-to-peer communications protocols: CS2 Network P2P and Shenzhen Yunni iLNKP2P.
An article by Shaun Nichols in The Register gets into the problems that have left things like webcams, baby monitors and other internet-linked devices vulnerable to hijacking. The two protocols are used by millions of devices worldwide, which means those devices can be accessed by anyone who wants to snoop, or worse.
The bugs were found by Paul Marrapese, who has a whole site, hacked.camera, dedicated to the vulnerabilities. ‘As of August 2020, over 3.7 million vulnerable devices have been found on the internet,’ reads the site, which lists affected devices and advice on what to do if you have any at-risk gear. (Summary: throw it away, or try firewalling it off.)
Of course, as Nichols notes, the vulnerabilities don’t end with the devices that the communication protocols run on.
… bear in mind these gadgets sit on people’s Wi-Fi and LANs, so once you’ve commandeered a security camera, or whatever it may be, you can reach adjacent machines to exploit, or use nearby wireless network MAC addresses to pinpoint the exact location of the hardware from Google’s databases, and so on.
For the full, “and so on,” which is quite a lot, we recommend reading the whole article, also leads us to a DEFCON talk from Paul Marrapese that gives an in-depth look for anyone who is interested or concerned about the security risks:
The Great Firewall Blocks TLS 1.3 and ENSI
August also brought news that China’s Great Firewall is now blocking HTTPS traffic that uses TLS 1.3 and ESNI (Encrypted Server Name Indication). Both technologies make it harder for Chinese censors to see what sites citizens are trying to connect to and for censors to control access to those websites.
A joint report from IYouPort, the University of Maryland and the Great Firewall Report confirmed the ban, according to an article by Catalin Cimpanu of ZDNet. The ban, which went into effect sometime in late July, still allows HTTPS traffic that uses older versions of TLS and unencrypted SNI, permitting government censors to see which domains citizens are trying to reach.
At the moment, the groups that released the report have identified six ways to circumvent the ban client-side and four ways to avoid it server-side, but both the group and the ZDNet article acknowledge these workarounds are not a long-term solution as the “cat and mouse game” between technology and Chinese censorship progresses.
Vulnerabilities in wolfSSL Discovered
Gérald Doussot of cyber security firm NCC Group published a technical advisory on August 24 describing a TLS 1.3 vulnerability in versions of wolfSSL prior to 4.5.0. Version 4.5.0 of the wolfSSL library, containing a fix, was released on August 17, prior to the publication of the NCC Group’s advisory, and NCC Group recommends that users update to the newer, secure version.
According to NCC Group:
wolfSSL incorrectly implements the TLS 1.3 client state machine. This allows attackers in a privileged network position to completely impersonate any TLS 1.3 servers and read or modify potentially sensitive information between clients using the wolfSSL library and these TLS servers.
As described on wolfSSL’s website, the wolfSSL embedded SSL library in question “ is a lightweight, portable, C-language-based SSL/TLS library targeted at IoT, embedded, and RTOS environments primarily because of its size, speed, and feature set.” The fact that these vulnerabilities are found on the Internet of Things and that the “things” that wolfSSL is found on number in the billions makes this worth notice. An update to the fixed, available version of the library is strongly advised.
Version Three of OASIS Standard PKCS#11 Released
An August 19 announcement on PrimeKey’s blog clued us in to the fact that version 3 of the OASIS standard PKCS#11 cryptographic token interface was published in June, 2020.
PKCS#11 has been in existence since 1995 and, as the blog itself describes it, is a “platform-independent API to access and use cryptographic functions in hardware security modules (HSMs), smart cards, USB tokens, TPMs and the like.”
According to PrimeKey (vendors of the Certificate Authority software EJBCA), the PKCS#11 standard has had some problems with standardization issues related to vendor-defined mechanisms in hardware tokens which limit its utility as a standard API. The previous version of the standard has also had some trouble keeping up with the rapid pace of cryptographic development these days, so version three is a welcome and needed change. As the blog notes:
In general, it has worked surprisingly well over the years, but there have been subtle nuances requiring consideration when attempting to use a new token claiming to be PKCS#11 compliant causing interoperability issues between clients and servers.
The addition of new, standardized cryptographic mechanisms in PKCS#11 v3.0 (including SHA3 and EdDSA signatures) will allow PrimeKey and other software vendors to implement them in a standardized way across hardware security modules and tokens that support the new standard.