Undisclosed OpenSSL vulnerability: Free scripts for target scoping

Tomorrow is “patch Tuesday” and it's a notable one. The OpenSSL project team announced last week that they will be releasing OpenSSL version 3.0.7, with a patch to fix a critical security vulnerability. Until the vulnerability details are released, not much is known about the nature of the vulnerability. In 2014, Heartbleed was an extremely serious vulnerability that was in the codebase for nearly 2 years going back to 2012, to this day that vulnerability remains unpatched in many environments. In 2016, OpenSSL had several other vulnerabilities and security bulletins ranging from egregious POODLE attacks against the AES-NI CBC MAC check to less serious buffer overflows. 

 While many are worried about what could potentially happen because of this disclosure this post answers the call to action of finding what resources are potentially impacted by this upcoming OpenSSL v3.x vulnerability. In this post you will be provided with several Python scripts for attempting to find resources with OpenSSL installed in them either directly or as an upstream dependency as part of their software supply chain. Hopefully these will assist Lightspin customers and other security professionals in the broader community. 

Locating OpenSSL: Microsoft Defender for Endpoint (MDE) 

Microsoft Defender for Endpoint (MDE), formerly known as Microsoft Defender Advanced Threat Protection (ATP), is an Extended Detection & Response (XDR) agent within the Microsoft Defender ecosystem that provides Threat & Vulnerability Management (TVM), Endpoint Detection and Response (EDR), and other security capability sets to users of the agent. MDE can provide XDR coverage of varying maturity to Linux, Windows, and MacOS devices within your environment – including cloud-based instances. 

Important Note: The following script relies on an Enterprise Application (EA) being created with necessary permissions to access various Defender APIs and your tenant ID, the EA client ID, and EA secret ID being stored in encrypted AWS Systems Manager (SSM) Parameter Store parameters. Refer to this Blog for more information on this setup. 

This script will retrieve credentials from AWS SSM Parameter Store, authenticate to the Microsoft Security Graph, retrieve every single active MDE machine, and then retrieve the installed software. Only machines with OpenSSL installed will be written to a JSON document along with basic metadata such as the computer name and IP addresses identified by MDE. The installed software API does not provide any version numbers or Common Platform Enumeration (CPE) identifiers. 

The expected output from this script will resemble this example:

{

    "MachineId": "29161338f0EXAMPLEEXAMPLE6186c85b3bad85c8",

    "ComputerDnsName": "ip-10-EXAMPLE-1-37.us-east-7.compute.internal",

    "OsPlatform": "Ubuntu",

    "OsVersion": null,

    "LastIpAddress": "10.EXAMPLE.1.37",

    "LastExternalIpAddress": "3.EXAMPLE.54.108",

    "SoftwareId": "ubuntu-_-python3-openssl_for_linux",

    "SoftwareName": "python3-openssl_for_linux"

}

Locating OpenSSL: AWS Systems Manager Inventory 

Within the AWS Cloud, the AWS Systems Manager (SSM) service is a management and governance service which combines several configuration management utilities such as patch management, package management, and software asset management into a suite of easy-to-use tools and APIs. Within the SSM ecosystem is Fleet Manager which is a sub-service that collates EC2 instances and on-premises servers managed by SSM Hybrid Activations along with their patch status, compliance status (e.g., from tools such as Chef InSpec), and their inventory. 

Using the ListInventoryEntries API from SSM, you can retrieve specific packages using filtering operators such as “BeginWith” to attempt to find installed packages. This method requires your EC2 instance to be onboarded to AWS SSM and have a correctly configured Inventory collection state management association. Additionally, this does not account for edge-cases where an installed package is not named OpenSSL but relies on it in an upstream fashion. 

The following script will locate all your opted-in AWS Regions for your Account and attempt to find EC2 instances, determined if they are onboarded by SSM, and then attempts to write any OpenSSL package into a JSON file. 

The expected output from this script will resemble this example:

{

    "InstanceId": "i-02f6EXAMPLE98f5c0c ",

    "AwsRegion": "us-east-7",

    "ApplicationName": "openssl-libs",

    "PackageId": "openssl-1.0.2k-24.amzn2.0.4.src.rpm",

    "ApplicationVersion": "1.0.2k"

},

{

    "InstanceId": "i-02f6EXAMPLE98f5c0c",

    "AwsRegion": "us-east-7",

    "ApplicationName": "openssl",

    "PackageId": "openssl-1.0.2k-24.amzn2.0.4.src.rpm",

    "ApplicationVersion": "1.0.2k"

} 

Locating OpenSSL: Anchore Grype & Syft 

This section deals with two related tools by Anchore, Grype and Syft, both of which are command-line utilities for Docker images and filesystems. Both work with several “flavors” of Linux such as Alpine, BusyBox, Amazon Linux, Ubuntu, and RHEL as well as several language-specific package managers such as Ruby Gems, NPM, Yarn, Wheel, Poetry, and their derivative files such as JAR and requirements.txt files.  

Grype is a vulnerability management tool that works on containers and filesystems so it can be used on your cloud-based instances as well as any Docker images which you build. Syft is a tool to generate Software Bill of Materials (SBOM) files in JSON, CycloneDX, and SPDX formats (among others) which can also be absorbed into Grype for faster vulnerability management built on top of your SBOM creation process. SBOMs have gained popularity within the wider cybersecurity community due to fiat decrees (Execute Orders) issued by the United States Government. 

While vulnerability management tools and SBOMs in their basest form will retrieve CPEs and other package information from the operating system and package management tools – how they use this information differs widely. For the most part a vulnerability management tool takes only the packages that match against any number of vulnerability information databases such as the NIST National Vulnerability Database (NVD) and retrieve information about the specific vulnerability such as the severity and description. 

An SBOM on the other hand is analogous to an ingredients label for your food, however it goes into more detail, imagine if the ingredients also came with individual provenance information such as their upstream ingredient, the factory it was produced in, how it got to where you purchased it, and other supply chain information. That is more akin to what an SBOM is, identifying the direct installed packages within your system as well as the upstream packages in which those other packages are dependent on – giving you a full picture of transient and deeply nested dependencies. Orienting your vulnerability management processes on SBOMs instead of directly on filesystems and package management tools will help solve for third party risk use cases as well as typical risk treatment efforts by your broader threat and vulnerability management program. 

Before using this script install both tools (this requires administrative permissions on your OS) using the command line and run a JSON report for both tools against public Docker images. Do not run the last two commands until you create the provided script. 

# Install Grype & Syft 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sudo sh -s -- -b /usr/local/bin # Run each tool against some public containers 
grype python:latest --scope all-layers -o json --file ./python_latest_docker_grype.json 
syft ubuntu:latest --scope all-layers -o json --file ./ubuntu_latest_docker_syft.json 
# Use the script 
python3 ParseGrypeOpenSsl.py --scanner_source Grype --filename python_latest_docker_grype.json 
python3 ParseGrypeOpenSsl.py --scanner_source Syft  --filename ubuntu_latest_docker_syft.json 

The ParseGrypeOpenSsl.py script referenced in the above Bash script is as follows. 

The expected output for Grype from this script will resemble this example:

{ 
    "SourceType": "image", 
    "SourceTargetName": "python:latest", 
    "SourceTargetId": "sha256:00cd1fb8bdcc67527e569dcdf5e4ad9d704b117eb961602804826281d641cac3", 
    "ArtifactName": "libssl-dev", 
    "ArtifactVersion": "1.1.1n-0+deb11u3", 
    "ArtifactPurl": "pkg:deb/debian/libssl-dev@1.1.1n-0+deb11u3?arch=amd64&upstream=openssl&distro=debian-11", 
    "ArtifactLocations": [ 
        { 
            "path": "/usr/share/doc/libssl-dev/copyright", 
            "layerID": "sha256:882fd36bfd35d8c0c12d8472686059e1a6943c23a1e12ff9c18bceec3027e47c" 
        }, 
        { 
            "path": "/var/lib/dpkg/info/libssl-dev:amd64.md5sums", 
            "layerID": "sha256:882fd36bfd35d8c0c12d8472686059e1a6943c23a1e12ff9c18bceec3027e47c" 
        }, 
        { 
            "path": "/var/lib/dpkg/status", 
            "layerID": "sha256:6b183c62e3d75c58f15d76cc6b6bedadab02270bff6d05ed239c763a63dce306" 
        }, 
        { 
            "path": "/var/lib/dpkg/status", 
            "layerID": "sha256:882fd36bfd35d8c0c12d8472686059e1a6943c23a1e12ff9c18bceec3027e47c" 
        } 
    ], 
    "ArtifactUpstreams": [ 
        { 
            "name": "openssl" 
        } 
    ] 
} 

The expected output for Syft from this script will resemble this example:

[

    {

        "SourceType": "image",

        "SourceTargetName": "ubuntu:latest",

        "SourceTargetId": "sha256:cdb68b455a141ed921945f6d39a8c0694a7e21a37b2b030488d73e38875a26cc",

        "ArtifactName": "libssl3",

        "ArtifactVersion": "3.0.2-0ubuntu1.6",

        "ArtifactPurl": "pkg:deb/ubuntu/libssl3@3.0.2-0ubuntu1.6?arch=amd64&upstream=openssl&distro=ubuntu-22.04",

        "ArtifactMetadataSource": "openssl"

    }

]

How Lightspin customers can discover any vulnerable OpenSSL endpoints 

Due to the fact that the CVE has not been released yet, it does not have a number, therefore Lightspin will show this vulnerable asset as having the CVE - ‘CVE-OPENSSL-UNDISCLOSED’. 

Starting from the next scan of each account, please follow these steps to identify all your vulnerable assets: 

• Log in to the Lightspin platform. 
• Go to the ‘Vulnerabilities’ page. 
• Search for ‘CVE-OPENSSL-UNDISCLOSED’. 
• If there are vulnerable assets, click on the result row. 
• A side panel opens with the full Details and the Assets list on the second tab. 
• Scroll down and click on ‘Show in Assets List’ to see the detailed list. 

The Lightspin Attack Path Prioritization Engine will prioritize those assets that are vulnerable which are public and/or noted that they contain sensitive data.  

For any readers not currently a Lightspin customer, anyone can start for free and get an immediate OpenSSL vulnerability assessment and prioritization of your cloud environment.  

Security is better when we work together 

Whenever a critical vulnerability on a popular piece of software is released, we get encouraged and inspired by how our cloud defenders, blue teamers, PSIRT engineers and many more come together to patch the gap. We’re proud to be a part of this community and hope some of these scripts and recommendations will help.