Auditing the SSL/TLS Configuration of Network Services
In today's blog post I will guide you through the process of auditing your network service's SSL/TLS configuration. We will utilize three open-source tools in order to map out available network services (nmap), scan their SSL/TLS configuration (testssl.sh) and convert the results into a beautiful XLSX report (pentest2xlsx).
The final result will look something like this:
Introduction
Transport Layer Security (TLS) plays a vital role by establishing a secure and encrypted transport channel between a client and a server. The transmitted data is therefore end-to-end encrypted (transport layer) and cannot be inspected by an outside attacker (e.g. in a Man-in-the-Middle position).
However, default SSL/TLS configurations may leave us vulnerable to publicly known issues and misconfigurations. Deprecated SSL/TLS protocols such as SSLv2, SSLv3, TLSv1.0, TLSv1.1 must be disabled and the offered cryptographic algorithms and ciphers suites hardened.
What's considered outdated?
As many of you hopefully know, Secure Socket Layer (SSL) is an old and deprecated technology. It was superseded by Transport Layer Security (TLS), which supports improved security internals. Furthermore, various outdated cryptographic algorithms and cipher suites exist, which are often offered but are not considered secure or state-of-the-art.
However, what must be disabled? What is considered modern and state-of-the-art? Let's talk about it.
SSL/TLS Protocol Versions
As outlined, SSL is considered a very old and deprecated standard. All SSL protocol versions such as SSLv2 and SSLv3 are therefore dated and should not be supported anymore. Some of you may scream "LEGACY PROTOCOL" now but I personally doubt the general need of such deprecated protocols. If there are clients, which cannot support TLS, please reconsider whether you even want to serve such clients. Take your part of forcing such client software to be upgraded.
So the answer is easy, right? Just disable SSL and support TLS only!
Not so fast. Although TLS is considered the most modern standard, which should be used and supported, TLS has its weaknesses also. In detail, the TLS protocol versions 1.0 and 1.1 are fairly old, deprecated and can lead to various security vulnerabilities.
The support for those protocol versions in modern browsers dwindles and many browsers start displaying a warning message if such a communication channel is established. For all SSL protocols, most browsers will not even establish a connection.
Therefore, it is recommended to offer TLSv1.2 and TLSv1.3 only.
SSL/TLS Cipher Suites
Another factor, besides the offered and applied SSL/TLS protocol, are cryptographic algorithms and cipher suites. Those are the key details of how a secure, encrypted communication channel is established between a client and a server.
Those ciphers are negotiated between a client and a server. Therefore, if a server only offers top-notch ciphers, which a client cannot support, a secure communication cannot be established. Therefore, it is important to find a balance between secure ciphers and some weaker ones, to support a multitude of varying clients. In the end, a client and server will usually agree on the most secure and strong ciphers possible (neglecting potential downgrading attacks by a MitM attacker).
So which ciphers suites are insecure or weak and should not be supported anymore? I will not go into detail much but if you see some of the following key words, it is very likely that the offered cipher suites are not the well chosen:
- DES
- 3DES
- MD5
- RC4
- SHA1
- ARCFOUR
- ANON
- EXPORT
- CBC
For more details, you may have a look at:
Hans Christian Rudolph
If you want to identify whether you support such weak cipher suites in your IT infrastructure, please keep reading. In this blog post, we will guide you through auditing and identifying security gaps regarding your SSL/TLS configuration.
SSL/TLS Vulnerabilities
Depending on which SSL/TLS protocol is supported and established between a client and a server as well as which cipher suites are negotiated, various vulnerabilities may exist and can be applied to an encrypted communication channel.
For the sake of simplicity, I will outline a few of the most common and popular SSL/TLS vulnerabilities as well as misconfigurations:
Heartbleed (CVE-2014-0160)
- Heartbleed is a critical security flaw in the OpenSSL library, which is commonly used for encrypting SSL/TLS connections. The flaw allows attackers to extract private keys, secret data, and passwords from the main memory of an affected system. Since the data is extracted directly from memory, it is not detectable by log or application logs and can be easily reused. Heartbleed can be executed without any detection and affects a large number of web servers, networks and systems worldwide.
RC4 (CVE-2013-2566, CVE-2015-2808)
- All versions of SSL and TLS with RC4 encryption are vulnerable to MitM (Man-in-the-Middle) attacks. It has been proven that it is possible to restore limited amounts of plain text transmitted over an RC4-encrypted connection.
WinShock (CVE-2014-6321)
- WinShock is a critical security flaw that affects the implementation of SSL/TLS in Microsoft Windows systems. The attack allows an attacker to exploit a vulnerability in the handling of TLS extensions to break a secure SSL/TLS connection and obtain sensitive information such as passwords or confidential data. The impact of WinShock is far-reaching as the affected software is widely distributed on many Windows systems and therefore a large number of users may be affected. It is important that Windows systems are protected against WinShock as soon as possible to ensure data security and confidentiality.
CRIME (CVE-2012-4929)
- CRIME stands for "Compression Ratio Info-leak Made Easy" and refers to an attack on SSL/TLS compression functions. CRIME uses the way data is compressed over an SSL/TLS connection to spy on sensitive data such as passwords and cookies. Because many applications rely on SSL/TLS compression to improve transmission speed, CRIME is a critical security flaw that can compromise data confidentiality and integrity. CRIME can run on a variety of applications and systems that support SSL/TLS compression.
POODLE (CVE-2014-3566)
- The POODLE attack (Padding Oracle On Downgraded Legacy Encryption) is an attack on the CBC mode of SSL 3.0 encryption. Unlike the BEAST and LUCKY13 SSL attacks, there is no implementable workaround, defacto there are therefore no secure CBC SSL 3.0 ciphers. To achieve guaranteed secure encryption, SSLv3 must be completely avoided or disabled.
DROWN (CVE-2016-0800)
- The DROWN (Decrypting RSA with Obsolete and Weakened Encryption) attack is a cross-protocol security flaw that attacks servers that support modern SSLv3/TLS protocol suites by leveraging their support for the obsolete, insecure SSLv2 protocol to launch an attack on connections that use current protocols and would otherwise be secure.
Secure Client Renegotiation (CVE-2011-1473)
- SSL/TLS client-initiated renegotiation is a feature that allows clients to renegotiate new encryption parameters for an SSL/TLS connection within a single TCP connection. Due to the higher computational overhead on the server side, this can lead to Denial of Service (DoS) attacks.
Secure Renegotiation (CVE-2009-3555)
- A design flaw in TLS allows an attacker to inject plaintext of his choice into a victim's TLS session. An attacker could restore sensitive information such as authentication tokens from a secure connection.
Logjam (CVE-2015-4000)
- A logjam attack (CVE-2015-4000) is a downgrade attack on TLS that allows an attacker to read and modify all data transmitted over an encrypted connection. The attack affects servers that support DHE_EXPORT encryption.
- Sometimes, no export ciphers are offered but a common DH prime in use. If the common DH prime has less than 2048-bit, it is known that the NSA would be capable of compromising an encrypted communication channel. Go ahead and craft a new, custom DH prime with >= 2048-bit.
Weak Diffie-Hellmann (DH)
- The use of a weak Diffie-Hellman (DH) key with ≤ 1024-bit may allow an attacker to break the used encryption through crypto-analysis (depending on the modulus size and resources of the attacker). This could allow an attacker to reconstruct plaintext or affect the integrity of a connection.
ROBOT (Return Of Bleichenbacher's Oracle Threat)
- ROBOT is an attack on the RSA cryptosystem used in many SSL/TLS implementations. The attack exploits a vulnerability in the so-called padding method used in RSA-based encryption schemes. A successful ROBOT attack can allow an attacker to spy on the contents of encrypted SSL/TLS messages and obtain secret information such as passwords or cookies. However, performing a ROBOT attack requires a significant amount of processing power and can therefore be difficult for an attacker. Nevertheless, ROBOT is a critical security flaw that can occur in many SSL/TLS implementations and should therefore be fixed urgently.
Ticketbleed (CVE-2016-9244)
- Ticketbleed is a security flaw in the implementation of SSL/TLS session-resuming functions, which are used by many websites and applications to improve the transmission speed of SSL/TLS connections. The flaw allows an attacker to read portions of the affected server's memory, including sensitive information such as passwords and cookies. Because SSL/TLS session resuming is a widely used functionality, Ticketbleed can affect a large number of systems and applications. A successful Ticketbleed attack can compromise the integrity and confidentiality of data.
FREAK (CVE-2015-0204)
- FREAK stands for "Factoring Attack on RSA-EXPORT Keys" and refers to an attack on RSA key exchange methods in SSL/TLS protocols. FREAK uses weak RSA keys (<= 512-bit) created for export to legacy systems with limited cryptography to hijack a connection and detect and read the contents of encrypted SSL/TLS connections. Since many systems are programmed to fall back to weaker RSA keys when they need to communicate with an older system, FREAK can run on many systems. FREAK compromises the confidentiality of data transmitted over an SSL/TLS connection.
CCS (CVE-2014-0224)
- CCS stands for "ChangeCipherSpec" attack and refers to a vulnerability in the implementation of SSL/TLS protocols. By mishandling the "ChangeCipherSpec" message type used in SSL/TLS protocols, an attacker can compromise the confidentiality of data transmitted over an SSL/TLS connection. A successful CCS attack can allow an attacker to spy on the contents of encrypted messages and obtain secret information such as passwords or cookies. CCS is a critical security flaw that can occur in a variety of SSL/TLS implementations.
TLS Fallback SCSV
- To counter downgrade attacks on a secure TLS connection, TLS fallback SCSV was introduced. This depends on the SSL library used, which should always be kept up to date.
BREACH (CVE-2013-3587)
- An attack against HTTPS using HTTP compression (e.g. gzip). BREACH is based on the security exploit CRIME.
BEAST (CVE-2011-3389)
- BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. It allows an attacker with prior Man-in-the-middle (MitM) access to compromise a user's SSL/TLS-protected HTTPS cookie. This would allow an attacker to steal the victim's active HTTPS-protected session or intercept the previously cryptographically protected network stream.
LUCKY13 (CVE-2013-0169)
- A LUCKY13 attack (CVE-2013-0169) is a timing attack on implementations of the TLS protocol that use CBC mode when an obsolete version of OpenSSL is used. An attacker could exploit this problem and restore sensitive data from a secure connection.
SWEET32 (CVE-2016-2183, CVE-2016-6329)
- The SWEET32 vulnerability relates to a birthday attack against 64-bit block encryptions such as DES and 3DES. The vulnerability could be exploited by a man-in-the-middle (MITM) attack by attackers intercepting a long-standing HTTPS connection. Successful exploitation of this problem could allow the attacker to steal a user session.
Null Ciphers
- Null ciphers provide no encryption, effectively leaving the communication channel unencrypted. This allows sensitive data to be learned by an attacker should he bind himself in a man-in-the-middle (MitM) position between victim and server.
Anonymous Ciphers
- Anonymous ciphers, often referred to as "anonymous Diffie-Hellman ciphers," rely on the Diffie-Hellman key exchange algorithm to establish a secure connection. However, they do not provide any server authentication, leaving the client vulnerable to Man-in-the-Middle (MitM) attacks.
Low Cipher Suites
- Support for weak 64-bit ciphers or 3DES/RC4 allows an attacker to break the encryption because the algorithms used are outdated and have vulnerabilities.
Weak Cipher Suites
- Supporting weak 112-bit ciphers or 3DES/IDEA allows an attacker to break the encryption because the algorithms used are outdated and may have vulnerabilities.
Obsolete Cipher Suites
- Support for obsolete ciphers, such as seed or 128/256-bit CBC ciphers, allows an attacker to break the encryption because the algorithms used are outdated and may have vulnerabilities.
Auditing SSL/TLS Configurations
In order to audit the SSL/TLS configuration of your network services, we will follow a three-step approach:
- Execute an Nmap portscan in order to identify available network services within your IT infrastrucuture.
- Identify STARTTLS network services as well as regular SSL/TLS network services to be audited with testssl.sh.
- Execute an SSL/TLS scan with testssl.sh and convert the JSON outputs into a beautiful XLSX report.
Nmap Portscanning
It is recommended to execute a full-portrange Nmap scan of your entire IT infrastructure. Doing it this way, we ensure that all network services are in scope and identified during the process. Alternatively, if you do not want to scan your entire infrastructure, you can also scan individual target hosts with nmap or directly with testssl.sh. This is not part of this blog post though.
For everyone following this blog post, please go ahead and scan your entire infrastructure with the Nmap portscanning tool. You may want to head out to my older blog post, talking about Nmap:
LRVT
Otherwise, it's a matter of executing the following Nmap command from a Linux machine within your target IT infrastructure. Just pass a file with your IT hostnames or IP addresses (line by line) into Nmap via the -iL CLI parameter:
sudo nmap -sS -sV -Pn --open --min-hostgroup 256 --min-rate 7000 --max-retries 2 -oA nmap_fullrange_portscan -vvv -p- -iL <FILE-WITH-HOSTS-AND-IPS>Nmap will automatically try to resolve hostnames to an IP address. It will also try to resolve IP addresses to a hostname via reverse DNS lookups (PTR records). So if your internal DNS server returns such entries, you will be fine defining a whole IP subnet range like /24 or so.
The scan may take a while to run, depending on the size of your IT infrastrucuture and the alive hosts as well as offered network services. Be patient and let it finish.
As a result you will obtain various output files, which we will use in the next steps.
Identifying STARTTLS/SSL/TLS Services
After conducting an Nmap portscan on your IT infrastructure, we now have the data in place to identify STARTTLS and SSL/TLS network services. This part is crucial as we now select the services to be later audited for weaknesses.
The final tool testssl.sh, which we use to audit an SSL/TLS configuration in step 3, is capable of taking an Nmap results file as input and identify SSL/TLS/STARTTLS services automatically. Therefore, we may feel tempted to just go straight into step 3.
However, there is a high chance that your IT infrastructure operates web servers, load balancers or reverse proxies that rely on virtual hostnames. As testssl.sh will only take an IP address of an identified SSL/TLS/STARTTLS network service, we may skip a relevant configuration for a specific virtual host web application.
If you'd like to take this edge case into account, keep on reading. Otherwise, head to step 3 where we will conduct our SSL/TLS scanning with the tool testssl.sh
Enumerating vHost HTTPS URLs
In order to identify HTTPS URLs in your IT infrastructure, we can again rely on the conducted Nmap portscan. We will utilize a Python3 script from GitHub to go over the Nmap output file and extract HTTPS URLs.
HaxxnetBasically a matter of executing the following commands:
git clone https://github.com/Haxxnet/nmap2urls && cd nmap2urls
python3 nmap2urls.py --file <path-to-your-nmap-xml-file> | grep https:// | while read line; do echo "-s -f -p -S -P -h -U --ip one --htmlfile . --jsonfile-pretty . --warnings=batch --parallel --ssl-native --fast --openssl-timeout 180 $line"; done | tee testssl_batch.txtThe resulting testssl_batch.txt file will later be passed into testssl.sh for auditing.
Auditing SSL/TLS with Testssl.sh
The heavy work of auditing the SSL/TLS configuration of network services is done with the tool testssl.sh.
drwetterThe approach looks something like this:
- Install testssl.sh
- Use testssl.sh and pass the Nmap GNMAP file as input. This will create a multitude of JSON output files.
- Use testssl.sh and pass the created
testssl_batch.txtfile as input. This will create a multitude of JSON output files. Optional task, as outlined above. - Convert all testssl.sh JSON files into an XLSX report with pentest2xlsx.
Install Testssl.sh
# via package manager
sudo apt install testssl.sh
# or simply download the latest release from github
# https://github.com/drwetter/testssl.sh/releases/Testssl.sh + Nmap Output File
# pass the nmap .gnmap output file into testssl.sh
testssl.sh -s -f -p -S -P -h -U --ip one --htmlfile . --jsonfile-pretty . --warnings=batch --parallel --ssl-native --fast --openssl-timeout 180 -iL nmap_fullrange_portscan.gnmap
Testssl.sh + Batch File
# pass the created batch file into testssl.sh
testssl.sh --parallel -iL testssl_batch.txtConverting Results into XLSX Report
# clone the github repo
git clone https://github.com/aress31/pentest2xlsx && cd pentest2xlsx
# convert all testssl.sh json output files into xlsx report
python3 pentest2xlsx.py testssl -iJ *.jsonSummary
Finally, you should have created a beautiful XLSX report with all necessary information regarding the SSL/TLS/STARTTLS configuration of your network services.
Go ahead and inspect the XLSX for severe misconfigurations and vulnerabilities in your IT infrastructure. You may have to remove duplicates if necessary. The most relevant entries are properly colorized according to an issue's risk. If you require in-depth details, please inspect the relevant testssl.sh log files. Those are properly referenced in the XLSX report and were created during your testssl.sh runs.
For mitigating and fixing the identified issues, please refer to NIST, OWASP and in general to your product manufacturer's documention on how to harden the SSL/TLS configuration.
SSL.com Support Team
April King
Member discussion