Tag: security

Opublikowane w

MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako MauiBot. Dokładnie:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów. W User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS). A nawet , że są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów. Następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane. Bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Ostatecznie przestałem go obserwować na bieżąco przez cztery tygodnie i w zasadzie czekałem tylko, kiedy skończy pobierać i czy np. nie zmieni IP. Nie zmienił, za to pobierać przestał 20 sierpnia 2018. Tempo pobierania w ostatnich godzinach to ok. 335/h, pobierał ze wszystkich stron w grupach nie po 4, a po 8 requestów.

Opublikowane w

Google CTF begginers quest – wrażenia

O Google CTF dowiedziałem się zupełnym przypadkiem, prawdopodobnie info mignęło mi na Twitterze. Do głównego nie podchodziłem i z braku czasu, i umiejętności. Jednak stwierdziłem w sobotę, że pobawię się chociaż zadaniami dla początkujących przy kawie, czyli begginers quest. Pierwsze wrażenie jak najbardziej pozytywne, jest fabuła, jest estetyczna strona.

Google CTF screenshot
Google CTF screenshot – poza ostatnim dolnym te zadania albo umiałem rozwiązać, albo bardzo niewiele zabrakło

Zadanie pierwsze (letter) trywialne, zadanie drugie (floppy) też poszło szybko i… się wciągnąłęm. Zadanie trzecie (JS safe) już nie takie proste. Tzn. niby widzę o co chodzi, ale JS to nie moja działka, więc próbuję innej ścieżki. Na warsztat poszło zadanie z dolnej ścieżki (moar) i… wpadłem w mailny, niepotrzebnie walcząc z socat zamiast przejść do sedna. TBH zmyliło mnie zepsute wyświetlanie i liczyłem, że flaga będzie po prostu gdzieś w manualu, jak tylko naprawię wyświetlanie, tj. połączę się przy pomocy socat zamiast nc. Żeby było śmieszniej o prawidłowym rozwiązaniu też pomyślałem, ale… zafiksowałem się na tym, że najpierw wymagany jest socat i nie drążyłem tematu.

Postanowiłem zajrzeć w górną ścieżkę i… bingo, pierwsze zadanie (OCR is cool) wygląda na proste. Najwięcej czasu zeszło mi na OCR. Dda się znaleźć sensowne online, niemniej jak potem testowałem to najlepiej od kopa działał lios. Kolejne zadania idą dość szybko, choć nie zawsze do końca ortodoksyjnie. Utknąłem dopiero na Media DB. Oczywiście prawidłowo rozpoznałem i typ, i miejsce, gdzie jest luka ale… Zabrakło skilla, a w przykładach w sieci dominuje PHP, MySQL i… nieco inne payloady, niż wymagany. Jak się później okazało, chciałem to zrobić w sposób mocno przekombinowany. Chwilę powalczyłem, ale nie wiedząc, czy specyfika Pythona, czy SQLite, odpuściłem, robiąc finalnie sześć zadań.

Przyznaję, że CTF bardzo mi się podobał. Niestety trochę słabo z czasem stałem, poza tym, to jedna z pierwszych tego typu zabaw. Chociaż z tego co pamiętam w jakieś podobne zagadki kiedyś się okazjonalnie bawiłem. Przy czym może nie do końca się to CTF nazywało i bardziej związane ze steganografią były. Klimat nieco podobny jak przy konkursach związanych z programowaniem, choć tu się bardziej psuje/debuguje, niż tworzy. 😉

Tak czy inaczej polecam zabawę, jeśli ktoś ma chwilę. Przez jakiś czas serwis powinien jeszcze działać, choć nie jest już supportowany, można się pobawić (dlatego bez spoilerów). Bardzo staranne przygotowanie, choć zadania trochę trudne, jak dla początkujących i bardzo przekrojowe.

Jeśli komuś się znudzi, albo po prostu utknie, to Gynvael pokazywał na YouTube rozwiązanie wszystkich zadań z Google CTF dla początkujących na żywo. Jest podział na zadania, można przeskoczyć do wybranego, co się przydaje, bo materiału trwa prawie cztery godziny.

Co do samego streamu mam mieszane uczucia. Z jednej strony bardzo fajnie i live, z drugiej trochę chaosu i momentami dłużyzn. Ale takie są uroki rozwiązywania na żywo. Za to jest klimat i wytłumaczenie okolic i przyległości. Gdyby coś było za szybko lub niezrozumiałe, to materiały powinny już być na GitHubie. Zatem ostatecznie polecam, tym bardziej, że nie kojarzę innego miejsca z kompletem rozwiązań.

Okazało się, że brakuje mi porządnego deassemblera. Moje hexedytory też nie do końca spełniają oczekiwania (lub nie umiem ich sprawnie używać). Ale przede wszystkim muszę dojść do porozumienia z terminalem, bo w zadaniu Fridge TODO list zamiast bannera widzę krzaki. I szczerze mówiąc myślałem, że pozbycie się ich to część zadania, dopiero ww. stream pokazał, że zupełnie nie o to chodzi… 😉

UPDATE: Tu znajdziesz wpis o Google CTF 2019.

Opublikowane w

Entropia w Linuksie – HOWTO

Dawno temu pojawił się mit, że źródłem prawdziwej entropii w Linuksie jest /dev/random jest, /dev/urandom jest gorszy. Pokutuje on do dziś i część softu za źródło danych przyjmuje właśnie /dev/random, niezależnie od realnych potrzeb. Ilość losowych danych w systemie nie jest nieskończona i zależy od dostępnych źródeł i zdarzeń zewnętrznych. Dopóki komputery były głównie fizyczne, często obsługiwane przez ludzi, problem był nieco mniejszy. W epoce wirtualek systemy i ruch są coraz bardziej powtarzalne, więc z „prawdziwą” entropią są problemy. A entropia w systemie Linux nadal jest w systemach aplikacjom potrzebna – słusznie lub nie, chyba nawet bardziej niż kiedyś, bo szyfrowanie wszystkiego jest coraz bardziej popularne i wykorzystywane są coraz silniejsze algorytmy.

Od pewnego czasu (okolice wersji 3.7) kernel Linuksa potrafi co prawda korzystać ze sprzętowych modułów (TPM) zapewniających źródła losowych danych, o ile takie są obecne. Nie każdy sprzęt jest jednak w to wyposażony, nie każda wirtualka posiada dostęp do danych z hypervisora i obecność modułu nie oznacza jeszcze, że dane będą dostępne dla programów, więc problem nadal pozostaje.

Entropia w systemie Linux – sprawdzenie dostępności

Jeśli nie wiemy, czy faktycznie system ma problem z dostępną entropią, możemy to w prosty sposób sprawdzić. Aktualną ilość można odczytać przez wydanie polecenia:

cat /proc/sys/kernel/random/entropy_avail

Oczywiście jest to wartość chwilowa, zmieniająca się w czasie, żeby z całą pewnością stwierdzić, jak system stoi z entropią, trzeba by poobserwować w dłuższym czasie, a najlepiej monitorować ją, np. przy pomocy Zabbiksa. Wartość powyżej 1000 oznacza, że na pewno problemu nie ma, wartości poniżej 300 oznaczają, że prawie na pewno są niedobory, mogące wpływać na pracę usług.

rngd

Istnieją dwa rozwiązania, które pomogą zwiększyć ilość dostępnych danych losowych w systemie. Pierwsze z nich, to rngd z pakietu rng-tools. Jego zadanie jest proste – dostarczać dane do napełniania /dev/random korzystając ze wskazanego źródła.

Jeśli platforma posiada sprzętowy moduł dostarczający dane losowe, rngd warto skonfigurować, by z niego korzystał. W tym celu w pliku

/etc/default/rng-tools

należy umieścić linię

HRNGDEVICE=/dev/hwrng

Natomiast w przypadku braku takiego modułu, sugerowane jest dodanie linii

HRNGDEVICE=/dev/urandom

Kontrowersje korzystania z /dev/urandom

Korzystanie z /dev/urandom jako źródła danych dla /dev/random powoduje kontrowersje. Główne zarzuty to niegwarantowana losowość danych w /dev/urandom (ale patrz mit), oraz powstawanie sprzężenia zwrotnego, co łącznie może powodować okresowość, a zatem teoretyczną możliwość przewidzenia stanu generatora liczb pseudolosowych. Podkreślam, że jest to możliwość czysto teoretyczna, nie wykazana w praktyce.

Alternatywa dla rngd

Istnieje drugie popularne rozwiązanie programowe, które pozwala na zwiększenie dostępnej w systemie entropii w systemie Linux. Jest to demon haveged z pakietu o tej samej nazwie. Korzysta on z faktu, że czas wykonania kodu przez procesor jest mało powtarzalny i zależy od wielu czynników. Jest to rozwiązanie obecne w dystrybucjach od wielu lat, proste w użyciu.

Wybór rozwiązania

Jeśli system posiada moduł sprzętowy, to bym z niego korzysał, za pośrednictwem rngd. Czy haveged jest lepszy od rngd zasilanego z /dev/urandom? Nie podejmuję się odpowiedzi na to pytanie. Oba zapewniają najważniejszą sprawę, czyli dostępność danych losowych. Oba rozwiązania spełniają proste testy badające losowość danych. Osobiście uważam, że w większości przypadków rozwiązanie korzystające z rngd jest wystarczające. Tam gdzie do losowości danych przykładamy dużą wagę, nie powinno być problemu z dostępem do sprzętowych generatorów, a niedobory entropii zawsze są bardziej szkodliwe, niż jej teoretycznie niższa jakość.

Linki

Na koniec zbiór linków dotyczących zagadnienia jakim jest entropia w systemie Linux; zarówno źródła jak i dalsza lektura, czyli ciekawe linki (kolejność losowa):