2008.10_Bezpieczeństwo poprzez utajnienie_[Bezpieczenstwo].pdf

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

poprzez utajnienie

Patryk Krawaczyński

Bezpieczeństwo poprzez utajnienie / bezpieczeństwo przez niejawność (ang. Security Through

Obscurity – STO – / Security By Obscurity – SBS) jest jedną z wielu ilozoii modeli bezpieczeństwa,

jednak jako paradygmat w wielu swoich odmianach wywołuje wiele kontrowersyjnych dyskusji w

środowisku ekspertów bezpieczeństwa.

ście problemów, z którymi można się spotkać

w wielu mechanizmach ochronnych, a dla jesz-

cze innych stanowi nową metodę rozwoju tech-

nik bezpieczeństwa. Cofając się trochę w historii można natra-

ić 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 zabezpie-

czeniach – mianowicie poprzez ignorowanie wcześniej zgła-

szanych problemów czy nie poddawanie ich dokumentacji. Po-

siadali oni tym samym nadzieję, że nikt się o nich nie dowie, a

ludzie którzy do nich dotrą – nie wykorzystają ich. Ta strategia

nigdy nie sprawdzała i sprawdza się na tyle długo, by od cza-

su do czasu nie zaskoczyć świat jakimś wydarzeniem - tak jak

zrobił to 2 listopada 1988 roku robak Roberta Tappan'a Morri-

sa (tzw. Morris Worm), który bazując na słabościach zabezpie-

czeń ówczesnych systemów BSD w wersji 4.2 oraz 4.3, Sun Mi-

crosystems oraz VAX unieruchomił na 8 dni 6 tysięcy kompute-

rów. Lecz dzięki takim wydarzeniom producenci oprogramowa-

nia 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ę, po-

ważne naprawianie błędów musiałoby poświęcić wszystkie za-

soby potrzebne do implementacji kolejnych, nowych wersji in-

terfejsów użytkownika, które jak wiadomo są ulubioną falbaną

na liście życzeń działu marketingu. Ponadto, gdyby producen-

ci w tamtych czasach zaczęli tak chętnie naprawiać błędy zwią-

zane z bezpieczeństwem, klienci dzisiaj mogliby zacząć oczeki-

wać, że rynek informatyczny zagwarantuje im pewnego rodzaju

prawo do systemu z mniejszą ilością dziur niż w podziurawio-

nym 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 prowa-

dzenia kampanii mającej na celu wymuszenie na irmie Apollo

(wykupionej przez irmę Hewlett - Packard) załatania luk w klo-

nie Uniksa – Aegis (po wykupieniu przez HP nazwanym Doma-

inOS). Oczywiście nie ruszono nawet palcem, by zrobić coś w

tej kwestii. Z drugiej strony fani systemu ITS (ang. Incompati-

ble Timesharing System ) twierdzą, że termin ten został ukuty la-

ta wcześniej przez niesamowicie paranoiczną opozycję – czy-

październik 2008

Bezpieczeństwo

D la niektórych jest to po prostu częściowe obej-

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

li ludzi z MIT (ang. Massachusetts Institute of

Technology ) zajmujących się systemem Mul-

tics (ang. Multiplexed Information and Compu-

ting Service ), dla których bezpieczeństwo było

wszystkim. Odnieśli się oni do faktu kultury ITS,

iż bardzo skromnie napisana dokumentacja i nie-

jasność masy poleceń powodowała wiele proble-

mów osobom próbującym odkryć możliwości te-

go systemu. Dlatego ludzie, którzy pragnęli po-

dzielić się swoimi osiągnięciami ze społecznością

ITS dokonywali najpierw różnych, niezamierzo-

nych komplikacji w swoim systemie, by później

odkryć rzeczywiste przeznaczenie wykonywa-

nych komend. Jednym z zamierzonych przypad-

kó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 po-

prawki na pracujący w normalnym trybie system

ITS (poprzez kombinację klawiszy: alt alt con-

trol-R ) – wyświetlanej jako: $$^D . Gdybyśmy w

rzeczywistości wpisali: alt alt ^D , ustawiłoby to

lagę systemu, która uniemożliwiałaby łatanie go

nawet w przypadku, gdybyśmy później wklepali

poprawną kombinację.

W dzisiejszych czasach termin ten jest po-

strzegany jako procesy mające zapewnić ukry-

cie ustawień systemowych, koniguracji, imple-

mentacji czy newralgicznych punktów systemu w

celu wprowadzenia w błąd potencjalnych agreso-

rów. Dla wielu osób (głównie producentów opro-

gramowania) technika ta ma sens, gdyż zakładają

oni, że nawet jeśli system posiada luki, to niezna-

jomość ich szczegółów technicznych uniemoż-

liwia przeprowadzenie za ich pomocą ataku. W

tym świetle trudno nie podzielić zdania ekspertów

od zabezpieczeń nisko oceniających tę ilozoię,

zwłaszcza jeśli jest ona jedynym zabezpieczeniem

systemu. Wynika to z kilku prostych przesłanek:

tajemnice bardzo trudno utrzymać – szczegól-

nie umieszczanie informacji w dwójkowym ko-

dzie komputera nie gwarantuje ich tajemnicy i co

najwyżej wymaga jedynie trochę więcej wysiłku

ze strony atakującego; ludzie, którym powierza-

my 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 mechani-

zmach zabezpieczeń mogą zostać wykryte bez

dostępu do ukrytych zasobów – zresztą w przy-

padku ukrywania zasobów pod postacią zamknię-

tych źródeł może zostać użyta inżynieria wstecz-

na (ang. reverse engineering ), a powoływanie się

na łamanie praw autorskich przy użyciu inżynierii

wstecznej jest pozbawione sensu, gdyż zdecydo-

wani 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 do-

puszcza 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 samooszuku-

jących się ignorantów lub polityków tracących nie

swoje pieniądze na komercyjne rozwiązania. Li-

der ruchu Open Source – Eric S. Raymond negu-

jący każdą formę zamkniętego oprogramowania

swoje racje opiera na przykładzie otwartych me-

chanizmów kryptograicznych. Mimo, że wiele

bardzo dobrych algorytmów szyfrowania w peł-

ni ujawnia swoje zasady działania to i tak ich jaw-

ność nie prowadzi do bezproblemowego odczyta-

nia zaszyfrowanych nimi treści. Potwierdza to tyl-

ko jedną z zasad współczesnej kryptograii, którą

sformułował w XIX wieku holenderski kryptolog

August Kerckhoffs – szyfry najczęściej spotyka-

ne w współczesnych systemach informatycznych

(np. 3DES, AES, Blowish, itd.) opierają swoją si-

łę nie na tajności samego algorytmu, a jedynie na

tajności zmiennego parametru tego algorytmu, ja-

kim jest klucz. Zgodnie z tą zasadą nowy algo-

rytm z wielu względów powinien być publicznie

znany. Za tą prawidłowością przemawia ułatwie-

nie jego publicznej oceny i dyskusji na temat jego

jakości wśród kryptoanalityków. Dzięki temu ła-

twiej i znacznie wcześniej można wykryć ewen-

tualne niedociągnięcia w jego konstrukcji. Za-

sada bezpieczeństwa przez niejawność w kryp-

tograii była powszechnie akceptowana w cza-

sach, gdy wszyscy kryptografowie o olbrzymiej

wiedzy byli zatrudnieni przez państwowe agen-

cje wywiadowcze, takie jak NSA (ang. National

Security Agency ). Ponieważ teraz kryptoanalitycy

często pracują dla uniwersytetów (gdzie publiku-

ją mnóstwo swoich odkryć [może nawet wszyst-

kie] i podają analizie osiągnięcia i prace innych)

albo dla prywatnych irm (gdzie wyniki ich pra-

cy częściej kontrolowane są poprzez patenty i pra-

wa autorskie, niż przez tajemnice) dyskusja na te-

mat STO w kryptograii 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 je-

go użyciu) – jako kryptosystem godny stopnia mi-

litarnego. Analogicznie z kryptograii można od-

nieść się do udostępniania kodów źródłowych.

Bez zbędnego utajniania kodu dla szerokiej publi-

ki odbiorców, wśród której znajdują się również

fachowcy najwyższej klasy – taki zabieg potrai

zapewnić wysoką jakość, formalną poprawność

oraz szybsze wykrywanie luk bezpieczeństwa niż

w zamkniętym odpowiedniku.

E.S. Raymond sformułował nawet w tym ce-

lu Prawo Linusa (ang. Linus' Law od imienia Li-

nusa Torvaldsa), 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, że danie wystarczająco dużej ilo-

ści pary oczu spowoduje, że wszystkie błędy sta-

ną się powierzchowne , co w bardziej formalnej

formie oznacza, iż zwrócenie się do wystarcza-

jąco dużej ilości beta-testerów oraz współdeve-

loperów spowoduje bardzo szybką charaktery-

stykę prawie każdego problemu, tym samym do-

starczając oczywistych ich rozwiązań. Prawo Li-

nusa podchodzi również pod dużą krytykę, głów-

nie ze strony producentów zamkniętego oprogra-

mowania. Eksperci w dziedzinie rozwoju opro-

gramowania – Robert Glass, Michael Howard

oraz David LeBlanc w swojej książce Writing

Secure Code zakwestionowali to prawo twier-

dząc, że napisanie aplikacji opartej na nim może

prowadzić do problemów związanych z jej bez-

pieczeństwem i utrzymaniem jej w dobrym sta-

nie rozwojowym – powołując się na małą licz-

bę przypadków wkładu poczynionego przez lu-

dzi z zewnątrz (nie należących do grona oicjal-

nych 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 środowi-

ska programistycznego i zrozumieć najważniej-

sze fragmenty kodu, zanim będzie mógł go efek-

tywnie rozwijać. Niektóre początkujące projekty

również świadomie odrzucają zewnętrzną pomoc

w obawie, że może ona przynieść trudne do wy-

krycia błędy lub luki w zabezpieczeniach. Moż-

na tutaj przywołać przykład Johna Viery – twór-

cy oprogramowania do obsługi list dyskusyjnych

Mailman. Pomimo otwartego źródła przez trzy la-

ta był on zmuszony do samodzielnego nanoszenia

poprawek i usuwania błędów, gdyż nigdy nie za-

oferowano 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ś in-

ny się nimi zajmie. Oczywiście Microsoft w swo-

jej antylinuksowej kampanii Get the facts promu-

jącej Windows Server w 2007 roku wykorzystał

to prawo przeciwko społeczności Linuksa i posłu-

żył się oświadczeniem Bena Laurie – dyrektora

bezpieczeństwa Apache Foundation (w rzeczywi-

stości organizacja ta nazywa się Apache Softwa-

re Foundation, a Pan Laurie był jedynie człon-

kiem drużyny związanej z bezpieczeństwem, po-

nieważ fundacja ta nie posiada żadnego dyrektora

bezpieczeństwa – lecz MS jak zawsze lubi ubar-

wiać), który stwierdził, że: pomimo tego, że zosta-

je 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świadcze-

nie na swoim blogu tłumacząc, że miał on po pro-

stu na myśli, iż wielu ludzi czytających kod nie

www.lpmagazine.org

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

stanowi gwarancji wyszukania wszystkich luk a

nie to, że prawo wielu oczu nie pomagało wcale

w ich odkrywaniu. Poddał również dyskusji fakt,

iż otwarte oprogramowanie jest lepszą gwaran-

cją bezpieczeństwa, odkąd każdy może zbadać

jego kod i szukać w nim skaz, co stanowi kon-

trast do zamkniętych źródeł, gdzie jednostka mu-

si zaufać sprzedawcom gdy ci mówią, że ich pro-

dukt jest bezpieczny. Nawet Linus Trovalds oso-

biście opisał pojęcie prawa Linusa w prologu do

książki The Hacker Ethic : Prawo Linusa 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 sa-

me rzeczy postrzegane jako 'etapy' – w procesie

ewolucji, jest to sprawa przejścia z jednej kate-

gorii do następnej. Tymi kategoriami w kolejno-

ści są 'przetrwanie', 'życie towarzyskie' oraz 'roz-

rywka'. Można domniemać, iż Trovalds miał na

myśli podejście jakim posłużyli się autorzy Wri-

ting Secure Code , jednak ujął je bardziej z punk-

tu socjologicznego. Wielu użytkowników na po-

czątku zadba o swój byt (poprzez etatową pracę

np. pod postacią pisania komercyjnego oprogra-

mowania), rodzinę i jej potrzeby, a dopiero roz-

rywkę, 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 testo-

wanie oprogramowania, mechanizmów bezpie-

czeństwa i zgłaszanie poprawek, co przenosi ich

od razu do pierwszej kategorii, ale za to odejmu-

je z trzeciej, gdyż poświęcanie się dodatkowo w

wolnym czasie temu samemu zajęciu, co w zawo-

dowej pracy nie będzie stanowić już dla nich roz-

rywki. Wszystko to rozgrywa się w klatce czasu,

która pozwala na mniejsze lub większe zaangażo-

wanie użytkowników w rozwój projektów Open

Source. Powyższą wypowiedź możemy rów-

nież przyrównać do hierarchii potrzeb (ang. ne-

eds hierarchy ) według modelu Abrahama Masło-

wa. Wprowadzając samorealizację, czyli potrze-

bę posiadania celu np. pod postacią rozwoju da-

nego projektu programistycznego, dzięki czemu

zaspokoimy również swoje potrzeby wiedzy, zro-

zumienia i nowości; oraz potrzebę uznania (sza-

cunku) i prestiżu we własnych oczach i oczach in-

nych developerów projektu, które pozwolą nam

z czasem na zdobycie dobrego statusu społeczne-

go i sławy. Zjawiska te doskonale tłumaczą nam

przeszkody, na które napotykają procesy rozwo-

ju wolnego oprogramowania przy próbie zaanga-

żowania się osób zewnątrz, a prawo Linusa mimo

wielu sprzecznych opinii ukazuje nam obraz bez-

pieczeństwa poprzez utajnienie odnoszącego się

do otwartych i zamkniętych źródeł.

Posiadając już omówione aspekty produ-

centów oprogramowania, otwartych i zamknię-

tych źródeł oraz mechanizmów kryptograicz-

nych 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. defen-

se in depth ). Obrona taka polega na budowie bez-

piecznego środowiska IT poprzez użycie wielu

warstw zabezpieczeń chroniących personel, tech-

nologię oraz operacje związane z normalnym cy-

klem życia danego systemu, np. użycie jednocze-

śnie zabezpieczeń izycznych (drzwi, zamków),

biometrii i mechanizmów autoryzacji (haseł, klu-

czy elektronicznych) klasyikuje już zabezpiecze-

nia do wielowarstwowych. Dlaczego bezpieczeń-

stwo przez niejawność powinno być tylko wspar-

ciem, a nie kolejną warstwą? Ponieważ jako od-

dzielna warstwa kwaliikuje się do mechanizmu,

który opiera się wyłącznie na tajemnicy, a jako

wsparcie umożliwia wzmocnienie i redukcję ry-

zyka wykorzystania luki we wspieranej warstwie.

Dlatego niejawność różnych rozwiązań w za-

bezpieczeniach, kiedy zostanie dodana do syste-

mu, w którym istnieją już dobrze skonigurowa-

ne mechanizmy ochronne niekoniecznie musi

być czymś złym. Wprawdzie, kiedy dobrze ją za-

stosować, może być silnym dodatkiem do naszej

wielowarstwowej ochrony. Oczywiście jej zasto-

sowanie ma mniejszy lub większy sens w okre-

ślonych warunkach. Głównymi przesłankami są

cele, jakie pragniemy osiągnąć. Na początku na-

leży pomyśleć o ewentualnych konsekwencjach

wynikających z faktu, że nasza tajemnica zosta-

nie odkryta. Dla przykładu: posiadamy dom z bar-

dzo cenną zawartością, który jest chroniony naj-

nowszym systemem alarmowym oraz posiada

zamki, do których nie ma możliwości podrobie-

nia kluczy. Jednak kod do alarmu jak i same klu-

cze w tajemnicy przed wszystkimi przechowuje-

my w naszej skrzynce pocztowej. W tym przy-

padku 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ów-

nać możemy to do wcześniej omówionej kryp-

tograii, w której całe bezpieczeństwo opierało-

by się na tajemnicy działania algorytmu. Do te-

go samego przykładu możemy odnieść utajnie-

nie pewnego faktu bezpieczeństwa jako wspar-

cie dla jednej z warstw zabezpieczeń. Załóżmy,

że ten sam dom jest chroniony przez alarm oraz

trzy różne klucze. Naszą tajemnicą będzie kolej-

ność, w jakiej należy włożyć klucze do drzwi, aby

móc je otworzyć - w innym przypadku uruchomi

się alarm. Uruchomi się on także, jeśli nie zosta-

nie do niego wpisany odpowiedni kod. Jak widzi-

my, już w tym przypadku odkrycie naszej tajem-

nicy nie kompromituje całego systemu zabezpie-

czeń, ponieważ nawet po otworzeniu drzwi musi-

my uporać się jeszcze z alarmem. Odbiciem tego

w kryptograii byłaby steganograia, zastosowana

jako ukrycie wiadomości w jednym z trzech iden-

tycznych obrazów. Mimo, iż odkryliśmy tajemni-

cę, w którym obrazie kryje się wiadomość, to i

tak nie posiadamy możliwości jej odczytania. Ty-

mi samymi schematami możemy odnieść się do

mechanizmów wykorzystywanych w zabezpie-

czeniach systemu Linux. Pierwszym przykładem

będzie mało istotny fakt, jakim jest zastosowanie

aliasów pocztowych. Jak wiadomo aliasy poczto-

we służą m.in. do ładnej prezentacji adresu e-ma-

il na wizytówkach irmowych, jednak posiadają

również drugą funkcję – potraią ukryć prawdzi-

wą nazwę użytkownika służącą do logowania w

systemie. Nawet jeśli zostanie ona ujawniona po-

zostaje jeszcze dobrze skonstruowane hasło, które

trzeba złamać. Bardziej wyrainowanym przykła-

dem użycia bezpieczeństwa przez niejawność ja-

ko wsparcia innej warstwy jest zastosowanie por-

tknockingu. Technika ta pozwala na ukrycie usług

sieciowych za dodatkową warstwą ochronną czy-

niąc je niewidocznymi dla skanerów portów, po-

nieważ 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 odpo-

wiedniej sekwencji pakietów i portu uniemożli-

wi nam dostanie się do systemu, gdyż będziemy

zmuszeni przejść jeszcze przez autoryzację kolej-

nej warstwy zabezpieczeń jaką jest nasłuchujący

serwer SSH. Nie uzależniliśmy ani nie 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 ochro-

nie źródeł, kryptograii czy warstwie zabezpie-

czeń – swoją funkcjonalność zawdzięcza głów-

nie celowi, w jakim zostało wykorzystane. Licząc

się z zastosowaniem tego rozwiązania zawsze na-

leży mieć na uwadze konsekwencje, jakie grożą

nam, gdy nasz utajniony mechanizm zabezpie-

czeń zostanie odgadnięty. Nigdy nie należy opie-

rać żadnej warstwy czy części chronionego sys-

temu na tej ilozoii, 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ć je-

go funkcjonalność.

O autorze

Autor w wolnych chwilach prowadzi serwis

na temat administracji oraz podstawowych

mechanizmów bezpieczeństwa systemu

operacyjnego Linux – www.nfsec.pl .

Kontakt z autorem: agresor@nfsec.pl

październik 2008

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: