WEP: Chopchop (z klientami wifi)

Chopchop jest stosunkowo nowym i całkiem skutecznym atakiem na WEP (jeśli interesuje Cię teoria - zapraszam na google). Zaczniemy od najbardziej normalnej sytuacji - AP do którego podłączony jest przynajmniej jeden klient wifi.

Tradycyjnie już - uruchamiamy kismet lub airodump-ng (airodump-ng ath0) i obczajamy na którym kanale, z jaką nazwą (SSID) i access pointem działa nasza sieć korzystająca z WEP. Na potrzeby tego dokumentu zakładam, że nie działa tam filtrowanie MAC a SSID nie jest ukryty (jak sobie z nimi poradzić możesz przeczytać na mojej stronie). OK, niech naszą testową siecią będzie "my_wep" (SSID) działająca na kanale nr 11. Otwieramy sobie nowy terminal i uruchamiamy airdump-ng w ten sposób, aby nasłuchiwał na naszym kanale (-c 11), przechwytywał tylko IV (--ivs) a wszystko zapisywał do pliku (-w zapis_chop):

Po chwili możemy się zorientować, że do naszej sieci przyłączony jest tylko jeden klient (00:0E:2E:8A:2B:DB) a liczba przechwycona do tej pory IV nie jest zachęcająca (#Data = 147):

Zamiast czekać, aż liczba słabych wektorów wzrośnie w okolice 150 czy 500 tysięcy - otwieramy nowe okienko i startujemy. Najpierw fakeauth - tutaj podstawiamy się pod adres 00:20:A6:B0:C2:53:

Niech sobie wysyła, my otwieramy kolejne okienko i przystępujemy do sedna:

Co my tu mamy? Uruchomiliśmy aireplay-ng z opcją chopchop, jako "cel" wskazaliśmy mu aktywnego (prawdziwego, legalnego itp.) klienta gadającego z AP. Czekamy na pakiet, którego nadawcą lub odbiorcą jest wskazany klient. Z doświadczenia wiem, że najlepiej sprawują się w tym miejscu ARPy (wysyłane przez klienta do "broadcasta"). Przykładowy wynik pojawia się naprawdę szybko:

I teraz tak - dużo zależy od naszego szczęścia (a dokładniej - od AP do którego próbujemy się wbić). Różne AP akceptują - bądź nie - różne "dziwactwa" do nich wysyłane (chopchop jest atakiem "aktywnym", w trakcie pracy, która za chwilę nastąpi zasypie AP różnymi nieprawidłowymi pakietami). Powiem tak: atak się uda.. no chyba, że się nie uda. Dlatego trzeba próbować.

W naszym przypadku przed odpowiedzią "y" zapamiętujemy (zapisujemy, robimy screenshota, kopiujemy & wklejamy) BSSID, Dest i Source. A, z powyższego obrazka można dowiedzieć się, że AP (Source) wysyła coś klientowi (Dest). Zaczynamy. Jeśli akcja się nie uda - próbujemy dalej czekając na przechwycenie innych pakietów. I tak do skutku:

Trwa to kilka minut i w końcu możemy ujrzeć koniec działania programu:

Mamy dwa pliki - .cap, który w zasadzie nie jest nam potrzebny, ale korzystając np. z tcpdump (tcpdump -n -v -e -s0 -r plik_dec.cap) możemy dowiedzieć się, co było przesłane, od kogo, do kogo (w tym miejscu często idzie obczaić adresy IP stosowane w sieci, w szczególności adres IP AP). Drugim, ważniejszym dla nas plikiem jest .xor - dzięki niemu i programowi packetforge-ng wygenerujemy nowy plik .cap, który wstrzykiwany będzie (tj. powinien) generować setki nowych IV. Może od razu przykład:

Po "-a" podajemy BSSID (MAC AP), po "-h" MAC z naszego fakeauth, po "-l" powinien znaleźć się adres IP AP ale wartość 255.255.255.255 działa w większości przypadków (adres ten możesz wyczaić np. kismetem lub próbować wspomnianego przed chwilą tcpdumpa). Po "-k" powinien nastąpić adres dowolnego klienta z sieci, w której pracuje klient i AP ale 255.255.255.255 działa w większości przypadków. Po "-y" wprowadzamy nazwę wyprodukowanego przed chwilą pliku .xor. I w końcu po "-w" podajemy nazwę pliku, który ma zostać wygenerowany. Uff.... Pozostała nam rzecz ostatnia - rozpocząć jego wstrzykiwanie korzystając a aireplay-ng:

Jak widzimy na załączonym obrazku - za chwile zaczniemy wstrzykiwać nasz plik do sieci. Po udzieleniu odpowiedzi twierdzącej - o ile AP przyjmnie to, co stworzyliśmy - liczba IV w pierwszym naszym oknie powinna zacząć galopować. Baaardzo szybko. Jeśli coś jest nie tak - musimy wrócić do packetforge-ng. I to by było chyba tyle. No a mając już odpowiednią liczbę IV możemy chwytać się aircrack-ng.

Teraz czas na parę drobiazgów.
Po pierwsze atak chopchop może się nie udać, jeśli AP jest na niego odporny. Coś, czego przeskoczyć nie można. Pierwszym miejscem, w którym coś może nawalić jest "aireplay-ng --chopchop...". Jeśli oprogramowanie AP stwierdzi, że dzieje się coś złego - może przestać przyjmować złe pakiety w dowolnym momencie (np. "przy 68% done"). Być może przechwyciłeś pakiet, który do tego się nie nadaje. A może to AP? Ten etap należy przejść przynajmniej kilka razy zanim "odpuścisz". Drugim miejscem poślizgu może być packetforge-ng. A dokładnie jego składnia. Jeśli nie idzie - w miejsce przełączników "-k" i "-l" wpisz odpowiednie adresy IP. Jeśli ciągle nie idzie - zamień te adresy miejscami (błąd drivera w którejś wersji). Kombinuj. Dobrym miejscem na szukanie pomocy jest forum aircracka (adres w "linkach"). I jeszcze jedna uwaga - jeśli przechwycisz komunikację między dwoma klientami (Source i Dest różne od siebie i od broadcasta) - spróbuj dodać przełączniki "-o" i "-j" do packetforge-ng. No i trzecie miejsce, w którym coś może nie wypalić - ostatni etap - wstrzykiwanie ("interactive"). Przyczyny dlaczego nie działa możesz nigdy nie poznać. Niektóre typy AP po prostu tak mają. Wówczas można próbować metody klasycznej lub fragment.

A, byłbym zapomniał. Pakiecik, który bardzo dobrze się sprawdza:

...rozmiar 68, od klienta do "broadcasta" - prawie na pewno ARP - i prawie na pewno tcpdump wyczyta z niego IP AP i klienta.