Table of Contents
A few moons back, I found myself wrestling with an interesting case that gave me a fresh lesson on SSL and security providers. The customer I was working with had a vulnerability scanner (Rapid7, in this case) that flagged their server as vulnerable to Sweet32. If you’ve ever had to deal with vulnerability scans, this might sound familiar!
Let me walk you through the scenario, the fix, and the curveball that a thrid party process threw at us.
The Vulnerability Report
Our story begins with a standard security scan, which operates by sending multiple “client hello” messages to the server with different cipher suites. The server responds with a “server hello” for every cipher it accepts—secure or not. The scanner then flags anything it sees as insecure. Enter Sweet32.
What is Sweet32?
Sweet32, or the birthday attack, targets encryption algorithms like 3DES or Blowfish that use 64-bit block sizes. It’s kind of like having a lock on your door, but after enough time, the key pattern starts repeating itself. When a cipher’s encrypted blocks start repeating, an attacker can piece together sensitive data. In high-traffic environments, this is a big no-no. For modern security, we need to switch to stronger encryption algorithms like AES that use larger block sizes and avoid this vulnerability.
The First Fix: Disable 3DES Cipher Suite
The customer’s server was flagged for accepting the 3DES cipher, a known weak link in the encryption chain. So, the first logical step was to configure the server to stop allowing this cipher by tweaking both local and Group Policy-controlled registry settings.
We tweaked the following registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\0010002HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\0010002
The server was rebooted, and we expected the issue to be resolved. But, spoiler alert—it wasn’t.
The Mystery Continues: False Positive or Missed Configuration?
After the reboot, the vulnerability scan still flagged the 3DES cipher as enabled. We thought, “Okay, it must be a false positive.” But network traces said otherwise. Despite our changes, the handshake process was still completing using the 3DES cipher.
So, we went back to square one—double-checking policies, reviewing registries, running the scan again. Everything seemed in place for the cipher to be disabled. Yet the vulnerability persisted.
The Sherlock Moment: Different Port, Different Story
Eventually, we started noticing a pattern. While port 443 (used for HTTPS connections) rejected the 3DES cipher as expected, port 5989—now that was a different story. The cipher was still being accepted there!
A quick internet search didn’t turn up anything definitive about port 5989, but we were determined to solve the mystery. So, we took a deeper dive using the trusty Netstat -anob and Tasklist commands. And guess what? We found the culprit: WMIServer.exe, owned by HPE at the time.
The Real Lesson: More Than Just Schannel
Here’s the big takeaway: Windows servers can have more SSL credential providers than just Schannel. In this case, WMIServer.exe was accepting the weak 3DES cipher, and it had its own SSL settings independent of Schannel.
So, when you’re dealing with SSL vulnerability scans like those from Nessus, QualysGuard, or OpenVAS, don’t forget to check all the SSL credential providers, not just Schannel. There might be other services on your server accepting those insecure ciphers without you even realizing it.
How to Identify the Process Listening on a Port
In case you ever find yourself in this situation, here’s a quick guide:
- Collect a Wireshark Network trace while you are running the scanner
- After the scanner report is done, start analyzing the network trace, you can use the filter “tls.handshake.type == 2” to show server hello only packets
- Expand the transport layer security and find the cipher suite included, look for any that you would like to eliminate
- Take note of the port in your local server, that port number is being used by a process that is accepting the vulnerable connection
- Run
netstat -anobto see all active connections, the associated process IDs, and the listening ports. - Use
tasklistto match the process ID to the name of the running process. - Optionally, use Process Monitor (ProcMon) or Windows Performance Recorder (WPR) with Windows Performance Analizer (WPA) to get the name of the company that owns the process (but usually you don’t need to go this far).
Conclusion & Call to Action
The moral of the story? Never assume Schannel is the only SSL provider at play. Windows can have more lurking in the background, especially with third-party software involved.
If you’re facing a similar vulnerability scan issue and are banging your head trying to figure out why your configurations aren’t sticking, consider checking for other SSL providers on your system. The solution might be right there in front of you!
Have you encountered something similar with SSL configurations or vulnerability scans? Drop your thoughts in the comments, and let’s discuss!
Leave a Reply