Recently, Duo Labs security researchers found a few sketchy certificates on a Dell Inspiron 14 laptop we purchased last week to conduct a larger research project. And we weren’t the only ones - a reddit thread and some Twitter noise prompted us to share our observations and the real-world impact of our findings.
Download our research paper for the full technical breakdown of our findings.
Our Findings
- There are two certificates found on Dell machines, including a trusted eDellRoot root certificate
- In the wild, we identified that one of the systems using these certificates for providing web services over HTTPS was a SCADA (supervisory control and data acquisition) system
- eDellRoot is shipped preinstalled with an associated private key, which is a pretty big mistake
- Our research indicates that Dell is intentionally shipping identical private keys in other models
- This means an attacker could sniff a Dell user’s web browsing traffic and manipulate their traffic to deliver malware
- We also found another certificate mishap on our Dell machine - an Atheros Authenticode certificate also shipped with the Bluetooth software In the interest of full-disclosure, we are including the eDellRoot private key we identified and the entire Atheros certificate bundle with this post.
Real-World Impact
If a user was using their Dell laptop at a coffee shop, an attacker sitting on the shop’s wi-fi network could potentially sniff all of their TLS encrypted traffic, including sensitive data like bank passwords, emails, etc.
The attacker could also manipulate the user’s traffic, e.g., sending malware in response to requests to download legit software, or install automatic updates - and make it all appear to be signed by a trusted developer.
Bonus Round: Leaked Atheros Authenticode Certificates
eDellRoot was not the only certificate mishap we identified with our Dell machine. The Bluetooth management tools which ship with the machine included a file called ‘Verisign.pfx’ the name alone was pretty ominous.
The .pfx archive required a password which took us all of 6 hours worth of sub-optimal cloud cracking to recover; the resulting password was: ‘t-span.’
It turns out an Atheros signing certificate also shipped with the Bluetooth management software! It’s the certificate used to sign four of the Bluetooth drives that shipped with the install:
btath_hcrp.sys
btath_lwflt.sys
btath_pan.sys
bthathfax.sys
Thankfully, this certificate expired on 3/31/2013 making it less prone to potential abuse. However, it appears that this certificate was in circulation while it was still valid (at least 11 days from what we can tell).
That means anything that was signed and timestamped prior to the certificate expiring could be valid. The earliest driver version that we could identify with this certificate was released on March 19, 2013 with the “Dell Wireless 1601,10.0.0.227, A00 Driver” version 11.22.54.596.
Remediation for eDellRoot
We are unsure what Dell Foundation Services (DFS) actually does on a Dell systems, however, Dell has a vague description here and a Dell support forum also contains this overly vague and unhelpful response from Dell.
Many people have indicated that removing the eDellRoot certificates from the root and personal certificate stores is sufficient to protect users. This is not entirely accurate; you must remove the eDell plugin entirely or the certificate will be reinstalled whenever it is loaded.
This can be accomplished by deleting the ‘Dell.Foundation.Agent.Plugins.eDell.dll’ module from the system. Failure to do so may result in continued exposure to this security flaw.
An alternate remediation could also be as follows, however, we recommend that this be only performed by qualified professionals:
Note that if you ever perform a factory reset on your Dell system, this certificate and the eDell plugin will be restored to the system and you will have to manually remove it again.
Conclusion
This highlights a disturbing trend among original equipment manufacturer (OEM) hardware vendors. Tampering with certificate stores exposes users to unnecessary, increased risk.
Tampering with the certificate store is a questionable practice, and OEM’s need to be careful when adding new trusted certificates, especially root certificates. Sadly, OEM manufacturers seem to not be learning from historical mistakes and keep making them over and over.
We look forward to engaging with the security community as a whole to get to the bottom of this to help protect affected Dell customers, and we look forward to more care and consideration on the part of OEMs when deciding to customize certificate stores.
Watch this blog for more on this and other issues like it from Duo Labs in the near future.