CVE-2015-1244 in Chrome
Summary
by MITRE
The URLRequest::GetHSTSRedirect function in url_request/url_request.cc in Google Chrome before 42.0.2311.90 does not replace the ws scheme with the wss scheme whenever an HSTS Policy is active, which makes it easier for remote attackers to obtain sensitive information by sniffing the network for WebSocket traffic.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/09/2022
The vulnerability identified as CVE-2015-1244 resides within the Google Chrome browser's handling of HTTP Strict Transport Security policies, specifically affecting versions prior to 42.0.2311.90. This flaw represents a significant security oversight in the browser's network protocol handling mechanism, where the URLRequest::GetHSTSRedirect function fails to properly transition WebSocket connections from the insecure ws scheme to the secure wss scheme when HSTS policies are enforced. The issue stems from the browser's inability to automatically upgrade WebSocket traffic to secure connections during HSTS enforcement, creating a potential attack vector that undermines the security guarantees provided by HSTS mechanisms.
The technical implementation flaw occurs within the url_request/url_request.cc source file where the HSTS redirect functionality does not account for WebSocket protocols during the security transition process. When a website enforces HSTS policies, Chrome should automatically redirect all subsequent requests to use secure protocols, but this particular function fails to handle WebSocket connections properly. The ws scheme remains unchanged even when HSTS is active, leaving WebSocket traffic vulnerable to interception and inspection. This represents a failure in protocol transition handling and demonstrates a lack of comprehensive security policy enforcement across different network protocols within the browser's request processing pipeline.
The operational impact of this vulnerability extends beyond simple information disclosure, as it creates a persistent attack surface for man-in-the-middle adversaries who can monitor network traffic to capture WebSocket communications that should have been protected by HSTS enforcement. Attackers can exploit this weakness by sniffing network traffic to identify WebSocket connections, potentially gaining access to sensitive data exchanged through these channels without the need for sophisticated attacks. The vulnerability is particularly concerning because WebSocket protocols are commonly used for real-time communication, including financial transactions, messaging applications, and other sensitive data exchanges where secure transport is critical. This flaw effectively undermines the security assurances provided by HSTS, which is designed to prevent protocol downgrade attacks and enforce secure communication channels.
This vulnerability maps directly to CWE-319, which addresses the exposure of sensitive information through the use of insecure protocols, and aligns with ATT&CK technique T1041, which covers data compression and encoding techniques for exfiltration. The flaw demonstrates a failure in secure protocol handling and represents a gap in the browser's security architecture where different protocol families are not uniformly protected by security policies. Organizations using affected Chrome versions remain vulnerable to passive network monitoring attacks that can capture WebSocket traffic, potentially exposing sensitive communications that should have been protected by HSTS enforcement. The vulnerability highlights the importance of comprehensive security policy enforcement across all network protocols and the need for consistent handling of protocol transitions in security-critical applications.
The recommended mitigations include immediate upgrade to Chrome version 42.0.2311.90 or later, which contains the necessary patches to properly handle WebSocket scheme transitions during HSTS enforcement. Network administrators should also implement additional monitoring to detect potential WebSocket traffic interception attempts and consider deploying network segmentation to limit exposure of sensitive WebSocket communications. Organizations should conduct security assessments to identify applications that rely on WebSocket protocols and ensure they are properly configured to enforce secure connections. The fix implemented in the patched version addresses the root cause by ensuring that all WebSocket connections are properly upgraded to secure wss schemes when HSTS policies are active, thereby maintaining consistent security enforcement across different protocol families.