Scan for POODLE using nmap from a Windows machine

Researchers from the Google Security Team have published findings about a vulnerability in SSL 3.0, a cryptographic protocol designed to provide secure communication over the internet. Although SSL 3.0 is nearly 15 years old, it's still used all over the place – browsers, VPNs, email clients, etc. In other words, this bug is pretty widespread.
 
Successful exploitation of this vulnerability can result in an attacker exposing data encrypted between an SSL 3.0 compatible client and a SSL 3.0 compatible server.  Overall, the issue is relatively difficult to exploit but you're still going to want to address it quickly.


What is the POODLE attack?

POODLE (Padding Oracle On Downgraded Legacy Encryption) is the attack that exploits this vulnerability. It allows an attacker to steal information over time by altering communications between the SSL client and the server (also known as a man in the middle attack, or MITM). This means that exploitation is NOT trivial; it takes some work.  
 
If SSLv2 and SSLv3 is disabled on the server, the issue is not exploitable. On the other hand, if one or both of these protocols is enabled, then the issue is exploitable. This is also how we are going to test whether your server is vulnerable to the POODLE flaw.


Scanning for POODLE with nmap on Windows

The nmap scan that we will launch will list all supported SSL/TLS ciphers and protocols. The scan will use the ssl-enum-ciphers nmap NSE script for this task.

The nmap command that we can use to scan for POODLE is the following:
nmap.exe -p 443 --script ssl-enum-ciphers -oN poodle_443 192.168.1.17

The command-line options that we specify mean the following:

  • -p 443: This indicates the port that we want to scan. Here we only scan port 443 which is the most common SSL/TLS port. If you have SSL/TLS servers running on other ports, you can add them by separating them with commas, e.g. -p 443,8080,8443,8888. If you leave out the -p parameter, nmap will scan a default list of the most common ports.
  • --script ssl-enum-ciphers: This indicates that the ssl-enum-ciphers NSE script should be executed on every found open port. This script will enumerate all SSL/TLS ciphers and protocols that the scanned server supports.
  • -oN poodle_443: Output scan in normal format to the given filename (in this case the filename will be poodle_443.nmap)
  • 192.168.1.17: This indicates the machine to scan.


If the server you are scanning supports the SSLv3 protocol, then it will be listed together with all supported SSLv3 ciphers in the output of the scan.
If the SSLv3 protocol is not supported, then either SSLv3 will not be present in the list of protocols. It can also occur that SSLv3 is listed, but with a message saying that no supported ciphers were found. This also indicated that SSLv3 cannot be used on the server, and therefore the server is also protected against the POODLE flaw.


Example output

Example output 1: a server supporting SSLv3, and therefore being vulnerable to POODLE

The example below shows the output of an nmap scan on a server that still supports the SSLv3 protocol. The fact that SSLv3 is still supported can be clearly seen in the output: after showing SSLv3, nmap lists all cipher-suites that can be used with the SSLv3 protocol on this particular server.

C:\TOOLS\nmap-6.40>nmap --script ssl-enum-ciphers -p 443 192.168.1.17

Starting Nmap 6.40 ( http://nmap.org ) at 2014-10-15 12:27 Romance Daylight Time

Nmap scan report for 192.168.1.17
Host is up (0.019s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       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_RC4_128_SHA - strong
|     compressors:
|       NULL
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       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_RC4_128_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

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



Example output 2: a server not supporting SSLv3, and therefore NOT being vulnerable to POODLE

The example below shows the output of an nmap scan on a server that does not support the SSLv3 protocol. The fact that SSLv3 is no longer supported can be clearly seen in the output: nmap lists SSLv3, but it also mentions that no supported ciphers were found. This indicated that SSLv3 cannot be used on this server. We have also seen outputs where SSLv3 is not even mentioned. This is dependent on the SSL/TLS configuration of the server.

C:\TOOLS\nmap-6.40>nmap --script ssl-enum-ciphers -p 443 192.168.1.17

Starting Nmap 6.40 ( http://nmap.org ) at 2014-10-15 12:33 Romance Daylight Time

Nmap scan report for 192.168.1.17
Host is up (0.019s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       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_RC4_128_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong

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



Additional links

Tags: 

Share

Comments

TLS ciphers under SSL?

I got asked a question that I haven't been able to find a good answer to.  Using nmap when a server supports SSLv3, there is a list of ciphers, but they all start with TLS.  My director asked why SSL would list TLS and I'm looking for a definitive answer.

Meaning of TLS at beginning of cipher name

The first piece of a cipher name has nothing to do with the actual SSL or TLS protocol. It merely refers to the RFC document in which the ciphersuite was defined.For example TLS RSA WITH RC4 128 SHA is a cipher suite that uses RSA for key exchange, RC4 as the bulk encryption algorithm and SHA1 as the hashing function for the MAC. It can be used on both SSLv3 and TLS connections. The TLS refers to the fact that this ciphersuite was defined in RFC 5246 which defined the TLS protocol (see http://tools.ietf.org/html/rfc5246#appendix-A.5).

Pages