Holistic Product Security Part 2: System Configuration

Continuing the series on Product Security, in this article we will explore some resources and steps you can take to address another major risk in your product’s software: system configuration.

The point of this series “Holistic Product Security” is to make sure you are thinking about what goes into your product at the various stages of the product development and DevSecOps lifecycle, and realize there are different security considerations at each phase of the lifecycle.

The most often overlooked and exploited vulnerabilities in modern connected devices are sometimes the easiest to fix, but knowing when to test for them and how to make sure you don’t reintroduce them in your product as a regression is still a challenge. 

Default or Weak Passwords

Most modern connected devices are running a full operating system such as Linux or Windows, or real-time operating systems such as VxWorks or QNX. There are many configuration options for these operating systems, but let’s talk about the most egregious examples of vulnerabilities that could have been prevented.

It is an unfortunate fact that many of the most well known and impactful vulnerabilities in recent years have come from having default credentials that are never updated or disabled before the devices join the network. 

At this point we are all familiar with the Mirai malware that created a botnet of hundreds of thousands of IoT devices including routers, cameras, and DVRs using more than 60 factory default username and password combinations that were hard-coded in the devices. The malware scanned for devices with open Telnet ports, and if they were available, brute force attempted the usernames and passwords until one of them worked, giving it complete access to the device. Although this malware spread in 2016, and has been the subject of numerous studies and news stories, hard coded usernames and passwords still make their way into new products.

Your typical Static Application Security Testing (SAST) tools won’t find this type of vulnerability, because the usernames and passwords are not part of the software your product team is building (the software to actually do the thing your product was designed to do). Instead, default passwords and insecure network services are incorporated into the operating system when the final system image is built.

In my previous post, Part 1: Open Source Software, I discussed “Source SBOMs,” “Build SBOMs,” and “Deployed SBOMs,” and how they come from different stages in the software development lifecycle. To detect default passwords, you should be analyzing your deployed system image. Binary SCA can tell you the software that is present in the deployed image system, but you need configuration analysis against the file system or firmware image to uncover default passwords and insecure services, like the ones that caused the Mirai botnet to be possible.

Secure Services Can Still Be Misconfigured

We discussed default credentials (admin:admin, anyone?), and Telnet, which should basically never be enabled under any circumstances for your final product, but there are plenty of other services that, although they are more secure by design, can suffer a similar attack if not adequately secured.

An SSH server is an example of a useful tool for legitimately accessing a device, and can offer a high amount of security (all SSH traffic is encrypted, and it stands for “Secure Shell,” after all). However, it suffers from basically the same fate as Telnet if it is misconfigured with standard password authentication enabled and user accounts that allow remote login. 

It can be made more secure by disabling username and password authentication, and instead requiring public-private key pairs for login, but be vigilant! Make sure your configuration analysis tools are checking for accidental inclusion of these keypairs in your final image! 

We have analyzed hundreds of thousands of firmware images, and it is still common to detect private SSH keys in firmware images, and authorized_keys files that basically make connecting to the device a cakewalk for any attacker. Make sure your tools are checking your system and service configurations (such as sshd config), and looking for any rogue private keys or certificates that could be used by attackers to bypass login security or impersonate your legitimate devices.

Real Time Operating Systems Aren’t Exempt

If you think your product can’t be affected by these types of vulnerabilities because it is not running Linux or Windows, think again. Although VxWorks and QNX are real-time operating systems, they can be configured to have user login functionality (with hard-coded default credentials if you’re not careful), and can even run a Telnet service. Connected devices need to communicate over a network, which means it is likely they have some implementation of standard protocols for talking to other devices and controllers. Configuration analysis can make sure the configuration of those services is done in a secure way.

Conclusion

Make sure you are considering what goes into your final product after your teams write the code to make your device do what it is designed to do. The operating system, user accounts, and network services are a major attack surface that warrants deep analysis to make sure your configuration isn’t inherently insecure. 

In this article we discussed a little bit about default passwords and insecure service configuration. These are still common mistakes to make, and the reason we advocate moving toward automated analysis of your product security at all phases of the product development lifecycle - to catch any regressions before the build goes into production. 

In a future article we’ll get more in-depth about insecure protocols and open ports, when to analyze your product’s software for them, and how to ensure your products ship secure - and stay secure.

About the Author

Nicholas Vidovich is Principal Product Manager with Finite State, the company building the Product Security Platform with market-leading Product Security and Risk Management. He works directly with Product Security teams at global device manufacturing companies and Asset Owners at critical infrastructure utilities, and is committed to Finite State’s mission to protect our connected world.