Ever wondered what will be the consequences if the link that is established between web server and browser is not encrypted one or a secured? Many attacks can happen !!so that is the reason why Secure Socket Layer SSL is used.
By this we can assume like SSL is very secure and hard to hack!! But it is no more!!!
Wanna Know how to hack websites that are even protected by SSL then you shouldn’t miss the article . Let’s get into it.
Attacking Secure Sockets Layer
Secure Sockets Layer (SSL) and Transport Layer Security (TLS), are cryptographic protocols used to provide secure communications across the Internet.
These protocols have been widely used in secure applications like the Internet messaging and e-mail, web browsing, and voice-over-IP.
These protocols are used across the Internet, they were started in the mid of1990s and are increasingly coming under attack. SSL Version 2.0 (Version 1.0 was never publicly released) contains a significant number of flaws that can be exploited, such as poor key and are vulnerable to man-in-the-middleattacks.
Although most users use Version 3.0 protocol and its newer versions of TLS, a misconfiguration can still lead to vulnerability.
Configuring Kali for SSLv2 scanning
Before beginning, verify that Kali has been configured to scan for SSL 2 protocols.
From a terminal window, enter the following command:
root@kali:~# openssl_s_client –connect www.opensecurityresearch.com:443 -ssl2
If this returns an unknown option -ssl2 error, then the additional configuration will be required.
To fix it, following these steps carefully:
- Install quilt, a program used to manage multiple patches to an application’s source code, using the following command:
root@kali:~# apt-get install devscripts quilt
- Download the openssl source code, and apply the patches, update the configuration files, and then rebuild the application. Use the following commands:
root@kali:~# apt-get source openssl root@kali:~# cd openssl-1.0.1e root@kali:~/openssl-1.0.1e# quilt pop –a
- Edit the /openssl-1.0.1e/debian/patches/series file, and delete the following line:
- Edit the /openssl-1.0.1e/debian/rules file, and delete the no-ssl2 argument and apply patches to openssl. Use the following commands:
root@kali:~/openssl-1.0.1e# quilt push -a root@kali:~/openssl-1.0.1e# dch -n 'Allow SSLv2'
- After completing, rebuild the openssl package, and then reinstall it. This step can be performed with the following commands:
root@kali:~/openssl-1.0.1e# dpkg-source --commit root@kali:~/openssl-1.0.1e# debuild -uc -us root@kali:~/openssl-1.0.1e# cd /root root@kali:~# dpkg -i *ssl*.deb
- Confirm that patches have been successfully applied by reissuing the command to connect using SSLv2, as shown in the following screenshot:
Kali scripts that rely on openssl, particularly sslscan, will need to be recompiled. To recompile, first, download the source and then rebuild it. When this is complete, reinstall it using the following commands:
root@kali:~# apt-get source sslscan root@kali:~# cd sslscan-1.8.2 root@kali:~/sslscan-1.8.2# debuild -uc -us root@kali:~/sslscan-1.8.2# cd /root rootl@kali:~# dpkg -i *sslscan*.deb
Reconnaissance of SSL connections
The reconnaissance phase remains important when assessing the SSL connectivity, especially when reviewing the following items:
- The x.509 certificate which is used to identify the systems involved in establishing the connection
- The type of encryption which is being used
- The configuration information
The SSL certificate can provide information which can be used for social Engineering attack. An attacker must check if the certificate is valid or not. Certificates that are invalid may cause an error in the signature.
If the user had previously accepted an invalid certificate, then the victim might accept a new invalid certificate, making the attacker easy.
The type of encryption used to secure an SSL connection is basically divided into the following categories:
- Null cyphers: These cyphers are used to verify the authenticity of a transmission. Because no encryption is applied, they do not provide any security.
- Weak cyphers: This is the cyphers with a key length of 128 bits or less. Cyphers that use the Diffie-Hellman algorithm for a key exchange can also be considered as weak since they are vulnerable to
- Strong cyphers: These are those cyphers that exceed 128 bits. currently, the most secure option is the AES encryption with a 256-bit key.
SSL and TLS rely on cypher suites to establish a secure connection. There are more than 30 such suites, and the complexity for selecting the best option results in users defaulting to less secure options. Therefore, each SSL and TLC connection must be tested.
To conduct reconnaissance against SSL connections, use the NSE modules of nmap or SSL-specific applications. The nmap NSE modules are described in the following table.
|Nmap NSE module||Module Function|
|ssl-cert||Retrieves the server’s SSL certificate. The amount of information returned depends on the verbosity level (none, -v, and -vv).|
|ssl-date||Retrieves a target host’s date and time from its TLS ServerHello response.|
|ssl-enum-ciphers||Repeatedly initiates SSL and TLS connections, each time trying a new cypher and recording if the host accepts or rejects it. Cyphers are shown with a strong rate. This is a highly intrusive scan and may be blocked by the target.|
|ssl-google-cert-catalog||Queries Google’s Certificate Catalogue for information that pertains to the SSL certificate retrieved from the target. It provides information on how recently, and for how long, Google has been aware of the certificate. If a certificate is not recognised by Google, it may be suspicious/false.|
|ssl-known-key||Checks whether the SSL certificate used by a host has a fingerprint that matches databases of compromised or faulty keys. Presently, it uses the LittleBlackBox database. However, any database of fingerprints can be used.|
|sslv2||Determines whether the server supports the obsolete and less secure SSL Version 2 and which cyphers are supported.|
To invoke a single script from the command line, use the following command:
root@kali:~# nmap --script <script name> -p 443 <Target IP>
In the following example, the ssl-cert script was invoked with the -vv option for maximum verbosity. The data on from this script is shown in the following screenshot
During the reconnaissance, an attacker can launch all SLL modules using the following command:
root@kali:~# nmap --script "ssl*" <IP address>
Kali’s attack tools that are specific to SSL can be invoked from the command line or selected from the menu by navigating to Kali Linux | Information Gathering | SSL Analysis. The tools are mentioned in the table below:
|sslcaudit||Automates the testing of SSL and TLS clients to determine the resistance against man-in-the-middle attacks.|
|Ssldump||Conducts network protocol analysis of SSLv3 and TLS communications. If provided with the appropriate encryption key, it will decrypt SSL traffic and display it in the clear.|
|Sslscan||Queries SSL services to determine which cyphers are supported. Output includes the preferred SSL cyphers and is displayed in text and XML formats.|
|Sslsniff||Enables man-in-the-middle attack conditions on all SSL connections over a particular LAN, dynamically generating certificates for the domains that are being accessed on the fly.|
|Sslsplit||Performs man-in-the-middle attacks against SSL and TLS networks. Connections are transparently intercepted through a network address translation engine and redirected to sslsplit, which terminates the original connection and initiates a new connection to the original destination while logging all the transmitted data. It supports plain TCP, SSL, HTTP/HTTPs, and IPv4 and IPv6.|
|Sslstrip||Designed to transparently hijack the HTTP traffic on a network, watch for HTTPS links, and redirect and then map these links to spoofed HTTP or HTTPS links. It also supports modes to supply a favicon that looks like a lock icon as well as selective logging of intercepted communications.|
|Sslyze||Analyses the SSL configuration of a server.|
|Tlssled||Unifies the use and output of several other SSL-specific applications, checks for encryption strength, certificate parameters, and renegotiation capabilities.|
The most commonly used are sslscan, which queries SSL services in order to determine the certificate details and the cyphers associated. The output is a text or XML formats. When a particular connection, use the –no-failed option, as in the screenshot, to have sslscan show only the accepted cypher suites.
The sslyze Python tool analyses the server’s SSL configuration and validates the certificate, tests for weak cypher suites, and identifies the configuration information that may support additional attacks.
Another SSL reconnaissance tool is tlssled.
These were some key points on Secure Socket Layer SSL reconnaissance for hunting down victim and playing with cyphers….
I hope you all enjoyed reading this article..
Let me know your Experiences in the comment section below