- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
14 stycznia 2020 Microsoft opublikował pierwszy w bieżącym roku zestaw poprawek bezpieczeństwa (Patch Tuesday) dla swoich produktów. Lista załatanych podatności składa się z 49 pozycji, z których osiem ma status krytyczne, a pozostałe zostały uznane za ważne.
Na liście znalazły się dwie krytyczne podatności dotyczące usługi Remote Desktop (zdalnego pulpitu). Mowa tu o podatnościach CVE-2020-0609 oraz CVE-2020-0610. Obie pozwalają na zdalne wykonanie kodu na serwerze RDG (Remote Desktop Gateway).
Czym jest Remote Desktop Gateway?
Remote Desktop Gateway (wcześniej znany pod nazwą Terminal Services Gateway) jest serwerem, na którym działa oprogramowanie z linii Windows Server. Jego zadaniem jest zapewnienie rutingu dla ruchu w protokole RDP (Remote Desktop Protocol). Protokół RDP jest protokołem pozwalającym użytkownikowi na zdalny dostęp przy pomocy graficznego interfejsu do innej maszyny. Podstawowy schemat działania polega na tym, że użytkownik łączy się przy użyciu oprogramowania klienckiego do serwera RDP. Aby tego typu serwer nie był osiągalny bezpośrednio z sieci Internet stosuje się bardzej złożony schemat połączenia, który zakłada, że zamiast łączyć się bezpośredno do serwera RDP, użytkownik łączy się do serwera RDG. Tam też dokonywane jest uwierzytelnianie. Pomyślne przejście tego procesu powoduje przekazywanie ruchu do konkretnego serwera, z którym chce się połączyć klient. Dzięki takiemu podejściu tylko serwer RDG musi być publiczne osiągalny z Internetu. Zmniejsza to więc powierzchnię ataku.
Standardowym sposobem komunikacji z serwerem RDG jest komunikacja przy użyciu protokołu TCP w warstwie transportu oraz tunelowanie ruchu RDP przez kanał wykorzystujący HTTPS (domyślnie na porcie 443). Protokół TLS zapewnia w ten sposób szyfrowanie danych. Poczynając od Windows Server 2012 pojawiła się nowa możliwość komunikacji przy użyciu protokołu UDP w warstwie transportu. Domyślnym portem dla tego typu połączeń jest port 3391. Także i w tym przypadku konieczne było szyfrowanie ruchu, co zostało zapewnione przy wykorzystaniu protokołu DTLS (Datagram Transport Layer Security). Wykorzystanie protokołu UDP znacznie przyspiesza komunikację, co można zaobserwować między innymi podczas strumieniowania materiałów wideo.
Na czym polega problem?
W związku z wymienionymi wyżej podatnościami, wysłanie specjalnie spreparowanych zapytań do serwera RDG pozwala wykonać dowolny kod na atakowanym serwerze. Atakujący może w ten sposób między innymi odczytać, zapisać, zmienić i usuwać dane znajdujące się na urządzeniu, instalować nowe oprogramowanie, czy też tworzyć nowe konta użytkowników z pełnymi uprawnieniami na serwerze RDG. Podatności te nie wymagają uwierzytelnienia oraz interakcji ze strony użytkownika. Aktualizacja przygotowana przez Microsoft rozwiązuje ten problem.
Analiza zagrożenia
Dokładny opis na czym polegają podatności CVE-2020-0609 oraz CVE-2020-0610 można znaleźć w analizie zamieszczonej przez portal Kryptos Logic.
Wspomniana analiza wskazuje na to, że podatność była zlokalizowana w funkcji odpowiedzialnej za obsługę ruchu w protokole UDP. Serwery RDG wykorzystujące UDP zapewniają możliwość podziału długich zapytań na mniejsze i umieszczenie ich w oddzielnych datagramach UDP, które mogą docierać do nich w dowolnej kolejności. Funkcja odpowiedzialna za obsługę ruchu UDP ma za zadanie scalić te fragmenty w jedno zapytanie i umieścić je w prawidłowej kolejności. Aby było to możliwe każdy z datagramów zawiera informacje dotyczące pozycji danego fragmentu w zapytaniu, całkowitej liczby fragmentów składających się na zapytanie czy długości danych wchodzących w skład danego fragmentu.
Jedna z omawianych podatności dotyczy niepoprawnego sprawdzania zakresu miejsca zaalokowanego w buforze dla danego zapytania przed umieszczeniem tam kolejnego fragmentu. Mamy tu do czynienia z podatnością typu heap overflow. W tym przypadku jest ona na tyle elastyczna, że pozwala na dokładną kontrolę miejsca, w którym zostaną zapisane dane należące do fragmentu, a nie tylko na kontrolę rozmiaru zapisywanych danych.
Druga z podatności wykorzystuje wadliwy sposób odnotowywania faktu otrzymania fragmentu zapytania. Tablica przechowująca flagi odnotowujące otrzymanie fragmentu ma ustaloną liczbę pozycji, natomiast atakujący ma możliwość wysłania datagramu z dowolnie ustawioną wartością pozycji danego fragmentu. W ten sposób jest w stanie ustawić wartość 1 (true), która odpowiada 32-bitowej liczbie całkowitej bez znaku, w dowolnym miejscu poza tą tablicą.
Obserwacja ruchu
W ramach naszej działalności rozwijany jest projekt pozwalający obserwować ruch sieciowy trafiający do darknetu (network telescope). Darknetem nazywamy nieużywaną pulę adresów IP, do której w teorii nie powinien być kierowany żaden ruch sieciowy. W praktyce możemy jednak zaobserwować ruch wygenerowany przez oprogramowanie skanujące Internet czy też dystrybuujące malware. Oznacza to, że tego typu ruch należy uznać przynajmniej za podejrzany, bądź też złośliwy.
Poniższy wykres pokazuje liczbę zebranych pakietów w 12 godzinnych okresach dla UDP na porcie 3391. Dane dotyczą okresu od 15.12.2019 do 25.01.2019.
Na wykresie widzimy nagły, gwałtowny wzrost liczby zebranych pakietów zanotowany 10 stycznia. Następnie począwszy od 15 stycznia następuje wzrost liczby zebranych pakietów, który utrzymuje się na wysokim poziomie już do końca monitorowanego okresu. Przypomnijmy, że oficjalna informacja o podatnościach została opublikowana przez Microsoft 14 stycznia.
Także w jednym z naszych honeypotów odnotowaliśmy analogiczną zależność w ilości zbieranych logów w analizowanym okresie dla protokołu UDP na porcie 3391. Wspomniany honeypot pozwala na zautomatyzowane wykrywanie rodzaju protokołu warstwy aplikacji, w którym przychodzi połączenie. Wykrytym protokołem dla tych logów jest protokół DTLS, co jest zgodne z oczekiwaniami.
Kolejny wykres zawiera liczbę unikalnych adresów IP odnotowanych w kolejnych 12 godzinnych okresach. Widzimy znaczny ich wzrost od momentu opublikowania informacji o podatności. Nie odnotowaliśmy natomiast wzrostu liczby unikalnych adresów IP 10 stycznia w porównaniu do poprzedzającego okresu. Oznacza to, że pakiety te musiały zostać wysłane z niewielkiej liczby źródeł.
Poniższy wykres przedstawia ruch wygenerowany 10 stycznia w godzinach 00:00 – 12:00. Tak jak przypuszczaliśmy pochodzi on głównie z jednego adresu IP (83.97.20.46).
Przyjrzyjmy się dokładniej okresowi rozpoczynającemu się w momencie opublikowania przez Microsoft informacji od podatnościach. Na poniższym wykresie możemy zobaczyć rozkład liczby unikalnych adresów IP na bazie kraju, z którego pochodzą. Widzimy, że zdecydowanie największa ich liczba pochodzi z Chin.
Omawiana podatność dotyczy serwera RDG i protokołu UDP. Warto jednak też zwrócić uwagę na statystyki ruchu sieciowego dla protokołu RDP, który działa standardowo na porcie 3389 TCP. Poniższy wykres przedstawia liczbę zebranych pakietów w 12 godzinnych okresach dla TCP na porcie 3389. Dane dotyczą okresu od 15.12.2019 do 25.01.2019. Odnotowaliśmy znaczny wzrost liczby pakietów, który rozpoczyna się 13 stycznia, a więc dzień przed oficjalną informacją, a kończy 15 stycznia. Można przypuszczać, że ten wzrost liczby skanowań jest spowodowany tym, że informacja o podatności dotyczącej usługi Remote Desktop była znana już wcześniej. Natomiast nie było wiadomo, że chodzi dokładnie o Remote Desktop Gateway. Stąd też spadek liczby skanowań dla RDP po opublikowaniu oficjalnej informacji.
Nie odnotowaliśmy zmian liczby unikalnych adresów IP w kolejnych 12 godzinnych okresach dla portu 3389 TCP. Zostało to przedstawione na kolejnym wykresie.
Zagrożone systemy
Podatność CVE-2020-0609 oraz CVE-2020-0610 dotyczy systemów:
Ze względu na fakt, że podatność dotyczyła obsługi ruchu UDP, która została wprowadzona wraz w Windows Server 2012, podatność nie dotyczy poprzednich wersji.
Rekomendacje
Zespół CERT Polska zwraca uwagę na konieczność pilnej aktualizacji wyżej wymienionych systemów. W przypadku, gdy nie jest to możliwe zalecamy wyłączenie możliwości używania przez serwer RDG protokołu UDP. Rozwiązaniem może być też ustawienie reguły na firewallu blokującej ruch UDP na porcie używanym przez serwer RDG (domyślnie port 3391).
Źródło: https://www.kryptoslogic.com/blog/2020/01/rdp-to-rce-when-fragmentation-goes-wrong
