Submitted via IRC for SoyCow1984
Audio device maker Sennheiser has issued a fix for a monumental software blunder that makes it easy for hackers to carry out man-in-the-middle attacks that cryptographically impersonate any big-name website on the Internet. Anyone who has ever used the company’s HeadSetup for Windows or macOS should take action immediately, even if users later uninstalled the app.
To allow Sennheiser headphones and speaker phones to work seamlessly with computers, HeadSetup establishes an encrypted Websocket with a browser. It does this by installing a self-signed TLS certificate in the central place an operating system reserves for storing browser-trusted certificate authority roots. In Windows, this location is called the Trusted Root CA certificate store. On Macs, it’s known as the macOS Trust Store.
The critical HeadSetup vulnerability stems from a self-signed root certificate installed by version 7.3 of the app that kept the private cryptographic key in a format that could be easily extracted. [...] the sensitive key was encrypted with the passphrase “SennheiserCC” (minus the quotation marks). That passphrase-protected key was then encrypted by a separate AES key and then base64 encoded. The passphrase was stored in plaintext in a configuration file. The encryption key was found by reverse-engineering the software binary.
[...] A later version of the Sennheiser app made a botched attempt to fix the snafu. It too installed a root certificate, but it didn’t include the private key. But in a major omission, the update failed to remove the older root certificate, a failure that caused anyone who had installed the older version to remain susceptible to the trivial TLS forgeries. Also significant, uninstalling the app didn’t remove the root certificates that made users vulnerable.
Source: Original source
(Score: 2) by acid andy on Friday November 30 2018, @02:01PM
That's a great idea, but I imagine in cases like TFA, the programmers might see the need to release their software installer as an operating system upgrade, in the same vein as the rootkits we have now, that would punch a hole in those sandbox protocols by "upgrading" that part of the operating system. I can't see how that can be stopped without also locking out the user from upgrading their own operating system. I suppose your first point about the increased permission granularity would at least mean they'd be told what OS component was about to be replaced, rather than the generic "this application needs root / admin access. OK?".
Master of the science of the art of the science of art.