Wątek: Uwaga! (nie)bezpieczna pomoc zdalna

Strona: 1 z 2

1 z 29: pajper

NVDARemote to bez wątpienia, przynajmniej w moim wypadku, jedna z najlepszych nowości dostępnościowych ostatnich lat. Świat jednak zwykle nie jest czarno-biały i pod wspaniałą funkcjonalnością kryje się... troszkę mniej wspaniałych rzeczy. Chodzi mi o bezpieczeństwo tej wtyczki.

Od dawna było wiadome, że wiele tu polega na zaufaniu do administratora serwera. Administrator serwera ma dostęp do kluczy wszystkich użytkowników. Stąd też bardzo przestrzegam przed niezaufanymi serwerami.
To jednak nie jest wszystko. NVDARemote używa do komunikacji gniazd szyfrowanych przez certyfikat TLS.
Problem stary i niestety dobrze znany: domyślny certyfikat jest taki sam. Wszędzie. W każdej instalacji. Oznacza to, że szyfrowanie tego typu nie stanowi żadnego problemu, o ile administrator serwera nie zmienił certyfikatu na inny. Dziś jednak, zestawiając na potrzeby sieci firmowej kilka dziwnych konfiguracji na routerze, zauważyłem dużo poważniejszy problem.

Okazuje się, że szyfrowanie NVDARemote jest, delikatnie to ujmując, niewiele warte, ponieważ dodatek nie wykonuje żadnej weryfikacji hosta i poprawności przedstawionych certyfikatów (tzw. SNI). Innymi słowy, nawet jeśli serwer jest poprawnie skonfigurowany, ze złożonym, generowanym RSA 4096 certyfikatem SSL, klient nie zweryfikuje otrzymanego certyfikatu. Otwiera to bardzo wiele możliwości ataku typu Man in the Middle, które w skrajnej sytuacji pozwalają przejąć sesję NVDARemote osobom bez dostępu do serwera i znajomości klucza, jeśli na przykład znajdują się w tej samej sieci (przykładowo sieć w szkole, internacie).

Oczywiście nie będę przedstawiał żadnego przykładu takiego ataku, jednak powiem, że testowo udało mi się go z powodzeniem wykonać między dwoma komputerami w sieci.


W tej chwili moim najlepszym zaleceniem dla osób korzystających z NVDARemote w krytycznym środowisku jest natychmiastowe przejście na komunikację idealnie z użyciem tunelu SSH lub szyfrowanego połączenia VPN. Zacząłem już prace nad poprawką i postaram się ją zaproponować na GitHubie, ale szczerze się obawiam, że zostanie ona uznana za "niezbyt pilną", jak kilka moich zgłaszanych kiedyś sugestii hardeningu tego dodatku.
Stąd też zdecydowałem się na inny tor działania i ostrzeżenie choć tutaj, zanim Pull Request trafi na światło dzienne i lukę, o ile jeszcze jej oczywiście nie znają, poznają osoby mające złe zamiary.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
13.05.2021 16:37

2 z 29: daszekmdn

Nie rozumiem ostatniego zdania.

13.05.2021 16:42

3 z 29: mateponczas

Jak to dobrze, że korzystam z własnego routera podczas sesji. Fajnie, że o tym mówisz.

13.05.2021 16:42

4 z 29: pajper

Zwykle, kiedy zauważy się błąd bezpieczeństwa, normalnym procederem jest poinformowanie o nim twórcy, dyskretnie. Przykładowo jakieś dwa miesiące temu w ten sposób zgłaszałem błąd w WordPressie. Odpowiedź dostałem w ciągu kilku godzin.

W wypadku tego projektu zdecydowałem się na inną kolejność, ponieważ zgłaszane taką drogą ostrzeżenia przeze mnie do twórców wcześniej nie przynosiły skutku.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
13.05.2021 16:46

5 z 29: zvonimirek222

to pisz pull requesta, w dodatku pisząc prywatnie do samego pana christophera Totha. Ja na każdym swoim serwerze remote generuję własny certyfikat. Przepraszam, ale nie dopuszczam takiego panoszenia. Słyszałem, że z bezpieczeństwem tej wtyczki jest źle, ale trzeba było wwłaśnie takiego uargumentowanego czegoś, żeby dotarło.
Student studentowi wszystko
13.05.2021 16:50

6 z 29: nuno69

haha, to jest wszystko spisek Spiveya. To jest robione przecież celowo.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb
14.05.2021 09:08

7 z 29: pajper

Na podstawie wykonanych eksperymentów (exploit na routerze open-wrt), uważam, że problem powinien być zaklasyfikowany jako przynajmniej poważny. Poniżej przeklejam przygotowany szerszy opis.


NVDARemote w połączeniach z serwerem używa szyfrowania TLS. Ma ono na celu zaszyfrowanie transmisji, chroniąc ją przed odczytaniem lub modyfikowaniem przez osoby postronne. Oczywiście należy tu zaznaczyć, że ochrona taka nie dotyczy administratora serwera i umożliwia mu podglądanie całej transmisji i wpływanie na nią. Pozwala jednak zabezpieczyć się przed podsłuchem przez innych użytkowników, a przynajmniej pozwalać powinna.
Podatność dotyczy procesu łączenia się z serwerem. Dodatek nie wykorzystuje warstwy SNI protokołu (Server Name Indication). Jej celem jest zweryfikowanie tożsamości serwera. W obecnej konfiguracji zaakceptowany zostanie każdy certyfikat przedstawiony przez serwer, bez żadnych weryfikacji.
Umożliwia to wykonanie ataku typu Man in the Middle. W tej sytuacji atakujący użytkownik podstawia ofierze własny, wygenerowany certyfikat SSL jako certyfikat serwera, a sam przekazuje otrzymywane informacje dalej, już właściwie zaszyfrowane. Z powodu braku weryfikacji klucza publicznego lub nazwy SNI, taki certyfikat zostanie zaakceptowany, zaś osoba atakująca uzyska pełen dostęp do wymienianych informacji. Zależnie od konfiguracji i poziomu izolacji sieci, wykonanie takiego ataku może być możliwe przez administratora routera lub dowolnego użytkownika znajdującego się w tej samej sieci.
Inny wariant ataku polegać może na utworzeniu sieci o zbieżnej do znanej nazwie. Użytkownicy, łącząc się do tak spreparowanej sieci, mogą nie zdawać sobie sprawy, że nie są już połączeni z wi-fi na przykład szkolnym lub pracowniczym, a specjalnym podstawionym przez hakera. Celem SNI jest właśnie zabezpieczenie przed tego typu działalnością.

Wygląda obecnie na to, że zabezpieczenie dodatku przed tą podatnością będzie wymagało aktualizacji wszystkich serwerów i klientów. Obecnie próbuję ocenić, jakie dokładnie zmiany można wprowadzić, by utrzymać kompatybilność wsteczną, być może jednak okaże się to niemożliwe. Poniżej wymienię rozważane przeze mnie zmiany.

Zalecenia dla użytkowników obejmują obecnie z mojej strony natychmiastowe zaprzestanie używania NVDARemote we wszystkich krytycznych systemach. Najbezpieczniej jest założyć, że luka była już znana i, być może, wykorzystywana. Zdecydowanie polecam używanie do łączenia się z serwerami Remote w firmach czy podobnych miejscach tunelu SSH lub szyfrowanej sieci VPN. Pozwoli to uniknąć podanego sposobu włamania.

Poniżej zamieszczam listę zmian, których implementację rozważam w dodatku w ramach uszczelnienia tej, jak i potencjalnie innych luk:
* Wymuszenie weryfikacji SNI lub, w wypadku hostów bez możliwości certyfikacji domeny, weryfikacji kluczem publicznym,
* Zmiana założenia klucza. Niech klucz będzie służył do podpisu lub nawet szyfrowania przekazywanych wiadomości przez funkcję ECDSA lub RSA, zaś do przekazywania wiadomości między komputerami służy jego hasz lub inna pochodna. W tym wypadku zgłoszona i każda przyszła luka, o ile nie dotyczyłaby protokołu szyfrowania, nie stanowiłaby zagrożenia lub dużego zagrożenia,
* Zapisywanie, jak w OpenSSH, listy znanych kluczy i zgłaszanie ich zmian.
Rozważyć można też całkowitą rezygnację z certyfikacji SSL na rzecz własnego protokołu podpisu kluczami publicznymi, z użyciem RSA. Możnaby w tym celu wykorzystać infrastrukturę podobną do propagacji kluczy GPG.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
14.05.2021 10:32

8 z 29: pajper

Oficjalne zgłoszenie problemu tutaj:
https://github.com/NVDARemote/NVDARemote/issues/234
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
14.05.2021 11:05

9 z 29: pajper

Pierwszy, na razie eksperymentalny szkic rozwiązania podatności:
https://github.com/NVDARemote/NVDARemote/pull/235
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
14.05.2021 17:44

10 z 29: zvonimirek222

nawet Christopher Toth odpowiedział. Pięknie się robi.
Student studentowi wszystko
14.05.2021 20:04

11 z 29: pajper

Podrzucam w załączniku pierwszą, wstępną, eksperymentalną łatkę. Na razie tylko po stronie klienta. Przy łączeniu się do serwerów bez łatki z tej wersji zobaczycie ostrzeżenie.
A jako że łatki dla serwerów jeszcze nie ma, prawdopodobnie wszędzie zobaczycie takie ostrzeżenie. :D

Podziękowania za współpracę dla @ctoth i @tech10.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
15.05.2021 13:48

12 z 29: piter9521

Ostatnio coś poszło na github to te poprawki? Jeśli tak to czy są jóż w addonie na stronie?

31.05.2021 16:00

13 z 29: zvonimirek222

Tak, jest nawet wersja alpha do nowej wersji do przetestowania.
Będę poprawiał spolszczenie, bo zrobiłem tam niechcący literówkę, więc i tak jest w fazie testów. Niedopatrzenia się zdarzają.
Student studentowi wszystko
31.05.2021 17:33

14 z 29: pajper

Warto podkreślić, że na razie łatka jest i tak niepełna, bo dotyczy jedynie warstwy klienckiej i jeszcze brak generowania własnego SSL, co sprawia, że łatka ma użytek baaaaardzo ograniczony.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
31.05.2021 17:37

15 z 29: zvonimirek222

@pajper ale chociażby użytkownik wie, że cośtam piszczy, i że jest to na razie w fazie eksperymentalnej.
W tej wersji też został naprawiony błąd między alphami i stabilkami, który powodował milczenie między klientami.
Student studentowi wszystko
31.05.2021 17:56

16 z 29: zvonimirek222

Pull request z tymi zmianami jest tutaj:
https://github.com/NVDARemote/NVDARemote/pull/237
Student studentowi wszystko
31.05.2021 17:58

17 z 29: piter9521

A jak uaktualnić certyfikat na swoim serwerze, żeby się nie plół?

13.07.2021 13:15

18 z 29: pajper

Na chwilę obecną polecam letsencrypta
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
13.07.2021 14:05

19 z 29: piter9521

Dzięki.

13.07.2021 14:06

20 z 29: johnson

Jak ktoś zupdatował do 2021.1 to już remote do najnowszego nvda jest.

13.07.2021 20:44