plik

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

październik 2008

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

www.lpmagazine.org

lin

ftw

.co

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

październik 2008

Bezpieczeństwo

Bezpieczeństwo poprzez utajnienie

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

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: agresor@nfsec.pl

O autorze