Assaults on trust through the SSL/TLS-encrypted traffic are now common and growing in frequency, sophistication, and sheer brazenness. The low-risk, high-reward nature of SSL/TLS vulnerability ensures that these trends will continue, placing organizations at risk of breach, failed audits, and unplanned system downtime. The following examples describe a few of the most common techniques, the impact on businesses, and suggestions on how to prevent them.
Increasingly, malware is being designed specifically to steal SSL/TLS keys and certificates for use in communications fraud and data exfiltration. For example, Advanced Persistent Threat (APT) operators exploiting Heartbleed malware stole digital keys and certificates that resulted in a breach of 4.5 million Community Health System (CHS) patient records. The Heartbleed exploit was used against a system behind the CHS firewall to expand the attack to reach these highly regulated patient records.
Heartbleed remediation requires that all keys and certificates be replaced, not just for a system to be patched. Incomplete remediation means that business and government services can be spoofed with the trust that a valid digital certificate provides, and sensitive communications can be decrypted.
To protect against advanced persistent malware, organizations need to identify all systems using SSL/TLS, install new keys and certificates on servers, revoke vulnerable certificates, and validate new keys and certificates are installed and working.
Successful MITM attacks gain the trust of communicating parties by impersonating a trusted website and eavesdropping on secure conversations. Access to SSL/TLS keys and certificates facilitates MITM attacks, and unsecured or lightly protected wireless access points are often exploited for entry.
There are several ways a bad actor can break the trust SSL/TLS establishes and launch a MITM attack. For example, a website’s server key could be stolen, allowing the attacker to appear as the server. In some cases, the issuing Certificate Authority (CA) is compromised and the root key is stolen, so criminals can generate their own certificates signed by the stolen root key.
MITM can also result from a client’s failure to validate the certificate against trusted CAs, or when a client is compromised and a fake CA is injected into the client trusted root authority. In many MITM attacks, malware performs this action to redirect users to fake banking web sites, where sensitive information can be easily stolen.
For enterprises, MITM attacks misuse trust to steal intellectual property, sensitive personal information, and damage an organization’s reputation. For highly regulated industries like healthcare and finance, these attacks can also result in costly penalties. To remediate these exploits, organizations need to identify and revoke all certificates used on impacted servers, create new keys for certificates, and verify that new keys and certificates are being used.
Server administrators frequently create self-signed “wildcard” certificates on-demand using free, OpenSSL. While quick and easy, this practice significantly erodes trust because no trusted third-party CA ever verifies these certificates.
Using a wildcard certificate on a publically facing webserver increases the risk that cybercriminals will use the server to host malicious websites in phishing campaigns. To eliminate this problem, organizations should avoid using wildcard certificates on production systems, especially public-facing ones. Instead, use subdomain-specific certificates that are rotated often.
Maintaining the trust required for today’s global business demands a known and reputable CA that both parties can rely upon to authenticate the conversation. Over time, an enterprise might discover that it has been using certificates from dozens of unknown and untrusted CAs. For example, China’s Certificate Authority—CCNIC—was recently cited as an untrusted CA.
In 2014, an Internet security organization named Netcraft, found dozens of fake digital certificates impersonating banks, ecommerce sites, ISPs and social networks deployed across the Internet. Even well-known CAs like GoDaddy can be compromised. Fake certificates purporting to be for GoDaddy’s email service could allow an attacker to masquerade as GoDaddy if applications don’t verify a certificate’s trustworthiness.
To remediate the problem, organizations must identify and remove all certificates associated with unknown and untrusted CAs, and replace them with new certificates from trusted sources.
Cybercriminals are using encryption to attack organizations at an ever-increasing rate. SSL/TLS is being turned against enterprises to deliver malware undetected, to listen in on private conversations, to disrupt secured transactions, and to exfiltrate data over encrypted communication channels. For example, the pervasive Zeus botnet used SSL communication to upgrade the attack after the initial email infection. Following the Boston Marathon bombing, a malware attached to a spam message also used SSL to communicate with its command and control server.
With more and more encrypted traffic, this trend is likely to expand rapidly. Gartner estimates that by 2017 more than 50% of the network attacks targeting enterprises will use SSL encryption, up from less than 5% today. For organizations that lack the ability to decrypt and inspect encrypted communications to assess these threats, this blind spot undermines traditional layered defenses and increases the risk of information breach and data loss.
To mitigate the impact of attacker encrypted communications, organizations should first evaluate the security risks from uninspected encrypted network traffic and update relevant risk indicators. In addition, the must also leverage existing network security solutions to enforce the outbound web policy on SSL traffic. With policies in place, companies should establish a prioritized list of the traffic profiles they need to decrypt. They should initiate a multiyear plan to improve coverage of encrypted traffic, starting with decrypting inbound and outbound Web traffic. And quantify current encrypted traffic mix with the anticipation it will grow 10% to 20% yearly.
Expired certificates either cause unplanned system outages or open a door through which hackers can enter your network, or both. In 2013, Microsoft Azure experienced a worldwide outage due to an expired certificate. As a result, this leading cloud provider was down for hours and issued service credits. In 2014, tens of thousands of payment terminals used to process credit card payments in the U.S. stopped working because of an expired certificate.
An SSL/TLS session that uses an expired certificate should not be trusted. Accepting an expired certificate makes users vulnerable to man-in-the-middle (MITM) attacks. To remediate this issue, all expired certificates should be identified and removed from servers.