Network Forensic Analysis of SSL MITM Attacks

The big news this past week has been the attack against Comodo where false certificates were created for popular domains like google.com, yahoo.com, live.com and skype.com.

Comodo is a Certificate Authority (CA) that your browser trusts, this means that these false certificates would be accepted by most browsers. But the attack was luckily discovered and the false certificates have now been revoked.

Someone performing a man-in-the-middle (MITM) attack on HTTPS traffic (i.e. HTTP over SSL) would be able to see all content of the encrypted communication, including transmitted usernames and passwords. Such MITM attacks can be performed by someone at your local WiFi connected coffee shop, your employer, your ISP or your government.

There are several ways users can detect MITM attacks, even when the certificate seems to be signed by a trusted CA. There are, for example, Firefox plugins available from Certificate Patrol as well as Perspectives that can help users by alerting on “new” certificates that have not been seen before.

But how would you go about doing forensic analysis of captured network traffic from a suspected MITM attack?

My suggestion is to load the pcap into NetworkMiner, which will automatically extract the X.509 certificates from the SSL streams to files with the “.cer” extension. These .cer files can be opened in MS Windows default certificate viewer for further inspection, simply right-click the extracted file in NetworkMiner and select “Open file”. I will in this blog post use the file “test1.pcap” from the “social nOtworking site” pcapr.net.

SSL capture file test1.pcap opened in NetworkMiner Professional

The first thing to inspect in a possible MITM attack is to verify that the IP and DNS name of the server seem to be correct. The next step is to look closer at the server's certificate, for example by opening the .cer file in Windows.

Extracted file mail.google.com.cer opened for inspection

Self signed certificates, revoked certificates and certificates that are signed by non-trusted CAs are generally not to be trusted. Finding such certificates in a pcap file can suggest that an SSL MITM attack has taken place. In this case, however, the certificate for mail.google.com seems to be signed properly by Thawte.

The recent attack on Comodo teaches us that even certificates signed by a trusted CA can be rogue, we can therefore not fully trust this certificate even though it is signed by Thawte. An attacker who has hacked into Thawte could have been able to apply a valid Thawte signature to his own fake certificate for mail.google.com. There is also the possibility that some governments might use MITM and false SSL certificates to inspect the contents of encrypted communications. Christopher Soghoian and Sid Stamm's paper “Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL” does for example start out with the following abstract:

“This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals' secure Web-based communications. We reveal alarming evidence that suggests that this attack is in active use. [...]”

This type of advanced MITM attack, where the certificate is signed by a trusted CA, can be detected by investigating whether or not other people across the internet are receiving the same certificate as you do for a particular website. The Perspectives Project, which is run by Carnegie Mellon School of Computer Science, provides a web based Perspectives Notary Demo that can be used to query their “network notary” servers to see what SSL certs they receive for a particular HTTPS website.

By submitting a query for SSL certificates on TCP 443 on mail.google.com to Perspectives I get the following response:

*** cmu.ron.lcs.mit.edu:8080 ***
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Mon Jan 24 11:02:00 2011
end : Sun Mar 27 03:11:18 2011

*** convoke.ron.lcs.mit.edu:8080 ***
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Mon Jul 6 20:59:14 2009
end : Wed Nov 18 03:15:36 2009
start: Wed Nov 25 15:17:24 2009
end : Thu Dec 10 03:21:52 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Wed Nov 18 03:15:37 2009
end : Wed Nov 25 15:17:23 2009
start: Thu Dec 10 03:21:53 2009
end : Wed Dec 23 03:29:22 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Wed Dec 23 03:29:23 2009
end : Sat Mar 26 16:06:14 2011

*** mvn.ron.lcs.mit.edu:8080 ***
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Fri Jan 21 17:21:53 2011
end : Sun Mar 27 03:44:32 2011

*** hostway.ron.lcs.mit.edu:8080 ***
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Wed May 6 10:47:37 2009
end : Tue Nov 24 15:46:54 2009
start: Wed Nov 25 15:46:34 2009
end : Wed Dec 9 16:04:13 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Tue Nov 24 15:46:55 2009
end : Wed Nov 25 15:46:33 2009
start: Wed Dec 9 16:04:14 2009
end : Tue Dec 22 15:58:32 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Tue Dec 22 15:58:33 2009
end : Sun Mar 27 03:41:06 2011

The 16-byte keys received from the four network notary servers are MD5 fingerprints for the certificates they have seen. The built in certificate viewer in Windows unfortunately only shows SHA1 fingerprints (20 bytes), we will therefore need to find some other way of computing an MD5 fingerprint of the certificate. I chose to do this by running OpenSSL in Cygwin, but installing Win32 OpenSSL works just as fine. Calculating the MD5 fingerprint of an SSL certificate with OpenSSL is done like this:

$ openssl x509 -inform DER -in mail.google.com.cer -noout -fingerprint -md5
MD5 Fingerprint=52:12:A2:B1:27:E3:BB:CC:E5:F5:AA:BD:A1:A1:E6:F8

As you can see this fingerprint was also provided by all the four network notaries, so we can assume that no SSL MITM attack was performed on the session between 10.33.134.158 and mail.google.com in test1.pcap.

If you wanna learn more about sniffing and analyzing SSL/TLS encrypted network traffic then I suggest you also read our recent blog posts titled Facebook, SSL and Network Forensics and Webmail-Information-Leakage.

Posted by Erik Hjelmvik on Sunday, 27 March 2011 13:31:00 (UTC/GMT)

Tags: #Netresec​