Browser Fingerprinting via SSL Client Hello Messages
Encrypted traffic has long been a challenge for network monitoring. But even if traffic is encrypted, there is still plenty of information that can be extracted. In this little example, we are looking at "SSL Hello" messages. These messages are sent by the client to initiate the SSL connection. They include a number of parameters that may vary depending on the SSL library used or the SSL clients preference.
The SSL Hello message contains a couple of major parts [1]
- a timestamp. This is the local time of the client, even if the RFC doesn't require it to be accurate.
- 28 random bytes
- a list of cipher suites the client supports
- the SSL version the client is using (e.g. TLS 1.0)
- any extensions the client may support (including compression)
This gives us quite a bit of data to fingerprint clients. The timestamp can be used to check if the clients time is in sync. The supported cipher suites and extensions may tell us what browser version the host is running and could for example be used to block out of date browsers at a gateway that is not able to decrypt traffic.
Ivan Ristic has published similar data in the past focusing on SSL ciphers [2], and p0f considered including some of that data.
My tool of choice to extract this information from packet captures is tshark. To run this test, I collected a couple minutes of traffic. I also extracted the IP addresses and user agents from the web server log to be able to link the "SSL Fingerprint" to the user agent. I ignored all IP addresses for which I saw multiple user agents (looks like mostly mobile devices that accessed the podcast via a podcast client as well as the web site via a browser).
In tshark, to extract the "fingerprint" I used:
tshark -r test.pcap -T fields -e ip.src -e ssl.handshake.ciphersuite -e ssl.handshake.version -e ssl.handshake.extension.type -R "ssl.handshake.type=-1"
Here is a partial result:
Firefox 25 on Windows 7 ( Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 )
Cipher Suites: 0x00ff,0xc00a,0xc014,0x0088,0x0087,0x0039,0x0038,0xc00f,0xc005,0x0084,0x0035,0xc007,0xc009,0xc011,0xc013,0x0045,0x0044,0x0033,0x0032,0xc00c,0xc00e,0xc002,0xc004,0x0096,0x0041,0x0005,0x0004,0x002f,0xc008,0xc012,0x0016,0x0013,0xc00d,0xc003,0xfeff,0x000a
SSL Version: 0x0301 (TLS 1.0)
Extensions: 0x0301 0x0000,0x000a,0x000b,0x0023,0x3374
Chrome 31 on Windows 7 (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36)
Cipher Suites:
0xc02b,0xc02f,0x009e,0x009c,0xc00a,0xc014,0x0039,0x0035,0xc007,0xc009,0xc011,0xc013,0x0033,0x0032,0x0005,0x0004,0x002f,0x000a
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0x0000,0xff01,0x000a,0x000b,0x0023,0x3374,0x0010,0x754f,0x0005,0x000d
Internet Explorer 7 on Windows 7 (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; .NET4.0E; Microsoft Outlook 14.0.7109; ms-office; MSOffice 14)
Cipher Suites:
0x003c,0x002f,0x003d,0x0035,0x0005,0x000a,0xc027,0xc013,0xc014,0xc02b,0xc023,0xc02c,0xc024,0xc009,0xc00a,0x0040,0x0032,0x006a,0x0038,0x0013,0x0004
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0xff01,0x0000,0x0005,0x000a,0x000b,0x000d
These three examples, all from Windows 7, show how different browser result in very different fingerprints. The order of ciphers and extensions appears to vary as well allowing for more detailed distinctions, and something that needs a bit more data to work with.
Timestamps
Timestamp fingerprinting was kind of interesting as well. Turns out that out of the times are actually very accurate. Out of a total of 3814 Client Hello messages, 3109 where within 5 seconds. A couple of time stamps where "far outliers" with timestamps in 1970, likely indicating a "time since reboot" instead of the absolute time.
Figure 1: Time difference frequency up to 10 seconds
[1] http://www.ietf.org/rfc/rfc2246.txt
[2] http://blog.ivanristic.com/2009/07/examples-of-the-information-collected-from-ssl-handshakes.html
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Facebook Phishing and Malware via Tumblr Redirects
We got a couple reports of pretty convincing Facebook spam redirecting users to malware and a Facebook phishing site.
The initial bait is a message that you may receive from one of your Facebook friends, whose account was compromised. The message claims to contain a link to images that show a crime that was committed against the friend or a close relative of the friend. The image below shows an example, but the exact message varies. The images then claim to be housed on Tumblr.
The Tumblr links follow a pattern, but appear to be different for each recipient. The host name is always two or three random English words, and the URL includes a few random characters as an argument. The preview of the Tumblr page lists some random words and various simple icons.
Once the user clicks on the link to the Tumblr page, they are immediately redirected to a very plausible Facebook phishing page, asking the user to log in. The links I have seen so far use the "noxxos.pw" domain, which uses a wildcard record to resolve to 198.50.202.224 . For example, the URL would look like:
hxxp:// facebook.com .accounts.login.userid.243534.noxxos.pw/awks/
Due to the size of the URL, and the fact that the host name starts with "facebook.com", it is hard for the victim to realize that this is not a valid Facebook page.
The fake Facebook page will ask the user for a username and password as well as for a "secret question".
Finally, the site attempts to run a java applet (likely an exploit, but haven't analyzed it yet), and the user is sent to a Youtube look-alike page asking the user to download and install an updated "Youtube Player". The player appears to be a generic downloader with mediocre AV detection.
(was 3/42 when I first saw it. Now 10/42 improved)
As an indicator of compromise, it is probably best right not to look for DNS queries for "noxxos.pw" as well as connections to 198.50.202.224 (which is likely going to change. The server only returns 404 errors right now)
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments