Grzegorz Trawiński: kto może zostać pentesterem?

Współpracuję z byłym programistą specjalizującym się w tworzeniu rozwiązań w oparciu o pakiet LAMP.

Kilka osób specjalizowało się wcześniej w testach manualnych czy automatycznych QA. Mamy chłopaka, bez tytułu magistra, a nawet inżyniera, który w pięć minut zagada Cię, jak manipulować procesami i pamięcią Windowsa, żeby otworzyć nową sesję terminala w kontekście NT AUTHORITY\SYSTEM.

Pracuje z nami były blue-teamowiec, który chwilę temu robił zmiany opalając się w nocy w blasku 12 monitorów wyświetlających alerty dotyczące ataków na infrastrukturę.

Ja sam pracowałem wcześniej jako programista .Net i to doświadczenie niesamowicie dużo rzeczy mi dziś ułatwiło, ale ostatecznie, tak sobie myślę, że background nie ma tak wielkiego znaczenia.

Co to są testy penetracyjne?

Testy penetracyjne to nic innego jak szukanie i identyfikowanie błędów w aplikacjach i systemach IT. Błędów mających wpływ ich bezpieczeństwo i bardzo często niezamierzonych, które zostały w systemie umieszczone przez przypadek obok niewinnej, poprawnie działającej funkcjonalności.

Kto może zostać pentesterem?

Każdy.

Kto może zostać ostatecznie ekspertem w tej dziedzinie? Tylko najlepsi.

No dobra, bez żartów – przede wszystkim jednostki ekstremalnie cierpliwe, które łatwo się nie poddają i notorycznie poszerzają swoją wiedzę z przeróżnych technologii.

Kiedy myślę o pentestowaniu, ciężko mi oderwać się od wyobrażenia bohaterskiego trio oprogramowania: programisty, testera QA oraz pentestera. Ten pierwszy, implementując jakąś funkcjonalność, stara się, aby spełniała ona swoje zadanie, obsłużyła wszystkie przypadki użycia i, powiedzmy, była odporna na błędy. Ten drugi sumiennie to weryfikuje, patrząc z perspektywy użytkownika końcowego czy ta funkcjonalność, aby na pewno spełnia swoje zadanie, dostarcza oczekiwaną wartość oraz czy przypadkiem nie działa w którymś miejscu niepoprawnie. Ten trzeci zastanawia się, gdzie ten pierwszy popełnił błąd w implementacji, a drugi nie zwrócił na niego uwagi. Chodzi o taki błąd, który można by było skutecznie wykorzystać na swoją korzyść.

Jak taka współpraca wygląda w praktyce?

Przykładowo, system typu CMS może posiadać funkcjonalność wyświetlania podstron w zależności od parametru p. Tester sumiennie sprawdził, że wszystkie oczekiwane podstrony zostały w aplikacji wyświetlone poprawnie i wspólnie z programistą mieli już fajrant. Natomiast Pentester sprawdzi, czy oprócz oczekiwanych stron, można zmanipulować parametr p w taki sposób, by wyświetlić nieoczekiwane strony.

Po kilku próbach i błędach może on znaleźć całkiem poważną podatność klasy path traversal, wymagającą podwójnego encodingu kropek i slash-a (ponieważ po drodze mamy dodatkowe nginx proxy, %252E%252E%252F). Może się okazać, że jesteśmy w stanie wyświetlić zawartość pliku /etc/passwd, ale /etc/shadow już nie (ze względu na poprawnie skonfigurowane uprawnienia). Po kilku kawach, możemy się natknąć na Easter Egg od jakiegoś podchmielonego administratora, który zostawił w jednym z katalogów plik shadow.bak. Niestety, schłodzony szampan musimy odłożyć na później, bo została skutecznie wdrożona silna polityka haseł i po kilku dobach ani john-the-ripper ani hashcat nie są w stanie zcrackować hashy haseł. Nie poddając się i dłubiąc, dosłownie dłubiąc, dalej w aplikacji natkniemy się wreszcie na plik konfiguracyjny, a w nim 256 bitowy ciąg znaków, niezbędny do poprawnego stworzenia podpisu HMAC tokenu JWT. Dzięki temu pentester może teraz stworzyć dowolny, poprawny token JWT i uwierzytelnić się w aplikacji jako jakikolwiek użytkownik, w tym administrator.

Przyjemnie się to czyta, ale takie błędy, są raczej rzadkością. Równie podobne i złudne wrażenie dają wyzwania typu Capture the Flag czy Hack The Box, które de facto są nastawione na sukces. Te spreparowane aplikacje czy systemy mają w sobie błędy i Ty o tym wiesz i w końcu te błędy znajdziesz.

Ta reguła niestety nie dotyczy prawdziwych aplikacji, w których nikt intencjonalnie nic nie zostawił, a nawet czasami postarał się, żeby je zabezpieczyć. Podczas naszego szkolenia uczestnicy otrzymali maszynę wirtualną z aplikacją webową, która zawierała błędy. Na jej podstawie mieli wykonać pentest oraz przygotować raport. Po tym ćwiczeniu kursanci otrzymali do testów prawdziwą aplikację webową przygotowaną przez zespół projektowy, która docelowo miała wylądować na hostingu u klienta.

Pamiętam, że dostałem pytanie “Grzesiek, jak mamy to testować, kiedy to jest zabezpieczone?” – no cóż, dokładnie tak samo jak poprzednią aplikację. Tylko najwyżej nie znajdziecie błędów.

Praca pentestera jest niewątpliwie trudna, niejednokrotnie żmudna i (może się wydawać) bezowocna. Wymaga specjalistycznej wiedzy i umiejętności technicznych, a spostrzegawczość i szybkie łączenie faktów są w tym zawodzie atutem. Nie wspominając o nieszablonowym myśleniu. Ostatecznie jest to też niesamowicie satysfakcjonujące zajęcie, zwłaszcza jeśli uda nam się zidentyfikować krytyczne błędy bezpieczeństwa, choćby raz na dziesięć różnych pentestów.

Lista potencjalnych błędów ciągle rośnie. Na pewno słyszałeś cokolwiek o SQL Injection czy Buffer Overflow – pytanie czy miałeś okazję słyszeć o Reflected File Download, Web Cache Deception czy HTTP Request Smuggling? Dzisiaj aplikacja wydaje się być bezpieczna, a jutro – przez nową klasę błędów – już nie.

Wszystkich chętnych lubiących łamigłówki i problemy (zazwyczaj trudne), czy po prostu pasjonatów cyberbezpieczeństwa zapraszam na szkolenie przygotowujące do pracy pentestera, gdzie przekażę Wam solidną porcję wiedzy na temat najistotniejszych błędów bezpieczeństwa aplikacji webowych oraz wspólnie rozpoczniemy rozwój warsztatu pentesterskiego.

Brzmi ciekawie? Zapisz się na następną edycję naszej Pentesting Academy.