Generator pakietów scapy – część 2.

17 kwietnia 2018, 12:15 | Teksty | komentarzy 6
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

W poprzednim artykule poruszyliśmy temat podstaw Scapy – narzędzia, które daje możliwość swobodnego generowania pakietów. Jeżeli brzmi to zbyt enigmatycznie, polecam zapoznanie się z wyżej wymienionym artykułem. Zostały w nim omówione podstawy, dzięki którym możliwe jest wskoczenie na kolejny poziom w obsłudze tego narzędzia, czyli pisania skryptów. Scapy oferuje możliwość użycia go wraz z programami pisanymi w Pythonie. Taka funkcjonalność umożliwia tworzenie skomplikowanych narzędzi, zautomatyzowanej analizy pakietów czy przeprowadzanie różnych ataków.

Tyle tytułem wstępu. Teraz przyszedł czas na praktyczne zastosowanie Scapy.

TCP handshake

Na dobry początek zabierzmy się do podstaw z zakresu wiedzy sieciowej czyli tzw. TCP handshake.

Sposób nawiązania połączenia TCP składa się z trzech etapów:

  • klient wysyła do serwera pakiet z flagą SYN, która oznacza, że chce on nawiązać połączenie;
  • serwer, który do tego czasu był w trybie listen, odbiera flagę SYN, po czym wysyła SYN-ACK, co oznacza, że serwer jest gotowy na nawiązanie połączenia;
  • ostatnim etapem jest wysłanie przez klienta pakietu z flagą ACK, która sygnalizuje rozpoczęcie połączenia.
Oczywiście, kiedy łączymy się z serwerem podczas korzystania z internetu, proces ten odbywa się automatycznie. Jednak ponieważ jest to artykuł o craftowaniu pakietów, pewnie się spodziewacie, że w tym wypadku sami stworzymy takie połączenie, mając wpływ na wszystkie parametry.

Skrypt zestawiania takiego połączenia z użyciem Scapy prezentuje Listing nr 1:

Jak można łatwo zauważyć, mamy wpływ na wszystkie używane parametry, ale prześledźmy to od początku.

W parametrze IP możemy ustawić zarówno źródło, jak i cel dla naszego pakietu.

Nie użyłem tutaj parametru src = ‚adres_IP_źródła’, co sprawia, że w pakiecie pole to zostanie uzupełnione automatycznie adresem IP przypisanym do mojego komputera. Parametr dst = ‚adres_IP_celu’ zawiera  docelowy adres IP, może to być adres www, jak w naszym przypadku, lub po prostu adres IP.

Pakiet TCP daje możliwość ustawienia takich parametrów jak:

  • sport  –  port, z którego wysłany zostanie pakiet,w tym przypadku będzie to losowo wybrana wartość z puli 1024-65535;
  • dport  –  port, na który zostanie wysłany pakiet, mamy tutaj do czynienia z HTTP, co z góry
  • oznacza port 80;
  • flags  –  flaga, jaką przypiszemy pakietowi, ponieważ jest to inicjacja połączenia, jest ot ‚S’, dla kolejnych stanów używa się kolejno ‚SA’ i ‚A’;
  • seq –  sekwencja, na tym etapie może zostać wylosowana.

Fragment SYNACK=sr1(SYN) jest bardzo ważnym elementem całego kodu, odpowiada za wysłanie flagi SYN i odebranie odpowiedzi, która zostanie zapisana w zmiennej SYNACK.

Flagę ACK tworzymy analogicznie jak SYN, używając jednak wartości otrzymanych w SYN-ACK.

Jeżeli ktoś jest bardzo ciekawy ostatnich dwóch parametrów odsyłam do poniższego artykułu, jest to bardzo ładnie i rzeczowo wytłumaczone.

Ostatni print w skrypcie wyświetla sposób nawiązywania połączenia:

Rysunek 1. Nawiązywanie połączenia przy pomocy skryptu.

Skaner sieciowy

Skoro wiemy już jak wysłać pakiety TCP SYN oraz potrafimy wybierać docelowe IP i porty, jest to wystarczająca wiedza, by zbudować skaner sieciowy (coś na kształt mini nmapa z opcjami, które są nam potrzebne w danym momencie). W tym wypadku podajemy adres docelowego hosta, a skaner szuka otwartych portów dla podanego w kodzie zakresu portów.

Tutaj kod jest bardziej skomplikowany, został on przedstawiony na Listingu nr 2:

Zmienna ip to adres IPv4 celu, który chcemy przeskanować w poszukiwaniu otwartych portów, closed i openp musiały zostać zdefiniowane, wrócimy do nich potem.

Funkcja is_up() pozwala zaoszczędzić skanerowi dużo czasu. Sprawdza, czy host jest w ogóle dostępny, by skaner nie szukał otwartych portów hosta, którego nie ma w danej sieci. Może obco brzmiący protokół ICMP, jest znany pewnie raczej z funkcji ping. Tak,  na początku wysyłamy do maszyny, którą chcemy sprawdzić, ping, jeżeli dostanimy odpowiedź, oznacza to, że możemy przystąpić do skanowania. Żeby wszystko było jasne, parametr timeout sprawia, że funkcja czeka przez 5 sekund na odpowiedź, jeżeli do tego czasu nie nadejdzie, wtedy zwróci False.

Następne szczegóły:

  • start_time nie jest niezbędny, ale dzięki temu będziemy mogli określić czas skanowania
  • ports daje możliwość ustalenia zakresu portów, które chcemy przeskanować, w tym wypadku są to te najciekawsze pierwsze 1024.

Teraz najważniejsza część skanera, czyli mechanizm analizy odpowiedzi od skanowanego hosta.

Pierwszy warunek, który musi zostać spełniony, by zadziałała reszta kodu – musimy dostać odpowiedź.

Jeżeli taka odpowiedź nadejdzie, trzeba przeanalizować flagi TCP, jakie niesie ze sobą odpowiedź z hosta. Podstawowe flagi i ich postać w prawdziwym pakiecie to:

ACK = 0x10
RST = 0x04
SYN = 0x02
FIN = 0x01

Proste matematyczne obliczenia tłumaczą pozostałą część:

  • 0x12 oznacza flagę SYN/ACK: port jest w stanie ‚open’. Ponieważ nie chcemy ustalać połączenia, wysyłamy w odpowiedzi flagę RST.

Nie wysłanie tej flagi może spowodować przypadkowy atak na skanowany host, o tym za chwilę w dalszej części artykułu.

  • 0x14 oznacza flagę RST/ACK: port jest w stanie closed.

Rysunek 2. Przykładowe działanie opisywanego skanera.

Podsumowanie

Pokazałem w tej części podstawy pisania skryptów przy pomocy Scapy. O ile w dalej skupię się bardziej na ofensywnym aspekcie tego narzędzia, myślę, że do tej pory moje przykłady obrazują, jak duże ma ono możliwości. Jeszcze tylko słowo podsumowania odnośnie skanerów.

Ten, który pokazałem, sprawdza dane porty dla wybranego hosta. Jednak w bardzo prosty sposób skanery można modyfikować i rozwijać. Dzięki temu możemy stworzyć spersonalizowane narzędzie, działające dokładnie w taki sposób, jakiego potrzebujemy.

Ofensywna strona Scapy

Skoro Scapy daje taki szeroki wachlarz możliwości związanych z craftowaniem pakietów, może to być bardzo przydatne narzędzie podczas przeprowadzania różnych testów bezpieczeństwa. Następne kilka przykładów będzie związane z atakami DOS/DDOS. Dobrym fundamentem do dalszej części tego artykułu będzie odświeżenie sobie tej tematyki.

Najprostszy ping w Scapy można wysłać za pomocą (Listing nr 3):

Mała modyfikacja w tradycyjnym pingu, dodajemy do naszego pakietu duży pakiet śmieciowych danych (Listing nr 4):

Działanie programu oraz odpowiednio pofragmentowane pakiety można obserwować w Wiresharku

Rysunek 3. Działanie programu w Wiresharku.

Przy odpowiednio dużym pakiecie (duża ilość ‘śmieci’ dołączonych do wiadomości) taki ping może sprawić problemy systemowi, do którego został  wysłany.

I w prosty sposób pakiet ICMP zmienia się w Ping of Death, jeszcze w latach 90. w ten sposób skonstruowany request mógłby na pewno spowodować sporo problemów ;).

Ping flood

Z perspektywy atakującego powyższy przypadek na pewno jest dość mizerny. Moc programowania daje możliwość małego upgrade’u tego ataku. Najważniejsze, że źródłem ataku jest jeden adres IP. Po pierwsze, w ramach obrony wystarczy zablokować taki adres, a po drugie – wydaje się, że nie jest najlepszym pomysłem wykonywanie takiego ataku ze swojego adresu IP.

Czy można spróbować wykonać DDOS przy pomocy Scapy?

Małe modyfikacje, które  możemy wprowadzić. prezentuje Listing nr 5:

Generujemy tutaj losowe adresy IP, z których cel zostaje ‘zalany’ ping requestami.  Obecnie nie jest to tak duży problem, jak dawniej, złote czasy tego ataku to połowa lat 90.

Rysunek 4. Przykładowe działanie programu.

Tutaj przykład takiej komunikacja obserwowanej w Wiresharku:

Rysunek 5. Komunikacja z ataku w Wiresharku.

Atak DDOS Smurf

Wymienione powyżej ataki były możliwe często dzięki małej przepustowości, jaką dysponował atakowany serwer. Cała sztuczka polegała na wygenerowaniu jak największego ruchu przy jak najmniejszym nakładzie ‚pracy’.  Dlatego ping flood ewoluował w DDOS Smurf attack (najbardziej popularny pod koniec lat 90.).

Modyfikacje, jakie możemy wprowadzić to:

  • dodanie adresu, na który będą wysyłane ping requesty
  • zmiana adresu w taki sposób, by źródłem był atakowany komputer, a celem ataku prawdziwa  ofiara w danej sieci (jak na schemacie).

Rysunek 6. Schemat ataku w rozbudowanej wersji. [Źródło]

Rysunek nr 6 prezentuje komunikację,  jaką udało się zaobserwować z atakującej maszyny, której adres to  192.168.1.108. Jak widać, komputer o adresie 192.168.1.109 został ‘zmuszony’ do wysłania pinga na inny adres (w tym wypadku broadcast danej sieci).

Rysunek 7. Komunikacja z ataku w Wiresharku.

Skoro mowa o wysyłaniu pakietów TCP poruszę tu też temat pewnych ciekawych podatności Windows Server 2003 :). Klasykiem był Land attack (https://en.wikipedia.org/wiki/LAND) na porty, które po takim działaniu crash’owały cały system (Listing nr 6).

Nie ma tutaj nic skomplikowanego, po prostu zbyt duża ilość TCP SYN requestów. Nie należy jednak mylić go z TCP SYN flood, który opisany został poniżej.

TCP SYN flood

Kolejny rodzaj ataku DOS, który jest nadal aktualny i bywa problematyczny. Wiąże się to ze sposobem działania protokołu TCP (TCP handshake, o którym pisałem powyżej). Kiedy serwer przetworzy SYN request, wysyła SYN-ACK i czeka na ostatnią część procesu, czyli ACK wysłane przez klienta. Serwer zostaje ‚zasypany’ dużą ilością requestów, na każdy z nich odpowiada i czeka na nawiązanie połączenia, które nie nadchodzi. To doprowadza go do momentu, w którym utrzymuje tysiące otwartych połączeń, oczekujących na nawiązanie połączenia. Z tego powodu w pewnym momencie nowi klienci nie są już w stanie połączyć się do danego serwera.

Z technicznej perspektywy może wystąpić tu problem, kiedy komputer wykonujący atak może chcieć automatycznie wysłać flagę RST. Stanie się tak, ponieważ system wykryje wysłane zapytania, które nie zostały przekształcone w połączenie. Rozwiązanie tego problemu jest proste dla Linuxów,wystarczy dodać wyjątek do iptables:

Zablokuje to wysłanie resetu i umożliwi nawiązanie bardzo dużej ilości niepełnych połączeń. Kod został przedstawiony na Listingu nr 7:

W powyższym kodzie najciekawszą rzeczą, o której wcześniej nie wspominałem, może być dziwna wartość dla TTL (time to live). Systemy takie jak IPS czy IDS, bardzo często używają tego parametru do rozpoznania, z jakiego systemu operacyjnego został przeprowadzony atak. Wprowadzenie takiej wartości sprawi, że częściowo ‚zamaskujemy’ swoje dane.

Przykładowe działanie skryptu zostało pokazane poniżej. Można zauważyć, że będzie on przesyłał request tak długo, dopóki skrypt nie zostanie zatrzymany:

Rysunek 8. Przykładowe działanie skryptu.

 

Rysunek 9. Analiza przykładu z Wiresharka.

Po kilku nienawiązanych połączeniach serwer zaczyna się upominać o połączenie i wysyła TCP retransmission. Kilka minut później w wiresharku pakietów retransmission jest więcej niż wysyłanych TCP SYN.

Co by się jednak stało, gdybyśmy nie ustawili wyjątku w iptables?

Po każdym wysłanym TCP SYN i otrzymanym SYN-ACK nasza maszyna wysłałaby flagę RST do serwera,zapobiegając temu atakowi:

Rysunek 10. Analiza przykładu z Wiresharka.

 

Ethernet i Scapy

Powyżej wszystkie operacje miały miejsce w trzeciej warstwie ISO/OSI. Nie można jednak zapominać o tym, że Scapy doskonale radzi sobie z warstwą fizyczną, do której zostały stworzone dedykowane funkcje (srp, srp1,sendp itp.). Tutaj to narzędzie daje również dość dużo możliwości.

ARP ping

Skoro jedną z podstawowych operacji jakie można wykonać w sieci  jest ping, można go zasymulować dla drugiej warstwy. Główne polecenie programu wysyła zapytanie ARP pod IP celu i w zależności od odpowiedzi budowana jest odpowiedź programu – jak na Listingu 8.

Działanie programu jest proste do przewidzenia:

Rysunek. 11. Działanie programu z przykładu.

ARP skaner

Od funkcji wysyłającej request na adres MAC przypisany do odpowiedniego adresu IP nie jest daleko do stworzenia skanera. W tym wypadku będę chciał, by program wyświetlił mi adresy IP w mojej sieci oraz przypisane do nich adresy MAC z tablicy ARP (Listing nr 9).

Działanie programu:

Rysunek 12. Działanie programu z przykładu.

ARP spoofing

Skoro poruszyłem temat ARP-ów oraz Scapy, nie mogłem tutaj pominąć innego klasyka  w dziedzinie bezpieczeństwa sieciowego. Zatem krótko o tym, na czym polegają tablice ARP i atak ARP spoofing.

ARP jest protokołem pozwalającym na skojarzenie adresów warstwy sieciowej z warstwą fizyczną.

Oto jak może wyglądać tablica ARP:

Rysunek 13. Tablica ARP.3

ARP spoofing polega na „podłożeniu” fałszywego adresu MAC pod dany adres IP, co pozwala na oszukanie komunikacji w warstwie drugiej i przechwytywanie pakietów nie dedykowanych dla danego komputera.

Do tego celu użyję skryptu, który działa w następujący sposób:

  • na wejściu przyjmuje interface, docelowy adres IP oraz adres MAC, jaki chcemy do niego  przypisać;
  • po uruchomieniu program nasłuchuje, czekając na zapytanie ARP kierowane pod wskazany wcześniej adres IP;
  • gdy zostanie przechwycone takie zapytanie, program automatycznie generuje pakiet w sposób, jaki został zadany w skrypcie;
  • spreparowany pakiet zostaje odebrany przez cel i adres MAC zapisany do tablicy ARP.

Kod prezentuje się na Listingu nr 10:

Mała próba działania programu. Spróbuję przyporządkować dowolny adres MAC do losowego adresu z mojej podsieci (host ten jest w stanie down).


Rysunek 14. Działanie programu z przykładu: krok 1.

Najpierw sprawdziłem, czy na pewno wybrany adres nie występuje w tablicy ARP jednego z moich hostów. Następnie – gdy już wiem, że nie – próbuję wysłać ping na dany host. Jak można się spodziewać, ping nie przeszedł, otrzymujemy informację Host Unreachable.

Rysunek 15. Działanie programu z przykładu: krok 2.

Następnie ustawiłem mój skrypt na wcześniej wspomniany adres, docelowo chciałbym do niego przypisać MAC o wartości 01.02.03.04.05.06. Program zaczyna nasłuchiwanie.

Podczas próby wysłania pinga na 192.168.1.178 drugi raz, skrypt wychwytuje zapytanie ARP i automatycznie się uruchamia.

Rysunek 16. Działanie programu z przykładu: krok 3.

Praca naszego skryptu w tym momencie się kończy. Zobaczmy przebieg działań ze strony hosta, który wysłał pinga:

Rysunek 17. Działanie programu z przykładu.

W tym momencie nie otrzymujemy odpowiedzi: Host Unreachable, lecz host wysyła ping, ale nie dostaje odpowiedzi, ponieważ pod podanym adresem MAC nic nie ma.

Sprawdzenie tablicy ARP na maszynie wysyłającej ping pokazuje, że zawiera ona dane zgodnie z tym, co miał wykonać skrypt. Dla potwierdzenia zapis z Wiresharka:

Rysunek 18. Działanie programu z przykładu z Wiresharka.

 

Podsumowanie

Starałem się przybliżyć,  jak duże możliwości dają skrypty pisane  w Pythonie, przy użyciu Scapy. Wpływ na parametry wysyłanych pakietów daje bardzo dużo możliwości, wykorzystywanych od skanerów, przez przez skrypty wykonujące ataki aż do narzędzi służących do wykrywania oraz obrony. W tym wypadku granicą są umiejętności programistyczne i wyobraźnia użytkownika.

— Michał Wnekowicz

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



Komentarze

  1. Tomasz

    Fajnie opisane, konkretnie, bez zbędnego biadolenia ;)

    Odpowiedz
  2. bob

    fajny artykul, jestem poczatkujacy w tym temacie ale zauwazylem ze czesc osob zamiast scapy uzywa golang z gopacket podobno duzo lepsze niz scapy

    Odpowiedz
  3. posypka

    Świetnie przekazana wiedza! Zgrabnie, jasno i zwięźle opisane aspekty techniczne. Cieszę się, że pojawił się u Was artykuł z podstawowego zastosowania scapy, aż chce się testować u siebie … Czekam na więcej! :)

    Odpowiedz
  4. czytelnik

    Super opisany temat. czekam na więcej. przypomina mi to rozwiniecie zagadnień uzywanych niegdyś w backtrack lub obecnie kalilinux :)

    Odpowiedz
  5. AlphaTango

    Super artykuł. Niestety dla mnie za późno opublikowany bo do tego wszystkiego musialem dochodzić sam z Internetu plus książki. Mam nadzieję ze mnie wyprzedzicie i opiszecie forwarding np. kilku portów UDP przez jakiś wymyślony na biegu protokół (Ale nie ala tunel czyli gotowiec VNC lub ssh i w docelowej lokalizacji rozpakowanie tego ruchu.
    Ciekawe kto będzie pierwszy. Mam wrażenie że znowu ja.
    A przy okazji piszcie zawsze jakiej wersji kod dotyczy 2.7 czy 3.x

    Odpowiedz
  6. adam

    super wpis:)

    Odpowiedz

Odpowiedz