NFsec Logo

Niezdrowe trendy w bezpieczeństwie – full disclosure

07/03/2010 w Bezpieczeństwo, Hackultura, Hakin9 & Linux+ 1 komentarz.  (artykuł nr 229, ilość słów: 1074)

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.

Kategorie K a t e g o r i e : Bezpieczeństwo, Hackultura, Hakin9 & Linux+

Tagi T a g i : , , , , , ,

1 komentarz.

  1. Patryk Krawaczyński napisał(a):

    Doskonałym komentarzem do tego felietonu jest artykuł opublikowany na łamach serwisu Heise Online traktujący o dyskusji o odpowiedzialnym ujawnianiu luk w zabezpieczeniach, która wywiązała się na konferencji bezpieczeństwa RSA:

    Już od dłuższego czasu producenci oprogramowania i hakerzy dyskutują o tym, jak najlepiej obchodzić się z nowo odkrywanymi lukami w zabezpieczeniach. Podczas jednej z dyskusji w ramach konferencji bezpieczeństwa RSA w San Francisco dotyczącej odpowiedzialnego ujawniania usterek (Responsible Disclosure) swój krytyczny stosunek do zachowania producentów oprogramowania wyraził między innymi odkrywca Metasploita H. D. Moore. Publikuje on szczegóły na temat odkrywanych przez siebie luk bez konsultacji z producentami, w związku z czym ci ostatni zarzucają mu nieodpowiedzialność. Tymczasem Moore zapytał, kto tak naprawdę jest nieodpowiedzialny: haker, który upublicznia lukę, czy producent, który mimo lepszej wiedzy przez wiele miesięcy nie raczy jej naprawić.

    Ponadto Moore wielokrotnie spotykał się z sytuacjami, w których producenci oprogramowania nie są w stanie dostarczyć na czas odpowiednich poprawek, mimo uprzednich deklaracji co do terminu ich ukazania się. Nieistotne, czy chodzi tu o 30, 60, 90 czy 120 dni – terminy te nigdy nie są dotrzymywane. Jeśli jednak kod exploit’a nagle pojawi się na jakimś forum, poprawka jest gotowa w ciągu dziesięciu dni.

    Obecni na konferencji przedstawiciele koncernów Adobe i Microsoft tłumaczyli ciągnące się miesiącami opóźnienia koniecznością przeprowadzania obszernych testów wprowadzanych poprawek. Brad Arkin, który w Adobe odpowiada za bezpieczeństwo produktów i ochronę danych, stwierdził, że obecnie zaprogramowanie właściwej poprawki zajmuje czasami nawet tylko jeden dzień. „Jednak samo testowanie może potrwać wiele tygodni, ponieważ np. w przypadku Adobe Readera musimy przetestować 29 różnych wersji w 80 różnych językach”. Mimo to firmie Adobe udało się w ubiegłym roku zredukować czas testów z ośmiu tygodni do 15 dni i to przy takim samej faktycznej liczbie roboczogodzin.

    Tim Stanley, CISO w liniach lotniczych Continental Airlines, skierował mocne słowa do obydwu producentów: „Mnie jest obojętne, jakie panują stosunki między hakerami a producentami. Płacę bezpośrednio i pośrednio za pracę obydwu grup i chcę, aby luki były zamykane tak szybko, jak to tylko jest możliwe”. Ponadto Stanley uważa, że nie do zaakceptowania jest fakt, że firmy takie jak Microsoft przez wiele miesięcy, a nawet lat wiedzą o lukach, a ich nie łatają ani też nie informują o nich klientów. Jest mu obojętne, nad iloma lukami jednocześnie producent pracuje i jakie przez to powstają opóźnienia w testach. „Jeśli nie jesteście w stanie zapewnić odpowiednich zasobów w celu szybkiego rozwiązania problemów, poszukajcie sobie innej branży” – grzmiał Stanley.

    Ekspert od bezpieczeństwa Steve Dispensa postulował, aby producenci przez proponowanie aktualizacji przynajmniej sugerowali między wierszami, iż z wersji, których one dotyczą, nie powinno się korzystać z uwagi na występujące w nich luki w zabezpieczeniach. Producenci oprogramowania nie palą się do takich deklaracji, ponieważ obawiają się, że na podstawie tego typu porad można szybko odgadnąć, w jakim konkretnym produkcie znajdują się luki. Reakcja Tima Stanleya była znów nerwowa: „Żarty sobie robicie? Źli chłopcy są wystarczająco sprytni. Oni są w stanie wykryć lukę i bez waszych wskazówek”.

    Z kolei Dispensa na podstawie własnych doświadczeń stwierdził, że sami eksperci często nie wiedzą, jak powinni wykorzystać zdobyte informacje. Nie wiadomo, do kogo trzeba się zwrócić, jeśli np. odkryje się lukę w protokole typu SSL. „Jestem w stanie zrozumieć, że jeśli ktoś ma w perspektywie informowanie kilkunastu producentów, to woli opublikować informację o błędzie po prostu na forum” – powiedział Dispensa.

    Wszyscy uczestnicy dyskusji zgodzili się jednak, że producenci oprogramowania i dostawcy usług sieciowych powinni zdefiniować odpowiedni proces kontaktu z hakerami. „Nie może być tak, że drogocenne informacje na temat poważnych luk giną w potoku ogólnych zgłoszeń pomocy technicznej danego producenta” – stwierdziła Katie Moussouris z Microsoftu. Michael Barrett, CISO w spółce córce eBaya – PayPal – był „zniesmaczony faktem, w jaki sposób niektóre firmy podają wskazówki do obchodzenia się z hakerami na swoich stronach internetowych”.

    Z kolei dla Moore’a znacznie bardziej skandaliczny jest fakt, że luki nie są łatane we wszystkich wersjach danego oprogramowania. „W niektórych produktach znajduje się prastary kod. Jeśli łatane będą tylko aktualne wersje, np. Windows 7 i Windows Vista, wówczas nikt nie powie klientom, że problemem dotknięte są także Windows XP i Windows Server 2003”. Tim Stanley wyraził się jeszcze bardziej dobitnie: „Nieuwzględnianie starych wersji podczas łatania i nieinformowanie klientów o zagrożeniach to po prostu skandal”. Zwracając się do Adobe, Stanley nadmienił wręcz, że tego rodzaju postępowanie ociera się o oszustwo biznesowe.

Zostaw odpowiedź.

Musisz być zalogowany by móc komentować.