Dell announced earlier this week that some of its homegrown digital (SSL) certificates used by Dell Foundation Services and Dell System Detect programs (which are intended to enhance support functions) have generated a significant security vulnerability for Windows systems. Essentially, if either certificate exists on a given computer, that computer can be lured to trust malicious systems, which might then expose it to malware or hacking attempts.

Before I go into specifics about where the threat may apply and how to protect your systems against it, here’s a quick background on how certificates work.

A primer on digital certificates

A digital certificate ensures the identity of a site that is connected to by an application such as a web browser. Its purpose is to assure the visitor (or application) that the site really is who it claims to be to prevent misrepresentation, which can assist in criminal or malevolent wrongdoing. Traffic is then encrypted to and from the site to protect the data it contains.

For instance, Twitter uses the following certificate to ensure site authenticity (Figure A).

Figure A

How do we know the certificate is legitimate? Because it’s issued (or signed) by a certificate authority called a root certificate authority (or root CA) that we trust. That authority has its own certificate (called a root certificate) that is often included by default in operating systems and common web browsers, but which can also be installed separately.

In Figure B we see the root certificate from a well-known and trusted agency called VeriSign, which was responsible for signing Twitter’s certificate.

Figure B

As long as your application trusts the root CA, it will trust any certificates issued by that entity. It’s much the same as your friend Michael the police officer telling you he’ll refer customers to your business, and you can trust if they say he sent them that they’re legitimate law enforcement personnel and not grifters, scammers, or other bad elements.

When the browser doesn’t trust the certificates it sees, you will receive prompts warning you as such, indicating it may be dangerous to access the site. Some browsers may even refuse to let you connect entirely.

An important note: Certificates rely on encryption involving private and public keys, which are sort of like signatures that link together like two pieces of a jigsaw puzzle. The private key is held only by the issuer — the root CA — and used to sign certificates to state “This came from me.” Client computers utilize the public key (which is publicly available) to confirm the certificate is legitimate.

If the root CA private key becomes compromised, a hacker can impersonate the root CA and issue their own certificates for malicious websites. They can then entice users to access the site for criminal, mischief, or other nefarious purposes — or write malware to do so silently, as well as read encrypted data. As long as the operating system or browser trusts that root certificate, it will accept any related certificates without question.

That’s what happened with Dell, and that’s what makes this such a big deal. The programs Dell put out had accompanying root CA certificates that were installed on the computers running this software. The problem is that the private keys were made public. It’s very similar to the Superfish incident from earlier this year.

Tim Erlin, the Director of IT Security and Risk Strategy for Tripwire, a well-known security organization, provided the following comments regarding the situation:

“It can be tough for consumers to understand not only how SSL certificates work, but also how they may present serious security vulnerabilities in the real world…. the system of certificates we rely on for encrypting communications also provides authentication of the parties involved. When a certificate is compromised, not only does it allow for an attacker to intercept communications, but it also allows an attacker to impersonate another party, such as a software vendor, in order to plant malicious software on your system.”

Dell has a helpful blog page that addresses the issue, and the comments section also provide further useful feedback and information.

The impact of the Dell certificates vulnerability

Certificates are trusted by operating systems (using a local certificate store) and within applications such as web browsers. Therefore, computers that have installed the Dell Foundation Services or Dell System Detect programs, or upon which a web browser was configured to trust the relevant root certificate authorities — called eDellRoot and DSDTestProvider, respectively — may be at risk.

Note: Systems with Dell System Detect upon which the “detect product” function was run between October 20, 2015 and November 24, 2015 may be affected; this may not apply if that function was never used. However, it’s important to be vigilant.

Unfortunately, it’s not just a matter of figuring out whether you’ve installed these programs on a system — Dell released them automatically since August 15, 2015, so it may be on your system(s) without your knowledge.

Dell has released a link that can automatically tell you if your system is vulnerable, but it’s worth confirming the results for yourself since this sort of thing can and will be useful knowledge down the road.

It’s not likely that anyone out there has manually set up Firefox to trust these certificates, but I’ll show you how to check a bit further anyhow. First, let’s look at how to examine the local certificate store to see if these certificates are trusted by the operating system.

1. Run the command mmc (Figure C).

Figure C

2. Click File and then choose Add Or Remove Snap-ins (Figure D).

Figure D

3. Double-click Certificates (Figure E).

Figure E

4. Choose Computer Account and then click Next and Finish.

Certificates installed on your local system will be displayed based on category: Personal, Trusted Root Certification Authorities, and so on. Access the Trusted Root Certification Authorities section to review the installed certificates (Figure F).

Figure F

I don’t have the offending certificates on my computer, but here are two examples of what you might find on a system that does have them (Figure G).

Figure G

This is the second example (Figure H).

Figure H

Double-clicking the eDellRoot certificate shows the following information (Figure I).

Figure I

How to check web browsers in Windows

The good news is that Internet Explorer and Google Chrome running on Windows rely on the local certificate store, so if you’ve followed the above steps the remediation advice below will apply.

Firefox has its own certificate store and must be inspected manually. Click Tools | Options | Advanced | Certificates and then select the Authorities tab. Scroll down the list to check for the root certificates described above.

The remediation

Dell has provided a page outlining the issue and offering an automatic removal tool as well as the manual steps involved. A full write up is here (PDF). In a nutshell, you can rely on their tool or, if you’d prefer to handle things yourself, manually remove the certificates and their related programs.

To manually remove the offending root certificates via the Certificate console I displayed previously, right-click each of them and choose Delete. For Firefox, select the certificate and then click Delete Or Distrust. To remove the Dell Foundation Services and Dell System Detect programs, you can uninstall them via the Control Panel. Note: If these programs remain on the computer, the problematic certificates may be reinstalled later.

Dell is also supposed to have released a software update last week to correct this and, as of November 27, 2015 the company stated it will take “several days to reach everyone,” so I feel it’s best to use one of the above options or at the very least have each system inspected to confirm the certificates have been flushed.

So what if you have to remove the certificates from multiple systems? These remediation steps may get exhausting. If you’re a system administrator, I recommend scripting their removal tools through whatever means you may have employed at your organization: Microsoft’s Configuration Manager (aka SCCM), PowerShell, Group Policy, or even batch files within login scripts. User comments on the Dell page indicate that this process may result in system notifications informing the user they’re either not affected or the problem has been fixed, so advanced warning to employees is a must.

In addition, it’s possible to centrally store the tools on your network and ask users to run them manually, though as an IT professional I prefer to handle things directly since it’s our job to protect systems and confirm as such.

Looking ahead

Mr. Erlin of Tripwire had this to say about the road before us:

“As long as we’re using the existing certificate-based system of encryption, we’ll continue to see these kinds of issues surface. It’s unlikely that this specific type of vulnerability will change much. Disclosing the private key will always allow for decryption. Encryption as a whole, however, has taken a beating around security in the last 18 months, from Heartbleed to Poodle and beyond. We’ll continue to see encryption related vulnerabilities escalate for the time being.”

That’s the problem with this sort of arrangement; if we trust root CAs, we are vulnerable to manipulations of this trust. In the meantime, what can we do to reduce their impact?

Well, if you followed along carefully, you may have noticed that Firefox, using its own certificate store, was invulnerable to this threat so long as no one manually configured it to trust those root certificates. But don’t let that lull you into a false sense of security and think that simply using Firefox will be an instant remedy for all future incidents; malware might be engineered to configure Firefox to do what hackers want it to do. I am aware of ways to use Group Policy, for instance, to get Firefox to trust specific root CAs.

I’ve researched this, and I’m not aware at this time of any methods to lock down certificate stores within operating systems or browsers so they cannot be changed, or to report on changes (this would be a great notion if it could be brought into practice), but it is possible to use centralized tools like Group Policy to trust specific root CAs, so as to maintain a consistent environment. This won’t prevent applications from installing their own root CAs, but it can at least help admins know what to expect when they examine root CAs on client systems and servers. And, hopefully, Dell will lead by example here, and this business of silently installing root CA certificates will cease among reputable software companies.

Ultimately, what it comes down to is reducing your attack footprint to present as small a target as possible. This is where standard methods for best security can help, such as reducing administrator access, eliminating unnecessary programs, and “whitelisting” applications so only those specifically permitted can run. Utilizing standard operating system images that can be deployed and redeployed with ease can also be helpful.

In short, knowing and managing a predictable environment — and preparing automation tools in advance to control it — will go a long way towards mitigating a threat or at least responding to it as rapidly as possible.

Article update on Dec. 8, 2015: In the Looking ahead section, we added to Mr. Erlin’s quote.