As a result of my PowerShell series ,,, where I used the handling of certificates as an example, mainly because I wanted a method to keep track easier of which certificates were being added by malware, I’ve have received some questions about how security certificates work and how they stopped our software from working.
First, it helps to take a look at your own certificates. Go ahead and open the Microsoft Certificates Management Console. You can do this by typing certmgr.msc in the search field of your start button. You will have to do this as an administrator of the system.
You should see an overview of your certificates divided up into categories. The most used and usually the most important categories are Trusted Root Certification Authorities and Untrusted Certificates.
What are these certificates?
Root certificates are a method to prove that a communication you are receiving (from a website, by mail, or otherwise) comes from the source that it claims to be. This is done by public key encryption to establish a trust between the holders of the public and the private keys. But since it would be impossible to store certificates for every site we’ve ever visited or wish to visit, the system of certificate authorities (CA) was set up. To establish trust that a certificate is genuine, it is digitally signed by a root certificate belonging to a trusted certificate authority. Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify that they have been issued and signed.
You may have seen prompts warning you about a website’s security certificate, or as in the example below, a mismatch between the certificate and the name of the site:
The image shows which checks have been made before allowing a free exchange of information:
- Can we trust the source of the certificate?
- Is the certificate still valid? They all have a starting and an expiration date.
- Is the name valid, and does the name on the certificate match the name on the site’s certificate?
- Is the signature strong enough?
Another important check needs to be done, however. Has the certificate been revoked? Sometimes the CA revoke certificates, mainly because the certificate, or the private key, has been stolen or compromised. This check is made against the Certificate Revocation List (CRL), which is a system that unfortunately has some flaws, meaning sometimes the check is not completed.
As we have seen in the past, certain types of malware place certificates in the Untrusted category, which basically disables users from downloading and using security software to remove the malware. Below you can see that the Malwarebytes certificate was placed in the Untrusted category by the Wdfload malware.
This certificate, however, has nothing to do with our website. Instead, it’s associated with our software. With the certificate above in the Untrusted category, this is what you will see if you try to run our software.
Even though the CA (DigiCert) did not revoke our certificate and can still be found under our Trusted Root Certification Authorities, the Malwarebytes certificate was listed as revoked by the malware. We have to remove the certificate shown above from the Untrusted category before we can use the software again.
So there you have it: a brief explanation of how security certificates work and how malware can abuse the certificates system to block you from downloading and/or running your favorite software.
This is a Security Bloggers Network syndicated blog post authored by Pieter Arntz. Read the original post at: Malwarebytes Labs