Weak Ciphers can be your key to MITM (Man in the Middle) traffic sniffing, so whats the best approach to discover them? There are many methods out there, Qualys SSL Labs is one of the most popular for scanning websites, but what about an internal server not publicly available?
Fire up your Kali VM, install TestSSL.sh and start scanning. Quick scanning capability, many scan parameter options and easy to read results make this a great tool for Cipher Recon.
Install TestSSL.sh
testssl.sh is not installed by default on the newer releases of Kali (2020.4) so that will need to be done prior to use. Info on the TestSSL project can be found here: https://testssl.sh/ make sure to read up on it before running in your own environment.
root@kali:~# sudo apt-get install testssl.sh
> then hit Y for accepting the install
(sudo isn’t needed if your running Kali as root, force of habit)
Once installed to run your first scan
# this is the basic scan, there are many parameters available for a specific scan style, running the ‘testssl’ command alone will give the full breakdown on parameters.
root@kali:~# testssl “target IP address”
If port 443 is not open you will receive a scan error, why is that? Remember we are scanning for vulnerable ciphers, you wont see a cipher handshake attempt when using port 80 / http.
Even though 443 is the default you can target any port that has an SSL enabled service listening, here are a few examples from testssl.sh website.
Example scans below use 443, so results start to pour in with that basic command above. With the initial search done by IP, TestSSL will perform a Revers DNS lookup and pull back the FQDN (Fully Qualified Domain Name). Side note: if the rDNS name does not match up its nothing really to worry about, maybe DNS scavenging isn’t enabled, maybe its not quite caught up on a stale record, either way running the scan against an IP should return accurate results for that target.
Initially testing protocols via socket for SSL and TLS versions, as well as NPN/SPDY and ALPN/HTTP2. Immediate red flags appear in our scan, our target server is running deprecated versions of TLS 1 and TLS 1.1. Again very easy to read results making this a tool anyone can use and gain valuable recon insight whether RedTeam or BlueTeam.
Moving on the next category up is Cipher Categories, this is looking for missing encryption, missing authentication, Obsolete Ciphers etc. Here we start to see a few more issues.
Low:64 Bit + DES, RC(2,4) (w/o export):
Triple DES Ciphers / IDEA:
Obsolete CBC Ciphers (AES, ARIA etc.):
Eliptical Curve Ciphers
Server Default Hello / certificate information
The error below was in reference to a wildcard certificate installed which did not match the domain name of the server.
HTTP header response
Vulnerabilities
Here is a nice set of leads, TestSSL takes the discovered Cipher list and cross references it against known CVEs. The following three vulnerabilities should be further researched for exploitation possibilities.
ROBOTS CVE – Oracle Vulnerability from 2017
SWEET32 CVE-2016-2183- Vulnerability in DES/3DES and CVE-2016-6329 – 64-bit block Cipher vuln
RC4 CVE-2013-2566- Single-byte bias in RC4 and CVE-2015-2088
Ciphers Suite test
Client simulation
The weak cipher versions suffer from cryptographic flaws that make it possible for us to potentially discover sensitive information or as stated above conduct MITM attacks. Both NIST and PCI DSS standards state these versions no longer qualify as “strong cryptography” and are not acceptable for secure communications. Since June 2018, SSL 3.0 and TLS 1.0 have been prohibited in PCI-regulated environments. Many of the major browsers are already refusing to connect to servers that use TLS 1.1 or earlier.
Even a strong protocol can be undermined by weak ciphers. Servers often ship with old or weakened cipher suites to allow backwards compatibility with old clients.
In this quick write-up on how run a basic scan for Ciphers with TestSSL.sh we’ve focused on the RedTeam side of the house. We didn’t go in depth on the “how” of exploitation of weak cipher vulnerabilities, that will be another day.
We’ll run through mitigations of these vulnerabilities back on the BlueTeam blog section soon.
Weister Creek Information Security – 7/8/2021
WEISTER CREEK 