J

ak w każdym zjawisku zachodzącym na masową skalę, tak i w bezpieczeństwie technologii informatycznych z socjologicznego punktu widzenia można wyróżnić pojawiające się lub zanikające trendy, które w określonym czasie cieszą się większym bądź mniejszym zainteresowaniem. Te bardziej znaczące i rewolucyjne potrafią zmienić dotychczasowe paradygmaty (w tym znaczeniu – wzorcowe przykłady tworzone na podstawie historii rozwoju zabezpieczeń) w sektorze security.

     Anomalią towarzyszącą w tworzeniu pewnych kanonów postępowania w sferze bezpieczeństwa systemów czy ogólnie oprogramowania jest fakt, że zazwyczaj powstające trendy nigdy nie rozwijają się dokładnie w tym kierunku, w którym na początku przewidywali ich twórcy. Gruntownym tutaj przykładem z poziomu antropologii pokazującym esencję powyższych stwierdzeń jest tzw. trend sekularny (zachodzący pod wpływem rozwoju cywilizacji) hackingu, który jest nierozłączną częścią bezpieczeństwa IT, a nawet jego fundamentem. Ukazuje on z perspektywy historycznej główną wadę poglądu full disclosure (pełne ujawnienie błędów), którego głównym założeniem jest podanie do opinii publicznej wszystkich informacji dotyczących odkrytych błędów w zabezpieczeniach informatycznych, włączając w to wszelkie dane techniczne oraz narzędzia (exploity), które wykorzystują te błędy i pozwalają na ich dokładną analizę.

     Termin hacking w pierwotnym znaczeniu wcześnie tworzonego żargonu informatycznego był międzynarodowym określeniem czynności, które pokonują wszelkie zabezpieczenia w postaci kodów i haseł zastrzeżonych dla osób wtajemniczonych pozwalając włamać się do sieci komputerowych. Był to pierwszy trend wśród użytkowników wykorzystujących ogólnodostępne źródła informacji w Internecie. W tamtych czasach odpowiedniki dzisiejszych for – BBSy (biuletyny komputerowe) roiły się od praktycznych porad i wskazówek dosłownie ukazujących krok po kroku słabości ówczesnych systemów. W dodatku na rynku wydawniczym królowała pozycja Hacker’s Handbook Hugo Cornwalla stanowiąca główny poradnik początkujących włamywaczy. Wszystko to spowodowało obranie złej drogi przez panującą modę i metodę prezentacji informacji, wymykając się spod kontroli jej autorów – ktokolwiek ubogi umysłowo technologicznie, czy nie mający większego pojęcia o technice komputerowej – był w stanie opanować parę chwytów, zdobyć adresy, kody, hasła i dostać się do baz danych i systemów państwowych. Wówczas poświęcono wiele konferencji, aby ukształtować finalną etykę hackerów oraz stworzyć prawdziwe podziemie w Sieci dostępne tylko dla wąskiej grupy specjalistów. Głównym czynnikiem, który wpłynął na rewolucje było prawo, które w przeszłości bardzo powolnie podążało za problemami pojawiającymi się w wraz z rozpowszechnianiem się technik przestępstw komputerowych. To wraz z jego reinterpretacją oraz stworzeniem nowych przepisów nastąpiła także akceleracja rozwoju świadomości samozachowawczej osób dyktujących warunki bezpieczeństwa Internetu. Można było wtedy wyraźnie zaobserwować odłączenie się grup guru od przeciętnych skrypciaków (ang. script kiddie), co zakończyło erę bezlitosnych nadużyć informacji przeznaczonych dla osób z branży. I oto bez podłoża genetycznego nastąpiła zmiana przystosowawcza do panujących warunków wśród hackerów, którzy stali się wartościowymi osobami posługującymi się szeroką gamą języków programowania, potrafiących porozumiewać się z wieloma odmianami systemów obsługujących sieci i posiadających dość inwencji, by udoskonalać nowe i już istniejące mechanizmy zabezpieczeń, a co najważniejsze – o wykrytych lukach powiadamiali pierw producentów oprogramowania.

     Historia, która lubi się powtarzać – ukazuje, że wraz z ciągłym rozwojem technologii internetowych zwiększa się prawdopodobieństwo naruszenia bezpieczeństwa już istniejących zabezpieczeń. Każda nowa technika ataku, narzędzie, czy technologia sprzętowa daje nowe możliwości w starych warunkach, a jeszcze większa rola wiarygodnych źródeł informacji pogłębia to zjawisko. Ostatnio szczególnie jest to widoczne w bezpieczeństwie serwerów rządowych, które są masowo testowane przez niezależne serwisy zajmujące się tematyką bezpieczeństwa. W wielu przypadkach niski poziom bezpieczeństwa polega na ignorancji. Wśród administratorów tych systemów panuje przekonanie, wynikające z braku wiedzy i pewności, że do ich systemu nie można się włamać. Zatrudniani są przeciętni fachowcy, którzy nie są zbytnio zainteresowani obsługiwanym przez nich systemem. Znudzeni nie reagują na zgłoszenia osób z zewnątrz, a swoją pracę wykonują jedynie dla pieniędzy. O ile początkowa wina leży po stronie celów audytów informatycznych, tak wiele razy serwisy powiadamiające o tych zaniedbaniach, zbyt szybko ujawniają krytyczne informacje powodując automatycznie dodatkowe ataki na te serwery. Błędem jest tutaj zmiana kolejności etapów wtajemniczenia osób postronnych. W celu uzyskania wyraźnego rozgłosu podaje się pierw do informacji publicznej zaistniałe fakty, a dopiero potem powiadamia się o nich samych zainteresowanych czekając na ich oświadczenia. Pozostawia to lukę czasową pozwalającą na działanie osób o nie w pełni sprecyzowanych zamiarach, które dodatkowo wyposażone są w techniczne szczegóły ujawniane często także, przez samych testerów mających na względzie błędnie rozumowane dobro publiczne.

     Analogiczna sytuacja ma miejsce w przypadku wypuszczania przez programistów exploitów typu 0-day (zerowego dnia) oraz proof of concept (dowodów na poprawność). Kod takich exploitów publikowany jest w bardzo, krótkim czasie po oficjalnym lub nie, ogłoszeniu istnienia określonej podatności w systemie czy programie, lecz zanim producent / autor oprogramowania wypuści poprawkę naprawiającą ów błąd. Dopóki tego nie zrobi wszyscy użytkownicy korzystający z danej marki pozostają w realnym zagrożeniu. Kontrastem dla tej sytuacji może być fakt wypuszczenia przez niezależnego programistę poprawki. Problemem w tym przypadku jest także złe wykorzystanie informacji. Bardzo wiele razy podaje się od razu dane dotyczące możliwości szybkiej aktualizacji, bez jakiegokolwiek przewidywania możliwości technicznych. W ten sposób na serwerze udostępniającym stronę programisty wykonywany jest nieświadomy atak DDoS (ang. Distributed Denial of Service) przez rzucających się jednocześnie na łatę użytkowników. W dodatku istnieje także obawa, że nieoficjalna poprawka może wprowadzać niepożądane zmiany w systemie.

     Wymienione powyżej przypadki noszą znamiona metody pełnego ujawniania, która umożliwia poznanie pełnej specyfikacji wykrywanych luk. Odkrywa ona szczegóły dotyczące konfiguracji oraz jakości stosowanego oprogramowania, ale także trafia do zbyt szerokiego grona użytkowników, którzy nie zawsze pozyskane informacje wykorzystują w odpowiedni sposób. Mimo to, że zmusza ona dostawców oprogramowania by tworzyli kod o najwyższej jakości, w celu uniknięcia publicznej kompromitacji – często wykorzystywana jest do praktyk brudnego marketingu, aby pomóc zainteresowanym osobom w doborze konkurencyjnego produktu – nie zawsze bardziej bezpiecznego. Zwykli użytkownicy nie będący programistami mogącymi samemu dokonać poprawek zostają skazani na wysoki stopień niebezpieczeństwa oraz nieprzemyślane ryzyko. Wszystko to, aby konkretne osoby lub zgrupowania zyskały jednoznaczny rozgłos. Metoda full disclosure powinna być głównie stosowana w przypadku powiadamiania dostawców oprogramowania, aby w jasny i klarowny sposób przedstawić im sedno problemu, a nawet zasugerować sposób naprawy. W ten sposób cała wartość informacji kierowana jest do odpowiedniego odbiorcy. Na szczęście w ujęciu publicznym trend ten cieszy się coraz mniejszym zainteresowaniem na przestrzeni ewolucji ujawniania luk w zabezpieczeniach, w której katalizatorem jest ciągły postęp technologiczny i rosnąca świadomość wartości wielu informacji. Coraz częściej stosowanym wariantem tego procesu staje się responsible disclosure (odpowiedzialne ujawnianie), które dzięki wcześniejszemu powiadomieniu producentów pozwala im na wydanie poprawki i publiczne ogłoszenie jej dostępności; odczekaniu odpowiedniego okresu czasu, aż wszyscy odpowiedzialni użytkownicy wykonają aktualizację, a dopiero później publikacji informacji o błędzie. No i ze względu na dzisiejszy hacking wydaje się to bardziej etyczne.

Felieton ten pochodzi z magazynu: Hakin9 Nr 4 (24) Kwiecień 2007.