Weak Cryptography Search Leads to Unexpected Discoveries with Reveal(x)

Best practice dictates "data is encrypted in transit". To do this, modern networks use various implementations of SSL, or secure sockets layer. Unfortunately, managing SSL certificates is hard, unappealing work—and it's double-plus-extra-hard in a large environment.

How hard? Real hard.

When Microsoft deprecated support for 1024-bit certificates, they recommended a four-step process, per machine, to assist in tracking down 1024-bit certificates:

1. Add two entries to the registry in the HKLM hive.
2. Wait a bit because the change is "going forward" and there's no looking back in time.
3. After waiting, enable CAPI2 logging in the Event Viewer.
4. Sift through the logs looking for the publicKeyLength field.

In a large environment, it's absolutely not scalable. (I think the registry key was YGBKM but I might be wrong.)

And, of course, these steps only worked for certain versions of Windows. Linux systems and older Windows machines—not to mention IoT devices and machines connected to your network you don't know about—are cut out, and that creates a major risk.

The Easy Way to Track Weak-Sauce Cryptography

Recently, I was working with a large organization and we used ExtraHop to quickly hunt down weak cryptography. We found the weak ciphers easy enough, and there was a super fun bonus surprise in store.

We'll get to the surprise—but first, here's just how easy it was:

Our first step is to navigate to the SSL server activity page.

From there, we open "top versions," click TLS1.0, and then select Records.

Note: We start with TLS 1.0 because (along with TLS 1.1) because it's been deprecated since 2018. If you want to learn about weak ciphers, why they're bad, and how to look for them, check out our free cryptography course.

This step gives us a view to look back in time, filter for specific certificates, look for certificates issued by my certificate authorities, or group by certificate key size.

In this case, there was one 1024-bit key we needed to worry about.

By using Reveal(x), we got to avoid all the typical, tedious processes: We didn't need to fiddle with the registry, and we didn't need to use Event Viewer.

Reaching the Logical (and Suspicious) End

Seeing the 1024-bit certificate raised a few questions. We needed to find out who issued it; what certificate it was. Is the certificate something the company controls, or is it a 3rd-party or supplier problem?

We mouse over 1024 and the field highlights, which means I can click and add a filter.

I want to focus on 1024-bit certificates so I set a filter on =.

This filter gives us everything we need, including some other juicy data points.

Notice the red line and the red camera in the screenshot below? We'll get back to that. But first, let's break down what each item indicates.

• Time: A timestamp of the transaction down to the millisecond, which is helpful for correlation with other tools.
• Client / Client IP Address: Shows who initiated the SSL conversation
• Client Port: Helpful when lazy bad guys forge transactions and reuse the same client port.
• Server / Server IP Address: Shows who received the SSL conversation.
• Server Port: Helpful when you have multiple listeners on one machine or when the server port dictates the service type (prod, test, user acceptance testing, etc.).
• Host / SNI: Useful when we are using wildcard certificates.
• Fingerprint: The cryptographic ID of the key in use.
• Key Size: Key strength, and 1024 is considered weak sauce these days.
• Subject: The common name of the SSL certificate.
• Not After: The SSL certificate's expiration date.
• Signature Algorithm: How the server certificate was signed.
• Cipher Suite: The cryptography that was used when setting up this single session.
• Handshake Time: The time to establish SSL, from clientHello to changeCipherSpec (dead sexy when troubleshooting SSL slowness).
• Version: SSL protocol version (TLS1.0 is deprecated—don't use it).
• Issuer: Shows who issued this particular SSL key.
• Weak Cipher Suite: Determines whether this cipher is considered weak.
• Not Before: Indicates when this key was issued.
• JA3 Hash: Client side fingerprinting, really clever and really helpful for finding specific client implementations.
• JA3S Hash: Server-side fingerprinting, again, clever and helpful.
• Serial: The serial number assigned to the certificate by the certificate authority.

Recall the red underline under the client address and the presence of the red security camera icon? That's some fun bonus information that tells me we have a suspicious IP.

I mouse over the client IP address and click on the red line:

We entered into this investigation wanting to find 1024 bit certificates, and with this information, our humble "find the weak cryptography" investigation has moved a few notches up the urgency scale. External actors are poking and probing the environment, meaning this needed to be fixed sooner rather than later.

As we've seen above, ExtraHop automatically extracts and stores troves of information that can help you find expired certificates (Certificate Not After), hunt for weak cryptography (Cipher Suite and Version), investigate self-signed certificates (Issuer), and track specific client implementations or see who else is in your environment is using a command and control node (JA3 Hash).

Orange You Glad It's Easy

My kids are gearing up for back to school, and that brings to mind an appropriate analogy with school supplies.

Why waste your time with the box of 8 crayons (registry, modification, windows event viewer, and logs) when you can use the box of 64 (ExtraHop)? And, that 64-crayon box has a super cool sharpener in the back—making a day's work much more efficient.