In this blog we shall reveal the uses for certificates, uncover how to combat abused certificates and dig deep into an example of how malicious software can be digitally signed to pass certification verification.
What is a certificate?
In cryptography, a public key certificate, also known as a digital certificate, is an electronic document that uses a digital signature to bind a public key with an identity — information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. The certificate authority, or certification authority (CA), is the entity that issues digital certificates. In the model of trust relationships, a CA is a trusted third party that is trusted by both the subject of the certificate and the party relying upon the certificate.
What is a CRL file?
CRL stands for certificate revocation list: it is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked, and therefore entities presenting those certificates should no longer be trusted. The CRL file is itself signed by the CA to prevent tampering. The CRL is always issued by the CA that issues the corresponding certificates.
An alternative to using CRLs is the certificate validation protocol known as Online Certificate Status Protocol (OCSP). In the OCSP method, the browser contacts a web service running at the specified URL and asks the service whether a specific certificate has been revoked; again, the response is signed to prevent tampering. OCSP has the primary benefit of requiring less network bandwidth, enabling real-time and near real-time status checks for high volume or high value operations.
There is another way called OCSP Stapling, which allows the secure server to cryptographically prove that it has a recent “This certificate is valid” ticket signed by the CA. These tickets have a short lifetime and must be renewed by the server in order to return the ticket to clients in a TLS handshake. OSCP Stapling is the fastest and most private method of revocation checking, but it’s not yet deployed on most sites.
When do we use these CRL files?
When we deal with certificates, we use a CRL file. For example, when a browser accesses an HTTPS URL, it verifies the server’s certificate. During the verification process, the browser will choose a way to check for revocation; if a CRL is chosen, it will download the CRL file from an URL specified by the certificate, and do further verification. If a CA indicates that a server’s HTTPS certificate was revoked, the user is blocked from navigating to a site. A similar process happens when you use Microsoft’s “User Account Control (UAC)” security feature: when you download a signed file from the internet and want to run it, Windows automatically verifies the file’s digital signature, and during this process, a CRL is also downloaded and checked. If a CA indicates that a downloaded binary’s signing certificate was revoked, the program will fail the Authenticode check and will not run.
The CRL mechanism is very important, and here is an example. In mid-March 2001, VeriSign issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation". The ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run. To tackle this issue, Microsoft released a security patch containing a CRL file for the two certificates. You can find details here: Microsoft Security Bulletin MS01-017 : Erroneous VeriSign-Issued Digital Certificates.
Let's Dig Into An Example
Here is another example that demonstrates how important it is to revoke certificates.
On May 22, Websense® Security Labs™ discovered a typosquatting case for youtube, using the following URLs:
youtibe.com
yougube.com
youtuhe.com
wwww.youutbe.com
yootube.es
owww.outube.com
www.youtuber.ca
youutube.ca
www.youutube.ca
Some of these URLs led to a drive-by file downloading: the file was disguised as FlashPlayer.exe and lured users to download and install it.
This malware is basically a downloader for many unwanted files from the internet, for example, “DriverPro” “OptimizerPro” “SpeedUpMyPc”, all of which are rogue software. It also downloads and installs the “WhiteSmoke” toolbar for Chrome and Firefox browsers.
What is interesting is that this malware is digitally signed, and could pass certificate verification.
We could see that the certificate is owned by “TUGUU SL”, the serial number of its certificate is “27 76 b2 57 97 9f 9a”, and we could download a CRL file from http://crl.godaddy.com/gds5-16.crl.
After we download the CRL file, we find there are 3447 records of revoked certificates; after parsing, CRL file looks like this:
Among the 3447 records of revoked certificates, we don’t find the serial number of this certificate. Of course this certificate is not included, as otherwise, it cannot pass Windows’ verification process. For this case, either the private key of “TUGUU SL” has been stolen by attackers, or “TUGUU SL” itself is distributing malware for profit. This certificate was issued on May 4, it was used to sign the malware on May 21, and was caught by Websense on May 22. According to our observations, at the time of publishing it has still not been revoked.
Thanks to Websense ThreatSeeker® Intelligence Cloud we have successfully collected some CRL file data. CRLs are accessed about 200,000 times per day within Websense ThreatSeeker Intelligence Cloud: we managed to gather about 10,000 access records in the course of one hour, and then we dug into those CRL URLs and files and found something interesting. All the following data in this blog is based on these 10,000 sample data records.
There are in total 9066 URLs which requested a CRL file. Among those 9066 requests there are 819 unique URLs, which means that some CRL URLs are requested many times. Let us see which URLs are the most popular:
The data shows that http://crl.globalsign.net/Root.crl is the most popular URL during that hour, which demonstrates that the most certificates verified at that time were issued by “Globalsign”. This is probably because this is the root CA of “Globalsign”, and it writes this URL as the certificate distribution point (CDP) for each certificate issued.
From those 819 unique URLs, we managed to download 511 CRL files.It is not a surprise that some of the URLs are just not responding. First, let us look at the size of these CRL files:
The minimum file size among these 511 files is 236 bytes, while the maximum file size is, amazingly, 26.8 MB (28,198,759 bytes). Among these 511 CRL files, 200 files are below 1000 bytes, which shows that most CRL file are small in size.
Remember a CRL file is used to contain revoked certificates, so let us check how many certificate records these CRL files have:
Surprisingly, the biggest CRL file contains 687762 records, while 107 files do not have even one record. In total, these 511 files contain 2232845 revoked certificate records, which means over 2 million files are listed as being “untrusted”.
Each CRL file is issued by one CA server, and one CA server can issue as many CRLs as it likes. When we check all of those CRL files, we find some of them are issued by the same CA: below is some statistical data about which CA issued the most CRL files:
The top 3 issuers are GoDaddy, Digicert, and Starfield. GoDaddy issued 86 of the 511 CRL files.
Each CRL file should choose its own algorithm for hash and encryption. In reality, the most popular used is “sha1WithRSAencryption”, which means use “sha1” as the hashing algorithm, and use “RSA” as the encryption algorithm. But other algorithms are used too, as shown here:
We can see that “sha1WithRSAEncryption” is the predominant signature algorithm currently used. Though “sha256” and “sha512” are perhaps more secure, sha1 is just safe enough.
Each CRL file contains a list of serial numbers for revoked certificates, which is like a blacklist for certificates. There is no standard specification for how to represent these serial numbers; it is up to the CA server, so different CAs use different lengths for this field.
Some CAs use 1 byte for the serial number, while others use 26 bytes to represent this field, but we could tell from the chart that 8 bytes is the most preferred length and 16 bytes is also a popular choice. When developing tools for parsing CRL files, in order to avoid mistakes we should keep in mind that the serial number could be any length. In fact, when parsing data using OpenSSL, we identified a bug in the “openssl crl” tool:
Windows can successfully parse the special CRL file “MicrosoftRootAuthority.crl” and display the correct result of revoked certificates’ serial numbers; however, when OpenSSL parses this file it shows negative serial numbers, which is not correct.
Certificates are revoked for many reasons, for example, a certificate's private key is compromised, the CA server is compromised, etc. There is a detailed list of revocation reasons at RFC 5280. Among all 2232845 records of certificate serial numbers, there are 1606045 records which specified a revocation reason:
From this data, we saw some interesting findings. “Key Compromise” is the top reason for revocation, taking up 44% of all revoked certificates which reminds all certificate holding companies that stolen keys is quite a serious problem and they should take care of their private keys. There are 61 records for “CA Compromise”, which reminds us of the security of CA servers: in 2011, the SSL CA Comodo was breached, in an exploit originally identified as a nation state attack sponsored by the government of Iran. The SSL CA DigiNotar was also breached in 2011 in an exploit that enabled attackers to issue fraudulent certificates for Google.com. Earlier this year, the SSL CA TURKTRUST also issued illegitimate SSL certificates for Google.com.
Each revoked certificate record specifies the revocation date. By profiling this data, we could discover the trend of certificate revocation problem, and make some predictions about certificate security issues. Let us take a look at the following chart, which demonstrates the number of revoked certificates for each year.
The earliest record of certificate revocation happens in 2000, and the number of revoked certificates grows every year, reaching 1045518 in 2012. During the first 5 months of 2013, the number is 766451, and we can guess by the end of 2013, the number will easily exceed 2012’s. From this data we can tell that more certificates get revoked each year, and we can make a guess that this number will keep growing in the next few years.
It is no doubt that revocation checking is very important for certificate verification, but many certificate verification tools do not check it at all during the verification process. Here are some interesting facts about certificate revocation checking:
1. Internet Explorer on Windows XP does not offer support for OCSP, thus Internet Explorer only supports OCSP on Windows Vista and later.
2. Internet Explorer on Windows XP does not check certificate revocation for web servers by default.
Go to Tools > Internet Options > Advanced to find the two options which control revocation checking. Check for server certificate revocation controls (whether revocation checks occur for HTTPS connections) and for publisher’s certificate revocation controls (whether revocation checks occur when validating the Authenticode digital signatures on downloaded programs and ActiveX controls).
By default, Windows Vista and later enable revocation checks in both scenarios, while Internet Explorer on Windows XP only enables Authenticode Revocation checking by default because of the performance impact of downloading CRLs for HTTPS connections.
3. When Internet Explorer checks certificate revocations on Windows Vista or later, if a given certificate specifies a CRL or OCSP URL, but the revocation check cannot be completed (i.e. the Certificate Authority’s server is not reachable), Internet Explorer will not notify the user.
4. Some well-known browsers like Chrome do not even check server revocation by default.
All these lead to security risks when doing certificate verification. In fact, a lot of work has been done by Windows to improve the safety of the certificate revocation process, even though it is hard to completely eradicate all security risks. We suggest our customers use newer versions of operating systems and browsers, which could mitigate those risks in some ways.
Websense can successfully protect customers on these issues.
Websense ACE™, our Advanced Classification Engine, does a complete certificate verification when doing file classification: during this verification process, it downloads and parses CRL files to check certificate revocation state, and what’s more, it even implements a cache mechanism to speed up this checking process. For some vulnerabilities discovered by the public during certificate verification process, Websense ACE has carefully checked itself to make sure all vulnerabilities are correctly patched – for example take MS12-024/CVE-2012-0151, where ACE has implemented counter measures into its code based on detailed analysis, thus it won’t be fooled by malicious samples. ThreatSeeker® Intelligence Cloud also successfully handles these security issues, all digital signatures are carefully verified and the certificate revocation state is correctly checked.
Leave a reply
