The big security news this past week was the SSL Renegotiation Flaw found by researchers Marsh Ray and Steve Dispensa at Phone Factor. Here is what they say :
The SSL authentication gap allows an attacker to mount a man-in-the-middle attack, and affects the majority of SSL-protected servers on the Internet. Specifically, the vulnerability allows the attacker to inject malicious data and commands into the authenticated SSL communications path. This can often be done without either the client or server (e.g. web server and browser) being able to detect the attack.
Read more at their site
Listen to an interview featuring Marsh Ray
What is really cool with this vulnerability is that the researchers have released packet captures of it in action.
Grab the packet captures, a whitepaper, and protocol diagrams from Phone Factor’s site.
Analyzing the packet captures
In this post,let us see how we can analyze these and similar packet captures. There is plenty of heavy lifting to be done, so we will be breaking open a tool called Unsniff. Laura Chappell over at Chappell Seminars has a similar post on analyzing the traces using Wireshark.
Among all the captures released, client_init_renego_bis.pcap seems to demonstrate the attack the best. To make this exercise easy we first decrypt the capture file using Unsniff’s TLS decryption capabilities and save it in Unsniff’s native USNF format.
The USNF format
The USNF format is a great way to share decrypted SSL/TLS packet captures without supplying the private key. No, the private key is not secretly tucked away in the file. It is simply not required after the initial decryption.
Step 1 : Download the latest version of Unsniff
Step 2 : Download the capture file in USNF format from here
Step 3 : Open the file and play with the Packets, PDU, and Sessions tabs.
- Packets : A list of link layer packets like you would see with Wireshark.
- Sessions : A list of TCP streams.
- PDUs : A list of reassembled and decrypted SSL records.
The Packets tab is not very interesting here because SSL records bear no relationship to link layer packet boundaries. So lets focus on the PDU and Sessions tabs.
Analyzing the streams
Switch to the sessions tab and note that the Sessions tab shows 6 TCP streams. But the original pcap file contained only 2 streams (from victim to MITM and from MITM to server). Unsniff creates two extra streams for every SSL/TLS stream. This is an great way to strip and analyze encrypted or tunneled streams.
The two extra streams are :
- The decrypted SSL stream (with all the handshakes in it. Decrypted but with signature and block cipher padding intact)
- The decrypted upper layer HTTP stream (with only the application data)
View HTTP data from the perspective of Server and MITM
Lets first look at the HTTP data from the HTTP server’s perspective.
Move to the Sessions tab and make sure the Stream sheet is activated. You may also have to rt-click and switch to UTF-8.
- Click on Stream 5 ( HTTP data as seen by the server)
What the web server sees (behold the evil)
- Click on Stream 6 (HTTP data sent by the victim)
What the victim sent to the webserver
Going deeper with the Bounce View
SSL Records Bounce Diagram (Click to view generated PDF)
The real juicy part is ofcourse the protocol exchanges between the victim, the MITM, and the server. The ideal tool for this is called the “PDU Bouncer’. Activate it by Right-Clicking on a PDU and selecting Bounce View. This creates a bounce diagram containing all the PDUs that went back and forth on the same TCP stream in time order. For example : Right click on PDU #2 to bring up the diagram shown on the right.
Three-way Bounce
What is really cool about this bounce diagram is that you can select two PDUs from different streams and you will then get a three-way (or even 4 way diagrams).
This is exactly what we need, the victim, the MITM, and the server PDUs all laid out in a protocol diagram. Switch to the PDU view, right click and select PDUs 2 and 14. Now bring up the PDU bouncer.
Lets see what we get.
Stage 1
Shows the MITM (192.168.80.17) intercepting the Client Hello from the victim and then establishing a separate connection to the server with the intention of patching on the client later. The session ID can be seen to be 1C144B..
Showing MITM intercepting victim
Stage 2
This shows the MITM sending the evil payload (PDU#28). Note the evil payload is an incomplete HTTP request sent with the hope that the victim will complete it. Once the payload is sent, you can see a new session being renegotiated. This new session is passed on to the client, from which point on the MITM stays away. The damage having been done ! Pure evil.
Step 2 : Renegotiating a new session and patching the client in
You can generate a PDF for any bounce diagram via Right Click + Print + Select CutePDF.
The PDF for this diagram is available here.
Tailpiece
The authors themselves have a pretty comprehensive whitepaper including a protocol diagram of their own in the package (http://www.phonefactor.com/sslgap/). The purpose of this post is to introduce a new tool you may wish to consider adding to your security toolbox in addition to the ubiquitous and lovable Wireshark.
Unsniff Network Analyzer 2.0 also features remote analysis in line with the NSM principles advocated in the Tao of Network Security Monitoring book. You can download the latest beta builds as they become available from http://www.unleashnetworks.com/downloads. Please support the product by testing out the beta builds.
