grey hat

Grey hat to haker, który szuka luk w cudzych systemach bez zgody właściciela, ale nie po to, by je wykorzystać. Znalezisko zgłasza właścicielowi albo ujawnia publicznie. Niebezpiecznik opisuje grey-hatów jako osoby, które działają w celu poprawy zabezpieczeń i generalnie nie są złe, ale potrafią przekroczyć granice etyczne lub normy prawne ^[1]. Nazwa pochodzi z umownego podziału na „kapelusze”: grey hat stoi między white hatem a black hatem.

Jak działa

Grey hat zachowuje się na początku jak napastnik, a na końcu jak badacz bezpieczeństwa. Sprawdza stronę albo usługę, której właściciel go o to nie prosił, na przykład przez skanowanie podatności albo ręczne testy. Gdy znajdzie podatność, nie kradnie danych i nie niszczy systemu, tylko informuje o problemie. Typowy przebieg pokazuje schemat poniżej.

RYS. 1Zgłoszenie od grey-hata

Różnica wobec white hata leży w pierwszym kroku. Etyczny test penetracyjny zaczyna się od zgody i uzgodnionego zakresu. Grey hat tej zgody nie ma, więc już samo wejście do systemu może być przestępstwem, nawet jeśli intencja była dobra.

Odmiany

Podział na kapelusze jest umowny i opisuje intencję oraz zgodę, a nie konkretne czynności techniczne.

W obrębie grey-hatów zachowania bardzo się różnią. Jedni po cichu powiadamiają właściciela i na tym kończą. Inni publikują szczegóły, gdy nie dostaną odpowiedzi, co może narazić użytkowników przed wydaniem poprawki. Jeszcze inni proszą o nagrodę za informację; gdy prośba zamienia się w żądanie pod groźbą ujawnienia, zachowanie zbliża się do szantażu i przestaje przypominać pracę badacza.

Granice prawne w Polsce

Polskie prawo nie zna pojęcia „grey hat”, ale reguluje czyny, których dotyczy. Art. 267 § 2 Kodeksu karnego penalizuje uzyskanie bez uprawnienia dostępu do całości lub części systemu informatycznego, a art. 269a zakłócenie pracy systemu przez działania na danych ^[2]. Artykuł 269c, dodany ustawą z 23 marca 2017 roku ^[3], wyłącza karalność za te czyny, jeśli sprawca działał wyłącznie w celu zabezpieczenia systemu albo opracowania metody zabezpieczenia, niezwłocznie powiadomił dysponenta o zagrożeniach, a jego działanie nie naruszyło interesu publicznego lub prywatnego i nie wyrządziło szkody ^[2].

Ten przepis jest najbliższy sytuacji grey-hata, ale warunki muszą być spełnione łącznie. Nie obejmuje on na przykład ujawnienia cudzej informacji innej osobie, opisanego w art. 267 § 4 ^[2]. Publikacja cudzych danych jako „dowodu” albo żądanie zapłaty wyprowadzają więc działanie poza ochronę art. 269c.

W WordPressie

Ekosystem WordPressa ma kanały, które pozwalają zgłosić lukę bez ryzyka publicznego ujawnienia. Błędy rdzenia zgłasza się w programie WordPressa na platformie HackerOne ^[5]. Podręcznik zabrania zgłaszania problemów bezpieczeństwa publicznie na forach wsparcia i w Core Trac, nawet gdy dotyczą tylko wersji rozwojowej, beta lub RC, a szczegóły mają pozostać poufne do wydania oficjalnej poprawki ^[5]. Za zgłoszenia rdzenia przysługują nagrody, podwajane od wersji Beta 1 do ostatniej wersji Release Candidate ^[5]; to przykład programu bug bounty.

Dla podatności we wtyczkach z katalogu wordpress.org zespół wtyczek przyjmuje zgłoszenia na adres plugins@wordpress.org i oczekuje, że zgłaszający najpierw spróbuje skontaktować się z autorem wtyczki ^[6]. Prosi też, by nie ogłaszać luk publicznie, bo zwiększa to ryzyko ich wykorzystania ^[6]. Zespół nie pomaga w uzyskaniu numeru CVE, a podatne wtyczki zwykle zamyka do czasu poprawki ^[6].

Właściciel strony, który dostał zgłoszenie od nieznanej osoby, powinien je sprawdzić, a nie tylko zignorować. Nawet jeśli test odbył się bez zgody, opisana luka może być prawdziwa i znana też innym. Plik security.txt wskazuje kontakt dla takich zgłoszeń i kieruje je do właściwej osoby.

Znaczenie

Działania grey-hatów pokazują, że dobre intencje nie zastępują zgody. Ich zgłoszenia bywają cenne, bo wskazują błędy, zanim wykorzystają je przestępcy. Jednocześnie test bez zgody może zakłócić działanie systemu, a publikacja przed poprawką daje przewagę atakującym.

Dlatego środowisko bezpieczeństwa promuje skoordynowane ujawnianie podatności. CERT Polska zaleca, by zgłaszający najpierw kontaktował się bezpośrednio z właścicielem podatnego systemu, zanim zgłosi lukę do CERT i ją upubliczni ^[4]. Wpisy CVE CERT publikuje po 90 dniach od przesłania szczegółów producentowi, a wcześniej, gdy producent wyda poprawkę albo mimo prób kontaktu nie współpracuje ^[4]. CERT nie ujawnia tożsamości zgłaszającego bez jego zgody ^[4]. Taka ścieżka pozwala grey-hatowi zamienić ryzykowne działanie w zgłoszenie obsłużone przez instytucję.

Historia i przykłady

W lipcu 2017 roku Niebezpiecznik opublikował relację polskiego badacza, który w publicznym łańcuchu bloków sieci Steem znalazł hasła wpisane przez użytkowników w pole notatki przelewu ^[7]. Napisał skrypt, który wyszukał takie konta, i zmienił w nich hasła, zanim zrobili to przestępcy; według tytułu relacji przejął 11 kont i kontrolę nad kryptowalutą wartą 21 tysięcy dolarów ^[7]. Właściciele odzyskali konta i środki przez mechanizm odzyskiwania sieci Steem ^[7]. Intencja była obronna, ale właściciele kont nie wyrazili wcześniej zgody, dlatego przypadek dobrze ilustruje nieostrą granicę między white hatem a grey-hatem.