CVE-2024-6387 Response Resources - "regreSSHion"

TL;DR: Qualys research team discovered an issue where you can exploit OpenSSH with a “brute force” like timing attack from the outside. This will effect vulnerable OpenSSH library versions, which is essentially any public facing Linux server open on port 22.

In my opinion, the likelihood on a real world exploit for this is mixed - on the one hand, if it’s targeted it can definitely work and there is some PoC code out there, on the other hand, it requires a lot of noisy traffic over a long(ish) period of time.

High level Qualys blog that I didn’t find super helpful is here.

Technical Summary of the exploit is here.

Mitigation:

1. Patch the effected OS (list below)

2. If you can’t patch, this is the mitigation from Canonical:

Set LoginGraceTime to 0 in /etc/ssh/sshd_config. This makes sshd
vulnerable to a denial of service (the exhaustion of all MaxStartups
connections), but it makes it safe from this vulnerability.

Effected Ditros

1. Ubuntu versions greater than 22.04 - Ubuntu Security Notice

2. Fedora (RHEL 9) - Red Hat Security Notice

3. SUSE - Evaluation in progress: SUSE Security Notice

4. AWS Linux - ALAS 2023 is pending fix, everything else is not vulnerable

Status and Summary Info:

Unverified POC is out: https://github.com/acrono/cve-2024-6387-poc

Brief summary of the technical writeup:

How Does It Work?

1. Signal Handler Issue:

   • When sshd times out waiting for authentication, it uses a signal handler to log the event. This logging process can be interrupted, leaving the server in an inconsistent state.

2. Remote Exploitation:

   • The attacker can manipulate this inconsistent state to execute arbitrary code. This is achieved by carefully timing the attack to coincide with the signal handler's execution.

Practical Example:

• While every version exploit in the paper was slightly different, an attacker might need around 10,000 attempts to successfully exploit the vulnerability, potentially gaining root access hours to a week depending on the concurrent connections that are available.

• Good high level summary from Oligo

What Scanners Would Detect This?

1. Any agent or agentless scanner with linux detection

2. Container vulnerability scanning - interesting example of ASPM contextual risk from Aikido who are using combining CSPM and Container Vuln data to increase risk based on if port 22 is open

3. Another example of Oligo and Raven being important because they can actually just block this as well as detect if openssh is actually in use or not

Some hypothetical mitigations/detections and thoughts from James:

1. Any DoS or high traffic volume alerts and trying to “wack-a-mole” against the attacker IPs

2. Understand your network flow for bastion setups and look for servers that are the most publicly facing

3. I would patch instead of mitigate where possible because the Mitigation makes you susceptible to DoS; however, this may be preferable for bastion setups where DoS can be low risk if you can re-deploy or scale easily.

4. Your actual likelihood of getting attacked here probably depends on your general risk profile - people will absolutely try to exploit this, but it requires a targeted commitment unlike Log4J