- December 09, 2015
- What's Behind
Public Key Cryptography or more precisely electronic signatures can be used by computers to verify the identity of people, other machines or content in the web. The verifier needs the authentic public key of the signer to verify its identity. To verify the authenticity of this public key, Certification Authorities (CAs) issue signed certificates. For scalability, these CAs are organized hierarchically: a root CA issues certificates for lower level CAs, which in turn issue certificates for people or web sites. Now the verifier only needs the authentic root certificate for an identity verification.
Web browser and operating systems vendors include these root certificates of Certification Authorities that pass certain criteria with their products. If a user or web site certificate cannot be traced back to one of these root certificates, the browser will issue a warning.
The eDellRoot Certificate
Dell customises Windows installations on its computers with bundled drivers, software, and an added root certificate. This certificate was introduced in new computers shipped in August 2015. The big problem with the certificate is that it is accompanied by the corresponding secret key. The certificate is marked as being valid for all usage (see Figure 1). A programmer named Joe Nord was the first to communicate about the problem.
The private key was protected by a password that was promptly cracked and turned out to be "dell".
Figure 1The eDellRoot certificate – Credit: Joe Nord
A Certificate Authority's secret key is its most precious asset. With the key, it can create certificates for any person, application, or web site. In this case, we find the deadly combination of a trusted root certificate, and the corresponding secret key on thousands of PCs sold by Dell. Anyone with access to one of these PCs has the ability to create certificates that will be accepted by owners of the same kind of PC.
All the attacks below are possible without access to a trusted root CA. The power of having a root CA is that since all the forged certificates described below can be verified, the software (email, web browser or Operating System) will never be in a position to complain about any mismatch.
The attacker can create certificates for well-known secure web sites like Google or banking web sites. Using social engineering techniques, the attacker can manage to sit between the user and the web site, and intercept traffic that the user thought to be secure.
This allows the attacker to steal credentials or modify bank orders and statements on the fly.
In order to prevent the installation of malicious privileged software, drivers are now digitally signed. The attacked can create certificates for drivers with malicious features, like key logging, and once again using social engineering techniques, have the users install those. Since the drivers are signed with a certificate that can be traced back to a trusted root certificate, the Operating System will not complain about unknown publishers.
The attacker (Mallory) can also create a certificate for another user (Bob), and digitally sign emails that will appear to come from Bob. Mallory can now send emails to Alice with instructions or misinformation, which seem to be signed by Bob. Alice will have no reason to believe the emails come from someone else than Bob, and will thus follow the instructions or believe the misinformation.
This is a variant of ID theft, where the attacker (Eve) persuades the victim (Bob) to accept a forged certificate in the name of someone else (Alice). Bob will then use the public key that is in the certificate to encrypt his communication with Alice. Eve will be able to read the encrypted communication.
Users can check whether the certificate is on their computer by visiting this web site.
The best protection is to remove the certificate. Dell provided information on how to remove it.
Microsoft has added functionality in its Windows Defender tool that detects and removes the offending certificate.
The biggest open question is: how did the certificate end up on production PCs? Other than providing information about how to remove the certificate and its secret key, Dell has not offered any explanation on how this blunder happened.
Another open question is exploitation. Was this vulnerability exploited? If yes, by whom?
And the last, probably most important one: how can users and companies know which CA certificates bundled with their software and computers can be trusted?
About “What’s Behind” from ENISA
With the “What’s Behind” series ENISA aims at giving the interested reader some in-depth background about NIS related topics. The background is derived from past experiences and common sense; in no way should “What’s Behind” be understood as recommended course of action in a specific incident or investigation, or being a final conclusion. Feel free to get in touch with ENISA to discuss or inquire more information on the “What’s Behind” series (email@example.com).