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:

  • Use of the SNI field. All reasonably modern browsers use this field.
  • Number of Ciphers used. I could look at individual ciphers, but the size of the ciphers offered field was easier to investigate
  • The total size of all extensions. Again simpler than looking at individual extensions. I subtracted the size fo the SNI option to eliminate variability due to different host names we use.

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:

Frequency Hostname
400 No SNI Option
1281 /

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:

  • BING: Looks like BING doesnt support SNI yet. This is kind of odd for a major search engine.
  • Some obviously fake user agents. They claim to be a modern browser, but for example only hit one particular URL over and over.
  • Nagios, the monitoring software (no surprise)
  • Python-urllib. Again, no surprise
  • wget
  • various RSS feed and Podcast clients

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 from54.213.123.74, which resolves to" />

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)

In conclusion:

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.

Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

(credit: Cao et al.)

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.

At the 25th Usenix Security Symposium on Wednesday, researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit that allows them to inject content into an otherwise legitimate USA Today page that asks viewers to enter their e-mail and passwords. The malicious, off-site JavaScript code attack is possible because the vulnerable USA Today pages aren't encrypted. Even if they were protected, attackers could still terminate the connection. Similar attacks work against a variety of other unidentified sites and services, as long as they have long-lived connections that give hackers enough time—roughly 60 seconds—to carry out the attack.

Read 8 remaining paragraphs | Comments

Cisco Security Advisory: Cisco IOS XR Software for Cisco ASR 9001 Aggregation Services Routers Fragmented Packet Denial of Service Vulnerability
Google Chrome Prior to 44.0.2403.89 Multiple Security Vulnerabilities
OpenStack Nova CVE-2015-8749 Information Disclosure Vulnerability
giflib CVE-2016-3977 Heap Based Buffer Overflow Vulnerability
Oracle Java SE CVE-2016-3550 Remote Security Vulnerability
Apache Xerces-C CVE-2016-0729 Buffer Overflow Vulnerability
First responders often have trouble communicating with each other in emergencies. They may use different types of radios, or they may be working in rural areas lacking wireless coverage, or they may be deep inside large buildings that ...

(credit: Guardian Project)

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.

Read 42 remaining paragraphs | Comments

Oracle Java SE and JRockit CVE-2016-3425 Remote Security Vulnerability
Internet Storm Center Infocon Status