Just when folks get around to implementing SSL, we need to retire SSL! Not a week goes buy that a client isnt 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 auditors recommendation was to update to SSL 3.0 (bad recommendation, keep reading on).">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 wasnt 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 clients *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">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
|_">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">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 youre still focused on that), and has an ssl-poodle script, but youll need to download that one from their script page at http://nmap.org/nsedoc/scripts/ - its not in the base installation.
While youre 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 - Im not thrilled with the 3des-cbc and MD5 support, but I guess thats why there">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)
|_">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, youd of course scan a wider range of ports (all of them if there">nmap -Pn -p22 192.168.122.0/24 --script=sshv1.nse
This scan didnt 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