How to remediate – Transport Layer Security (TLS) Protocol CRIME Vulnerability

1. Introduction

2. Technical Explanation

The CRIME attack exploits weaknesses in TLS implementations when compression is enabled. Specifically, it abuses the ability to predict HTTP response content, allowing an attacker to recover parts of encrypted data. The vulnerability requires that the server uses SSL/TLS compression or advertises support for the SPDY protocol prior to version 4. Nessus has identified a configuration on this remote service which may be vulnerable but did not attempt exploitation. CVE-2012-4929 and CVE-2012-4930 relate to this issue.

• Root cause: SSL/TLS compression is enabled, or SPDY protocol version 3.x is advertised.
• Exploit mechanism: An attacker sends specially crafted requests to the server and analyses the compressed responses to deduce plaintext data. For example, an attacker could attempt to recover cookies from encrypted traffic.
• Scope: Web servers using OpenSSL versions prior to 1.0.1e are affected when compression is enabled or SPDY v3 is advertised.

3. Detection and Assessment

Confirming vulnerability involves checking the TLS configuration of a server. A quick check can identify if compression is active, while more thorough scanning can reveal SPDY protocol support.

• Quick checks: Use `openssl s_client -connect :` and look for “compression” in the output.
• Scanning: Nessus plugin ID 63958 identifies this vulnerability. Other scanners may have similar signatures.
• Logs and evidence: Examine server logs for TLS handshake details, looking for cipher suites that include compression algorithms.

openssl s_client -connect example.com:443

4. Solution / Remediation Steps

The primary solution is to disable compression and/or the SPDY service on affected servers. This reduces the attack surface and prevents exploitation of the CRIME vulnerability.

4.1 Preparation

• Dependencies: Ensure you have access to modify the server’s SSL/TLS configuration. Roll back plan: Restore from backup if issues occur.
• Change window: Schedule during off-peak hours, and obtain approval from relevant teams.

4.2 Implementation

1. Step 1: Disable compression in the server’s SSL/TLS configuration file (e.g., Apache httpd.conf or Nginx nginx.conf).
2. Step 2: If SPDY is enabled, disable it or upgrade to version 4 or later.
3. Step 3: Restart the web server service for changes to take effect.

4.3 Config or Code Example

Before

SSLCompression on

After

SSLCompression off

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and similar vulnerabilities. Least privilege reduces the impact of exploitation, while secure defaults minimise misconfigurations. Patch cadence ensures timely application of fixes.

• Practice 1: Least privilege limits an attacker’s access if a vulnerability is exploited.
• Practice 2: Secure defaults reduce the risk of accidental exposure through unsafe configurations.

4.5 Automation (Optional)

Configuration management tools can automate disabling compression across multiple servers.

# Example Ansible task to disable SSL compression
- name: Disable SSL Compression in Apache
  lineinfile:
    path: /etc/apache2/mods-enabled/ssl.conf
    regexp: '^SSLCompression on'
    line: 'SSLCompression off'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run `openssl s_client -connect :` and confirm “compression” does not appear in the output.
• Re-test: Re-run the Nessus scan (plugin ID 63958) to verify the vulnerability is no longer detected.
• Monitoring: Monitor server logs for TLS handshake details, ensuring compression algorithms are not used.

openssl s_client -connect example.com:443 | grep "compression"

6. Preventive Measures and Monitoring

• Baselines: Update a security baseline or policy to require SSL compression to be disabled.
• Pipelines: Add checks in CI/CD pipelines to scan for insecure TLS configurations.
• Asset and patch process: Implement a monthly patch review cycle for critical systems.

7. Risks, Side Effects, and Roll Back

Disabling compression may slightly reduce performance, but the security benefits outweigh this risk. Rolling back involves re-enabling compression in the server configuration file.

• Risk or side effect 1: Minor performance impact due to disabling compression.
• Roll back: Restore the original SSL/TLS configuration from backup. Restart the web server service.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?c44d5826
• NVD or CVE entry: CVE-2012-4929, CVE-2012-4930
• Product or platform documentation relevant to the fix: https://www.iacr.org/cryptodb/data/paper.php?pubkey=3091