The Internet is built upon its ability to allow devices to communicate with each other and, even back when it was first created, Internet pioneers were thinking about the need for security and privacy. As the Internet continued to grow, the need for “secure” encrypted conversations across the Internet emerged and certain cryptographic standards were adopted and deployed throughout the web, allowing secure communications between clients and servers. Enter Secure Sockets Layer (SSL) and Transaction Layer Security (TLS) cryptographic protocols.
SSL and TLS are meant to secure communications between two devices (a client and a server). Digital certificates are intended to prove that a server really belongs to a specific entity, to ensure that a client is talking with a verified server, rather than a rogue, fraudulent domain. The SSL/TLS keys ensure that the conversations between those servers are encrypted and secured. SSL/TLS shows trusted client; certificates ensure trusted server. This all makes sense in theory, of course, but in practice, things get complicated quickly.
Attacks that take advantage of issues and misconfigurations within TLS and SSL encryption clients have been around for decades, partly due to the fact that the encryption technology itself is more than 20 years old. Adversaries exploit weaknesses in TLS and SSL because it’s low-hanging fruit — offering big rewards for very little effort or risk for the attacker(s).
The fact that everything on the Internet is connected using this old technology puts pretty much everything at risk, but some advancements have been made to ensure that we don’t have to trash the entire Internet and start over (no, this is not an option). We’ll get to security tips at the end of this article. But, first, the real-world attacks.
DROWN Attack, FREAK, Logjam, Heartbleed…ALL THE ATTACKS
Many cyberattacks we hear about these days are tied to SSL (OpenSSL, in particular), and TLS protocols, including a few very public widespread attacks in the past decade, like DROWN, FREAK, Logjam, and Heartbleed. Coincidentally, all three of these well-known attacks were analyzed and reported on at length by several of our founders. Censys’ Engineering Manager David Adrian, Chief Technologist Zakir Durumeric, and Chief Scientist J. Alex Halderman were on the research teams that were the first to report the DROWN and Logjam attacks and the first researchers to measure the impact of DROWN, Logjam, FREAK and Heartbleed attacks. These attacks were some of the first to demonstrate the value of scanning the global Internet to hunt for attacks, measure their impact, and understand how they worked.
These terrifying, logoed and branded, media-frenzied attacks had something in common, they used SSL and TLS clients to spy on data shared between the client and server(s). Attackers were able to insert probes into the SSL/TLS servers to read the connection between the client and the server. With that access, malicious actors were able to read and modify data passed through Web and email servers — for the DROWN attack alone, tens of thousands of servers were affected.
Find Unknown Vulnerable Assets Using SSL/TLS Protocol to Improve Security
Censys indexes TLS certificates associated with hosts and services and also tracks a few specific vulnerabilities, which means you can use it to find outdated, insecure devices and certificates in your organization. We’ll take you through a few of those searches, related to TLS. The biggest problem IT teams face is simply the ability to see everything that’s in use in their business, outside of the known corporate-owned devices. It’s possible you’ve got some hosts using vulnerable TLS protocol out there that can act as a way in for attackers. So let’s start by finding those.
We know that weak public key lengths are an indicator that a TLS certificate is potentially vulnerable. Perspective Risk published an in-depth article about this if you’d like to explore further. Cryptographic key sizes are a crucial factor in key security, assuming other factors are held constant (protecting the private key from unauthorized access, a good random number generator, etc).
In 2019, public key lengths are generally considered weak if they are anything below 2048 bits. That means we could focus on searching for common weak key sizes to locate hosts vulnerable to brute force attacks.
Start with the following search and replace the parsed names field (“example.com”) with your organization’s domain:
https://censys.io/ipv4/help?q=443.https.tls.certificate.parsed.subject_key_info.rsa_public_key.length%3A+%5B+0+TO+2047+%5D+AND+443.https.tls.certificate.parsed.__expanded_names%3A+example.com
This search range captures all of the public keys that are below 2048 bits and would be inherently weak from a security standpoint.
Next, find hosts vulnerable to Heartbleed
This search will show you all domains used in your organization that are vulnerable to Heartbleed. Replace “example.com” with your domain:
https://censys.io/ipv4?q=%28443.https.heartbleed.heartbleed_vulnerable%3A+true+AND+443.https.heartbleed.heartbeat_enabled%3A+true%29+AND+443.https.tls.certificate.parsed.names%3A+example.com
Old or Weak Certificates
Next, you might search for stale or expired certificates for devices you own or that are in use in your organization, using the Censys certificates data set. Censys’ tagging system makes it easy to screen for these certificates right in the results page. Here’s how you’d go about looking for those:
- Choose the “certificates” drop down next to the Censys search bar and select parsed.names: [yourdomain]
- https://censys.io/certificates?q=aol.com – replace “aol.com” with your domain
- Then from those results, filter down based on certificate trust status from the left hand margin, choosing “Untrusted” “Never Trusted” “Self-Signed” “Expired”, etc. until you’ve got your list of domains you need to explore further
TLS Configurations Using Weak Hashing Algorithms
Searching next in the IPv4 data set by selecting “IPv4” from the dropdown menu, we can look for the hashing algorithms used in the cipher suite, which also factor into TLS security. Some hashing algorithms are vulnerable to collision attacks, where the algorithm generates the same hash value for two independent inputs.
You can use Censys to find instances of TLS configurations using weak hashing algorithms with known vulnerabilities or attacks (SHA-1 and MD5, in our example):
https://censys.io/ipv4?q=443.https.tls.signature.hash_algorithm%3A+%2Fsha1%7Cmd5%2F+AND+443.https.tls.certificate.parsed.names%3A+example.com (Again, you’ll need to replace the parsed names “example.com” domain with your own to make this work).
These are just a few examples of how to find vulnerable assets you didn’t already know about through Censys, but it’s a good start. Taking care of any of those issues before they’re exploited, causing damage to your business, improves the overall security of the company and prevents trauma in the future.
A Few Tips for Better Security Hygiene and PCI Compliance
So you found some servers using outdated, vulnerable SSL/TLS used in your business, now what? First, tackle these couple of things first to prevent things like man-in-the-middle (MITM) attacks:
- Make sure you configure your servers to support the latest TLS protocol versions – 1.2 is widely supported both in servers and clients, and 1.3 has been finalized and support is emerging
- Disable TLS 1.0 if you haven’t already and ALL versions of SSL
- While we’re sure you always follow our tips, it’s worth pointing out that as of June 2018 you must have disabled support for all versions of SSL and early TLS versions in order to be PCI compliant. More details on that here
- If you found old expired certificates on devices that are still in use, ensure that you’ve begun the process of renewing those certs and added them to your asset management inventory list
