Ten artykuł został napisany w oparciu o bardzo udany pentest przeprowadzony kilka lat temu przez specjalistów Group-IB: wydarzyła się historia, którą można było zaadaptować na potrzeby filmu w Bollywood. Teraz prawdopodobnie reakcja czytelnika będzie następująca: „Och, kolejny artykuł PR, znowu je przedstawiają, jakie są dobre, nie zapomnij kupić pentestu”. Cóż, z jednej strony tak. Istnieje jednak wiele innych powodów, dla których pojawił się ten artykuł. Chciałem pokazać, czym dokładnie zajmują się pentesterzy, jak ciekawa i niebanalna może być ta praca, jakie śmieszne okoliczności mogą zaistnieć w projektach, a co najważniejsze, pokazać materiał na żywo na prawdziwych przykładach.
Aby przywrócić równowagę skromności na świecie, za jakiś czas napiszemy o penteście, który nie wypadł najlepiej. Pokażemy, jak dobrze zaprojektowane procesy w firmie mogą chronić przed całą gamą ataków, nawet dobrze przygotowanych, po prostu dlatego, że te procesy istnieją i faktycznie działają.
Dla klienta w tym artykule wszystko było ogólnie doskonałe, według naszych odczuć co najmniej lepsze niż 95% rynku w Federacji Rosyjskiej, ale było wiele drobnych niuansów, które utworzyły długi łańcuch wydarzeń, który najpierw doprowadziło do obszernego raportu z pracy, a następnie do tego artykułu.
Zaopatrzmy się więc w popcorn i zapraszamy do kryminału. Słowo - Paweł Suprunyuk, kierownik techniczny działu „Audyt i doradztwo” Group-IB.
Część 1. Lekarz Poczkina
2018 Jest klient – zaawansowana technologicznie firma informatyczna, która sama obsługuje wielu klientów. Chce uzyskać odpowiedź na pytanie: czy można bez wstępnej wiedzy i dostępu, pracując przez Internet, uzyskać uprawnienia administratora domeny Active Directory? Nie interesuje mnie żadna inżynieria społeczna (), nie mają zamiaru celowo zakłócać pracy, ale mogą przez przypadek - np. przeładować dziwnie działający serwer. Dodatkowym celem jest zidentyfikowanie jak największej liczby innych wektorów ataku na obwód zewnętrzny. Firma regularnie przeprowadza takie testy, a teraz nadszedł termin nowego testu. Warunki są niemal typowe, odpowiednie, zrozumiałe. Zacznijmy.
Jest tam nazwa klienta - niech będzie to „Firma” z główną stroną internetową . Oczywiście klienta nazywa się inaczej, ale w tym artykule wszystko będzie bezosobowe.
Prowadzę rekonesans sieci - dowiaduję się, jakie adresy i domeny są zarejestrowane u klienta, rysuję schemat sieci, w jaki sposób usługi są dystrybuowane pod te adresy. Otrzymuję wynik: ponad 4000 aktywnych adresów IP. Przyglądam się domenom w tych sieciach: na szczęście zdecydowana większość to sieci przeznaczone dla klientów klienta i formalnie nie jesteśmy nimi zainteresowani. Klient myśli tak samo.
Pozostaje jedna sieć z 256 adresami, dla której na ten moment jest już rozeznanie w rozkładzie domen i subdomen według adresów IP, jest informacja o przeskanowanych portach, co oznacza, że można szukać w usługach interesujących. Równolegle uruchamiane są wszelkiego rodzaju skanery na dostępnych adresach IP oraz osobno na stronach internetowych.
Istnieje wiele usług. Zwykle jest to dla pentestera radość i oczekiwanie szybkiego zwycięstwa, gdyż im więcej jest usług, tym większe jest pole ataku i łatwiej jest znaleźć artefakt. Szybki rzut oka na strony internetowe pokazał, że większość z nich to interfejsy internetowe znanych produktów dużych światowych firm, które z pozoru mówią, że nie są mile widziane. Proszą o nazwę użytkownika i hasło, wytrząsają pole do wpisania drugiego czynnika, proszą o certyfikat klienta TLS lub wysyłają go do Microsoft ADFS. Do niektórych z nich po prostu nie można dotrzeć z Internetu. Dla niektórych oczywiście musisz mieć specjalnego płatnego klienta za trzy pensje lub znać dokładny adres URL, który należy wprowadzić. Pomińmy kolejny tydzień stopniowego przygnębienia podczas prób „przełamania” wersji oprogramowania pod kątem znanych luk, wyszukiwania ukrytych treści w ścieżkach internetowych i kont, które wyciekły z usług stron trzecich, takich jak LinkedIn, a także prób odgadnięcia haseł za ich pomocą jak wykrywanie luk w samodzielnie pisanych witrynach internetowych — nawiasem mówiąc, według statystyk jest to obecnie najbardziej obiecujący wektor ataku zewnętrznego. Od razu zwrócę uwagę na pistolet filmowy, który następnie wystrzelił.
Znaleźliśmy więc dwie witryny, które wyróżniały się spośród setek usług. Strony te miały jedną wspólną cechę: jeśli nie przeprowadzisz szczegółowego rekonesansu sieci według domeny, ale będziesz szukać otwartych portów lub użyjesz skanera podatności na ataki przy użyciu znanego zakresu adresów IP, wówczas witryny te unikną skanowania i po prostu nie zostaną widoczne bez znajomości nazwy DNS. Być może przynajmniej przeoczyli je wcześniej, a nasze automatyczne narzędzia nie znalazły z nimi żadnych problemów, nawet jeśli zostały wysłane bezpośrednio do zasobu.
Nawiasem mówiąc, o tym, co ogólnie znalazły wcześniej uruchomione skanery. Przypomnę: dla niektórych osób „pentest” jest równoznaczny z „automatycznym skanowaniem”. Ale skanery w tym projekcie nic nie wykazały. Cóż, maksimum wykazały średnie luki (3 z 5 pod względem ważności): w niektórych usługach zły certyfikat TLS lub przestarzałe algorytmy szyfrowania, a w większości witryn Clickjacking. Ale to nie doprowadzi Cię do celu. Być może bardziej przydałyby się tutaj skanery, ale przypomnę: klient sam jest w stanie takie programy kupić i przetestować się z nimi, a sądząc po fatalnych wynikach, już to sprawdził.
Wróćmy do stron „anomalnych”. Pierwsza to coś w rodzaju lokalnej Wiki pod niestandardowym adresem, ale w tym artykule niech będzie to wiki.firma[.]ru. Od razu też poprosiła o login i hasło, ale poprzez NTLM w przeglądarce. Dla użytkownika wygląda to jak ascetyczne okno z prośbą o podanie nazwy użytkownika i hasła. I to jest zła praktyka.
Mała uwaga. NTLM w witrynach obwodowych jest zły z wielu powodów. Pierwszym powodem jest ujawnienie nazwy domeny Active Directory. W naszym przykładzie okazało się, że jest to również firma.ru, podobnie jak „zewnętrzna” nazwa DNS. Wiedząc o tym, możesz starannie przygotować coś złośliwego, tak aby zostało wykonane tylko na komputerze domeny organizacji, a nie w jakimś piaskownicy. Po drugie, uwierzytelnianie przechodzi bezpośrednio przez kontroler domeny poprzez NTLM (niespodzianka, prawda?), ze wszystkimi funkcjami „wewnętrznych” zasad sieciowych, w tym blokowaniem kont przed przekroczeniem liczby prób wprowadzenia hasła. Jeżeli atakujący odnajdzie loginy, spróbuje podać dla nich hasła. Jeśli skonfigurowano blokowanie wprowadzania nieprawidłowych haseł przez konta, będzie to działać, a konto zostanie zablokowane. Po trzecie, do takiego uwierzytelnienia nie można dodać drugiego czynnika. Jeśli ktoś z czytelników jeszcze wie, jak to zrobić, proszę dać mi znać, to naprawdę interesujące. Po czwarte, podatność na ataki typu pass-the-hash. ADFS został wynaleziony między innymi po to, aby przed tym wszystkim chronić.
Produkty Microsoftu mają jedną wadę: nawet jeśli nie opublikowałeś specjalnie takiego protokołu NTLM, zostanie on domyślnie zainstalowany przynajmniej w programach OWA i Lync.
Nawiasem mówiąc, autor tego artykułu pewnego razu przypadkowo zablokował około 1000 kont pracowników jednego dużego banku w ciągu zaledwie godziny przy użyciu tej samej metody, po czym wyglądał nieco blado. Obsługa informatyczna banku również wypadła blado, ale wszystko zakończyło się dobrze i należycie, nawet chwalono nas, że jako pierwsi odkryliśmy ten problem i sprowokowaliśmy szybkie i zdecydowane rozwiązanie.
Druga strona miała adres „oczywiście jakieś nazwisko.firma.ru”. Znalazłem to w Google, coś takiego na stronie 10. Projekt pochodził z początku połowy XNUMX roku i szanowana osoba oglądała go ze strony głównej, mniej więcej tak:
Tutaj zrobiłem kadr z „Serce psa”, ale wierzcie mi, było trochę podobne, nawet kolorystyka była w podobnej tonacji. Niech witryna zostanie wywołana preobrazhensky.company.ru.
To była osobista strona internetowa... urologa. Zastanawiałem się, co robi witryna urologa w subdomenie firmy z branży zaawansowanych technologii. Szybkie sprawdzenie Google wykazało, że ten lekarz był współzałożycielem jednej z osób prawnych naszego klienta i wniósł nawet około 1000 rubli na kapitał zakładowy. Strona powstała prawdopodobnie wiele lat temu, a zasoby serwera Klienta posłużyły jako hosting. Strona już dawno straciła na znaczeniu, ale z jakiegoś powodu działała przez długi czas.
Pod względem luk sama witryna była bezpieczna. Patrząc w przyszłość powiem, że był to zbiór informacji statycznych - prostych stron html z wstawionymi ilustracjami w postaci nerek i pęcherzy. Nie ma sensu „łamać” takiej witryny.
Ale serwer WWW pod spodem był bardziej interesujący. Sądząc po nagłówku serwera HTTP, miał on IIS 6.0, co oznacza, że używał systemu operacyjnego Windows 2003. Skaner wykrył wcześniej, że ta konkretna witryna internetowa urologa, w odróżnieniu od innych wirtualnych hostów na tym samym serwerze internetowym, odpowiedziała na polecenie PROPFIND, co oznaczało, że działała usługa WebDAV. Nawiasem mówiąc, skaner zwrócił tę informację ze znakiem Info (w języku raportów skanera jest to najniższe niebezpieczeństwo) - takie rzeczy są zwykle po prostu pomijane. W sumie dało to ciekawy efekt, który został ujawniony dopiero po kolejnym wykopaniu w Google: rzadka luka w zabezpieczeniach związana z przepełnieniem bufora związana z zestawem Shadow Brokers, a mianowicie CVE-2017-7269, która miała już gotowy exploit. Innymi słowy, jeśli masz system Windows 2003 i protokół WebDAV działa w IIS, wystąpią problemy. Chociaż uruchomienie produkcyjnego systemu Windows 2003 w 2018 roku jest problemem samym w sobie.
Exploit trafił do Metasploit i został natychmiast przetestowany z obciążeniem, które wysłało żądanie DNS do kontrolowanej usługi – do przechwytywania żądań DNS tradycyjnie używany jest Burp Collaborator. Ku mojemu zdziwieniu zadziałało za pierwszym razem: otrzymano nokaut DNS. Następnie nastąpiła próba utworzenia połączenia zwrotnego przez port 80 (czyli połączenie sieciowe serwera z atakującym z dostępem do cmd.exe na hoście ofiary), ale potem doszło do fiaska. Połączenie nie nastąpiło, a po trzeciej próbie skorzystania ze strony, wraz ze wszystkimi ciekawymi zdjęciami, zniknęło bezpowrotnie.
Zwykle po tym następuje list w stylu „kliencie, obudź się, rzuciliśmy wszystko”. Powiedziano nam jednak, że witryna nie ma nic wspólnego z procesami biznesowymi i działa tam bez powodu, podobnie jak cały serwer, i że możemy korzystać z tego zasobu, jak nam się podoba.
Mniej więcej dzień później witryna nagle zaczęła działać samodzielnie. Po zbudowaniu ławki z WebDAV w IIS 6.0 odkryłem, że domyślnym ustawieniem jest ponowne uruchamianie procesów roboczych IIS co 30 godzin. Oznacza to, że gdy kontrola opuściła kod powłoki, proces roboczy IIS zakończył się, następnie kilka razy uruchomił się ponownie, a następnie przeszedł w stan spoczynku na 30 godzin.
Ponieważ połączenie wsteczne z TCP nie powiodło się za pierwszym razem, przypisałem ten problem zamkniętemu portowi. Oznacza to, że założył obecność jakiejś zapory ogniowej, która nie pozwalała na przechodzenie połączeń wychodzących na zewnątrz. Zacząłem uruchamiać kody powłoki, które przeszukiwały wiele portów TCP i UDP, nie było żadnego efektu. Ładowanie połączenia zwrotnego przez http(s) z Metasploit nie działało -meterpreter/reverse_http(s). Nagle nawiązano połączenie z tym samym portem 80, ale natychmiast je zerwano. Przypisałem to działaniu wciąż wyimaginowanego IPS-a, który nie lubił ruchu licznikowego. W świetle faktu, że nie nastąpiło połączenie czystego protokołu TCP z portem 80, ale połączenie http tak, doszedłem do wniosku, że w systemie w jakiś sposób skonfigurowano serwer proxy http.
Próbowałem nawet Meterpretera przez DNS (dzięki za twoje wysiłki, uratowałeś wiele projektów), przypominając sobie pierwszy sukces, ale nawet na stojaku nie zadziałał - kod powłoki był zbyt obszerny dla tej luki.
W rzeczywistości wyglądało to tak: 3-4 próby ataków w ciągu 5 minut, potem czekanie 30 godzin. I tak przez trzy tygodnie z rzędu. Ustawiłem nawet przypomnienie, żeby nie tracić czasu. Dodatkowo istniała różnica w zachowaniu środowiska testowego i produkcyjnego: dla tej luki istniały dwa podobne exploity, jeden z Metasploit, drugi z Internetu, skonwertowany z wersji Shadow Brokers. Zatem w walce przetestowano tylko Metasploit, a na stanowisku testowym tylko drugi, co jeszcze bardziej utrudniało debugowanie i wykańczało mózg.
Ostatecznie skuteczny okazał się kod powłoki, który pobierał plik exe z danego serwera przez http i uruchamiał go w systemie docelowym. Kod powłoki był wystarczająco mały, aby się zmieścić, ale przynajmniej działał. Ponieważ serwer w ogóle nie lubił ruchu TCP, a http(y) zostały sprawdzone pod kątem obecności licznika, zdecydowałem, że najszybszym sposobem będzie pobranie pliku exe zawierającego licznik DNS-metrpretera za pośrednictwem tego kodu powłoki.
Tutaj znowu pojawił się problem: podczas pobierania pliku exe i, jak wykazały próby, niezależnie od tego, które, pobieranie zostało przerwane. Ponownie, pewne urządzenie zabezpieczające pomiędzy moim serwerem a urologiem nie podobało się ruchowi HTTP z plikiem exe w środku. „Szybkim” rozwiązaniem wydawała się zmiana kodu powłoki, tak aby zaciemniał ruch http w locie, tak aby przesyłane były abstrakcyjne dane binarne zamiast pliku exe. Wreszcie atak się powiódł, kontrola została przejęta przez cienki kanał DNS:
Od razu stało się jasne, że mam najbardziej podstawowe prawa przepływu pracy w IIS, które pozwalają mi nic nie robić. Tak to wyglądało na konsoli Metasploit:
Wszystkie metodologie pentestu zdecydowanie sugerują, że musisz zwiększyć uprawnienia podczas uzyskiwania dostępu. Zwykle nie robię tego lokalnie, ponieważ pierwszy dostęp jest postrzegany po prostu jako punkt wejścia do sieci, a naruszenie bezpieczeństwa innej maszyny w tej samej sieci jest zwykle łatwiejsze i szybsze niż eskalacja uprawnień na istniejącym hoście. Ale w tym przypadku tak nie jest, ponieważ kanał DNS jest bardzo wąski i nie pozwoli na oczyszczenie ruchu.
Zakładając, że ten serwer Windows 2003 nie został naprawiony pod kątem słynnej luki MS17-010, tuneluję ruch do portu 445/TCP przez tunel DNS licznika na hoście lokalnym (tak, jest to również możliwe) i próbuję uruchomić pobrany wcześniej plik exe przez podatność. Atak działa, otrzymuję drugie połączenie, ale z uprawnieniami SYSTEMOWYMI.
Co ciekawe, nadal próbowali chronić serwer przed MS17-010 - miał on wyłączone podatne na ataki usługi sieciowe w interfejsie zewnętrznym. To rzeczywiście chroni przed atakami przez sieć, ale atak od wewnątrz na localhost zadziałał, ponieważ nie można po prostu szybko wyłączyć SMB na localhost.
Następnie ujawniane są nowe interesujące szczegóły:
- Posiadając uprawnienia SYSTEMOWE, możesz łatwo nawiązać połączenie zwrotne poprzez TCP. Oczywiście wyłączenie bezpośredniego protokołu TCP jest problemem wyłącznie dla ograniczonego użytkownika IIS. Spoiler: ruch użytkowników IIS został w jakiś sposób zawinięty w lokalnym serwerze proxy ISA w obu kierunkach. Jak dokładnie to działa, nie odtworzyłem.
- Jestem w pewnej „DMZ” (i nie jest to domena Active Directory, ale GRUPA ROBOCZA) – brzmi to logicznie. Jednak zamiast oczekiwanego prywatnego („szarego”) adresu IP mam zupełnie „biały” adres IP, dokładnie taki sam, jak ten, który zaatakowałem wcześniej. Oznacza to, że firma jest na tyle stara w świecie adresacji IPv4, że stać ją na utrzymanie strefy DMZ dla 128 „białych” adresów bez NAT według schematu, jak to przedstawiono w instrukcjach Cisco z 2005 roku.
Ponieważ serwer jest stary, Mimikatz gwarantuje pracę bezpośrednio z pamięci:
Otrzymuję hasło lokalnego administratora, tuneluję ruch RDP przez TCP i loguję się do przytulnego pulpitu. Ponieważ mogłem zrobić z serwerem co chciałem, usunąłem program antywirusowy i stwierdziłem, że serwer był dostępny z Internetu tylko przez porty TCP 80 i 443, a 443 nie był zajęty. Skonfigurowałem serwer OpenVPN na 443, dodałem funkcje NAT dla mojego ruchu VPN i uzyskuję bezpośredni dostęp do sieci DMZ w nieograniczonej formie poprzez mój OpenVPN. Warto zauważyć, że ISA, mając niektóre nie wyłączone funkcje IPS, blokował mój ruch skanowaniem portów, dla czego trzeba było go zastąpić prostszym i bardziej zgodnym RRAS. Zatem pentesterzy czasami nadal muszą zarządzać różnymi rzeczami.
Uważny czytelnik zapyta: „A co z drugą witryną – wiki z uwierzytelnianiem NTLM, o której tyle napisano?” Więcej na ten temat później.
Część 2. Nadal nie szyfrujesz? W takim razie przyjedziemy do Ciebie już tutaj
Istnieje więc dostęp do segmentu sieci DMZ. Musisz udać się do administratora domeny. Pierwsze co przychodzi na myśl to automatyczne sprawdzanie bezpieczeństwa usług w segmencie DMZ, zwłaszcza, że coraz więcej z nich jest obecnie dostępnych do badań. Typowy obraz podczas testu penetracyjnego: obwód zewnętrzny jest lepiej chroniony niż usługi wewnętrzne, a uzyskując jakikolwiek dostęp wewnątrz dużej infrastruktury, znacznie łatwiej jest uzyskać rozszerzone prawa w domenie tylko dlatego, że domena ta zaczyna być dostępne dla narzędzi, a po drugie, w infrastrukturze składającej się z kilku tysięcy hostów zawsze będzie kilka krytycznych problemów.
Ładuję skanery przez DMZ przez tunel OpenVPN i czekam. Otwieram raport - znowu nic poważnego, najwyraźniej ktoś przede mną przeszedł tę samą metodę. Następnym krokiem jest sprawdzenie, w jaki sposób komunikują się hosty w sieci DMZ. Aby to zrobić, najpierw uruchom zwykły Wireshark i nasłuchuj żądań transmisji, głównie ARP. Pakiety ARP były zbierane przez cały dzień. Okazuje się, że w tym segmencie wykorzystuje się kilka bramek. Przyda się to później. Łącząc dane dotyczące żądań i odpowiedzi ARP oraz dane skanowania portów, znalazłem punkty wyjścia ruchu użytkowników z sieci lokalnej oprócz tych, które były wcześniej znane, takich jak internet i poczta.
Ponieważ w tej chwili nie miałem dostępu do innych systemów i nie miałem ani jednego konta do usług korporacyjnych, postanowiono wyłowić przynajmniej część konta z ruchu za pomocą ARP Spoofing.
Na serwerze urologa uruchomiono Cain&Abel. Biorąc pod uwagę zidentyfikowane potoki ruchu, wybrano najbardziej obiecujące pary do ataku typu man-in-the-middle, a następnie część ruchu sieciowego została odebrana poprzez krótkotrwałe uruchomienie na 5-10 minut, z timerem umożliwiającym ponowne uruchomienie serwera w przypadku zamarznięcia. Podobnie jak w dowcipie, były dwie wiadomości:
- Dobrze: przechwycono wiele danych uwierzytelniających i cały atak zadziałał.
- Wada: wszystkie referencje pochodziły od klientów klienta. Świadcząc usługi wsparcia, specjaliści klienta łączyli się z usługami klientów, którzy nie zawsze mieli skonfigurowane szyfrowanie ruchu.
W rezultacie zdobyłem wiele referencji, które były bezużyteczne w kontekście projektu, ale zdecydowanie interesujące jako demonstracja niebezpieczeństwa ataku. Routery graniczne dużych firm z telnetem, przesyłane debugowanie portów http do wewnętrznego CRM ze wszystkimi danymi, bezpośredni dostęp do RDP z Windows XP w sieci lokalnej i inne obskurantyzm. Okazało się tak .
Znalazłem też śmieszną okazję do zbierania listów z ruchu drogowego, coś takiego. To przykład gotowego listu, który poszedł od naszego klienta na port SMTP jego klienta, znowu bez szyfrowania. Niejaki Andriej prosi swojego imiennika o ponowne przesłanie dokumentacji, która w jednej odpowiedzi zostaje przesłana na dysk w chmurze wraz z loginem, hasłem i linkiem:
To kolejne przypomnienie o szyfrowaniu wszystkich usług. Nie wiadomo, kto i kiedy konkretnie będzie czytał i wykorzystywał Twoje dane – dostawca, administrator systemu innej firmy, czy taki pentester. Milczę na temat tego, że wiele osób może po prostu przechwycić niezaszyfrowany ruch.
Mimo pozornego sukcesu, nie zbliżyło nas to do celu. Można było oczywiście długo siedzieć i wyławiać cenne informacje, jednak nie jest faktem, że tam się pojawią, a sam atak jest bardzo ryzykowny z punktu widzenia integralności sieci.
Po ponownym zagłębieniu się w usługi przyszedł mi do głowy ciekawy pomysł. Istnieje narzędzie o nazwie Responder (łatwo znaleźć przykłady użycia pod tą nazwą), które „zatruwając” żądania rozgłoszeniowe, prowokuje połączenia za pośrednictwem różnych protokołów, takich jak SMB, HTTP, LDAP itp. na różne sposoby, następnie prosi każdego, kto się łączy, o uwierzytelnienie i konfiguruje je tak, aby uwierzytelnianie odbywało się za pośrednictwem protokołu NTLM i w trybie niewidocznym dla ofiary. Najczęściej atakujący zbiera w ten sposób uściski dłoni NetNTLMv2 i za pomocą słownika szybko odzyskuje hasła użytkowników domeny. Tutaj chciałem coś podobnego, ale użytkownicy siedzieli „za ścianą”, a raczej byli oddzieleni zaporą sieciową i uzyskiwali dostęp do sieci poprzez klaster proxy Blue Coat.
Pamiętasz, że podałem, że nazwa domeny Active Directory pokrywa się z domeną „zewnętrzną”, czyli była to firma.ru? Tak więc Windows, a dokładniej Internet Explorer (oraz Edge i Chrome), pozwala użytkownikowi na przejrzyste uwierzytelnianie w HTTP za pomocą NTLM, jeśli uzna, że witryna znajduje się w jakiejś „strefie intranetu”. Jednym ze znaków „Intranetu” jest dostęp do „szarego” adresu IP lub krótkiej nazwy DNS, czyli bez kropek. Ponieważ mieli serwer z „białym” adresem IP i nazwą DNS preobrazhensky.company.ru, a komputery domeny zwykle otrzymują sufiks domeny Active Directory przez DHCP w celu uproszczenia wprowadzania nazw, musieli jedynie wpisać adres URL w pasku adresu , aby znaleźć właściwą ścieżkę do serwera zaatakowanego urologa, nie zapominając, że nazywa się on teraz „Intranetem”. Oznacza to, że jednocześnie przekazuję mi uścisk dłoni użytkownika NTLM bez jego wiedzy. Pozostaje tylko zmusić przeglądarki klienckie do zastanowienia się nad pilną potrzebą skontaktowania się z tym serwerem.
Na ratunek przyszło wspaniałe narzędzie Intercepter-NG (dzięki ). Umożliwiał zmianę ruchu w locie i działał świetnie w systemie Windows 2003. Miał nawet oddzielną funkcję modyfikowania tylko plików JavaScript w przepływie ruchu. Zaplanowano coś w rodzaju masowego skryptowania między witrynami.
Serwery proxy Blue Coat, za pośrednictwem których użytkownicy uzyskiwali dostęp do globalnej sieci, okresowo buforowały zawartość statyczną. Przechwytując ruch, było jasne, że pracowali przez całą dobę, bez przerwy żądając często używanych statycznych, aby przyspieszyć wyświetlanie treści w godzinach szczytu. Ponadto BlueCoat posiadał specyficznego User-Agenta, co wyraźnie odróżniało go od prawdziwego użytkownika.
Przygotowano JavaScript, który za pomocą Interceptera-NG zaimplementowano na godzinę w nocy dla każdej odpowiedzi z plikami JS dla Blue Coat. Skrypt wykonał następujące czynności:
- Określono bieżącą przeglądarkę przez User-Agent. Jeśli był to Internet Explorer, Edge lub Chrome, nadal działał.
- Poczekałem, aż utworzy się DOM strony.
- Wstawiono niewidoczny obraz do DOM z atrybutem src formularza :8080/NNNNNNN.png, gdzie NNN to dowolne liczby, aby BlueCoat nie buforował ich.
- Ustaw globalną zmienną flagi, aby wskazać, że wstrzyknięcie zostało zakończone i nie ma już potrzeby wstawiania obrazów.
Przeglądarka próbowała załadować ten obraz; na porcie 8080 zaatakowanego serwera czekał na niego tunel TCP prowadzący do mojego laptopa, na którym działał ten sam obiekt odpowiadający, co wymagało od przeglądarki zalogowania się za pomocą protokołu NTLM.
Sądząc po logach Respondentów, ludzie przyszli rano do pracy, włączyli swoje stacje robocze, po czym masowo i niezauważeni zaczęli odwiedzać serwer urologa, nie zapominając o „wyssaniu” uścisków dłoni NTLM. Uściski dłoni padały cały dzień i wyraźnie zgromadziły materiał na ewidentnie udany atak mający na celu odzyskanie haseł. Tak wyglądały dzienniki obiektu odpowiadającego:
Masowe tajne wizyty użytkowników na serwerze urologa
Pewnie już zauważyłeś, że cała ta historia opiera się na zasadzie „wszystko było w porządku, ale potem była wpadka, potem było przezwyciężenie, a potem wszystko się udało”. Więc tutaj był bałagan. Z pięćdziesięciu unikalnych uścisków dłoni żaden nie został ujawniony. A to uwzględnia fakt, że nawet na laptopie z martwym procesorem te uściski dłoni NTLMv2 są przetwarzane z prędkością kilkuset milionów prób na sekundę.
Musiałem uzbroić się w techniki mutacji haseł, kartę graficzną, grubszy słownik i czekać. Po długim czasie ujawniono kilka kont z hasłami w postaci „Q11111111....1111111q”, co sugeruje, że wszyscy użytkownicy byli kiedyś zmuszeni do wymyślenia bardzo długiego hasła z różną wielkością liter, co również miało być złożony. Ale doświadczonego użytkownika nie da się oszukać i w ten sposób ułatwił sobie zapamiętywanie. W sumie włamano się na około 5 kont i tylko jedno z nich miało cenne prawa do usług.
Część 3. Roskomnadzor kontratakuje
Tak więc otrzymano pierwsze konta domenowe. Jeśli po długiej lekturze nie zasnąłeś do tego momentu, prawdopodobnie pamiętasz, że wspomniałem o usłudze, która nie wymagała drugiego czynnika uwierzytelniania: jest to wiki z uwierzytelnianiem NTLM. Oczywiście najpierw trzeba było tam wejść. Szperanie w wewnętrznej bazie wiedzy szybko przyniosło rezultaty:
- Firma posiada sieć WiFi z uwierzytelnianiem przy użyciu kont domenowych z dostępem do sieci lokalnej. Przy obecnym zestawie danych jest to już działający wektor ataku, jednak do biura trzeba iść na nogach i znajdować się gdzieś na terenie biura klienta.
- Znalazłem instrukcję, według której istniała usługa, która pozwalała... samodzielnie zarejestrować urządzenie uwierzytelniające „drugiego czynnika”, jeśli użytkownik znajduje się w sieci lokalnej i pewnie pamięta swój login i hasło do domeny. W tym przypadku o „wewnątrz” i „na zewnątrz” decydowała dostępność portu tej usługi dla użytkownika. Port nie był dostępny z Internetu, ale był dość dostępny poprzez strefę DMZ.
Oczywiście do zaatakowanego konta natychmiast dodano „drugi czynnik” w postaci aplikacji na moim telefonie. Istniał program, który mógł albo na głos wysłać żądanie push do telefonu z przyciskami „zatwierdź”/„odrzuć” dla akcji, albo cicho wyświetlić na ekranie kod OTP w celu dalszego samodzielnego wprowadzenia. Co więcej, instrukcja zakładała, że pierwsza metoda będzie jedyną poprawną, ale nie zadziałała, w przeciwieństwie do metody OTP.
Po zepsuciu „drugiego czynnika” mogłem uzyskać dostęp do poczty Outlook Web Access i dostępu zdalnego w Citrix Netscaler Gateway. W poczcie w Outlooku pojawiła się niespodzianka:
Na tym rzadkim zdjęciu widać, jak Roskomnadzor pomaga pentesterom
Były to pierwsze miesiące po słynnym zablokowaniu Telegramu przez „fanów”, kiedy z dostępu nieubłaganie zniknęły całe sieci z tysiącami adresów. Stało się jasne, dlaczego push nie zadziałał od razu i dlaczego moja „ofiara” nie wszczęła alarmu, bo zaczęła korzystać z jej konta w godzinach otwarcia.
Każdy, kto zna Citrix Netscaler, wyobraża sobie, że jest on zwykle realizowany w taki sposób, że użytkownikowi można przekazać jedynie interfejs obrazkowy, starając się nie dawać mu narzędzi do uruchamiania aplikacji innych firm i przesyłania danych, ograniczając w każdy możliwy sposób działania poprzez standardowe powłoki kontrolne. Moja „ofiara” ze względu na zawód dostała tylko 1C:
Po krótkim obejściu interfejsu 1C odkryłem, że znajdują się tam zewnętrzne moduły przetwarzające. Można je załadować z interfejsu i zostaną wykonane na kliencie lub serwerze, w zależności od uprawnień i ustawień.
Poprosiłem moich przyjaciół programistów 1C, aby stworzyli przetwarzanie, które zaakceptowałoby ciąg znaków i wykonało go. W języku 1C rozpoczęcie procesu wygląda mniej więcej tak (zaczerpnięte z Internetu). Czy zgadzasz się, że składnia języka 1C zadziwia ludzi rosyjskojęzycznych swoją spontanicznością?
Przetwarzanie przebiegło perfekcyjnie, okazało się, że pentesterzy nazywają to „powłoką” – za jej pośrednictwem uruchomiono przeglądarkę Internet Explorer.
Wcześniej w poczcie odnaleziono adres systemu umożliwiającego zamówienie wejściówek na teren. Zamówiłem przepustkę na wypadek konieczności użycia wektora ataku WiFi.
W internecie krążą plotki, że w biurze klienta nadal można było zjeść pyszny darmowy catering, ale ja i tak wolałem rozwijać atak zdalnie, jest spokojniej.
Funkcja AppLocker została aktywowana na serwerze aplikacji z systemem Citrix, ale została pominięta. Ten sam Meterpreter został załadowany i uruchomiony przez DNS, ponieważ wersje http(s) nie chciały się połączyć, a ja nie znałem wówczas wewnętrznego adresu proxy. Nawiasem mówiąc, od tego momentu zewnętrzny pentest zasadniczo całkowicie zmienił się w wewnętrzny.
Część 4. Prawa administratora dla użytkowników są złe, OK?
Pierwszym zadaniem pentestera przy przejmowaniu kontroli nad sesją użytkownika domeny jest zebranie wszelkich informacji o uprawnieniach w domenie. Istnieje narzędzie BloodHound, które automatycznie pozwala na pobieranie informacji o użytkownikach, komputerach, grupach bezpieczeństwa poprzez protokół LDAP z kontrolera domeny, a poprzez SMB - informacje o tym, który użytkownik ostatnio się zalogował i kto jest lokalnym administratorem.
Typowa technika przejmowania uprawnień administratora domeny wygląda na uproszczoną jako cykl monotonnych działań:
- Udajemy się na komputery domenowe, na których znajdują się uprawnienia administratora lokalnego, na podstawie już przejętych kont domenowych.
- Uruchamiamy Mimikatz i otrzymujemy hasła z pamięci podręcznej, bilety Kerberos i skróty NTLM kont domen, które ostatnio logowały się do tego systemu. Lub usuwamy obraz pamięci procesu lsass.exe i robimy to samo po naszej stronie. Działa to dobrze w systemie Windows młodszym niż 2012R2/Windows 8.1 z ustawieniami domyślnymi.
- Ustalamy, gdzie zaatakowane konta mają uprawnienia administratora lokalnego. Powtarzamy punkt pierwszy. Na pewnym etapie uzyskujemy uprawnienia administratora dla całej domeny.
„Koniec cyklu;”, jak napisaliby tutaj programiści 1C.
Tak więc nasz użytkownik okazał się lokalnym administratorem tylko na jednym hoście z systemem Windows 7, którego nazwa zawierała słowo „VDI”, czyli „Infrastruktura wirtualnych pulpitów”, czyli osobiste maszyny wirtualne. Prawdopodobnie projektantowi usługi VDI chodziło o to, że skoro VDI jest osobistym systemem operacyjnym użytkownika, to nawet jeśli użytkownik zmieni środowisko oprogramowania według własnego uznania, host nadal będzie mógł zostać „przeładowany”. Ja też pomyślałem, że ogólnie pomysł jest dobry, pojechałem do tego osobistego hosta VDI i tam założyłem gniazdo:
- Zainstalowałem tam klienta OpenVPN, który zrobił tunel przez Internet do mojego serwera. Klient musiał przejść przez ten sam Blue Coat z uwierzytelnieniem domeny, ale OpenVPN zrobił to, jak mówią, „od razu po wyjęciu z pudełka”.
- Zainstalowano OpenSSH na VDI. No cóż, czym tak naprawdę jest Windows 7 bez SSH?
Tak to wyglądało na żywo. Przypomnę, że wszystko to należy zrobić za pośrednictwem Citrix i 1C:
Jedną z technik promowania dostępu do sąsiednich komputerów jest sprawdzanie zgodności haseł administratora lokalnego. Tutaj szczęście natychmiast czekało: dostęp do skrótu NTLM domyślnego administratora lokalnego (którego nagle nazwano Administratorem) został osiągnięty poprzez atak typu pass-the-hash na sąsiednie hosty VDI, których było kilkaset. Oczywiście atak natychmiast ich uderzył.
Tutaj administratorzy VDI strzelili sobie dwa razy w stopę:
- Po raz pierwszy maszyny VDI nie zostały objęte programem LAPS, zasadniczo zachowując to samo hasło administratora lokalnego z obrazu, który został masowo wdrożony w VDI.
- Domyślny administrator to jedyne konto lokalne podatne na ataki typu pass-the-hash. Nawet przy tym samym haśle można by uniknąć masowego kompromisu, tworząc drugie konto administratora lokalnego ze złożonym, losowym hasłem i blokując hasło domyślne.
Dlaczego w tym systemie Windows dostępna jest usługa SSH? Bardzo proste: teraz serwer OpenSSH zapewnił nie tylko wygodną interaktywną powłokę poleceń bez zakłócania pracy użytkownika, ale także proxy skarpetki5 na VDI. Dzięki tym skarpetom połączyłem się przez SMB i zebrałem konta w pamięci podręcznej ze wszystkich setek maszyn VDI, a następnie szukałem ścieżki do administratora domeny, używając ich na wykresach BloodHound. Mając do dyspozycji setki hostów, dość szybko znalazłem tę drogę. Uzyskano uprawnienia administratora domeny.
Oto zdjęcie z Internetu przedstawiające podobne wyszukiwanie. Połączenia pokazują, kto gdzie jest administrator i kto gdzie jest zalogowany.
Nawiasem mówiąc, pamiętaj warunek z początku projektu - „nie używaj socjotechniki”. Proponuję więc pomyśleć o tym, jak bardzo całe to Bollywood z efektami specjalnymi zostałoby odcięte, gdyby nadal można było stosować banalny phishing. Ale osobiście bardzo interesujące było dla mnie robienie tego wszystkiego. Mam nadzieję, że miło ci się to czytało. Oczywiście nie każdy projekt wygląda tak intrygująco, ale praca jako całość jest bardzo wymagająca i nie pozwala na stagnację.
Pewnie ktoś będzie miał pytanie: jak się zabezpieczyć? Nawet w tym artykule opisano wiele technik, o których administratorzy systemu Windows nawet nie mają pojęcia. Proponuję jednak spojrzeć na nie przez pryzmat oklepanych zasad i środków bezpieczeństwa informacji:
- nie korzystaj z przestarzałego oprogramowania (pamiętasz na początku Windows 2003?)
- nie włączaj zbędnych systemów (po co była strona urologa?)
- sam sprawdź siłę haseł użytkowników (w przeciwnym razie zrobią to żołnierze... pentesterzy)
- nie mieć tych samych haseł do różnych kont (kompromis VDI)
- i inne
Jest to oczywiście bardzo trudne do zrealizowania, ale w kolejnym artykule pokażemy w praktyce, że jest to całkiem możliwe.
Źródło: www.habr.com