Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

68

październik 2008

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

69

www.lpmagazine.org

lin

ux

@

so

ftw

ar

ae

.co

m

.p

l

D

la 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 jesz-
cze innych stanowi nową metodę rozwoju tech-

nik bezpieczeństwa. Cofając się trochę w historii można natra-
fić 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 firmie Apollo
(wykupionej przez firmę 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-

Bezpieczeństwo

poprzez utajnienie

Bezpieczeństwo poprzez utajnienie / bezpieczeństwo przez niejawność (ang. Security Through
Obscurity – STO – / Security By Obscurity – SBS) jest jedną z wielu filozofii modeli bezpieczeństwa,
jednak jako paradygmat w wielu swoich odmianach wywołuje wiele kontrowersyjnych dyskusji w
środowisku ekspertów bezpieczeństwa.

Patryk Krawaczyński

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

68

październik 2008

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

69

www.lpmagazine.org

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
flagę 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, konfiguracji, 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ę filozofię,
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 kryptograficznych. 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 kryptografii, którą
sformułował w XIX wieku holenderski kryptolog
August Kerckhoffs – szyfry najczęściej spotyka-
ne 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, 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-
tografii 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 firm (gdzie wyniki ich pra-
cy częściej kontrolowane są poprzez patenty i pra-
wa autorskie, niż przez tajemnice) dyskusja na te-
mat 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 je-
go użyciu) – jako kryptosystem godny stopnia mi-
litarnego. Analogicznie z kryptografii 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 potrafi
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 oficjal-
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

70

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

październik 2008

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 kryptograficz-
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ń fizycznych (drzwi, zamków),
biometrii i mechanizmów autoryzacji (haseł, klu-
czy elektronicznych) klasyfikuje już zabezpiecze-
nia do wielowarstwowych. Dlaczego bezpieczeń-
stwo przez niejawność powinno być tylko wspar-
ciem, a nie kolejną warstwą? Ponieważ jako od-
dzielna warstwa kwalifikuje 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 skonfigurowa-
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-
tografii, 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 kryptografii byłaby steganografia, 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 firmowych, jednak posiadają
również drugą funkcję – potrafią 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 wyrafinowanym 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ł, kryptografii 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 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ć je-
go funkcjonalność.

Autor w wolnych chwilach prowadzi serwis
na temat administracji oraz podstawowych
mechanizmów bezpieczeństwa systemu
operacyjnego Linux – www.nfsec.pl.
Kontakt z autorem: [e-mail]

O autorze