CVE-2024-55560

Executive Summary

CVE-2024-55560 is a critical vulnerability in MailCleaner, an open-source email gateway and anti-spam solution. The vulnerability stems from the use of default, hard-coded SSH host keys (ssh_host_dsa_key, ssh_host_rsa_key, and ssh_host_ed25519_key) that persist after installation. This allows an attacker who obtains these default keys to perform a man-in-the-middle (MITM) attack against any MailCleaner instance, decrypting and potentially modifying SSH traffic. The vulnerability has a CVSS score of 9.8 (Critical) due to its network-based attack vector, low complexity, and high impact on confidentiality, integrity, and availability.

Supply Chain & Package Security

This vulnerability is not related to a specific package manager (NPM, PyPI, Go, Ruby) but is a configuration flaw in the MailCleaner application itself. The risk is amplified in supply chain scenarios where a compromised MailCleaner instance could be used to intercept and modify email traffic, potentially leading to data exfiltration or injection of malicious content.

CVSS Breakdown & Threat Level

• CVSS Score: 9.8 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - No user action is required.
• Scope (S): Unchanged (U) - The impact is confined to the vulnerable component.
• Confidentiality (C): High (H) - Complete disclosure of all SSH traffic.
• Integrity (I): High (H) - Potential to modify SSH traffic.
• Availability (A): High (H) - Potential to disrupt SSH connections.

Deep Dive & Mechanics

The vulnerability is rooted in the MailCleaner installation process. During initial setup, the application generates SSH host keys for the DSA, RSA, and Ed25519 algorithms. However, due to a flaw in the code (fixed in commit 28d913e), these keys are not regenerated uniquely for each installation. Instead, they are hard-coded into the application's source code or configuration files, meaning every MailCleaner instance uses the same set of SSH host keys.

An attacker who obtains these default keys (which are publicly available in the MailCleaner source code or from a compromised instance) can perform a MITM attack. When a client (e.g., an administrator using SSH to manage the MailCleaner server) connects, the attacker can intercept the connection, present the default host key, and decrypt the traffic. This allows the attacker to steal credentials, inject commands, or exfiltrate data.

The attack flow is as follows:

1. Attacker obtains the default SSH host keys from the MailCleaner source code.
2. Attacker positions themselves between a legitimate client and the MailCleaner server (e.g., via ARP spoofing, DNS poisoning, or compromised network infrastructure).
3. When the client initiates an SSH connection, the attacker intercepts it and presents the default host key.
4. The client, seeing a known host key (if they have previously connected to a MailCleaner instance), may accept it without warning.
5. The attacker decrypts the SSH session, gaining access to all transmitted data.

Vulnerable vs. Patched Code

Vulnerable Code (before commit 28d913e): The vulnerable code likely resides in the installation script or configuration file that sets the SSH host keys. A simplified example:

# /etc/ssh/ssh_host_rsa_key (hard-coded)
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
-----END RSA PRIVATE KEY-----

The keys are static and identical across all installations.

Patched Code (after commit 28d913e): The patched code regenerates unique keys during installation:

# Installation script
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

This ensures each MailCleaner instance has unique SSH host keys.

Exploitation & Lab Setup

Red Team (Attacker)

Lab Setup:

1. Victim: A MailCleaner instance with the default SSH host keys (e.g., version before commit 28d913e).
2. Attacker: A Kali Linux machine with ssh-mitm or bettercap installed.
3. Client: A machine that will SSH into the MailCleaner instance.

Exploitation Steps:

1. Obtain the default SSH host keys from the MailCleaner source code (e.g., from a public repository or a compromised instance).
2. Set up a MITM position using ARP spoofing:

   sudo arpspoof -i eth0 -t <client_ip> <mailcleaner_ip>
   sudo arpspoof -i eth0 -t <mailcleaner_ip> <client_ip>
   

3. Use ssh-mitm to intercept the SSH connection:

   ssh-mitm server --remote-host <mailcleaner_ip> --remote-port 22 --host-key-file /path/to/default_rsa_key
   

4. When the client connects, ssh-mitm will present the default host key, and the attacker can capture credentials and session data.

Blue Team (Defender)

Detection Steps:

1. Check SSH Host Keys: Verify if the SSH host keys on the MailCleaner server match the known default keys.

   ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
   

   Compare the fingerprint with known default fingerprints from the MailCleaner source code.
2. Monitor for MITM Attacks: Use network monitoring tools to detect ARP spoofing or unusual SSH connections.
3. Implement SSH Key Rotation: Regularly rotate SSH host keys and ensure they are unique per installation.

Indicators of Compromise (IOCs)

• File Hashes (SHA-256):
  • ssh_host_rsa_key: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (example, replace with actual hash)
  • ssh_host_dsa_key: d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592 (example)
  • ssh_host_ed25519_key: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb (example)
• Network Indicators:
  • Unusual ARP traffic indicating spoofing.
  • SSH connections from unexpected IP addresses.
• Log Indicators:
  • SSH logs showing host key mismatch warnings.
  • /var/log/auth.log entries with "REMOTE HOST IDENTIFICATION HAS CHANGED" messages.

Detection Engineering

YARA Rule

rule CVE_2024_55560_MailCleaner_Default_SSH_Keys {
    meta:
        description = "Detects default SSH host keys used in MailCleaner CVE-2024-55560"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-55560"
    strings:
        $rsa_key = "-----BEGIN RSA PRIVATE KEY-----" ascii wide
        $dsa_key = "-----BEGIN DSA PRIVATE KEY-----" ascii wide
        $ed25519_key = "-----BEGIN OPENSSH PRIVATE KEY-----" ascii wide
        $default_fingerprint = "SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ascii wide
    condition:
        any of ($rsa_key, $dsa_key, $ed25519_key) and $default_fingerprint
}

Sigma Rule

title: Detection of Default SSH Host Keys in MailCleaner
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects the presence of default SSH host keys associated with CVE-2024-55560
author: Valters IT
date: 2024/01/01
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename|contains:
            - '/etc/ssh/ssh_host_rsa_key'
            - '/etc/ssh/ssh_host_dsa_key'
            - '/etc/ssh/ssh_host_ed25519_key'
        TargetFilename|endswith: '.pub'
    condition: selection
falsepositives:
    - Legitimate key regeneration
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 22 (msg:"CVE-2024-55560 MailCleaner Default SSH Key MITM"; flow:to_server,established; content:"SSH-2.0-"; depth:6; content:"|00 00 00 00 00 00 00 00|"; distance:0; within:8; reference:cve,2024-55560; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade MailCleaner to commit 28d913e or later. This ensures unique SSH host keys are generated during installation.
2. Regenerate Keys: If upgrading is not immediately possible, manually regenerate the SSH host keys:

   sudo rm /etc/ssh/ssh_host_*
   sudo dpkg-reconfigure openssh-server
   

3. Network Segmentation: Isolate MailCleaner instances on a separate network segment to limit the impact of a MITM attack.
4. Monitor SSH Connections: Enable SSH logging and monitor for host key mismatches.
5. Use SSH Certificates: Implement SSH certificate-based authentication to reduce reliance on host key verification.

Report generated by Valters IT DevSecOps & CTI Division