A definitive guide to digital certificates and encryption keys

Unfortunately Public Key Infrastructure is not mainstream, many seasoned CIO's, CTO's, CSO's and CISO's do not understand the critical importance and completely negative, overriding effect inadequate PKI management has on the entire security of their business and that without full PKI management, the chances of an acceptable cyber posture is all but zero.

This definitive guide is to enable the real vulnerabilities across a PKI and why, if you do not have full visibility and knowledge across the entire enterprise of your certificates and keys, you are more than likely already being breached and data is being lost and nefarious activities will, if not already, be possible.

CERTIFICATE EXPIRY / REVOKED 

REVOKED CERTS

Revoked: A certificate is irreversibly revoked if, for example, it is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, misrepresentation of software behaviour, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen). This essentially could mean you have trusted malware in your organisation and without finding the revoked certificate and the software related to it, you would not be aware of the problem as it can bypass most other security controls. 

EXPIRED CERTS

Without knowing and understanding what certificates have expired and what their usage is/was, you are completely blind to any service loss that will have experienced as a direct result. This could be anything from a customer web service, internal services such as security controls (Equifax was a classic example here and allowed months of data to be exfiltrated in it’s breach due to this), WiFi, VPN connectivity no longer working, digital signatures on emails no longer functional and much more.

 SELF SIGNED

Self-signed certificates represent an overt danger if used in production. Think about these problems in the context of a self-signed endpoint:

• No one can revoke a self-signed certificate. If you lost control of the private key, data encrypted by an attacker would forever be just as good as data encrypted by you. Data meant for you could always be signed by your public key and read by your attacker.
• Why should anyone trust a self-signed certificate, even members of your own organisation? Literally, anyone can create a certificate and stick your name on it.
• You can’t lock up the private key. You’re actively using it. And, you imported its public key on at least one other machine which now blindly trusts it. That does not qualify as “secure” in any sense of the word.
• A compromised root CA would be terrible, but tearing down the entire PKI would at least address the problem. You can use centralised tools to remove the compromised CA from Windows’ trust lists. If you manually imported a self-signed certificate, you will have to manually hunt it down.

 KEY LENGTH

The longer the key length, the harder it is to break with standard computer technology until the true arrival of Quantum Computing. So being able to understand what your algorithms are and the respective key lengths will provide an organisation with valuable information as to how easily encryption can be broken depending on the key length related to algorithm.

 ALGORITHMS

Security researchers have achieved real-world collision attacks against the SHA-1 hash function, producing two different PDF files with the same SHA-1 signature. This shows that the algorithm's use for security-sensitive functions should be discontinued, hence it is now seen as deprecated and should no longer be in use. 

SHA-1 (Secure Hash Algorithm 1) dates back to 1995 and has been known to be vulnerable to theoretical attacks since 2005. The U.S. National Institute of Standards and Technology banned the use of SHA-1 by U.S. federal agencies since 2010, and digital certificate authorities have not been allowed to issue SHA-1-signed certificates since Jan. 1, 2016.

Up to date safe algorithms should be used in place of deprecated algorithms to mitigate this risk. 

FAKE CERTIFICATES

There have been numerous articles describing a new tactic in the arms race between hackers trying to sneak malicious content past anti-malware and data exfiltration scanners and the network defenders trying to stop them. Attackers now use certificate extension types such as .PEM to embed malicious code in order to bypass other security mechanisms and can be used in multi-stage attacks to devastating effect. It’s critical that these are found quickly to mitigate the progression of the attack. 

FAKE SELF-SIGNED CERTS

Finding these types of certs should act as an IoC either internally malicious tampering or external threat actors. If you have these in your environment then it should serve as a warning that a incident response team should be made aware of. 

UNTRUSTED ROOT CA

Root certificates can be installed for purposes such as time stamping, server authentication, code-signing, and so on. If there are untrusted Root CA certificates in the trusted store, that means any future software installed with certs signed by the untrusted certs will be trusted which is completely the opposite of what should be allowed.

Having a certificate in the Trusted Root Certification Store for “All” intended purposes on a Windows system gives anyone that has the private key associated with the certificate the ability to completely own the system on which it is installed. The impact is the same as for any Certificate Authority (CA) behind certificates installed on Windows systems.

 PUBLIC / PRIVATE KEYS

To prevent key misuse such as lateral movement through a network (SSH), unapproved methods of encryption (such as PGP) for nefarious purposes such as exfiltration of sensitive data, connectivity to external networks through VPN, all keys need to be known for visibility and understanding of where keys are and who has access to them. Redundant keys need to be removed for complete hygiene and reduced risk. In addition, the key length needs to be understood to ensure it’s appropriate for it’s intended purpose and as strong as it needs to be for compliance and regulations. Any private keys associated with code-signing certificates for example, pose the risk of an attacker signing malware as the organisation it’s retrieved the key from. 

SELF SIGNED CERTIFICATES

Self-signed certificates need to be understood and monitored as this is a route for attackers and malware to create and establish encrypted tunnels to exfiltrate data in addition to the risk of finding the organisations private key on the same endpoint and being able to re-use for malicious purposes.

The NIST framework lists Step 1 as being to Identify and until now, it was virtually impossible to identify all variants of certificates and keys, as such, an enterprise could never be secure as it was only ever partially known about, managed or secure.

To get full visibility and to ensure you can at least manage your entire PKI, not just a fraction of it, contact CIP.