How to remediate – Weak DH Key Exchange Supported (PCI DSS)

1. Introduction

The Weak DH Key Exchange Supported vulnerability means a service on your network allows connections using an older, less secure method for establishing encrypted communications. This impacts confidentiality as attackers could potentially intercept and read sensitive data. Systems offering SSH, TLS/SSL, or VPN services are commonly affected. A successful exploit could lead to loss of confidential information.

2. Technical Explanation

This vulnerability occurs when a service uses Diffie-Hellman (DH) key exchange with a public modulus smaller than 2048 bits. DH keys below this size are considered insecure according to NIST Special Publication 800-57 Part 1. An attacker could exploit this by attempting to establish a connection using the weak DH parameters, and then use known mathematical techniques to break the encryption.

• Root cause: The service is configured to accept Diffie-Hellman key exchange with a public modulus less than 2048 bits.
• Exploit mechanism: An attacker initiates a connection attempt using a client that supports weak DH parameters. If successful, they can then attempt to decrypt the communication.
• Scope: Systems running SSH servers, TLS/SSL-enabled web servers (like Apache or Nginx), and VPN services are affected. CVE-2015-4000 details this issue in OpenSSL.

3. Detection and Assessment

You can check for vulnerable systems by examining service configurations and running network scans. A quick check involves looking at the SSH daemon configuration. More thorough assessment requires a vulnerability scanner.

• Quick checks: Check your SSH server config file (usually /etc/ssh/sshd_config) for `DHGroup` settings. If set to 1 or 2, it likely uses weak DH parameters.
• Scanning: Nessus plugin ID 74733 can detect this vulnerability. OpenVAS also has relevant scans. These are examples only.
• Logs and evidence: Examine TLS/SSL handshake logs for cipher suites using Diffie-Hellman key exchange with a modulus smaller than 2048 bits. The specific log location varies by service (e.g., Apache access logs, Nginx error logs).

ssh -V # Check OpenSSH version; older versions may default to weaker DH settings

4. Solution / Remediation Steps

The best solution is to reconfigure the service to use at least 2048-bit DH parameters or disable DH entirely in favour of Elliptic-curve Diffie-Hellman (ECDH). Follow these steps carefully.

4.1 Preparation

• Ensure you have access to the server console or a reliable remote connection in case of issues. A roll back plan is to restore the backed-up configuration file and restart the service.
• Changes may require a maintenance window, depending on the service’s criticality and user impact. Approval from your change management team might be needed.

4.2 Implementation

1. Step 1: Edit the service’s configuration file (e.g., /etc/ssh/sshd_config for SSH).
2. Step 2: Change the `DHGroup` setting to a stronger group, such as `5`, or remove it entirely and rely on ECDH.
3. Step 3: If using TLS/SSL, update the cipher suite configuration to prioritize modern ciphers that use ECDHE over DH.
4. Step 4: Restart the service for the changes to take effect.

4.3 Config or Code Example

Before

# /etc/ssh/sshd_config
DHGroup 1

After

# /etc/ssh/sshd_config
DHGroup 5 # Or remove the line entirely to rely on ECDH.

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of a compromised service. Regular patch management ensures you’re running secure versions of software. Secure configuration baselines enforce strong settings by default.

• Practice 1: Implement least privilege to limit the damage if an attacker compromises a service using weak cryptography.
• Practice 2: Maintain a regular patch cadence for all servers and network devices.

4.5 Automation (Optional)

Ansible can automate configuration changes across multiple systems. Use caution when automating SSH configurations, as incorrect settings can lock you out of servers.

---
- hosts: all
  tasks:
    - name: Update sshd_config to use stronger DH group
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^DHGroup 1'
        line: 'DHGroup 5'
      notify: Restart SSHD
  handlers:
    - name: Restart SSHD
      service:
        name: sshd
        state: restarted

5. Verification / Validation

Confirm the fix by checking the service configuration and running a vulnerability scan. A negative test involves attempting to connect using a client configured for weak DH parameters.

• Post-fix check: Run `ssh -V` again. Check your SSH server config file (usually /etc/ssh/sshd_config) and confirm the `DHGroup` setting is now 5 or removed.
• Re-test: Re-run Nessus plugin ID 74733 or OpenVAS scan to verify the vulnerability is no longer detected.
• Smoke test: Test SSH login functionality with a standard user account to ensure connectivity remains intact.
• Monitoring: Monitor TLS/SSL handshake logs for any cipher suites still using weak DH parameters.

ssh -V # Expected output should show updated OpenSSH version and no mention of weak DH groups

6. Preventive Measures and Monitoring

• Baselines: Update your CIS benchmark or internal security policy to require at least 2048-bit DH parameters or ECDH.
• Pipelines: Add SAST tools to your CI/CD pipeline to scan configuration files for insecure settings like weak DH groups.
• Asset and patch process: Review and apply security patches on a monthly basis, prioritizing critical vulnerabilities like this one.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Older clients may not support ECDH and require a downgrade to a weaker but still acceptable cipher suite.
• Roll back: Restore the backed-up service configuration file and restart the service.

8. References and Resources

• Vendor advisory or bulletin: https://weakdh.org/
• NVD or CVE entry: Updated on October 26, 2025