Flushing out the Crypto Rats - Finding "Bad Encryption" on your Network

Published: 2014-12-01. Last Updated: 2014-12-01 14:45:43 UTC
by Rob VandenBrink (Version: 1)
4 comment(s)

Just when folks get around to implementing SSL, we need to retire SSL!  Not a week goes buy that a client isn't asking me about SSL (or more usually TLS) vulnerabilities or finding issues on their network.

In a recent case, my client  had just finished a datacenter / PCI audit, and had one of his servers come up as using SSL 2.0, which of course has been deprecated since 1996 - the auditor's recommendation was to update to SSL 3.0 (bad recommendation, keep reading on).  When he then updated to SSL 3.0 and was re-scanned, the scanner of course found problems with *that* too - and the recommendation changed to update to TLS 1.1 or 1.2 - SSL 3.0 has its own set of issues, including the furor around the recent POODLE vulnerability.

This shows two things actually:

1/ W-a-a-a-y too many assessments consist of scanning the target, and pasting the output of the scanning tool into the final report.  

2/ In this case, the person writing the report had either not read the text they were pasting, or was not knowledgeable enough to understand that updating from SSL 2 to SSL 3 wasn't going to get to a final "good" state.  Shame on them either way!

As a side note, if the site (it was on an internal network remember) was running plain old HTTP, then  the scanner would not have identified a problem, and the person behind the scanner would very likely have missed this completely! (OOPS)

Anyway, my client's *real* question was "how can we scan our network for vulnerable SSL versions and ciphers, but not pay big bucks for an enterprise scanning tool or a consultant?"

My answer was (that day) - NMAP of course!

To check for weak or strong ciphers on a server or subnet, use the script "ssl-enum-ciphers"

nmap -Pn -p443 isc.sans.edu --script=ssl-enum-ciphers  (Bojan covered this one in some detail in August, at https://isc.sans.edu/diary/18513 )

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 09:42 Eastern Standard Time

Nmap scan report for isc.sans.edu (66.35.59.249)
Host is up (0.097s latency).
rDNS record for 66.35.59.249: isc.sans.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 34.63 seconds

You can scan specifically for SSHv2 devices using the script "sshv2.nse"

nmap -Pn -p443 --open  192.168.122.0/24 --script=sslv2

Oops - this scan found a server admin card (an iLO equivalent) on my home network that I thought that I had updated (my bad)

Nmap scan report for 192.168.122.246
Host is up (0.029s latency).
PORT    STATE SERVICE
443/tcp open  https
| sslv2:
|   SSLv2 supported
|   ciphers:
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|_    SSL2_RC4_128_EXPORT40_WITH_MD5
MAC Address: 00:E0:81:CE:9E:74 (Tyan Computer)

NMAP also has scripts ssl-heartbleed script (if you're still focused on that), and has an ssl-poodle script, but you'll need to download that one from their script page at http://nmap.org/nsedoc/scripts/  - it's not in the base installation.

While you're at it, take a look at cipher support on any SSH enabled devices on your network - you are likely to be surprised at what you find.  For instance, this is the management interface of my home firewall - I'm not thrilled with the 3des-cbc and MD5 support, but I guess that's why there's a new firewall in a box, just waiting for a free day for me to swap it in I guess.

nmap -Pn -p22 192.168.122.1 --script=ssh2-enum-algos.nse

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-27 17:02 Eastern Standard Time

Nmap scan report for 192.168.122.1
Host is up (0.0020s latency).
PORT   STATE SERVICE
22/tcp open  ssh
| ssh2-enum-algos:
|   kex_algorithms: (1)
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (1)
|       ssh-rsa
|   encryption_algorithms: (4)
|       aes128-cbc
|       3des-cbc
|       aes192-cbc
|       aes256-cbc
|   mac_algorithms: (4)
|       hmac-sha1
|       hmac-sha1-96
|       hmac-md5
|       hmac-md5-96
|   compression_algorithms: (1)
|_      none
MAC Address: C8:4C:75:DA:31:E3 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 47.39 seconds

Or, for a real eye-opener, scan your subnet for SSHv1 enabled devices - note that this scan (and the previous one) assumes that your SSH service is on port 22.  In a "zero knowledge" scan, you'd of course scan a wider range of ports (all of them if there's time for that):

nmap -Pn -p22 192.168.122.0/24 --script=sshv1.nse

This scan didn't find anything at my house, but it *always* finds stuff at client sites!

What crypto support issues have you found when you scanned for them?  And how long do you thing these problems were there?  Please, share your story using our comment link!

===============
Rob VandenBrink
Metafore

Keywords:
4 comment(s)

Comments

Hey, thanks for the info!

I like nmap but most of the time find I am not using it on a daily basis so I have to revamp my understanding every time I want to use it.

I have been using SSLScan, which does only scanning for SSL certificates and identifies cipher suites surpported, and includes the option of scanning non-standard ports, which is very useful.

It runs on Linux and has a Windows port.
Maybe a noob question...but I am confused by the output of my scan

------------

ssl-enum-ciphers:

| SSLv3:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: weak

All the SSLv3 ciphers are prefixed with 'TLS' and seem to be TLSv1.0 ciphers rather than SSLv3.0 ciphers.

Am I missing something?

cheers
SSL 3.0 and TLS 1.0 are very similar, but do not inter-operate. This explains why the cipher lists might look the same, but nmap tags some as TLS 1.0 and some as SSL 3.0

You'd need to look at the NSE script source code in some detail, or perhaps compare the NMAP output to your server config - - it wouldn't surprise me if NMAP is making the protocol decision just based on the cipher support, which could very well give you false results.
If that's what you're seeing, please ping me back! If that's the case, it's definitely worth a deeper look, another story and a conversation with Fyodor.

There's an interesting discussion on how the enum script is evolving here:
http://seclists.org/nmap-dev/2014/q4/153
Looks like this NSE script has changed quite a bit lately, and we can expect more changes as the code gets refined. This also references the changes that Bojan put into the script (at https://github.com/bojanisc/nmap-scripts )

Anyway, while the two protocols (SSL 3.0 and TLS 1.0) do share the same ciphers, they do operate differently. This site summarizes the differences nicely:
http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html

From that site:

SSL 3.0

This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn't released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
-Separation of the transport of data from the message layer
-Use of a full 128 bits of keying material even when using the Export cipher
-Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
-Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
-Allowing for record compression and decompression
-Ability to fall back to SSL 2.0 when a 2.0 client is encountered

Netscape's Original SSL 3.0 Draft: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
Comparison of SSLv2 and SSLv3: http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html


TLS 1.0

This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don't interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
-Key derivation functions are different
-MACs are different - SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
-The Finished messages are different
-TLS has more alerts
-TLS requires DSS/DH support

RFC 2246: http://tools.ietf.org/html/rfc2246
Thanks for the reply Rob.

We did a pretty good job of mitigating POODLE...but I was surprised to find so many hits on the scans I did this afternoon.

As it turns out, without exception, all the hits were on iLO boards and the web interfaces of our Xerox Phaser printers. It will take some time to investigate what exactly the cipher support is on these devices. For the printers, the latest firmware dates back to 2009...so I doubt that this can be mitigated at all.

thanks again....

Diary Archives