Wednesday, 25 November 2015

Dell Certificate Blunder Not Limited to New Computers

The news that Dell has been bundling a Trusted Certificate Authority to customers of brand new computers has been widely reported in the last few days. If you have not yet caught up with the news, essentially a Dell CA has been bundled with software installed on a new machine, which unfortunately also contains the corresponding private key. This means that anyone who has this private key, which is available to anyone with access to a new Dell computer, can sign any certificate. This would allow a suitably positioned attacker to masquerade as trusted secure web sites, with no visible warning in the end-user's browser.

However, Cyberis has noted that this issue is not limited to new computers. Within the last few weeks, we have identified multiple customer machines having another Trusted CA installed called DSDTestProvider (Serial a44c3847f8ee7180434db180b9a7e962, Thumbprint 02c2d931062d7b1dc2a5c7f5f0685064081fb221). Again, this Trusted CA has the corresponding private key, allowing anyone in possession of this key to once again generate new "trusted" certificates. All machines identified were cleanly built from Microsoft supplied installation media, on Dell hardware. The only commonality between the affected Dell machines identified was that users had reportedly run 'Detect Product' function on the Dell support website. If you've ever used this function, or the associated 'automatically detect drivers' function, it's recommended that you check your computer's certificate stores.

Uninstallation of the tool seemingly does not remove the rogue certificate. However, visiting the Dell support website this morning (25/11/2015) and running the auto-detect function did not appear to install the certificate. However, based on our customers' reports, within the last two weeks this certificate has been unknowingly installed on their freshly built workstations, suggesting if a fix has been rolled out, it's been very recent.

Recommendations are as follows:

Tuesday, 8 April 2014

OpenSSL "Heartbleed" Vulnerability

You may have already seen reference to the OpenSSL 'Heartbleed' vulnerability which was published this week (

If you have not yet seen this advisory, this is a very serious vulnerability in OpenSSL version 1.0.1 through 1.0.1f inclusive, and when exploited this bug allows a connecting attacker to retrieve sensitive memory contents from affected servers.

Exploitation of this vulnerability will allow an attacker to retrieve the private keys used by vulnerable servers, and consequently decrypt past and future traffic, and impersonate the service at will. Following the retrieval of the key material, the protection offered by the use of encrypted connections is nullified, and protected content (including personal data, usernames and passwords) may also be compromised.

The researchers who have identified the vulnerability are unsure whether it is currently being actively exploited, but the attack leaves no obvious trace in logs and consequently there is no way to ascertain whether systems (and key material) have been compromised. OpenSSL versions in the wild have been vulnerable to the attack since March 2012.

OpenSSL is, of course, widely used and a number of your applications may be affected. We strongly recommend that you take action to identify any OpenSSL-based services within your infrastructure that are vulnerable to this attack via their version, including web servers, VPNs, email and instant messaging systems.

All vulnerable OpenSSL installations should be upgraded immediately, or recompiled to prevent heartbeats - see

Following this, all key material that was exposed on vulnerable servers should be replaced - certificates should be revoked and reissued for public-facing services since these keys may already have been compromised.

Where applications have been protected by vulnerable OpenSSL versions, all existing session cookies and tokens should be considered compromised and invalidated. Passwords and other secondary encryption keys protected by vulnerable services should also be considered compromised, and users should be encouraged to change these details once certificates have been replaced.

Please contact us for further advice or assistance.