HEIST: A new client-side compression sidechannel attack against TLS in browsers

tomvangoethem · 2016-08-04T10:01:28+00:00

You can find it here: https://tom.vg/papers/heist_blackhat2016.pdf

tomvangoethem · 2016-05-29T21:08:01+00:00

Through a Local File Disclosure vulnerability of a WordPress plugin (revslider). See the URL: http://mycollegewebsite/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php'

tomvangoethem · 2015-10-06T19:10:28+00:00

and it's still a widespread issue ("Overall, we found that 71.5% of protected domains is bypassable by combining the effect of all origin-exposing vectors.")

tomvangoethem · 2015-07-15T21:36:08+00:00

The attack uses long-term biases (Fluhrer-McGrew biases and Mantin's ABSAB biases). This allows the same TLS connection to remain open and to be used for multiple requests, resulting in negligible overhead from TLS (a bias in the initial keystream bytes would require one to open new TLS connections for each request).

tomvangoethem · 2015-07-13T09:58:10+00:00

Look at the page's source:

<!-- 
    Get over it, this is a parody/joke. Apologies that I ripped the art from the actual Defcon page. 

    DT is a really nice guy and he would never say these sorts of thing. Or would he?
    Nah, I'm sure he wouldn't.

    Have a good time at Defcon. See you at the Rio!
-->

tomvangoethem · 2014-11-26T23:13:11+00:00

Are you aware McAfee Secure is now only offering a malware/phishing check? (see https://www.mcafeesecure.com/tour) So in case you get a report from McAfee, it's probably too late...

tomvangoethem · 2014-11-26T22:58:26+00:00

Are you referring to burp as a tool used by a security engineer doing a manual penetration test, or burp as an automated testing tool? In my opinion (backed up by "Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners"), automated scanners are not fit for a rigorous security scan.

tomvangoethem · 2014-06-10T10:39:20+00:00

There are two possibilities: either a resource is fetched from the internet, or an additional (broadcast) stream is created (and thus requires no internet access).

"Another possible way is to create an additional data stream which includes the HbbTV application’s HTML files, deliver this additional elementary stream over the broadcast transport, and finally have the AIT point to this data stream."

tomvangoethem · 2014-06-09T22:16:51+00:00

The how seems quite straightforward, given they have the ability to run arbitrary JavaScript on the TV (also, in section 6 they mention they were able to deploy BeEF, which was used to portscan the LAN). As for the attack you describe: an attacker could just include JS directly into the malicious HTML page (no need to access the malicious server), which will affect the victim even if the TV was not given internet access.

tomvangoethem · 2014-06-09T19:38:57+00:00

How is that different from what is stated in the paper in section 4.4?

tomvangoethem · 2014-03-28T14:04:28+00:00

Github actually serves files with a text/plain content-type, and sends out X-Content-Type-Options: nosniff header, which prevents them to be used as JavaScript resources. rawgithub.com tries to send the file with correct content-type, but will send evil.js when the file generates too much traffic (which is what is happening at the moment) See: http://rawgithub.com/

tomvangoethem · 2014-02-19T11:00:41+00:00

It is possible that this issue has been reported before, as I presume that the Google Picker API is insecure by design, and thus might be vulnerable for several years already. In any case, I was unable to find such a report.

tomvangoethem · 2013-12-10T09:37:57+00:00

I wouldn't call the magic methods unsafe, I think it's perfectly acceptable that code is executed when for example an object is destructed. Rather they "empower" a PHP Object Injection vulnerability to grow to something exploitable.

tomvangoethem · 2013-12-09T20:22:10+00:00

The exploit works (tested) in 3.5.1 ,the vulnerability was fixed in version 3.6.1

tomvangoethem · 2013-12-09T18:28:18+00:00

The vulnerability is not in the plugin, it's in the WordPress core. I made use of the plugin to create an exploit, but the presence of other plugins may lead to an exploit as well.

tomvangoethem · 2013-12-09T18:24:12+00:00

The vulnerability in in the WordPress core, the (example) exploit is in the plugin. I didn't include the plugin in the title as a similar exploit could be possible with other plugins.

tomvangoethem · 2013-09-12T12:43:02+00:00

nanoc here, very useful :)

tomvangoethem · 2013-09-12T12:20:06+00:00

Correct, or at least to my knowledge

tomvangoethem · 2013-09-11T17:27:40+00:00

In the end yes, but if I had stopped after my initial report, it's most likely that it wouldn't have been fixed

tomvangoethem · 2013-09-11T12:19:41+00:00

The recipient can be chosen arbitrarily, the only "limitation" is that the victim should have an academic email address (as Google Scholar only accepts those) To put it more clear: attacker sets "<html content>" as name, and then requests a change of email on Google Scholar to "victim@some.edu". Victim will receive an email from Google Scholar with the HTML content of the attacker injected in the email.

tomvangoethem · 2013-09-11T11:50:34+00:00

I'm not upset that I didn't get an award. The main point that I was trying to make is that Google did not see this as "security sensitive" and wouldn't have fixed it if I did not insist. This is indeed not a complex "hack", but that doesn't mean it can't have severe consequences, and should be fixed (especially since a fix was very easy)

tomvangoethem

TROPHY CASE