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. $ 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. 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. 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. I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS London April 2021 |
Bojan 396 Posts ISC Handler Mar 1st 2017 |
Thread locked Subscribe |
Mar 1st 2017 4 years ago |
This seems like a non-issue. It's trying to run STARTTLS which means the connection would then shift to 686 (LDAPS). Or am I missing something here?
SSL on LDAP is very common, especially in Active Directory environments. |
Darron Wyke 19 Posts |
Quote |
Mar 8th 2017 3 years ago |
Well yea - it's trying to run STARTTLS, but the connection will not shift to 686 - it will continue using 389, with TLS activated.
I thought that's what made this interesting :) Cheers, Bojan |
Bojan 396 Posts ISC Handler |
Quote |
Mar 9th 2017 3 years ago |
Sign Up for Free or Log In to start participating in the conversation!