At a recent penetration test, one of typical tests that everyone runs these days are available TLS/SSL ciphers. There are many tools that can be used for this – I personally prefer nmap’s ssl-enum-ciphers script, which does a great job on ranking ciphers similarly to what SSL Labs do (but you can run it on any port and on internal sites as well). A lot of people use testssl.sh, which is very nice as well.
I was going through results of a scan and noticed something weird – weak ciphers were reported for TCP port 389, which is LDAP. This actually caused me to think it is a false positive, but then – having such a false positive with nmap was unusual so I decided to dig deeper (read: thing that SANS ISC Handlers love the most: look into packets).
Here’s the output of the nmap script:

$ nmap -sT -Pn -p 389 10.0.161.5 --script ssl-enum-ciphers

Starting Nmap 7.40SVN ( https://nmap.org ) at 2017-03-01 21:06 CET
Nmap scan report for rhea.zoo.local (10.0.161.5)
Host is up (0.00036s latency).
PORT    STATE SERVICE
389/tcp open  ldap
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 1024) of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: C

As shown above – it’s certainly TCP port 389 and yet we have ciphers properly detected. Initially I thought this must be some kind of STARTTLS, which allows one to take an existing insecure connection and upgrade it to a secure connection using SSL/TLS. STARTTLS is very common on SMTP but here we’re talking about LDAP.
After doing a network capture I went to analyze packets and, since we’re talking about LDAP, the whole STARTTLS story looks a bit different. The important packet is shown in the figure below:

We can see that a specific OID is being requested here: LDAP_START_TLS_OID (1.3.6.1.4.1.1466.20037). This request basically tells the LDAP server STARTTLS – if the response is success, which we can see in the figure below, the client can start an SSL/TLS session:

After this the packet capture shows normal SSL/TLS continuation where Client Hello, Server Hello and all other required packets are exchanged.
The listing above shows also a lot of ciphers which are today not considered secure or best practice.

However, before blindly screaming SSLv3 and POODLE, it should be noted that exploitation of this vulnerability requires the attacker (besides performing a MitM attack) to be able to make the client send some arbitrary requests (so proper padding can be provoked), which might not be that easy or possible for protocols such as LDAP – but I’ll leave this for a future diary.

--
Bojan
INFIGO IS
@bojanz