How the HTTPS-snooping, email addy and SSN-raiding HEIST JavaScript code works Malicious ads can potentially masquerade as people online and grab their personal information from HTTPS-protected websites, two boffins have shown. The technique is dubbed HEIST – HTTP Encrypted Information can be Stolen through TCP-Windows – and it was devised by Tom Van Goethem and Mathy Vanhoef, both PhD researchers at the …
Sadly, and as noted in the article, 3rd party cookies are *still* enabled by default in most browsers. And most people don't know their browsers have options, let alone what they should set them to. So the default setting abides for most users.
Which is a good thing, of course, because without third-party cookies being enabled, advertising revenue might be affected in some way to some extent, and therefore the interwebs will implode and the terrorists will have won. Is that what you want?
And the inbuilt cookie control settings on most browsers seem to get less and less useful (less flexible / configurable) (As Mark Simon described for Firefox)
On most browsers I use I have to use cookie controlling plugins for any decent level of fine grained cookie management (e.g. 3rd party cookies "never" is fine most of the time but there are occasions when I want to allow certain specific third party cookies on certain sites only).
3rd party cookies are required by some websites in order to work. This is more true now that in the past, mostly due to CDNs and the like where user data might be stored on both the primary domain (company.com) as well as (compCDN.com or company.CDNprovider.com). My bank does this for their online banking portal where the main website and unencrypted content comes from cloudflare, but the secure data comes from the bank's domain.
Sites can also perform detection. If a site is receiving an abnormal number of requests from an IP address for the same resource within a small amount of time something is not right. An IP address will typically request many resources in a short period of time but usually for the different resources a browser needs to present a page. It's unusual for an IP address to access the same resource more the a few times in a short window of time. A user might refresh a page quickly once or twice but it's not likely they will be be refreshing the page several times even in a few seconds..
Even our noddy site site performs these tests and blocks the offending IP address at the firewall so they are unable to proceed. We see attacks like this all the time, especially to registration pages, and are usually blocking one or two IP addresses per hour. I like to think that more sophisticated sites perform similar real-time checks if only out of self-interest because such attacks consume resources and capacity.
I wonder if this slowing down of the attack will prove effective. They may be still able to purloin some sensitive information.
It may be easier to return forms uncompressed or introduce some random noise into the page. (random hidden text of varying length)
It sounds like the fix needs to be on the content creators sites, unfortunately
"Malicious ads can potentially masquerade as people online and grab their personal information from HTTPS-protected websites"
And this is why I'll never uninstall my ad blocker. I don't block ads because they're annoying (which they surely are), I block them because they're an untrustworthy menace.
Yet another way to fuck up somebodies computer is based on ADS.
And they seriously wonder why people are so god damn fed up of this SHIT !!!!
sorry for being so ranty, but I cannot stand the factg so much of our computer use is screwed up just so levi's can try to convince me I need so slide my fat arse into skinny jeans ......
"We want to find out the email address. So first we send aaa@example.com and get back, say, 200 bytes of compressed encrypted data. We next send a combination of addresses until we hit bob@example.com and get back 184 bytes"
So in other words it just guesses at the email address. Presumably it'll have to do the same for any bank account/social security numbers too? Good luck with that. I suspect the bank server will become suspicious at all the failed attempts and lock the account long before the trojan manages to guess anything succesfully.
Is the desperate acronym. That has to be up there near the top, beating even the US government ones such as USA PATRIOT:
Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001"
As well as:
http://www.motherjones.com/mojo/2014/08/congress-acronyms-backronyms-bill-names
But if you are a server op, simply turning off compression on your https connections mitigates this attack.
This has been a best practice for a while, but as you can imagine there a LOT of sites out there that don't do this, including your regular high-street banks.
Unfortunately the timings for just the request are available, meaning that you are looking at entirely client-generated data, a large proportion of which is the cookies.
You could just throw a new random-noise cookie into every response though, which might work.
The problem isn't ads qua ads. It's ads served from third party servers. The whole concept is stupid and dangerous.
If you want to run ads, for goodness sake, feel free. But use your own machines to host them, consume your own bandwidth to serve them, and accept responsibility for their contents.
Yes, noscript is the answer, and it has been for quite some time. If you have any sense, you would install it and keep using it.
Of course, logging out of your banking (or other sensitive) web site is also a good idea. One must vigilant when it comes to $$$ or other similar sensitive data.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
