Slashdot Mirror
Microsoft Warns Of Two Apps That Installed Root Certificates Then Leaked the Private Keys (zdnet.com)
Catalin Cimpanu, reporting for ZDNet: Microsoft has issued a security advisory this week warning that two applications accidentally installed two root certificates on users' computers, and then leaked the private keys for all. The software developer's mistake means that malicious third-parties can extract the private keys from the two applications and use them to issue forged certificates to spoof legitimate websites and software publishers for years to come.
The two applications are HeadSetup and HeadSetup Pro, both developed by German audio hardware company Sennheiser. The software is used to set up and manage softphones -- software apps for making telephone calls via the Internet and a computer, without needing an actual physical telephone. The issue with the two HeadSetup apps came to light earlier this year when German cyber-security firm Secorvo found that versions 7.3, 7.4, and 8.0 installed two root Certification Authority (CA) certificates into the Windows Trusted Root Certificate Store of users' computers but also included the private keys for all in the SennComCCKey.pem file.
The two applications are HeadSetup and HeadSetup Pro, both developed by German audio hardware company Sennheiser. The software is used to set up and manage softphones -- software apps for making telephone calls via the Internet and a computer, without needing an actual physical telephone. The issue with the two HeadSetup apps came to light earlier this year when German cyber-security firm Secorvo found that versions 7.3, 7.4, and 8.0 installed two root Certification Authority (CA) certificates into the Windows Trusted Root Certificate Store of users' computers but also included the private keys for all in the SennComCCKey.pem file.
I tried to follow the advisory link in TFS and was redirected to a page asking me to accept a EULA. I have to agree to a EULA before I can read a security advisory? Holy fucking shit. Tell me again how this isn't the same old evil Microsoft. Actually, it isn't; time was, you could read anything on their site even without javascript. Now you need to not only enable scripts, but agree to a contract?
Fuck that. Die of ass cancer in a fire, Microsoft.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The 21st century MS is far more of the latter as all their decent programmers and team leads upped and left years ago.
Sennheiser makes headphones. WTF were they installing root certificates for?
You mean Sennheiser, one of the world's largest, high-end audio hardware companies? It's the obvious lack of research on the small things that expose journalists complete misunderstanding of the big things.
I feel that the NSA should be paying contractors for this valuable service instead of always getting it for free. Someone ought to sue. First we need to organize an idiot software contractor's union. (ISCU)
“Common sense is not so common.” — Voltaire
These are root CA certs. Their very specific permission is to be able to sign other certs, including intermediate CA certs, by the way.
Not saying the system is the bee's knees, but clearly you don't know the first thing about it.
CLI paste? paste.pr0.tips!
The entire point of 'APPS' are to sandbox stuff so the rest of the system is not compromised by a bad app. Android manages to fail in some ways with actual vulns where a evil app can send malformed messages to other apps etc. However by and large the permissions model works for single user devices.
Serious question for MS why in the world can an app modify the system trusted roots? Why is that even possible? Seems like the sort of thing that only a first party signed tool should be permissioned to do!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Partners of MicroSoft (having a Certification Authority (CA) certificate) are allowed to pass through Windows Firewall with no notifications.
I can't find a link for it now, as it's was posted a very long time ago.
Yeah, they make high quality expensive audio gear. But their customer service sucks, and I wouldn't be surprised if their programmers suck for the same reason.
A few years ago, I had a problem with a cable on one of their high end headphones, where it connected to the earcup. The cable wasn't removable, so I emailed their service department to ask about repair.
I got a very snotty reply suggesting I buy a new set of headphones. So I did. Not Sennheiser, of course. They have plenty of competition in the high-end audio market, and my new Focal phones sound way better than the old Sennheisers.
Wouldn't be surprised if the corporate response to this security issue is similar.
I think the point GP is making is why can we not have domain-specific trusted CAs, limited I. This case to creating certificates for a limited purpose (like sennheiser.com)?
I understand the need for verisign et al to need a global wildcard CA, but sennheiser shouldnâ(TM)t, and if the system doesnâ(TM)t allow them to do what they need without having to give them a global trusted cert, then the system is broken.
If only there was some company that has root on all the boxes, that could delete and/or revoke these certificates.....
I am quite sure that Apple could remove root certificates during a software update on MacOS. There is a set of root certificates that are always installed by the system, that set is totally under Apple's control. Other root certificates are stored in the keychain. Storing and modifying items in the keychain requires some password, but deleting items doesn't. I would assume other operating systems can do the same. Not sure how revoking root certificates work.
You don't need to DERIVE the public key: It's already *public*. It's clearly listed in the "root CA" (PEM file or similar) on the target system. The problem here is that the idiots at Sennheiser *also* included the "private" key in the PEM file.
Once an attacker has the private key for the root CA, and that root CA is installed as a trusted root CA on a target system, the attacker has all the information needed to create a TLS certificate that can be used on any connection and the target system will automatically trust it.
You need to read up on PKI.
ANYONE can create a "root CA". If they then convince some user, browser vendor or OS vendor to install that "root CA" (PEM file including the root CA public key) on their systems, then any system or intermediate certificate that is signed with the private key of the root CA will then be trusted by that system.
When some entity wants to issue a new "root CA" they create the "root CA" keys, one of which is "public" that they give away to anyone who wants to trust that "root CA" and the other key is the "private key" for the root CA. THIS "private key" must be kept secret!!!!!
In the early days the suggested practice was to build a standalone system that could create the keys (Any linux box can do it: A Raspberry Pi is perfectly capable.) and then create the keys for the root CA. The export the files for the root CA including the public key, but NOT the private key unless it's to copy it to a backup storage device. THEN take the "standalone system" and ALL copies of the "private key" and turn off the power and store in a vault like a safety deposit box or some other airgapped, extremely secure system.
Then when a vendor asks for an intermediate or system certificate to be signed by the "root CA", the vendor cert would be copied to an offline storage device, taken to the vault, and only then would the system with the private key be turned on, just long enough to sign the vendor cert and copy the signed output to the offline storage. The ONLY thing taken out of the vault would be the signed vendor cert and the private key would never leave the vault. Then the vendor could install their signed vendor cert on their webserver: Since everyone knows the public key for the root CA they can verify the signature of the vendor cert since the public key can decrypt what was encrypted with the root CA private key.
As long as the "private key" for the CA remains secret, then the owner of that key is the ONLY entity that can sign the customer's certs. That's the basis for the whole SSL infrastructure and all the padlocks in the browser: We trust the entity that owns the root CA to only sign a cert for a vendor if they have verified the vendor is real. Because we trust the root CA issuer, we transitively trust the vendor with the TLS cert signed by the root CA.
When the "root CA private key" is made public, ANYONE can sign anything and appear as if they were the entity that issued the root CA. So Joe Hacker can now create a TLS cert that looks like it was signed by Sennheiser.
Bottom line: Sennheiser has screwed up and is letting ANYONE IN THE WORLD create a TLS cert that will tell the OS or browser that it has been signed by Sennheiser, and if a system trusts that Sennheiser root CA then ANYONE can create a cert that will be accepted by the system.
Suggest: If you have a system, browser or app that trusts the Sennheiser root CA, remove that entry from the trusted root CA list and wait until someone who knows what they are doing tells you it's OK to put it back in.
Here's the CVE with a link to the details https://nvd.nist.gov/vuln/deta...
From the security advisory:
They did just what you ask, via the automatic Certificate Trust list Download. If you have the CTLD process download broken in your environment you can distribute it via script or group policy.
I've worked in the past with Beckhoff, Siemens and many other German manufacturers who also released a lot of software. They were all, without exception, terrible. The German industry has a serious software problem.
Also, the root certs are only half the story. The SennComCCKey.pem filename indicates that what was used was OpenSSL, and it'll be an ancient, unpatched, never-updated copy, alongside all the other ancient, unpatched, never-updated copies that every other app that needs crypto installs. I once counted seventeen copies on a random work machine, the oldest one being one of the 0.9.6 family, and that was in 2017.