We, at a certain level, used to assume that when a connection uses HTTPS with SSL or TLS encryption, it is secured and any attacker that intercepts it will only receive a series of meaningless numbers. Well, this may not be absolutely true; the HTTPS servers need to be correctly configured to provide a strong layer of encryption and protect users from MiTM attacks or cryptanalysis. A number of vulnerabilities in implementation and design of SSL protocol have been discovered; thus, making the testing of secure connections mandatory in any web application penetration test.
In this recipe, we will use SSLScan, a tool included in Kali Linux, to analyze the configuration (from the client's perspective) of the server in terms of its secure communication.
- OWASP BWA virtual machine has already configured the HTTPS server, to be sure that it works right go to
https://192.168.56.102/, if the page doesn't load normally, you may have to check your configuration before we continue. - SSLScan is a command-line tool (it is inbuilt in Kali), so we need to open a new terminal.
- The basic
sslscancommand will give us enough information about the server:sslscan 192.168.56.102
The first part of the output tells us the configuration of the server in terms of common security misconfigurations: renegotiation, compression, and Heartbleed, which is a vulnerability recently found in some TLS implementations. In this case, everything seems to be fine.
In this second part, SSLScan shows the cipher suites the server accepts, and as we can see, it supports SSLv3 and some ciphers such as DES, which are now considered unsecure; they are shown in red color, yellow text means medium strength ciphers.
Lastly, we have the preferred ciphers, the ones that the server is going to try to use for communication if the client supports them; and finally, the information about the certificate the server uses. We can see that it uses a medium strength algorithm for signature and a weak RSA key. The key is said to be weak because it is 1024 bits long; nowadays, security standards recommend 2048 bits at least.
SSLScan works by making multiple connections to a HTTPS server by trying different cipher suites and client configurations to test what it accepts.
When a browser connects to a server using HTTPS, they exchange information on what ciphers the browser can use and which of those the server supports; then they agree on using the higher complexity common to both of them. If an MiTM attack is performed against a poorly configured HTTPS server, the attacker can trick the server by saying that the client only supports a weak cipher suite, say 56 bits DES over SSLv2, then the communication intercepted by the attacker will be encrypted with an algorithm that may be broken in a few days or hours with a modern computer.
As we mentioned earlier, SSLScan is able to detect Heartbleed, which is an interesting vulnerability recently discovered in the OpenSSL implementation.
Heartbleed was discovered in April 2014. It consists in a buffer over-read—more data can be read from memory than should be allowed—situation in the OpenSSL TLS implementation.
In practice, Heartbleed can be exploited over any unpatched OpenSSL (versions 1.0.1 through 1.0.1f) server that supports TLS and by exploiting it, it reads up to 64 KB from the server's memory in plain text, this can be done repeatedly and without leaving any trace or log on the server. This means that an attacker may be able to read plain text information from the server such as the server's private keys or encryption certificates, session cookies or HTTPS requests that may contain users' passwords and other sensitive information. More information on Heartbleed can be found on its Wikipedia page: https://en.wikipedia.org/wiki/Heartbleed.
SSLScan is not the only tool that can retrieve cipher information from SSL/TLS connections. There is another tool included in Kali Linux called SSLyze that could be used as an alternative and may sometimes give complimentary results to our tests:
sslyze --regular www.example.com
SSL/TLS information can also be obtained through OpenSSL commands:
openssl s_client -connect www2.example.com:443