Packet analysis of the SSL Renegotiation Flaw

A deeper analysis of the SSL/TLS renegotiation flaw using the packet captures provided by the researchers.

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)
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
What the victim sent to the webserver

Going deeper with the Bounce View

SSL Records Bounce (click for bigger)
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
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
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.

Forensics Fun : YouTube videos from packet captures

Reconstruction of videos from packet captures. How to extract videos from a youtube session and to script the whole thing.

Who says people who look at raw packets cant have fun ? Let’s see how we can reconstruct YouTube videos from raw packets and play them back directly from Unsniff. We also show you a nifty Ruby script to automate this.

Playback

1. Fire up Unsniff Network Analyzer and start a packet capture

2. Go watch some YouTube video(s)  to completion. We will explain how to deal with half played videos later.

3. Once you are done,  switch over to the User Objects tab where all the action is. You will see a list of “user objects” extracted by Unsniff from the stream. Click on the Type column to sort by Type and locate the FLV objects. Right click to Save or Play (To playback you need the free VLC Player installed and FLV files associated with VLC).

Right click the user object of type FLV and select Play or Save
Right click the user object of type FLV and select Play or Save

Feeling adventurous ?  Lets try some more tricks.

Pruning the packet capture

When you interact with a site like YouTube there is a ton of content exchanged, not all of it is the video bits. You have packets containing images, HTML, Flash, and Javascript. The actual FLV is exchanged in a single TCP stream. If you can save these streams alone, you will be able to reconstruct the videos.

Here is how you do it.

1. Switch over to the “Sessions”, here is where you will see a list of TCP sessions updated in real time (every packet).

Only the TCP Stream containing the media is required ! Cut and paste it
Only the TCP Stream containing the media is required ! Cut and paste it

2. Locate the TCP Stream carrying FLV traffic. These are typically the really large ones. Select the stream, copy the stream (Edit->Copy) and Paste it as a new file (Edit -> Paste as New). Voila ! Switch to the User Objects in the new file and you will find the FLV without all the other clutter.

Script the whole thing using Ruby

The right clicking novelty quickly wears out after a while. You really want to automate this type of forensic stuff.

Here is a sample which shows you how you can use Ruby to script this stuff.

Task : Extract all the videos in a capture file as separate playable files. (including the ones that were aborted in the middle due to the use losing interest)

1. Save the capture as USNF format (this is the scriptable format used by Unsniff).

2. Run this script like so

We are still working on tweaking the experience for our upcoming Unsniff 2.0 release. In the meantime, we invite you to  try out the Unsniff Beta 1.8 and give us feedback on what you’d like to really see.

Resolving SNMP OIDs in packet captures

How to convert SNMP OIDs in packet captures to human readable names ?

A common problem while analyzing SNMP traffic is resolving OIDs to names.

We don’t want to see this :

Showing raw SNMP OIDs in the packet list
Showing raw SNMP OIDs in the packet list

We want to see this :

Showing human readable names in the packet list
Showing human readable names in the packet list

The venerable Wireshark‘s own resolution capabilities work fine for many simple cases. With Wireshark, you can list the modules you need and have it load them upon startup. But what if you want to load thousands of MIBs ? What if you want to deal with badly written MIBs, MIBs with incorrect module names, MIBs with dependencies ?  We might be able to help you.

We make two products, Unbrowse SNMP and Unsniff Network Analyzer. Unbrowse SNMP is a full fledged SNMP tool that can compile almost anything you throw at it. It then persists the properties of each OID in a very efficient format on disk. The Unbrowse Scripting API provides a number of ways to get at this data. The other product, Unsniff is the actual SNMP packet analyzer. We have integrated both these products in such a way that Unsniff will use the OID information already available via Unbrowse.

To use this feature : (Requires latest versions of Unbrowse SNMP and Unsniff Network Analyzer)

  1. Download and Install Unbrowse SNMP
  2. Press Crtl+M and select all the MIB files you want to add
  3. Alternately, Download a precompiled package (we have one containing all the Cisco MIBs)
  4. Done

Unsniff will automatically detect if the Unbrowse SNMP name resolution facility is installed and will then proceed to resolve all OIDs to the maximum extent it can.

Resolving OIDs where ever they are found
Resolving OIDs where ever they are found

The advantages :

  • Leverage Unbrowse SNMP’s very flexible compiler
  • OIDs of thousands of modules are instantly available for resolution
  • Has no impact on Unsniff’s startup time
  • High speed resolution with low memory overhead
  • Scriptable via Ruby