Putting OpenSSL in Context for xIoT Device Security

OpenSSL.org announced last week that an updated version of its OpenSSL software package (v3.0.7) will be released on November 1, 2022. The update is expected to include a fix for a yet-to-be-disclosed security issue that was originally deemed as “CRITICAL, but has since been downgraded to “HIGH”. 

So, what’s important about this vulnerability from an xIoT (purpose built IoT, OT & network devices running firmware that’s network-connected and where you can’t install endpoint security controls) perspective?

There are literally billions of xIoT devices, far more than traditional IT endpoints and cloud devices by several orders of magnitude. In fact, most organizations have about 3-5 xIoT devices per employee. As such there are indeed devices that are running with vulnerable versions of SSL. Is that a problem? Yes. But let’s put the “problem” into some context.

Most organizations don’t even know how many xIoT devices they have, where they are, what they do, who’s responsible for them, or how insecure they are. Discovery is an important first step in addressing this issue.

The majority of xIoT devices operate with firmware that is more than six years old. They run on common operating systems, like Linux, Android, BSD, and real-time operating systems like VxWorks, just to name a few. About a quarter of those devices are running firmware that is end of life. These devices are full of vulnerabilities. In fact, almost 70% of these devices operate with high and critical level CVEs which means remote administrative control can be gained with little-to-no skill. Will some of those systems have out-of-date SSL? Yes, they will have out-of-date SSL, and many will have versions of SSL that are multiple generations old and vulnerable. These xIoT devices need to have their firmware updated and patches applied as frequently as traditional IT assets.

If being full of vulnerabilities wasn’t enough of a problem, consider passwords. About half of enterprise xIoT devices operate with default passwords. Those passwords can be discovered in seconds with a simple Google search, and with a simple Shodan search you can find those xIoT devices that are also Internet-accessible. The other half of the xIoT devices aren’t much better. Often, xIoT devices have their passwords changed once, and that change was forced by the firmware at the time of installation. That installation isn’t usually conducted by a security professional, but rather by a vendor installing a massive number of VoIP phones, door locks, cameras, etc., and they aren’t thinking about security best practices. Changed passwords tend to be basic – i.e., not following best practices for upper- and lower-case characters, numbers, and special characters. The passwords are often the same across all 10,000 printers, all 2,000 security cameras, or all 5,000 digital door locks, for example. These passwords also don’t follow best practices on password length, and they are never rotated in accordance with organizational policies, such as every 90-days. They are unmanaged and typically not linked to PAM solutions. You can have all the SSL vulnerabilities you like, but if the passwords are set to “password” or “123456” you have greater concerns, and stronger password management is required.

Enterprise xIoT devices often operate promiscuously with multiple services and protocols enabled to make them easy to use and connect with. A printer, for example, may be running HTTP, HTTPS, SSH, Telnet, FTP, TFTP, Bluetooth, wired Ethernet, or Wi-Fi. Might it have an SSL vulnerability? Yes, but having such a massive attack surface on one device multiplied by tens of thousands of devices within your organization means you need device hardening, and you need to shut down unneeded services and protocols.

Certificates are used on many xIoT devices. That’s a good thing, right? Well, yes, if they are good certificates. But, just like old firmware, bad passwords, and promiscuous devices, certificates are often flawed. They could be expired, self-signed, running old TLS versions for example, or simply not be operating in with strong cryptological capabilities. These systems could also have out-of-date SSL, which again, this is a problem, but ensuring that your certificates are operating in accordance with good security practices is also important.

Summary

Vulnerabilities are commonplace across IT and xIoT. This isn’t the first time we’ve seen an SSL vulnerability, and it won’t be the last. In the xIoT world, there is a common practice of not developing systems with a SDLC in mind, leveraging white labeling, and using shared libraries. This means it’s highly likely that the vulnerabilities found on a printer, including SSL vulnerabilities, can also show up on a KVM switch, UPS, or VoIP phone. Organizations should take note of this vulnerability and take steps to mitigate the risk. Also, think about the vulnerabilities from a broader perspective, and take more strategic steps to threat mitigation juxtaposed to a tactical approach that may simply address a single SSL vulnerability while leaving your xIoT devices vulnerable and exposed, thus leaving your local IT and cloud environments at risk.

Steps to mitigating threats on xIoT devices should include:

• Holistic, accurate, and timely discovery of your xIoT assets – i.e., know what you’ve got
• At-scale firmware updates and patching per the vendor’s guidelines
• Robust credential management that follows best practices and organizational policies
• System hardening and certificate management
• xIoT monitoring to mitigate environmental drift and keep systems you’ve secured, secure in perpetuity
• VLANs for device separation can be useful for end-of-life devices and for devices where the vendors have gone out of business and patches are no longer available
• Limit what xIoT devices can be reached from the Internet
• Limit what xIoT devices can communicate out to the Internet