![Are You Still Using Vulnerable Certificates on Your Network? [Are You Sure?] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F469e9c95-8555-4f24-82d2-ce9a859ae6ef%2Faid_field_img__f393b5d1a748dfb9425cb95bb31160e3.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
Insecure machine identities can wreck your world. Unfortunately, if you don’t really understand what you are doing with your keys and certificates, it is extremely easy for them to be vulnerable. But the problem is that these vulnerable certificates are like a ticking time bomb. You may never know how exposed you are until there is a problem.
That’s why Machine Identity Management is a must. With the right solution in place, you can set high standards for your machine identities and make sure that they are maintained across your entire organization. By finding and replacing any certificates that don’t meet your rigid standards for security, you can protect yourselves from a potential disaster.
We discovered a ticking time bomb
Granted, it’s not every day you come across a disaster waiting to happen, but I did the other day when I was helping a customer troubleshoot an issue with certificates on their F5 server. The customer reported that Venafi was failing to connect to an F5 server in order to manage all the virtual IPs. As we dug into it, we found some problems with the connection.
Namely, the certificates outlived their validity periods (some as long as 10 years previously!) Plus, they were still using vulnerable MD5 and SHA-1 algorithms that had been deprecated for quite a long time. While public browsers no longer accept these algorithms, many organizations still have some in their internal systems that they have overlooked, were simply never able to locate, or worse yet, did not understand.
When Venafi encountered the bad certificate it would not let admins connect to the F5 server. Venafi was not broken, it was a warning and a stop gap to keep the organization safe. “Thank you Venafi for knowing that the connection was not healthy!”
There are multiple attack vectors available with these vulnerable certificates. Issues, such as weak algorithms, make the connection vulnerable enough that you could capture the credentials being passed over the connection. We also noticed that the F5 Administrative credential was shared among all the F5 servers. This means that even the F5 servers with good machine identities are now exposed due to the server with a bad machine identity. This translates to thousands of sites that could be/could have been compromised, over the last 10+ years.
TLS Machine Identity Management for Dummies
What you can do
It is a challenge to find certain trusted roles that have relevant PKI experience and understand enough or have enough time to effectively manage your machine identities. Venafi can help here.
We’ll help you:
- Set enforced policy to issue certificates that adhere to best practices only
- Find certificate vulnerabilities so you can correct them
- Alert your security team when there is a problem with machine identities
- Create unique credentials for each F5 server so you don’t expose everything due to one bad server
The security team we worked with wanted us to force Venafi to just accept the expired MD5 certificate and they demonstrated how easy it is to click past the certificate warning box. There is a fundamental lack of understanding of the issue. So, if I was going to choose an attack vector here, I think I would just go phishing and catch plenty of Sucker fish. Instead, I recommended the following:
Remediation actions
- Stop access to these servers.
- Do targeted network discovery
- Report and Remediate vulnerabilities
- Create larger planned network discovery
- Report and Remediate
- Reform best practices and educate trusted role
Following best practices is awesome, if -
Following best practices is awesome. But if you only do the minimum, you may still face challenges that may still impact your security. Here’s an example. Even after we explained this situation and the gravity of it to the organization, they issued a new certificate and even at SHA-2 there were still problems that we needed to help educate on.
Here are issues that would still need to be addressed in the new certificates:
- Still self-signed
- Common name of LocalHost
- Validity period of 10 years
- Not protected by any company or industry policies/best practices
Do you have any vulnerable certificates in your network?
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts