Skip to Content

On continuation of the TOP 10 SSL Security Vulnerability and Solution – PART 1

Vulnerability 6 – SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)

In SSLv3.0 and TLSv1.0 implementation the choice CBC mode usage was poor because the entire traffic shares one CBC session with single set of initial IVs. The rest of the IV are as mentioned above results of the encryption of the previous blocks. The subsequent IV are available to the eavesdroppers. This allows an attacker with the capability to inject arbitrary traffic into the plain-text stream to verify their guess of the plain-text preceding the injected block. If the attackers guess is correct then the output of the encryption will be the same for two blocks.

For low entropy data it is possible to guess the plain-text block with relatively few number of attempts. For example for data that has 1000 possibilities the number of attempts can be 500.

  • How to diagnose:

Using openssl connect to the server on respective port with limiting connection only to CBC mode ciphers.

If any of these tests is successful, then the target is vulnerable to BEAST attack.

CBC ciphers

RC4-SHA

ECDHE-RSA-DES-CBC3-SHA

openssl s_client -connect domain.com:POR -cipher ‘RC4-SHA:ECDHE-RSA-RC4-SHA’

  • How to resolve:

This attack was identified in 2004 and later revisions of TLS protocol contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability and setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability.

Add an entry to SSL section in httpd.conf or the SSL configuration file of the respective application listening to the vulnerable port.

SSLHonorCipherOrder On

SSLCipherSuite RC4-SHA:HIGH:!ADH

Note: RC4 recommendation is only in situations where upgrade to TLSv1.2 is not possible.

  • How to validate:

Before : On executing the command, with successful connection the output shows information of the certificate used by port.

After : On executing the command after applying the solution , with successful connection the output do not show the certificate value instead handshake failure and secure renegotiation is not supported.

Vulnerability 7 – SSL/TLS Server Factoring RSA Export Keys (FREAK) vulnerability

The remote SSL/TLS server is vulnerable to FREAK attack when:

  • The RSA+EXPORT ciphers are supported
  • The size of the RSA public key in certificate is not stronger than 1024
  • The temporary RSA key size is less than 1024
  • The temporary RSA key is stable(used multiple times)

Only SSLv3 and TLSv1 are potentially vulnerable.

  • How to diagnose:

Using openssl connect to the server on respective port with limiting connection only to cipher EXP

openssl s_client -servername domain.com -connect IPaddress:PORT -cipher “EXP”

  • How to resolve:

This vulnerability can be addressed by disable RSA_EXPORT cipher suites and do not use temporary RSA key multiple times.

Add the CIPHER text

SSLCipherSuite !EXPORT

Save the file, test the new configuration and restart the apache service.

Vulnerability 8 – SSL Server Has SSLv2 Enabled Vulnerability

SSLv2 is insecure and has been superseded by SSLv3.Essentially, there is no need to support SSLv2 anymore. Additionally, it is specifically called out as a required PCI Failing Vulnerability.

  • How to diagnose:

Using openssl connect to the server on respective port with limiting connection only to SSL v2

openssl s_client -servername domain.com -connect IPaddress:PORT -ssl2

  • How to resolve:

The solution would be to disable any SSLv2 Connections on the Server Side, and only allow secure connections such as SSLv3.

To disable SSLv2 in Apache edit the apache SSL configuration file at ‘/etc/apache2/mods-available/ssl.conf ‘or the SSL configuration file of the respective application listening to the vulnerable port.

Go to the section of SSL directives and edit the line as

SSLProtocol All -SSLv2

  • How to validate

On executing the command, with successful connection the output shows information of the certificate used by port. After disabling SSLv2 it will connect successfully and output do not show the certificate value instead handshake failure and secure renegotiation is not supported.

Vulnerability 9 – HTTP TRACE / TRACK Methods Enabled

TRACE is enabled by default in an apache installation.

  • How to diagnose:

If the web server is listening on port 80, by far the easiest way to determine whether it is vulnerable or not is using telnet.  Simply open up your telnet application and connect to your website/web server over port.

telnet <hostname> 80

Once connected, type the following:

TRACE / HTTP/1.0
Host: <Testing hostname>
TestA: Hi
TestB: Testing

Press enter twice and if trace is enabled, you should see output similar to the following, then the server is vulnerable.

HTTP/1.1 200 OK
Server: Apache
Date: Tue, 04 Aug 2009 20:17:15 GMT
Content-Type: message/http
Content-Length: 76

TRACE / Testing hostname>
TestA: Hi
TestB: Testing

  •  How to resolve:

Simply add the TraceEnable directive into the httpd.conf and set the value to Off.

TraceEnable Off

Restart apache.

  • How to validate:

Re-run the diagnose steps and should receive an HTTP 405-Method Not Allowed status code back

Before: The telnet connection will return 200 OK or 302 Found message

After: The telnet connection will return 405 Method Not Allowed message.

Vulnerability 10 – SSL Certificate Vulnerabilities

An SSL Certificate associates an entity (person, organization, host, etc.) with a Public Key. In an SSL connection, the client authenticates the remote server using the server’s Certificate and extracts the Public Key in the Certificate to establish the secure connection.

The client can trust that the Server Certificate belongs the server only if it is signed by a mutually trusted third-party Certificate Authority (CA).

Common SSL certificate vulnerabilities are,

  • SSL Certificate – Self-Signed Certificate
  • SSL Certificate – Signature Verification Failed Vulnerability
  • SSL Certificate – Subject Common Name Does Not Match Server FQDN
  • SSL Certificate – Improper Usage Vulnerability

By exploiting these vulnerabilities, an attacker can impersonate the server by presenting a fake self-signed certificate. If the client knows that the server does not have a trusted certificate, it will accept this spoofed certificate and communicate with the remote server.

If a client is unable to verify the certificate, it can abort communication or prompt the user to continue the communication without authentication.

A certificate whose Subject commonName or subjectAltName does not match the server FQDN offers only encryption without authentication.

  • How to diagnose:

Check if the SSL certificate used by port of the application is self-signed or signed by third party CAs. Verify whether the SSL certificate has the common name attribute correct that match the FQDN of the server and correct subject type is maintained in basic constraints attribute.

Check the server certificate’s Basic Constraint attribute has correct usage type as “End Entity” or “CA”.

  • How to resolve:

Self-signed certificates are created generally for testing purposes or to avoid paying third-party CAs. These should not be used on any production or critical servers.

Install a server certificate signed by a trusted third-party Certificate Authority.

Install a server certificate whose Subject commonName or subjectAltName matches the server FQDN.

Please note that a false positive reporting of this vulnerability is possible in the following case:
If the common name of the certificate uses a wildcard such as *.somedomainname.com and the reverse DNS resolution of the target IP is not configured. In this case there is no way for Qualys to associate the wildcard common name to the IP. Adding a reverse DNS lookup entry to the target IP will solve this problem.

The basicConstraints section of the certificate may specify if it is a Certificate Authority (CA) certificate.
In general, a server public key should not be used for Certificate or CRL signing, a client or CA certificate should be not used as a server certificate. Install the server certificate with correct usage.

Tips :

To identify what are the ciphers included in each categories use the command

openssl ciphers <LEVEL> -v

Level – LOW,MEDIUM,HIGH,NULL,FIPS

To identify which protocol and cipher is currently used by an open connection use the s_client to connect to the server on a respective port as below. At the end of the output it will be displayed.

echo -n | openssl s_client -connect domain.com:PORT

An ideal setup of SSL configuration for Apache Tomcat is to disable vulnerable protocols and week ciphers.

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 +TLSv1.1 +TLSv1.2

SSLHonorCipherOrder On

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DSS:RSA+AES:DH+AES:RSA+AESGCM:DH+AES256:ECDH+AES128:DH+AESGCM:ECDH+AES256:ECDH+AESGCM:!3DES

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply