Preamble :

During my research on TLS/SSL Compatibility across different Operation Systems and Browsers I created supporting tools for myself and later decided to release them for the public.

"SSL Audit" remotely scans web servers for SSL support - unlike other tools it is not limited to ciphers supported by underlying SSL engines such as "OpenSSL" or "NSS" but can detect cipher suites based on it's own (simplistic) SSL/TLS engine. As a gimmick it features an innovative Fingerprinting engine that is based on behavioral heuristics.



Final release for my paper explaining the different attack vectors and impacts for (CVE-2009-3555) "TLS / SSL renegotiation vulnerability".

  • Added comments and corrections by Alun Jones (Who I hereby thank for his time)
  • Changed FTPS description
  • Better PDF output
I profit from the update to stress particular impacts that seem to be forgotten about, in addition to the plain-text injection described everywhere (Please refer to the paper to know more)

Additional Impacts
  • Potentially allows to downgrade from HTTPS to HTTP (à la SSLstrip)
  • Potentially allows to inject XSS into Trace requests
Available Tools (2011)
I have been delighted by the interest given to this paper at the time, the paper is referenced by the US-CERT, DFN-CERT, BELNET-CERT, SWITCH-cert, Nessus, Qualys, c't Heise and the book "IPhone and IOS Forensics: Investigation, Analysis and Mobile Security" covers the analysis on Page 110

Download "TLS/SSL Session Renegotiation Vulnerability Explained"


A colleague of mine spotted the below while doing expenses - The photograph below shows two separate receipts from two parking buildings that are not far away from each other in central Luxembourg (est. 1km). Both were paid by credit card / debit card.

Update:  Bruce Schneier thoughts on this matter


As some regulars might have noticed I restructed this blog a bit trying to get rid of some clutter. At the same time I updated a few specific pages I wanted to point out :



Since this is a rather old topic with both sides having valid points I will keep this post short and sweet. I have had no time to measure of investigate in depth and I don't think I will find any.

Both have understandable view points, so let's have a look.


Secure renegotiation makes it easier - THC-SSL DoS
Short non technical background story, when SSL connections are setup they require server-side computational effort (RSA decryption), if you try to setup connections repeatedly this will consume a lot of ressources on the server and might lead to Denial of Service.

THC makes use of the secure renegotiation feature recently introduced to setup ssl connections repeatably, in fact they are using a security feature for abuse.

On the word press site it is claimed that :

Interesting here is that a security feature that was supposed to make SSL more secure makes it indeed more vulnerable to this attack:
URLs :

By Design (Eric Rescorla)

Eric takes a very factual systematic approach to this issue, particularly with regards to the claim that the renegotiation feature makes it "more vulnerable to this attack". (Errata: I previously attributed the blog to Marsh Ray)

The holistic view point by Eric includes the total costs for the attacker to achieve this attack, this is a standard approach to weight whether a certain path an attacker can take is more costly for him and hence less likely to be chosen :
If I want to mount the old, multiple connection attack, I need to incur the following costs:
  1. Do the TCP handshake (3 packets)
  2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
  3. Send the SSL/TLS ClientKeyExchange, ChangeCipherSpec, Finished messages (1 packet). These can also be canned.
 His viewpoint on the same exhaustion attack using the secure renegotiation mechanism that is claimed to be make it "more vulnerable" :
Now let's look at the "new" single connection attack based on renegotiation. I need to incur the following costs
  1. Do the TCP handshake (3 packets) [once per connection.]
  2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
  3. Receive the server's messages and parse the server's ServerHello to get the ServerRandom (1-3 packets).
  4. Send the SSL/TLS ClientKeyExchange and ChangeCipherSpec messages (1 packet).
  5. Compute the SSL/TLS PRF to generate the traffic keys.
  6. Send a valid Finished message.
  7. Repeat steps 2-7 as necessary.
Eric goes on with :
Briefly then, we've taken an attack which was previously limited by network bandwidth and slightly reduced the bandwidth (by a factor of about 2 in packets/sec and less than 10% in number of bytes) at the cost of significantly higher computational effort on the attacker's client machines. Depending on the exact characteristics of your attack machines, this might be better or worse, but it's not exactly a huge improvement in any case.
and finally concludes with :
All the known defenses are about trying to make it easier to distinguish legitimate users from attackers before you've invested a lot of resources in them, but this turns out to be inherently difficult and we don't have any really good solutions
 I for one rest my case, there isn't anything more to say on this particular subject.

URL :
Recommendations  / FAQ
http://orchilles.com/2011/04/ssl-renegotiation-dos-faq.html



TOC

  • Introduction
  • Updates
  • Attacker Classes
  • Attacker Pyramid
  • Q&A

Updates

  • 24.10.2011 - Renamed "Business Asset" to "Typical Targeted Asset", added Sophistication Pyramid
  • 24.10.2011 - Added Q&A section
  • 17.05.2012 - Added my OWASP BeNeLux presentation, which is inline with the overall context and further explains the rationale
  • 17.05.2012 - Renamed "Targeted" to "Professional" in the pyramid for consistency

Introduction

At OWASP BeNeLux 2011 I presented The Rise of the Vulnerability Markets - History, Impacts, Mitigations, which sets out the reasoning behind the attacker-centric model and the impacts and motivations that follow from it - the pieces that make it useful as an input to threat modelling.

Attacker Classes

The model distinguishes four classes:

  • Opportunists
  • Targeting Opportunists
  • Professionals
  • State-Founded

Opportunists

This class covers bots, worms, mass malware, and script kiddies. They are opportunistic in the sense that they move on if they don't find a particular known vulnerability. Sophistication is relatively low, and to compensate they operate at scale.

Keywords: large scale, low-hanging fruit, low sophistication.

Targeting Opportunists

A more focused subset of Opportunists. They don't scan the internet at random and stop at whatever they stumble across; they pick a single organisation and probe it continuously, looking for weak spots.

Keywords: targeted at a specific organisation, continuous probing, more sophistication, more motivation.

Professionals

Digital mercenaries. Sophisticated attackers targeting specific organisations and assets over extended periods. This class does not stop at low-hanging fruit or a single attack vector - they pursue the objective by whatever means it takes. They are funded to some degree, and their skill level lets them develop new attack techniques and bypasses for exploit mitigations.

Keywords: targeted, motivated, sophisticated.

State-Founded

This class represents very well-funded and sophisticated attackers acting in the interests of nation states. Their targets are intellectual property, strategic assets, and classified information.

Keywords: targeted, specialised, Stuxnet.

Attacker Pyramid

The diagram below shows what I call the Attacker Pyramid. The left-hand pyramid shows the four attacker classes; the surface area of each layer indicates the relative number of threat agents in that class. The right-hand pyramid shows the assets each class is after, with the surface area indicating the relative value those assets represent to the business.

Attacker Classes and Sophistication

The pyramids above can be complemented by an inverse pyramid representing motivation, sophistication and funding.

Attacker Class Triad

The complete triad looks like this:

Q&A

What is the difference between this and Veris?

Veris is post-mortem - essentially an incident classification framework. There's no real link between Veris and the Attacker Pyramid. What's presented here is the concept of adjusting your defences to the highest attacker class expected (HAE). It serves as a framework to classify data and assets into buckets so you can zone and protect them accordingly.

Why "Attacker Class" and not "Threat Agent"?

The concept centres on malicious intent, not natural hazards or the other general categories that fall under "threat agent." I like the term "threat agent" and might swap "attacker class" for something else at some point, but I still think it captures motivation and intent more directly than the more generic label.

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 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
  • Proposed countermeasures
  • Literature
  • Advisories
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

Source: TLS/SSL Compatibility Report 2011

 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, followed by "Security impact of the Rizzo/Duong CBC BEAST attack"

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 . (Note: Please take my recommendation and use this as a short term solution only, RC4 is not the strongest solution but the only non CBC cipher...)
  • 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. (Splits non-empty Application Data Records, image below) - it is currently pushed to Chromium Beta channels for testing
2 separate Application Data Records - Image courtesy of Adrian Dimcev
Literature
Advisories :

This is a cross post from the G-SEC blog

My professional and private commitments made it difficult to maintain a healthy 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 cipher-suites available to XP systems considerably (compared to IE) but loosing the TLS 1.1 and 1.2 capability of later Windows Operation Systems.
  • Added OPERA cipher-suites


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

I stumbled across this weird PHP bug in the crypt() implementation (version 5.3.7RC5) [1]
The bug reporter states that :

"If crypt() is executed with MD5 salts, the return value consists of the salt only."
In other words the call :
printf("MD5: %s\n", crypt('password', '$1$U7AjYB.O$'));

results in   
$1$U7AjYB.O

instead of:
$1$U7AjYB.O$L1N7ux7twaMIMw0En8UUR1

What this means is that in case we store a credential in a Database and later check for the validity of a password the check will always result in TRUE (i.e correct)
$saltedpass = crypt($pw, $salt);

Here is the patch that fixed it (Note how the the strlcat to strcat change was made):http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg261500.html

For readers unaware of the concept of a cryptographic "salt", look here
[1] https://bugs.php.net/bug.php?id=55439

This page represents more of an archive than an up-to-date functional lists, it's been 20 years of a ride so far :) Below is a list of Tools (Offensive / Defensive) I developed and released, my presentation at international security conferences, some hardware modifications I made and vulnerabilities I discovered and coordinated.

Conference Presentations

Bluetooth

"The Death of AV Defense in Depth?" as being presented at Cansecwest © hirsan



Excerpt of "Bluetooth Security - All your base are belong to us.

Whitepapers

TLS/SSL Renegotiation Vulnerability (CVE-2009-3555)
This paper explains the SSLv3/TLS renegotiation vulnerability for a broader audience and summarizes the information that is currently available. It includes original research and Proof of concept code.

Updates:

  • Updated : Added SMTP over TLS attack scenario
  • Updated : Added FTPS analysis
  • Updated : New attacks against HTTPS introduced
  • Updated : PoC files for TRACE and 302 redirect using TLS rengotiation flaw

References
This paper is referenced by the US-CERT, DFN-CERT, BELNET-CERT, SWITCH-cert, Nessus, Qualys, c't Heise, and many more. Furthermore it has served as a internal Training paper for a major OS vendor.

Details
TLS/SSLv3 renegotiation protocol vulnerability
▪ 
Blog post : SSLv3/TLS mitm vulnerability

Tags: Whitepaper, TLS/SSL Renegotiation Vulnerability

TLS/SSL hardening and compatibility report 2011
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.

This paper aims at answering the following questions :
  • What SSL/TLS configuration is state of the art and considered secure enough ?
  • 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 free tools :
  • SSL Audit : SSL/TLS scanner
  • Harden SSL/TLS : Windows server and client SSL/TLS hardening tool
Details
Download : SSL/TLS Hardening and Compatibility report 2010
Download : SSL/TLS Hardening and Compatibility report 2011

Tags: SSL / TLS Compatibility Report

Tools

I  do not consider myself to be a developer, I have however hacked together plenty of Proof of Concept code. That includes a few offensive and defensive tools that I have made public.


BTCrack 1.11
BTCrack was the worlds first Bluetooth Pass phrase (PIN) and linkkey brute-force tool. It was presented at SAAL1 at the 23C3 in Berlin. BTCrack will brute-force the Passkey and the Link key from captured Bluetooth pairing exchanges.

To capture the pairing exchange it is necessary to have a Professional Bluetooth Analyzer : FTE (BPA 100, BPA 105, others), Merlin OR to know how to flash a CSR based consumer USB dongle with special firmware. (Update 2011: Ubertooth also is a possibility now)

As of version 1.1, BTCrack started to include FPGA support through picocomputing E-Series.

Speed Comparison :

P4 2Ghz - Dual Core  :      200.000 keys/sec
FPGA E12 @ 50Mhz :   7.600.000 keys/sec
FPGA E12 @ 75Mhz : 10.000.000 keys/sec
FPGA E14                 :   30.000.000 keys/sec


Details
Download BTCrack 1.1
More information
▪ Video : 23C3 All you Bluetooth is belong to us
Talk : Heisec Scheunentor Bluetooth



Tags : Offensive, Proof of Concept


BTCrack Open Source Version (GPL)
This is a straight forward linux port of BTCrack.

Details
Download BTCrack Open Source Version

Tags: Offensive, Proof of Concept



Secure-It

Secure-It™ is a local Windows security hardening tool, proactively secures your PC by either disabling the intrusion and propagation vectors proactively or simply by reducing the attack surface by disabling unimportant functions.
The tool secured Windows workstation  as-well as servers against new dangers by blocking the root cause of the vulnerabilities exploited by malware, worms and spyware. Secure-it had a track record of preventing several 0-day exploits pro actively

History of real-life proactive protection :
  • 2004 Protected against the Help Active X control exploit in advance.  
  • 2004 Protected against the second Help Active-X control exploit not correctly patched.
  • 2004 Protected against the DHTML Active-x Control exploit in advance. 

Note: Secure-it last update was in 2005 and some settings, like the active-x blacklist are outdated and should no longer be used. 

Details
More information

Tags : Defensive, Hardening, Tool



Harden-it
Harden-It™ is a Network and System hardening tool for Windows, by hardening the IP stack your Network can sustain or completely thwart various sophisticated network attacks : 

  • Harden your server's TCP and IP stack (ICMP, SYN, SYN-ACK..) Reduces or mitigates effects from DoS and other network based attacks
  • Enable SYN flood protection when an attack is detected  Set the threshold values that are used to determine what constitutes an attack
  • Various other protections.
History of real-life proactive protection :
 ▪  2006 Protected against the Windows IGMP Denial of service attack in advance.

Details
More information Tag

Tags : Defensive, Hardening, Tool 


Remote Administration Tool (GPL)
Remote Administration Tool is a small free remote control software package derived from the popular TightVNC software.

With "Remote Administration Tool", you can see the desktop of a remote machine and control it with your local mouse and keyboard, just like you would do it sitting in the front of that computer. Small, easy, no installation required.

Details
More information


Tags :  Administration, Tool


CSS-DIE
CSSDIE is a community-developed fuzzer for verifying browser integrity, written by H D Moore, Matt Murphy, Aviv Raff, and Thierry Zoller. CSSDIE will look for common CSS1/CSS2/CSS3 implementation flaws by specifying common bad values for style values

Details
More information

Tags: Fuzzer, Offensive, Tool


Omron Communicator 
This software is based on my efforts to reverse engineer the Hitachi Omron Hybrid Card readers. Omron Card readers are used in various commercial setups like ATM, identity management, payment systems, parking systems. The effort displayed on this blog is purely done out of research and awareness purposes.

Details
 ▪ Part 1 - Omron hybrid card reader - New toy



Tags: Reverse Engineering, Smartcard, Tool


Excerpt of discovered Vulnerabilities
Below is an overview of new vulnerabilities I have discovered, coordinated and disclosed, this list does not include vulnerabilities that were being discovered during my professional career.


2020

Hardware 
I am by far not an electronic engineer - I learned to solder and modified a bit of hardware as a hobby and out of interest.

This is my version of the the Bluetooth Sniper weapon, it features a medium sized YAGI antenna combined with a 10* magnification scope and a metalized parabolic which may bundle the Bluetooth signal, thus further enhancing the range.
A long term project with regards to USB devices and security.