> Nevertheless, because both eDellRoot and DSDTestProvider are installed in the Windows root store for certificate authorities together with their private keys, they can be used by attackers to generate rogue certificates for any website that would be accepted on the affected Dell systems.
It's not the certificate that's the problem. It's the installation of the private keys along with the certificate.
> It's not the certificate that's the problem. It's the installation of the private keys along with the certificate.
No, that just makes it much worse. Your system provider has no business installing a root certificate even without a private key, because that still gives them the ability to spoof any website. And even if you trust them not to do so, do you trust everyone who could break their security?
well. actually it's that the private key is the same for all machines and publicly accessible.... im going to have lots of fun with this. a ton of Dell machines about to get totally owned.
I'm happy with my zenbook hardware wise, but it still came with a bunch of crap installed. I only use my arch partition, but I think I'll wipe the windows partition it came with and do a fresh install if I get tempted to use windows for something.
Microsoft is the one to blame for this situation really, they need to take responsibility for checking the security of all OEM installs prior to shipping.
To appropriately market such PCs, you have to expose the ad-infested fraud that the standard BestBuy or Staples laptops are, and that is an uncomfortable position to be in for Microsoft. So no wonder Signature PCs didn't take off. It's kind of like advertising "Signature Boats", "Signature" because they have zero holes in them.
Where is Dell|Asus|HP|Lenovo going to find the margin to charge to be able to afford the sorts of capital expenditures that Apple makes to provide better hardware? I'm sure that the PC people know how awful an experience their computers provide; but they're trapped in a very low margin commodity business.
I think the point is that an adult mostly risks losing money from their bank account (assuming they do their banking online), credit card (if they buy anything online) or the like.
Having a compromised machine on your network serves as entrypoint. The machine may also be part of a botnet which could expose you to questioning or worse by the authorities if the botnet is used in an attack.
neither is something you'd want, even if the machine itself is not used for anything critical.
Until your main laptop is unavailable for some reason, so you borrow the kids one to do that urgent bank transfer or buy something online. Hopefully at that point you'll notice the amount of adware and crapware hogging the laptop and compromising it's performance that the kids have just got used to, and realise something is wrong before handing over your bank details to the Russian mob.
A part of me wants to go "Un-freaking-believable!"
The other part is like, "You really did not see this coming?"
The worst part is that this was probably done for ridiculous reasons. If they had put the certificate on their systems to allow the NSA to spy on their customers (just as hypothetical example), planting such a certificate would probably be a reasonable approach. But in the case of Lenovo and Superfish, this was done to show f___ing advertisements to users, and I am certain in Dell's case their reason is not much better. And for that, they put their customers security at risk. For freaking advertisements and (Dell's claim, I think) making life slightly easier for their support staff.
Once upon a time I spent a couple of hours looking at the Dell update utility and found that it pretty much allowed remote code execution to any web page your browser visits[1][2]. The quality of their code, the clear lack of anyone with any security knowledge looking at it and the 'fix' they deployed[3] made me never ever trust Dell again.
Seriously, their entire security relied on 'if url.endswith('dell.com')', plus a bunch of home grown 'encryption' that was utterly ridiculous. I'm sure if anyone spent a good hour or so looking at some of the oodles of software they pre-install on laptops you can dig up some other juicy exploits.
Oops, it was actually checking if the URL ends with 'dell.com', not startswith, but yeah. Any script on 'scriptkiddydell.com' gets full SYSTEM RCE, on a program that shows no signs of running and starts automatically. It's pretty much malware...
Well, to be fair they do parse it, extract the hostname, then do the ridiculous "if hostname.endswith('dell.com')". The simple fix is to replace it with '.dell.com', but they didn't do that. No, they 'upgraded' their 'authentication' mechanism (just a sha256 hash of a hard-coded GUID + the current time) and called it a day.
Oh, and they obfuscated the binary for iron-clad maximum security.
Essentially, there's a public DNS A record that maps a Dell subdomain to your local machine's IP, namely localhost.dell.com to 127.0.0.1
An attacker who can either abuse an already running local webserver (like Apache configured to listen to *:80) or start up a locally running webserver (using something like python's SimpleHTTPServer) can serve their content under a Dell subdomain.
This requires some sort of local filesystem privileges or potentially RCE, but if the original commenter is correct, this can be pivoted to SYSTEM RCE.
> The simple fix is to replace it with '.dell.com', but they didn't do that.
That doesn't suffice either, unless they also enforce HTTPS. Otherwise, any network you connect to can spoof DNS and load a fake dell.com page over http to break your security.
(Of course, even if they did require HTTPS, the attacker could serve up a fake dell.com HTTPS site signed with eDellRoot...)
And either way, they have no business even allowing an authentic dell.com page to execute arbitrary code on your system, either.
Is this a hardware or a software boycott? Because I have trouble finding anything remotely decent when it comes to macbookpro alternatives. Then again, I just sorta assumed most people always did clean installs and wiped the pre-installed shit that every PC vendor bundles.
Honest question: could you even do that without buying an extra copy of Windows? Back in the old days you got a CD key with your PC, so you can install a fresh copy of Windows easily from your own media.
But nowadays it seems like not all keys are equal, and I'm under the impression that short of buying your own copy you can only reinstall the OEM, hacked-up version.
I just went through this with a new Dell XPS for my dad.
I performed a wipe/reinstall (with media created directly from a Microsoft download) and Windows 10 never asked me for a key after reinstalling it, and it reports as being activated.
Seems like they've moved away from requiring an OEM key in addition to the SLIC BIOS signature.
They went a step further. Once a Windows 10 machine is activated, a "hash" of its hardware is taken and associated with the product key. When you reinstall Windows 10, the activation service matches your hardware information with the product key. You need to enter a product key only the first time you install Windows 10 on a particular machine.
When I was building machines and asked about the OEM licence, this hardware hash is related to the motherboard. MS consider a new motherboard a new PC, everything else you should get away with changing.
Am I reading it correctly that they also included the private keys? Why are the private keys for the cert installed with the cert? That doesn't make any sense.
Is this just incompetence, or is there some other reason that I'm failing to understand?
It reminds me of the various usability studies of PGP where new users, tasked to exchange keys with a correspondent, in a large percentage of cases emailed the private key to the recipient. It's awfully easy to do.
Exactly how Dell managed to distribute both private and public keys to this certificate is a wonder.
It might make sense if a unique private key was generated each time the application was downloaded.
For example, a user wishing to use the Azure web services either supplies their own cert/public key to Azure, OR requests Azure to generate a unique cert/key, and supplies the private key to you. Now, obviously, someone using Azure APIs doesn't install this key into your root store.
And that's the second "WTF?" - why install this as a Trusted Root cert, when your application could just hold it locally, and reference it?
(The first WTF being distributing a common private key - rendering the point of encryption useless.)
Maybe it's a good time to share this - I just bought a brand-new Dell XPS 15 and it runs Ubuntu like a dream. The only problem I've had is that suspend/resume (i.e. closing the lid) causes a kernel panic, but I've heard that's fixed in the next kernel release.
Regarding the suspend/resume stuff, which version of Ubuntu are you running? I don't have a problem, but I had to do a couple of things to get it working more like a Macbook: http://karlgrz.com/dell-xps-15-ubuntu-tweaks/
I'm running Ubuntu 15.04 and I haven't tried any of those things. My suspend/resume experience isn't like that blog, though - what happens to me is that I shut the lid, the os "suspends", I open the lid again and get an unresponsive black screen and I have to reboot.
This is almost exactly what I've done to set up my machine: http://ubuntuforums.org/showthread.php?t=2301071&p=13382949#... . This thread claimed that the kernel v4.3 fixed this issue, but it still happens for me - I was going to wait until the next 4.4 RC to give it another whirl.
I've had this problem too, in my case it was caused by some clever (way too clever imo) stuff going on that tries to write a bunch of io ports to a safe place on suspend and writes that data back to the various chips on resume. This caused all kinds of trouble.
If your BIOS supports it choose 'sleep' rather than 'hibernate' for suspend/resume. It will be a bit slower but there is far less OS dependent magic going on under the hood.
What really bugs me about this whole certificate saga is this: Ok, so you messed up. But then we get this - to my ears - absolutely bogus spiel about this being for 'improved customer service'. I find it very hard to make that link. And then, to add insult to injury, after messing up like that there is no 'all hands' inside Dell to see if that 'mistake' (let's assume it really is a mistake, to be kind to them) had been made in more than one place, which in fact it is.
Once is normal, twice may be coincidence, thrice is enemy action. Let's hope for Dell that there won't be a third, and if there is that they spot it themselves before someone else does. And I'm not buying the line about 'improved customer service' even for a moment, you can't improve customer service by allowing anybody aware of this certificate to MITM any and all connections from these machines and even if that were the case it is just a little bit too convenient that such a mistake would also include the private key, which allows Dell to conveniently deny that they ever leaked the private key to anybody in particular (instead, they leaked it to the world at large).
Superfish was bad, this is in some ways just as bad or worse.
Now, Dell, can we please have a detailed technical explanation about why these two root certificates and their private keys were stashed on customers machines without their knowledge centering on specific functionality (as in what is that you could not do without these certificates and keys distributed) rather than some weasel worded techno babble about 'improved support'?
I am convinced that the only thing that approaches the designed security level of an operating system is to buy a machine, completely wipe it and install your own paid for copy.
It appears that hardware vendors cannot make enough money merely selling hardware, and so they sell access, data and advertising to third parties (at least Superfish was in that area).
Being able to mod the software on your car is (I think) recently allowed (by the Librarian of Congress?). But it can be taken away at any revisiting event. I can see the day coming when it will be illegal to wipe a machine, because circumventing.
> I am convinced that the only thing that approaches the designed security level of an operating system is to buy a machine, completely wipe it and install your own paid for copy.
Of something other than Windows, since Windows will automatically run binaries provided by the firmware in the "Windows Platform Binary Table", which hardware vendors now use to reinstall their malware into a fresh Windows install.
(Of course, if you don't trust the firmware, it can do any number of other terrible things to you as well. And firmware from major hardware vendors has messed with Windows partitions to reinstall malware even without the WPBT.)
For what it's worth, Apple machines come secure out of the box, without any of this BS. They even prompt you to set up full disk encryption, and because it's well designed, almost anyone can figure it out.
This is one of the best things about the Apple eco system. Apple exists to sell you the hardware. All the software is designed to get you to love the experience so much that you will buy more hardware. They don't let anyone fuck with that.
This isn't an inherently bad idea – it works to provide critical drivers which you might need to get online, for example – but it really underscores how much depends on the OEM being more diligent than they've been in the past.
> I disagree that it isn't an inherently bad idea.
How else do you provide any drivers needed to get online? If you store them on the disk, malware or hardware failure will break it. If you use external media, it's an expense to OEMs and something the user will lose before they need it, not to mention the growing number of tablets & other devices which have very limited connectivity options.
I would be the first to say that Lenovo abused this and deserves all of the backlash they got but Microsoft created this mechanism to solve a real problem (“Get closer to an Apple-level experience”) which millions of people encounter at some point.
Unfortunately, when you cannot trust the hardware vendor the only answer is not to buy from them. There is no level of making the user experience worse or removing features which will prevent them from causing problems if they choose.
Does anyone know of a tool for Windows and OSX that will audit all the certificates installed on a machine and tell you which ones are removed, compromised, or generally unrecognized? It would be great if there was one so I can run audits because even if you install a fresh copy of the OS, the NSA and their friends can eventually sneak a cert on there. It would be great if there were an audit tool.
75 comments
[ 4.2 ms ] story [ 133 ms ] thread> Nevertheless, because both eDellRoot and DSDTestProvider are installed in the Windows root store for certificate authorities together with their private keys, they can be used by attackers to generate rogue certificates for any website that would be accepted on the affected Dell systems.
It's not the certificate that's the problem. It's the installation of the private keys along with the certificate.
No, that just makes it much worse. Your system provider has no business installing a root certificate even without a private key, because that still gives them the ability to spoof any website. And even if you trust them not to do so, do you trust everyone who could break their security?
It hasn't really taken off, so it appears that people don't highly value such safety.
Edit: I'm not defending Dell in any way, but if they're watching youtube and browsing facebook, they'll probably be just fine.
neither is something you'd want, even if the machine itself is not used for anything critical.
Email accounts are interesting for spammers. Reason enough to want working https.
http://www.theregister.co.uk/2015/11/25/dell_backdoor_part_t...
The other part is like, "You really did not see this coming?"
The worst part is that this was probably done for ridiculous reasons. If they had put the certificate on their systems to allow the NSA to spy on their customers (just as hypothetical example), planting such a certificate would probably be a reasonable approach. But in the case of Lenovo and Superfish, this was done to show f___ing advertisements to users, and I am certain in Dell's case their reason is not much better. And for that, they put their customers security at risk. For freaking advertisements and (Dell's claim, I think) making life slightly easier for their support staff.
Seriously, what were these guy thinking?
OTOH Dell used to bundle adware openly around 2007 and a lot of manufacturers still bundle badware/scareware. (Yes, I'm talking about McAfee here.)
Seriously, their entire security relied on 'if url.endswith('dell.com')', plus a bunch of home grown 'encryption' that was utterly ridiculous. I'm sure if anyone spent a good hour or so looking at some of the oodles of software they pre-install on laptops you can dig up some other juicy exploits.
1. http://webcache.googleusercontent.com/search?q=cache:http://... (sites down at the moment :/)
2. http://www.theregister.co.uk/2015/04/08/dell_update_security...
3. They literally just updated their home grown encryption/authentication code and made it clear that they didn't understand the issue at all.
Oh, and they obfuscated the binary for iron-clad maximum security.
That would be, if it were not for...
$ dig localhost.dell.com
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> localhost.dell.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56836 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;localhost.dell.com. IN A
;; ANSWER SECTION: localhost.dell.com. 462 IN A 127.0.0.1
An attacker who can either abuse an already running local webserver (like Apache configured to listen to *:80) or start up a locally running webserver (using something like python's SimpleHTTPServer) can serve their content under a Dell subdomain.
This requires some sort of local filesystem privileges or potentially RCE, but if the original commenter is correct, this can be pivoted to SYSTEM RCE.
That doesn't suffice either, unless they also enforce HTTPS. Otherwise, any network you connect to can spoof DNS and load a fake dell.com page over http to break your security.
(Of course, even if they did require HTTPS, the attacker could serve up a fake dell.com HTTPS site signed with eDellRoot...)
And either way, they have no business even allowing an authentic dell.com page to execute arbitrary code on your system, either.
But nowadays it seems like not all keys are equal, and I'm under the impression that short of buying your own copy you can only reinstall the OEM, hacked-up version.
I've never tried though. I don't know if there is still a different version for OEM or VL windows like XP had different key types.
I performed a wipe/reinstall (with media created directly from a Microsoft download) and Windows 10 never asked me for a key after reinstalling it, and it reports as being activated.
Seems like they've moved away from requiring an OEM key in addition to the SLIC BIOS signature.
https://www.techdirt.com/articles/20150812/11395231925/lenov...
Is this just incompetence, or is there some other reason that I'm failing to understand?
Exactly how Dell managed to distribute both private and public keys to this certificate is a wonder.
For example, a user wishing to use the Azure web services either supplies their own cert/public key to Azure, OR requests Azure to generate a unique cert/key, and supplies the private key to you. Now, obviously, someone using Azure APIs doesn't install this key into your root store.
And that's the second "WTF?" - why install this as a Trusted Root cert, when your application could just hold it locally, and reference it?
(The first WTF being distributing a common private key - rendering the point of encryption useless.)
Also updated my corresponding blog post (links to cert and key there in case you're interested): https://blog.hboeck.de/archives/876-Superfish-2.0-Dangerous-...
And the best part - no bogus certs!
This is almost exactly what I've done to set up my machine: http://ubuntuforums.org/showthread.php?t=2301071&p=13382949#... . This thread claimed that the kernel v4.3 fixed this issue, but it still happens for me - I was going to wait until the next 4.4 RC to give it another whirl.
If your BIOS supports it choose 'sleep' rather than 'hibernate' for suspend/resume. It will be a bit slower but there is far less OS dependent magic going on under the hood.
...
The only problem I've had is that suspend/resume (i.e. closing the lid) causes a kernel panic
I think it's time to apply a higher standard to "runs like a dream."
Once is normal, twice may be coincidence, thrice is enemy action. Let's hope for Dell that there won't be a third, and if there is that they spot it themselves before someone else does. And I'm not buying the line about 'improved customer service' even for a moment, you can't improve customer service by allowing anybody aware of this certificate to MITM any and all connections from these machines and even if that were the case it is just a little bit too convenient that such a mistake would also include the private key, which allows Dell to conveniently deny that they ever leaked the private key to anybody in particular (instead, they leaked it to the world at large).
Superfish was bad, this is in some ways just as bad or worse.
Now, Dell, can we please have a detailed technical explanation about why these two root certificates and their private keys were stashed on customers machines without their knowledge centering on specific functionality (as in what is that you could not do without these certificates and keys distributed) rather than some weasel worded techno babble about 'improved support'?
It appears that hardware vendors cannot make enough money merely selling hardware, and so they sell access, data and advertising to third parties (at least Superfish was in that area).
Being able to mod the software on your car is (I think) recently allowed (by the Librarian of Congress?). But it can be taken away at any revisiting event. I can see the day coming when it will be illegal to wipe a machine, because circumventing.
Of something other than Windows, since Windows will automatically run binaries provided by the firmware in the "Windows Platform Binary Table", which hardware vendors now use to reinstall their malware into a fresh Windows install.
(Of course, if you don't trust the firmware, it can do any number of other terrible things to you as well. And firmware from major hardware vendors has messed with Windows partitions to reinstall malware even without the WPBT.)
http://www.extremetech.com/mobile/197005-new-apple-malware-i...
http://arstechnica.com/information-technology/2015/08/lenovo...
This isn't an inherently bad idea – it works to provide critical drivers which you might need to get online, for example – but it really underscores how much depends on the OEM being more diligent than they've been in the past.
I disagree that it isn't an inherently bad idea.
How else do you provide any drivers needed to get online? If you store them on the disk, malware or hardware failure will break it. If you use external media, it's an expense to OEMs and something the user will lose before they need it, not to mention the growing number of tablets & other devices which have very limited connectivity options.
I would be the first to say that Lenovo abused this and deserves all of the backlash they got but Microsoft created this mechanism to solve a real problem (“Get closer to an Apple-level experience”) which millions of people encounter at some point.
Unfortunately, when you cannot trust the hardware vendor the only answer is not to buy from them. There is no level of making the user experience worse or removing features which will prevent them from causing problems if they choose.
http://geer.tinho.net/geer.blackhat.6viii14.txt
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...