Exploring encrypted Skype conversations, in clear-text
Skype is, or was, heralded as one of the most secure IM and VOIP applications available. This wiki on Skype security goes into some detail for how data is encrypted, but it also mentions their information is outdated with the original research completed years ago. According to CNET: “Skype was the only IM company that said it could not perform a live interception if presented with a wiretap request: "Because of Skype's peer-to-peer architecture and encryption techniques, Skype would not be able to comply with such a request.”
Based on my preliminary research, documentation about Skype’s encryption and transport mechanisms appear to be outdated, inaccurate, or, in many cases, simply don't exist. I suppose one can attribute some of that to the intentions of building a secure protocol (never mind the adage "security through obscurity is not security at all"). Let’s also not forget that Skype has changed hands a few times over the years and their current owner, Microsoft, has made a few changes---not all for the better.
Not long ago, I found myself at home winding down from a long day on the road. My phone just beeped at me to indicate there was a new email waiting. Dula, a colleague of mine, had just dropped me a note to ask me if Solera reconstructed Skype conversations. It's a valid question: Solera can reconstruct a handful of IM applications. I don’t recall my exact words, but they were something to the effect that the traffic was encrypted with proprietary mechanisms and we, as mere mortals, wouldn’t be able to see the decrypted conversations. She said she had already decrypted Skype messages using Blue Coat’s SSL inspection technology.
In a temporary state of disbelief, I asked her to forward me a pcap of the traffic. While waiting for it to arrive, I conferred with a few of my current and former colleagues that work in network security to see if they knew if Skype was decryptable. Everyone came back with the same resounding no; citing variations of the closed encryption story and "peer to peer-like" communications. The pcap arrived a bit later and she was right – we had clear text traffic. Wow. I immediately thought there are going to be a lot of people interested in hearing about this. Get ready, strap your boots on, and we’ll see how far down the rabbit hole we can go.
I scurried up to my lab and sought to reproduce Dula’s efforts. The basic requirements for inspecting Skype’s SSL traffic and recording it are as follows:
- Blue Coat SSL visibility technology
- Client PC running the latest version of the Skype client
- Packet capture device attached to clear-text output of SSL visibility - Solera (preferred), Wireshark, TCPDump, etc.
- Knowledge of SSL, certificates, PKI, and SSL MITM
Here is a basic representation of what I used for my lab setup.
(Yes, I couldn’t resist reusing the recent NSA catch phrase in my diagram)
I registered a couple of dummy Skype accounts for testing, sent some traffic through Skype, and reviewed all my Skype packets to find that, in fact, they were encrypted. To verify that my SSL traffic was in fact re-signed and decrypted by my SSL visibility appliance, I popped over to a few of my favorite test sites, PayPal and Facebook – and confirmed that, through the use of the SSL-VA, all SSL traffic was decrypted and sent to the SAP device in the clear.
After poking around a bit more to ensure client settings were correct, double checking that the resigning CA certificate was in the trusted root store, and further reviewing my captured traffic it dawned on me I was probably using an older version of the Skype client. Bingo! I updated to the latest version and immediately saw my IM conversations in the clear. Something did change with Microsoft’s update to Skype.
Something else I found is that the Skype client doesn’t inform the user it’s using SSL, nor does it show what certificates are in use. For example, on most web browsers, the user can click the padlock icon to view the certificates for any given site. Skype doesn’t present that information to the end user at all.
That behavior is not completely unexpected, as many standalone apps either embed their own certificate store or just use the operating system’s certificate store. What this means for the Skype user is that, as long as their operating system trusts the Certificate Authority and certificate chain, their client will successfully connect to Skype’s servers. To successfully pull off SSL inspection, the user must trust some (usually) private Certificate Authority (CA). The SSL visibility appliance performs a man-in-the-middle SSL attack, re-signing the original SSL certificate chain with its own CA certificate. Provided the user’s system trusts this new CA, our Skype user would never know if their traffic was intercepted by an SSL inspection device. Simply stated: drop a CA cert in the user’s certificate store, and they’ll never suspect they’ve been SSL MITM’d. Adjust that tin foil hat anyone?
Let’s analyze some of what I’ve collected. I may not have all the answers for how Skype is operating, but based on my observations and the tasks I performed, we can make some assertions about what it’s doing. I’m also presenting all the artifacts and associated pcaps here so you can continue to analyze the data on your own. Note that the artifacts don’t represent everything worth analyzing; you’ll need to break out your Wireshark skills to look a bit deeper.
I’m not going to pore over the details of every artifact or packet, but I will highlight some of the ones I think are interesting. Let’s start with the Skype chat session pcap. If you are following along in Wireshark, TCP stream 5 is the first stream which presents some data of interest. Here we can see the OS version, processor type, and the country code (which, interestingly, is wrong, as I’m located in the US, not Australia). The server responds with a target located at messenger.live.com, and a base64 encoded string which decodes to:
If you wish to extract artifacts yourself, follow the various TCP streams in Wireshark and force it to decode them as HTTP traffic.
Shortly after I logged into Skype, I found an interesting string that is delimited by “uic” – a user identification code perhaps? The data appears to be base64 encoded, but decoding it as such renders the results meaningless to me; I couldn’t see any recognizable strings. I think this may be where the user’s password is exchanged, as it clearly isn’t elsewhere in the pcap. I suspect Skype is simply passing a hash of the password, but after decoding the data and comparing the results with various hashed results of the account’s password I came up empty. The user’s ID is there though: spoonfed123.
It appears it’s using a nonce for something:
They are grabbing the system’s hostname here:
As the IM exchange starts, we can clearly see the messages fly back and forth by following the correct TCP streams:
When a file is transferred, we can spot what appears to be the control channel for the file transfer. The beginning of the message contains the Message Type, the mime type (they tag it as content-type), followed by some file tags. The actual data itself is in a separate stream, which unfortunately, I wasn’t able to decode properly with the limited amount of time I spent on it.
Here’s some data tagged with a NodeInfo identifier and it appears as if this is a status updates for people in my contact list. Is this leftover from the days of Skype’s super node model perhaps?
There is a litany of other artifacts the Skype client pulls down from different sources such as msn.com, msads.net, Hotmail.com, scorecardresearch.com, and the list go on.
I’m not going to analyze each of these, but rather I’ll point out the following large java script file from apps.skype.com.
Switching gears, let’s take a look at the skype-call pcap, where a phone call was placed. I put a few “markers” in the chat conversation while using VOIP to help sift through packets and make sense of where the audio data might be in the packet stream, e.g. “endcall”. TCP stream 2 contains the brief IM conversation, made apparent with the endcall marker.
Streams 3 and 4 are of particular interest though. While the data itself doesn’t contain any human readable strings, it resembles the data patterns you’d find in a VOIP call. I dumped the contents of the streams to two separate files (presented below as sky1 and sky2) and pumped them through a few different codec detectors and various audio playback apps to discover that I’ve hit a wall. Either it’s not audio data or I’m not using the right tools to playback the audio streams. I’m hoping the collective internet might be able to help me figure this one out.
Is Skype still secure? I suppose that depends on your perspective. Sure it uses SSL to encrypt your data, but as we’ve demonstrated, with the right tools it’s easy to decrypt and intercept that traffic. I wish Skype would allow the user to see what certificates are in use. Granted 99% of the user base probably won’t care, but those (like myself) more concerned with the sanctity of their connection will want to verify that. Short of Microsoft providing the means to do so, you could fire up Wireshark on your local system to record the SSL handshake and verify the certs in use. For those that thought Skype was the panacea for secure communications, you’ll want to reevaluate what and how you use IM and VOIP applications. If you haven’t been introduced to OTR (Off The Record), now may be a great time to familiarize yourself with that.