Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Flushing out the Crypto Rats - Finding "Bad Encryption" on your Network InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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)
Diary Archives