[BreachExchange] New attack steals SSNs, e-mail addresses, and more from HTTPS pages

[Inga Goddijn]

http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/

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.

The exploit is notable because it doesn't require a man-in-the-middle
position <https://en.wikipedia.org/wiki/Man-in-the-middle_attack>. 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 secure sockets layer or
transport layer security protocols
<http://en.wikipedia.org/wiki/Transport_Layer_Security> 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 transmission control protocol
<https://en.wikipedia.org/wiki/Transmission_Control_Protocol>, one of the
Internet's most basic building blocks.
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 BREACH
<http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/>
and the CRIME
<http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/>
exploits are able to decrypt payloads by manipulating the file compression
that sites use to make pages load more quickly. HEIST will be demonstrated
for the first time
<https://www.blackhat.com/us-16/briefings/schedule/#heist-http-encrypted-information-can-be-stolen-through-tcp-windows-3379>
on Wednesday at the Black Hat security conference in Las Vegas.

"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."

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, @gmail.com, 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.

HTTP compression is based on the Deflate algorithm
<http://en.wikipedia.org/wiki/DEFLATE>, 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.

To determine the size of an HTTPS-protected response, the attacker
uses an oracle
technique
<http://www.drdobbs.com/understanding-oracle-attacks-on-informat/184405917>
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.
Coming to a Web drive-by near you?
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 cryptographic side channel
<https://en.wikipedia.org/wiki/Side_channel_attack> 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.

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.

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:

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.

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.

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.
Wednesday's demo will show how a malicious ad displayed on *The New York
Times* website is able to painstakingly measure the size of an encrypted
response sent by a fictitious third-party site they dubbed targetwebsite.com
(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).

HEIST is also effective against HTTP/2
<https://en.wikipedia.org/wiki/HTTP/2>, 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.

"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."

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.

"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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160803/e74ed044/attachment.html>