Information Security News
Cisco recently published a paper showing how malicious SSL traffic sometimes uses very specific SSL options. Once you know what set of SSL options to look for, you will then be able to identify individual pieces of malware without having to decrypt the SSL traffic.
(and before anybody complains: SSL does include TLS. I am just old fashioned that way)
I wanted to see how well this applies to HTTPS traffic hitting the ISC website. I collected about 100 MB of traffic, which covered client hello requests from about 719 different IP addresses.
There are a couple of parameters I looked at:
First the SNI option. I used the following tshark command to extract the size of the SNI option:
tshark -r pcap -n -Y ssl.handshake.type==1 -T fields -e ssl.handshake.extensions_server_name_list_len | sort -n | uniq -c
Here is the result broken down by hostnames:
|400||No SNI Option|
|1281||isc.sans.edu / isc.sans.org|
I was a bit surprised by the high number of hits without SNI. So I took a closer look at them.
Next step: Find out who isnt using SNI.
tshark -r pcap -n -Y ssl.handshake.type==1 ! ssl.handshake.extensions_server_name_list_len -T fields -e ip.src
One issue I ran into is that some of the requests to our site went through proxies. Proxies terminate the SSL connection, and the options observed do not depend on the web browser, but the client. The top user agents I saw without SNI:
With the exception of Bing, all of these are good to identify-)
Next, lets look at the number of ciphers offered by the client.
tshark -r pcap -n -Y ssl.handshake.type==1 -T fields -e ip.src -e ssl.handshake.cipher_suites_length | sort -u | cut -f2 | sort -n | uniq -c " />
Again we get a very diverse picture. I expected more pronounced peaks, but looks like we got a wide range of possible right answers. 34 (which implies 17 different ciphers) appears to be the most common answer followed by 26 and 52. But lets look at some of the outliers again:
The larges number of ciphers was 99 (cipher length of 198). This request came from126.96.36.199, which resolves to gw.dlvr.it." />
Finally, lets get te total length of the client hello extensions (cipher suites are not included) and subtract the length of the SNI option for its variability:
Again, we get a fairly wide distribution. Looks a bit like the cipher length. There some client that didnt appear to use any extensions, which is probably the outlier to look at here first.
Among the user agents not using any SSL extensions, the scripts stick out again (nagios, wget, curl and the like)
I think this does deserve more study. I only had a couple hours today to work on this. I think for a workstation networks, watching SSL options will certainly make for a nice backup to monitoring user agents, in particular if you cant intercept user agents for SSL. For a server, it comes down to how much you can tighten up the range of clients you allow to access your web applications. In a DoS situation, this may be a nice way to filter an attack, and you should certainly look for anomalies.
Computer scientists have discovered a serious Internet vulnerability that allows attackers to terminate connections between virtually any two parties and, if the connections aren't encrypted, inject malicious code or content into the parties' communications.
The vulnerability resides in the design and implementation of RFC 5961, a relatively new Internet standard that's intended to prevent certain classes of hacking attacks. In fact, the protocol is designed in a way that it can easily open Internet users to so-called blind off-path attacks, in which hackers anywhere on the Internet can detect when any two parties are communicating over an active transmission control protocol connection. Attackers can go on to exploit the flaw to shut down the connection, inject malicious code or content into unencrypted data streams, and possibly degrade privacy guarantees provided by the Tor anonymity network.
A startup on a shoestring budget is working to clean up the Android security mess, and has even demonstrated results where other "secure" Android phones have failed, raising questions about Google's willingness to address the widespread vulnerabilities that exist in the world's most popular mobile operating system.
"Copperhead is probably the most exciting thing happening in the world of Android security today," Chris Soghoian, principal technologist with the Speech, Privacy, and Technology Project at the American Civil Liberties Union, tells Ars. "But the enigma with Copperhead is why do they even exist? Why is it that a company as large as Google and with as much money as Google and with such a respected security team—why is it there's anything left for Copperhead to do?"
Copperhead OS, a two-man team based in Toronto, ships a hardened version of Android that aims to integrate Grsecurity and PaX into their distribution. Their OS also includes numerous security enhancements, including a port of OpenBSD’s malloc implementation, compiler hardening, enhanced SELinux policies, and function pointer protection in libc. Unfortunately for security nuts, Copperhead currently only supports Nexus devices.