Quicklinks: Home | Contact |

TLS / SSLv3 renegotiation vulnerability explained (Update #2)(

0 comments Posted by Thierry Zoller

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

This paper explains the vulnerability for a broader audience and summarizes the information that is currently available. The document is prone to updates and is believed to be accurate by the time of writing.

  • Updated 18.11.2009 : Added SMTP over TLS attack scenario, added s_client testcase
  • Updated 30.11.2009 : Added FTPS analysis, new attacks against HTTPS (injecting responses and downgrading to HTTP)  
  • Updated 09.12.2009 : Proof of concept files for TRACE and 302 redirect using TLS rengotiation flaw

Download "TLS / SSLv3 renegotiation vulnerability explained"

posted by Thierry Zoller

Related post: Vulnerabilities like it's 1999 SSLv3 / TLS Man in the Middle vulnerability - update #8

 

SSLv3 / TLS Man in the Middle vulnerability - update #9

1 comments Posted by Thierry Zoller

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


  • Updated 17:50 GMT+1 / 05.2009 - added Mitigation / Impact 
  • Updated 16:40 GMT+1 / 06.2009 - added IETF draft 
  • Updated 14:35 GMT+1 / 07.2009 - added SSLTLS Test Tool 
  • Updated 16:34 GMT+1 / 07.2009 - added OpenSSL patch 
  • Updated 13:00 GMT+1 / 09.2009 - added GNUTLS patch 
  • Updated 19:40 GMT+1 / 09.2009 - added Mikestoolbox.net testing TLS renegotiation support 
  • Updated 21:29 GMT+1 / 09.2009 - added Apache patch, Mozilla Bug ID, Redhat Bug ID, Mozilla patch disabling tls renegotiation, Tomcat mitigation 
  • Updated 21:00 GMT+1 / 12.2009 - added a whitepaper trying to explain the vulnerability and it's implications to a broader audience

After some in-house tests, we can confirm that the vulnerability presented at http://www.extendedsubset.com/ indeed real and should pose a significant threat to most. The vulnerability has been discovered by Marsh Ray, Steve Dispensa and Martin Rex.

We are currently looking into possible mitigations and will update this blog post regularly with more information regarding said vulnerability.

Details
Patches
Advisories 
Impacts :
Currently known to exist
  • In general an attacker positioned in the middle of a connection may inject arbritary content into the beginning of an authenticated stream it will be interesting to see what potential impact this vulnerability has within each of the applications / protocols supporting it. IMAPS, FTPSSL, POP3 etc
  • For web servers - Attackers (if in the middle) can inject data into a segment that is authenticated to the web server, the web server will merge those requests and process them. (GET requests are trivially exploitable, POST are not known to be)  
Posted by Thierry Zoller

     

    Solving the HACK.LU 2009 reversing challenge like it's 1998

    4 comments Posted by Thierry Zoller

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


    Here is quick overview of one possible way to solve the Hack.lu 2009 crackme  (reversing challenge) with the classical JZ/JNZ method (hence the 1998 reference).

    Disclaimer : If you are used to reversing software, you can skip this post, there is nothing new for you to glimpse here.  This is one way to solve this crackme, of course you could try to reverse engineer the serial generation algorithm. In reality, if you'd  use a serial system like this in a shareware type of application nobody would bother to do so. 


    Although there are no classical packer signatures to be detected (PEid, ExeInfoPE), looking at the results of entropy tests it is clear that the sample is compressed/crypted in some way or another.  Entropy being the measure for randomness/chaos.

    Examples : 
    • AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA has an entropy of 0 
    • ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx has an entropy of 96,04%



     Entropy measurement of crackme.exe



    There are several ways to measure whether a binary (or parts of it) are compressed/encrypted, I happen to use gynvaels' excellent tool ENT (not to be confused by a similar entropy measurement tool) as it offers several advantages such as mapping to .code and .data section of a PE file. As we can see above the entropy of the code section (Green) is that of normal code, the data section is high on entropy at the very end of it.

    Luckily for us it doesn't use stolen bytes or more advanced methods to hinder dumping from memory while the sample decrypted/decompressed itself.

    So we proceed with
    • Loading the sample in Ollydbg - Wait until it hits OEP
    • Dump the process using Ollydump 
    • fix import table
    • Search for "serial"
    • Look for branching code 
    • Patch branching code from JZ to JNZ

    Patching the Jump Zero to a Jump Not Zero instruction

    This is it








    Posted by Thierry Zoller


     

    Subscribe to: Posts (Atom)