Working to detect and remove the eDellRoot malicious Root Certificate

Content Authoring
1

I’m actively working on BigFix content to detect and eventually remove the eDellRoot malicious Root Certificate.

Read more here: http://arstechnica.com/security/2015/11/dell-does-superfish-ships-pcs-with-self-signed-root-certificates/

Cert Thumbprint: (reddit)

98:A0:4E:41:63:35:77:90:C4:A7:9E:6D:71:3F:F0:AF:51:FE:69:27

Cert Serial Number: (reddit)

6b:c5:7b:95:18:93:aa:97:4b:62:4a:c0:88:fc:3b:b6

The following relevance SHOULD detect any certificate containing “eDellRoot”:

exists (hexadecimal string it) whose(it contains "eDellRoot") of ( unique values of (it as string) of values "blob" of keys of keys "Certificates" of keys whose(name of it as uppercase contains "CA" OR name of it as uppercase contains "ROOT") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates" of (x64 registries; x32 registries) )

The following session relevance should give the # of computers with “Dell Foundation Services” installed, which seems to be the source of this cert: https://bigfix.me/relevance/details/3003681

sum of multiplicities of unique values whose(it contains "Dell Foundation Services") of values of results of bes properties "Installed Applications - Windows"

The following session relevance should give the number of computers with the Dell Foundation Services windows service installed. Should match the number from the above session relevance:

sum of multiplicities of unique values whose(it contains "Dell Foundation Services") of values of results of bes properties "Services - Windows"

Names of Computers with “Dell Foundation Services” installed: https://bigfix.me/relevance/details/3003683

names of computers of results whose(exists values whose(it contains "Dell Foundation Services") of it) of bes properties "Installed Applications - Windows"

References:

4 Likes
2

Related Screenshots from: Blog Joe Nord: New Dell computer comes with a eDellRoot trusted root certificate

Showing cert in MMC:

Serial Number:

3

This should be the set of certificates to examine to see if they contain “eDellRoot”

number of values "blob" of keys of keys "Certificates" of keys whose(name of it as uppercase contains "CA" OR name of it as uppercase contains "ROOT") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates" of (x64 registries; x32 registries)
4

This is a pretty rough attempt at parsing the certificate data from the Windows Registry: https://bigfix.me/relevance/details/3003682

( concatenations " ; " of (preceding text of first "%82%01" of it | it) whose(it != "" AND it does not contain "%00%00%00%01%00%00%00") of (preceding text of first "%82%0f" of it | it) of (preceding text of first "0%82" of it | it) of (preceding text of first "0%81" of it | it) of (preceding text of first "0%1e%17" of it | it) of (preceding text of last "1" of it | it) of (following text of (start of first (first matches (regex "[\u1300-\u13ff]") of it) of it) | it) whose(exists (first matches (regex "[\u1300-\u13ff]") of it)) of (preceding text of first "%06%03" of it | it) of substrings separated by "U%04" of it) of it whose(it contains "U%04") of (hexadecimal string it) of ( unique values of (it as string) of values "blob" of keys of keys "Certificates" of keys whose(name of it as uppercase contains "CA" OR name of it as uppercase contains "ROOT") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates" of (x64 registries; x32 registries) )
5

Looking like this will make for a good Fixlet here. I’ve got an engineer just now starting to work on this and take what you’ve started to create a Fixlet we can include in our product, hopefully overnight.

1 Like
6

This does seem to correctly detect the presence of the eDellRoot cert:

exists (hexadecimal string it) whose(it contains "eDellRoot") of ( unique values of (it as string) of values "blob" of keys of keys "Certificates" of keys whose(name of it as uppercase contains "CA" OR name of it as uppercase contains "ROOT") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates" of (x64 registries; x32 registries) )
1 Like
7

– Edited 26 Nov 2015 –

Deploy eDellRoot and DSDTestProvider removal tool.bes

Dell has released the official KB page acknowledging both the eDellRoot and DSDTestProvider. An eDellRoot and DSDTestProvider removal tool was also provided in the KB page. This Fixlet helps to deploy the removal tool. Big thanks to James (@jgstew) for all the help!

Note: This Fixlet is not yet tested as the removal tool seems only run on affected Dell computers. Any field test and feedback is greatly appreciated.

– 25 Nov 2015 –

Revoke eDellRoot Certificate - Enable Workaround.bes

Here is a Fixlet which (hopefully) does the job. Kindly see below the detailed analysis. I can go wrong in many ways, so please do correct me.

Note: the Fixlet is in BETA stage, please test before deploying to production.

– Relevance #1 –

exists keys "Root\Certificates\98A04E4163357790C4A79E6D713FF0AF51FE6927" of keys "Software\Microsoft\SystemCertificates" of (keys whose (exists key "Software\Microsoft\SystemCertificates" of it) of key "HKEY_USERS" of it; keys "HKEY_LOCAL_MACHINE" of it) of native registry

This relevance tries to see whether the eDellRoot certificate exists in all ‘Trusted Root Certification Authorities’ stores. I am trying to use the certificate’s thumbprint to identify it.

– Relevance #2 –

not exists key "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Disallowed\Certificates\98A04E4163357790C4A79E6D713FF0AF51FE6927" of native registry

The eDellRoot Certificate is not yet in the “Untrusted Certificates” store.

– Action Script –

The action script creates a .reg file which writes the eDellRoot Certificate as a blob into the “Untrusted Certificates” store, effectively revoking the certificate.

The official removal instructions published by Dell includes deleting of certain DLLs/services which will keep installing this certificate. Since the action script does not delete the certificate but rather revokes it, I chose not to handle the DLLs to minimize any possible issue.

– Additional FYI –

There was a eDellRootCertFix.exe that’s once released in Dell’s official post. I decided not to use this tool, for the following reasons:

  • At the time of editing this post, Dell has pulled back this tool from the post.
  • Some users reported serious issue with this tool, in the replies of the post.
  • It requires .NET 4.0.

The “DSDTestProvider root certificate” that’s reported due to the same issue, was not yet confirmed by Dell. I chose not to release anything for it as of now.

4 Likes
8

Relevance 1 should be written this way:

exists keys "Root\Certificates\98A04E4163357790C4A79E6D713FF0AF51FE6927" of keys "Software\Microsoft\SystemCertificates" of (keys of keys "HKEY_USERS" of it; keys "HKEY_LOCAL_MACHINE" of it) of (x64 registries; x32 registries)

This is equivalent, but more efficient and more thorough.

Relevance 2 should be written this way:

not exists keys "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Disallowed\Certificates\98A04E4163357790C4A79E6D713FF0AF51FE6927" of (x64 registries; x32 registries)

As far as the actionscript, I’m not certain if the certificate needs to be revoked in both the 32bit registry and the 64bit registry. If so, then that actionscript wouldn’t be sufficient.

9

I’m also looking to create a fixlet to remove Dell Foundation Services and another to update it to a version that does not include the eDellRoot certificate once dell releases it.

10

FWIW, I seem to remember having problems using this method with 32bit systems. IIRC, I was using it to return values into console properties, and 32bit systems returned “error” instead of a useful value.

11

It will do that if you use x64 registry instead of x64 registries. In my testing x64 registries works fine on 32bit systems.

12

Thanks James for the suggestions!

1 Like
13

As I’m working through this, I would recommend the following steps:

I’d probably put all 3 of these items in a baseline and take it as a policy action.

Here is an analysis I created: https://bigfix.me/analysis/details/2994825

1 Like
14

Apparently there is another certificate from Dell from another Dell application with similar issues:

1 Like
15

Thanks James, this is new to me. They have also released a new fix tool.

1 Like
16

Do you know how to remove the certificates that are affected on the command line?

I was playing with certutil and some other commands. I’ve had more luck adding certificates than removing them.

Seems like this may be the answer:

Certutil.exe -delstore “ROOT” "CertificateSerialNumber"
17

Some session relevance for reporting on Dell System Detect:

Dell System Detect can be a per-user install:

18

Hi James, I have not tried certutil, but take note that after deleting the certificate, it’s possible that they can be added back. The Dell services using these certificates do add the certs back to the trusted cert store automatically.

FYI, what MS does is to add them to the Untrusted Certificates list: https://technet.microsoft.com/en-us/library/security/3119884

1 Like
19

I realize they can be added back, which is why I am removing the software / services, revoking the certificate, and removing the certificate.

Ideally I want to do all 3 in addition to adding it to the Untrusted Certificates list.

20

Something very odd about eDellRoot is that it doesn’t really make sense. Dell’s justification for doing this to provide a better customer support experience is absurd spin.

If all Dell was doing was having the client computers accept a connection to a remote server that was using the eDellRoot as it’s root signing certificate, then they didn’t need to include the private key with the certificate. Also, in this case, this would just be a convoluted way to get out of paying for a proper SSL certificate.

If Dell had not included the private key, this wouldn’t have been such an issue. If you assume that the private key is required for the use case, then it seems likely that Dell wanted the client machine to actually sign a certificate with eDellRoot and use that to authenticate with Dell’s servers, but then that doesn’t really make sense either because the authentication would be only as strong as the password securing the private key, which turned out to be very weak and would need to be embedded in the software anyway. This would be a convoluted way to achieve something no better than Pre-Shared Key (PSK) or Secure Remote Password (SRP) with TLS.

Reference: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Pinning_Alternatives