What kind of attacks does SSL prevent?

SSL & TLS are protocols that are used for the encryption of communication channels between network devices. SSL & TLS are used to bind the identities of systems, users, websites, etc., with the help of digital certificates. These digital certificates are either issued by internal trusted certificate authorities or public Certificate authorities. Internal certificates are trusted between networking devices within enterprise while public certificates are trusted by networking devices across the globe.

These certificates hold identities of end entities and contains a cryptographic key pair consisting a pair of public and private key. Public key is distributed along with the certificate whereas private keys are kept secured by the entities. A network channel is encrypted using these key pair which ensures that data communicated between these network devices are secured from tampering or altering.

However, with all these security in place there are always vulnerabilities, technology and process gaps that enable hackers to exploit and steal the data.  In this blog we are going to discuss some of the SSL/TLS challenges which are common to exploits.

SSL vs TLS

TLS (Transport Layer Security) is the successor to SSL (Secure Socket Layer) protocol for authentication and encryption. At present, TLS 1.3 is considered to be the most secure compared to it predecessors and is defined in RFC 8446.  SSL & TLS ver 1.2 are deprecated due to vulnerabilities and attacks to these protocols such as ROBOT, LogJam, & WeakHD.

These attacks have exploited the way key exchanges happen between client and server during the negotiation phase. These attacks have been mitigated with the introduction of TLS 1.2, however there are still vulnerable to downgrade attacks such as POODLE. These vulnerabilities have been mitigated in TLS 1.3 which protects the handshake during client-server negotiation.

What attacks does SSL/TLS prevent?

SSL/TLS is the defacto standard in internet/online security.  These protocols are used to encrypt data sent over the unsecured medium (the Internet) between a client machine and a server (a website hosted on a computer).  This prevents many types of attacks. Even if a hacker intercepts encrypted data, he/she can’t read it or use it for beneficial purposes without the private key used for the decryption process.

The hackers in the world continuously search for ways to break the defacto standards of internet i.e. SSl/TLS. SSL/TLS vulnerability’s highly rewarding nature makes the attackers put their best efforts forward, which places organizations at risk of breaches and unplanned system downtime. The following examples of attacks describe a few of the most common SSL/TLS exploitation techniques, their impact on businesses, and suggestions on how to prevent these attacks.

Following are the common SSL attacks explained

SSL Renegotiation Attack

SSL Renegotiation attacks aim to exploit the vulnerability discovered in the SSL renegotiation procedure, which allows an attacker to inject plaintext into the victim’s requests. Attackers who can hijack an HTTPS connection can add their own requests to the conversation between the client and server. The attacker cannot decrypt the client-server communication, so it is different from a typical man-in-the-middle attack.

To fix the renegotiation vulnerability for SSLv3, you must stop allowing renegotiation on the server side. A renegotiation indication extension, which fixes the vulnerability, was proposed for TLS that requires the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

SSL/TLS Downgrade Attacks

An SSL/TLS downgrade attack tricks a web server into negotiating connections with previous versions of TLS that have long since been abandoned as insecure. The attacker then tries to intercept and/or alter the information by exploiting flaws in the older protocol versions or cryptographic algorithms.

Following are the most infamous Downgrade attacks in the history:

• Poodle Attack

  In the POODLE (Padding Oracle on Downgraded Legacy Encryption) attack, a vulnerability (CVE-2014-3566) is exploited to eavesdrop on communications encrypted with SSLv3. In this attack, the attacker can steal confidential data such as passwords, session cookies etc, to imitate a legitimate user. The recent Acunetix 2020 Web Application Vulnerability Report shows that as many as 3.9% of web servers are still vulnerable to POODLE as they are still using SSLv3 to encrypt their communication. To fix the POODLE attack on your web server, configure the web server to support TLS 1.2 or higher protocols.

• Freak Attack

  The FREAK (Factoring RSA Export Keys) attack works by exploiting the deliberately weak export cipher suites introduced to comply with US cryptography export regulation agencies. FREAK tricks the server into using an export cipher suite that uses RSA moduli of 512 bits or less. The earliest intention was to allow the cipher suites to be broken only by the National Security Agency however, this key can be easily cracked by today’s computing power. To fix this for your website, you must disable support for any export-grade cipher suites in software using SSL/TLS.

• Logjam Attack

  The Logjam attack, discovered in May 2015, allows an attacker to intercept an HTTPS connection by downgrading the connection to 512-bit, export-grade Diffie-Hellman groups. This is similar to the FREAK attack, except that Logjam attacks the Diffie-Hellman key exchange instead of the RSA key exchange, as is the case in Freak attack. To overcome this, you must disable support for all export-grade Diffie-Hellman cipher suites on your servers. This won’t allow an attacker downgrade the connection to the 512-bit DH export key.

Drown Attacks

DROWN is a serious vulnerability that targets servers supporting contemporary SSL/TLS protocol suites by exploiting their support for obsolete and insecure protocols. This allows attackers to leverage an attack on connections using up-to-date protocols that would otherwise be secure. DROWN exploits a vulnerability in the protocols and configuration of the server, rather than any specific implementation error.

DROWN gives attackers the ability to break the encryption, and read or steal sensitive communications. To protect against DROWN attack, server owners need to ensure that their private keys are not used anywhere with server software that allows SSLv2 connections. Web servers, SMTP servers, IMAP, and POP servers are all examples that supports SSLv2 connections.

Truncation attack

A TLS truncation attack blocks a victim’s account logout requests so that the user unknowingly remains logged into a web service. When the sign out request is sent, the attacker injects an unencrypted TCP FIN message to close the connection. The server does not receive the logout request, and is unaware of the abnormal termination. To prevent this, SSLv3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Sweet32 Attack

The Sweet32 attack breaks 64-bit block ciphers used in CBC mode by exploiting a “birthday attack”. In order to execute birthday attack, the attacker uses “man-in-the-middle” attacks or injects malicious JavaScript into a web page to capture enough traffic to mount a birthday attack. To protect against Sweet32 attack, avoid the usage of legacy 64-bit block ciphers, and disable cipher suites using DES/3DES.

MITM (Man in The Middle Attack)

Man in the middle (MITM) attacks occur when a hacker is able to get unauthorized access and intercept the secure communication between the sender and the receiver.  There are many ways by which a hacker is able to perform MITM attacks, which include getting access to SSL/TLS private keys that bind the certificate authenticity and unsecured end points. In some case, poorly secured Intermediate Certificate Authority’s private keys can get compromised, leading to a much bigger impact on all the certificates issued by them.

 In some cases, MITM attacks can also happen if the end point system is vulnerable and an attacker is able to add a fake trusted Root CA certificate in the trusted root authority list.Many organizations are not able to manage certificate life cycles, leading to compromised or expired certificates not getting revoked or renewed. In such a case, there is a high possibility that an attacker will continue using such revoked certificates to establish trust with a compromised sites and be able to eavesdrop on communications on secured channels.

SSL Stripping attacks

In SSL Stripping, an attacker establishes theirself as a router and establishes HTTPS connections with Internet servers. Usually, the end-user connects with the attacker over the unsecured HTTPS connection believing it’s an authenticated router. The attacker is then able to read the communication, forward the request to the server, and pass the response back to the user. The intent of such attacks is to read data such as usernames, passwords, and any payment related data that the attacker can later exploit.

SSL Hijacking attacks

Session hijacking, also known as cookie hijacking, is the exploitation of a valid session by gaining unauthorized access to the session key/ID information. In the process, when the user tries to login to the web application, the server sets a temporary remote cookie in the client’s browser to authenticate the session. This enables the remote server to remember the client’s login status. In order to execute session hijacking, a hacker needs to know the client’s session ID information. This can be obtained in different ways, such as by tricking the user into clicking a malicious link that contains a prepared session ID.

Through both methods, the attacker can take over the targeted session by using the stolen session ID in their own browser session. Eventually, the server is tricked into thinking that the attacker’s connection is the same as the real user’s original session. To protect yourself against SSL hijacking, avoid connecting to non-secure (HTTP) urls, be careful while connecting to the public wi-fi, use secure cookie flag, use anti-malware on clients as well as server machines, and time-out inactive sessions.

SSL/TLS Vulnerability Attacks

Like we have with other protocols, SSL/TLS protocols also have their share of flaws. Below are attacks which affect SSL/TLS 1.2 and older versions.

• BEAST Attack

  BEAST (Browser Exploit Against SSL/TLS) attacks affect SSL 3.0 and TLS 1.0 by exploiting the vulnerability (CVE-2011-3389). In this attack, the attacker can exploit a vulnerability in the implementation of CBC (cipher block chaining) in TLS 1.0. This enables the attacker to decrypt the encrypted data between two users/systems by injecting the crafted packets into TLS streams using MITM techniques.

  These techniques allow the attacker to guess the initialization vector used with the injected message. They can then compare the results to the ones in the block that they want to decrypt. This attack requires access to the client’s (victim) machine browser as a prerequisite. To execute this attack successfully, the attacker might use some other attack vectors in the initial stages. To overcome this attack, use browsers that support TLS 1.1 or higher.

• CRIME Attack

  In CRIME (Compression Ratio Info Leak Made Easy) attacks, the mechanism of compression algorithms is exploited, which is covered under the vulnerability (CVE-2012-4929). In general, the compression method is included in the server hello message in response to the client hello message, to reduce the bandwidth requirement for the data exchange. To facilitate this process, the server sends the “Compression method” (DEFLATE is most commonly used) to the client, whereas the server sends the “NULL” compression method to the client if there is no compression required.

  One of the primary techniques used by compression algorithms is replacing the repeated byte sequences in the message with a pointer to the first instance of that sequence. The bigger the repeated sequences are, the higher the compression ratio. To fix this attack, use your browser to support the latest TLS protocol (TLS 1.3).

• BREACH Attack

  The BREACH (Browser Reconnaissance and Exfiltration via Compression of Hypertext) attack is aimed at exploiting the mechanism of compression used by HTTP rather than TLS, as is the case in CRIME attacks. This vulnerability is listed under the NIST NVD database as CVE-2013-3587. This vulnerability can be exploited even when the TLS compression is turned off. This is done by redirecting the client (victim) browser’s traffic to any third-party url which is TLS enabled, and monitoring the traffic between server and client using MITM attack techniques. The web servers that are using HTTP compression reflect user input/secrets in HTTP response bodies, and are prone to being vulnerable to this. To control this vulnerability, you may disable HTTP-level compression, separate secrets from user inputs, and masks secrets.

• HEARTBLEED Attack

  Heartbleed was a critical attack that uncovered the vulnerability in the heartbeat extension of the openssl library, and is listed under the NIST NVD database as CVE-2014-0160. The heartbeat extension is used to keep a connection alive as long as both parties are still there.

  Let’s understand the Heartbleed functionality in openssl library. The client sends the heartbeat message with the data and size to the server. The server then responds back with the client’s data received and size data. The Heartbleed vulnerability was aimed to exploit the fact that if the client sends a fake data length to the server, then the server would respond back with some random data from its memory to meet the length requirement specified by the client.

  The random unencrypted data from the server’s memory may contain critical information, such as private keys, credit card details, and other sensitive information. To fix the Heartbleed vulnerability, either upgrade to the latest version of openssl library or recompile the installed version with the flag “DOPENSSL_NO_HEARTBEATS”.

How to protect from SSL Attacks?

As explained in the above sections regarding some of the common SSL attacks, it is important that organizations review their security policies related to SSL protection.  Just by implementing SSL or TLS does not ensure the security of your infrastructure and business. It must, instead, be managed with the right policies, processes, & procedures to minimize risks. In addition, there are multiple techniques and tools available in the market in order to secure your enterprise. The selection of those tools/security products, however, is a function of the nature and security goals of your enterprise and should be decided after thoroughly investigating every aspect of security.

Common causes of attacks in an enterprise network

Avoid Self-signed certificates

Many times, systems are configured to use self-signed certificates that are not signed or issued by an authorized and trusted Certificate Authority. Such self-signed certificates do not have the valid credentials or information of the certificate issuer. They might also be using weak & deprecated algorithms such, as SHA1 or RSA algorithms, with weak key strengths.  Such servers are easy to exploit for attacks, and a malicious user may be able to host malicious code on such. Self-signed certificates should only be used for testing and never in production systems. Also, a server should never trust self-signed certificates.

Avoid Wildcard Certificates

Usage of a wildcard certificate on a public facing webserver increases the risks to an organization that hackers will use the server to host malicious websites in various malicious campaigns. To overcome this issue, organizations should avoid using wildcard certificates on production systems, especially public-facing ones. Instead, use specific certificates for each domain and sub-domain.

Avoid unknown Certificate Authorities

To maintain trust between both the parties depends upon the trustworthiness of a CA. In the real world, lots of customers might rely on CAs which are unknown and not popular in the market because they provide cheaper solution. This may cost them (customers) in the long run as attackers might compromise those CAs and impersonate the legitimate CA to steal lots of critical information. To protect from this, organizations should identify all the CAs and certificates from unknown and untrusted sources, and discard or replace them with CAs and certificates from trusted sources.

Attacker using encrypted communication

In the current world, attackers use encryption as a tool against organizations. More and more cybercriminals are using SSL/TLS encrypted communication to implant malwares in enterprise networks and systems. As this trend is gaining momentum, one of the Gartner reports says that 50% of network attacks targeting enterprises will use encryption.

This will become a cumbersome job for the enterprises to inspect and decrypt this kind of traffic, specifically when they don’t have the ability to do so. To overcome this, organizations should leverage network security solutions to impose outbound web policies on SSL traffic. They also should carefully distinguish between which encrypted traffic profiles should be considered for decryption in both the inbound and outbound direction.

Avoid using expired SSL/TLS Certificates

Expired SSl/TLS certificates are the most common cause of service outages across the globe. Microsoft encountered an infamous service outage in their Azure service and had to give service credits to their customers, causing them huge losses. Expired certificates also cause organizations to be vulnerable to MITM (Man-in-the-Middle) attacks, as attackers can easily take advantage of expired certificates.

To protect your organization from this, all expired certificates should be immediately taken out of the system and replaced with active/valid certificates.

Avoid Phishing Attacks

Phishing attacks aim to exploit the human emotions vulnerability to trick them and provide sensitive/personal information to attackers. When users get a link in a form such as html to provide some personal information about themselves, they should note whether the link is secured or unsecured. A secured link has “https” in the address bar, whereas unsecure link have “http” only.

To protect yourself from these kind of phishing attacks, SSL/TLS gives you a warning message if the html page you are trying to access is unsecured. Also, if you are leaving a secured page and going to an unsecured page, SSL/TLS still gives you a warning. As a best practice, users should always use authentic urls/websites to avoid phishing attacks.

Use Strict SSL

In Strict SSL, also known as full SSL, additional validation as to the identity of the origin server is performed in order to prevent active snooping and modification of your traffic on the Internet.  In the real world, SSL/TLS encrypts the communication between the client and website/ server. However, MITM attacks trick users/clients into interacting with the fake counterpart of the legitimate website/server unknowingly. That’s where the Strict SSL comes into the picture. SSL enforces the client’s browser to check the authentication certificate of any website to make sure if it has a valid certificate. MITM attacks cannot alter the authentication certificates, hence the purpose of full SSL is served.

How can Encryption Consulting help?

Encryption Consulting provides a specialized Certificate Lifecycle management solution CertSecure Manager. From discovery and inventory to issuance, deployment, renewal, revocation, and reporting. CertSecure provides an all-encompassing solution. Intelligent report generation, alerting, automation, automatic deployment onto servers, and certificate enrollment add layers of sophistication, making it a versatile and intelligent asset.