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.
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'
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.
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:
Only SSLv3 and TLSv1 are potentially vulnerable.
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"
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.
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
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
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.
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
Simply add the TraceEnable directive into the httpd.conf and set the value to Off.
TraceEnable Off
Restart apache.
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,
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.
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".
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
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
- SAP Managed Tags:
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
