B

ezpieczeństwo poprzez utajnienie / bezpieczeństwo przez niejawność (ang. Security Through Obscurity – STO – / Security By Obscurity – SBO) jest jedną z wielu filozofii modelów bezpieczeństwa. Jednak jako paradygmat w wielu swoich odmianach wywołuje wiele kontrowersyjnych dyskusji w środowisku ekspertów bezpieczeństwa. Dla niektórych jest to po prostu częściowe obejście problemów, z którymi można się spotkać w wielu mechanizmach ochronnych, a dla jeszcze innych stanowi nową metodę rozwoju technik bezpieczeństwa.

Cofając się trochę w historii można natrafić na źródło pod postacią Nowego Słownika Hackerów (ang. The New Hacker’s Dictionary) świadczące o tym, że termin ten został stworzony przez hackerów w stosunku do największych wydawców systemów operacyjnych, których ulubionym „zajęciem” była sprzedaż swoich produktów z lukami w zabezpieczeniach – mianowicie poprzez ignorowanie wcześniej zgłaszanych problemów czy nie poddawanie ich dokumentacji. Posiadali oni tym samym nadzieję, że nikt się o nich nie dowie, a ludzie którzy do nich dotrą – ich nie wykorzystają. Ta „strategia” nigdy się nie sprawdzała i sprawdza się na tyle długo by od czasu do czasu nie zaskoczyć świat jakimś wydarzeniem – tak jak zrobił to 2 listopada 1988 roku robak Roberta Tappan’a Morris’a (ang. Morris Worm), który bazując na słabościach zabezpieczeń ówczesnych systemów BSD w wersji 4.2 oraz 4.3, Sun Microsystems oraz VAX unieruchomił na 8 dni 6 tysięcy komputerów. Lecz dzięki takim wydarzeniom producenci oprogramowania nie raz zastanawiają się nad swoimi płytkimi poczynaniami w względach bezpieczeństwa – przewracając się na drugi bok by móc wrócić do spokojnego snu. Przecież, tak naprawdę poważne naprawianie błędów musiało by poświęcić wszystkie zasoby potrzebne do implementacji kolejnych, nowych wersji interfejsów użytkownika, które jak wiadomo są ulubioną falbaną na liście życzeń działu marketingu. Ponadto, gdyby producenci w tamtych czasach zaczęli tak chętnie naprawiać błędy związane z bezpieczeństwem klienci dzisiaj mogli by zacząć oczekiwać, że rynek informatyczny zagwarantuje im pewnego rodzaju prawo do systemu z mniejszą ilością dziur niż w podziurawionym serze szwajcarskim, co przecież w rzeczywistości stało się faktem. Powracając do etymologii sformułowania: bezpieczeństwo poprzez utajnienie – wyróżnia się dwie szkoły. Pierwsza z nich mówi, że termin ten został po raz pierwszy użyty na grupie dyskusyjnej: comp.sys.apollo w wiadomości dotyczącej prowadzenia kampanii mającej na celu wymuszenie na firmie Apollo (wykupionej przez firmę Hewlett – Packard) załatania luk w klonie Uniksa – Aegis (po wykupieniu przez HP nazwanym DomainOS). Oczywiście nie ruszono nawet palcem by zrobić coś w tej kwestii. Z drugiej strony fani systemu ITS (ang. Incompatible Timesharing System) twierdzą, że termin ten został ukuty lata wcześniej przez niesamowicie paranoiczną opozycję – czyli ludzi z MIT (ang. Massachusetts Institute of Technology) zajmujących się systemem Multics (ang. Multiplexed Information and Computing Service), dla których bezpieczeństwo było wszystkim. Odnieśli się oni do faktu kultury ITS, iż bardzo skromnie napisana dokumentacja i niejasność masy poleceń powodowała wiele problemów osobom próbującym odkryć możliwości tego systemu. Dlatego ludzie, którzy pragnęli podzielić się swoimi osiągnięciami ze społecznością ITS dokonywała najpierw różnych, niezamierzonych komplikacji w swoim systemie, by później odkryć rzeczywiste przeznaczenie wykonywanych komend. Jednym z „zamierzonych” przypadków użycia bezpieczeństwa przez utajnienie, który został zarejestrowany w tamtych czasach – było użycie komendy pozwalającej na nałożenie poprawki na pracujący w normalnym trybie system ITS (poprzez kombinację klawiszy: alt alt control-R) – wyświetlanej jako: $$^D. Gdybyśmy w rzeczywistości wpisali: alt alt ^D – ustawiło by to flagę systemu, która uniemożliwiałaby łatanie systemu, nawet w przypadku, gdybyśmy później wklepali jej poprawną kombinację.

     W dzisiejszych czasach termin ten jest postrzegany jako procesy mające zapewnić ukrycie ustawień systemowych, konfiguracji, implementacji czy newralgicznych punktów systemu w celu wprowadzenia w błąd potencjalnych agresorów. Dla wielu osób (głównie producentów oprogramowania) technika ta ma sens, gdyż zakładają oni, że nawet jeśli system posiada luki to nieznajomość ich szczegółów technicznych uniemożliwia przeprowadzenie za ich pomocą ataku. W tym świetle, trudno by nie podzielić zdania ekspertów od zabezpieczeń nisko oceniających tą filozofię, zwłaszcza jeśli jest ona jedynym zabezpieczeniem systemu. Wynika to z kilku prostych przesłanek: tajemnice bardzo trudno utrzymać – szczególnie umieszczanie informacji w dwójkowym kodzie komputera nie gwarantuje ich tajemnicy i co najwyżej wymaga jedynie trochę więcej wysiłku ze strony atakującego; ludzie, którym powierzamy tajemnice w rzeczywistości mogą być ludźmi, którzy dokonają na nas ataku; luki w bezpieczeństwie podawane są bardzo często do wiadomości publicznej, dlatego ich utajnianie bardzo szybko wychodzi na światło dzienne; błędy w mechanizmach zabezpieczeń mogą zostać wykryte bez dostępu do ukrytych zasobów – zresztą w przypadku ukrywania zasobów pod postacią zamkniętych źródeł może zostać użyta inżynieria wsteczna (ang. reverse engineering), a powoływanie się na łamanie praw autorskich przy użyciu inżynierii wstecznej jest pozbawione sensu, gdyż zdecydowani napastnicy w fazie ataku są gotowi złamać prawo pod wieloma względami. Ma to również negatywny wpływ na badania nad skutecznością różnych zabezpieczeń, gdyż takie ujęcie nie dopuszcza do recenzowania systemów bezpieczeństwa [patrz „Zjawisko bezpieczeństwa otwartego systemu Linux” / Linux+ nr 1 (117) styczeń 2007] – jednak nadal poparcie dla zamkniętych źródeł znajduje oddźwięk w oczach wielu samo oszukujących się ignorantów lub polityków tracących nie swoje pieniądze na komercyjne rozwiązania. Lider ruchu Open Source – Eric S. Raymond negujący każdą formę zamkniętego oprogramowania swoje racje opiera na przykładzie otwartych mechanizmów kryptograficznych. Mimo, że wiele bardzo dobrych algorytmów szyfrowania w pełni ujawnia swoje zasady działania to i tak ich jawność nie prowadzi do bezproblemowego odczytania zaszyfrowanych nimi treści. Potwierdza to tylko jedną z zasad współczesnej kryptografii, którą sformułował w XIX wieku holenderski kryptolog August Kerckhoffs – szyfry najczęściej spotykane w współczesnych systemach informatycznych (np. 3DES, AES, Blowfish, itd.) opierają swoją siłę nie na tajności samego algorytmu, a jedynie na tajności zmiennego parametru tego algorytmu, jakim jest klucz. Zgodnie z tą zasadą nowy algorytm z wielu względów powinien być publicznie znany. Za tą prawidłowością przemawia ułatwienie jego publicznej oceny i dyskusji na temat jego jakości wśród kryptoanalityków. Dzięki temu, łatwiej i znacznie wcześniej można wykryć ewentualne niedociągnięcia w jego konstrukcji. Zasada bezpieczeństwa przez niejawność w kryptografii była powszechniej akceptowana w czasach, gdy wszyscy kryptografowie o olbrzymiej wiedzy byli zatrudnieni przez państwowe agencje wywiadowcze, takie jak NSA (ang. National Security Agency). Ponieważ teraz kryptoanalitycy często pracują dla uniwersytetów (gdzie publikują mnóstwo swoich odkryć [może nawet wszystkie] i podają analizie osiągnięcia, i prace innych) albo dla prywatnych firm (gdzie wyniki ich pracy częściej kontrolowane są poprzez patenty i prawa autorskie niż przez tajemnice) dyskusja na temat STO w kryptografii straciła wiele na swojej dawnej popularności. Przykładem może być PGP (ang. Pretty Good Privacy) wypuszczony jako program o wolnym dostępie do kodu źródłowego (od wersji 5.0 stał się produktem komercyjnym) i gdyby dobrze się zastanowić (o odpowiednim jego użyciu) – jako kryptosystem godny stopnia militarnego. Analogicznie z kryptografii można odnieść się do udostępniania kodów źródłowych. Bez zbędnego utajniania kodu dla szerokiej publiki odbiorców wśród, której znajdują się również fachowcy najwyższej klasy – taki zabieg potrafi zapewnić wysoką jakość, formalną poprawność oraz szybsze wykrywanie luk bezpieczeństwa niż w zamkniętym odpowiedniku.

      E.S. Raymond nawet w tym celu sformułował Prawo Linus’a (ang. Linus’s Law od imienia Linus’a Torvalds’a), o którym możemy przeczytać w jego sławnym eseju „Katedra i Bazar” (ang. „The Cathedral and The Bazaar”). Opiera się ono na stwierdzeniu iż, „danie wystarczająco dużej ilości pary oczu spowoduje, że wszystkie błędy staną się powierzchowne”, co w bardziej formalnej formie oznacza, iż zwrócenie się do wystarczająco dużej ilości beta-testerów oraz współdeveloperów spowoduje bardzo szybką charakterystykę prawie każdego problemu, tym samym dostarczając oczywistych ich rozwiązań. Prawo Linus’a podchodzi również pod dużą krytykę, głównie ze strony producentów zamkniętego oprogramowania. Eksperci w dziedzinie rozwoju oprogramowania – Robert Glass, Michael Howard oraz David LeBlanc w swojej książce „Writing Secure Code” zakwestionowali to prawo – twierdząc, że napisanie aplikacji opartej na tym prawie może prowadzić do problemów związanych jej bezpieczeństwem i utrzymaniem jej w dobrym stanie rozwojowym – powołując się na małą liczbę przypadków wkładu poczynionego przez ludzi „zewnątrz” (nie należących do grona oficjalnych developerów) do projektów Open Source. Jest to w dużej mierze rezultat działania samego prawa, gdyż każdy potencjalny developer musi na początku wgłębić się w działanie całego środowiska programistycznego, zrozumieć najważniejsze fragmenty kodu zanim będzie mógł go efektywnie rozwijać. Niektóre początkujące projekty również świadomie odrzucają zewnętrzną pomoc w obawie, że może ona przynieść trudne do wykrycia błędy lub luki w zabezpieczeniach. Można tutaj przywołać przykład John’a Viery – twórcy oprogramowania do obsługi list dyskusyjnych – Mailman. Pomimo otwartego źródła przez trzy lata był on zmuszony do samodzielnego nanoszenia poprawek i usuwania błędów, gdyż nigdy nie zaoferowano mu zewnętrznej pomocy mimo licznej społeczności użytkowników tego programu. Sam Viera uważa, że masa użytkowników wiedziała o wielu błędach jednak liczyli oni na to, że ktoś inny się nimi zajmie. Oczywiście Microsoft w swojej antylinuksowej kampanii „Get the facts” promującej Windows Server w 2007 roku wykorzystał to prawo przeciwko społeczności Linuksa i posłużył się oświadczeniem Ben’a Laurie – dyrektora bezpieczeństwa Apache Foundation (w rzeczywistości organizacja ta nazywa się Apache Software Foundation, a Pan Laurie był jedynie członkiem drużyny związanej z bezpieczeństwem, ponieważ fundacja ta nie posiada żadnego dyrektora bezpieczeństwa – lecz MS jak zawsze lubi ubarwiać), który stwierdził, że: „pomimo tego, że zostaje ono użyte w dyskusjach, jest dla mnie jasnym, iż prawo „wielu oczu” jako argument odnoszący się do bezpieczeństwa, nie ma racji bytu”. W późniejszym czasie Laurie wyjaśnił owo oświadczenie na swoim blogu, tłumacząc się, że miał on po prostu na myśli, iż wielu ludzi czytających kod nie stanowi gwarancji wyszukania wszystkich luk, a nie to – że prawo „wielu oczu” nie pomagało w cale w ich odkrywaniu. Poddał również dyskusji fakt, iż otwarte oprogramowanie jest lepszą gwarancją bezpieczeństwa, odkąd każdy może zbadać jego kod i szukać w nim skaz, co stanowi kontrast do zamkniętych źródeł, gdzie jednostka musi zaufać sprzedawcą, gdy ci mówią, że ich produkt jest bezpieczny. Nawet Linus Trovalds osobiście opisał pojęcie prawa Linus’a w prologu do książki „The Hacker Ethic”: „Prawo Linus’a mówi o tym, że wszystkie z naszych motywacji wpadają do trzech podstawowych kategorii. Co ważniejsze, w postępie chodzi o przedostawanie się przez te same rzeczy postrzegane jako ‘etapy’ – w procesie ewolucji, jest to sprawa przejścia z jednej kategorii do następnej. Tymi kategoriami w kolejności są ‘przetrwanie’, ‘życie towarzyskie’ oraz ‘rozrywka’. Można domniemać, iż Trovalds miał na myśli podejście jakim posłużyli się autorzy „Writing Secure Code”, jednak ujął je bardziej z punktu socjologicznego. Wielu użytkowników na początku zadba o swój byt (poprzez etatową pracę np. pod postacią pisania komercyjnego oprogramowania), rodzinę i jej potrzeby, a dopiero rozrywkę, której częścią może być pomoc w rozwoju różnych wolnych projektów. Oczywiście, niektórzy programiści zarabiają na życie poprzez testowanie oprogramowania, mechanizmów bezpieczeństwa i zgłaszanie poprawek, co przenosi ich od razu do pierwszej kategorii, ale za to odejmuje z trzeciej, gdyż poświęcanie się dodatkowo w wolnym czasie temu samemu zajęciu, co w zawodowej pracy nie będzie stanowić już dla nich rozrywki. Wszystko to rozgrywa się w klatce czasu, która pozwala na mniejsze lub większe zaangażowanie użytkowników w rozwój projektów Open Source. Powyższą wypowiedź możemy również przyrównać do hierarchii potrzeb (ang. needs hierarchy) według modelu Abrahama Masłowa. Wprowadzając samorealizację, czyli potrzebę posiadania celu np. pod postacią rozwoju danego projektu programistycznego, dzięki czemu zaspokoimy również swoje potrzeby wiedzy, zrozumienia i nowości; oraz potrzebę uznania (szacunku) i prestiżu we własnych oczach i oczach innych developerów projektu, które pozwolą nam z czasem na zdobycie dobrego statusu społecznego i sławy. Zjawiska te doskonale tłumaczą nam przeszkody, na które napotykają procesy rozwoju wolnego oprogramowania przy próbie zaangażowania się osób zewnątrz, a prawo Linus’a mimo wielu sprzecznych opinii ukazuje nam obraz bezpieczeństwa poprzez utajnienie odnoszącego się do otwartych i zamkniętych źródeł.

      Posiadając już omówione aspekty producentów oprogramowania, otwartych i zamkniętych źródeł oraz mechanizmów kryptograficznych odnoszących się do STO, pozostaje nam rozpatrzeć pozytywny wpływ bezpieczeństwa poprzez utajnienie jako wsparcie jednej z warstw w wielowarstwowej strategii obrony (ang. defense in depth). Obrona taka polega na budowie bezpiecznego środowiska IT poprzez użycie wielu warstw zabezpieczeń chroniących personel, technologię oraz operacje związane z normalnym cyklem życia danego systemu np. użycie jednocześnie zabezpieczeń fizycznych (drzwi, zamków), biometrii i mechanizmów autoryzacji (haseł, kluczy elektronicznych) klasyfikuje już zabezpieczenia do wielowarstwowych. Dlaczego bezpieczeństwo przez niejawność powinno być tylko wsparciem, a nie kolejną warstwą? Ponieważ jako oddzielna warstwa kwalifikuje się do mechanizmu, który opiera się wyłącznie na tajemnicy, a jako wsparcie umożliwia wzmocnienie i redukcję ryzyka wykorzystania luki we wspieranej warstwie. Dlatego niejawność różnych rozwiązań w zabezpieczeniach, kiedy zostanie dodana do systemu, w którym istnieją już dobrze skonfigurowane mechanizmy ochronne nie koniecznie musi być czymś złym. W prawdzie, kiedy dobrze ją zastosować, może być silnym dodatkiem do naszej wielowarstwowej ochrony. Oczywiście jej zastosowanie ma mniejszy lub większy sens w określonych warunkach. Głównymi przesłankami są cele jakie pragniemy osiągnąć. Na początku należy zastanowić się o ewentualnych konsekwencjach wynikających z faktu, że nasza tajemnica zostanie odkryta. Dla przykładu: posiadamy dom z bardzo wartościową zawartością, który jest chroniony najnowszym systemem alarmowym oraz posiada zamki, do których nie ma możliwości podrobienia kluczy. Jednak kod do alarmu jak i same klucze w tajemnicy przed wszystkimi przechowujemy w naszej skrzynce pocztowej. W tym przypadku alarm i zamek są warstwami, które oparte są wyłącznie o naszą tajemnicę przechowywania do nich środków dostępu. W przypadku, gdy ktoś odkryje miejsce przechowywania naszych kluczy oraz kodu – mimo bardzo dobrych zabezpieczeń – cały system zostaje skompromitowany. Porównać możemy to do wcześniej omówionej kryptografii, w której całe bezpieczeństwo by opierało się na tajemnicy działania algorytmu. Do tego samego przykładu możemy odnieść utajnienie pewnego faktu bezpieczeństwa jako wsparcie dla jednej z warstw zabezpieczeń. Załóżmy, że ten sam dom jest chroniony przez alarm oraz 3 różne klucze. Naszą tajemnicą będzie kombinacja w jakiej należy włożyć kluczę do drzwi, aby móc otworzyć drzwi w innym przypadku uruchomi się alarm. Alarm uruchomi się także jeśli nie zostanie do niego wpisany odpowiedni kod po otworzeniu drzwi. Jak widzimy, już w tym przypadku odkrycie naszej tajemnicy nie kompromituje całego systemu zabezpieczeń, ponieważ nawet po otworzeniu drzwi musimy uporać się jeszcze z alarmem. Odbiciem tego w kryptografii była by steganografia zastosowana jako ukrycie wiadomości w jednym z trzech identycznych obrazów. Mimo, iż odkryliśmy tajemnicę, w którym obrazie kryje się wiadomość to i tak nie posiadamy możliwości jej odczytania. Tymi samymi schematami możemy odnieść się do mechanizmów wykorzystywanych w zabezpieczeniach systemu Linux. Pierwszym przykładem będzie mało istotny fakt jakim jest zastosowanie aliasów pocztowych. Jak wiadomo aliasy pocztowe służą m.in. do ładnej prezentacji adresu e-mail na wizytówkach firmowych, jednak posiadają również drugą funkcję – potrafią ukryć prawdziwą nazwę użytkownika służącą do logowania w systemie. Nawet jeśli zostanie ona ujawniona – pozostaje jeszcze dobrze skonstruowane hasło, które trzeba złamać. Bardziej wyrafinowanym przykładem użycia bezpieczeństwa przez niejawność jako wsparcia innej warstwy jest zastosowanie portknockingu. Technika ta pozwala na ukrycie usług sieciowych za dodatkową warstwą ochroną czyniąc je niewidocznymi dla skanerów portów, ponieważ pomiędzy Internetem, a usługami znajduje się zapora sieciowa, która jest dziurawiona przez odpowiednią sekwencję pakietów wysłanych na odpowiedni port. Jeśli w ten sposób poddajemy ochronie usługę SSH, to nawet odkrycie odpowiedniej sekwencji pakietów i portu uniemożliwi nam dostanie się do systemu, gdyż będziemy zmuszeni przejść jeszcze przez autoryzację kolejnej warstwy zabezpieczeń jaką jest nasłuchujący serwer SSH. Nie uzależniliśmy ani zastąpiliśmy w ten sposób naszej podstawowej warstwy zabezpieczeń od innej opartej na utajnieniu, a po prostu dodaliśmy ją do już istniejącej. Tak więc, widzimy, że bezpieczeństwo poprzez utajnienie, niezależnie gdzie zostanie użyte – czy w ochronie źródeł, kryptografii czy warstwie zabezpieczeń – swoją funkcjonalność zawdzięcza głównie celowi, w jakim zostało wykorzystane. Licząc się ze zastosowaniem tego rozwiązania zawsze należy mieć na uwadze konsekwencje jakie grożą nam, gdy nasz utajniony mechanizm zabezpieczeń zostanie odgadnięty. Nigdy nie należy opierać żadnej warstwy czy części chronionego systemu na tej filozofii, ponieważ stanowi ona zbyt słabą ochronę. Jednak przy zastosowaniu jej jako nakładki na już dobrze funkcjonujący mechanizm zabezpieczeń możemy z pewnością wesprzeć jego funkcjonalność. Nie stoi nic na przeszkodzie by nasze tajemnice również poddać podwójnemu zabezpieczeniu, tak by ich odgadnięcie wymagało pokonania kolejnej warstwy ochrony.

Felieton ten pochodzi z magazynu: Linux+ Nr 10 (137) Październik 2008.