alphaspirit - Fotolia
Dell recently experienced a root certificate issue with its eDellRoot certificate, which was discovered to be preinstalled along with its private key on Dell PCs. The issue was similar to Lenovo's Superfish adware controversy in 2015. Microsoft has revoked support of the certificate, but at this stage there have been no known attacks related to eDellRoot. How serious is this eDellRoot exposure? Are self-signed root certificate authorities inherently problematic or was this just an isolated error?
The security vulnerabilities that the eDellRoot certificate spawned were serious, but it looks like the problem was discovered and mitigated before anyone managed to take advantage of this huge security blunder. The exact same eDellRoot certificate was installed on various models of Dell computers by an application called Dell Foundation Services that Dell preloads on many of its devices in order to speed up online support by identifying the computer model, drivers, operating system and hard drive.
The certificate created a threat as the certificate's private key was also preinstalled and because it was a self-signed, unconstrained trusted root certificate. The private key for a root certificate authority (CA) should only ever be held by the CA in a highly protected environment. Although the key was marked as nonexportable, various downloadable tools can easily retrieve it. Being unconstrained, it can be used for any purpose, including signing other Web server certificates. This scenario means a malicious user could act as a CA comparable to Verisign or Symantec CA, and sign its own fake certificates to impersonate other domains. Even HTTP public key pinning would not protect against such attacks, because browsers allow locally installed certificates to override any key pinning protection. Attackers could also make malicious software appear to be signed by a trusted developer, create phishing sites that wouldn't get flagged as illegitimate or perform man-in-the-middle attacks against Dell customers. For example, a hacker could connect to a coffee shop or airport's Wi-Fi network and decrypt the TLS encrypted communications of anyone using an affected Dell laptop to connect to the same network, without the knowledge of the victim.
Dell is removing the certificate from all future Dell systems and has pushed a software update to existing owners, which checks for the certificate and removes it if found. Meanwhile, Microsoft has revoked support for the eDellRoot certificate and a second root certificate called DSDTestProvider, by listing them as nontrusted certificates in the Windows Certified Trust List, so even if the certificates are installed, they will not be accepted. All supported editions of Windows 8 and later and Windows Server 2012 and later include an automatic update of certificate trust lists, so most users won't need to take any action to ensure they're protected.
It is important to follow the instructions provided by Dell for removing the eDellroot certificate. Simply removing the certificate from the root and personal certificate stores or reformatting a machine's hard drive and reinstalling Windows is not enough, as the Dell.Foundation.Agent.Plugins.eDell.dll module will reissue the eDellroot certificate. German security blogger Hanno Böck's website can run a check to see whether a machine is vulnerable.
While these actions resolve this particular situation, it is another example of how the centralized trust model based on CAs and the certificates they issue, and on which the internet relies, continues to be undermined. This is not an isolated error. Lenovo computers also shipped devices containing Superfish software that allowed man-in-the-middle attacks similar to the Dell situation. These incidents show that enterprise development teams looking to use any form of encryption and to deploy certificates in their software or hardware products need to have a far better understanding of how they should be installed and used, without opening up potentially highly dangerous vulnerabilities.
The issuance of an unconstrained intermediary certificate by the Chinese CA, CNNIC, which allowed the Egyptian company MCS Holdings to issue unauthorized digital certificates for several Google domains, demonstrates that CAs can abuse certificate-issuance mechanisms. The CA/Browser Forum tries to enforce its baseline requirements for certificates that are capable of being used to issue new certificates, but only browser and OS vendors, who do not have a unified vision of how to handle trust and security breaches, have the power to fully revoke support for certificates deemed untrustworthy.
Ask the Expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)
Discover how new TLS links can fix certificate authority failures
Find out if your enterprise should use open certificate authorities like Let's Encrypt
Dig Deeper on PKI and digital certificates
Related Q&A from Michael Cobb
WhatsApp vulnerabilities can enable hackers to bypass end-to-end encryption and spoof messages. Expert Michael Cobb explains how these attacks work ... Continue Reading
Disabling Google location tracking involves more than turning off Location History. Learn how to manage your account settings to stop tracking ... Continue Reading
Compared to TLS 1.2, TLS 1.3 saw improvements in security, performance and privacy. Learn how TLS 1.3 eliminated vulnerabilities using cryptographic ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.