Wprowadzenie
Cześć!
Ja jestem Kacper Szurek a to podcast Szurkogadanie, w którym opowiadam o różnych kwestiach powiązanych z bezpieczeństwem.
Dzisiaj nieco szerzej i dokładniej o poszukiwaniu błędów w ramach programów bug bounty.
Jeżeli chciałbyś się dowiedzieć jak rozpocząć swoją przygodę, na co zwrócić szczególną uwagę i jak to się po prostu robi - ten odcinek jest dla Ciebie.
W tym odcinku postaram się po krótce scharakteryzować każdy z podstawowych elementów, jakie towarzyszą bug huntingowi.
Zaczniemy więc od znalezienia programu i domen, które są z nim powiązane.
Ale warto posłuchać tego odcinka nawet jeżeli nie chcesz się zajmować bezpieczeństwem stron internetowych.
Wiedząc bowiem jak poszukuje się błędów, będziesz świadomy na co zwracać uwagę podczas tworzenia stron.
Więcej informacji na temat bezpieczeństwa znajdziesz na naszej grupie od 0 do pentestera na Facebooku.
Podcast ten można również znaleźć na Spotify oraz Google i Apple Podcasts oraz Anchor.
Zapraszam do słuchania.
Pieniądze
Jak to mówią najtrudniej zacząć.
W naszym wypadku najpierw musimy określić target - czyli firmę, którą jesteśmy zainteresowani.
I już na tym etapie musimy sobie odpowiedzieć na parę pytań.
Czy chcemy za poszukiwanie błędów otrzymać jakieś pieniądze?
Jeżeli tak - to jakie kwoty nas interesują?
Jeżeli nie - to czy interesują nas inne formy nagrody - chociażby koszulki czy drobne gadżety reklamowe?
A może chcemy to robić za darmo - dla sławy i ćwiczenia swoich własnych umiejętności?
Od odpowiedzi na te pytania zależy gdzie i jak będziemy poszukiwać stron, które będziemy testować.
Branża security przeżywa szybki wzrost.
Z jednej strony oznacza to zwiększone stawki za niektóre usługi.
Z drugiej jednak coraz większą konkurencję.
Prawdą jest, że duże firmy w stylu Google i Facebooka płacą spore kwoty za poważne błędy bez mrugnięcia okiem.
Także komunikacja z nimi jest przyjemna.
Znajdują się tam ludzie, którzy znają się na swojej pracy i doceniają to co robimy dla firmy.
Z drugiej jednak strony - nie tylko my przyglądamy się tym serwisom - a wiele tysięcy innych osób.
To oznacza, że próg wejścia jest dość spory.
Tak naprawdę możemy zapomnieć o szkolnych błędach w stylu OWASP Top 10.
Duplikaty
Jeżeli takowe istniały to albo zostały znalezione przez wewnętrzne zespoły bezpieczeństwa albo przez innych badaczy.
A jeżeli takie błędy nadal istnieją to mogą to być tak zwane duplikaty.
Można powiedzieć że duplikaty to zmora dzisiejszych programów bug bounty.
O co chodzi?
Jeżeli ktoś przed nami zgłosił ten sam błąd, ale nie został on jeszcze przez firmę naprawiony, to my za takie samo zgłoszenie, które nastąpiło później i tyczy się tej samej podatności - nic nie zyskujemy.
To sprawia, że spędzamy swój czas na tworzenie raportu na marne, ponieważ nie będzie z niego żadnych korzyści.
Dlatego też na początek proponowałbym od rozpoczęcia swojej przygody z mniej popularnymi programami.
Owszem, od czasu do czasu jesteśmy świadkami bardzo prostych podatności, które zostały wprowadzone przez czyjąś nieuwagę - ale ich odnalezienie zazwyczaj opiera się na nutce szczęścia.
Im mniejsza firma i witryna tym większe prawdopodobieństwo, że mało osób poświęciło jej uwagę.
To tym samym oznacza, ze nasze szanse się zwiększają, bo może ktoś przegapił coś co dla nas jest oczywiste.
Także programy które nie płacą mogą być dobre na początek.
Trzeba pamiętać, że na świecie istnieje grupa osób, która z poszukiwania błędów uczyniła swoją pracę.
Najlepsi są w stanie zarabiać milion dolarów rocznie tylko poprzez udział w programach bug bounty.
Ale, aby dotrzeć do takich pieniędzy - bierze się udział tylko w najlepiej płatnych programach.
Platformy
No dobrze, wiemy już jakich programów poszukujemy.
Gdzie zatem możemy znaleźć informacje na ich temat?
Obecnie istnieje przynajmniej kilka platform, które pośredniczą w poszukiwaniu błędów.
Zamiast więc zgłaszać nasze znaleziska bezpośrednio do firmy przy pomocy chociażby adresu email - zapisujemy swój raport na stronie internetowej należącej do pośrednika.
Dzięki temu - wszystko jest przejrzyste i czytelne.
Wszystkie nasze raporty do różnych firm znajdują się w jednym miejscu.
Poza tym, pośrednik za swoje usługi pobiera pewną opłatę.
Jest więc szansa, że będzie nam w stanie pomóc - jeżeli firma stwierdzi, że nasz raport jest zły lub takowa podatność nie istnieje.
Wystarczy więc wejść na stronę HackerOne czy też BugCrowd i poszukać programu, który nas interesuje.
Ale to nie jedyna możliwość.
Często zdarza się, że firmy informują o możliwości wysyłania błędów bezpieczeństwa w formie odpowiedniej podstrony.
Tam to informują potencjalnych badaczy gdzie należy wysłać błąd, publikują swoje klucze gpg a także wcześniejsze błędy, które zostały w taki sposób znalezione.
Można więc poszukiwać fraz powiązanych z tym tematem w Google w celu odnalezienia tego rodzaju witryn.
Takie podejście ma jedną przewagę.
Im łatwiej dany program znaleźć, tym więcej osób się nim najprawdopodobniej zainteresowało.
Zakres
No dobrze, wiemy już jak znaleźć firmę, którą chcielibyśmy się zająć.
Pora na drugi ważny krok - określenie zakresu badań, na jakie dana firma pozwala.
Jest to tak zwany scope.
Określa się w nim jaki zakres adresów oraz domen może być przez nas atakowany.
Czasami zdarza się, że firmy tworzą specjalne wersje środowisk z kopią danych, dostępne jedynie dla badaczy.
Chodzi o to, aby w przypadku odkrycia jakiejś podatności nie przerywać prawidłowego działania serwisu.
Tutaj warto przyjrzeć się kilku konkretnym podpunktom.
Za jakie błędy dana firma płaci?
Praktycznie każdy program posiada listę wykluczeń - czyli błędy które są znane, ale nie są traktowane przez daną spółkę jako błąd.
Wszystko zależy od rodzaju serwisu z jakim mamy do czynienia.
Weźmy chociażby pod uwagę błąd open redirection.
Polega on na tym, że użytkownik jest przekierowywany automatycznie na inną stronę, której domena zostaje zawarta w parametrze.
Tego rodzaju podatności są wykorzystywane głównie w atakach phishingowych.
Zamiast bowiem w złośliwej wiadomości email podawać bezpośredni link do złej strony - można użyć podatności open redirection.
Wtedy, użytkownik widzi, że link ten należy do znanej strony której ufa, istnieje więc wyższe prawdopodobieństwo że na nią wejdzie.
Następnie, zostanie automatycznie przekierowany do innej witryny.
Ale tego, może już nie zauważyć.
Błąd ten może być traktowany zatem jako krytyczny w odniesieniu do witryn banków.
Ale równocześnie w zwykłym serwisie z wiadomościami, może nie być traktowany jako błąd.
Wszak taki serwis z założenia przekierowuje swoich użytkowników do wielu innych witryn.
Tak bowiem działają serwisy z wiadomościami.
Wildcard
Tutaj też, definiuje się zakres domen, które mogą być testowane.
W tym przypadku, z perspektywy pentestera - najlepszym kąskiem są domeny z tak zwanym wildcardem, czyli gwiazdką przed nazwą.
Chociażby *.szurek.pl.
Taki zapis oznacza bowiem, że można testować wszystkie strony w obrębie danej domeny.
Możemy więc testować a.szurek.pl, b.szurek.pl i c.szurek.pl pomimo tego, że nie są one wypisane na liście.
Ten fakt jest istotny z jeszcze jednego powodu.
Jeżeli nie istnieje z góry zdefiniowana lista domen, które można testować, ilość odnalezionych błędów jest zazwyczaj wprost proporcjonalna do ilości subdomen jakie odnajdziemy.
Subdomeny
I tutaj przechodzimy do kolejnego punktu - czyli poszukiwania wszystkich subdomen, które zawierają się w danym zakresie.
Jest na to przynajmniej kilka metod.
Pierwsza to skorzystanie z wyszukiwarek internetowych.
Odpowiednio skonstruowane zapytania, z użyciem słowa kluczowego site mogą nam pomóc zwrócić wyniki tylko z konkretnych domen, które nas interesują.
To podejście ma jednak jeden minus.
Aby odnaleźć takie subdomeny wyszukiwarka musiała wcześniej natrafić na ich ślad w Internecie.
To znaczy gdzieś wcześniej musiał znajdować się publiczny link prowadzący do danej subdomeny.
A przecież sporo subdomen może być wykorzystywane wewnętrznie, tylko w obrębie danej organizacji.
A to właśnie takie witryny są najlepszym kąskiem dla pentesterów.
Certificate transparency
Inną metodą jest zatem używanie certificate transparency log.
Jeżeli korzystamy z protokołu https, to obok nazwy domeny w przeglądarce zazwyczaj wyświetlana jest zielona kłódeczka.
Oznacza to, że połączenie pomiędzy naszą przeglądarką a serwerem jest szyfrowane.
Aby cały ten mechanizm działał, potrzebny jest certyfikat.
To dzięki niemu przeglądarka wie, że dany serwer jest prawidłowym serwerem danej domeny i nikt inny nie podszywa się pod niego.
Takie certyfikaty wystawiane są przez zewnętrzne firmy, tak zwane urzędy certyfikacji.
One to najpierw weryfikują czy dany podmiot ma uprawnienia do korzystania z danej nazwy a dopiero później wystawiają odpowiedni certyfikat.
Wszystko opiera się zatem na zaufaniu.
Ale jak mówi znane przysłowie: ufaj - ale kontroluj.
Dlatego też jakiś czas temu twórcy przeglądarek postanowili wprowadzić dodatkowy mechanizm logowania.
Od tej pory każdy certyfikat wystawiony przez dany urząd certyfikacji jest zapisywany w odpowiednim logu - tak zwanym "certificate transparency log".
Ten to log jest dostępny publicznie dla każdego.
I to właśnie z tego miejsca można pozyskać informacje na temat nowo wystawionych certyfikatów.
A to niesie pewne niebezpieczeństwo.
Jeżeli bowiem administrator wygeneruje certyfikat dla danej subdomeny - jej nazwa automatycznie znajdzie się w logu i będzie publiczne znana.
A jeśli dostęp do serwera, który obsługuje daną subdomenę nie jest odpowiednio zabezpieczony - może dojść do wycieku danych.
Tak więc - jest to kolejna metoda pozyskiwania nazw domenowych.
Virustotal
Ale istnieją też inne.
Innym pomysłem jest skorzystanie z witryny Virustotal.
Jest to serwis do którego można przesłać dowolny plik.
On to jest następnie przetwarzany przez silniki antywirusowe kilkudziesięciu firm, a wyniki są zwracane użytkownikowi końcowemu w postaci przejrzystej tabelki.
W taki oto sposób można sprawdzić czy dany plik jest bezpieczny czy też nie.
Ale różni ludzie wysyłają do tego serwisu różne pliki.
A w tych plikach mogą znajdować się różne informacje.
Chociażby adresy domen, z którymi łączy się dany program.
Wyobraźmy sobie bowiem sytuację, że firma korzysta ze swojego wewnętrznego narzędzia, które to łączy się z odpowiednią domeną w celu pobrania interesujących danych.
Ale nowy pracownik nie zna tego oprogramowania i postanawia sprawdzić czy jest ono bezpieczne - wysyłając dany plik na Virustotal.
A ponieważ w treści pliku zaszyta jest nazwa domeny - zewnętrzne podmioty mogą ją poznać i wykorzystać do testowania.
Writeup
Cennym źródłem wiedzy są również wcześniejsze raporty innych osób, które dotyczą danej firmy.
Mowa tutaj o writeup - czyli opisach jak odnaleziono dany błąd, jaką metodologię użyto oraz jak wykorzystano go w praktyce.
Zawsze stanowią one cenne źródło wiedzy i mogą stanowić cenną inspirację, jak inni ludzie podchodzą do tych samych tematów.
Podobna sprawa z publicznie dostępnymi plikami różnych programów biurowych.
Mogą one zawierać różnego rodzaju metadane.
Tam to ponownie - znaleźć można ciekawe i interesujące informacje.
archive.org
Obecnie technologia rozwija się w zastraszająco szybkim tempie.
To samo tyczy się stron internetowych.
Co chwilę wychodzą nowe frameworki, strony zmieniają swój wygląd a także kod źródłowy.
Dla nas widoczne są tylko te nowe wersje, ale zdarza się, że wszystkie stare funkcjonalności dalej są dostępne.
A to wszystko z powodu zachowania kompatybilności wstecznej.
I tutaj do gry wchodzi serwis archive.org, który nieustannie przeszukuje zasoby Internetu i zapisuje w swojej pamięci.
To dzięki temu narzędziu możemy zobaczyć jak wyglądały popularne witryny jeszcze parę lat temu.
Jest to ciekawe doświadczenie wizualne ale może także pomóc osobom zajmującym się bezpieczeństwem.
Dzięki temu możemy bowiem sprawdzić jak serwis się rozwijał, jak wyglądał w przeszłości.
Ba, możemy również zapoznać się ze starszymi wersjami plików JavaScript, które były wykorzystywane w danej witrynie parę lat wstecz.
Ale dlaczego mielibyśmy się nimi interesować?
Obecne strony są dynamiczne - to znaczy pobierają treść z serwera w tle, bez potrzeby przeładowywania całej strony.
Wszystko dzieje się z poziomu kodu JavaScript i to właśnie tam możemy odnaleźć adresy z jakimi łączyła się dana strona w celu pobrania danych informacji.
Ale nie zawsze wszystko jest podane wprost na tacy.
Czasami liczy się szczęście.
Głębokie ukrycie
Ale jemu warto pomóc - zwłaszcza, gdy rozmawiamy o głębokim ukryciu.
Głębokie ukrycie to praktyka ochrony danych komputerowych, polegająca na umieszczaniu ich w nieprzewidywalnej i trudnej do odgadnięcia ścieżce dostępu.
Czyli mówiąc w prostych słowach - generujemy długą i skomplikowaną nazwę pliku a następnie umieszczamy go na naszym serwerze.
Zakładamy wtedy, że dostęp do tego pliku jest możliwy jedynie, jeżeli użytkownik zna jego nazwę.
A co w przypadku, jeżeli ta nazwa nie jest taka losowa, jak by się mogło wydawać?
Może jest to wyraz znajdujący się w słowniku?
W Linuxie mamy do czynienia z katalogami ukrytymi - czyli takimi, których nazwa rozpoczyna się od kropki.
Standardowo, są one niewidoczne dla użytkownika.
Chociażby używając komendy ls w standardowej konfiguracji ich nie zobaczymy.
Dopiero używając dodatkowego przełącznika są one widoczne.
W taki sposób przechowuje się różne pliki konfiguracyjne.
Tak działają repozytoria gita - czyli miejsca, gdzie programiści przechowują swój kod źródłowy.
Standardowo, widzimy tylko gałąź na której obecnie pracujemy.
Reszta zmian jest ukryta przed naszymi oczami aż do momentu, gdy wykonamy odpowiednią komendę.
Git
Ale git - sam musi jakoś te pliki przetrzymywać na dysku twardym.
Robi to w specjalnym katalogu .git.
I tutaj mamy do czynienia z potencjalnym problemem.
Co bowiem w przypadku - gdy roztargniony programista razem ze swoją stroną internetową skopiuje taki katalog na swój serwer?
Wtedy to po odnalezieniu takiego ukrytego katalogu możemy pobrać jego zawartość i zapoznać się z całym kodem źródłowym.
A posiadanie kodu źródłowego to znacząca przewaga.
Mówimy wtedy bowiem o testowaniu metodą whitebox.
Takie podejście do testowania aplikacji ma znaczącą przewagę.
Nie musimy już bowiem zgadywać jak działa dana funkcjonalność, jakie parametry przyjmuje i co jest sprawdzane.
Możemy to wyczytać wprost z kodu źródłowego.
Jest to tym niebezpieczniejsze, że czasami w kodzie źródłowym mogą się znajdować sekretne klucze API do różnych serwisów.
Teoretycznie są one tajne - ale posiadając kod źródłowy - możemy je z łatwością z niego wyciągnąć i użyć w dalszych atakach.
GitHub
Ale repozytoria kodu źródłowego mogą się znajdować również w publiczne dostępnych serwisach, które pozwalają na ich przetrzymywanie.
Chociażby GitLab czy tez GitHub.
Zazwyczaj firmy przetrzymują swoje projekty jako prywatne - czyli dostępne tylko dla osób z danej organizacji.
Ale każdemu zdarzają się błędy w konfiguracji.
Podobna sprawa tyczy się serwerów Continuous Integration czy też Bug Tracker.
Teoretycznie są to narzędzia używane tylko z wewnątrz firmy.
Ale z tym różnie bywa.
Weźmy chociażby pod uwagę serwer Jenkinsa.
W pewnej specyficznej konfiguracji każdy użytkownik może wykonać dowolny kod Groovy.
Groovy to pewien specyficzny język skryptowy.
A ponieważ jest to język, pozwala on na wykonanie praktycznie dowolnej funkcji.
Czyli wykonanie dowolnego kodu na serwerze CI.
A to jest bardzo niebezpieczne.
Wszak w taki sposób możemy zmodyfikować pliki czy też pobrać hasła użytkowników.
Chmura
Teraz żyjemy w czasach chmury.
Sporo firm nie używa zatem własnej infrastruktury i serwerów, a korzysta z zewnętrznych firm do przechowywania różnego rodzaju informacji.
Tutaj ciekawym przykładem może być aplikacja Trello służąca do zarzadzania projektami.
Jest ona popularna i używana przez wiele firm, co sprawia, że w serwisie tym znajduje się wiele potencjalnie tajnych danych.
Swego czasu badacze zaczęli przeglądać zasoby tego serwisu w poszukiwaniu błędnie skonfigurowanych tak zwanych boards, czyli kawałków tablicy.
Nagle okazało się, że sporo firm zapomniało ustawić odpowiednie ustawienia widoczności, co sprawiło, że mieliśmy dostęp do tajnych danych.
A mogły być to chociażby loginy i hasła do jakichś wewnętrznych serwisów.
To tylko pokazuje, że im więcej czasu poświęcimy na poszukiwania wszystkich dostępnych informacji na temat danej firmy, tym teoretycznie lepsze rezultaty możemy uzyskać.
Rekonesans
Gdy wiemy już jakimi domenami się zajmiemy - pora na poszukiwanie błędów.
Na początku warto zarejestrować się w serwisie i po prostu się przez niego "przeklikać".
Podczas testów możemy mieć do czynienia z różnego rodzaju witrynami.
Począwszy od serwisów społecznościowych, a skończywszy na stronach powiązanych z finansami.
Każda strona ma inną charakterystykę.
Zapoznając się po krótce jak działają możemy mieć lepszy ogólny pogląd co się dzieje, jakie dane przetwarzają i możemy spróbować zidentyfikować potencjalnie niebezpieczne miejsca i problemy.
Weźmy chociażby pod uwagę sklep internetowy.
Tutaj można się skupić na funkcji zakupów - chociażby kodów rabatowych.
Tam to może dojść do ataku race condition - kiedy to dany kod da się wykorzystać dwa razy na jednym produkcie, sprawiając iż jego cena będzie znacząco niższa, od tej zakładanej.
Następnie warto sprawdzić jakiej technologii używa dana strona.
Czy jest to jakiś znany skrypt - chociażby WordPress czy Magento, a może jakiś serwis napisany unikalnie dla tej firmy?
To pytanie jest istotne ponieważ darmowe oprogramowanie posiada błędy odnalezione przez innych badaczy.
Czasami nie ma sensu tworzyć koła na nowo - może administrator zapomniał zaktualizować dane oprogramowanie, co sprawia, że jest ono podatne na znane ataki?
Język
Istotna jest też kwestia języka programowania, w którym stworzony jest dany serwis.
Inaczej szuka się podatności w PHP a inaczej w Ruby.
Każdy język ma swoje specyficzne problemy, na których warto się skupić podczas poszukiwania błędów.
Chociażby podczas ataku object injection kiedy to chcemy aby aplikacja wykonała obiekt wcześniej przez nas przygotowany - musi on być stworzony w odpowiednim języku.
Dalej - czy strona używa jakiegoś web application firewall?
Jest to specjalne oprogramowanie, które filtruje parametry przekazywane do aplikacji.
Mówiąc w prostych słowach - stara się wykryć takie ciągi znaków, które nie są prawidłowymi danymi od użytkowników a stanowią część ataku.
W takich przypadkach - nawet gdy odnajdziemy podatność, jej wykorzystanie w praktyce może być znacząco utrudnione.
Chociaż z drugiej strony - jeżeli nie jest to znane rozwiązanie, a zbudowane własnymi siłami przez własną firmę - to może samo odnalezienie obejścia takiego WAF-a może być liczone jako błąd w programie bug bounty?
Stworzenie dobrego narzędzia chroniącego przed wszystkimi atakami nie jest bowiem takie proste.
