Opowieść o badaniach i rozwoju w 3 częściach. Część 1 ma charakter eksploracyjny.
Jest wiele buków - jeszcze więcej korzyści.
Stwierdzenie problemu
Podczas pentestów i kampanii RedTeam nie zawsze możliwe jest wykorzystanie standardowych narzędzi Klienta, takich jak VPN, RDP, Citrix itp. jako kotwica wejścia do sieci wewnętrznej. W niektórych miejscach standardowa sieć VPN działa przy użyciu MFA, a token sprzętowy jest używany jako drugi czynnik, w innych jest brutalnie monitorowany i nasz login VPN od razu staje się widoczny, jak to się mówi, ze wszystkim, co się z tym wiąże, ale w innych po prostu nie ma takich środków.
W takich przypadkach stale musimy wykonywać tzw. „tunele zwrotne” – połączenia z sieci wewnętrznej do zasobu zewnętrznego lub kontrolowanego przez nas serwera. Wewnątrz takiego tunelu możemy już pracować z wewnętrznymi zasobami Klienta.
Istnieje kilka odmian tych tuneli powrotnych. Najbardziej znanym z nich jest oczywiście Meterpreter. Tunele SSH z przekierowaniem portów zwrotnych są również bardzo poszukiwane wśród mas hakerów. Istnieje wiele sposobów wdrażania tunelowania odwrotnego, a wiele z nich zostało dobrze zbadanych i opisanych.
Oczywiście ze swojej strony twórcy rozwiązań bezpieczeństwa nie stoją z boku i aktywnie wykrywają takie działania.
Na przykład sesje MSF są skutecznie wykrywane przez nowoczesny IPS firmy Cisco lub Positive Tech, a odwrotny tunel SSH może zostać wykryty przez prawie każdą zwykłą zaporę ogniową.
Dlatego, aby w dobrej kampanii RedTeam pozostać niezauważonym, musimy zbudować tunel odwrotny przy użyciu niestandardowych środków i dostosować się jak najbliżej rzeczywistego trybu pracy sieci.
Spróbujmy znaleźć lub wymyślić coś podobnego.
Zanim cokolwiek wymyślimy, musimy zrozumieć, jaki wynik chcemy osiągnąć, jakie funkcje ma pełnić nasz rozwój. Jakie będą wymagania dla tunelu, abyśmy mogli pracować w trybie maksymalnego ukrycia?
Oczywiste jest, że w każdym przypadku takie wymagania mogą się znacznie różnić, ale na podstawie doświadczenia zawodowego można zidentyfikować główne:
- pracować na systemie operacyjnym Windows-7-10. Ponieważ większość sieci korporacyjnych korzysta z systemu Windows;
- klient łączy się z serwerem poprzez SSL, aby uniknąć głupiego podsłuchiwania za pomocą ips;
- Podczas łączenia klient musi obsługiwać pracę za pośrednictwem serwera proxy z autoryzacją, ponieważ W wielu firmach dostęp do Internetu odbywa się poprzez serwer proxy. Tak naprawdę maszyna kliencka może nawet nic o tym nie wiedzieć, a serwer proxy używany jest w trybie przezroczystym. Musimy jednak zapewnić taką funkcjonalność;
- część kliencka powinna być zwięzła i przenośna;
Oczywiste jest, że aby pracować w sieci Klienta, możesz zainstalować OpenVPN na komputerze klienckim i stworzyć pełnoprawny tunel do swojego serwera (na szczęście klienci openvpn mogą działać przez proxy). Ale po pierwsze nie zawsze to zadziała, ponieważ możemy nie być tam lokalnymi administratorami, a po drugie, będzie tyle hałasu, że porządny SIEM lub HIPS natychmiast nas „dorzuci”. W idealnym przypadku naszym klientem powinno być tzw. polecenie inline, ponieważ na przykład zaimplementowano wiele powłok bash, które są uruchamiane z wiersza poleceń, na przykład podczas wykonywania poleceń z makra słownego. - 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ł zakładany tylko dla naszego klienta, a nie dla każdego, kto przyjdzie do naszego serwera pod wskazany adres i port. W idealnym przypadku strona docelowa z kotami lub tematami zawodowymi związanymi z pierwotną domeną powinna otwierać się dla „użytkowników zewnętrznych”.
Na przykład, jeśli Klientem jest organizacja medyczna, to dla administratora bezpieczeństwa informacji, który zdecyduje się sprawdzić zasób, do którego uzyskał dostęp pracownik kliniki, stronę z produktami farmaceutycznymi, Wikipedię z opisem diagnozy lub blog doktora Komarowskiego itp. powinien się otworzyć.
Analiza istniejących narzędzi
Zanim wymyślisz na nowo własny rower, musisz przeprowadzić analizę istniejących rowerów i zrozumieć, czy naprawdę go potrzebujemy i prawdopodobnie nie tylko my pomyśleliśmy o potrzebie posiadania tak funkcjonalnego roweru.
Googlowanie w Internecie (wydaje się, że googlujemy normalnie), a także wyszukiwanie na Githubie przy użyciu słów kluczowych „odwrócone skarpetki” nie dało wielu wyników. Zasadniczo wszystko sprowadza się do budowy tuneli ssh z przekierowaniem portów zwrotnych i wszystkim, co jest z tym związane. Oprócz tuneli SSH istnieje kilka rozwiązań:
Wieloletnia implementacja tunelu zwrotnego autorstwa chłopaków z Kaspersky Lab. Nazwa wyjaśnia, do czego przeznaczony jest ten skrypt. Zaimplementowany w Pythonie 2.7 tunel działa w trybie czystego tekstu (jak to się teraz modnie mówi – cześć RKN)
Kolejna implementacja w Pythonie, również w formacie zwykłego tekstu, ale z większymi możliwościami. Jest napisany jako moduł i posiada API umożliwiające integrację rozwiązania z Twoimi projektami.
Pierwszy link to oryginalna wersja implementacji Reverse Sox w Golang (nieobsługiwana przez programistę).
Drugi link to nasza wersja z dodatkowymi funkcjami, również w języku Golang. W naszej wersji zaimplementowaliśmy SSL, pracę poprzez proxy z autoryzacją NTLM, autoryzację na kliencie, stronę docelową w przypadku błędnego hasła (a raczej przekierowanie na stronę docelową), tryb wielowątkowy (czyli kilka osób może jednocześnie pracować z tunelem), system pingowania klienta w celu ustalenia, czy żyje, czy nie.
Implementacja Reverse Sox od naszych „chińskich przyjaciół” w Pythonie. Tam dla leniwych i „nieśmiertelnych” jest gotowy plik binarny (exe), zmontowany przez Chińczyków i gotowy do użycia. Tutaj tylko chiński Bóg wie, co jeszcze może zawierać ten plik binarny oprócz głównej funkcjonalności, więc używaj na własne ryzyko i ryzyko.
Całkiem ciekawy projekt w C++ do implementacji Reverse Sox i nie tylko. Oprócz tunelu zwrotnego może przekierowywać porty, tworzyć powłokę poleceń itp.
miernik MSF
Tutaj, jak mówią, nie ma komentarzy. Wszyscy, mniej lub bardziej wykształceni hakerzy są z tym bardzo zaznajomieni i rozumieją, jak łatwo można je wykryć za pomocą narzędzi bezpieczeństwa.
Wszystkie opisane powyżej narzędzia działają w oparciu o podobną technologię: na maszynie wewnątrz sieci uruchamiany jest wcześniej przygotowany wykonywalny moduł binarny, który nawiązuje połączenie z serwerem zewnętrznym. Na serwerze działa serwer SOCKS4/5, który akceptuje połączenia i przekazuje je do klienta.
Wadą wszystkich powyższych narzędzi jest to, że na komputerze klienckim musi być zainstalowany Python lub Golang (czy często widziałeś Python instalowany na maszynach na przykład dyrektora firmy lub pracownika biurowego?) binarny (właściwie python) należy przeciągnąć na tę maszynę i skrypt w jednej butelce) i uruchomić ten plik binarny, który już tam jest. Pobranie pliku exe, a następnie jego uruchomienie jest także podpisem dla lokalnego programu antywirusowego lub systemu HIPS.
Generalnie wniosek nasuwa się sam – potrzebujemy rozwiązania PowerShell. Teraz polecą na nas pomidory - mówią, że powershell jest już cały zhakowany, jest monitorowany, blokowany itp. i tak dalej. Faktycznie, nie wszędzie. Deklarujemy odpowiedzialnie. Swoją drogą sposobów na ominięcie blokowania jest mnóstwo (tu znów pojawia się modne powiedzenie o hello RKN 🙂), zaczynając od głupiej zmiany nazwy powershell.exe -> cmdd.exe a kończąc na powerdll itp.
Zacznijmy wymyślać
Wiadomo, że najpierw poszukamy w Google i… nic na ten temat nie znajdziemy (jeśli ktoś znalazł, niech wrzuca linki w komentarzach). Jest tylko Socks5 na PowerShell, ale jest to zwykły „bezpośredni” sox, który ma wiele wad (porozmawiamy o nich później). Można oczywiście lekkim ruchem ręki zamienić go na odwrotny, ale będzie to tylko sox jednonitkowy, czyli nie do końca nam potrzebny.
Nie znaleźliśmy więc niczego gotowego, więc nadal będziemy musieli wymyślić koło na nowo. Przyjmiemy jako podstawę naszego roweru Reverse Sox w Golang, a my implementujemy dla niego klienta w PowerShell.
RSocksTun
Jak więc działa rsockstun?
Działanie RsocksTun (zwanego dalej rs) opiera się na dwóch komponentach oprogramowania – serwerze Yamux i Socks5. Serwer Socks5 to zwykły lokalny serwer Socks5, działający na kliencie. A multipleksowanie połączeń z nim (pamiętasz o wielowątkowości?) zapewniane jest za pomocą yamux (). Schemat ten pozwala na uruchomienie kilku serwerów klienckich Socks5 i dystrybucję do nich połączeń zewnętrznych, przekazywanie ich przez jedno połączenie TCP (prawie jak w liczniku) od klienta do serwera, wdrażając w ten sposób tryb wielowątkowy, bez którego po prostu się nie obejdziemy w stanie w pełni pracować w sieciach wewnętrznych.
Istota działania Yamux polega na tym, że wprowadza dodatkową warstwę sieciową strumieni, implementując ją w postaci 12-bajtowego nagłówka dla każdego pakietu. (Tutaj celowo używamy słowa „strumień”, a nie wątek, aby nie pomylić czytelnika z „wątkiem” strumienia programu - tym pojęciem będziemy się również posługiwać w tym artykule). Nagłówek Yamux zawiera numer strumienia, flagi instalacji/zakończenia strumienia, liczbę przesłanych bajtów i rozmiar okna przesyłania.
Oprócz instalowania/kończenia strumienia, Yamux implementuje mechanizm utrzymywania aktywności, który pozwala monitorować wydajność ustanowionego kanału komunikacyjnego. Działanie mechanizmu komunikatów KeepLive konfiguruje się podczas tworzenia sesji Yamux. Właściwie w ustawieniach są tylko dwa parametry: włączenie/wyłączenie i częstotliwość wysyłania pakietów w sekundach. Wiadomości Keepalive mogą być wysyłane przez serwer Yamux lub klienta Yamux. Odbierając wiadomość podtrzymującą, strona zdalna musi na nią odpowiedzieć, wysyłając dokładnie ten sam identyfikator wiadomości (właściwie liczbę), który otrzymała. Ogólnie rzecz biorąc, keepalive to ten sam ping, tylko dla Yamux.
Całą technikę działania multipleksera: rodzaje pakietów, flagi zestawiania i terminacji połączeń oraz mechanizm przesyłania danych szczegółowo opisano w do Yamuxa.
Podsumowanie części pierwszej
Tak więc w pierwszej części artykułu zapoznaliśmy się z niektórymi narzędziami do organizacji tuneli zwrotnych, przyjrzeliśmy się ich zaletom i wadom, przestudiowaliśmy mechanizm działania multipleksera Yamux i opisaliśmy podstawowe wymagania dla nowo utworzonego modułu PowerShell. W dalszej części będziemy rozwijać sam moduł, praktycznie od zera. Ciąg dalszy nastąpi. Nie przełączaj :)
Źródło: www.habr.com