<div dir="ltr"><a href="http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/">http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/</a><br><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p>The HTTPS cryptographic scheme protecting millions of websites is 
vulnerable to a newly revived attack that exposes encrypted e-mail 
addresses, social security numbers, and other sensitive data even when 
attackers don't have the ability to monitor a targeted end user's 
Internet connection.</p>
<p>The exploit is notable because it doesn't require a <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle position</a>.
 Instead, an end user need only encounter an innocuous-looking 
JavaScript file hidden in an Web advertisement or hosted directly on a 
webpage. The malicious code can then query a variety of pages protected 
by the <a href="http://en.wikipedia.org/wiki/Transport_Layer_Security">secure sockets layer or transport layer security protocols</a>
 and measure the precise file sizes of the encrypted data they transmit.
 As its name suggests, the HEIST technique—short for HTTP Encrypted 
Information can be Stolen Through TCP-Windows—works by exploiting the 
way HTTPS responses are delivered over the <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">transmission control protocol</a>, one of the Internet's most basic building blocks.</p>Once attackers know the size of an encrypted response, they are free to 
use one of two previously devised exploits to ferret out the plaintext 
contained inside it. Both the <a href="http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/">BREACH</a> and the <a href="http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/">CRIME</a>
 exploits are able to decrypt payloads by manipulating the file 
compression that sites use to make pages load more quickly. HEIST will 
be <a href="https://www.blackhat.com/us-16/briefings/schedule/#heist-http-encrypted-information-can-be-stolen-through-tcp-windows-3379">demonstrated for the first time</a> on Wednesday at the Black Hat security conference in Las Vegas.
<p>"HEIST makes a number of attacks much easier to execute," Tom Van 
Goethem, one of the researchers who devised the technique, told Ars. 
"Before, the attacker needed to be in a Man-in-the-Middle position to 
perform attacks such as CRIME and BREACH. Now, by simply visiting a 
website owned by a malicious party, you are placing your online security
 at risk."</p>
<p>Using HEIST in combination with BREACH allows attackers to pluck out 
and decrypt e-mail addresses, social security numbers, and other small 
pieces of data included in an encrypted response. BREACH achieves this 
feat by including intelligent guesses—say, @<a href="http://gmail.com">gmail.com</a>, in the case of an
 e-mail address—in an HTTPS request that gets echoed in the response. 
Because the compression used by just about every website works by 
eliminating repetitions of text strings, correct guesses result in no 
appreciable increase in data size while incorrect guesses cause the 
response to grow larger.</p>
<p>HTTP compression is based on the <a href="http://en.wikipedia.org/wiki/DEFLATE">Deflate algorithm</a>,
 which shortens data streams by storing only the first instance of a 
repeating string such as “value=” inside an HTML document and using 
space-saving pointers each time it's repeated. In general, the more 
repetitions of identical strings found in a data stream, the more 
potential there is for compression to reduce the overall size.</p>
<p>To determine the size of an HTTPS-protected response, the attacker uses an <a href="http://www.drdobbs.com/understanding-oracle-attacks-on-informat/184405917">oracle technique</a>
 that returns what amounts to a yes-or-no response to each guess. When a
 request containing "value=" results in the same data size, the attacker
 knows that string is inside the encrypted response and then tries to 
modify the guess to include the next character, say "value=0". If that 
guess results in a larger file size, the attacker knows it's wrong and 
will try "value=1", "value-=2", and so on until the new guess similarly 
results in a response that shows no increase in file size. The attacker 
then tries to guess the next character and repeats the process until the
 entire token has been recovered.</p>
<h2>Coming to a Web drive-by near you?</h2>
<br>Until
 now, this BREACH-style exploit required the attacker to be able to 
actively manipulate the traffic passing between the Web server and end 
user. A HEIST-enabled BREACH exploit removes that limitation. It does 
this by using TCP characteristics as a quasi <a href="https://en.wikipedia.org/wiki/Side_channel_attack">cryptographic side channel</a>
 to measure the size of an HTTPS response. TCP divides large 
transmissions into smaller fixed-sized chunks called frames and further 
groups frames inside what are called TCP windows, which are sent one at a
 time. TCP sends a new window only after receiving confirmation that 
frames from the previous window were received by the end user.
<p>HEIST is able to count the number of frames and windows sent by 
interacting with a set of newly approved APIs, one called Resource 
Timing and another called Fetch. In the process, they allow a piece of 
JavaScript to determine the exact size of an HTTPS response. The 
malicious HEIST code then works in tandem with BREACH to ferret pieces 
of plaintext out of the encrypted response by adding thousands of 
guesses to requests and analyzing the size of each resulting response.</p>
<p>Van Goethem and fellow researcher Mathy Vanhoef have already 
disclosed their findings to researchers at both Google and Microsoft. 
That means Wednesday's demonstration isn't likely to catch them by 
surprise. Still, when asked how practical the attack is against Gmail, 
Bank of America, and other real-world sites, Van Goethem gave the 
following answer:</p>
<blockquote><p>If I would take my time, and write exploits for a number 
of websites, then visiting a malicious site (it even doesn't have to be a
 malicious one, there could also happen to be a malicious JavaScript 
file on there; there are numerous of possibilities for that to happen), 
could cause a lot of havoc. Probably the most damage could be dealt out 
by exploiting BREACH, as it allows the attacker to read out CSRF tokens.
 Depending on the functionality offered by the website, it could be that
 by knowing the CSRF token the attacker could simply take over the 
complete account of the victim.</p>
<p>I haven't inspected the requests and responses of every website in 
detail, but as a user one should expect the worst. An attacker only has 
to find a single endpoint that contains a secret token and reflects part
 of the request in the response to extract this token. As I mentioned, 
knowing this token is typically enough to compromise the user's account.</p></blockquote>
<p>Van Goethem said the only mitigation he knows of is to disable the 
third-party cookies, since responses sent by the HTTPS site are no 
longer associated with the victim. At the moment, most Web browsers by 
default enable the receipt of third-party cookies, and some online 
services don't work unless third-party cookies are allowed.</p>
Wednesday's demo will show how a malicious ad displayed on <em>The New York Times</em>
 website is able to painstakingly measure the size of an encrypted 
response sent by a fictitious third-party site they dubbed 
<a href="http://targetwebsite.com">targetwebsite.com</a> (see the image below). It will go on to show how that 
information can be used to infer the characters contained in a security 
token designed to prevent cross-site request forgery attacks (see the 
image at the top of this post).

<p>HEIST is also effective against <a href="https://en.wikipedia.org/wiki/HTTP/2">HTTP/2</a>,
 the drop-in replacement for the older HTTP standard that encrypts all 
Web traffic. In some cases, HEIST can abuse new features of HTTP/2 to 
increase the damaging effects.</p>
<p>"If we know that HTTP/2 is used, we can let the browser 
simultaneously request the targeted resource, and another resource that 
contains reflected content," Vanhoef and Van Goethem wrote in a research
 paper that has not yet been published. "Since HTTP/2 is used, both 
requests are sent in parallel to the server, and the server replies to 
them in parallel as well."</p>
<p>It's too early to know if HEIST combined with BREACH will be 
exploited against real people visiting real HTTPS-protected websites. 
Van Goethem said that as sites improve their defenses against cross-site
 scripting (XSS), SQL injection, and cross-site request forgery attacks,
 there's a good chance HEIST will become a more attractive exploit. 
While there's no indication that BREACH has ever been exploited in the 
wild, the new convenience offered by HEIST may change that.</p>
<p>"Regardless of the typical security measures taken by websites, most 
of them will remain vulnerable to BREACH (the attack has been around for
 three years, and nothing has been done to mitigate it—most likely 
because it's far from trivial to do so)," he wrote in an e-mail. 
"Combined with the fact that the only requirement for HEIST is that a 
victim simply has to visit a (malicious) website, we consider it likely 
that attacks such as BREACH over HEIST will become the easiest way to 
compromise accounts."</p></div></div></div></div></div></div></div></div></div>
</div>