1. Wprowadzenie
Firmy, które nie posiadały systemów zdalnego dostępu, kilka miesięcy temu wdrożyły je w trybie awaryjnym. Nie wszyscy administratorzy byli gotowi na takie „gorączki”, w efekcie luki w zabezpieczeniach: błędna konfiguracja usług czy nawet instalacja nieaktualnych wersji oprogramowania z wykrytymi wcześniej lukami. Niektóre z tych zaniedbań już wróciły jak bumerang, inne miały więcej szczęścia, ale zdecydowanie każdy powinien wyciągnąć wnioski. Lojalność wobec pracy zdalnej wzrosła, a coraz więcej firm na bieżąco akceptuje pracę zdalną jako akceptowalny format.
Istnieje więc wiele opcji zapewniania zdalnego dostępu: różne sieci VPN, RDS i VNC, TeamViewer i inne. Administratorzy mają w czym wybierać, w zależności od specyfiki budowy sieci korporacyjnej i urządzeń w niej zawartych. Rozwiązania VPN pozostają najpopularniejsze, jednak wiele małych firm wybiera RDS (Remote Desktop Services), są one łatwiejsze i szybsze do wdrożenia.
W tym artykule porozmawiamy więcej o bezpieczeństwie RDS. Zróbmy krótki przegląd znanych luk, a także rozważmy kilka scenariuszy przeprowadzenia ataku na infrastrukturę sieciową opartą na Active Directory. Mamy nadzieję, że nasz artykuł pomoże komuś w pracy nad błędami i poprawie bezpieczeństwa.
2. Najnowsze luki RDS/RDP
Każde oprogramowanie zawiera błędy i luki, które są wykorzystywane przez atakujących, a RDS nie jest wyjątkiem. Ostatnio Microsoft często zgłaszał nowe luki w zabezpieczeniach, postanowiliśmy je krótko omówić:
Ta luka w zabezpieczeniach naraża użytkowników łączących się z zaatakowanym serwerem. Osoba atakująca może przejąć kontrolę nad urządzeniem użytkownika lub zdobyć przyczółek w systemie w celu uzyskania stałego zdalnego dostępu.
- / /
Ta grupa luk umożliwia nieautoryzowanemu atakującemu zdalne wykonanie dowolnego kodu na serwerze RDS przy użyciu specjalnie spreparowanego żądania. Mogą być również wykorzystywane do tworzenia robaków — złośliwego oprogramowania, które samodzielnie infekuje urządzenia znajdujące się w pobliżu sieci. W związku z tym luki te mogą zagrozić całej sieci firmy i tylko terminowa aktualizacja może je przed nimi uchronić.
Oprogramowanie do zdalnego dostępu cieszy się coraz większym zainteresowaniem zarówno badaczy, jak i osób atakujących, więc wkrótce możemy usłyszeć o większej liczbie takich luk.
Dobrą wiadomością jest to, że nie wszystkie luki mają dostępne publiczne exploity. Złe jest to, że atakującemu z doświadczeniem nie będzie trudno napisać exploita na lukę zgodnie z opisem lub przy użyciu technik takich jak Patch Diffing (nasi koledzy pisali o tym w ). Dlatego zalecamy regularne aktualizowanie oprogramowania i monitorowanie pojawiania się nowych wiadomości o wykrytych lukach.
3. Ataki
Przechodzimy do drugiej części artykułu, w której pokażemy jak rozpoczynają się ataki na infrastrukturę sieciową opartą na Active Directory.
Opisane metody dotyczą następującego modelu atakującego: atakujący posiadający konto użytkownika i dostęp do Remote Desktop Gateway – serwera terminali (często dostępnego np. z sieci zewnętrznej). Dzięki zastosowaniu tych metod atakujący będzie mógł kontynuować atak na infrastrukturę i skonsolidować swoją obecność w sieci.
Konfiguracja sieci w każdym przypadku może się różnić, ale opisane techniki są dość uniwersalne.
Przykłady wyjścia z ograniczonego środowiska i podniesienia uprawnień
Podczas uzyskiwania dostępu do bramy usług pulpitu zdalnego osoba atakująca prawdopodobnie napotka ograniczone środowisko. Po podłączeniu do serwera terminali uruchamiana jest na nim aplikacja: okno do łączenia za pośrednictwem protokołu Remote Desktop dla zasobów wewnętrznych, Eksploratora, pakietów biurowych lub dowolnego innego oprogramowania.
Celem atakującego będzie uzyskanie dostępu do wykonywania poleceń, czyli uruchomienia cmd lub powershell. Może w tym pomóc kilka klasycznych technik ucieczki z piaskownicy systemu Windows. Rozważmy je dalej.
opcja 1. Osoba atakująca ma dostęp do okna połączenia pulpitu zdalnego w ramach bramy pulpitu zdalnego:
Otworzy się menu „Pokaż opcje”. Pojawią się opcje manipulowania plikami konfiguracyjnymi połączenia:
Z tego okna możliwy jest swobodny dostęp do Eksploratora poprzez naciśnięcie dowolnego przycisku „Otwórz” lub „Zapisz”:
Zostanie otwarty Eksplorator. Jego „pasek adresu” umożliwia uruchamianie dozwolonych plików wykonywalnych, a także wyświetlanie listy systemu plików. Może to być przydatne dla atakującego, gdy dyski systemowe są ukryte i nie można uzyskać do nich bezpośredniego dostępu:
→
Podobny scenariusz można odtworzyć np. w przypadku używania Excela jako oprogramowania zdalnego z pakietu Microsoft Office.
→
Ponadto nie zapomnij o makrach używanych w tym pakiecie biurowym. Nasi koledzy odnieśli się w tym do kwestii bezpieczeństwa makr .
opcja 2. Korzystając z tych samych danych wejściowych, co w poprzedniej wersji, atakujący uruchamia wiele połączeń zdalnego pulpitu w ramach tego samego konta. Podczas ponownego łączenia pierwszy zostanie zamknięty, a na ekranie pojawi się okno powiadomienia o błędzie. Przycisk pomocy w tym oknie wywoła Internet Explorera na serwerze, po czym atakujący może przejść do Eksploratora.
→
opcja 3. Przy skonfigurowanych ograniczeniach uruchamiania plików wykonywalnych osoba atakująca może napotkać sytuację, w której zasady grupy uniemożliwiają administratorowi uruchomienie cmd.exe.
Można to obejść, uruchamiając plik nietoperza na zdalnym pulpicie z zawartością taką jak cmd.exe /K <polecenie>. Błąd podczas uruchamiania cmd i udany przykład wykonania pliku bat pokazano na poniższym rysunku.
opcja 4. Zakaz uruchamiania aplikacji korzystających z czarnych list po nazwie plików wykonywalnych nie jest panaceum, można je obejść.
Rozważmy następujący scenariusz: odmówiliśmy dostępu do wiersza poleceń, uniemożliwiliśmy uruchomienie Internet Explorera i PowerShell przy użyciu zasad grupy. Atakujący próbuje wezwać pomoc - brak odzewu. Próby uruchomienia powershella poprzez menu kontekstowe okna modalnego, wywoływane z wciśniętym klawiszem Shift - komunikat o zakazie uruchamiania przez administratora. Próbuje uruchomić PowerShell za pomocą paska adresu - znowu brak odpowiedzi. Jak ominąć ograniczenie?
Wystarczy skopiować powershell.exe z folderu C:WindowsSystem32WindowsPowerShellv1.0 do folderu użytkownika, zmienić nazwę na inną niż powershell.exe i pojawi się uruchomienie.
Domyślnie podczas łączenia się ze zdalnym pulpitem zapewniony jest dostęp do lokalnych dysków klienta, skąd atakujący może skopiować powershell.exe i uruchomić go po zmianie nazwy.
→
Podaliśmy tylko kilka sposobów na ominięcie ograniczeń, scenariuszy jest znacznie więcej, ale wszystkie łączy dostęp do Eksploratora Windows. Istnieje wiele aplikacji korzystających ze standardowych narzędzi do manipulacji plikami systemu Windows, a po umieszczeniu w ograniczonym środowisku można zastosować podobne techniki.
4. Zalecenia i wnioski
Jak widać, nawet w ograniczonym środowisku jest miejsce na rozwój ataku. Możliwe jest jednak skomplikowanie życia atakującemu. Podajemy ogólne zalecenia, które będą przydatne zarówno w rozważanych przez nas opcjach, jak iw innych przypadkach.
- Ogranicz uruchamianie programów za pomocą czarnych / białych list za pomocą zasad grupy.
Jednak w większości przypadków nadal możliwe jest uruchomienie kodu. Zachęcamy do zapoznania się z projektem zorientować się w nieudokumentowanych sposobach manipulowania plikami i wykonywania kodu w systemie.
Zalecamy połączenie obu typów ograniczeń: na przykład możesz zezwolić na uruchamianie plików wykonywalnych podpisanych przez Microsoft, ale ograniczyć uruchamianie cmd.exe. - Wyłącz karty ustawień Internet Explorera (można to zrobić lokalnie w rejestrze).
- Wyłącz wbudowaną pomoc systemu Windows za pomocą regedit.
- Wyłącz możliwość montowania dysków lokalnych dla połączeń zdalnych, jeśli takie ograniczenie nie jest krytyczne dla użytkowników.
- Ogranicz dostęp do dysków lokalnych maszyny zdalnej, pozostaw dostęp tylko do folderów użytkownika.
Mamy nadzieję, że byłeś przynajmniej zainteresowany, a maksymalnie ten artykuł pomoże uczynić zdalną pracę Twojej firmy bezpieczniejszą.
Źródło: www.habr.com