Attacks/Breaches
8/8/2013
11:19 AM
50%
50%

30-Second HTTPS Traffic Attack: No Fix

Researchers who discovered BREACH vulnerability promise a tool to see if your site is at risk -- but say there's no easy fix.

The Syrian Electronic Army: 9 Things We Know
(click image for larger view)
The Syrian Electronic Army: 9 Things We Know
No fix is available for an attack that can recover plain-text information from encrypted HTTPS traffic in 30 seconds or less.

The BREACH attack -- short for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext -- was discovered by Salesforce.com lead product security engineer Angelo Prado, Square application security engineer Neal Harris, and Salesforce.com lead security engineer Yoel Gluck. They first presented their findings in full at last week's Black Hat information security conference in Las Vegas. According to the researchers, all versions of the transport layer security (TLS) and secure sockets layer (SSL) protocols are vulnerable to the attack, but not every HTTPS-using site is necessarily at risk.

How can website operators identify if their sites are at risk? In general, the researchers said, vulnerable sites, Web applications and pages will use an HTTP response body -- referring to the set of rules that control the content in an HTTP response -- that employs HTTP compression. Vulnerable sites also will use query string parameters (POST) to reflect user data. Finally, the website must be serving sensitive data -- email addresses, security credentials -- to make it attractive to a would-be attacker.

[ Are the social network moguls right? Read Online Privacy: We Just Don't Care. ]

Prado and his fellow researchers promised to release a tool to allow businesses to test their own sites using proof-of-concept BREACH exploit code. "I am in the process of cleaning up the code and hope to publish it within a week, hopefully by Sunday. It would be a standalone tool that you can run locally (currently in .NET) and target our PoC site," said Prado via email, referring to a proof-of-concept site. "Then you could just adjust the targets and hopefully point against [your] own sites."

To be clear, the tool can't be used to scan the Web at large and find vulnerable sites. "The tool is not a scanner, you'd actually have to identify a vulnerable endpoint first, this requires a human," Prado said. "In the meantime the 'Am I Affected' section of breachattack.com should be a good start for manual testing with a tool such as Fiddler," which is a free debugging tool.

What happens if a site might be vulnerable? "Unfortunately, we are unaware of a clean, effective, practical solution to the problem," said the researchers on their breachattack.com site. "Some of these mitigations are more practical and a single change can cover entire apps, while others are page specific." They added: "Whichever mitigation you choose, it is strongly recommended you also monitor your traffic to detect attempted attacks."

The most effective technique for mitigating the vulnerability is to disable HTTP compression, which is used to make the best use of bandwidth and server processing capabilities for a faster browsing experience. Compression involves replacing duplicate series of bytes with a pointer to the original string, and shortening commonly used symbols. But employing compression means that HTTPS traffic is vulnerable to a padding oracle attack, in which an attacker -- who's able to eavesdrop on HTTPS communications -- can look at the size of the packets being transmitted, and by sending HTTPS requests, ultimately deduce the information being transmitted.

"In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests," Prado said, referring to session tokens. "A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command and control center."

Despite that threat, disabling HTTP compression isn't typically feasible, because compression makes possible the Web server performance and page-response times that site administrators and users have come to expect, according to Ars Technica.

Other less-effective mitigation techniques suggested by the researchers include "separating secrets from user input" -- which would likely involve redesigning website server software – or masking secrets by making them random. Other techniques include adding a random number of bytes to HTTP response messages to hide their true length, and rate-limiting HTTPS requests.

But many of the potential fixes carry their own baggage, and don't actually fix the underlying HTTPS problem. Or as noted by the "BREACH vulnerability in compressed HTTPS" advisory released last week by the Department of Homeland Security: "We are currently unaware of a practical solution to this problem."

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The Impact of a Security Breach 2017
The Impact of a Security Breach 2017
Despite the escalation of cybersecurity staffing and technology, enterprises continue to suffer data breaches and compromises at an alarming rate. How do these breaches occur? How are enterprises responding, and what is the impact of these compromises on the business? This report offers new data on the frequency of data breaches, the losses they cause, and the steps that organizations are taking to prevent them in the future.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.