Today, 1st of November, many teams will be upgrading OpenSSL to fix the critical vulnerability that will be announced between 13:00 and 17:00 UTC. That will be possible only if they know where they have OpenSSL installed in their infrastructure. Organizations know that an inventory of assets is essential for security, however, few have one up-to-date. Even in the case a company has an inventory of assets and it is up-to-date, it might not include information about packages installed on operative systems, containers and container images.
In this article I have dumped some ideas to try to find OpenSSL in an organization infrastructure.
Before starting, we have to decide if we might be affected or not. The vulnerable versions of OpenSSL, between 3.0.0 and 3.0.6, are not the default versions in many operative systems. If we are not using one of the affected operative systems, we should be safe. In the case of Red Hat, they have published this information.
If we cannot be sure that we are using only not affected operative systems, we will need to search for OpenSSL.
If we use containers and we are using them correctly (without installing packages in the running container), we can scan our container images to determine if we are using any of the OpenSSL affected versions. In order to scan container images we can use syft, which is an open source tool from Anchore that can scan container images and list the packages installed and their versions. We can dump its output to plain text files and then grep them looking for openssl.
For non-containerized environments, we will need to query the operative systems. For this case, we can use a tool like Ansible to log into each machine on our infra and execute the corresponding command to list installed packages. That command will be different depending on the OS and package manager in use. This is an example of why it is important to always use package managers to install software instead of installing by using tar xzvf or curl | bash. Software installed by these later methods is more difficult to find.
In the case of desktop systems, you may or may not have a way to manage them from a centralized place. If you have a centralized tool, you probably already have a way to identify if OpenSSL is installed and its version. If not, you might need to request users to execute a command in their machine to check if OpenSSL is installed and send the results to you.
By checking the OS, you will probably have all the information you need. However, there are still two places you can investigate as sanity check.
If your organization does a heavy use of open source or develop their own applications, you may clone all the code repositories you use and grep them searching for “openssl”. Any appearance of OpenSSL should be consistent with what you found by scanning the operative systems. If not, you might want to investigate it. Maybe it is a transient dependency, but as we are talking about a critical vulnerability, maybe you want to double check.
Another action you can perform to find OpenSSL is port scan your own organization. You can use nmap with ssl–enum–ciphers to find the TLS protocol in open ports. With this you won’t be able to identify OpenSSL version but the presence of OpenSSL should be consistent with what you found when scanning the OSs.
In the case of HTTP, you may want to grab HTTP server banners:
Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0.e
The right way of identifying OpenSSL in our infrastructure is just querying a good inventory of assets that includes software components, packages, dependencies and versions. However, many organization does not have the processes in place to have such an inventory up-to-date. In the absence of a better solution, we have to do what we can to be comprehensive and find as many uses of OpenSSL as possible.
