Na przełomie października i listopada organizowaliśmy dla Państwa konkurs typu Capture The Flag w ramach Europejskiego Miesiąca Bezpieczeństwa Cybernetycznego.
Pierwszy etap zadania rozpoczęło ponad 300 osób, do ostatniego dotarło ponad 60 osób, a trójka najszybszych, którzy przesłali poprawne rozwiązanie zadania to:
- Hubert Barc (rozwiązanie nadesłane 3 godziny i 22 minuty po rozpoczęciu konkursu),
- Sergiusz Bazański (5 godzin i 34 minuty),
- Piotr Florczyk (5 godzin i 37 minut).
Zwycięzcom serdecznie gratulujemy!
Wszyscy chętni, którzy nie wzięli udziału w konkursie mogą nadal sprawdzić swoje umiejętności na stronie https://ecsm2016.cert.pl.
Poniżej przedstawiamy również sposób rozwiązania wszystkich etapów konkursu.
Trojan
Zadanie zaczyna się od pobrania podejrzanego pliku ze strony https://ecsm2016.cert.pl. Po pobraniu warto zweryfikować czy hash zgadza się z podanym na stronie:
81e553e35dcccaaef8d9f534dd03bd9ba6ed33e2 ~/Downloads/suspicious
Jeśli tak, warto sprawdzić z czym mamy do czynienia:
/home/msm/Downloads/suspicious: python 2.7 byte-compiled
Wychodzi na to że jest to plik .pyc, czyli program w Pythonie skompilowany do kodu pośredniego. Możemy go uruchomić:
$ python ~/Downloads/suspicious.pyc
Traceback (most recent call last):
File "stage2/trojan/trojan.1.zip.packed.py", line 2, in
File "", line 19, in
File "", line 2, in
File "", line 34, in
File "", line 2, in
ImportError: No module named trojan
Nie uruchomi się on jednak poprawnie przez brakujący moduł „trojan”, ale widać, że idziemy w dobrą stronę.
Możemy analizować kod pośredni Pythona bezpośrednio, ale to bardzo zły pomysł – prościej użyć gotowego narzędzia (np. Uncompyle), które spróbuje odtworzyć oryginalny kod.
Skrypt jest dość długi i nie robi nic ciekawego (wszystkie rzeczy są delegowane do modułu trojan) – ale jest w nim zapisany nowy adres URL:
CNC_URL = 'https://secretpanel.ecsm2016.cert.pl'
CNC_PATH = '/get_command'
Trojan łączy się z adresem https://secretpanel.ecsm2016.cert.pl/get_command. Pod nim nie ma nic ciekawego, ale jeśli wejdziemy bezpośrednio pod secretpanel.ecsm2016.cert.pl zobaczymy panel webowy trojana.
Panel webowy, etap pierwszy
Wszystko poza /get_command wymaga zalogowania się i robi przekierowanie do /login. Musimy się więc w jakiś sposób zalogować.
Pierwszym problemem jest to, że nie znamy nazwy użytkownika, na którego można by się zalogować.
Na szczęście walidacja hasła nie jest zrobiona do końca bezpiecznie i umożliwia sprawdzenie czy użytkownik z podanym nickiem istnieje – dla użytkownika „aaa” otrzymujemy informację „Username is invalid”, ale po kilku próbach można zauważyć że istnieje np. użytkownik „admin”.
Drugim problemem jest to że nie znamy hasła. Na szczęście, twórca panelu popełnił tutaj książkowy błąd i możemy wykonać trywialne SQLi. Logujemy się do panelu z nazwą użytkownika admin i hasłem ' or 1=1 --.
Słowem wyjaśnienia dlaczego taki błąd występuje. Strony są podatne na SQLi, jeśli gdzieś w kodzie sklejane są polecenia SQL z niezaufanymi danymi (np. nazwa użytkownika lub hasło). Przykładowe, książkowe SQLi w PHP wygląda tak:
Dla użytkownika „admin” i hasła „kot” wykonane zostanie polecenie:
Co jest zgodne z zamierzeniami twórcy. Ale jeśli ktoś jako hasło poda kot' or 1=1 --, składnia zapytania zmieni się:
W ten sposób niezależnie od tego jakie jest prawdziwe hasło, zapytanie zawsze zwróci wszystkie rekordy i strona zinterpretuje to jako sukces przy walidacji użytkownika.
Zaszyfrowana komunikacja
Po zalogowaniu widzimy trochę więcej – mamy dostęp do komunikacji między administratorem a „hackerem”. Niestety, w pewnym momencie zaczyna ona być zaszyfrowana:
Problemy są dwa:
- Jak działa szyfrowanie (program szyfrujący do pobrania z https://secretpanel.ecsm2016.cert.pl/static/encryptor)?
- Jakie hasło zostało użyte do szyfrowania (z komunikacji wynika że hasło do komunikacji jest takie same jak hasło do panelu)?
Pierwszy problem możemy rozwiązać reversując dostarczoną binarkę. Jest ona dostarczona ze wszystkimi symbolami więc nie jest to zbyt trudne.
Najbardziej spodziewanym przez autorów rozwiązaniem było odwrócenie algorytmu programu szyfrującego (bardzo prostej modyfikacji RC4) i stworzenie własnego dekryptora na tej podstawie. Większość użytkowników konkursu poszła znacznie prostszą (więc lepszą) drogą – znalazła funkcję deszyfrującą (która była w binarce, chociaż nieużywana) i zmodyfikowała program aby z niej korzystał.
Funkcja szyfrująca wyglądała tak (w oryginale):
unsigned char state[256];
rc4keysched(state, key, key_size);
int a = 0, b = 0;
for (int i = 0; i < (int)data_size; i++) {
data[i] = (data[i] ^ rc4rand(state, &a, &b)) + i;
}
}
Gdzie rc4ksysched i rc4rand to książkowa implementacja rc4. Czyli cały algorytm można zapisać jako:
Więc żeby wyciągnąć z tego plaintext należałoby obliczyć:
Wspomnimy jeszcze tylko że innym możliwym rozwiązaniem tego etapu była kryptoanaliza algorytmu – było to trochę trudniejsze, ale ciekawsze (i nie wymagało znajomości RE).
Drugi problem to poznanie hasła użytego do szyfrowania. Znowu trzeba do tego wykorzystać SQL injection na stronie, ale tym razem trzeba wyciągnąć dane, a nie tylko wymusić zalogowanie się. Można to zrobić w tym przypadku za pomocą blind SQL injection – można było do tego albo napisać własne narzędzie, albo spróbować wykorzystać SQLmapa – oba podejścia dawały nam prawdziwe hasło użytkownika (MakeCyberGreatAgain).
Tajny chat
Odzyskany adres prowadził nas do aplikacji internetowej, która przedstawiała konwersację pomiędzy podejrzanymi. Celem zadania było odzyskanie flagi zawartej w jednej z wiadomości. Niestety ta była dla nas ukryta i była widoczna tylko dla jej autora.
Mogliśmy również wysyłać wiadomości, które były przez podejrzanego hackera odczytywane. Błąd w aplikacji polegał na braku filtrowania HTML w widoku pojedynczej wiadomości co umożliwiało przeprowadzenie ataku typu XSS. Mogliśmy wysłać kod JavaScript, który wykonał się w kontekście przeglądarki naszego podejrzanego oraz ukradł flagę z widocznej tylko dla niego wiadomości.
Potencjalny payload mógł wyglądać tak:
Odzyskana flaga oraz rozwiązanie całego konkursu to: ecsm{this.is.the.flag}.
