Historia badań i rozwoju w 3 częściach. Część 1 — badania.
Jest wiele buków — jeszcze więcej korzyści.
Sformułowanie zadania
Podczas przeprowadzania testów penetracyjnych i kampanii RedTeam nie zawsze można wykorzystać standardowe narzędzia Klientów, takie jak VPN, RDP, Citrix itd. jako środek do załączenia się do wewnętrznej sieci. Czasami standardowy VPN działa w oparciu o MFA, a jako drugi czynnik jest używany token sprzętowy, gdzie indziej jest on ściśle monitorowany i nasze połączenie przez VPN jest od razu widoczne, jak to mówią — z wszelkimi konsekwencjami, a gdzie indziej takich środków po prostu nie ma.
W takich przypadkach ciągle trzeba tworzyć tzw. «tunel zwrotny» — połączenia z wewnętrznej sieci do zewnętrznego zasobu lub serwera, którym zarządzamy. W obrębie takiego tunelu możemy już pracować z wewnętrznymi zasobami Klientów.
Istnieje kilka rodzajów takich tuneli zwrotnych. Najbardziej znanym z nich jest oczywiście Meterpreter. Wśród hakerskich mas cieszą się również dużym zainteresowaniem tuneli SSH z odwrotnym przekierowaniem portów. Istnieje wiele narzędzi do realizacji tunelowania zwrotnego i wiele z nich jest dobrze poznanych i opisanych.
Oczywiście, ze swojej strony deweloperzy rozwiązań ochronnych nie pozostają obojętni i aktywnie wykrywają takie działania.
Na przykład, sesje MSF są skutecznie wykrywane przez nowoczesne IPS od Cisco lub Positive Tech, a odwrotny tunel SSH można wykryć praktycznie przez każdą, nawet słabą zaporę ogniową.
W związku z tym, aby pozostać niezauważonym w dobrej kampanii RedTeam — musimy budować tunel zwrotny w sposób nietypowy i maksymalnie dostosować się do rzeczywistego trybu działania sieci.
Spróbujmy znaleźć lub wynaleźć coś takiego.
Zanim coś wynaleziemy, musimy zrozumieć, jaki wynik chcemy osiągnąć, jakie funkcje powinna spełniać nasza praca. Jakie będą wymagania dotyczące tunelu, abyśmy mogli działać w trybie maksymalnej ukrytości?
Jasne, że dla każdego przypadku takie wymagania mogą się znacznie różnić, ale na podstawie doświadczenia można wyróżnić kilka podstawowych:
- działanie na systemach Windows 7-10. Ponieważ w większości sieci korporacyjnych używana jest właśnie Windows.
- Klient łączy się z serwerem przez SSL, aby wykluczyć pasywne podsłuchiwanie za pomocą IPS;
- Podczas łączenia klient musi wspierać działanie przez serwer proxy z autoryzacją, ponieważ w wielu firmach dostęp do internetu odbywa się przez proxy. W rzeczywistości maszyna kliencka może o tym nawet nie wiedzieć, a proxy działa w trybie transparentnym. Ale taki funkcjonalność musimy uwzględnić;
- Część kliencka powinna być zwięzła i przenośna;
Jasne jest, że do pracy wewnątrz sieci Klienta na maszynie klienckiej można zainstalować OpenVPN i stworzyć pełnoprawny tunel do własnego serwera (na szczęście klienci OpenVPN potrafią działać przez proxy). Jednak po pierwsze, nie zawsze jest to możliwe, ponieważ możemy nie być lokalnymi administratorami, a po drugie, spowoduje to tyle hałasu, że porządny SIEM czy HIPS natychmiast nas 'zwróci' gdzie trzeba. W idealnym przypadku nasz klient powinien być tzw. inline command, jak na przykład w wielu powłokach bash, i być uruchamiany przez wiersz poleceń, na przykład, przy wykonywaniu poleceń z makra w programie Word. - Nasz tunel musi być wielowątkowy i obsługiwać wiele połączeń jednocześnie;
- Połączenie klient-serwer musi mieć jakąś autoryzację, aby tunel był nawiązywany tylko dla naszego klienta, a nie dla wszystkich, którzy zgłoszą się na nasz serwer pod wskazanym adresem i porcie. W idealnym przypadku dla 'zewnętrznych użytkowników' powinna otwierać się strona docelowa z kotkami lub profesjonalną tematyką związaną z pierwotną domeną.
Na przykład, jeśli Zamawiającym jest organizacja medyczna, to dla administratora bezpieczeństwa informacji, który postanawia sprawdzić zasób, do którego odwoływał się pracownik kliniki, powinna otworzyć się strona z produktami farmaceutycznymi, Wikipedia z opisem diagnozy lub blog doktora Komarowskiego itd.
Analiza istniejących narzędzi
Zanim skonstruujemy własny rower — należy przeprowadzić analizę istniejących rowerów i zrozumieć, czy naprawdę tego potrzebujemy, a być może nie tylko my zastanawiamy się nad koniecznością takiego funkcjonalnego roweru.
Wyszukiwanie w Internecie (wygląda na to, że robimy to dobrze), a także przeszukiwanie GitHub'a pod kątem słów kluczowych „reverse socks” nie przyniosło wielu rezultatów. W zasadzie wszystko sprowadza się do budowy tuneli SSH z odwrotnym przejściem portów i wszystkiego, co z tym związane. Oprócz tuneli SSH, można wyróżnić kilka rozwiązań:
Dawna realizacja odwrotnego tunelu od ekipy z Laboratorium Kaspersky'ego. Z nazwy wynika, do czego służy ten skrypt. Zrealizowany w Pythonie 2.7, tunel działa w trybie cleartext (jak to się teraz mówi — witaj RKN).
Kolejna realizacja w Pythonie, również w cleartext, ale oferująca więcej możliwości. Napisana jako moduł i posiada API do integracji z własnymi projektami.
Pierwszy link — pierwotna wersja realizacji reverse socks w Golangu (nie jest wspierana przez twórcę).
Drugi link — nasza wersja z dodatkowymi funkcjami, również w Golangu. W naszej wersji zrealizowaliśmy SSL, działanie przez proxy z autoryzacją NTLM, autoryzację po stronie klienta, stronę docelową przy błędnym haśle (a właściwie — przekierowanie na stronę docelową), tryb wielowątkowy (tj. z tunelem może pracować kilka osób jednocześnie), system pingów klienta w celu ustalenia, czy jest aktywny.
Realizacja odwrotnego socks od naszych „chińskich przyjaciół” w Pythonie. Dla leniwych i „nieśmiertelnych” przygotowano już gotowy plik binarny (exe), stworzony przez Chińczyków i gotowy do użycia. Tylko jeden chiński bóg wie, co jeszcze może znajdować się w tym binarze, oprócz podstawowej funkcjonalności, więc używaj na własne ryzyko.
Dosyć interesujący projekt w C++ do realizacji odwrotnego socks oraz nie tylko. Oprócz odwrotnego tunelu, może robić przekierowanie portów, tworzenie powłoki poleceniowej itd.
MSF meterpreter
Jak to się mówi, bez komentarzy. Wszyscy półwykształceni hackerzy doskonale znają to narzędzie i rozumieją, jak łatwo jest je wykryć za pomocą środków ochronnych.
Wszystkie wcześniej opisane narzędzia działają na podobnej technologii: na maszynie w sieci uruchamiany jest wcześniej przygotowany plik binarny, który nawiązuje połączenie z zewnętrznym serwerem. Na serwerze uruchamiany jest serwer SOCKS4/5, który akceptuje połączenia i przekazuje je do klienta.
Wadą wszystkich wymienionych narzędzi jest to, że albo na maszynie klienckiej musi być zainstalowany Python lub Golang (ile razy spotkałeś zainstalowanego Pythona na komputerach, na przykład dyrektora firmy lub pracowników biurowych?), albo na tę maszynę trzeba przenosić wcześniej zbudowany plik binarny (de facto python i skrypt w jednym pakiecie) i uruchamiać ten plik już tam. A pobieranie pliku exe i jego późniejsze uruchamianie to niezła sygnatura dla lokalnego programu antywirusowego lub HIPS.
Ogólnie rzecz biorąc, konkluzja nasuwa się sama — potrzebujemy rozwiązania na PowerShell. Teraz spadną na nas pomidory — mówiąc, że PowerShell to już wszystko oklepane, jest monitorowane, blokowane itd. W rzeczywistości — wcale nie wszędzie. Odpowiedzialnie to oświadczamy. Przy okazji, istnieje mnóstwo sposobów, aby obejść blokady (tu znów modna fraza o powitaniu RKZ 🙂), zaczynając od zwykłego zmian nazwy powershell.exe na cmdd.exe, a kończąc na powerdll itd.
Zaczynamy wymyślać
Jasne, że najpierw zerknę w Google i… nie znajdę kompletnie nic na ten temat (jeśli ktoś znalazł — wrzucajcie linki w komentarzach). Jest tylko Socks5 na PowerShell, ale to zwykły „bezpośredni” socks, mający szereg swoich wad (o nich porozmawiamy później). Można oczywiście łatwo przekształcić go w odwrotny, ale to będzie tylko jednowątkowy sock, co nie do końca odpowiada naszym potrzebom.
Zatem, nie znaleźliśmy nic gotowego, więc będziemy musieli sami stworzyć nasz rower. Za podstawę naszego roweru weźmiemy odwrotnego socksa na Golang, a klienta do niego wdrożymy na PowerShell.
RSocksTun
Jak działa rsockstun?
W podstawie działania RsocksTun (dalej w tekście — rs) leżą dwa komponenty programowe — Yamux i serwer Socks5. Serwer Socks5 to zwykły lokalny socks5, uruchamia się po stronie klienta. A multiplexowanie połączeń do niego (pamiętasz o wielowątkowości?) zapewnia yamux (). Taki schemat pozwala na uruchomienie kilku klientów socks5 serwerów i rozdzielanie zewnętrznych połączeń do nich, przeprowadzając je przez jedno jedyne połączenie TCP (prawie jak w meterpreter) od klienta do serwera, realizując tym samym tryb wielowątkowy, bez którego nie będziemy w stanie w pełni funkcjonować w wewnętrznej sieci.
Istota działania yamux polega na wprowadzeniu dodatkowego poziomu sieciowego strumieni, które realizowane są w postaci 12-bajtowego nagłówka dla każdego pakietu. (Tutaj celowo używamy słowa 'strumień', a nie 'wątek', aby nie mylić czytelnika z wątkami programowymi — to pojęcie również będzie używane w tym artykule). Wewnątrz nagłówka yamux znajdują się numer strumienia, flagi do otwierania/zamykania strumienia, liczba przesyłanych bajtów oraz rozmiar okna transmisyjnego.
Poza otwieraniem/zamykaniem strumienia w yamux wprowadzono mechanizm keepalive, który pozwala na monitorowanie sprawności nawiązanej ścieżki komunikacyjnej. Funkcjonowanie mechanizmu wiadomości keepalive jest konfigurowane podczas tworzenia sesji Yamux. W zasadzie z ustawień dostępne są tylko — dwa parametry: włącz/wyłącz oraz częstotliwość wysyłania pakietów w sekundach. Wiadomości keepalive mogą wysyłać zarówno serwer yamux, jak i klient yamux. Po otrzymaniu wiadomości keepalive, strona zdalna ma obowiązek odpowiedzieć na nią pakietem o dokładnie tym samym identyfikatorze wiadomości (de facto — liczby), który została odebrana. Ogólnie rzecz biorąc, keepalive to ten sam ping, tylko dla yamux.
Szczegółowo cała technika działania multipleksera: typy pakietów, flagi otwierania i zamykania połączeń, mechanizmy przesyłania danych opisane są w k yamux.
Podsumowanie pierwszej części
Zatem w pierwszej części artykułu zapoznaliśmy się z pewnym zestawem narzędzi do organizacji tuneli zwrotnych, przyjrzeliśmy się ich zaletom i wadom, zbadaliśmy mechanizm działania multipleksera Yamux oraz opisaliśmy podstawowe wymagania dotyczące nowego modułu PowerShell. W następnej części zajmiemy się opracowaniem samego modułu, praktycznie, od zera. Ciąg dalszy nastąpi. Nie przełączajcie się 🙂
Źródło: habr.com
