Słynny starożytny chiński generał Sun Tzu powiedział to najlepiej ponad 2500 lat temu: „Jeśli znasz wroga i znasz siebie, nie musisz się obawiać wyniku stu bitew. Jeśli znasz siebie, ale nie wroga, za każde odniesione zwycięstwo poniesiesz także porażkę. Bazując na tej ponadczasowej radzie, wypada poznać naszego wroga, hakera z czarnym kapeluszem.
Nie wszyscy zgadzają się ze stosowaniem programów nagród za błędy, ponieważ istnieją pewne kwestie, które są kontrowersyjne. Na przykład dostawcy mogą używać tych platform do oceniania badaczy, ale badacze zwykle nie mogą oceniać dostawców. Niektóre programy nagród za błędy są skonfigurowane tak, aby zbierać raporty, ale dostawca może nie komunikować się prawidłowo z badaczem. Ponadto może nie być możliwości sprawdzenia, czy odpowiedź „duplikat” jest rzeczywiście dokładna. Co więcej, system punktacji może być arbitralny i nie odzwierciedlać dokładnie wartości ujawnienia podatności, biorąc pod uwagę wartość raportu na czarnym rynku. Dlatego każdy badacz będzie musiał zdecydować, czy program nagród za błędy jest dla niego i czy korzyści przeważają nad wadami.
Programy nagród za błędy oferują wiele nieoficjalnych i oficjalnych zachęt. Na początku nagrodami były listy, koszulki, karty podarunkowe i po prostu możliwość przechwalania się. Następnie w 2013 roku Yahoo! wstydził się dawać badaczom coś więcej niż tylko gadżety. Społeczność zaczęła podpalać Yahoo! za tanie nagrody, dawanie koszulek lub nominalnych kart podarunkowych w zamian za raporty o lukach w zabezpieczeniach. W liście otwartym do społeczności Ramses Martinez, dyrektor ds. wyszukiwania błędów w Yahoo!, wyjaśnił, że finansował cały wysiłek z własnej kieszeni. Od tego momentu Yahoo! zwiększyła swoje nagrody do 150–15 000 dolarów za zatwierdzony raport. W latach 2011–2014 Facebook oferował ekskluzywną kartę debetową Visa „White Hat Bug Bounty Program”. Czarna karta z możliwością ponownego ładowania była pożądana, a jej błysk na konferencji poświęconej bezpieczeństwu umożliwiał rozpoznanie badacza i być może zaproszenie na imprezę. Obecnie programy nagród za błędy nadal oferują szereg nagród, w tym Kudos (punkty umożliwiające ranking i uznanie badaczy), łupy i rekompensatę finansową.
Termin „bugs bounty” został po raz pierwszy użyty w 1995 roku przez Jarretta Ridlinghafera z Netscape Communication Corporation. Po drodze firmy iDefense (później zakupione przez VeriSign) i TippingPoint pomogły w procesie przyznawania nagród, działając jako pośrednicy między badaczami a oprogramowaniem, ułatwiając przepływ informacji i wynagrodzenie. W 2004 roku Fundacja Mozilla zorganizowała nagrodę za błędy w Firefoksie. W 2007 r. w CanSecWest ogłoszono konkurs Pwn2Own, który stał się punktem zwrotnym w dziedzinie bezpieczeństwa, ponieważ badacze zbierali się, aby wykazać luki w zabezpieczeniach i ich exploity w zamian za nagrody i pieniądze. Później, w 2010 r., Google uruchomił swój program, a następnie Facebook w 2011 r., a następnie w 2014 r. w ramach programu Microsoft Online Services. Obecnie istnieją setki firm oferujących nagrody za luki w zabezpieczeniach. Koncepcja nagród za błędy to podejmowana przez dostawców oprogramowania próba odpowiedzialnego reagowania na problem luk w zabezpieczeniach. W najlepszym przypadku badacze bezpieczeństwa oszczędzają firmom mnóstwo czasu i pieniędzy na znajdowaniu luk w zabezpieczeniach. Z drugiej strony, w najgorszym przypadku raporty badaczy bezpieczeństwa, jeśli nie zostaną właściwie obsługiwane, mogą zostać przedwcześnie ujawnione, co może kosztować firmy mnóstwo czasu i pieniędzy w związku z kontrolą szkód. W związku z tym wyłoniła się interesująca i krucha gospodarka, ponieważ zarówno dostawcy, jak i badacze mają zainteresowanie i motywację do dobrej współpracy.
Do tej pory omówiliśmy pełne ujawnienie dostawcy, pełne ujawnienie publiczne i odpowiedzialne ujawnienie. Wszystkie te metody ujawniania podatności są bezpłatne, dzięki czemu badacz bezpieczeństwa spędza niezliczone godziny na poszukiwaniu luk w zabezpieczeniach i z różnych powodów niezwiązanych bezpośrednio z rekompensatą finansową ujawnia lukę dla dobra publicznego. W rzeczywistości często trudno jest naukowcowi otrzymać wynagrodzenie w takich okolicznościach, nie interpretując tego jako manipulacji sprzedawcą. W 2009 roku zasady gry uległy zmianie. Na corocznej konferencji CanSecWest stanowisko zabrało trzech znanych hakerów: Charlie Miller, Dino Dai Zovi i Alex Sotirov. Podczas prezentacji prowadzonej przez Millera Dai Zovi i Sotirov trzymali kartonową tabliczkę z napisem „KONIEC WIĘCEJ DARMOWYCH BŁĘDÓW”. Było tylko kwestią czasu, zanim badacze zaczną głośno mówić o nieproporcjonalnej liczbie godzin potrzebnych na badanie i odkrywanie luk w porównaniu z kwotą wynagrodzenia otrzymywanego przez badaczy. Nie wszyscy zajmujący się bezpieczeństwem zgodzili się z tym, a niektórzy publicznie skrytykowali ten pomysł. Inni, przyjmując bardziej pragmatyczne podejście, zauważyli, że chociaż ci trzej badacze zgromadzili już wystarczający „kapitał społeczny”, aby żądać wysokich stawek konsultantów, inni nadal będą bezpłatnie ujawniać słabe punkty, aby budować swój status. Niezależnie od tego, to nowe nastroje wywołały falę uderzeniową w branży papierów wartościowych. Dla niektórych było to wzmacniające, dla innych przerażające. Bez wątpienia dziedzina bezpieczeństwa przesuwała się w stronę badaczy, a nie dostawców.
Do tej pory omówiliśmy dwie skrajności: pełne ujawnienie dostawcy i pełne ujawnienie publiczne. Przyjrzyjmy się teraz metodzie ujawniania informacji, która mieści się pomiędzy obiema metodami: ujawnianie skoordynowane. W 2007 roku Mark Miller z Microsoftu formalnie zaapelował o „odpowiedzialność ujawnienia.” Przedstawił powody, w tym potrzebę zapewnienia dostawcy, takiego jak Microsoft, czasu na pełne naprawienie problemu, łącznie z otaczającym go kodem, w celu zminimalizowania ryzyka wprowadzenia zbyt wielu poprawek. Miller przedstawił kilka trafnych uwag, ale inni argumentowali, że odpowiedzialne ujawnianie informacji jest skierowane w stronę dostawców i gdyby Microsoft i inni nie zaniedbywali tak długo poprawek, w ogóle nie byłoby potrzeby pełnego ujawniania informacji. Wkrótce ludzie zaczęli argumentować, że nazwa „odpowiedzialne ujawnianie informacji” sugeruje, że próby zapewnienia odpowiedzialności dostawcy są zatem „nieodpowiedzialne”. Przyznając tę uwagę, sam Microsoft zmienił później swoje stanowisko i w 2010 roku ponownie zaproponował użycie zamiast tego terminu „skoordynowane ujawnianie luk w zabezpieczeniach” (CVD). Mniej więcej w tym czasie Google podgrzało atmosferę, wyznaczając sztywny termin 60 dni na naprawienie wszelkich problemów związanych z bezpieczeństwem przed ujawnieniem informacji. Wydawało się, że posunięcie to było skierowane do firmy Microsoft, której naprawienie problemu czasami zajmowało ponad 60 dni. Później, w 2014 roku, Google utworzył zespół o nazwie Project Zero, którego celem było wyszukiwanie i ujawnianie luk w zabezpieczeniach z wykorzystaniem 90-dniowego okresu karencji. Cechą charakterystyczną skoordynowanego ujawniania informacji jest groźba ujawnienia po rozsądnym terminie w celu pociągnięcia dostawców do odpowiedzialności. Centrum Koordynacyjne Zespołu Reagowania na Kryzysy Komputerowe (CERT) zostało utworzone w 1988 roku w odpowiedzi na robaka Morris i przez prawie 30 lat służyło jako pośrednik w dostarczaniu informacji o lukach w zabezpieczeniach i poprawkach. CERT/CC ustanowiło 45-dniowy okres karencji na rozpatrywanie raportów o podatnościach, w tym sensie, że CERT/CC opublikuje dane o podatnościach po 45 dniach, chyba że zaistnieją wyjątkowe okoliczności.18 Badacze bezpieczeństwa mogą zgłaszać luki do CERT/CC lub jednej delegowanych przez niego podmiotów oraz ,że CERT/CC zajmie się koordynacją z dostawcą i opublikuje luki w zabezpieczeniach, gdy łatka będzie dostępna lub po 45-dniowym okresie karencji.
Powstały niezliczone ziny, listy mailingowe i grupy w Usenecie omawiające luki w zabezpieczeniach, w tym niesławna lista mailingowa Bugtraq, utworzona w 1993 roku. Wiele z tych ujawnień miało na celu budowanie reputacji hakera. Inne wynikały z frustracji wynikającej z chęci naprawienia sytuacji bez dobrego, formalnego kanału komunikacji. Niektórzy właściciele systemów i dostawcy oprogramowania po prostu nie rozumieli bezpieczeństwa; niektórzy nie mieli prawnego powodu się tym przejmować. Jednak z biegiem lat w społeczności hakerów narastała frustracja, ponieważ dostawcy nie byli postrzegani jako osoby postępujące uczciwie i nietraktujące badaczy poważnie. W 2001 roku konsultant ds. bezpieczeństwa Rain Forest Puppy zajął stanowisko i oświadczył, że da dostawcy tylko tydzień na odpowiedź, zanim w pełni i publicznie opublikuje lukę w zabezpieczeniach. W 2002 roku narodziła się niesławna lista mailingowa Full Disclosure, która przez ponad dekadę służyła jako narzędzie, na którym badacze swobodnie zamieszczali szczegóły dotyczące luk w zabezpieczeniach, z powiadomieniem dostawcy lub bez. Niektórzy znani twórcy tej dziedziny, tacy jak Bruce Schneier, pobłogosławili tę taktykę jako jedyny sposób na osiągnięcie rezultatów, twierdząc, że dostawca oprogramowania najprawdopodobniej naprawi problem, gdy się tego wstydzi. Inni założyciele, jak Marcus Ranum, nie zgodzili się z tym, stwierdzając, że nie jesteśmy lepsi i mniej bezpieczni. Ponownie, nie ma zgody w tej kwestii lub jest ona niewielka; pozwolimy Tobie, czytelniku, sam określić, po której stronie stoisz. Podejście oparte na pełnym ujawnieniu oznacza również, że dostawcy w pośpiechu dotrzymując arbitralnie ustalonych terminów mogą nie naprawić właściwie rzeczywistego problemu. Oczywiście tego typu wybryki są szybko odkrywane przez innych badaczy i proces się powtarza. Inne trudności pojawiają się, gdy dostawca oprogramowania ma do czynienia z luką w zabezpieczeniach biblioteki, której nie opracował. Na przykład, gdy OpenSSL miał problemy z Heartbleed, tysiące witryn internetowych, aplikacji i dystrybucji systemów operacyjnych stało się podatnych na ataki. Każdy z tych twórców oprogramowania musiał szybko przyswoić te informacje i włączyć do swojej aplikacji poprawioną wersję biblioteki. Wymaga to czasu, a niektórzy dostawcy działają szybciej niż inni, w międzyczasie pozostawiając wielu użytkowników mniej bezpiecznych, ponieważ osoby atakujące zaczęły wykorzystywać lukę w ciągu kilku dni od jej udostępnienia. Kolejną zaletą pełnego publicznego ujawnienia jest ostrzeżenie opinii publicznej, aby ludzie mogli podjąć kroki zaradcze przed wydaniem poprawki. Pogląd ten opiera się na założeniu, że czarne kapelusze prawdopodobnie już wiedzą o problemie, więc uzbrojenie społeczeństwa jest dobrą rzeczą i w pewnym stopniu wyrównuje szanse pomiędzy atakującymi i obrońcami. W tym wszystkim pozostaje kwestia szkody publicznej. Czy społeczeństwo jest bezpieczniejsze z pełnym ujawnieniem informacji czy bez? Aby w pełni zrozumieć to pytanie, należy zdać sobie sprawę, że osoby atakujące prowadzą własne badania i mogą wiedzieć o problemie oraz wykorzystywać go do atakowania użytkowników jeszcze przed ujawnieniem luki. Ponownie pozostawimy odpowiedź na to pytanie Tobie.
Począwszy od około 2000 roku, niektórzy badacze byli bardziej skłonni do współpracy z dostawcami i ujawniania pełnego dostawcy, co oznaczało, że badacz w pełni ujawniał dostawcy lukę w zabezpieczeniach i nie ujawniał jej żadnym innym stronom. Było to częściowo spowodowane rosnącą otwartością dostawców na akceptowanie opinii publicznej bez uciekania się do działań prawnych. Jednak koncepcja bezpieczeństwa komputerowego zaczęła coraz bardziej przenikać przestrzeń dostawców, co oznaczało, że więcej firm zaczęło przyjmować formalne kanały ujawniania informacji. Większość tych ujawnień wymagałaby nieujawniania informacji opinii publicznej ze strony badacza lub badacz zdecydowałby się nie ujawniać publicznie szczegółów ze względu na etos białego kapelusza. Jednakże brak formalnych środków umożliwiających obsługę takich zgłoszeń i brak zewnętrznego źródła odpowiedzialności często wiązały się z nieograniczonym okresem czasu na załatanie luki. Pogląd, że dostawcy nie mają motywacji do łatania luk, prowadził do pozbawienia badaczy praw, co czasami skłaniało hakerów do preferowania pełnego ujawnienia informacji. Z drugiej strony dostawcy oprogramowania nie tylko musieli opracować nowe procesy mające na celu usunięcie tych luk, ale także zmagali się z zarządzaniem dystrybucją aktualizacji do swoich klientów. Zbyt wiele zmian w krótkim czasie mogłoby podważyć zaufanie konsumentów do produktu. Nieujawnianie szczegółów na temat tego, co zostało naprawione, może skłonić konsumentów do niezastosowania łatki. Niektórzy konsumenci mieli duże i skomplikowane środowiska, w których instalowanie poprawek stwarzało problemy logistyczne. Ile czasu zajęłoby komuś odtworzenie łatki i utworzenie nowego exploita i czy byłoby to mniej więcej tyle, ile zajęłoby wszystkim konsumentom zapewnienie sobie ochrony?
Luki w oprogramowaniu są tak stare jak samo oprogramowanie. Mówiąc najprościej, luki w oprogramowaniu to słabość w projektowaniu lub wdrażaniu oprogramowania, która może zostać wykorzystana przez osobę atakującą. Należy zauważyć, że nie wszystkie błędy są lukami w zabezpieczeniach. Błędy od luk odróżniamy za pomocą współczynnika możliwości wykorzystania. W 2015 roku Synopsys przygotował raport, który pokazał wyniki analizy 10 miliardów linii kodu. Badanie wykazało, że kod komercyjny miał 0,61 defektów (błędów) na 1000 linii kodu (LoC), podczas gdy oprogramowanie open source miało 0,76 defektów (błędów) na 1000 LoC. Jednak to samo badanie wykazało, że kod komercyjny radził sobie lepiej w porównaniu ze standardami branżowymi, takimi jak OWASP Top 10.5. Ponadto wykazano, że 1–5 procent defektów oprogramowania okazuje się lukami w zabezpieczeniach. Ponieważ współczesne aplikacje powszechnie mają licznik LoC wśród setek tysięcy, jeśli nie milionów, typowa aplikacja może zawierać dziesiątki luk w zabezpieczeniach. Jedno jest pewne: tak długo jak ludzie będą tworzyć oprogramowanie, będziemy mieć luki w zabezpieczeniach. Co więcej, dopóki mamy luki w zabezpieczeniach, użytkownicy są zagrożeni. Dlatego też na specjalistach i badaczach ds. bezpieczeństwa spoczywa obowiązek zapobiegania, znajdowania i naprawiania tych luk, zanim osoba atakująca je wykorzysta, wyrządzając szkodę użytkownikowi. To ostateczna misja hakera w szarym kapeluszu. Podczas ujawniania luk w zabezpieczeniach pojawia się wiele kwestii. Dla hakera oznacza to szczegółowe informacje, takie jak to, z kim się skontaktować, jak się z nim skontaktować, jakie informacje podać i jak zapewnić odpowiedzialność wszystkich stron za ujawnienie. W przypadku dostawcy obejmuje to szczegółowe informacje, takie jak śledzenie raportów o lukach w zabezpieczeniach, przeprowadzanie analizy ryzyka, uzyskiwanie odpowiednich informacji do wprowadzenia poprawki, przeprowadzanie analizy kosztów i korzyści związanych z programowaniem mającym na celu wprowadzenie poprawki oraz zarządzanie komunikacją z konsumentami i osobą, która zgłosił lukę. Kiedy cele związane z tymi rozważaniami nie są zbieżne między hakerem a dostawcą, istnieje możliwość tarć. Pojawiają się kluczowe pytania, np. ile czasu wystarczy dostawcy na wprowadzenie poprawki? Czy haker i sprzedawca zgadzają się, że poprawka jest ważna? Czy osoba, która w dobrej wierze zgłasza lukę w zabezpieczeniach, powinna otrzymać odszkodowanie lub zostać rozpoznana? Jak długo klienci powinni zapewnić sobie bezpieczeństwo, instalując łatkę, zanim haker lub sprzedawca opublikuje szczegółowe informacje na temat luki? Jaka ilość szczegółów jest odpowiednia? Czy klienci zastosują łatkę, jeśli nie zrozumieją niebezpieczeństwa niezastosowania łatki? Odpowiedzi na wszystkie te pytania często są przedmiotem gorących sporów. Niektórzy badacze mogą uznać nieujawnianie informacji za nieujawnione, jeśli sprzedawca zdecyduje się nie podejmować działań w związku z luką. Utrzymujące się zagrożenie dla konsumentów w obliczu utrzymującej się luki w zabezpieczeniach może być frustrujące, gdy nie ma innego organu, który mógłby pociągnąć dostawcę do odpowiedzialności za bezpieczeństwo. Jednak nawet dostawcy dbający o bezpieczeństwo mogą działać zgodnie z wymaganiami wielu badaczy, budżetów, menedżerów produktów, konsumentów i inwestorów, co wymaga ponownego zrównoważenia priorytetów, co nie zawsze zadowala każdego badacza. W tych kwestiach nie ma formalnego konsensusu. Typowe metody ujawniania obejmują pełne ujawnienie dostawcy, pełne ujawnienie publiczne i ujawnienie skoordynowane. W duchu etycznego hakowania skłaniamy się ku koncepcji skoordynowanego ujawniania informacji; mamy jednak nadzieję, że przedstawiliśmy opcje w przekonujący sposób i pozwolimy Tobie, czytelniku, podjąć decyzję.
UWAGA: terminy te są kontrowersyjne i niektórzy mogą preferować „częściowe ujawnienie dostawcy” jako opcję postępowania w przypadkach, gdy kod potwierdzający koncepcję (POC) jest ukrywany i gdy w proces ujawniania zaangażowane są inne strony. Aby było to proste, w tej książce będziemy trzymać się powyższych terminów.
W tej sekcji przedstawiamy przegląd historii dziedziny etycznego hakowania, zaczynając od tematu ujawniania podatności, a następnie przechodząc do nagród za błędy. Położy to podwaliny pod dalsze tematy w tym rozdziale, takie jak zaawansowane trwałe zagrożenia (APT), Lockheed Martin Cyber Kill Chain, MITRE ATT&CK, testy penetracyjne, informacje o zagrożeniach, polowanie na zagrożenia i inżynieria bezpieczeństwa.