HEIST - A new exploit to steal data from HTTPS pages
24 replies, posted
[QUOTE]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. 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 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, one of the Internet's most basic building blocks.[/QUOTE]
Source: [url]http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/[/url]
Detailed PDF describing the exploit: [url]https://tom.vg/papers/heist_blackhat2016.pdf[/url]
[B]TL;DR[/B]
By default, when doing a cross-origin AJAX request, you are unable to actually access the response of said request, this is to prevent accessing private information.
HEIST can be used in conjunction with BREACH or CRIME to abuse the compression used to make responses faster (gzip). Long story short: you can check whether a string is present in an encrypted response by looking for changes in the size of the response.
What HEIST actually does is remove the need for an MITM attack as it can retrieve the size of the response.
The people who found this out are absolute geniuses.
Isn't this only for SSL (v1) which shouldn't be used anymore anyway?
[QUOTE=Darkwater124;50830851]Isn't this only for SSL (v1) which shouldn't be used anymore anyway?[/QUOTE]
No it's not an issue with SSL itself, the actual issue is with the compression algorithms, but that was already known for about 3 years but you had to perform a man in the middle attack to do that since you needed the size of the response. With HEIST all it takes is some malicious javascript running in your browser.
And yet another reason to never disable adblock and noscript
what's so dangerous about knowing the size of a message that's still encrypted?
[QUOTE=bitches;50831148]what's so dangerous about knowing the size of a message that's still encrypted?[/QUOTE]
Because it helps you break the encryption or decipher the message?
[QUOTE=bitches;50831148]what's so dangerous about knowing the size of a message that's still encrypted?[/QUOTE]
think like that: Tim got 5 bucks and entered into a condom store, when he left he only had a penny. what do you think tim purchased?
[QUOTE=Andre Gomes;50831424]think like that: Tim got 5 bucks and entered into a condom store, when he left he only had a penny. what do you think tim purchased?[/QUOTE]
4 chewing gums.
Seriously now; knowing the length of some content is pretty useless on its own, you have to bundle it with something else, like the [URL="https://en.wikipedia.org/wiki/CRIME"]CRIME[/URL] or [URL="https://en.wikipedia.org/wiki/BREACH_(security_exploit)"]BREACH[/URL].
How it's used is actually pretty simple, it relies on how the compression algorithm works. When crafting requests to the target size you observe the change in the data. If the size of the data is reduced, it means some of the injected content matches some part of the source. You can iterate over this multiple times to get an exact match on the data. That's the simplified version.
A bank or serious website isn't going to have ads on any https page. Seems like this will be more relevant on forums, news, etc with ads trying to grab passwords.
[QUOTE=I Am A Rock;50833371]A bank or serious website isn't going to have ads on any https page. Seems like this will be more relevant on forums, news, etc with ads trying to grab passwords.[/QUOTE]
No. This works from any site by forging requests to the target site. What you described is used in XSS attacks.
So how would you go about preventing this exploit as an end user (I guess just adblock and what not) and website developer?
Surely if they have managed inject script onto your page you have already lost anyway?
[QUOTE=_RJ_;50833904]So how would you go about preventing this exploit as an end user (I guess just adblock and what not) and website developer?[/QUOTE]
As an end user, your only luck is disabling 3rd party cookies.
Don't have time to read the article, but Javascript doesn't let you get any info about an external source -- including size of the reply.
[editline]5th August 2016[/editline]
Hell, it won't even initiate the connection if it doesn't obey same origin rules.
[QUOTE=Map in a box;50837604]Javascript doesn't let you get any info about an external source -- including size of the reply.[/QUOTE]
That's exactly what the exploit is about: getting the size of the reply.
[QUOTE=Map in a box;50837604]Hell, it won't even initiate the connection if it doesn't obey same origin rules.[/QUOTE]
Same-Origin rules prevents you from reading the response, not initiating it.
The PDF is assuming a lot -- like being able to easily know the size of the response HTTP headers/SSL initiation; thats simply not feasible and is making a lot more assumptions than are true.
[editline]6th August 2016[/editline]
cross-origin checks which most major sites have will prevent this exploit from working as well.
how do you protect yourself from this? anyways?
[QUOTE=J!NX;50840321]how do you protect yourself from this? anyways?[/QUOTE]
Don't access sensitive info on public wifi
[editline]6th August 2016[/editline]
Wait shit didn't read it
[editline]6th August 2016[/editline]
From the sounds of it noscript + adblock would stop it.
[QUOTE=J!NX;50840321]how do you protect yourself from this? anyways?[/QUOTE]
More of a thing for websites to fix. It really isn't as dangerous as the article says it is, it won't be able to do anything substantial due to how necessary it is to predict the unpredictable.
[QUOTE=Map in a box;50840368]More of a thing for websites to fix. It really isn't as dangerous as the article says it is, it won't be able to do anything substantial due to how necessary it is to predict the unpredictable.[/QUOTE]
The exploit is happening on the browser, from what I read. This means there is a vulnerability in the browser, so browsers need to be updated to protect against this attack. Most likely adding restrictions to the javascript environment. Or a new TLS version needs to be made that encrypts the length of the message, however this might have implementation challenges.
What's the alternative for NoScript on chrome? I checked the app store, didn't see it there.
[QUOTE=Winded;50840779]The exploit is happening on the browser, from what I read. This means there is a vulnerability in the browser, so browsers need to be updated to protect against this attack. Most likely adding restrictions to the javascript environment. Or a new TLS version needs to be made that encrypts the length of the message, however this might have implementation challenges.[/QUOTE]
The exploit takes heavy guessings on the size of the HTTP headers. And even if that weren't the case, the exploits would be easily mitigated on the server's end using headers that don't allow cross-site requests.
[editline]6th August 2016[/editline]
You can't just encrypt the length of the message.
[QUOTE=Ricenchicken;50841062]What's the alternative for NoScript on chrome? I checked the app store, didn't see it there.[/QUOTE]
If uMatrix is offered I cannot recommend it enough. The default settings are basically NoScript, but the things it blocks are separated into their content types rather than just blocking scripts and frames. So if you really don't trust a site, but need to see an image, you could unblock images only.
Well lads, better hope that none of the ad provider networks have a malicious ad circulating and all your most loved sites are XSS proofed.
[QUOTE=hexpunK;50841107]If uMatrix is offered I cannot recommend it enough. The default settings are basically NoScript, but the things it blocks are separated into their content types rather than just blocking scripts and frames. So if you really don't trust a site, but need to see an image, you could unblock images only.
Well lads, better hope that none of the ad provider networks have a malicious ad circulating and all your most loved sites are XSS proofed.[/QUOTE]
For people that want to prevent this entirely on their own server, add:
[code]
x-xss-protection: 1; mode=block
[/code]
to their headers, and don't allow requests to finish that don't match the right Origin
Sorry, you need to Log In to post a reply to this thread.