Skip to content

DROWN Attack on SSLv2/TLS

DROWN Attack on SSLv2/TLS

Description

This vulnerability indicates that the server is susceptible to DROWN attacks, which exploit SSLv2 support to decrypt modern TLS connections through cross-protocol Bleichenbacher padding oracle attacks.

DROWN (Decrypting RSA with Obsolete and Weakened encryption) occurs when servers support the obsolete SSLv2 protocol alongside modern TLS. Even if clients never use SSLv2, attackers can exploit SSLv2's weak RSA padding implementation to decrypt captured TLS sessions that share the same private key.

How It Works:

  1. Attacker captures hundreds of TLS connections between client and server
  2. Using the same RSA private key, attacker connects to SSLv2 service on same/different server
  3. Sends specially crafted SSLv2 handshake messages with modified RSA ciphertext
  4. SSLv2 server responses leak information about private key through padding oracle
  5. After ~40,000 probes, attacker can decrypt one of the captured TLS sessions

Requirements:

  • Target server or related server supports SSLv2 with same RSA private key
  • RSA key exchange used in TLS connections (not ECDHE/DHE)
  • Network access to capture TLS traffic and probe SSLv2 services
  • Computational resources for cryptographic attacks ($440 on cloud)

Example Scenario: A bank's HTTPS website properly disables SSLv2, but their SMTP email server on the same infrastructure supports SSLv2 using the same RSA certificate. An attacker captures customer TLS sessions to the website, then makes thousands of crafted SSLv2 connections to the email server. The weak SSLv2 padding oracle reveals enough information to decrypt the captured HTTPS sessions, exposing login credentials and financial data.

The attack exploits legacy export-grade cryptography restrictions from the 1990s, demonstrating how government-mandated crypto weakening continues to threaten modern security decades later.

Recommendation

To mitigate DROWN attacks:

Primary Defense - Disable SSLv2 Completely:

# Apache - disable SSLv2
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:!aNULL:!MD5:!SSLv2:!SSLv3

# Nginx - disable SSLv2 (already disabled by default)
ssl_protocols TLSv1.2 TLSv1.3;

Update OpenSSL:

Upgrade to patched versions: - OpenSSL 1.0.2g or later - OpenSSL 1.0.1s or later - These versions disable SSLv2 and export ciphers by default

Check ALL Services Using Same Private Key:

Critical: Ensure no other services support SSLv2: 

# Check for SSLv2 support across all services
nmap --script ssl-enum-ciphers -p 443,993,995,25,587,465 example.com

# Test specific service for SSLv2
openssl s_client -connect mail.example.com:993 -ssl2

Common vulnerable services: - SMTP servers (port 25, 587, 465) - IMAP servers (port 993) - POP3 servers (port 995) - Secondary web servers - Load balancers and proxies

Generate New Keys if Needed:

If you cannot confirm SSLv2 is disabled everywhere: 

# Generate new RSA private key
openssl genrsa -out new-private-key.pem 2048

# Create new certificate signing request
openssl req -new -key new-private-key.pem -out new-csr.pem

Additional Protections:

  • Use ECDHE/DHE cipher suites for perfect forward secrecy
  • Implement certificate pinning where possible
  • Monitor logs for unusual SSLv2 connection attempts
  • Consider network-level filtering of SSLv2 traffic

The key insight: ANY service sharing your private key that supports SSLv2 makes ALL your TLS services vulnerable, even if they individually disable SSLv2.

Standards

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_4_1
    • REQ_6_2
    • REQ_11_3