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.

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):

Debian over Tor

Z lekkim opóźnieniem, ale nadal news godny uwagi: Debian jest dostępny po sieci Tor. Najwidoczniej pozazdrościli Facebookowi, o którym wspominałem opisując uruchomienie strony w sieci Tor. 😉 Uzasadnienie uruchomienia jest następujące (i ładne):

The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others.

Dodatkowo, Tor zapewnia niezależne od zewnętrznych źródeł, „wbudowane” uwierzytelnianie i szyfrowanie treści – powiedzmy, że taki wbudowany HTTPS. Pełen katalog serwisów Debiana dostępnych via Tor dostępny jest tutaj, ale najważniejsze są chyba repozytoria pakietów.

Tor logoŹródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Przy okazji dowiedziałem się o load balancerze dla serwisów Tor.

Wpis jest pokłosiem dodania do czytnika RSS nowego serwisu Debiana, czyli micronews, który swoją drogą też wygląda ciekawie i być może pod względem technicznym będzie cegiełką do uruchomienia kolejnego projekciku…