Quicklinks: Home | Contact |

A few new Advisories (Post will be updated regularly)

0 comments Posted by Thierry Zoller

Subscribe to the RSS feed in case you are interested in updates
This is a living post, that will be updated as I release Advisories.

Updates:

  • 02.01.2020 - Added Initial List of Advisories
  • 09.01.2020 - Added Bitdefender and Kaspersky Advisories
  • 12.01.2020 - Added Bitdefender Advisories
  • 13.02.2020 - Added TZO-011/012 ESET and AVIRA Advisories
  • 14.02.2020 - Added TZO-15 F-Secure Advisory


List of advisories: 

Where can I find more information about this bug class ?
I wrote a post about this bug class in 2009 and in essence, it still holds true. The threat landscape has shifted and so have the technical capabilities : https://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html
Why now ?
10 years ago I took a look at ways to evade AV/DLP Engine detection by using various techniques and released a metric ton of Advisories. 10 years later after multiple CISO type roles, I wanted to deep dive again and see how far (or not) the AV  industry has reacted to this class of vulnerabilities. [1,2]

These types of evasions are now actively being used in offensive operations [3]. To my surprise with a few exceptions most AV Vendors haven't appropriately reacted and in some cases I even found the very same vulnerabilities that were patched and disclosed years ago.

Worse than that is the fact that some vendors that were very collaborative in 2008/2009 have now started to ignore submissions (until I threaten disclosure) or are trying to argue that generically evading AV detection is not a vulnerability although they patched and released advisories before. Go figure.

I had a lot of back and forth on this matter, for instance, one vendor argued that this could not be called a vulnerability because it would not impact Integrity,  Availability or Confidentiality. Another Vendor argued that this cannot pose a "risk" to their customers because of XYZ (assumptions).

Well, I am reporting vulnerabilities within products, not risks. Furthermore, the impact on the customer is highly dependant on how the customer contextually uses the product. Something the vendor has rarely any insight into. Trying to calculate the expected loss for a hundred thousand customers is something we shouldn't be doing when handling vulnerability notifications, however, a shocking amount of vendors are unable to understand the difference between a vulnerability and a risk.

Even more bothersome to me is how the bug bounty platforms have created a distorted Reporter/Vendor relationship and mostly are executed to the detriment of the customers. I am collecting my experiences and plan to write a blog post about this phenomenon in the future.

I am hoping that I can finally help to eradicate this bug class and I don't have to come back to this 10 years from now.

[1] Our presentation at Hack.lu and CansecWest entitled "The Death of AV Defence in Depth?"



[2] It didn't go unnoticed - Past Press Coverage: Washington Post, Infoworld, Heise, Security Focus ... etc.






 

An Overview of the BEAST - TLS, CBC, countermeasures (Update 3)

0 comments Posted by Thierry Zoller

Lots of good information floating on the internet on the Proof of Concept (dubbed 'BEAST) against TLS 1.0 by Juliano Rizzo and Thai Duong at the Ekoparty. This Post summaries the credible information available.

This blog post will be continuously updated as new items and possible mitigation emerge. Subscribe to the RSS feed in case you are interested in updates.

Updates
TOC
  • Introduction to BEAST, TLS and CBC
  • Relevant Papers
  • Proposed countermeasures
Introduction to BEAST, TLS and CBC
Juliano and Thai presented a Proof of Concept of an attack against TLS 1.0 is first documented in 2001 and discussed in papers in 2005 and 2006. It was thought to be an impractical attack back then and solved by adding empty fragments into the IV. 

  • This issue was addressed in TLS 1.1 (2005-6) and OpenSSL by inserting  Empty Fragments into the message.
So why is this still and issue today ? 
  • Secondly the OpenSSL option "SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS" is activated by default as it caused incompatibilities with certain SSL stacks. Activating here means removing the mitigation against this attack. It is known that Tomcat, Apache mod_ssl, and Exim disable this feature in OpenSSL by default. Note : The proposed NSS patch (see countermeasures) adds empty application data records, which appears to be more compatible.
To quote Nelson Bolyard on why TLS 1.1 was not introduced sooner in the NSS stack (Currently used by Chrome, Firefox and various servers) :
"There is no significant market demand for TLS 1.1, so we've been working on improvements in 
other areas,such as sharable DBs and full RFC 3280 compliance.  Once TLS 1.2 finally becomes 
an RFC, we will work on that some time thereafter. We believe there will be a demand for 
TLS 1.2 and some of the new cipher suites that require TLS 1.2 as a prerequisite." Source


 What is TLS ? What is CBC ?
Putting it in layman terms, TLS is the new name for SSL. SSL was developed by Netscape and was renamed and reworked into TLS when handed over to the IETF.

More details are available on Wikipedia - The post by the TOR team does an excellent job of explaining TLS, CBC and the attack itself, I highly recommend reading it especially if you are interested in the details.

How does the Attack work ?
The attack has the CVE number CVE-2011-3389 - Thai himself explains the attack and how it was discovered in his blog post "Beast"

Proposed Countermeasures   

Generic Server Recommendations :
  • Short-Term : Prioritize the RC4 Algorithm over CBC based ciphers (AES, DES). See the recommendations by PhoneFactor .
  • Short to Mid-Term : Enable and Offer TLS1.1 or TLS1.2 (Note: Firefox and chrome do not support TLS 1.1 and will fallback). For a compatibility overview look here
In the works : 
  • The publication by Juliano and Thai should create the necessary incentive for Vendors to implement and use TLS1.1 and/or TLS 1.2. I will keep an eye on the usual suspects and collect all relevant support in the "TLS/SSL compatibility Report"
  • The Phone Factor (the guys behind the TLS session renegotiation vulnerability) propose prioritizing RC4 over AES or DES as a short term mitigation.
  • The chrome team has created patches to NSS fixing the issue client-side. (Empty Application Data Records) - it is currently pushes to Chromium Beta channels for testing
  • Various vendor discuss countermeasures in this Bugzilla entry 
Literature
Advisories

 

SSL/TLS Hardening and compatibility report 2011 (updated)

0 comments Posted by Thierry Zoller

Subscribe to the RSS feed in case you are interested in updates


My professional and private commitments made it difficult to maintain a healthly blogging style, I am trying to get back to some blogging on a more regular basis.

Quick Update:
  • G-SEC does no longer operate on a commercial basis, for those that want to join the G-SEC Team and blogging platform drop me (Thierry) a mail.
  • I updated the "TLS/SSL hardening and compatibility Report" to 2011


TLS/SSL hardening and compatibility Report 2011
Notable Changes:
  • Chrome moved from SCHANNEL to NSS, this move enhances the ciphersuites available to XP systems considerably (compared to IE) 
  • Added OPERA ciphersuites
  • Updated: Restructured Tables to reflect usage of NSS by Firefox and Chrome
  • Updated: Fixed typos



Note: I have not re-tested all browsers completely, if you find errors please let me know. The report is can be downloaded here

Signed - Thierry Zoller

 

New Paper: SSL/TLS Hardening and Compatibility report 2010

0 comments Posted by Thierry Zoller

Subscribe to the RSS feed in case you are interested in updates

At last. What started as an "I need an overview of best practise in SSL/TLS configuration" type of idea, ended in a 3 month code, reverse engineer and writing effort. I really hope this comes in handy for you and was worth the effort. This is the "Release candidate" version of the paper, should no errors be found it will be the final version.

This paper aims at answering the following questions :
  • What SSL/TLS configuration is state of the art and considered secure (enough) for the next years?
  • What SSL/TLS ciphers do modern browsers support ?
  • What SSL/TLS settings do server and common SSL providers support ? 
  • What are the cipher suites offering most compatibility and security ?
  • Should we really disable SSLv2 ? What about legacy browsers ?
  • How long does RSA still stand a chance ?
  • What are the recommended hashes,ciphers for the next years to come

The paper includes two tools :
  • SSL Audit (alpha) :  SSL scanner scanning remote hosts for SSL/TLS support (Video)
  • Harden SSL/TLS (beta) : Windows server and client SSL/TLS hardening tool (Video)
Without further ado here is the complete package

PS: In order to know whether this type of publication is useful to some and whether I should spend time on such publications in the future, I would appreciate a heads-up if you find this to be interesting. Thierry

 

Harden SSL/TLS - Tool release

2 comments Posted by Thierry Zoller

Subscribe to the RSS feed in case you are interested in updates
 
“Harden SSL/TLS” allows hardening the SSL/TLS settings of Windows 2000,2003,2008,2008R2, XP,Vista,7. It allows locally and remotely set SSL policies allowing or denying certain ciphers/hashes or complete ciphersuites.

^This tool specifically allows setting policies with regards to what ciphers and protocols are available to applications that use SCHANNEL crypto interface. A lot of windows applications do use this interface, for instance Google Chrome as well as Apple Safari are a few of these. By changing the settings you can indirectly control what ciphers these applications are allowed to use.



Advanced mode
· re-enable ECC P521 mode on Windows7 and 2008R2
· Set TLS Cache size and timeout

Known issues:
· none

Author :
Thierry ZOLLER for G-SEC
Download: Harden TLS/SSL (beta)
Download: Documentation


 

Subscribe to: Posts (Atom)