-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

Kasperski pokazuje 37 podatności w popularnych rozwiązaniach VNC.

23 listopada 2019, 11:59 | W biegu | komentarze 4

Badanie dotyczyło kilku produktów:

  • Biblioteki LibVNC
  • TightVNC 1.X
  • TurboVNC
  • UltraVNC

a w trakcie badania zlokalizowano aż 37 luk (z czego aż 22 w UltraVNC) – większość w części klienckiej. Zaskakuje fakt, że podatności (również klasy buffer overflow) można znaleźć tu wyjątkowo prosto – również w części serwerowej. Zobaczmy np. taki fragment kodu z TurboVNC:

Sprawdzanie długości ciągu, który kopiujemy do bufora jest wprawdzie realizowane, ale dopiero po tym kopiowaniu (!!!). No więc mamy tu stary jak świat stack overflow.

Część zgłoszonych podatności nie jest załatana do teraz (np. w TightVNC), mimo że właściciele projektu otrzymali informację około 10 miesięcy przed planowaną publikacją. Z innej strony pociesza fakt, że prawdopodobnie wszystkie zlokalizowane podatności serwerowe wymagają uwierzytelnienia.

Sprawdźcie w każdym razie czy:

  • zaktualizowaliście swoje oprogramowanie VNC (klienckie / serwerowe)
  • nie udostępniacie anonimowego dostępu po VNC (nawet jeśli później wymagane jest logowanie już w inny sposób) – tutaj zdecydowanie polecane jest ustawienie odpowiednio złożonego hasła

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. User110

    Luzik, podatne protokoły (m. in. RDP, VNC) lecą w tunelu SSH (czytałem i zastosowałem art SSH dla zaawansowanych na stronach Mozilli ;-) ). Nauczyłem też moją wspólniczkę zestawiać połączenie SSH, żeby miała pulpit zdalny do biura.
    U jej znajomych jest tylko ikona na pulpicie do kliknięcia (RDP puszczony w Internet na 3389) i za nic nie dali się przekonać do tunelowania, ale tam jest „mądrzejszy” informatyk.

    Odpowiedz
    • Wojtek

      To ten mądry informatyk niech sprawdzi ruch z Rosją, bo może już są podłączeni. Otwartego RDP’a błyskawicznie wyłapują nawet na wysokich, natowanych portach.

      Odpowiedz
  2. Adam

    TightVNC od dawna jest w wersji 2.x – dlaczego mają łatać starą wersję?

    Odpowiedz
  3. Borygo

    TightVNC 1.X jest od dawna nierozwijany i nawet w tym raporcie przytaczają ten fakt. Rozwijaną wersją jest 2.X a ta nie była badana na podatności.

    Odpowiedz

Odpowiedz na User110