Jednym z niezbędnych narzędzi każdego złodupca hakera administratora jest diagnostyka i badanie, czy usługi, które się uruchomiło, działają prawidłowo. Nie ma bowiem niczego równie irytującego, jak ślepa diagnostyka aplikacji, wiążąca się z wieloma straconymi godzinami, rzuconymi ladacznicami, konfliktami zbrojnymi oddziałów hardware z obiektami budowlanymi, a także załamaniami psychicznymi, depresjami, inflacją, brakiem mleka u krów, abdykacją sołtysa rodzimej gminy i gnijącymi ziemniakami w piwnicy sąsiada. Choć w ostatnim skutku nie jestem w stanie zbyt wiele zdziałać (kłamstwo: krowy też nie są moją mocną stroną), o tyle istnieje pewien rodzaj niedocenionych narzędzi, które mogą proces debugowania znacząco przyspieszyć.
Wyjaśnię na prawdziwych, choć prostych przykładach, jak dokonać dość prymitywnej analizy ruchu, choć nazywanie tego analizą jest finalnie dość dużym nadużyciem. Niemniej stanowi to potężne podstawy do dalszej nauki nowych technologii, pomaga zrozumieć działanie mechanizmów i praw w naszym grajdołku technologicznym, jest często także zamaskowane w wielu produktach z działu security, które wykorzystują badanie i analizę ruchu (i to często w czasie rzeczywistym). U podstaw nie ma jednak żadnej magii, a prymitywne narzędzia, które nazywają się trudniej, niż faktycznie funkcjonują. I je poznamy.
Czy to legalne?
Tak, o ile robisz to u siebie, masz u kogoś pozwolenie, bawisz się we własnym grajdole. Nie, jeśli wjeżdżasz komuś w sieć z niecnymi zamiarami. Tak, omówionymi narzędziami da się przechwycić ruch (bo do tego służą?), a co z przechwyconym ruchem się stanie, cóż, zależy od nas. Nie bądź dupkiem.
Co nam to może dać?
Wiele nieprawidłowości działania aplikacji ma swoje źródło w mechanizmie zwanym pakiety nie docierają i dotrzeć nie miały jak, bo admin to dupa. Tak na prawdę niezależnie od tego, czy badamy działanie DHCP (co mi kurwa rozdaje adresy IP zamiast routera?), reverse proxy (gdzie są kurwa moje zapytania ja się pytam!?), czy badamy działanie firewalla (czy te rulki na firewallu mogłyby, kurwa, przestać dolatywać skoro je zablokowałem?!), potężnym ułatwieniem jest możliwość podejrzenia czy i jakie pakiety sieciowe dolatują. Oczywiście puntem wspólnym jest kurwa ruch sieciowy, a skoro ruch sieciowy, można w nim radośnie gmerać.
Zyskujesz możliwość analizy ruchu i reagowania właściwie w czasie rzeczywistym. Dobrze byłoby wiedzieć, jak dany protokół działa, ale szybko się przekonasz, że teoria znaleziona gdzieś na Wikipedii ma swoje odniesienie w rzeczywistości. I jest w tym coś magicznego, gdy patrząc na zrzut ruchu można znaleźć praktyczne odzwierciedlenie tej wiedzy (warstwy modelu OSI – patrzę na was).
Jak zacząć?
Zacznijmy od ustalenia, co będziemy badać. Rozważymy dwa przypadki:
- ping jakiegoś hosta
- serwer WWW: jak znaleźć pakiety dej mnie te stronę
Naszym środowiskiem będą dwie maszyny z zainstalowanym Linuksem (tutaj: Debian). Na jednym z nich będą zainstalowane usługi, takie jak serwer WWW czy serwer DHCP, drugi będzie jedynie wysyłać żądania o daną usługę, ewentualnie podsłuchiwać ruch. Przechwytywany ruch, o ile zajdzie taka potrzeba, przeanalizuję w Wiresharku na innej maszynie, choćby dlatego, że będzie to wygodniejsze. Na testowych maszynach użyję tekstowego tcpdump, aby ograniczyć potrzebę stosowania GUI. Nie będzie nam potrzebne, szczególnie, że przecież już wiadomo, że istnieje coś takiego jak curl 🙂
Nie będę jednak zagłębiać się w działanie protokołów, chyba, że będzie to niezbędne do dalszego tłumaczenia. Ograniczę się jednak do minimum, a skupię się na narzędziach.
Filtry
Komputery nie żyją (kropka), znaczy się inaczej. Chwila, od początku. Komputery podłączone do sieci nie pracują w próżni. W domyślnej konfiguracji rzadko działają cicho i jednak coś wysyłają, czasami taki ruch jest kierowany na broadcast i dociera do innych maszyn w tej samej domenie rozgłoszeniowej.
Szybkie wyjaśnienie: broadcast to taki cel wysyłki pakietów, który można interpretować jako wyślij do wszystkich. Jest to szczególny rodzaj ruchu, bo targetem w 2 warstwie modelu OSI (czyli adresem MAC na który jest to wysyłane) jest FF:FF:FF:FF:FF:FF. Zakres, do którego takie pakiety trafią, jest nazywany domeną rozgłoszeniową i ograniczana jest ona przez routery.
Powoduje to, że w trakcie łapania ruchu uda się nam zgarnąć także dużo śmieci, nie mających związku z naszymi zamiarami. A jeśli będziemy do tego robić to będąc jednocześnie podłączonymi przez SSH, zobaczymy straszny bajzel na ekranie. Stąd właśnie narzędzia niuchające (sniffery, ale kurde, niuchacze brzmi dużo, dużo lepiej!) posiadają funkcjonalność, mogącą odfiltrować to, co dla nas istotne. Oczywiście broadcast nie jest jedynym celem, na jaki komputery wysyłają pakiety, ale jest bardzo widoczny po uruchomieniu sniffera ruchu.
Kryteria mogą być różne i właściwie ograniczeniami jest Twoja wyobraźnia. I nie wspominam o tym, aby nabić więcej literek, o nie (to mój dysk i moje literki, więc zależy mi na oszczędzaniu danych 🙂 ). Wspominam, aby zaznaczyć, że umiejętność filtrowania ruchu jest szalenie pożądaną cechą, znacząco przyspieszającą procesy troubleshootingu.
Podsłuchiwanie pinga
Nie ma prostszego przykładu. Chyba. Polecenie ping jest znane chyba wszystkim, jest także znacząco trywializowane, ale to pokłosie jego dostępności i przystępności. Niemniej siła tego narzędzia tkwi właśnie w tych cechach: jest niemal zawsze dostępne i jest niemal zawsze tak samo przystępne.
Pytasz się zatem, co kryje się pod takim płaszczykiem? Ja odpowiadam: niewiele cała machineria oparta o protokół ICMP.
ICMP to protokół diagnostyczny, pozwalający badać i analizować sieć na podstawie zapytań i odpowiedzi. Najpopularniejszymi narzędziami są ping i traceroute, dzisiaj skupimy się jednak na tym pierwszym. Pakiety mają swoje typy, których tabelę znajdziemy tutaj. Typ jest zawierany w nagłówku pakietu, pozwalając na proste wskazywanie, co jest przedmiotem badania. Tym sposobem host wie, że otrzymują pakiet ICMP o typie 8 (echo request) ma odpowiedzieć ICMP typem 0 (echo reply). My tym samym widzimy, że badany host jest online, odpowiada i ma się raczej nieźle.
Zbadajmy więc to. Uruchommy więc na jednej maszynie polecenie:
ping 192.168.10.51
Adres IP powyżej to adres badanej przeze mnie maszyny. U Ciebie może być inny.
Widok raczej będzie nam znany:
Widać, że host odpowiada, że jest online, że jest ładnie. Ale na tym nie poprzestaniemy. Jednocześnie na badanym hoście (192.168.10.51) przechwyciłem pakiety za pomocą tcpdump. Przyjrzyjmy się poleceniu i jego wynikowi:
Zacznijmy od polecenia:
tcpdump -i enp0s3 icmp
tcpump to właśnie wspomniane narzędzie. Flaga -i wskazuje na interfejs sieciowy, który będzie badany (tutaj interfejs o nazwie enp0s3), a dopisek icmp mówi, że pakiety związane z tym protokołem mają być filtrowane.
Skąd taka konstrukcja? Jestem zalogowany do tej maszyny przez protokół SSH, a sama maszyna posiada kilka interfejsów sieciowych. Brak filtrowania poskutkuje w takim wypadku bałaganem na ekranie:
Prawda, że to nie jest czytelne? Wykonajmy jednak ponownie ten test, tym razem zapisując zrzut ruchu do pliku. Otworzymy taki zrzut w kombajnie Wireshark, co pozwoli nam na czytelniejszą analizę. Powtórzmy więc test, ale zainicjujemy zrzut ruchu modyfikując polecenie:
tcpdump -i enp0s3 icmp -w ICMP.pcap
Nasza modyfikacja to flaga -w ICMP.pcap, która mówi wprost: co wpadnie ci panie tcpdump na bęben, wrzuć w plik ICMP.pcap. Nie zobaczymy nic na ekranie. Reszta taka sama: ping, po chwili przerywamy, idziemy po kawkę, czytamy dalej.
Szybki transfer naszego pliku za pomocą scp:
scp [email protected]:/root/ICMP.pcap .
W skrócie: wbij na konto root na 192.168.10.51, idź do pliku /root/ICMP.pcap i zapisz go tu, gdzie jesteś (ta kropka na końcu polecenia), bez zmiany nazwy. Wspaniałe narzędzie.
I otwieramy w Wiresharku to, to pobraliśmy:
Naszym oczom ukaże się las lista pakietów. Pamiętasz, co mówiłem o filtrach? One pozwoliły nam zapisać tylko ICMP, bez dodatkowych śmieci. Wspaniałe narzędzie.
Przyjrzyjmy się zatem. Taki jeden element, to pakiet, który nas właśnie interesuje:
Widać jego źródło, cel, protokół, zwartość, umiejscowienie w czasie… Dużo więcej też widać poniżej po podświetleniu pakietu:
I co to takiego, zapytasz się. Znaczy się nie zapytasz, bo pewnie drżą Ci ręce, albo powieka, w zależności, czy ogarnia Cię strach, czy nerw, że to tyle trwa. Czytaj to od góry do dołu, linijka po linijce, a potem spójrz na model OSI.
Obrazek powyżej jest zajumany z Wikipedii, ale świetnie oddaje to, co chcę przekazać. Pierwsza linijka zwiera niezbyt interesujące informacje o warstwie pierwszej. Ale druga linijka jest już ciekawa. Tutaj są informacje o adresach MAC źródła i celu:
Trzecia linijka to trzecia warstwa, warstwa sieciowa, gdzie kiedyś ktoś mądrzejszy ode mnie uznał, że będzie pakować adresy IP: tutaj źródłowe i celu:
Czy tutaj jest zawarta informacja co i jak badamy? Nie. To nadal tylko kawałek pakietu wskazujący gdzie ma trafić. Jednocześnie trzeba postawić sprawę jasno: jeśli celem jest dany adres IP, on jest badany. Ciekawiej się robi w czwartej, transportowej warstwie:
To jest to miejsce, gdzie ICMP jest sobą i są o nim zawarte informacje: co jest badane (typ pakietu, 8). Wysyłamy pakiet ICMP typu 8 (przyjrzyj się kilka linijek powyżej, gdzie odsyłam do dokumentu na ten temat) i oczekujemy, że badany host odpowie nam typem 0. Można wpłynąć na to zachowanie, wyłączając odpowiedzi na ICMP, blokując to za pomocą firewalla, ale w naszym przypadku mamy zwykły, generyczny… przypadek.
A co z odpowiedzią? A proszę, pakiet numer dwa:
Źródło z celem się zamieniły miejscami (bo wszak ma odpowiedzieć temu, kto pytał, nie?), a pakiet którym odpowiadamy, to ICMP typ 0. Czyli „jestem online, żyję”.
Ciekawostka: Wireshark potrafi w zaznaczanie takiej komunikacji, jeśli są skonstruowana w formacie pytanie-odpowiedź. Przy zaznaczeniu pakietu są widoczne strzałeczki i linie łączące pakiety:
Bardzo podnosi to czytelność i przyspiesza proces. Wspaniałe narzędzie.
Można teraz zadać pytanie: no dobra, widzę że to lata, że są pakieciki, że coś się dzieje, ale po cholerę mi to? Zwolnij i przyjrzyj się uważnie:
- Host odpowiada, jest online
- Odpowiada prawidłowo, na ósemkę odpowiada zerem
- ICMP nie jest blokowane na firewallu
- Jeśli nie działa jakaś inna usługa, można porównać reguły towarzyszące ruchowi ICMP z regułami towarzyszącymi innej usłudze, skoro ICMP odpowiada, problem leży w samej aplikacji?
- Wireshark i tcpdump są zajebiste
- Wireshark i tcpdump mogą ugryźć w dupę, jeśli to nie my wykonamy badanie, bo są wstanie wyciągnąć i przeanalizować jakiś ruch, można wyciągnąć z tego wiele użytecznych danych, nie tylko źródło i cel transmisji, ale przy odrobinie szczęścia i samozaparcia także zawartość transmisji (diagnozowałem tak VOIP i dało się wyciągnąć rozmowę!). A to potężny duet, gdy ktoś chce zrobić nam krzywdę
- De facto przechwyciłeś ruch. Co prawda tylko ICMP (bo tak kazałeś), ale jest to żywy, prawdziwy ruch internetowy, ze wszystkimi informacjami i całą zawartością pakietów
A to tylko 10 minutowy lab. Z jednej strony to tylko ICMP, z drugiej już tylko to pokazuje, jak bardzo jest ważne zabezpieczanie sieci.
Strona WWW
Na serwerze 192.168.10.51 został uruchomiony serwer WWW Apache2, który serwuje prostą stronę WWW:
Kod tej strony jest ściśle tajny tylko w drodze wyjątku i umowy z naszej strony, że nie zostanie komercyjnie wykorzystany, zostanie upubliczniony:
<html>
<head>
<link rel="icon" href="data:,">
<title> Testujemy </title>
</head>
<body>
<p> To tylko test
</body>
</html>
Skoro prawa autorskie mamy za sobą, przyjmujemy, że ten gagatek serwuje nam stronę WWW na porcie 80. Zwykły HTTP, bez dodatkowych zabezpieczeń. To tylko lab, nikt nas w sieci lokalnej nie dojedzie za brak security.
Jak to wygląda z poziomu podglądania ruchu? Syntetyczny tcpdump nie da nam ładnego wyniku. Widać, że jest jakiś ruch, że się coś ruszało, ale w obecnej formie niewiele nam to mówi.
Wejdźmy głębiej w tę króliczą norę i zrzućmy ruch do pliku:
tcpdump port 80 -i enp0s3 -w WWW.pcap
Czekaj, jaki port? Otóż wskazujemy, że tcpdump ma słuchać wyłącznie ruchu na porcie 80, na interfejsie enp0s3 i tak dalej… Filtrowanie, pamiętasz?
Na naszej sprawdzającej maszynie wydaj polecenie:
curl -v http://192.168.10.51/
Ostatecznie możesz użyć przeglądarki internetowej, ale konsolowy curl ma gdzieś ciasteczka przeglądarki, cache i inne ułatwiatory, które mogą nam wynik zafałszować.
Czego właściwie szukamy w zrzucie ruchu? Skupmy się na zapytaniu o witrynę i zwróconym kodzie HTTP. Do dzieła.
Strona przechwycona, ruch też. Dobieramy się do paczki z ruchem, kopiowanko:
scp [email protected]:/root/WWW.pcap .
I WWW.pcap do Łajerszarka.
Moment, ale jakie kody HTTP!? HTTP opiera się na tak zwanych kodach odpowiedzi. Są one logicznie posegregowane numerycznie, są ustandaryzowane i ogólnie przyjęte. Pozwalają one na szybką i logiczną wymianę obiekcji na temat zastanego stanu witryny (bądź jej braku). Listę kodów można sprawdzić tutaj.
Powyższy mem dobrze i humorystycznie podsumowuje bloki kodów HTTP. To, co nas interesuje to kod o numerze 200. I nic innego, nie teraz. Przyjmijmy się zatem zrzutowi ruchu.
W pierwszej fazie następuje nawiązanie ruchu TCP. W ramach tego transmisja ma potwierdzenia prawidłowości danych, ma się pewność, że dane nie uciekły w trakcie transmisji. Nuda i chwilowo nie interesuje nas to w szczegółach, wystarczy nam informacja, że transmisja była zarówno ze strony komputera, jak i serwera. Skierujmy teraz wzrok na pierwszy z pakietów HTTP.
Przeczytaj od góry zawartość powyższego screena. Tutaj widać o co pytamy (ostatnia sekcja Full request URI ), jaki User Agent został od nas wypchnięty i wiele, wiele innych ciekawostek. Wykazaliśmy, że widać zapytanie o witrynę http://192.168.10.51/.
A odpowiedź? A proszę:
Nie dość, że w payload (ostatnia sekcja) widać całego HTML, to serwer się wygaduje, jaka aplikacja i system mieszkają na nim. Ale! Druga linijka screenshota: HTTP/1.1 200 OK. Właśnie wykazaliśmy, że serwer odpowiedział kodem 200 i całość działa jak trzeba. A co, jeśli zapytamy się o coś, co nie istnieje? Spróbowałem zapytać się o http://baremetal.work, co nie powinno się udać, bo witryna jest dostępna jedynie poprzez HTTPS. A proszę:
400 Bad Request. Odnosząc się do mema: you fucked up. Poprosiłeś o coś, co nie istnieje. Ten Wireshark to jednak wspaniałe narzędzie.
Wnioski? Bo póki co znowu jakieś pakiety, jakaś strona, jakieś dziwne rzeczy…
- Podejrzałeś ruch HTTP (więc ten nieszyfrowany), wiedząc kto i o co pyta a także co dostał w odpowiedzi, wraz ze wszystkimi danymi. To od Ciebie zależy, co z tymi danymi zrobisz, dobrego lub złego
- Możesz czuć się jak haker, bo jednak to można traktować już w kategoriach ataku. Ale spokojnie, to kontrolowane środowisko, nic nielegalnego
- Zostawiając żarty na bok: wykazałeś, że serwer WWW prawidłowo obsługuje zapytania HTTP i jeśli występują problemy, to raczej nie są spowodowane samym serwerem WWW
- Wskazałeś konkretne pakiety odpowiedzialne za tę transmisję, a także przyjrzałeś się ich zawartości, pobieżnie analizując ich zawartość
- Na własnej skórze dowiodłeś, dlaczego HTTPS jest cholernie istotny w ramach działania współczesnej sieci. Nie znaczy, że HTTP jest do zaorania, ale nie stosujmy go w tam, gdzie może zostać wdrożony HTTPS
Skąd mam wiedzieć, co słuchać?
Na samym początku, aby oswoić się z instytucją podglądania pakietów, polecam skupić się na Wireshark. Jest to narzędzie HUI GUI, przez co może być trochę wygodniejsze. Przy starcie pozwala także wybrać podsłuchiwany interfejs:
Na liście zobaczysz nie tylko listę swoich kart sieciowych, ale kilku innych urządzeń. Część z nich może wyglądać dziwnie na początku. Jeśli używasz VPN, to go tutaj także zobaczysz, podobnie jak VLAN. Sam Wireshark jest już bardzo potężnym narzędziem, a w połączeniu z tcpdump to potężny oręż w rękach doświadczonego hakera administratora. W większości przypadków będziesz mieć informację, na jakim interfejsie (a przynajmniej na jakim adresie IP) działa jakaś usługa. Nic nie stoi na przeszkodzie, aby słuchać wszystkiego i odpowiednio to filtrować. A właśnie, Wireshark ma też świetny filtr, gdybyś na żywo chciał coś łowić, albo wyłuskać coś z zapisanego już ruchu. Proszę, SSH na żywo:
Szalenie polecam pobawić się, przydaje się.
Po co mi to?
Możesz prowadzić diagnostykę na ślepo. Możesz także jedynie na logach się opierać. Możesz także rzucać monetą, a także możesz oprzeć się na narzędziach, które działają. Nie ma jednego scenariusza, jednego przypadku użycia, który wyczerpałby temat i jednoznacznie wyznaczył twarde granice używania snifferów. Najważniejsze przypadki użycia to:
- Jeden z kroków diagnostyki aplikacji
- Możliwość wykrywania ataków, dziwnych zachowań w sieci
- Możliwość śledzenia tras pakietów
- Wykazywanie problemów bądź testowanie zabezpieczeń
- Możliwość precyzyjnego pokazania palcem na kafelek i obwinienie go o burdel jaki spowodował
- Zabawa w
hakeraadministratora - Świetna pomoc dydaktyczna w ramach nauki protokołów
Dość celowo w tekście skreślałem hakera i zamieniałem go na administratora. Wpis prezentuje podstawy działania narzędzi, ale dość dobrze wskazuje na cienką granicę pomiędzy tym dobrym a tym złym. Często jedynym rozgraniczeniem są nasze intencje i fakt, czy mamy pozwolenie na dłubanie w jakimś środowisku. Rzecz jasna nie popieram nielegalnych działań, wroga jednak trzeba znać i wiedzieć, jak go wykryć, do czego te narzędzia, w doświadczonych rękach, mogą się przyczynić. Nikt oczywiście ręcznie nie sprawdza regularnie sieci takimi narzędziami, do tego służą inne aplikacje z działu security, ale doraźnie, w ramach diagnostyki są nieocenionym narzędziem.
Źródła
- https://pl.wikipedia.org/wiki/Internet_Control_Message_Protocol
- https://datatracker.ietf.org/doc/html/rfc792
- https://pl.wikipedia.org/wiki/Model_OSI
- https://www.reddit.com/r/ProgrammerHumor/comments/2rttnv/http_status_ranges_in_a_nutshell/
- „CCNA 200-301. Zostań administratorem sieci komputerowych Cisco.” Adam Józefiok, wydawnictwo Helion. Stron nie podam, to nie bibliografia
0 komentarzy