Wprowadzenie
Witam wszystkich bardzo serdecznie. Ja nazywam się Kacper Szurek, a to podcast Szurkogadanie, w którym opowiadam o bezpieczeństwie w prosty i zrozumiały sposób.
Ten odcinek jest specjalny, ponieważ nagrywam go na żywo z konferencji Security Case Study w Warszawie1.
Jest to pierwszy raz kiedy wykonuję podcast na żywo z publicznością, dlatego może się trochę różnić od tego, do czego przywykli moi słuchacze na co dzień.
A wiec o czym będę dzisiaj mówił?
Jesteś prezesem lub osobą odpowiedzialną za bezpieczeństwo firmy?
Zastanawiasz się jak zwiększyć bezpieczeństwo?
A może program Bug Bounty?
Co to takiego i czy mojej firmie się opłaci?
Jakie są plusy i minusy?
Postaram się obalić mity powiązane z tym tematem, a także opisać jak można rozpocząć wdrażanie takiego tematu z punktu widzenia firmy.
Na czym można oszczędzić i ile to tak naprawdę kosztuje?
Bezpieczeństwo nie opłaci naszych rachunków, ale może zmniejszyć wydatki ponoszone przez naszą organizację.
Jak wygląda test penetracyjny?
Ale aby rozpocząć, musimy zastanowić się jak działa tradycyjny model tworzenia oprogramowania.
Najpierw więc mamy pomysł.
Potem przystępujemy do jego implementacji, następnie testy, faza beta i gdzieś tutaj zazwyczaj po środku zaczynamy zastanawiać się co z bezpieczeństwem.
Zatrudniamy więc firmę, która przeprowadza dla nas test penetracyjny.
Ale robimy to zazwyczaj po to, aby mieć jakąś podkładkę, potrzebną wtedy gdy coś pójdzie nie tak i dane naszych klientów wyciekną.
Przecież zrobiliśmy wszystko co w naszej mocy aby dane klientów były bezpieczne.
Plusy i minusy pentestu
Takie podejście ma swoje plusy i minusy.
Po pierwsze płacimy za spędzony czas, a nie za liczbę błędów odnalezionych przez firmę.
Tak naprawdę nie mamy pewności co i w jakiej ilości zostanie znalezione.
Oczywiście firma będzie robiła wszystko, aby znaleźć jak największą liczbę błędów niosących największe konsekwencje.
Ale to zawsze zagadka.
Jeżeli chcemy sprawdzić regresję – czyli po jakimś czasie ponownie wrócić do sprawdzania naszej aplikacji – ponownie płacimy za wykonanie tej samej usługi.
Ale takie podejście ma też plusy.
Po pierwsze wiemy kto przeprowadza test.
O jakiej porze, w jaki sposób, z jakiej puli adresowej.
Możemy też spodziewać się raportu z przeprowadzanych czynności.
Wiemy do kogo się zwrócić.
I tutaj do gry wchodzą programy Bug Bounty.
Co to jest Bug Bounty?
W normalnym penteście mamy jakąś określoną, skończoną liczbę osób, która ma określony czas2.
Mnożymy więc ten czas przez liczbę osób i otrzymujemy pracę, która została wykonana nad danym projektem.
W Bug Bounty wygląda to trochę inaczej, ponieważ teoretycznie liczba osób biorących udział jest nieskończona.
Naszą aplikację może sprawdzać nieskończenie wiele osób z różnych zakątków świata.
W takim równaniu nawet jeżeli każda z tych osób spędzi tylko jedną godzinę nad bezpieczeństwem naszej aplikacji, rachunek jest nieco inny.
Główna różnica pomiędzy pentestem
Ważny szczegół: tutaj płacimy za wykonaną pracę - czyli za odnaleziony błąd.
Nie interesuje nas ile ta osoba spędzi czasu nad poszukiwaniem takich błędów.
Więc w najgorszej sytuacji, ktoś może spędzić 100 godzin przeglądając naszą aplikację i nie otrzyma od nas żadnej zapłaty.
Często zdarza się, że firmy twierdzą, że nie mogą wprowadzić programu Bug Bounty ponieważ jest to drogie.
Ile to kosztuje?
A prawda jest taka, że program Bug Bounty może nie kosztować zupełnie nic.
Nie musimy płacić za błędy.
Owszem, jest to taka standardowa praktyka, ale pieniądze nie są konieczne.
Równie dobrze możemy przesyłać upominki, kartki pocztowe z gratulacjami, czy też po prostu listy gratulacyjne podpisane przez prezesa.
Oczywiście im więcej płacimy tym prawdopodobnie lepsze błędy otrzymamy.
Sami definiujemy budżet.
Mamy określoną kwotę i ją przekroczyliśmy – możemy tymczasowo zawiesić program, jeżeli okaże się, że zgłoszeń jest zbyt wiele i nasza aplikacja jest dziurawa jak ser szwajcarski.
Ale żeby zrozumieć finanse warto przyjrzeć się realnym stawkom.
Co to jest platforma
I tutaj do gry wchodzą platformy.
Z roku na rok jest ich coraz więcej.
Ale co to takiego?
Jeżeli chcemy przyjmować błędy od osób z zewnątrz oczywiście możemy robić to samemu.
Na przykład poprzez jakąś pocztę elektroniczną lub system do obsługi zgłoszeń.
Ale prościej jest skorzystać z gotowego rozwiązania, szytego na miarę.
Serwisy te zbierają wiele osób zajmujących się bezpieczeństwem, a także wiele różnych programów, w których te osoby mogą wziąć udział.
Widzimy wszystkie zgłoszenia w jednym miejscu, zebrane w jednym panelu.
Średnie kwoty wypłat
Teraz kilka danych, z dokumentów marketingowych3 firm posiadających swoje platformy Bug Bounty.
Jeżeli popatrzymy na kwoty z punktu widzenia polskiego rynku, mogą wydawać się one dość wysokie.
Znalezienie błędu krytycznego - czyli takiego, który na przykład umożliwia wykonanie zdalnego kodu na serwerze, to w lepiej płatnych przypadkach około 4000$.
Oczywiście kwoty te różnią się nieznacznie w zależności od rodzaju rynku, którego dotyczą.
Średnia utrzymuje się w okolicy 2000$ za jeden błąd.
Dużo - jak na nasze polskie standardy.
Ale popatrzmy na drugi wykres w percentylach.
Tutaj widzimy, że tylko jeden procent firm płaci za błąd ponad 20 000$.
Ale zdecydowana większość firm płaci poniżej 5000 $.
A jak te kwoty zmieniały się wraz z upływem czasu?
Tutaj widzimy tendencję wzrostową - ale tylko dla najbardziej krytycznych podatności.
W innych przypadkach ten wzrost nie jest tak bardzo widoczny.
Dlaczego? Ponieważ firmy zainteresowane są głownie tylko tymi błędami, które stanowią duży problem dla ich działalności.
Różnica pomiędzy prywatnym a publicznym programem
Te kwoty mogą robić wrażenie.
Ale by je lepiej zrozumieć, musimy powiedzieć o kolejnym temacie – rozdzieleniu programów na publiczne i prywatne.
Publiczny program to taki, do którego każdy ma dostęp i może zgłosić w nim błąd.
Do prywatnego programu natomiast, zapraszani są tylko niektórzy.
Co to oznacza dla nas?
W publicznych programach często zdarza się, że otrzymujemy sporo szumu – czyli informacji, które nie są dla nas istotne.
Czasami zdarzają się wręcz próby szantażu, gróźb, prośby o pieniądze.
Przykład: ktoś może myśleć, że odnalazł błąd krytyczny, jednak po sprawdzeniu okazuje się, że taka podatność nie istnieje.
Trwa jednak dalej w swoich żądaniach.
W prywatnych programach sami decydujemy kogo zapraszamy.
Dzięki temu mamy większą kontrolę nad tymi, którzy przyglądają się naszym stronom bliżej.
Możemy chociażby przyjmować jedynie te osoby, których tożsamość została dodatkowo potwierdzona przez platformę – chociażby skanem dowodu tożsamości.
Możliwe jest także wyszukiwanie osób w zależności od ich zdolności.
Jeżeli bowiem jesteśmy firmą, której biznes oparty jest na kryptowalutach – dobrym pomysłem byłoby wybranie osób, dla których ten temat nie jest niczym obcym.
Możemy też testować aplikacje jeszcze przed ich oficjalną premierą.
Linki do tych aplikacji nie są bowiem publicznie dostępne, a wysyłane jedynie do wybranych wcześniej osób.
Jakie firmy mogą brać udział?
Kolejnym mitem jest to, że tylko firmy technologiczne decydują się na takie programy.
A to nieprawda, bowiem w dzisiejszym świecie prawie każda firma ma albo sklep internetowy, bloga czy też forum.
I każde z tych miejsc może zostać zaatakowane.
Niektórzy twierdzą, że Bug Bounty może przynieść nam zły PR.
No bo jak to będzie wyglądało, jeżeli jakiś badacz odnajdzie poważny błąd w naszym systemie i zgłosi go nam, a następnie pochwali się tym na Twiterze bądź innym medium społecznościowym?
Przecież to będzie ujma na naszym honorze.
Ale popatrzmy na duże firmy: na Microsoft, Google i Facebooka.
One biorą udział w tych programach i nie widać negatywnych efektów marketingowych takiego podejścia.
Dlaczego? Bo pokazują w ten sposób, że bezpieczeństwo się dla nich liczy.
Jeżeli błąd zostanie naprawiony w przeciągu kilku minut, to wiemy, że firmy te posiadają działy bezpieczeństwa traktujące takie sytuacje poważnie.
Zatem czy programy Bug Bounty mogą wyprzeć tradycyjne pentesty?
Nie do końca, ponieważ bezpieczeństwo oprogramowania nie powinno być sprawdzanie jedynie w fazie implementacji.
Tak naprawdę musimy myśleć o bezpieczeństwie już na etapie projektowania, aby nie popełnić błędów, które okażą się trudne do naprawienia w przyszłości.
Poza tym istnieją też firmy i instytucje, które po prostu nie mogą sobie pozwolić na takie programy.
Ciężko bowiem wyobrazić mi sobie sytuację, w której 50 osób próbuje włamać się do elektrowni atomowej albo banku.
Po prostu w niektórych branżach taki pomysł nie ma szans na realizację.
A wiec programy Bug Bounty nie będą zastępowały testów penetracyjnych.
Będą z nimi współgrały.
Od czego zacząć?
Jak zatem wystartować z takim programem?
Po pierwsze, najlepiej zatrudnić kogoś od security w naszej firmie.
Dlaczego? Ponieważ najpierw należałoby sprawdzić najprostsze rzeczy samemu.
Jeżeli wystartujemy z programem pewnym jest, że dużo osób będzie próbowało wykorzystać znane narzędzia – chociażby Burp Suite - i przy ich pomocy przetestować naszą aplikację.
Jeżeli ktoś może uruchomić jakieś automatyczne narzędzie i na tej podstawie znaleźć parę błędów to przecież nic nie stoi na przeszkodzie, abyśmy tą samą czynność wykonali sami – w swojej firmie.
Potem musimy sobie zadać pytanie: czy jesteśmy na to przygotowani?
Bowiem taki program to dużo pracy.
Należy też w odpowiedni sposób ustalić datę.
Nie warto uruchamiać programu w czarny piątek lub wakacje, kiedy sporo osób jest na urlopach.
Start bez pieniędzy
Wystartujmy z programem bez pieniędzy.
Dlaczego tak?
Jak to możliwe, że ktoś będzie pracował za darmo?
Aby to zrozumieć, musimy pomyśleć jak działają ogólnie dostępne platformy Bug Bounty.
Wcześniej wspominałem, że spora część programów to programy prywatne, które nie są publicznie dostępne.
A więc aby wziąć udział w takich programach, musimy zostać do nich zaproszeni.
A zapraszamy kogoś bazując na jego rankingu.
Jeżeli zatem jakiś użytkownik dopiero rozpoczyna swoją przygodę z poszukiwaniem błędów, jego pozycja jest niska.
Musi w jakiś sposób pokazać swoje umiejętności.
Stara się więc odnajdywać błędy w publicznie dostępnych programach.
W taki oto sposób pnie się po drabinie i zdobywa coraz więcej punktów.
A to sprawia, że z czasem zdobywa coraz więcej zaproszeń do prywatnych programów.
I właśnie ten mechanizm możemy wykorzystać na naszą korzyść, bowiem ktoś wykonuje pracę za darmo.
Tak naprawdę, ciężko stwierdzić jak wygląda bezpieczeństwo naszej aplikacji.
Może rzeczywiście jest bardzo dziurawa, a może niekoniecznie?
Potem musimy zastanowić się nad zakresem - czyli domenami i aplikacjami, których bezpieczeństwo nas (jako firmę) interesuje.
Definiowanie zakresu
Musimy dokładnie zdefiniować na co pozwalamy użytkownikom.
Możemy dodać wykluczenia – czyli rzeczy, których wykonywanie jest zabronione.
Tam to też możliwe jest zdefiniowanie czasu reakcji, czyli informacji o tym jak szybko odpowiadamy na zgłoszenia.
Osoby profesjonalnie zajmujące się bezpieczeństwem uczyniły z tego swój zawód, zarabiając rocznie spore pieniądze.
Tacy uczestnicy programów lubią wiedzieć, kiedy mogą spodziewać się wypłaty za prawidłowo zgłoszony błąd.
Jeżeli bowiem błąd średnio naprawiamy w przeciągu 180 dni, a pieniądze wypłacamy po 90 – może się okazać, że rzadko kto będzie chciał z nami współpracować.
Musimy się też zastanowić bezpieczeństwo czego tak naprawdę najbardziej nas interesuje.
Przykład: jeżeli jesteśmy firmą zdrowotną, to kluczowe dla naszego biznesu jest bezpieczeństwo danych na temat naszych pacjentów.
W przypadku instytucji finansowych natomiast mogą to być dane finansowe klientów.
Aby cały proces miał sens, istotna jest współpraca pomiędzy różnymi działami w firmie.
Dlaczego? Po pierwsze, musimy uzgodnić wszystkie kwestie prawne.
Istotna też jest zgoda szefostwa na wykonanie takich działań.
Należy bowiem zaplanować pracę wielu działów.
W Bug Bounty nie chodzi bowiem tylko o to, aby odnaleźć podatności.
Współpraca pomiędzy działami
Znalezienie błędu to dopiero początek.
Ktoś musi bowiem taki błąd naprawić.
A kto naprawia błędy w naszej firmie?
Programiści. Jeżeli więc w naszym kosztorysie nie uwzględnimy ich czasu, nagle może się okazać, że i owszem mamy zgłoszonych bardzo wiele błędów, ale ich naprawa będzie trwała zdecydowanie zbyt długo.
Warto też skontaktować się z działem finansowym naszej korporacji, aby upewnić się jak rozliczać koszty programów.
W przypadku korzystania z dedykowanych platform – sprawa jest znacznie uproszczona.
Firmy te zazwyczaj wystawiają nam odpowiednią fakturę, którą my musimy opłacić.
Jeżeli jednak chcielibyśmy programem zarządzać sememu, rozliczanie wypłat będzie bardziej skomplikowane.
Program rozpocznijmy na małej próbce z ograniczonym zakresem.
A więc wyślijmy zaproszenia do małej liczby uczestników, określając równocześnie jedną bądź dwie interesujące nas subdomeny.
Teoretycznie im więcej płacimy tym więcej możemy wymagać.
Ale na samym początku trudno przewidzieć jak sytuacja się rozwinie.
Dopiero realne błędy pozwolą nam na pogląd całej sytuacji.
Ile czasu jesteśmy w stanie poświęcić na przeglądanie raportów oraz naprawianie błędów?
Czy mogę zaufać hackerom?
Kolejny mit mówi o tym, że hackerom nie można ufać.
Tylko, że na platformach bardzo wiele osób podpisuje się z imienia i nazwiska.
W taki oto sposób możliwe jest budowanie swojej reputacji.
Piszą oni na blogach, budują swoją markę w mediach społecznościowych pokazując siebie.
Zwiększa to możliwość znalezienia nowej, lepiej płatnej pracy.
Podczas rekrutacji można bowiem pochwalić się realnymi umiejętnościami, które posiadamy i które są cenione na rynku pracy.
Ale jak ulepszyć swój program?
Warto dostarczyć wszystkie potrzebne informacje – czyli udostępnić pełną dokumentacje danego projektu.
Jeżeli wykorzystujemy jakieś API - udostępnienie wszystkich możliwych do wykonania operacji wraz z możliwymi parametrami może pomóc.
Większość testów odbywa się bez dostępu do kodu źródłowego aplikacji – tak zwany black box.
W takim podejściu niektóre parametry trzeba zgadywać na podstawie dostępnych informacji.
Posiadając dokumentację – sprawa jest dużo prostsza.
Naprawa przyczyny a nie błędu
Na etapie łatania błędów, nie warto robić tego zbyt szybko.
Należałoby się zastanowić co jest powodem istnienia takiego błędu – tak zwany root cause.
Bo zamiast naprawiać każdy pojedynczy błąd z osobna, warto rozważyć je z szerszej perspektywy.
Może jest to jakaś jedna klasa podatności, której naprawa wymaga jednej zmiany nieco wyżej w strukturze kodu?
Rozważmy także warianty danego błędu – czyli błędy podobne do zgłoszonego, ale mogące występować w innych miejscach naszej aplikacji.
Jeżeli zgłoszony błąd znajduje się w jakiejś bibliotece, to czy czasem nie jest ona używana również w naszych innych projektach?
Sprawdzanie logów
A czy pomyślałeś o weryfikacji logów?
Mogły się tam bowiem pojawić błędy niewychwycone podczas przeprowadzania testów.
Przykład: przesłany przez użytkownika ciąg znaków może doprowadzić do wyłączenia serwera.
Tylko, że nasza aplikacja składa się z wielu serwerów.
Wyłączenie jednego z nich jest nieistotne z punktu widzenia użytkownika końcowego.
Ale my w logach będziemy w stanie dotrzeć do tej informacji i wykorzystać ją do naprawy podatności.
Signal to noise ratio
Kolejnym ważnym parametrem jest signal to noise ratio.
Pokazuje on ile zgłoszonych do nas błędów jest istotnych, a ile to szum - czyli coś, co musimy przejrzeć, ale nie przynosi nam żadnej wartości.
Zmorą nowoczesnych programów Bug Bounty są bowiem duplikaty.
Duplikaty to błędy, które zostały już wcześniej przez kogoś zgłoszone, ale nie zostały jeszcze przez nas poprawione w aplikacji.
A więc dwie osoby wykonują tą samą pracę odnajdując tą samą podatność w naszym kodzie.
Szczęśliwie dla nas w takich przypadkach, płacimy tylko raz - osobie, która była pierwsza.
Naszym kosztem dodatkowym jednak jest praca, którą wykonaliśmy przeglądając zduplikowane rekordy.
Istnieje bowiem przekonanie, że największym kosztem4 Bug Bounty nie są pieniądze wypłacane badaczom, ale czas, przeznaczony na ich triażowanie.
Każdy raport musi bowiem zostać przeglądnięty przez odpowiednią osobę.
Czy zgłoszony błąd rzeczywiście nim jest?
Czy jest on powtarzalny – to znaczy, czy możliwe jest jego powtórzenie na podstawie podanych przez użytkownika informacji?
Taką procedurę musi wykonać albo nasz pracownik, albo zewnętrzna, zatrudniona do tego celu firma.
Odnajdowanie słabych punktów
Ale w czym tak naprawdę Bug Bouny może pomóc?
Jak można wyczytać w materiałach promocyjnych, według osób pracujących w GitHubie5, udział w programie pozwolił im na odnalezienie tak zwanych „blind spots” – czyli głęboko ukrytych miejsc w kodzie, które nie były odpowiednio zabezpieczone.
W tradycyjnym penteście zazwyczaj definiujemy miejsca, których testowanie nas interesuje.
W przypadku Bug Bounty ten zakres może być dużo większy.
Dzięki temu może się okazać, że jeden z badaczy natrafił na starą, dawno zapomnianą już funkcjonalność, która może stanowić potencjalne niebezpieczeństwo dla naszej aplikacji.
Na sam koniec: nie kłam.
Jeżeli ktoś zgłosił błąd, a taki błąd rzeczywiście istniał w naszym systemie, oczywiście należy go naprawić, ale także przyznać się do wystąpienia takiej sytuacji.
Kłamstwo ma krótkie nogi. Wykonanie fałszywego ruchu zazwyczaj ma odwrotne do spodziewanych rezultaty.
Nie chcemy bowiem odnaleźć informacji na Twitterze, gdzie badacz demaskuje nasze nadużycie równocześnie oskarżając nas o kłamstwa.
Live events
Pamiętajmy: nie istnieją aplikacje idealne.
A nawet jeśli takowe są, z roku na rok powstają nowe techniki ataków, na które możemy być podatni.
Gdy nasza spółka dysponuje sporym budżetem, zainteresować mogą nas „live hacking events”.
Zapraszamy wtedy kilku uczestników do wspólnego atakowania naszej infrastruktury.
Zbieramy ich razem, na kilka dni w jednym fizycznym miejscu.
Wtedy to możliwe jest tymczasowe zwiększenie zakresu – czyli miejsc, w których za odnalezienie podatności płacimy pieniądze.
Pozwala się wtedy również na rozmowy z naszymi inżynierami, co pozwala na przedyskutowanie trudniejszych błędów.
Podsumowując: dlaczego badacze biorą udział w programach Bug Bounty?
Zaskakująco, dopiero na trzecim miejscu, według przeprowadzonej ankiety, znajdują się pieniądze.
Przed nimi zabawa i rozwijanie swoich umiejętności.
Skąd takie wnioski? Dla osób zajmujących się bezpieczeństwem rozwój to podstawa działalności.
Biorąc udział w programach, mogą zwiększać swoją ekspercką wiedzę.
Icon made by Freepik www.flaticon.com
https://go.synack.com/rs/738-OEX-476/images/CrowdsourcedSecurityTesting_FINAL_5-29-2018.pdf ↩
https://www.hackerone.com/sites/default/files/2018-07/The%20Hacker-Powered%20Security%20Report%202018.pdf ↩
https://medium.com/engineers-optimizely/raising-the-security-bug-bounty-b8abeb46409a ↩
https://www.hackerone.com/sites/default/files/2017-05/Case%20Study%20-%20GitHub%20-%20FINAL.pdf ↩