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.
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
It's funny that it's a telephone app used to sell headsets.
And I can totally see installing root certificates as being the most direct way to solve their problems using authentication libraries on Windows. The wrong way, but the most direct. I guess a headphone company didn't want to pay to have their certificates signed, so they became their own authority. Best way to lose money is to cut costs.
“Common sense is not so common.” — Voltaire
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
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.