Sennheiser-programma's plaatsten rootcertificaten met privésleutels

Microsoft en beveiligingsbedrijf Secorvo waarschuwen dat de HeadSetup-software van Sennheiser rootcertificaten op de computer van gebruikers installeert, waarbij de privésleutels te onttrekken zijn.

Microsoft meldt in de waarschuwing dat het zijn lijst van vertrouwde certificaten heeft bijgewerkt en de betreffende rootcertificaten van Sennheiser verwijderd heeft. De Sennheiser HeadSetup 7.3.4903-en 8.0-applicaties en de Pro-versies van de software plaatsten ca-certificaten in de Trusted Root CA-database van lokale systemen, constateerde beveiligingsbedrijf Secorvo.

HeadSetup en HeadSetup Pro zijn applicaties van Sennheiser die op de achtergrond draaien en moeten garanderen dat headsets en speakerphones van de fabrikant functioneren met verschillende telefoniepakketten. De software zorgt onder andere voor firmware-updates en gepersonaliseerde instellingen.

De headsets zijn te benaderen via de browser, waarvoor de applicatie een lokale websocket opzet. De toegang daartoe verloopt via https, om bepaalde restricties van browsers te omzeilen, aldus Sennheiser. Daarvoor moet de HeadSetup-sdk een lokaal vertrouwde tls-servercertificaat toevoegen. Het probleem was dat de software de private sleutel publiceerde in het bestand SennComCCKey.pem, dat samen met het bestand SennComCCCert.pem in de installatatiemap stond. Bij het verwijderen van het programma bleven de ca-certificaten aanwezig in trusted root store.

Het gaat om een ernstige kwetsbaarheid volgens Secorvo, omdat kwaadwillenden met een certificaat en een private sleutel malafide code kunnen signeren waarna deze zich als legitieme software kan voordoen. Daarnaast stelt dit criminelen in staat man-in-the-middle-aanvallen uit te voeren door een server als veilige server te maskeren.

Eerdere incidenten waarbij software rootcertificaten installeerde en daarbij voor onveilige systemen zorgde waren de Superfish-advertentiemalware van Lenovo en het eDellRoot-certificaat dat Dell op laptops plaatste.

Sennheiser heeft de programma's van zijn site verwijderd en updates uitgebracht die ervoor zorgen dat de certificaten verwijderd worden. De bijgewerkte versies zijn Headsetup Pro v.2.6.8235, Headsetup 8.1.6114 voor de pc en versie 5.3.7011 voor de Mac.

Reacties (30)

[t link]

Het begint wel steeds meer een probleem te worden dat lokale apparaten ook encrypted verkeer willen zonder meteen allemaal alarmbellen af te laten gaan in de browser. denk aan je router e.d. Heel lastig probleem vanuit een beveiligingsperspectief. Aan de ene kant zou je die apparaten via een cloudomgeving benaderbaar kunnen maken waardoor ze via dat certificaat toch zonder alarmen toegankelijk zijn, maar dan ben je afhankelijk van servers en moet je dat ook weer erg goed beveiligen en heb je daar blijvende kosten aan als bedrijf. Aan de andere kant zou je via lets encrypt een certificaat kunnen binnenhalen, maar dan moet je wel een geregistreerd domein hosten en hoe ga je dat in gods naam dan weer doen? je kan ook doodleuk zeggen klik maar weg die errors maar dan krijg je dat mensen langzaam aangeleerd krijgen dat die errors niet erg zijn wat je ook weer niet wil. dus hoe lossen we dit probleem dan op? toch veilige toegang tot je apparaten hun webportaal zonder cloud? ik weet het niet maar ik snap best dat bedrijven er zulke grove fouten gaan maken, het systeem werkt ook niet echt mee nu.

[Jerie]

Je kunt in theorie prima PKI gebruiken zoals bijv WoT zonder dat je CA of Letsencrypt of een FQDN nodig hebt.

[t link]

Dat snap ik niet helemaal, hoe kan je PKI gebruiken zonder een certificate authority te gebruiken zonder dat de browser allerlij foutmeldingen naar de eindgebruiker gooit?

[Jerie]

https://en.wikipedia.org/...#Methods_of_certification

[t link]

Dat vereist nogsteeds een certificaat authoriteit alleen dan binnen het lokale netwerk. in andere woorden heb je nogsteeds een certificaat authoriteit nodig die er niet is in consumenten netwerken. als jij nu een router op de markt brengt en je wilt de inlogpagina via HTTPS doen ga je dat niet kunnen doen zonder nieuwe CA toe te voegen aan de browser. Het is ook compleet onrealistisch om te verwachten van consumenten dat ze een eigen CA binnen hun netwerk gaan draaien, consumenten kunnen nouwelijks hun wifi netwerk goed beveiligen laat staan een CA.

[Jerie]

Nee hoor, dat kan gewoon een lokale snapshot zijn van een WoT zoals je bijv ook keys gebruikt bij DNSSEC. Consumenten kunnen in theorie prima zelf een "CA" worden dmv een USB stickje oid dat verder veilig wordt bewaard.

Zo kan ik bijvoorbeeld via HTTPS naar mijn router, wat snakeoil is, maar gezien ik WPA2 gebruik is dat OK (liever nog WPA3 of Enterprise). Maar ik kan ook WireGuard gebruiken waardoor het niet uit maakt hoe veilig het onderliggende netwerk is. Een valide HTTPS verbinding is in zo'n geval defense in depth; niet noodzakelijk.

[t link]

Keys die je gebruikt voor DNSSEC hebben nietzoveel te maken met https, https keys worden vertrouwd als ze ondertekend zijn met keys van known good CA's, dat gebeurt niet bij DNSSEC en die moet je dan ook handmatig goedkeuren wat dus in praktijk gewoon weer een self signed certificate is toch? want alleen de bron van die key bevestigd dat het inderdaad die key is, niet een derde authoriteit. zoals ik al zei, je kan dit probleem niet oplossen zonder zelf een CA te worden wat voor de gemiddelde consument gewoon geen doen is. of begrijp ik je nou verkeerd?

[Jerie]

Als het certificaat enkel werkt voor een bepaald intern domein (bijv in 127/8 range) dan zou het veilig moeten werken. Probleem is dat cert pinning niet werkt met deze methode.

[kuurtjes]

Ik vind het eigenlijk wel mooi dat ze voor encryptie zijn gegaan bij de communicatie tussen host en headset

Natuurlijk vrij raar dat ze voor een root certificate hebben gekozen, want eigenlijk is dat niet nodig.

[Radiant]

Er wordt niets gezegd over de communicatie tussen host en headset. Het gaat hier puur om communicatie tussen de browser en een lokale applicatie, dat moet schijnbaar via HTTPS. De lokale applicatie praat weer met de headset.

[frickY]

Wel "om bepaalde restricties van browsers te omzeilen", aldus hunzelf.

[ajolla]

Misschien de restrictie dat https vereist is?

[Verwijderd]

Er zijn inderdaad diverse browser API's, vooral in Chrome, die je alleen kunt gebruiken op HTTPS pagina's en niet op HTTP pagina's.

Afgezien daarvan worden browsers ook steeds "vervelender" in het melden wanneer je informatie stuurt naar niet-beveiligde pagina's.

Op zich best te begrijpen dat je dergelijk gedoe wilt voorkomen bij een app die feitelijk bestaat uit een lokale webserver. Maar ik vraag me af of daar geen betere manier voor is?

[Stoney3K]

Op zich best te begrijpen dat je dergelijk gedoe wilt voorkomen bij een app die feitelijk bestaat uit een lokale webserver. Maar ik vraag me af of daar geen betere manier voor is?

Hetzelfde heb je bijvoorbeeld met het niet toelaten van CORS (Cross-Origin-Resource-Sharing) op pagina's die via HTTP worden benaderd. Qua veiligheid te begrijpen, maar als je een embedded platform maakt is het soms veel te tijdrovend in de CPU om alles over SSL te moeten doen. Bovendien weet je toch dat er nooit een ongeautoriseerde client op komt, en als die het wel doet, kan ie niet meer dan de client die je zelf maakt.

Een simpele uitzondering zou bijvoorbeeld zijn om HTTPS niet af te dwingen op 127.0.0.1 en vanaf IP-adressen binnen het lokale subnet.

[Accretion]

Zo had ik bijvoorbeeld een relaisbord dat via ethernet aangestuurd kon worden.

In de URL wordt de username/password meegegeven, maar dat werd plots niet meer ondersteund door Chrome...

Het effect is dat je authenticatie volledig uit moest zetten...

Het ging hier ook om een apparaat dat ook niet vanuit het internet bereikbaar was.

[tweaknico]

Ja dat kan door te plekke een sleutel te genereren die alleen voor localhost bruikbaar is.
zoals iedereeen dat kan doen met de verschillende SSL toolkits.

Daarmee zijn het niet direct "vertrouwde" certificaten, in ieder geval zijn het dan per systeem bekende sleutels niet globaal bekende sleutels.

[Verwijderd]

Op zich best te begrijpen dat je dergelijk gedoe wilt voorkomen bij een app die feitelijk bestaat uit een lokale webserver. Maar ik vraag me af of daar geen betere manier voor is?

Als de rede dat je een browser nodig hebt is omdat je een desktop applicatie met webtechnologie wilt ontwikkelen, zijn daar voldoende frameworks voor. Zoals Electron.

[Xander2]

Op zich best te begrijpen dat je dergelijk gedoe wilt voorkomen bij een app die feitelijk bestaat uit een lokale webserver. Maar ik vraag me af of daar geen betere manier voor is?

Het probleem is: niet alle resolvers redirecten localhost direct naar loopback.
(https://tools.ietf.org/ht...localhost-be-localhost-06)

[R4gnax]

Op zich best te begrijpen dat je dergelijk gedoe wilt voorkomen bij een app die feitelijk bestaat uit een lokale webserver. Maar ik vraag me af of daar geen betere manier voor is?

Wie heeft het over een app? Het artikel hier heeft het over benaderbaar via je browser; dwz een normale webpagina.

Websockets zelf zijn niet HTTPS of HTTP. Websockets zijn TCP. Enige vereiste - in de meeste browsers althans - om er eentje te openen, is dat de webpagina die hem probeert te openen van een secure domain (dus HTTPS) afkomt.

Dus Sennheiser had simpelweg zelf een pagina online kunnen zetten met hun eigen certificaat, verifieerbaar via een chain-of-trust; en klaar.

[BoomSmurf]

Als je de private key erbij levert heb je niets aan die encryptie

[keranoz]

Het ging er, alsus het artikel, alleen over de browser restriction. Om die te kunnen omzeilen.


Zelf vind ik het kwalijk dat als je de software verwijdert dit soort troep achterblijft. Dit is precies de reden waarom ik ongeveer elk jaar mijn laptop en desktop van een verse Windows installatie voorzie.

[freaky]

Natuurlijk vrij raar dat ze voor een Root certificate zijn gegaan, want dat is eigenlijk niet nodig.

Inderdaad, geheel niet. Hadden alleen het certificaat zelf (publieke deel, tenzij de server het private deel ook uit de store haalt) hoeven te importeren onder het systeem | prive store. Dan was het geen CA geweest (dus niet toegestaan om andere certs te tekenen) en had het wel gefunctioneert.

Dit is opgezet door iemand die wat gegoogled heeft en het verre van begreep ws.

[GoBieN-Be]

De server die de webpagina aanlevert moet de private sleutel hebben. Aangezien de server hier op de computer zelf draait, via hun software, is de private sleutel echt wel nodig.

De fout is dat ze een Root CA gebruiken, en dezelfde Root CA op iedere computer met dezelfde private sleutel. Dat laat toe om websites op internet aan te maken met valse certificaten getekend door die Root CA. Iedereen die de software staan heeft en surft naar die website ziet een geldig certificaat.

Ze hadden kunnen gebruik maken van een dynamisch self-signed certificaat voor localhost of 127.0.0.1 en dat toevoegen aan de persoonlijke certificaten in de store.

Kleine opmerking: volgens mij gebruikt Firefox standaard NIET de certificaten in de trust store van Windows, maar enkel de ingebakken trust store van Firefox. Je kan dit wel aanzetten met een configuratie optie.

[seba]

Hoezo mooi? Deze actie bewijst enkel dat ze er werkelijk niets van hebben begrepen. Ze kregen het enkel werkende over https en de oplossing waarmee ze komen (een root CA met private key in) helpt je volledige beveiliging om zeep.

[locke960]

Het bewijst ook weer eens dat het hele certificaten systeem eigenlijk niet geschikt is als je echt veiligheid wilt hebben. Er zijn zo verschrikkelijk veel bedrijven die certificaten uitgeven en gebruiken, er zit altijd wel een prutser als Sennheiser tussen. Het is waarschijnlijk dat er nog veel meer prutsers zijn.

Hoe groter dit "chain of trust" bouwwerk wordt, hoe wankeler, zelfs als alle CA's 100% te vertrouwen zijn en 100% veilig opereren, wat ook onrealistische verwachtingen zijn, dan nog heb je de prutsers.

[fastedje]

De oorzaak is dat trusted CAs geen cerrificates voor lokale adressen uitgeven en dus lokaal https verkeer voor de gemiddelde gebruiker dan onbruikaar wordt. Ik heb me altijd afgevraagd waarom browsers voor lokale adressen zo kieskeurig zijn voor zowel http maar ook https met self-signed certificates.

[Fredi]

Waar is de deutsche grundlichkeit nu?

[Djordjo]

Hebben ze niets geleerd van het Lenovo-debacle met SuperFish-malware? Volgende keer artikel helemaal lezen

[Reactie gewijzigd door Djordjo op 23 juli 2024 02:31]

[RobinJ1995]

Wat een private key password ook, "SennheiserCC" 🤦‍♂️

[mutley69]

Sennheiser komt dan op m'n zwarte lijst. Zo simpel is dat.