CVE-2024-34447

7.5 HIGH

📋 TL;DR

This vulnerability in Bouncy Castle's TLS implementation allows DNS poisoning attacks to bypass hostname verification when SSL sockets are created without explicit hostnames. It affects Java applications using BCJSSE with endpoint identification enabled, potentially enabling man-in-the-middle attacks. Systems using HttpsURLConnection or similar patterns without explicit hostname specification are vulnerable.

💻 Affected Systems

Products:
  • Bouncy Castle Crypto Package for Java
  • Applications using BCJSSE
  • Java applications with HttpsURLConnection
Versions: BC TLS Java before 1.0.19 (ships with BC Java before 1.78, BC Java (LTS) before 2.73.6), BC FIPS TLS Java before 1.0.19
Operating Systems: All platforms running Java with affected Bouncy Castle versions
Default Config Vulnerable: ⚠️ Yes
Notes: Vulnerability requires endpoint identification to be enabled and SSL sockets created without explicit hostnames (as with HttpsURLConnection default usage).

⚠️ Manual Verification Required

This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.

Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).

🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.

Recommended Actions:
  1. Review the CVE details at NVD
  2. Check vendor security advisories for your specific version
  3. Test if the vulnerability is exploitable in your environment
  4. Consider updating to the latest version as a precaution

⚠️ Risk & Real-World Impact

🔴

Worst Case

Successful DNS poisoning leads to complete TLS session interception, allowing attackers to decrypt sensitive data, inject malicious content, or impersonate legitimate services.

🟠

Likely Case

Attackers could redirect traffic to malicious servers, intercept authentication tokens, or steal sensitive information from vulnerable applications.

🟢

If Mitigated

With proper network controls and DNS security measures, the attack window is limited, but the vulnerability still exposes applications to potential MITM attacks.

🌐 Internet-Facing: HIGH
🏢 Internal Only: MEDIUM

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ⚠️ Yes
Complexity: MEDIUM

Exploitation requires DNS poisoning capability and targeting of vulnerable applications. The vulnerability is in the verification logic rather than requiring code execution.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: BC TLS Java 1.0.19 or later (BC Java 1.78+, BC Java (LTS) 2.73.6+), BC FIPS TLS Java 1.0.19+

Vendor Advisory: https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9034447

Restart Required: Yes

Instructions:

1. Update Bouncy Castle libraries to patched versions. 2. Update dependencies in build configuration (Maven/Gradle). 3. Rebuild and redeploy affected applications. 4. Restart Java applications/services.

🔧 Temporary Workarounds

Explicit Hostname Specification

all

Always specify explicit hostnames when creating SSL sockets instead of relying on DNS resolution.

// Java code example: SSLContext context = SSLContext.getInstance("TLS");
// context.init(null, null, null);
// SSLSocketFactory factory = context.getSocketFactory();
// SSLSocket socket = (SSLSocket)factory.createSocket(hostname, port);

🧯 If You Can't Patch

  • Implement DNS security measures (DNSSEC, DNS filtering) to prevent poisoning attacks
  • Use network segmentation and monitoring to detect unusual DNS activity

🔍 How to Verify

Check if Vulnerable:

Check Bouncy Castle version in classpath: java -cp "your-app.jar:bcprov-jdk*.jar" -Djava.security.debug=jar 2>&1 | grep -i bouncy

Check Version:

java -cp "bcprov-jdk*.jar" org.bouncycastle.util.test.Test 2>&1 | grep -i version

Verify Fix Applied:

Verify updated Bouncy Castle JAR files are present and version numbers match patched versions

📡 Detection & Monitoring

Log Indicators:

  • Unexpected certificate validation failures
  • SSL handshake errors with unusual hostnames
  • DNS resolution errors preceding TLS connections

Network Indicators:

  • Unusual DNS queries preceding TLS connections
  • TLS connections to unexpected IP addresses
  • Certificate mismatches in TLS sessions

SIEM Query:

source="dns" AND query_type="A" AND response_code="NOERROR" | join query="source=\"tls\" AND dest_ip=*" on dest_ip

🔗 References

📤 Share & Export