Koniec z darmowymi błędami

https://chacker.pl/

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.

Skoordynowane ujawnianie informacji

https://chacker.pl/

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.

Pełne ujawnienie publiczne

https://chacker.pl/

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.

Pełne ujawnienie dostawcy

https://chacker.pl/

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?

Historia ujawniania luk w zabezpieczeniach

https://chacker.pl/

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.

Historia etycznego hakowania

https://chacker.pl/

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.

Definicja hakowania szarego kapelusza

https://chacker.pl/

Jak widać, termin „szary kapelusz” wywodzi się z wczesnego rozpoznania, że istnieje więcej „odcieni szarości”, że tak powiem, niż biegunowych terminów czerni i bieli. Oczywiście określenie „czarny i biały” w odniesieniu do hakerów pochodzi ze starych amerykańskich westernów telewizyjnych, gdzie dobrzy ludzie byli kowbojami w białych kapeluszach, a źli zawsze nosili czarne kapelusze. Hakerzy w szarym kapeluszu to zatem ci, którzy działają pomiędzy. Decydujemy się działać zgodnie z prawem i etycznie, korzystając z badań i wiedzy konkurencyjnej, aby ulepszać świat poprzez ulepszanie zabezpieczeń otaczających technologię. Żeby było jasne, my, autorzy tej książki, nie wypowiadamy się w imieniu wszystkich hakerów w szarym kapeluszu, ani nawet nie sądzimy, że wszystkie osoby, które uważają się za hakerów w szarym kapeluszu, zgodziłyby się z tą definicją. Jednakże, przedstawiając techniczne tematy , chcieliśmy zacząć od opisania, skąd pochodzimy, czyli od stanowiska etycznego hakowania, zgodnie z którym nasze wysiłki są wykorzystywane w dobrym celu, a nie w szkodzie. Wielu, choć nie wszyscy, hakerzy w szarych kapeluszach, wykorzystuje te techniki do zarabiania na życie w sensie zawodowym i jest bardzo dumnych ze swojego rzemiosła i honorowego ducha, w jakim go wykonujemy. Mamy nadzieję, że wy również przyjmiecie ten punkt widzenia i wykorzystacie swoje moce w dobrym celu. Jest wystarczająco dużo hakerów w czarnych kapeluszach; potrzebujemy więcej szarych kapeluszy, wkraczając w lukę, aby chronić innych. Jeśli spodobała Ci się ta książka, mamy nadzieję, że dołączysz do nas w wyjaśnianiu nieporozumień związanych z tym tematem. Odpowiadaj, gdy usłyszysz, że ktoś błędnie opisuje hakera w szarym kapeluszu. Chrońmy nasze pole, stając w obronie tego, co słuszne i dobre, i wzywajmy tych, którzy przekraczają linię.

Etyka i hakowanie

https://chacker.pl/

W tym i innych tekstach wielokrotnie pojawia się również termin „etyczny haker”. Termin ten jest czasami kwestionowany, ponieważ moralność, etyka i prawa różnią się w zależności od jednostki, grupy społecznej i rządów. W większości kontekstów termin ten ma na celu rozróżnienie pomiędzy przestępczością a zachowaniem zgodnym z prawem — aby rozróżnić osobę, która hakuje dla większego dobra, od osoby, która włamuje się w celach zawodowych, od osoby, która dąży do osobistych korzyści, czynnej przestępczości lub wyrządzenia krzywdy umiejętnością. Wytyczne dotyczące tego, co wyróżnia etycznego hakera, są czasami nawet skodyfikowane dla posiadaczy certyfikatów i członków niektórych organizacji zajmujących się bezpieczeństwem komputerowym, które używają kodeksów postępowania do ustalania oczekiwań dotyczących zachowania.

Historia hackowania

https://chacker.pl/

Etyczny hacking nie zawsze był akceptowany jako zawód prawniczy. Był czas, gdy jakakolwiek forma włamania, niezależnie od jego celu, była traktowana jako czynność czysto przestępcza. W miarę jak technologia ewoluowała i stawała się coraz bardziej wszechobecna w naszym życiu, wzrastała także wiedza na temat hakowania i praw rządzących jego wykorzystaniem. Dla wielu czytelników tej książki są to pojęcia po prostu utracone w historii. Ważne jest jednak zrozumienie tej historii i uznanie ciężkiej pracy założycieli tej dziedziny, którzy umożliwili kontynuowanie tej kariery. Podajemy te informacje nie tylko po to, aby informować, ale także chronić zdolność profesjonalistów do etycznego stosowania swoich umiejętności hakerskich, aby mogli w dalszym ciągu czynić świat lepszym miejscem. Był czas, gdy korzystanie z komputerów regulowało mniej zasad, ponieważ umiejętności i wiedza prawodawców i organów ścigania pozostawały w tyle w obliczu szybkiej ewolucji systemów sieciowych. Hakerzy, którzy mogli atakować systemy z ciekawości lub nawet psot, odkryli jednak nowy świat możliwości. Nie każdy, kto pozwolił sobie na ciekawość, zrobił to bez szkody. Jednak wynikające z tego starcia z autorytetami, które nie były w stanie zrozumieć systemów, sprawiły, że wielu życzliwych, bystrych i inteligentnych hakerów zostało uznanych za przestępców przez większość światowych dostawców oprogramowania i rządów, niezależnie od ich intencji. Widzisz, ludzie boją się tego, czego nie rozumieją, a wielu zrozumie jedynie, że haker włamał się do systemu bez pozwolenia – nie dlatego, że nie miał zamiaru wyrządzić w ten sposób żadnej krzywdy. W 1986 roku Stany Zjednoczone przyjęły ustawę Computer Fraud and Abuse Act, aby wzmocnić istniejące przepisy dotyczące oszustw komputerowych. To wyraźnie zabraniało dostępu do systemów komputerowych bez autoryzacji lub powyżej autoryzacji i miało na celu ochronę krytycznych systemów rządowych. Wkrótce potem w 1988 r. wydano ustawę Digital Millennium Copyright Act. Uznawała ona za przestępstwo ataki na kontrolę dostępu lub zarządzanie prawami cyfrowymi (DRM). W czasach, gdy hakowanie komputerów było nie tylko źle rozumiane, ale wręcz budziło strach, środowisko, w którym pracowali badacze bezpieczeństwa, mogło być bardzo wrogie. Uprawnionym badaczom należącym do społeczności hakerów pozostała teraz obawa, że znalezienie luk w zabezpieczeniach i zgłoszenie ich może skutkować podjęciem kroków prawnych lub nawet karą więzienia, zgodnie z jednym lub obydwoma tymi aktami, biorąc pod uwagę argument, że kod jest chroniony prawami autorskimi, a zatem inżynieria wsteczna jest nielegalna, lub że nieuprawniony dostęp do jakiegokolwiek systemu (nie tylko systemów rządowych) musi być karalny. W niektórych miejscach nadal się to zdarza . Zwiększona presja na hakerów, aby odróżniali się od przestępców, skłoniła wielu badaczy do zdefiniowania dla siebie zestawu zasad etycznych, który nie może budzić żadnych wątpliwości prawnych, podczas gdy inni kwestionowali odstraszający wpływ prawa i ogólną reakcję na badania nad bezpieczeństwem. Osoby z pierwszego obozu stały się znane jako „hakerzy białych kapeluszy” i decydowali się omawiać znane słabości z minimalną możliwą ilością szczegółów, aby spróbować naprawić sytuację. Hakerzy ci postanowili również wystrzegać się technik, które mogą wyrządzić szkody podczas prowadzonych przez nich badań, i wykonywać wyłącznie działania wymagające pełnego pozwolenia. To spowodowało, że resztę uznano za „hakerów w czarnych kapeluszach” dla każdego, kto mógłby kwestionować dobroć prawa. Jednak wyłoniła się trzecia grupa. Hakerzy, którzy nie chcieli wyrządzać krzywdy, ale polepszyć sytuację, byli sfrustrowani niemożnością wprowadzenia pozytywnych zmian w obliczu tych ograniczeń. Gdzie były przepisy nakładające na producentów i dostawców oprogramowania odpowiedzialność za decyzje dotyczące bezpieczeństwa, które miały negatywny wpływ na konsumentów? Odkrywanie luk nie ustało; został po prostu zepchnięty pod ziemię, podczas gdy techniki białych kapeluszy nadal były utrudnione w tym, co udało im się odkryć, ze względu na prawne ograniczenia ich metod. W przypadku pewnej podgrupy hakerów nie chodziło wyłącznie o przestrzeganie zasad, ale nie chodziło też o osobiste korzyści ani wyrządzenie szkody. Wyrażenie „hakowanie w szarym kapeluszu” zostało po raz pierwszy użyte przez Peitera „Mudge” Zatko w 1997 r. podczas pierwszego postępowania w sprawie Black Hat1, kiedy ogłosił, że rozpocznie współpracę z firmą Microsoft w celu usunięcia luk w zabezpieczeniach.2 W tym samym wydarzeniu jego kolega haker z grupy hakerskiej L0pht, Weld Pond, ujął to najlepiej: „Po pierwsze, bycie szarym nie oznacza angażowania się w jakąkolwiek działalność przestępczą ani jej tolerowania. Z pewnością nie.  Każdy człowiek jest odpowiedzialny za swoje czyny. Bycie szarym oznacza, że uznajesz, że świat nie jest czarny ani biały.”3 Później, w 1999 r., L0pht użył tego terminu w artykule4. (Nawiasem mówiąc, kiedy po raz pierwszy zdecydowaliśmy się napisać Grey Hat Hacking, zaczęliśmy od użycia wyrażenie „szary kapelusz” (pisane przez e), ale od wydawcy dowiedział się, że „szary” jest bardziej powszechną pisownią w Wielkiej Brytanii, dlatego zdecydowano się użyć zamiast niego słowa „szary”, które jest częściej używane w Wielkiej Brytanii USA.) L0pht i inni pionierzy w tej dziedzinie wykorzystali swoją wiedzę do edukowania autorytetów, w tym do składania zeznań przed Kongresem. Ta edukacja pomogła zmienić podejście do hakerów i badań nad bezpieczeństwem, dzięki czemu dzisiejsi prawowici praktycy mogą prowadzić prace poprawiające bezpieczeństwo komputerów, bez obawy przed ściganiem z powodu braku zrozumienia. Jest to jednak delikatna równowaga i walka o utrzymanie tej równowagi toczy się z każdą nową sprawą, każdą nową technologią i każdym nowym hakerem.

Omówienie hakowania szarego kapelusza

https://chacker.pl/

Określenie „haker w szarym kapeluszu” wywołało sporo kontrowersji. Dla niektórych oznacza to hakera, który czasami łamie prawo lub robi coś nieetycznego, aby osiągnąć pożądany cel. My, jako hakerzy w szarych kapeluszach, odrzucamy tę koncepcję. Za chwilę podamy naszą definicję. Przeczytaliśmy więcej niż jedną książkę, co jeszcze bardziej zagmatwało znaczenie tego wyrażenia i zdaliśmy sobie sprawę, że autorzy tych książek po prostu nie wiedzą nic lepiej i nie uważaliby się za hakerów w szarym kapeluszu, ponieważ nie rozumieją, kim jesteśmy są, więc próbują oczerniać naszą grupę.