Protecting Against regreSSHion with Secure Workload

On July 1, 2024, the Qualys Threat Research Unit (TRU) disclosed an unauthenticated, remote code execution vulnerability that affects the OpenSSH server (sshd) in glibc-based Linux systems.

Now we have seen how CVE-2024-6387 has taken the internet by storm, making network security teams scramble to protect the networks while app owners patch their systems.

Secure Workload helps organizations get visibility of application workload traffic flows and implement microsegmentation to reduce the attack surface and contain lateral movement, mitigating the risk of ransomware.

Below are multiple ways in which Secure Workload can be leveraged to get visibility of affected application workloads and enforce segmentation policies to mitigate the risk of workloads being compromised.

1. Visibility of SSH Traffic Flows

According to the Qualys Threat Research Unit, the versions of OpenSSH affected are those below 4.4p1, as well as versions 8.5p1 through 9.8p1, due to a regression of CVE-2006-5051 introduced in version 8.5p1.

With Secure Workload, it is easy to search for traffic flows generated by any given OpenSSH version, allowing us to spot affected workloads right away and act. By using the following search attributes, we can easily spot such communications:

◉ Consumer SSH Version

◉ Provider SSH Version

Figure 1: Visibility of OpenSSH version from Traffic Flows

2. Visibility of OpenSSH Package Version in Workloads

Navigate to Workloads > Agents > Agent List and click on the affected workloads. On the Packages tab, filter for the “openssh” name and it will search for the current OpenSSH package installed on the workload.

Figure 2: OpenSSH package Version

3. Visibility of CVE-ID Vulnerability in Workloads

Navigate to Vulnerabilities tab, and a quick search for the CVE ID 2024-6387 will search the current vulnerabilities on the workload:

Figure 3: Vulnerability ID Information Per Workload

4. Mitigating Risk of regreSSHion

Once the relevant workloads are spotted, there are three main avenues to mitigate the risk: either by microsegmenting the specific application workload, implementing organization-wide auto-quarantine policies to proactively reduce the attack surface, or performing a virtual patch with Secure Firewall.

◉ Microsegmentation: Microsegmentation policies allow you to create fine-grained allow-list policies for application workloads. This means that only the specified traffic flows will be permitted, denying any other traffic that might be generated from the workload.

Figure 4: Microsegmentation Policies For Affected Application Workload

◉ Auto-Quarantine: You can choose to implement organization-wide policies to reduce the attack surface by quarantining workloads that have installed a vulnerable OpenSSH package or are directly affected by the CVE ID.

Figure 5: Organization-Wide Auto-Quarantine Policies

◉ Virtual Patch: If quarantining a workload is too disruptive to the organization (e.g., business-critical applications or internet-exposed applications), you can perform a virtual patch with the help of Cisco Secure Firewall to protect the application workloads against the exploit while still maintaining connectivity for the application.

Figure 6: Virtual Patch with Secure Firewall Connector

Figure 7: Vulnerability Visibility and IPS Signature in FMC

5. Process Anomaly and Change-In Behavior Monitoring of regreSSHion

Even in the scenario where a workload is compromised, Secure Workload offers continuous monitoring and anomaly detection capabilities, as shown below:

◉ Process Snapshot: Provides a process tree of existing runtime processes on the workload. It also tracks and maps running processes to vulnerabilities, privilege escalation events, and forensic events that have built-in MITRE ATT&CK Techniques, Tactics, and Procedures.

Figure 8: Process Snapshot of Affected Workloads

◉ Forensic Rules: Secure Workload comes with 39 out-of-the-box MITRE ATT&CK rules to look for techniques, tactics, and procedures leveraged by adversaries. It is also possible to create custom forensic rules to track certain process activities, such as privilege escalation performed by processes. The system can also generate alerts and send them to the Secure Workload UI and SIEM systems.

Figure 9: Example Manual Forensic Rule Creation (left) and Built-In Mitre ATT&CK Rules (right)

Source: cisco.com