Jak zacząłem zabawę z CTF, czyli błądzić jest rzeczą ludzką

Wstęp

Wśród osób związanych bezpieczeństwem teleinformatycznym oraz pasjonatów z całego świata dość popularne są turnieje znane jako Capture The Flag (lub w skrócie CTF). Czym są i na czym polegają CTF-y dość dokładnie opisał na swoim blogu Gynvael Coldwind (kapitan polskiego teamu CTF Dragon Sector) we wpisie Rok CTFów z Dragon Sector  oraz Dragon Sector Update: top1 w sezonie 2014 .

Polecam także prezentację z zeszłorocznej konferencji CONFidence 2014 w Krakowie CONFidence 2014: On the battlefield with the Dragons, na której Gynvael wraz z Mateuszem „j00ru” Jurczykiem (również z Dragon Sector) zaprezentowali kilka interesujących zadań z wybranych CTF-ów.

Tyle tytułem wstępu. Celem niniejszego artykułu nie jest bowiem opis, czym są i na czym polegają tego rodzaju turnieje, lecz przedstawienie zagadnienia z punktu widzenia totalnego „żółtodzioba”, który postanowił sprawdzić się w boju.

Zaczynamy

Jeśli ktoś chciałby rozpocząć swoją przygodę z turniejami CTF, pierwsze kroki może skierować w stronę serwisu http://ctftime.org, będącym swoistym agregatorem informacji o turniejach, teamach, uczestnikach i rankingach zawodów odbywających się na całym świecie. Po założeniu konta (co nie jest koniecznością, by brać udział w poszczególnych zawodach) możemy rozpocząć zabawę albo jako jednoosobowy zespół, albo spróbować dołączyć do jednej z już istniejących drużyn.

1. Serwis ctftime.org – „brama” do świata CTF – kalendarz imprez, drużyny, zawodnicy, rankingi, statystyki.

Ponieważ od początku nastawiony byłem na grę w pojedynkę, od razu w kalendarzu poszukałem informacji o najbliższym wydarzeniu.

Pierwszy turniej

Okazał się nim Ghost In The Shellcode 2015  – odbywający się jako impreza towarzysząca konferencji Shmoocon w Waszyngtonie w Stanach Zjednoczonych. Sam turniej składał się z kilku faz, ja wziąłem udział jedynie w ostatniej, finałowej rozgrywce on-line, w dniach 16-18 stycznia.

Ze względu na napięty grafik zajęć, nie mogłem poświęcić wystarczająco dużo czasu na udział (co było jednym z błędów, jakie popełniłem, ale o tym w dalszej części artykułu). Postanowiłem jednak za wszelką cenę zdobyć jakiekolwiek punkty w klasyfikacji (byłem bardzo naiwny, choć koniec końców jeden punkt wpadł…) i z tą myślą w piątek o 21:30 naszego czasu, gdy zawody oficjalnie ruszyły, wszedłem na stronę turnieju.

Let’s go!

Moim oczom ukazała się strona główna Ghost In The Shellcode z listą zadań oraz aktualizowanym rankingiem dwudziestu najlepszych drużyn.

Wyzwania podzielone były na kategorie (m.in. Forensic, Crypto, Programming, Web, Pwnable). W każdej z nich zadania oznaczone zostały ilością punktów do zdobycia w zależności od stopnia trudności (od 100 do 400 punktów). Większość zadań z początku była niedostępna (w tym te łatwiejsze). Organizatorzy co jakiś czas odblokowywali kolejne, a lista z lewej strony ekranu pokazywała aktualny postęp najlepszych teamów.

1. Strona główna CTF Ghost In The Shellcode już po zakończeniu zawodów – lista zadań i klasyfikacja 20 najlepszych drużyn

Zabrałem się za rozwiązanie jedynej zagadki w kategorii Trivia, wartej jeden punkt, polegającej na odgadnięciu „What is the biggest name in CTF? (strlen)” (dosłownie taka była jej treść).

Błądzić jest rzeczą ludzką

I już tu popełniłem kolejny błąd. Założyłem, że skoro jest to CTF, to musi być w tym zadaniu coś podchwytliwego – postawiłem na „(strlen)”, będący m.in. w językach C, C++ czy PHP funkcją sprawdzającą długość ciągu znaków podanego jako jej argument. Oczywiście był to zły trop i rozwiązaniem wcale nie była długość ciągu „What is the biggest name in CTF?” ani żadna wariacja na ten temat. Po całej serii desperackich i nieudanych prób zastosowania funkcji strlen() we wszystkich możliwych, znanych i nie znanych mi językach zatrzymałem się na chwilę. „Co może oznaczać to pytanie?”, „Jak powinna brzmieć odpowiedź?”. Rozwiązanie okazało się banalne, ale go nie podam – sami możecie spróbować odgadnąć, co autorzy mieli na myśli :)

Podbudowany pierwszym zdobytym punktem (i jak się później okazało, jedynym), ochoczo zabrałem się do kolejnego wyzwania (’Knockers’ z kategorii Crypto). Polegało ono na wysłaniu do zdalnego serwera odpowiednio zmodyfikowanego tokena w taki sposób, by serwer odpowiedział na określonym porcie. Niestety, musiałem przerwać analizę napisanego w Pythonie skryptu, który realizował owe połączenia (eh, te domowe obowiązki…), a po powrocie do komputera po kilku godzinach zauważyłem kolejne dostępne zadania i postanowiłem spróbować swoich sił w którymś z nich.

Padło na zadanie 'cloudfs’ z kategorii Forensic. Na początek, po rozpakowaniu załącznika w postaci archiwum, moim oczom ukazał się plik .pcap, będący zapisem transmisji sieciowej z jednym z serwerów w domenie wikipedia.org. Transmisja składała się w zasadzie z samych pakietów ICMP (było ich ponad trzy i pół tysiąca), a dokładna analiza zawartości sekcji 'data’ pakietów pozwoliła odnaleźć ciąg 'key.tbz’ w pakiecie numer 995. W międzyczasie odkryłem również powtarzające się ciągi 'apple’, 'banana’, 'juiced apple’, '@bonus’ oraz dziwny ciąg 'contenttttt’ (była to jednak klasyczna „zmyła”, jak w przypadku „strlen” z pierwszego zadania). Większość z tych pakietów mieściła się w kilkudziesięciu bajtach, ale sporo było też takich o rozmiarze 1066 bajtów. Uznałem, że tam właśnie ukryte jest archiwum key.tbz, zawierające kolejną wskazówkę, a być może nawet sam klucz. Niestety, okazało się to ślepą uliczką, choć z drugiej strony mój tok rozumowania okazał się prawidłowy. Co kryło się w pakietach oraz jak należało wyciągnąć z nich wspomniane archiwum i dokończyć zadanie możecie przeczytać na blogu Tin Duong’a pod adresem http://blog.tinduong.pw/ghost-in-the-shellcode-2015-write-ups/

To był następny popełniony przeze mnie błąd – chaotyczne miotanie się pomiędzy zadaniami, żadnego z nich nie doprowadzając do końca. 'cloudfs’ pochłonęło mnie na tyle, że w zasadzie wyczerpałem całą moją rezerwę czasową na sobotę i na dokończenie 'Knockersa’ nie została mi już ani minuta. Utknąłem w martwym punkcie z dwoma rozgrzebanymi zadaniami i paroma godzinami zapasu w niedzielę do 19:00 naszego czasu, gdy turniej miał zostać zakończony.

Błąd powtórzyłem następnego dnia porzucając oba rozpoczęte ćwiczenia, gdy odblokowane zostało jedyne z kategorii Web – 'Aart’.  Zanim jednak wpadłem na właściwy trop zmierzający do pomyślnego jego rozwiązania wybiła godzina 19:00 i z wywalczonym na początku jednym punktem zakończyłem swój udział w pierwszym w życiu turnieju CTF. Całkowicie na tarczy, jak mawiali starożytni wojownicy ze Sparty.

Błędem numer pięć był brak odpowiedniego zaplecza. Szukanie, instalacja i sprawdzanie oprogramowania już w trakcie turnieju to kiepski pomysł, bo zabiera bardzo dużo cennego czasu i, co tu ukrywać, mocno dekoncentruje. Stąd moja rada początkującego dla początkujących: zgromadźcie odpowiedni zestaw narzędzi zanim zaczniecie udział w CTF-ie:

– konsola bash (warto postarać się o jakiś dobry emulator konsoli, jeśli korzystacie z systemów operacyjnych jej nie posiadających)
– dobry edytor heksadecymalny, pozwalający na wgląd i edycję dowolnego pliku na poziomie binarnym. Absolutne must-have.
– program do analizy ruchu sieciowego, ze wsparciem dla formatu .pcap (np. Wireshark)
– edytor tekstowy lub jakieś proste IDE, które umożliwi szybkie pisanie i uruchamianie skryptów. Większość zadań będzie wymagała zautomatyzowania pewnych czynności bądź napisania exploita i bez choćby podstawowej znajomości Pythona, Perla, Bash czy innego języka skryptowego spędzicie długie godziny na rozwiązywaniu metodą prób i błędów albo ręcznego testowania np. parametrów przekazywanych do serwera. Dobra wiadomość – Wasze umiejętności tworzenia takich skryptów będą rosły wraz z każdą napisaną linijką kodu – sam się o tym przekonałem
– przeglądarka internetowa z zestawem narzędzi developerskich (do zadań z kategorii Web) Tutaj nie będę jakoś specjalnie oryginalny wskazując na Chrome i Chrome Developer Tools, ale oczywiście jest to kwestia preferencji – ważne, by sprawnie się tymi narzędziami posługiwać. Mimo, że są to moje narzędzia na co dzień, a z racji wykonywanej pracy zawodowej znam je bardzo dobrze, ta umiejętność nie okazała się wystarczająca do wygrania turnieju :)
– proxy HTTP (Burp, OWASP ZAP) pozwalające analizować i modyfikować żądania HTTP

Powyższa lista to tylko początek, bo do wielu kategorii zadań, wymagających np. reverse engineering, dojdą następne (np. debuggery czy dekompilatory). Ważne, by zestaw narzędzi odpowiadał Waszym preferencjom oraz byście swobodnie się nimi posługiwali, by nie tracić czasu na zbędną walkę z nieznanym interfejsem już w trakcie turnieju (ja zmarnowałem na to łącznie około godziny – kolejny błąd, kolejna lekcja).

Jeśli ktoś lubi papierowe ściągi, warto zawczasu wydrukować sobie np. tablicę kodów ASCII wraz z wartościami dziesiętnymi i szesnastkowymi, encji HTML, czy składnię filtrów do Wiresharka/tcpdump. Szczególnie ta pierwsza przydaje się na każdym niemal kroku.
Don’t learn to hack, hack to learn (@BruteLogic)

Swojego występu w żadnym wypadku nie mogę zaliczyć do udanych, jednakże zdałem sobie sprawę z kilku istotnych kwestii, których w ciągu całego weekendu nie zauważałem.

Po pierwsze – nie można do udziału w CTF-ach przygotować się „systemowo”. Zadania wymagają rozległej wiedzy z wielu dziedzin (programowanie, kryptografia, sieci, reverse engineering, znajomość działania rozmaitych protokołów, systemów operacyjnych itd.) – nie do opanowania przez pojedynczego człowieka. No po prostu się nie da. Każde rozwiązanie to połączenie wielu technik, narzędzi i przede wszystkim myślenia i kombinowania.

Po drugie – zadania są z natury podchwytliwe, choć nie ma ograniczeń co do sposobu ich rozwiązywania (zakładam, że do ich zakończenia prowadzi co najmniej jedna, prawidłowa ścieżka). Jak powiedział na linkowanej na początku artykułu prezentacji Mateusz „j00ru” Jurczyk – „whatever works, it works”. To zmusza do próbowania różnych „wektorów ataku”, bo nigdy nie wiadomo, czy nie uda się pozornie trudnego ćwiczenia zakończyć banalnym odgadnięciem flagi czy po prostu klasycznym brute force. Pewne schematy pojawiają się wraz z nabywanym doświadczeniem (już przy trzecim zadaniu mniej więcej byłem w stanie zorientować się, co może być „fałszywym tropem”).

Po trzecie – byłem sam. Drużyny z czołówki, takie jak polski Dragon Sector, amerykańskie Samurai albo Plaid Parliament of Pwning (PPP) czy rosyjski More Smoked Leet Chicken to zespoły złożone z kilkunastu często wyspecjalizowanych w poszczególnych kategoriach „wymiataczy”. To pozwala im na podzielenie się zadaniami i pracę równocześnie nad kilkoma z nich.

Try harder (Offensive Security)

Co tak naprawdę daje udział w CTF? Przede wszystkim, na własnej skórze można przekonać się, co oznacza motto Offensive Security (Kali/Bactrack Linux, certyfikacje OSCP, OSCE) – „Try harder” (w wolnym tłumaczeniu: postaraj się bardziej).

CTF zmusza do szukania rozwiązań i nauki, nauki i szukania rozwiązań, ponownie szukania rozwiązań i nauki, poznawania nieznanych dotąd narzędzi, protokołów, formatów plików, algorytmów i wielu innych rzeczy (czy wspomniałem już o nauce i szukaniu rozwiązań?). Zdałem sobie sprawę z tego, gdy przejrzałem swoje notatki z całego weekendu. Nie jestem mocny, jeśli chodzi o sieci, jedno z zadań zmusiło mnie do przejrzenia RFC 792 na temat protokołu ICMP czy odświeżenia wiedzy z zakresu tworzenia filtrów dla tcpdump, kolejne – co oznacza np. zapis z pojedynczą i podwójną gwiazdką w argumentach metod w Pythonie albo do czego służy moduł 'struct’. To kilka z przykładów.

I choćby tylko z tego powodu udział w CTF jest świetnym sposobem na doskonalenie już posiadanych umiejętności i nabywanie nowych. Każda kolejna informacja czy praktyczna umiejętność wzbogaca „warsztat”, którego używamy na co dzień w pracy zawodowej – jako programiści, webmasterzy, pentesterzy czy administratorzy sieci.

Zadania nie są (w większości) czymś, na co można natknąć się w realnych scenariuszach ataków, ale techniki prowadzące do rozwiązania – już jak najbardziej tak. Turnieje te to swoisty poligon, sposób, by w pełni legalnie i bezpiecznie dla siebie i innych po prostu „hakować”.

Podsumowanie

Czy CTF-y mają jakieś wady? Na pewno są to pożeracze czasu  (sam udział jak i samo przygotowanie się czy późniejsze analizowanie rozwiązań już „na sucho” pochłaniają wiele godzin) – nie traktowałbym jednak tego w kategoriach wad. W zasadzie ciężko dopatrzeć się czegoś, co odstraszałoby od udziału. Subiektywnie rzecz biorąc – nie odczułem żadnych negatywnych konsekwencji.

Jak wspomniałem na początku, jednym z błędów, jakie popełniłem, było nie wygospodarowanie sobie tej odpowiedniej ilości czasu. Ghost In The Shellcode wypadł w terminie dla mnie dość niefortunnym, co spowodowało, że na grę nie mogłem przeznaczyć tyle czasu, ile powinienem lub bym chciał. GITS trwał łącznie niemal 48 godzin – i na taki wolny przedział czasowy trzeba się nastawić, gdy chce się wyciągnąć z zabawy jak najwięcej – zarówno punktów, jak i wiedzy (co oznacza w praktyce cały weekend, z lekkim kilkugodzinnym przesunięciem gdy turniej odbywa się w innej strefie czasowej).

Wiem jedno – złapałem bakcyla i już nie mogę doczekać się kolejnego CTF-a (w chwili pisania tego artykułu z kalendarza wynika, że będzie to Boston Key Party CTF 2015 w dniach 28. lutego – 1. marca). Tym razem jednak, bogatszy o doświadczenia zdobyte w trakcie debiutu w GITS, nie zamierzam popełnić tych samych błędów.

Was też gorąco zachęcam do spróbowania swoich sił (o ile już tego nie zrobiliście wcześniej ode mnie) i do podzielenia się swoimi wrażeniami. Niestety, pomimo wysokiego poziomu, jaki reprezentujemy na arenie międzynarodowej w branży IT, nasza reprezentacja w CTF-ach wypada dość mizernie. W czołówce znajdują się aktualni mistrzowie, czyli Dragon Sector oraz team Snatch The Root, który w klasyfikacji ogólnej w 2014 roku zajął 29. pozycję (na 5471 drużyn, które w ogóle zdobyły jakieś punkty).

Przydatne linki

https://ctftime.org/
http://blog.dragonsector.pl/
http://www.wykop.pl/link/2325106/dragon-sector-ama/

–bl4de