Is Dell shipping their computers with rogue root CA similar to Lenovo and Superfish?

According to Microsoft, this Dell cert. is also compromised.

 

So far these are the only two I know of edell & CN=DSDTestProvider and so maybe edell is only on computers shipped since august but CN=DSDTestProvider goes further back.

ON MS website they list the location in regedit but not the rest.
Here is what WD shows

HKLM\Software\Microsoft\SystemCertificates\ROOT\Certificates\
HKCU\Software\Microsoft\SystemCertificates\Root\Certificates\
rootcert:02C2D931062D7B1DC2A5C7F5F0685064081FB221

 

What I don't understand is if dell did a patch on the nov 24th why did I still have it on the 26th? how did they dispatch it?

 

eDellroot is not the only self-signed trusted root certificate on Dell computers.

Researchers at Duo Security found two more on a Dell Inspiron 14-inch laptop purchased by Darren Kemp, one of its researchers who is based in Calgary, Canada, including one cert related to eDellroot that also ships with a corresponding private key, and a Atheros Authenticode certificate and private key used to sign Bluetooth drivers.

The impact of the two other certs is limited compared to the original offender. The Bluetooth certificate has been expired since March 2013, but Duo Security director of research Steve Manzuik said it was in the wild for 10-15 days. Now that the cert is expired, it could cause problems for the drivers.

“Because it’s expired, the risk is quite a bit lower. You can’t use cert to man-in-the-middle traffic,” Manzuik said of the Bluetooth cert. Duo published a report last night on its findings. “There was a period of 10-15 days when it was valid and being shipped. In that scenario, you could sign device drivers with it and the OS would trust them if signed by a known trusted cert. The risk now is when you revoke it, it will more than likely have an impact on Bluetooth drivers. You may have to reinstall new ones.”

Ref: https://threatpost.com/additional-self-signed-certs-private-keys-found-on-dell-machines/115467/

 

More info on Microsoft's actions here: https://malwaretips.com/threads/mic...dell-root-certificates-dll.53611/#post-453945

 

Actually, I disagree with this statement:

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)
​

I do so with the following ask HIPS rule given in pseudo code:

Source: any

Target: registry key/s =

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\*
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SystemCertificates\*

* = this key and all subordinate keys

So far I have had to add the following allow rule exceptions for the above ask rule:

Source: svchost.exe

Target: registry key/s =

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertLastSyncTime HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertEncodedCtl

Note that the above ask HIPS rule will also protect against recent adware that installs AV vendor code signing certs. in the Disallowed Cert. registry area.

​

​