Cryptographic protocols are crucial elements of communication networks since they enable machines to communicate privately by establishing secure connections. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are used to encrypt network connections today, enabling data privacy and integrity by ensuring data in transit is difficult to read. However, just like any form of technology, these protocols have their flaws and vulnerabilities.
SSL security misconfiguration is one of the most commonly exploited aspects of a tech stack. This led to the earlier versions of SSL being deprecated since there were known security misconfiguration vulnerabilities that could become targets for threat vectors.
On similar lines, there are known vulnerabilities in wider versions of TLS protocols that result in getting exploited by malicious attackers.
This article delves into the criticality of SSL and TLS security misconfiguration, common attack approaches, and the essential steps to mitigate them.
TLS and SSL Security Misconfigurations
Most TLS and SSL security misconfigurations occur on account of the lack of security best practices when setting up security measures for application servers. This allows threat vectors to identify weak points and gain access to system data or target core components of the tech stack.
Combined with this is the scenario where the growth of applications’ complexity, and security misconfigurations become harder to pinpoint, allowing hackers to escalate attacks without being traced.
This section delves into some of the commonly known misconfigurations, their common causes, and the approaches to mitigate such risks.
Common Mistakes that Cause Security Misconfiguration
TLS/SSL misconfigurations are a hacker’s typical targets since they are known and easily detected. Since security teams require time to track vectors in complex communication systems, attack vectors often have the required time to exploit such vulnerabilities using privilege escalation.
Such misconfigurations are most often caused by unintentional mistakes while configuring a tech stack. Some of these mistakes include:
Retaining Default Accounts and Passwords
Every software program or device comes with a set of default credentials for initial access that requires authentication. Attackers use many methods, including brute-force attacks, to access such programs/devices using vulnerable account credentials and then escalate privileges to gain further ground into the tech stack.
As part of a regular security exercise, these credentials are recommended to be changed immediately after initial access, retired after prolonged lack of use, and frequently changed to avoid misuse.
Revealing Too Much Information on Error Messages
Some web servers have default configurations that include verbose error messages that reveal sensitive system data. This information, such as detailed stack traces, can be exploited by attackers looking for root-level system access.
Hackers also hunt for specific vulnerabilities based on component versions and software dependencies that enable vertical and horizontal escalations to gain unauthorized access within an entire application system.
Keeping Unnecessary Features Active
Having unnecessary components, features, and code samples active is prone to an application vulnerability. Some features that must be checked when assessing for vulnerabilities include:
- Unnecessary Open Ports
- Unused but Running Services
- Accessible Leftover Pages
- Unused Accounts
Enabling Debugging in Production Environments
Most software teams isolate their production and development environment(s), allowing developers to test features before they go live. Production instances that allow debugging are susceptible to attacks, which could lead an attacker to access sensitive information, including source code or sensitive customer information.
As a best practice, debugging should only be enabled in the development clusters to help refine the software by analyzing helpful insights based on usage and traffic.
Other common mistakes that software organizations should look out for include:
- Accessible, unprotected files & directories
- Improper configuration of cloud systems
- Old or outdated software versions
Threat vectors take advantage of these mistakes to target system security vulnerabilities. In the section to follow, we discuss some of the well-known TLS/SSL security misconfigurations and their prevention strategies.
Prevention Guide
Security Misconfiguration Prevention Guide
Learn how to detect and prevent security misconfigurations.
Common TLS/SSL Misconfiguration Attacks and Prevention
POODLE
The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack takes advantage of servers that still use SSL 3.0 encryption. This protocol allows for compatibility with legacy systems and exposes the system to a block-padding-related vulnerability.
Attackers use this vulnerability to initiate a Man-in-the-Middle attack by pretending to be a web server until the client agrees to use an SSL 3.0 encryption to connect with them. The attacker then retrieves their desired information using automated tools that modify padding blocks and wait for the server’s response.
Some practices to prevent POODLE attacks include:
- Completely disabling SSL 3.0
- Upgrading the client to the latest version
- Enabling TLS_FALLBACK_SCSV
BEAST
The Browser Exploit Against TLS/SSL (BEAST) attack allows hackers to decrypt secure data by exploiting a vulnerability in Cypher Block Chaining mode in TLS 1.0. An attack orchestrates a man-in-the-middle attack to inject packets into the SSL stream, then compares this message with the encrypted message to guess an initialization vector.
BEAST attacks can be prevented by using TLS versions 1.1 and above.
CRIME
Attackers can use the Compression Ratio Info-leak Made Easy (CRIME) attack to reconstruct cookie values using feedback from the web server, allowing them to capture encrypted messages. This is achieved by replacing byte sequences in a compression algorithm. CRIME attacks can be prevented by using the latest browser versions.
BREACH
Hackers commonly use Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH attack) to target HTTP compression. In this, the attacker uses a man-in-the-middle attack to connect the client’s browser to a third-party website with TLS enabled. This way, they can continuously monitor traffic between the web server and client browsers. Some ways to prevent BREACH attacks include:
- Disabling HTTP compression
- Enforcing HTTP Strict Transport Security (HSTS)
- Enabling Secure Channels for TLS (DNSSEC)
- Separating User input from Secrets
Heartbleed
The OpenSSL library provides a heartbeat extension to keep a connection alive so long as the communicating parties exist. Heartbleed is a misconfiguration of this extension that would leak unencrypted data from the server memory. Attackers can achieve this by sending false data lengths through the client, and the server responds by sending the data received by the client or some random data from its memory that meets the length specified by the client. Heartbleed attacks can be prevented by using an updated version of OpenSSL.
SSL/TLS Renegotiation
Renegotiation allows two parties to begin a new handshake inside an existing negotiation to request new cryptographic keys or cipher suites. Hackers can utilize the renegotiation process to initiate Distributed Denial of Service (DDoS)attacks by requesting numerous simultaneous handshakes. This causes a Denial of Service on the application server’s interface. Renegotiation can be prevented by using the latest TLS version and ensuring Secure Renegotiation.
Other common misconfigurations that can be exploited include:
CCS Injections – Attackers use malicious hosts to intercept and decrypt secured data by forcing the client to use weak SSL keys
Ticketbleed – Where the TLS stack invalidates encryption by exposing various bytes of the request to the attacker
SSL Drown – Attackers leverage weakened encryption to expose session keys for captured handshakes
SSL Robot – Allows attackers to break encryption confidentiality by infiltrating certain implementations of cipher suites
Scan for SSL/TLS misconfiguration vulnerabilities, like security headers, TLS Key Size, and more, and mitigation approaches here.
How to Avoid Security Misconfiguration
Security Misconfiguration led attacks can take advantage of both general lack of knowledge and human error. By knowing the common mistakes and vulnerabilities that attackers use, software organizations can implement avoidance and preventive measures.
Following are some common best practices and specific mitigations to avoid TLS and SSL common security misconfigurations:
Best Practices to Prevent Security Misconfiguration
- Remove unused features – Besides bogging down the system, unused features make an application susceptible to attacks. It is best only to enable features as needed.
- Perform regular updates – Using the most updated version of software helps to protect devices and applications from malware that the security team may not have identified
- Automate vulnerability scanning – Take advantage of automation tools and software to search for unnecessary features, unused default accounts, and misconfigurations
- Disable debugging in Production environments – The configuration of all debugging features on Prod instances should be disabled unless they are needed in exceptional circumstances
- Deactivate the listing of directories – Ensure that all files and folders have the proper permissions, then restrict access so users can only view the files for which they have the permissions
- Limit accounts with administrative rights – By default, admin rights should be disabled for every user and only changed when deemed necessary. This policy should be reviewed frequently, keeping in line with the least privileges.
Some of the more common ways that servers get compromised include:
- Using self-signed certificates
- Not checking the validity of certificates
- Using outdated versions of OpenSSL
- Using default settings
- Setting up incorrect trust chains
- Incorrectly configured TLS/SSL configuration
Specific Mitigations for Misconfiguration
While misconfigurations are easy to detect and exploit, most are also well known and documented in the repository of standards-based vulnerability management data. The database also includes mitigations for various misconfiguration exploits. Some of these include:
- Hardening TLS Session Resumption
- Enabling Perfect Forward Secrecy
- Configuring the SSL Cipher Order
- Using Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP)
- Enabling Missing SSL Certificate Authority Authorization (CAA) Records
How do I know if my application has these vulnerabilities?
You could run vulnerability scans like this SSL / TLS Scanner to ensure that your application does not contain these vulnerabilities. For example, Crashtest Security Suite offers an automated vulnerability scanning solution that tests for susceptible entry points and misconfigured protocols within an application workflow.
It’s important to understand that with the pragmatic use of various best practices and tools, organizations can prepare and prevent privilege escalation attacks.
Summary
Misconfigurations allow attackers access to personal data, with over 70% of compromised cloud data in 2017 resulting from open security vulnerabilities. In addition, Gartner predicts that through 2025, 99% of cloud security failures will be the customer’s fault. This exposes the criticality of improperly configured SSL/TLS security and highlights that most security attacks are avoidable.
With the pragmatic use of various best practices and tools, organizations can prepare and prevent privilege escalation attacks. For example, Crashtest Security Suite offers an automated vulnerability scanning solution that tests for susceptible entry points and misconfigured protocols within an application workflow.
To know more about how Crashtest Security can perform a comprehensive scan and protect your tech stack from malicious attacks, just sign up and take it for a spin. It is free at full capability for a 14-day trial, and no credit card is required.
