- Introduction
- The purpose of digital certificates
- What is a self-signed certificate?
- What’s the impact?
- Where do we go from here?
- Conclusion
Ever since communication was invented, the need for encryption has been apparent and the solution has been sought after by all. This led many mathematicians down a path to create scalable, efficient solutions that not only encrypt communications, but creates a system that ensures integrity and confirms messages were truly sent by the person that it claims to be. While cryptography is a gigantic conversation piece that definitely deserves its own blog post, it is not our intention to get into the nitty gritty about the math behind cryptography. Instead, I’d rather talk about the fundamental purpose of digital certificates, and why IT admins seem to forget half of their purpose.
The purpose of digital certificates
Digital certificates serve two main purposes:
- Provide information about the public key so that communication can be encrypted, and only decrypted by those that hold the paired private key. In other words, it ensures others can’t see the data within your session.
- Certifies the ownership of a public key by the named subject of the certificate. In other words, it confirms that system you are communicating with is the one that you intended to.
But over time, many IT administrators seem to have forgotten about half the reason these digital certificates exist. From my time working at an MSP, to my time working as a Pentester, it is far too common to see self-signed certificates in use on important network infrastructure, including backup systems, remote desktop servers/workstations, switches, access points, camera systems, Hypervisors, and more — with many users trained to ignore certificate warnings because “that’s suppose to happen”.
What is a self-signed certificate?
Self-signed certificates have a useful purpose, which is to allow you to communicate with a device over an encrypted connection. This is obviously very important, but they lack in one critical area.
Digital certificates not only contain information about the public key used to encrypt the connection, but they also contain the digital signature of an entity that has verified the certificate’s contents (called the issuer). When a certificate is “self-signed”, that means there was no third party issuer to confirm the legitimacy of the system’s identity. This would be like a couple of police officers showing up with badges they printed themselves from Staples — It may look legitimate, but the police department (a trusted third party) didn’t actually issue those badges to verify the legitimacy of the “officers” identity.
Because of this, what would stop an attacker from pretending to be the system you meant to connect to? Sure, the communication would be encrypted, but if the attacker provides the public key used for the encryption, then they could also control the private key used to decrypt the communication. This is called a Man in The Middle attack.
What’s the impact?
When most people think of “Man in the Middle” (MitM) attacks, they usually think of connecting to insecure, public Wi-Fi networks. This is a problem.
MitM attacks are not restrained to only wireless networks, they’re prevalent in wired network environments too. The goal of these attacks can range from spying on somebody’s activity, harvesting credentials, or even redirecting the flow of traffic to a different location. All of these can have very real impacts, especially when you consider the high value of infrastructure that we commonly find using self-signed certificates.
For example, let’s talk about a technology that 2020 has us all more familiar with — the Remote Desktop Protocol (RDP). It is very common to see self-signed certificates in use when connecting to a remote computer via RDP. If you’re unsure if your computer is using a self-signed certificate, let me ask you: Does this image seem familiar?
If you answered “Yes” to that question, and if your first instinct when being displayed with this prompt is to click “Yes”, then your computer is likely using a self-signed certificate and you are vulnerable to Man in The Middle Attacks.
Seth is a tool written by Adrian Vollmer of German-based security company SySS that helps automate the process of performing RDP MitM attacks. If you’re interested in seeing just how easy it is to use this tool to perform attacks, feel free to check out my post Performing RDP Man in the Middle (MitM) Attacks Using Seth.sh to Steal Passwords.
Let me ask you another one. Are you an IT administrator that is used to seeing this when browsing to the web interface of your equipment? If the answer is “Yes”, then your equipment is likely using a self-signed certificate and you are vulnerable to Man in The Middle Attacks.
Where do we go from here?
The good news is that there are many articles online on how to replace self-signed certificates with trusted ones, which makes this problem easy to fix from a technical perspective. The bad news is fixing this problem at an organizational level may be a bit more difficult if your users are already used to blindly accepting these certificate warnings.
Once certificates are signed by a trusted authority, users will no longer be presented with these warnings as long as things are working properly. This means that in the event of a real MitM attack, users will need to be aware that these certificates errors should NOT be ignored, as it will be an indication that a real attack is underway. Should they choose to follow their untrained habit of ignoring these warnings, they will still be vulnerable to these attacks.
This is where user awareness training comes in, yet again, as a very critical piece of your security posture. If you need help getting your security awareness training programs dialed in, feel free to reach out to us at Lykosec.
The IT department must not be excluded from this training either, as they are probably the most at-risk of misunderstanding why they’re getting a certificate warning. Devices ship out of the box with self-signed certificates deployed automatically, and IT admins are very used to ignoring them when browsing the web interfaces of these devices. IT needs to not only be made aware of the impact of this problem, but also needs to understand how it works so they can determine properly when a certificate warning is safe and when it isn’t.
IT teams should make every effort to replace self-signed certificates. In an ideal scenario, equipment that ships with self-signed certificates should be prepped in an isolated subnet that no other users connect to. IT should make sure that they are the only devices connected to this subnet before accepting the certificate warning, and include replacing the self-signed certificate with a certificate signed by a trusted authority as a mandatory step before that device is put into production.
Conclusion
While self-signed certificates serve their purpose for encrypting communications, relying on them in production invites Man in the Middle attacks as users are no longer able to verify the legitimacy of the system’s identity. If you can’t confirm who you’re talking to, you don’t really know them, and as our mothers always told us, “you should never talk to strangers”.
