Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Warns Of Two Apps That Installed Root Certificates Then Leaked the Private Keys (zdnet.com)

Posted by msmash on from the deja-vu dept.

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.

79 comments

  1. NSA Strikes Again by Anonymous Coward · · Score: 0

    Thank God for contractors who can take the blame and give bigbrother a backdoor.

    1. Re: NSA Strikes Again by Anonymous Coward · · Score: 0

      I am not surprised they have a bug. I am surprised they announced it at the same time they were releasing the latest updates

    2. Re:NSA Strikes Again by OrangeTide · · Score: 2

      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
    3. Re:NSA Strikes Again by Killall+-9+Bash · · Score: 0

      If only there was some company that has root on all the boxes, that could delete and/or revoke these certificates.....

      BULL. FUCKING. SHIT.

      This is like management at an apartment complex telling you some idiot left the back door open for anyone to get in. Did they close the door? No, but you should be appreciative of the fact that they told you about it.

      --
      "Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
    4. Re:NSA Strikes Again by gnasher719 · · Score: 1

      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.

  2. Holy shit, Microsoft is more evil than usual by drinkypoo · · Score: 4, Interesting

    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.'"
    1. Re:Holy shit, Microsoft is more evil than usual by DarkRookie2 · · Score: 1

      Fuck that. Die of ass cancer in a fire, Microsoft.

      Too good for them.

      --
      http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
    2. Re:Holy shit, Microsoft is more evil than usual by ctilsie242 · · Score: 1

      Probably because of the GDPR. A lot of pages state that because of the GDPR, all people connecting have to agree to stuff (usually, no-sue arbitration, all data can be used however the website feels like, user gives up all rights, usual legal garbage) before they can access the page.

    3. Re:Holy shit, Microsoft is more evil than usual by mysidia · · Score: 1

      usually, no-sue arbitration, all data can be used however the website feels like, user gives up all rights, usual legal garbage

      Generally in such an online EULA there would need to be an Opt-Out option provided where users can avoid the binding arbitration to avoid claims of procedural unconscionability invalidating the no-sue arbitration and rights waivers.

    4. Re:Holy shit, Microsoft is more evil than usual by Anonymous Coward · · Score: 1

      The only reason to have a "click to accept" or "EULA" is because the web page owner wants to f*ck you out of the rights guaranteed by the GDPR.

      If Micro$oft really wanted to provide the information freely without trying to track the reader and sell their data to whoever wants it, they wouldn't need an EULA.

    5. Re:Holy shit, Microsoft is more evil than usual by ctilsie242 · · Score: 2

      Looks like the opt-out option is to leave the page...

      This makes me wonder if this violates the GDPR's spirit.

    6. Re: Holy shit, Microsoft is more evil than usual by Anonymous Coward · · Score: 0

      I believe that Microsoftâ(TM)s lawyers and executive team were unanimous in their assessment that this could be a detrimental path to follow. Perhaps there is some expert firm somewhere who wants to tackle that issue directly and report back

    7. Re:Holy shit, Microsoft is more evil than usual by Anonymous Coward · · Score: 0

      Some pages state in the GDPR bar that closing it means that one agrees to their policies. I usually leave the bar open, but I also assume that that doesn't make any difference at all regarding tracking etc.

    8. Re:Holy shit, Microsoft is more evil than usual by gnasher719 · · Score: 1

      Probably because of the GDPR. A lot of pages state that because of the GDPR, all people connecting have to agree to stuff (usually, no-sue arbitration, all data can be used however the website feels like, user gives up all rights, usual legal garbage) before they can access the page.

      The problem of these sites is that they don't just need me to press a button, but to actually voluntarily consent. If the site only gives me the choice to either consent or not see the site, then they are in violation of the GDPR. (Source: Recent discussion on law.stackexchange.com with the relevant paragraphs of GDPR attached).

      slashdot.com is probably also in violation of GDPR, asking users again and again, so that we can safely assume that a click on "I agree" is not agreement, but clicking the wrong button. Guys, I really recommend you don't make any assumption that European users have agreed to anything if you want to stay on the right side of EU law.

    9. Re:Holy shit, Microsoft is more evil than usual by gnasher719 · · Score: 3, Informative

      Looks like the opt-out option is to leave the page...

      This makes me wonder if this violates the GDPR's spirit.

      It violates both the spirit, and the law. (According to law.stackexchange.com).

    10. Re:Holy shit, Microsoft is more evil than usual by thegarbz · · Score: 1

      Oh noes an EULA for reading a security advisory. I notice you didn't have any problem accepting a EULA to make this post.

    11. Re:Holy shit, Microsoft is more evil than usual by ElizabethGreene · · Score: 1

      The underlying paper is here:
      https://www.secorvo.de/publika...

      The CVE is here:
      https://nvd.nist.gov/vuln/deta...

    12. Re:Holy shit, Microsoft is more evil than usual by mysidia · · Score: 1

      This makes me wonder if this violates the GDPR's spirit.

      Opt-Out by leaving the page is NOT GPDR compliant.

      In fact.... Opt-Out in general is non-compliant with the GPDR.

      The GPDR requires Opt-In, and the default cannot be that you Opt-In, AND
      the service cannot require you to Opt-In in order to have full use of the service.

      That's why "closing the page to opt-out" is non-compliant: If you close the page, then
      you cannot proceed to use the service, because you've left the service without having use of it.

  3. Terrible system. by Anonymous Coward · · Score: 0

    You'd think each cert would only have specific permissons, like one just for sound hardware access.

    1. Re:Terrible system. by fisted · · Score: 1

      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!
    2. Re:Terrible system. by Anonymous Coward · · Score: 0

      Not saying the system is the bee's knees, but clearly you don't know the first thing about it.

      You're right, I don't. Would you mind explaining it like I'm 5? I am really confused by this specifically:

      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.

      Why is it that bad guys can apparently use this information to forge certificates for, say, Microsoft instead of just Sennheiser? That implies that Sennheiser themselves could forge certs for Microsoft. Why did they have that power? Is it just an inherent part of the whole ecosystem?

    3. Re:Terrible system. by Anonymous Coward · · Score: 0

      Because it a trusted CA and they left the private key in the form of a PEM file. Once you have that you can sign microsoft.com and your computer and browser will accept it because it is signed by a trusted CA.

    4. Re: Terrible system. by spongman · · Score: 1

      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.

    5. Re:Terrible system. by arglebargle_xiv · · Score: 1

      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.

  4. Never confuse evil with stupidity by Viol8 · · Score: 4, Insightful

    The 21st century MS is far more of the latter as all their decent programmers and team leads upped and left years ago.

  5. Nevermind the key leak by Anonymous Coward · · Score: 1

    Sennheiser makes headphones. WTF were they installing root certificates for?

    1. Re:Nevermind the key leak by OrangeTide · · Score: 2

      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
    2. Re:Nevermind the key leak by Killall+-9+Bash · · Score: 0

      And instead of a security update to remove and block these compromised root certs, we get a "this is fine" from MS.

      --
      "Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
    3. Re:Nevermind the key leak by Anonymous Coward · · Score: 0

      We used to do it, but we weren't dumb enough to ship the private key.

      The reason we did it is no certificate authority would sign a cert for an IP address.

    4. Re:Nevermind the key leak by bill_mcgonigle · · Score: 1

      The common name has to be a real hostname, but you can put in IP address in as a alternative name. What reason was there to not use a host name in the first place?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    5. Re:Nevermind the key leak by aaronb1138 · · Score: 1

      Classic "stay in your lane" problem. Though I would be surprised if Sennheiser even did the application development in house. Vastly more likely they either bought some of the not-quite-COTS customizable middleware stuff and had it branded or they contracted out to someone in southeast asia who pulled a, "needfully provide root cert to install drivers and sign packages".

    6. Re:Nevermind the key leak by Anonymous Coward · · Score: 0

      That's because only a goddamned moron embeds an IP address in software.

  6. How lazy can the reporting get? by Anonymous Coward · · Score: 1

    ...both developed by German software developer Sennheiser

    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.

  7. OMFG MSFT by Anonymous Coward · · Score: 0

    WTF?

  8. WTF by DarkOx · · Score: 4, Insightful

    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
    1. Re:WTF by Tom · · Score: 1

      This.

      Why does any app have the right, or the need, to install a root certificate? What is wrong with the people who allowed that to happen in the first place (MS, that means you) and what is wrong with the people who came up with, implemented and shipped that idea (that's the apps).

      And how do all those endpoint security solutions, all the three hundred 3rd party apps you need to install on a windows system to make it halfway secure all fail to catch this?

      Here is a prime example why information security is a failure: Everyone in this chain didn't understand what certificate chains are for.

      --
      Assorted stuff I do sometimes: Lemuria.org
    2. Re:WTF by Anonymous Coward · · Score: 0

      The root CA wasn't the problem. The issue is the included PEM file which contained the private key which is used to sign certificates. This should have never left a secure location. This is also why enterprises manage trusted root CA stores on workstations as well as servers In short, this is overblown as long as you don't trust that CA.

    3. Re:WTF by countach74 · · Score: 1

      That's definitely an issue, but the point is that the system should not make it so easy for an app to compromise the system like that. Allowing an app to install a root certificate is like giving the app the keys to the kingdom, but in a very subvert sort of way. It shouldn't happen. That is the real problem.

    4. Re:WTF by Skuld-Chan · · Score: 1

      So typically in Windows - to install software you need local admin rights - once your running as admin you can modify the trusted root in the Windows Certificate Store - that's the security model.

      There are limitations though - you can't use the patch engine unless the patch is signed by Microsoft or you have the trusted publisher setup via GPO. Depending on the type of driver as well if it's not Microsoft signed you can't install it at all (short of disabling OS code signing, which you can do as admin as well).

      Does Linux work differently? I know OS-X doesn't. I know Android doesn't - ie if you have root you're allowed to a certain extent to fuck up the machine and make it way less secure. You can setup Windows using policies to disable modifying the trusted root as well - even as admin (but an admin is setting up the policy on the server side).

      That said - all windows clients - whether consumer or commercial update their revocation lists automagically out of the box and Microsoft has been very on top of doing this for as long as I've used the OS.

    5. Re:WTF by Skuld-Chan · · Score: 2

      I would add too this is a legacy application - which isn't really sandboxed. I suspect they installed this to work-around not signing their drivers properly (there's an easier solution - just add the public key to the trusted publisher store).

      Modern apps - ie windows store apps can't modify the trusted root.

    6. Re:WTF by Nkwe · · Score: 2

      Serious question for MS why in the world can an app modify the system trusted roots? Why is that even possible?

      An application can not modify the system trusted roots, not unless you give it root / administrative permissions. The problem is that in the Windows world many people just do everything with an administrative account. To compensate for this (always running with an administrative account), Windows has a feature called User Account Control (UAC) which is kind of like "sudo" in the Linux world. The continued problem is that most users just click through the UAC prompts and let any software that wants administrative / root permissions to have them. In Windows when you install software and you get that prompt (modal dialog box with the rest of the screen sort of dimmed out) indicating that a program wants to make changes to your machine, you are being asked if you want to grant administrative rights / root to the software being installed. By clicking on "okay" you are granting rights for the application to escape the sandbox. (Technically it's not a sandbox, its a restricted set of permissions.)

    7. Re:WTF by thegarbz · · Score: 1

      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.

      The permission model works for a given purpose of a basic toy app. This isn't a basic toy app and it would be physically impossible for this "app" to work on Android without rooting the phone.

      While what you say is very true it still comes down to the basic tenant of security by reduced functionality.

      Serious question for MS why in the world can an app modify the system trusted roots?

      The "app" in particular is a management "app" for controlling and deploying headsets throughout the organisation and managing the devices they are connected to. I have a far more serious question. Why are you talking about "apps"? The advisory itself calls it "Software". Most of the article calls it an "application". The link to the update is a downloadable setup file from Sennheiser's website just like any proper software and will require administrator privileges to run.

    8. Re:WTF by thegarbz · · Score: 1

      Why does any app have the right, or the need, to install a root certificate?

      Ask your browser.
      Ask the Java installer.

      I don't understand what your fuss is about. The whole point of software is to be functional and part of being functional is using APIs in the system in the way they are intended. It's not like this happens by magic, you need to elevated privileges to access this.

    9. Re:WTF by Anonymous Coward · · Score: 0

      How about no?

      If I install a fucking phone app, that is not fucking permission for a fucking headphone company to fucking control all fucking cryptographic trust on my fucking machine. Regardless of where the fucking fuck they fucking keep the motherfucking keys.

      You're fucking goddamned fucking right I don't fucking trust that fucking CA, so why the fucking fuck are those fuckers fucking shoving it in my fucking "root CA store" for me?

      Fucking.

    10. Re:WTF by Anonymous Coward · · Score: 0

      This isn't about drivers, and it isn't the kind of app you get from Windows Store.

      I think this is a management application that allows users to generate certificates for headsets that they purchase, enabling the headsets to have secure communication with the host. Unfortunately you can't just go to your favorite root CA and ask them to sign certs for the 50 internal IP addresses of your headsets, so they wrote software to sign them and install their own root CA so you can authenticate the certs they generate.

      dom

    11. Re:WTF by ElizabethGreene · · Score: 1

      > Why does any app have the right, or the need, to install a root certificate?

      This is addressed in the underlying paper.

      The Sennheiser HeadSetup SDK supports the use of a locally connected headset by webbased softphones in a browser, loaded from a server web site via HTTPS. According to [Senn2018], the way HeadSetup supports this application scenario is by opening a local secure web socket (WSS) through which the headset can be accessed from within the browser. According to Sennheiser, the browser must be able to access this local web socket through a trusted HTTPS connection in order to bypass cross origin resource sharing (CORS) restrictions implemented by relevant browsers. Hence, the HeadSetup SDK needs a locally trusted TLS server certificate issued to the localhost IP address1 (127.0.0.1) and the associated private key.

      Source: https://www.secorvo.de/publika...

    12. Re:WTF by Anonymous Coward · · Score: 0

      Because, it isn't installed as an *app*, it's installed as a Win32 conventional program. It's not sandboxed. I'm guessing you'd be the first to complain if Microsoft made all applications run as apps run through the sandbox engine. (MS have done this -- it's called "Windows 10 S". Notice how popular that approach isn't with the Slashdot crowd?)

      "Seems like the sort of thing that only a first party signed tool should be permissioned to do!"
      So you wouldn't be the first to complain that Microsoft locked off certificate maintaience so only their tool can alter the root certificate list?

      The ideal fix is, you're right, for this to be an Appx-style application. (I have not got any idea WHY this thing needs to run a webserver on localhost - so that's the problem. It really should be a conventional application running inside an APPX container.)

      However, I do have an application (Telerik Fiddler) that does, delibrately, inject a SSL certificate in the same fashion (major difference is that it's very upfront about it with huge security warnings) - and it needs to (as I actually WANT it to do MITM SSL decoding.) It, however, takes the sensible precaution of generating the certificate then and there when the feature is enabled so no two machines have the same certificate. But it shows that there are legitimate uses of this very functionality. Did you think that might happen?

    13. Re:WTF by Anonymous Coward · · Score: 0

      The entire point of 'APPS' are to sandbox stuff so the rest of the system is not compromised by a bad app.

      No, that is what a 'sandbox' or a 'container' is for. An 'app' or 'Application' as it was called back in yesteryear, is a program that carries out a set of specific tasks. 'Apps' by definition have nothing to do with implementing a system's security framework beyond being subject to it.

      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?

      Because an Administrator gave it's installer permission to do so. That's one of the reasons they had to click "Run as Administrator" on it. Whenever you run something as the system admin account, you are by definition granting said thing very broad and powerful permissions that can do pretty much anything on a PC. Which is why the person responsible for the device needs to be aware of the consequences of doing so.

      Why is that even possible?

      Because some apps need to trust other things that are not protected by a third party. Modifying the trusted root store is a common thing in enterprise apps where the thing being trusted is run on an internal server. One such category of said apps is wait for it: Softphones.

      Seems like the sort of thing that only a first party signed tool should be permissioned to do!

      Anything that uses the Windows Crypto APIs with a privileged enough security token can do this. By definition they did use the "first party signed tool" you are referring to. There are also Group Policies, or their equivalent, that are used on enterprise networks that do the same thing for mass deployment.

      The real problem here was the fact that no one including the app developer implemented the PKI correctly. Security is hard to the point of the geeks oversimplifying it far beyond what it was designed to handle. The fact that people know next to nothing about how PKIs, and the entirety of HTTPS by virtue of PKIs being the core of HTTPS, actually work is the biggest failing of modern technology instruction. As a result of this failure we get a crapton of extra problems and "solutions" to said problems. Even in this thread there are people demanding that Microsoft should revoke such access to their own systems out of pure fear of the unknown. This is a real problem because simply revoking access doesn't prevent it from happening. It prevents legitimate uses, and makes more excuses for the willful ignorant to remain ignorant, but it will never prevent a cracker from doing it anyway. People need to realize that using a computer comes with responsibilities they must be aware of and upheld. This is one of those "If you don't know what it's talking about, find someone who does and learn from them" moments. One that we should all be mindful of.

      Sidenote: TFS is misleading. It makes the story look like actual malicious intent, when the linked article makes it very obvious it was a mistake made by the app developers. A mistake that said developers are already in the process of correcting by removing the app from download on their site, working on an updated version of their app, and putting up links to articles that give instructions on how to remove the installed certificates manually. Microsoft already issued an update to reject those keys for Windows users. We'll probably see similar responses from other vendors shortly. This is by no means malicious and TFS should be fixed to indicate this better.

    14. Re:WTF by Anonymous Coward · · Score: 0

      short of disabling OS code signing, which you can do as admin as well).

      Or during a reboot by entering the Advanced options on the recovery menu. ;)

      Does Linux work differently?

      Depends on the distro, but for Debian-based systems (Ubuntu) you need to put the cert into the /usr/local/share/ca-certificates folder and run update-ca-certificates from the terminal. For Fedora based systems, you put the cert into the /etc/pki/ca-trust/source/anchors folder and run update-ca-trust from the terminal. Both of these distros require root or sudoer permissions to perform this task. Once done, the cert will be trusted for all user-level operations. To use it within the kernel, i.e. for kernel modules, it's more complicated. That either requires root to install the cert to the kernel keyring at runtime, or that the kernel be rebuilt to include the cert by default. For Secure Boot signing, that's even more of a mess as you'll need to install the cert into the firmware which obviously requires root to even attempt, assuming your device permits such actions.

      I know Android doesn't - IE if you have root you're allowed to a certain extent to fuck up the machine and make it way less secure.

      Wrong. If the device is actually rooted, then you can do pretty much anything to an Android device as long as the user grants you the superuser permission when the prompt comes up. Even stock versions of Android allow installing trusted certs to some extent, although they also place a permanent notification that can't be dismissed when you install such certs, much to everyone's annoyance. The newest versions of Android actually break this functionality by allowing an app to ignore user-installed certs and even the system wide trust store if they so choose. The latter are actually more dangerous because in this case apps that ignore the system-wide trust store would need an update to be aware of the issue described in TFS. The latter are also subject to an issue of sudden functionality loss due to a corporate proxy server not being able to inject it's cert as it's expected to do. With no indication to the user for why said app doesn't work but others work perfectly fine. Said dangerous apps could actually encourage disabling security to make things work instead of improving security.

      Further, Android is actually worse than Windows on this front, because Android makes the user choose between "Secure Boot"*, or no "Secure Boot". There's no option to replace or modify the "Secure Boot" keys used by the bootloader under Android. As such, the user that wants to install a custom rom AND verify it hasn't been tampered with is left out in the cold.

      * I don't know what the official name for bootloader signature checking is under Android.

      I know OS-X doesn't.

      Funny, OS-X is one of the OSes impacted by TFA. Of course it allows this behavior. OS-X wouldn't be suited for enterprise environments if it didn't. Granted OS-X will not allow you to replace their "Secure Boot"* keys, but you can still do some damage. At the very least all of the user level things you could do under Windows. (HTTPS hijacking)

      * Once again I don't know what Apple's official term is for their bootloader signature verification mechanism.

      That said - all windows clients - whether consumer or commercial update their revocation lists automagically out of the box and Microsoft has been very on top of doing this for as long as I've used the OS.

      All OSes do this assuming the CRL / OCSP checking is implemented correctly both by the crypto library being used and the group that made the certificate in question. The reason why Microsoft and others issue updates is because some systems are not internet connected and may not be able to check properly on their own, or in the instances where the cert in question has missing or bad CRL / OCSP URLs in them and need to be distrusted by default.

    15. Re:WTF by Tom · · Score: 1

      The root CA wasn't the problem.

      Yes, it was. And you explain in your next sentences why. Because we know that not every dofus can handle cryptography correctly, which is why we have a limited number of trusted root CA which we at least expect to not be complete idiots.

      And that's why stupid people shouldn't handle root CAs or other dangerous materials.

      --
      Assorted stuff I do sometimes: Lemuria.org
    16. Re:WTF by Tom · · Score: 1

      My browser includes a set of root CAs because it needs to. Online banking and all the other HTTPS stuff (i.e. some day the entire Internet) won't work properly without.

      In a perfect world, my operating system would manage the root CAs, and the browser would just use them. In reality, it's a mix of both.

      But some random app? Sorry no, it has no business messing with this.

      --
      Assorted stuff I do sometimes: Lemuria.org
    17. Re:WTF by Tom · · Score: 1

      You didn't answer the question. They were lazy and cheap, that's all. It is possible to setup CORS properly. It is possible to get your certificate signed by a proper root CA. And nothing in the world forces you to use this particular method to access the device, you could have designed the setup differently.

      This answer is like saying "yeah, I gave the keys to the vault to every bank customer so they can go and take money whenever they need it. Much easier and convenient and we don't need to pay tellers."

      --
      Assorted stuff I do sometimes: Lemuria.org
    18. Re:WTF by thegarbz · · Score: 1

      because it needs to.

      Bingbingbing. You get a gold star. Now go look up what this "random" "app" actually does and things may start making far more sense to you.

      In a perfect world, my operating system would manage the root CAs

      For most browsers it does, none the less you need a way to install and uninstall certificates for specific purposes.

    19. Re:WTF by ElizabethGreene · · Score: 1

      It is possible to get your certificate signed by a proper root CA.

      With the utmost respect, you are incorrect. Per the CA/Browser Forum guidelines no publicly trusted CA should issue a certificate for an intranet name or IP address including both localhost and 127.0.0.1. Additionally, consider that your approach would have them use the same certificate on every machine that received the software. If that was the architectural decision then there would be no need to ship the root certificate public key to the machine at all.

      you could have designed the setup differently.

      I agree entirely. Why you'd want to shovel this desktop softphone application into a browser eludes me entirely.

    20. Re:WTF by Tom · · Score: 1

      For most browsers it does, none the less you need a way to install and uninstall certificates for specific purposes.

      The keyword being "for specific purposes". That should not be system-wide.

      --
      Assorted stuff I do sometimes: Lemuria.org
    21. Re:WTF by Tom · · Score: 1

      Per the CA/Browser Forum guidelines no publicly trusted CA should issue a certificate for an intranet name or IP address including both localhost and 127.0.0.1.

      That is true. I stand corrected.

      --
      Assorted stuff I do sometimes: Lemuria.org
    22. Re:WTF by thegarbz · · Score: 1

      What part of our connected online world where multiple applications access the same information often through a cloud (kind of like this service here) would imply that security certificates should not be system wide?

    23. Re:WTF by Tom · · Score: 1

      Explain to me why a headphone needs to install a certificate that will change which websites my browser trusts. Yes, I understand you can make a stupid design that requires this, but your design - your responsibility. So apart from that, why should the trust that contains my online banking and health insurance be modifyable by a random hardware gadget?

      I'm curious for any explanation that doesn't contain a variation of the phrase "because some other part of the thing that we designed relies on it". Find me a reason outside your control that makes this a good idea.

      --
      Assorted stuff I do sometimes: Lemuria.org
    24. Re:WTF by thegarbz · · Score: 1

      Explain to me why a headphone needs to install a certificate

      No I won't spoon feed you. The fact that you think this is a headphone that needs to install a certificate simply shows you have taken not the slightest bit of interest in the topic at hand. You don't even know the product, it's purpose, how to manage it, or it's target market, yet somehow you feel qualified to speak about it from your position of immense ignorance.

      Educate yourself and then maybe we can continue this discussion. Because right now it's as pointless as me telling you that you paid too much for your house and you should refinance (I don't even know if you have a house, but hey since knowledge of a topic seems to be irrelevant in this thread there you go, call your bank now)

  9. n=p*q... by Anonymous Coward · · Score: 0

    By releasing the private key, much easier for people to derive public key. Convenience.

    1. Re:n=p*q... by Anonymous Coward · · Score: 1

      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.

    2. Re:n=p*q... by Anonymous Coward · · Score: 0

      Whoosh...

  10. Why did Sennheiser even have root certificates? by Anonymous Coward · · Score: 0

    If the root certificates are given out to anybody, then they are likely already compromised even if they aren't accidentally leaked to the entire world.

    1. Re:Why did Sennheiser even have root certificates? by Anonymous Coward · · Score: 2, Informative

      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.

  11. This is why I don't run/use Windows Firewall. by Trax3001BBS · · Score: 1

    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.

    1. Re:This is why I don't run/use Windows Firewall. by mysidia · · Score: 1

      That's not a good reason to not run Windows firewall. Its expected to be there, and you're exposing yourself to excessive and unnecessary risk if you turn it off.
      Sure.... some applications you install can potentially circumvent outgoing restrictions by adding a custom rule when you install the application,
      But the primary purpose anyway is to reduce the attack surface for unintended Incoming IP traffic by locking down a large number of ports that are wide-open otherwise.

    2. Re:This is why I don't run/use Windows Firewall. by Anonymous Coward · · Score: 1

      "That's not a good reason to run Windows. You're exposing yourself to excessive and unnecessary risk if you turn Windows on."

      FTFY

    3. Re:This is why I don't run/use Windows Firewall. by Trax3001BBS · · Score: 1

      That's not a good reason to not run Windows firewall. Its expected to be there, and you're exposing yourself to excessive and unnecessary risk if you turn it off.

      I don't run Windows Firewall or Antivirus. I do and have run Comodo firewall for many years
      And a large HOSTS file help very much.
      Sorry to take so long to reply.

  12. Sennheiser not my favorite company by marcle · · Score: 1

    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.

  13. This is how you tell the difference... by Anonymous Coward · · Score: 0

    ... between software development and a profession.

    In an actual profession, the subhuman who actually put that cert into the software would not just be fired, but be permanently blacklisted, have their license revoked, have their name disclosed to the public, and possibly face criminal charges.

    Their bosses would likely lose the same licenses if they had them, and would also likely face criminal charges if they ordered this to be done.

  14. I have three words for all browser and OS vendors: by Anonymous Coward · · Score: 0

    DNSSEC DANE TLSA.

    Implement. Now. I don't care if you are under threat of FISA court order and U.S. government retaliations. This is precisely why DNSSEC DANE TLSA must be implemented. No more dragging your feet. This leak ends all trust in public CAs (assuming there was any left).

  15. Here's the CVE... CVE-2018-17612 by ElizabethGreene · · Score: 1

    Here's the CVE with a link to the details https://nvd.nist.gov/vuln/deta...

  16. Misleading headline by Anonymous Coward · · Score: 0

    Microsoft Warns Of Two Apps That Installed Root Certificates Then Leaked the Private Keys

    They did not install certificates and then leak private keys. They did both at the same time.

  17. Actually, by ElizabethGreene · · Score: 1

    From the security advisory:

    As a precaution, Microsoft has updated the Certificate Trust List to remove user-mode trust for these certificates. Customers who have not installed Sennheiser HeadSetup software have no action to take to be protected. Customers who have installed Sennheiser HeadSetup software should update that software via the links above.

    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.

  18. German software... by Kid+CUDA · · Score: 1

    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.

  19. "for all"? by Anonymous Coward · · Score: 0

    From the article: "Microsoft has issued a security advisory today warning that two applications accidentally installed two root certificates on users' computers, and then leaked the private keys for all."

    The article uses the clause "for all" more than once. What is this supposed to mean? "For everyone to see"? Or, even weirder, "for all [sic; 'both'/two] root certificates"?

    On the surface, the context of the "for all" clauses strongly suggests the ridiculous scenario of the private keys of *all* installed root certificates (i.e., including those unrelated to two certificates associated with the product) were exposed.