Słuchawki… z oprogramowaniem umożliwiającym podsłuchiwanie Waszej komunikacji https!

Dokładniej chodzi o oprogramowanie Sennheiser HeadSetup oraz Sennheiser HeadSetup Pro.

Doinstalowywało ono do Windows / macOS dwa nowe root certyfikaty CA. Co z tego wynika? Jeśli producent stworzyłby zupełnie inny certyfikat (np. dla serwera https) i podpisałby go swoim kluczem, nasz Windows ufałby takiemu połączeniu bez żadnego ostrzeżenia. W końcu tak w uproszczeniu działa PKI (mamy lokalnie zapisane „zaufane” certyfikaty CA – od Google, ekhem Symanteca, itp).

To jeszcze pół biedy, ale okazuje się, że z binarek oprogramowania można było pobrać klucz prywatny związany z jednym z certyfikatów!

Adding a Trusted Root CA certificate is a severe vulnerability, if a potential attacker has access to the associated private key. Such an attacker can issue forged certificates at his or her own discretion that will be automatically validated as valid and hence trusted on the affected vulnerable system.

Wprawdzie klucz prywatny jest zaszyfrowany AES-em, ale z jednego pliku DLL można było pobrać AES-a w plaintext. Przytoczmy dłuższy fragment oryginalnego badania:

In order to decrypt the file we needed to know the encryption algorithm and key that the manufacturer used for encryption. Our first guess was that the vendor employed the common AES encryption algorithm with 128-bit key in CBC mode. In the HeadSetup installation directory, we found only one piece of executable code that contained the file name SennComCCKey.pem, a DLL file named WBCCListener.dll. We searched for “AES” in the strings contained in this DLL. The result is shown in Figure 4: there is indeed the algorithm identifier aes-128.cbc. We found the key that the vendor used in close proximity to that algorithm identifier, stored in clear in the code.

Tym razem żeby ukrócić częsty komentarz producentów – to potencjalna podatność, bla bla bla, nic się nie da zrobić, bla bla bla, autorzy przygotowali konkretny atak. Najpierw przeprowadzili atak MiTM na „testową ofiarę” (np. za pomocą ARP cache poisoningu), a następnie za pomocą narzędzia mitm proxy podstawili swój certyfikat dla domeny google.de (podpisany otrzymanym wcześniej kluczem prywatnym). Chrome nawet się nie zająknął i przedstawił piękną kłódkę:

przejęte połączenie

Atakujący mieli dostęp do całej komunikacji w plaintext… (mogliby również ją modyfikować „w locie”).

Szybki fix to po prostu usunięcie ew. „lewych” certyfikatów. W Powershellu można zrobić to tak:

certutil -delstore root „127.0.0.1”
certutil -delstore root „SennComRootCA”.

Sam producent wskazał też bardziej „klikalną” wersję usunięcia certyfikatów i dla Windowsa i dla macOS.

Martwi też ten wskazany przez badaczy fakt (nawet po usunięciu oprogramowania certyfikaty zostają…):

Due to the fact that any system on which the older version was ever installed remains vulnerable despite later updates or removal of the software

Jednocześnie producent chyba cały czas pracuje nad finalną poprawką:

HeadSetup & HeadSetup Pro software are temporarily not available for download due to a potential security threat.

–ms