Bezpieczeństwo Systemów Linux

Bezpieczeństwo Systemów Linux
Wykonał: Alan Zieliński
Temat wirusów dla systemów uniksowych jest dość kontrowersyjny. Mała ilość informacji w
Internecie, brak wiarygodnych źródeł, a przede wszystkim dość popularna wśród linuksowych
nowicjuszy opinia, że Linux jest systemem odpornym na wszelkiego rodzaju zagrożenia, z jakimi
zmaga się użytkownik systemu Windows - wszystko to może wpływać na zniekształcenie
rzeczywistego obrazu sytuacji. Jak jest naprawdę? Czy wirusy dla Linuksa rzeczywiście nie powstają?
Czy używając tego systemu możemy się czuć zupełnie bezpieczni w Sieci? A jeśli nie, jak możemy
zapewnić sobie podstawowe bezpieczeństwo? Na te i wiele innych pytań postaramy się odpowiedzieć
w tym artykule.
Słabości Linuksa
Wśród niektórych użytkowników Linuksa panuje przekonanie, że Linux to system sam z siebie
bezpieczny, wolny od zagrożeń, ponieważ techniczne możliwości ich tworzenia są ograniczone. Tacy
ludzie w swojej ignorancji, bądź fascynacji "pingwinem", ślepo wierzą, że Linux jest systemem
pozbawionym nie tylko słabości, znanych z systemów z Redmond, ale pozbawionym słabości w ogóle.
Nic bardziej błędnego! Jakie zatem to więc słabe punkty ma legendarny system-twierdza? Na ogół
takie, jak każdy inny system operacyjny.
Przede wszystkim należy zwrócić uwagę na liczne luki i błędy w jądrze systemu i systemowych
programach. Jeśli ktoś interesuje się nowinkami ze świata Linuksa wie, że krytyczne luki dotyczące
bezpieczeństwa nie są wcale niczym obcym i egzotycznym w tym środowisku. Linuksa również tworzą
ludzie, a istota ludzka nie jest nieomylna. Dlaczego programiści Linuksa mieliby popełniać mniej
pomyłek, niż programiści komercyjnych systemów operacyjnych? Ktoś mógłby powiedzieć, że o
błędach w systemie Windows słyszy się dużo częściej, ale i taki argument można zbić bez problemu.
Logiczne jest, że o popularnym systemie - tak o jego zaletach, jak i słabościach - mówi i pisze się
więcej. Nie trzeba też chyba dodawać, że nawet jeśli jakieś błędy nie zostały wykryte, to wcale nie
znaczy, że ich nie ma. Tezę o bezbłędności Linuksa można zatem włożyć między bajki.
Przyjmujemy więc do wiadomości istnienie luk w linuksowym jądrze i programach. W tym miejscu
zazwyczaj pojawia się argument koronny: "ale przecież Linux ma otwarte źródła!". Racja, plusy
wynikające z otwartego kodu są niezaprzeczalne. Jest on dostępny dosłownie dla każdego - każdy
może do niego zajrzeć, znaleźć błąd i podesłać łatkę, każdy może włączyć się w jego doskonalenie i
rozwijanie. Ludzie z różnych stron świata posiadający różne umiejętności, różne pomysły i tę samą
pasję, mogą stanowić większy potencjał twórczy, niż stała, zamknięta grupa programistów,
zobowiązana do utrzymywania efektów swojej pracy w tajemnicy. Rozwój systemu o otwartych
źródłach jest w tym świetle dużo bardziej dynamiczny, a czas reakcji na wykryte błędy zazwyczaj
bywa krótszy. Jednak otwartość źródeł posiada również pewne ciemne strony. To, co jest ogromną
przewagą, stanowi jednocześnie duże zagrożenie dla bezpieczeństwa otwartego oprogramowania.
Twierdzenie bowiem, że każdemu człowiekowi, który "grzebie" w źródłach systemu w poszukiwaniu
dziur, przyświeca chlubny cel, byłoby co najmniej niepoprawnym optymizmem. Podczas gdy
znalezienie luk w programie o zamkniętym kodzie wiąże się z próbami atakowania programu na
chybił-trafił, bądź też z dekompilacją i analizowaniem kodu na poziomie asemblera, co jest
czasochłonne i wymaga dużych umiejętności, w programach spod znaku Open Source sytuacja jest
dużo łatwiejsza. Często wystarczy tylko wiedzieć, gdzie i czego mniej więcej szukać i mieć jakieś
pojęcie o programowaniu. Tam, gdzie jeden człowiek napisze łatkę na znalezioną lukę, inny może
ową lukę wykorzystać do napisania exploita.
W dyskusji na temat bezpieczeństwa Linuksa często się mówi o dobrze rozwiązanej kwestii
uprawnień. Owszem, podejście Linuksa wypada znacznie korzystniej od podejścia Windowsa sprzed
czasów Visty. Jednak ostatecznie i tak wszystko zależy od administratora systemu, ponieważ może on
w każdej chwili zmienić konto lub uprawnienia, z jakimi pracuje użytkownik. Przyjmijmy, że większość
użytkowników Linuksa przestrzega uniksowej zasady i nie korzysta z konta roota do codziennej pracy.
Czy są oni całkowicie bezpieczni? Uzyskanie uprawnień administratora to punkt kluczowy ataków na
systemy uniksowe, bez tego nie sposób przejąć systemu, ukryć się w nim, czy wyrządzić jakiejkolwiek
większej szkody. Gdyby było to niemożliwe (pomijając element ludzki, w tym socjotechnikę), Linux
rzeczywiście zasługiwałby na miano najbezpieczniejszego systemu na świecie. Istnieją jednak pewne
mechanizmy, mogące ułatwić niepożądanym osobom zdobycie tych uprawnień. Jednym z nich są
atrybuty suid (Set User ID) oraz sgid (Set Group ID). Procesy, które powstają w wyniku wykonania się
programu z ustawionym bitem suid/sgid mają uprawnienia właściciela tego pliku - zazwyczaj roota.
Jest to niezbędne w momencie, gdy zwykły użytkownik musi dokonać akcji, do której nie ma
uprawnień. Dobrym przykładem będzie tu możliwość zmiany własnego hasła (passwd) i preferencji
własnego konta (chfn, chsh), możliwość planowania zadań (at, crontab), czy zdalny dostęp do
komputera (ssh, rlogin). Niebezpieczeństwo polega na tym, iż wykorzystując lukę w takim programie,
atakujący może uruchomić na maszynie ofiary kod z prawami administratora.
Mamy więc błędy w jądrze i luki w programach, które można łatwo odnaleźć dzięki otwartym
źródłom, mamy też możliwość wykorzystania tych luk do przejęcia władzy nad systemem. Co z tego powie ktoś - skoro przecież istniejące szkodliwe programy dla Linuksa można wyliczyć na palcach
jednej ręki? Jakie jest prawdopodobieństwo, że akurat nam się coś przytrafi? Otóż nie jest ono wcale
tak małe, jak by się mogło wydawać. Po pierwsze, jeśli coś nie jest znane, nie znaczy, że nie istnieje.
Najstarsze wersje rootkitów i exploitów zazwyczaj powstają w podziemiu na długo przed tym, zanim
zostaną złapane "na gorącym uczynku"; część z nich zaś może nigdy nie zostać wykryta. Po drugie - i
najważniejsze - trzeba zdawać sobie sprawę z różnic pomiędzy charakterem szkodliwych programów
dla systemu Windows i ich uniksowych odpowiedników.
Podczas gdy te pierwsze mają zazwyczaj na celu zainfekować jak największą liczbę przypadkowych
komputerów, te drugie najczęściej są przeznaczone dla jednej, konkretnej maszyny. Dlaczego akurat
nasza maszyna miałaby się stać celem takiego ataku? Powodów jest wiele, jednym z nich może być
sam fakt posiadania Linuksa! Brak zwyczaju korzystania z jakiegokolwiek oprogramowania
antywirusowego i zbytnie poczucie bezpieczeństwa większości użytkowników "pingwina" sprawia, że
raz zainstalowany rootkit może egzystować w systemie znacznie dłużej, niż na przeciętnym
komputerze z Windowsem, gdzie program antywirusowy to wymuszona codzienność. W ten sposób
nasz Linux może stanowić świetną platformę do przeprowadzania ataków na inne maszyny, za które
w razie wykrycia odpowiadać będziemy my. Oczywiście nie znaczy to, że w Linuksie równie łatwo jest
paść ofiarą rootkita, co w systemie Windows - jednak na wszelki wypadek lepiej jest liczyć się z taką
możliwością.
Najczęstszym obiektem ataków są jednak różnego rodzaju serwery działające pod kontrolą Linuksa.
Takie serwery powinny być szczególnie chronione, ponieważ mogą stać się źródłem zagrożenia dla
wszystkich komputerów w sieci, które korzystają z oferowanych przez nie usług. Bardzo popularną
ostatnio techniką jest wykorzystywanie błędów w serwerach WWW i infekowanie przechowywanych
na nich plików php i html szkodliwymi skryptami javy, które z kolei poprzez luki w przeglądarkach
dokonują instalacji szkodliwego oprogramowania na komputerze oglądającego stronę użytkownika. O
najnowszych tego typu zagrożeniach pisał niedawno Siergiej Golowanow w Dzienniku Analityków
Kaspersky Lab.
Inną kwestię stanowią linuksowe serwery pocztowe i serwery plików świadczące usługi dla klientów z
systemem Windows. Mimo, że szkodniki dla Windowsa nie są w stanie wyrządzić krzywdy takiemu
serwerowi, mogą się poprzez niego bez przeszkód rozprzestrzeniać. Skaner antywirusowy z
aktualnymi bazami sygnatur wydaje się być w takich przypadkach niezbędny. W sporach
zwolenników Windowsa z sympatykami Linuksa z obu stron padło wiele niesłusznych oskarżeń, lecz
padło też wiele trafnych argumentów. Racja jak zwykle leży mniej więcej po środku. Skrajne poglądy
zawsze dają zniekształconą, subiektywną wizję rzeczywistości, więc nawet jeśli Linux stał się dla kogoś
pasją i życiem, nie można podchodzić do niego bezkrytycznie i idealizować go, zamykając oczy na
oczywiste niedoskonałości i usterki. Prawda jest taka, że każdy system operacyjny posiada luki i
błędy, a im jest on bardziej rozbudowany i skomplikowany, tym więcej się owych niedociągnięć i
pomyłek programistycznych można spodziewać.
Jedną z największych słabości Linuksa jest przekonanie jego użytkowników o tym, że nie ma on wad.
Pamiętajmy - jeśli ktoś się czuje się całkowicie bezpiecznie, nie zachowuje należytej ostrożności, a
wtedy jest najbardziej podatny na atak.
Bezpieczniejszy, bo rzadziej atakowany - czyli dlaczego wirusów dla Linuksa jest tak mało?
Jednym z powodów, dla którego nie pisze się w większych ilościach szkodliwego oprogramowania dla
systemu Linux, jest jego stosunkowo niewielka popularność. Im system operacyjny jest bardziej
popularny, tym chętniej jest obierany jako cel ataków. Do niedawna Linux w badaniach popularności
systemów operacyjnych zajmował bardzo niskie lokaty, co zwolennicy systemu Windows obracali w
żart twierdząc, że jest to granica błędu statystycznego i ostateczny dowód na to, że Linuksa nie używa
nikt. Począwszy jednak od roku 2008, Linux zaczął zyskiwać coraz większe grono zwolenników,
przekraczając tym samym w kwietniu 2009 roku magiczny 1% używanych w sieci systemów
operacyjnych.
Rys. 2. Popularność systemów operacyjnych, kwiecień 2009 r. (fot. Kaspersky Lab)
Można zatem powiedzieć, że system Windows nie jest już jedynym środowiskiem wybieranym przez
użytkowników. Do głosu doszły Mac OS i Linux. Jeżeli tendencja zwyżkowa będzie trwała nadal, to nie
należy łudzić się z tym, że system Linux zostanie pominięty przez osoby piszące szkodliwe
oprogramowanie. Im więcej zainfekowanych komputerów tym większe zarobki chociażby z przyłączania
kolejnych maszyn do botnetu lub wykradania haseł i loginów. Przykładem może służyć sam system
operacyjny Mac OS, który w czasach mniejszej popularności, wynoszącej 3 - 4% praktycznie nie był
atakowany. Obecnie, kiedy jego odsetek jego użytkowników sięga prawie 10%, spotyka się coraz więcej
zagrożeń. Przykładem jest chociażby trojan OSX.Iservice, który daje atakującemu zdalny dostęp do
komputera ofiary oraz wysyła prywatne dane do twórcy. Dodatkowo trojan ten może zostać uruchomiony
na komputerach x86 oraz PPC. Poniższy obrazek prezentuje jak na przestrzeni kilkudziesięciu miesięcy
wzrosła popularność systemu Linux.
Biorąc pod uwagę powyższą zależność popularności systemu do częstotliwości atakowania go, można
faktycznie założyć, że w miarę zwiększania popularności systemu Linux i przechodzenia nań większej ilości
użytkowników, będziemy spotykali się z coraz to nowszymi atakami. Niestety nawet przy popularności na
poziomie 1% system ten nie jest zupełnie bezpieczny i zdarzają się przypadki atakowania go, a nawet
przyłączania linuksowych maszyn do botnetów.
Kolejnym powodem, który ma znaczący wpływ na poziom bezpieczeństwa Linuksa to sami użytkownicy.
Posiadają oni zazwyczaj większą wiedzę na temat budowy systemu operacyjnego oraz aspektów jego
bezpieczeństwa. Dawniej, kiedy Linux był systemem głównie serwerowym, nie był on przyjazny dla
przeciętnego użytkownika jako alternatywny system. W ostatnich kilku latach bardzo dużo się zmieniło.
Linux ma sporo graficznych udogodnień, przez co jest prostszy w obsłudze. Należy jednak pamiętać, że i
teraz użytkownik ma duże pole manewru jeżeli chodzi o dostosowanie systemu do swoich potrzeb. To z
kolei wymaga poświęcenia choć odrobiny uwagi budowie systemu i sprzyja pogłębianiu wiedzy na jego
temat. Może się wydawać, że to drobne i niemające wpływu na bezpieczeństwo fakty, ale należy
pamiętać, że im więcej potrzeba umownego "grzebania i dłubania" w systemie, tym trudniej przekonać
użytkownika do wykonania operacji mających wpływ na newralgiczne elementy systemu.
Jednym z najczęściej przywoływanych argumentów opowiadającym się za większym bezpieczeństwem
Linuksa jest lepsze niż w Windows nadawanie uprawnień. Jest to główny powód, dla którego pisze się
mało wirusów na system Linux. Jeżeli szkodliwa aplikacja chce wyrządzić szkodę w systemie, to musi
posiadać odpowiednie uprawnienia (root), które pozwolą na dokonanie zmian i modyfikacji. Standardowo
użytkownik po instalacji loguje się na konto z ograniczonymi prawami, przez co kod wirusa nie może
zostać wykonany. W momencie kiedy chcemy zainstalować np. nowy program, należy nadać odpowiednie
prawa oraz posiadać hasło roota. Dzięki temu prostemu zabiegowi niezwykle trudno jest zaatakować
system Linux wirusem, jednak nie jest to niemożliwe. Wystarczy zachęcić użytkownika do instalacji
programu używając socjotechniki, czyli przekonując go że aplikacja jest czymś innym niż w rzeczywistości
(chociażby grą).
Zagrożenia dla Linuksa
Wirusy
Najpopularniejsze ataki na system Windows czyli wirusy i trojany, niekoniecznie muszą się sprawdzać w
odniesieniu do Linuksa. Jak pokażemy w następnej części artykułu, istnieją inne, poważniejsze zagrożenia
dla systemu spod znaku pingwina. Historia wirusów na ten system jest krótka, ich ilość jest mała, a
skuteczność w negatywnym tego słowa znaczeniu - znikoma. Pierwszym przypadkiem wirusa na Linuksa
był Bliss z 1997 roku. Jego działanie polegało na dodaniu kodu do nagłówka pliku wykonywalnego. Nie
uszkadzał on jednak go tak jak większość wirusów czyni, miał natomiast na celu udowodnienie, że
napisanie wirusa pod system Linux jest możliwe. Pozwalał on nawet na wyleczenie zainfekowanych przez
siebie plików za pomocą parametru --bliss-uninfect-files-please.
W późniejszym okresie pojawiały się także inne wirusy, jednak przeszły one bez większego echa, a
wszystko za sprawą braku odpowiednich uprawnień, dzięki czemu nie mogły one spustoszyć systemu...
Kolejnym zagrożeniem na drodze ewolucji stały się wirusy wieloplatformowe, będące jednocześnie
niebezpieczeństwem dla systemów Windows i Linux. Za przykład może posłużyć BadBunny. Podszywa się
on pod obrazek programu OpenOffice.org o nazwie BaduBunny.odg. Po jego uruchomieniu, w zależności
od posiadanego systemu wirus atakuje inne pliki. W Linuksie stał się dodatkiem do programu xchat (klient
IRC), zapisany jako badbunny.py. W ten sposób wirus mógł się dalej rozprzestrzeniać. Na zainfekowanych
systemach wyświetlał on także obrazki pornograficzne. Ten i inne wirusy wieloplatformowe (Bi, Pelf,
Etapux) są dowodem na to, że zagrożenie ze strony wirusów istnieje niezależnie od platformy.
Pierwszy Linuksowy botnet
Botnet jest to sieć komputerów, która jest ze sobą połączona i sterowana zdalnie. Wszystko zaczyna się w
momencie infekcji komputera robakiem internetowym, którego zadaniem jest rozprzestrzenianie się po
sieci i zarażanie kolejnych maszyn. Te, które są już zarażone nazywane są komputerami zombie, gdyż
zazwyczaj ofiara nie wie o infekcji i fakcie przyłączenia jej komputera do powiększającej się sieci. Taki
botnet, składający się zazwyczaj z kilku tysięcy komputerów może atakować serwery (ataki DDoS),
powodując czasowe lub całkowite wstrzymanie ich działania. Do wszystkich maszyn zostaje przekazane
żądanie o wysyłanie zapytania na podany adres IP, a serwery nieprzygotowane na jednoczesne przyjęcie
tak wielu pakietów staja się niedostępne. Poniższy schemat powinien to lepiej zobrazować.
Uważa się, że tworzenie botnetów jest domeną systemu Windows. Jest w tym trochę prawdy, bowiem
większość robaków internetowych pisanych jest właśnie z myślą o tym systemie operacyjnym. Wynika to
głównie z jego popularności - łatwiej jest stworzyć botnet z komputerów pracujących pod kontrolą
systemu używanego przez blisko 90% użytkowników komputerów, niż z takich, których używa zaledwie
1%. Widać jednak, że nie do końca tym tokiem myślenia kierowali się twórcy pierwszego botnetu
linuksowego.
Pisząc o Linuksowym botnecie mam na myśli urządzenia, które są pod kontrolą Linuksa, a nie stricte
systemach operacyjnych na komputerach pojedynczych użytkowników. Mowa bowiem o routerach i
modemach. Robak internetowy o nazwie psyb0t atakował m.in. routery działające pod kontrolą systemu
Linux, posiadające słabe lub domyślne hasła do panelu administracyjnego (np. login - admin, hasło admin) lub nie posiadały takowego w ogóle. Liczbę zainfekowanych w ten sposób maszyn szacuje się na
80-100 tysięcy. Liczba z pewnością niebagatelna - z pomocą tak licznego botnetu można przeprowadzić
niejeden udany atak odmowy dostępu.
Atakowane urządzenia posiadały procesory oparte na architekturze MIPS (Microprocessor without
Interlocked Piped Stages). Dla procesorów tych został stworzony system Mipsel Linux, odpowiednio
zmodyfikowana dystrybucja oparta na Debianie. Oczywiście nie jest to jedyna dystrybucja pracująca w
takich urządzeniach. Inne to MontaVista czy OpenWRT (wersja przystosowana przez firmę Linksys). Ważny
jest tutaj jednak fakt, że wszystkie infekowane systemy pochodziły z rodziny Linux. Jak wspominaliśmy
wcześniej, atakowane były routery posiadające słabe zabezpieczenia. Wiele z nich dało się złamać metodą
słownikową (robak posiadał bazę ponad 6 000 nazw użytkowników i 13 000 haseł). Ujawniła się tutaj
pewna słabość większości tego typu urządzeń na rynku. Otóż nie posiadają one limitu nieudanych prób
logowania. Dzięki temu robak mógł próbować kolejnych, nowych haseł i loginów do momentu uzyskania
dostępu do urządzenia. Routery i modemy zagrożone tym atakiem były dostępne nie tylko z poziomu
HTTP (czyli strony z ustawieniami modemu/routera), ale także SSH czy TELNETU.
Ponieważ jest to system linuksowy, można tutaj użyć komendy wget aby pobrać i skompilować pliki
binarne, a następnie je wykonać. Po udanym ataku Psyb0t uniemożliwia innym osobom dostępu do
panelu administracyjnego. Kolejnym krokiem jest łączenie się z IRC (Internet Relay Chat), gdzie urządzenie
przyłączane jest do botnetu i oczekuje na polecenia.
Równie ciekawą kwestią jest dostęp osoby atakującej do zainfekowanych przez siebie maszyn. Jeżeli
komputery są rozproszone po całym świecie, to nigdy nie będzie dostępna większość z nich. Na noc
komputery są wyłączane, w dzień także nie każdy korzysta z Sieci. W przypadku infekcji routera, atakujący
ma do nich dostęp praktycznie zawsze. Routery włączone są przeważnie 24 godziny na dobę, bez względu
na to czy ktoś używa w danej chwili Internetu czy też nie.
Kiedy robak zainfekuje urządzenie w taki właśnie sposób, jest go bardzo ciężko wykryć. Jest to możliwe
podczas analizy ruchu sieciowego, jednak przeciętny użytkownik nie jest w stanie samodzielnie tego
dokonać. Na pocieszenie można dodać, że przy resecie urządzenia robak znika, gdyż jest on zapisany w
pamięci RAM, która przy takiej czynności jest czyszczona. Oczywiście robaki nie infekują jedynie urządzeń
sieciowych, jak wspomniany psyb0t. Dowodem na to są epidemie z przełomu 2002/2003 oraz 2005 roku,
w których główną rolę odegrały robaki infekujące systemy desktopowe i serwerowe (Scalper, Slapper,
Lupper, Mare). Wykorzystywały one głównie luki w oprogramowaniu serwerowym, np. Bind, Apache, a
także błędy protokołów, takich jak OpenSSL.
Aby się tego ustrzec, należy pamiętać o stosowaniu mocnych haseł ze znakami specjalnymi, cyframi oraz
literami różnej wielkości. Jeżeli jest taka możliwość, należy także dokonywać aktualizacji oprogramowania
wewnętrznego (firmware) urządzeń do nowszych wersji.
Exploity
Najbardziej realnym atakiem, który mógłby zostać przeprowadzony na system Linux, jest wykorzystanie
luk w oprogramowaniu i samym systemie. Kiedy zostaje odkryta nowa dziura w aplikacji, bardzo szybko
pojawia się specjalistyczny program nazywany exploitem, którego zadaniem jest wykorzystanie
wspomnianej luki i przejęcie kontroli nad całym systemem (łącznie z nadaniem sobie najwyższych
uprawnień). Czasami usłyszeć też możemy o tak zwanych "zero day exploit", są to exploity napisane przed
wydaniem łaty na aplikację/system. Najczęściej działanie exploita prowadzi do przepełnienia bufora, czyli
wysłaniu do bufora (pamięci) większej ilość informacji niż zostało w rzeczywistości przeznaczone na ten
cel. Skutkiem tego, informacje znajdujące się za buforem zostają "przepełnione". Dzięki temu atakujący
używając exploita może wykorzystać program do nadania takich samych uprawnień, jakie posiada
program.
Linux jest współtworzony przez wielu ludzi, powstają dla niego tysiące różnych programów, a nie
wszystkie są kontrolowane przez całą społeczność Open Source. Błędy programistyczne i luki w takich
aplikacjach mogą zostać użyte przez osoby mające złe intencje wobec nas. Przykładem może być dziura w
funkcji vmslice. Luka dotyczyła większości dystrybucji z jądrem w wersji 2.6.17 - 2.6.24.1 i pozwalała na
nadanie sobie praw roota. Wprawdzie bardzo szybko pojawiła się łatka dla tego błędu, ale nigdy nie
dowiemy się, ilu programistów ma świadomość błędów w kodzie i zachowuje te informacje dla siebie,
tylko po to by mieć możliwość ataku na serwer.
Jak już wspomnianoy, aby skompromitować system Linux należy znaleźć błąd w oprogramowaniu, napisać
exploita i uzyskać prawa roota. Jednak takie akcje zapewniają dostęp jednorazowy, kolejna próba
włamania się do systemu przez tę samą lukę może się nie powieść. Prężnie działająca społeczność
linuksowa dba o to, aby łatki i aktualizacje były publikowane jak najczęściej, natomiast większość
użytkowników jest na tyle przezorna, aby utrzymywać swój system w stanie "up-to-date".
Backdoory to specjalnie spreparowane luki w zabezpieczeniach systemu, dzięki którym atakujący
zapewnia sobie późniejszy dostęp do raz przejętej maszyny. Może uzyskać go przez wprowadzenie swoich
plików do atakowanego systemu, edycję plików konfiguracyjnych niektórych usług (np. inetd.conf), bądź
odpowiednią modyfikację programów systemowych (passwd, login).
Backdoory występują też pod postacią tzw. koni trojańskich, czyli programów udających użyteczne
aplikacje, a działających na niekorzyść użytkownika. Namawiając ofiarę do instalacji trojańskiego
oprogramowania, agresor może uzyskać łatwy dostęp do systemu bez konieczności wykorzystywania
exploita. Oczywiście występuje tu więcej trudności, niż gdybyśmy mieli do czynienia z przeciętnym
użytkownikiem systemu Windows - nie wystarczy kliknięcie podejrzanego odsyłacza, czy potwierdzenie
dziwnie brzmiącego komunikatu. Trzeba przekonać odbiorcę do użycia uprawnień administratora, a co za
tym idzie, upewnić go, że aplikacja, którą instaluje jest nie tylko tą, której poszukuje, ale i godną zaufania.
W historii Linuksa nieobce są przypadki włamań na serwery ftp znanych i zaufanych dostawców
oprogramowania celem podmiany autentycznych aktualnych paczek na wersje stare, dziurawe, bądź
zainfekowane. Za przykład mogą posłużyć takie programy jak sendmail, OpenSSH czy Mozilla Thunderbird,
których trojańskie wersje były przez jakiś czas serwowane na oficjalnych stronach tych projektów. W 2007
roku włamywacze uzyskali też dostęp do repozytorium SquirrelMail, podmieniając pliki do pobrania. Na
komputerach, na których została zainstalowana ta wersja można było wykonać dowolny kod. Zagrożenia
te zostały jednak szybko wykryte dzięki sumom kontrolnym i podpisom cyfrowym, które w przypadku
sfałszowanych paczek nie zgadzały się. W czasach, gdy Linux staje się systemem coraz bardziej przyjaznym
i łatwym w obsłudze - a co za tym idzie, korzysta z niego coraz więcej osób niedoświadczonych cyberprzestępcy mogą skutecznie wykorzystywać fałszywe serwery ftp, oferujące zainfekowane
repozytoria. Oprócz sprawdzania sum kontrolnych wszystkich nowo instalowanych paczek, należy więc też
zwrócić uwagę na to, skąd owe paczki pochodzą.
Dużo niebezpieczniejszy był przeprowadzony w roku 2003 atak na serwer kernel.bkbits.net i modyfikacja
CVS zawierającego źródła jądra Linuksa 2.6.0 (wtedy na etapie testowania). Do pliku kernel/exit.c
dopisane zostały dwie linijki, które miały zapewnić możliwość uzyskania praw roota w systemie
korzystającym z tej wersji jądra. Gdyby nie przezorność i uwaga deweloperów, którzy na czas rozpoznali
nieautoryzowaną modyfikację, jądro Linuksa w wersji stabilnej zainfekowane byłoby ciężkim do wykrycia
backdoorem, który z pozoru mógłby się wydać zwykłą pomyłką programistyczną, nie zaś intencjonalnym
atakiem na bezpieczeństwo Linuksa. Ponadto zwykły użytkownik nie miałby najmniejszej możliwości się
przed tym backdoorem uchronić - do momentu wydania łatki, korygującej ten błąd, jego komputer byłby
otwarty dla intruza. Mimo, że takie rzeczy zdarzają się w świecie Linuksa incydentalnie należy mieć
świadomość, że zagrożenie istnieje i zachowywać ostrożność w każdej sytuacji.
Rootkity to zestawy narzędzi (ang. "kit"), które pomagają w uzyskaniu uprawnień administratora i
ukrywają obecność szkodliwych plików, procesów czy też użytkowników na zaatakowanej maszynie. Ich
historia jest ściśle związana z systemami opartymi o platformę *nix a jej początków można szukać jeszcze
przed nastaniem ery "okien". W roku 1989 został wykryty pierwszy program, mający na celu fałszowanie
informacji przekazywanych przez zaatakowany system. Było to proste narzędzie do czyszczenia logów
systemowych, dzięki któremu ślady obecności intruza w systemie mogły być w powierzchowny sposób
zatarte. W połowie lat 90-tych nastąpił intensywny rozwój tego typu oprogramowania, powstają pierwsze
"prawdziwe" rootkity dla systemów SunOS, Linux i BSD, a ich działanie i poziom skomplikowania różnią się
znacznie od niewielkich, filtrujących logi prototypów. Zazwyczaj nie były to już pojedyncze aplikacje, a całe
zestawy szkodliwych programów, w skład których często wchodziły backdoory, trojany, zmodyfikowane
wersje plików systemowych, a także skrypty, które wykonywały instalację całego tego asortymentu w
systemie. Pod koniec ubiegłego wieku zaczęły się pojawiać również rootkity dla systemów z rodziny
Windows NT, jednak działały one nieco inaczej i nie są przedmiotem tego artykułu.
Ze względu na sposób działania, rootkity można podzielić na dwa podstawowe rodzaje: rootkity działające
w przestrzeni użytkownika (binarne) i rootkity działające w przestrzeni jądra (sterownikowe).
Rootkity binarne
Rootkity binarne są w sposobie działania nieco zbliżone do koni trojańskich i tak też mogą być czasem
nazywane. Zastępują one kluczowe pliki wykonywalne systemu swoimi - odpowiednio zmodyfikowanymi wersjami, dzięki czemu niewzbudzające podejrzeń, zaufane programy, mogą działać na korzyść intruza.
Głównym celem rootkitów binarnych są narzędzia służące do wyświetlania różnych informacji o tym, co
dzieje się w systemie. Ich zmodyfikowane wersje będą pozornie działać bez zarzutu, jednak wyświetlane
przez nie informacje będą sfałszowane lub niepełne.
Najczęściej podmieniane są programy:
- ps, pstree, top - pokazują listę procesów aktywnych w systemie. Ich szkodliwe wersje mają zazwyczaj na
celu ukrywanie w systemie procesów szkodnika.
- ls, find, du - odpowiadają za wyświetlanie i wyszukiwanie plików w systemie. Zmodyfikowane wersje
będą, na przykład, ukrywać pliki szkodnika przed użytkownikiem.
- netstat - wyświetla listę połączeń sieciowych. Wersja trojańska nie wyświetli połączeń generowanych
przez szkodnika.
- ifconfig - pokazuje ustawienia interfejsów sieciowych. Zmodyfikowana wersja może ukrywać przed
użytkownikiem informację, że karta sieciowa działa w trybie nasłuchiwania.
- w, who, users - wyświetlają listę użytkowników zalogowanych w systemie. Modyfikując te programy
atakujący może ukryć swoją obecność przed administratorem.
- sshd, inetd, passwd, login - drobne modyfikacje tych plików mogą zapewnić atakującemu dostęp do
naszego systemu z prawami roota.
Przykładem takiego rootkita binarnego jest t0rn, modyfikujący programy du, find, netstat, ifconfig, login,
ls, ps, sz i top. Dla doświadczonego administratora nie stanowi on jednak trudnego przeciwnika. Autor
rootkita nie uwzględnił wielu kluczowych narzędzi, takich jak na przykład lsof, dzięki którym obecność
szkodnika może być łatwo wykryta. Ponadto trojańskie wersje plików mają inny rozmiar i datę
modyfikacji, niż oryginały.
Nieco inaczej działają rootkity podmieniające biblioteki. Nie modyfikują one dużej liczby programów
systemowych, zamiast tego podmieniają współdzielone biblioteki, z których programy te korzystają.
Głównym celem ataku jest w tym wypadku wirtualny system plików/proc, w którym przechowywane są
wiadomości dotyczące różnych aspektów systemu. Podmiana jednej biblioteki może spowodować, że
pewne informacje o systemie będą sfałszowane, niezależnie od programu, jakim będziemy starali się je
pobrać i wyświetlić.
Stworzenie pełnej listy plików, jakie mogą zostać podmienione jest niemożliwe. Jeśli atakujący zdobędzie
w jakiś sposób uprawnienia administratora, może podmienić dowolny program lub plik swoją wersją, ma
więc pełną kontrolę nad działaniem aplikacji w przejętym systemie. Ma również możliwość modyfikacji
naszych prywatnych danych. Jest to trudne do wykrycia, jednak możliwe - dzięki mechanizmowi
sprawdzania sum kontrolnych plików. Jeśli zostały wprowadzone jakiekolwiek zmiany w pliku, jego suma
kontrolna będzie wyglądać zupełnie inaczej. O ile w przypadku plików systemowych takie zmiany można
dość szybko wykryć za pomocą specjalnych narzędzi, takich jak np. chkrootkit czy rkhunter, o tyle
modyfikacje w plikach i programach, dla których nie dysponujemy sumami kontrolnymi ich poprawnych
wersji, mogą pozostać przez nas niezauważone.
Następca t0rna - w00tkit - próbuje obejść problem programów sprawdzających sumy kontrolne. Od razu
po instalacji oblicza on sumy oryginalnych plików, znajdujących się w systemie i podmienia narzędzie
md5sum, dzięki czemu trojańskie wersje będą wydawały się być poprawnymi. Modyfikuje on między
innymi bibliotekę libproc.so, która przekazuje informacje do programów, takich jak ps, pstree czy top.
Jego obecność można wykryć, odczytując dane o systemie bezpośrednio z katalogu /proc lub używając
programów linkowanych statycznie.
Rootkity sterownikowe
Innym rodzajem rootkitów są rootkity ingerujące w jądro systemu (np. LKM Adore, LRK) Występują one w
postaci dynamicznie ładowanych modułów jądra (LKM - Loadable Kernel Module), za pomocą których
modyfikują one niektóre wywołania systemowe. Mechanizm wywołań systemowych (System Calls)
pozwala na komunikację aplikacji z przestrzeni użytkownika (czyli dowolnego programu, który
uruchamiamy) z jądrem systemu, a dzięki temu ze sprzętem (procesorem, dyskiem twardym itd.).
Modyfikacja takiego wywołania powoduje, że wszystkie dane przekazywane z aplikacji do jądra i z jądra do
aplikacji stają się potencjalnie niewiarygodne. Rozważmy taki przykład: użytkownik próbuje otworzyć plik
za pomocą programu edytora tekstu. Program ten musi wysłać do procesora żądanie otwarcia pliku, a
następnie odczytania z dysku jego zawartości. Dokonuje tego za pomocą wywołań systemowych open() i
read(). Jeśli funkcje tych wywołań zostały zmodyfikowane przez rootkita, możemy dostać informację, że
żądany plik nie istnieje, lub może zostać otwarty plik inny, niż oczekujemy.
Modyfikowanie wywołań systemowych jest bardziej zaawansowane i niebezpieczne, niż podmiana plików
binarnych. W zaatakowanym w ten sposób systemie wszystkie informacje, które przechodzą przez
zmodyfikowane wywołanie systemowe, będą sfałszowane. Nie pomogą tu żadne dodatkowe aplikacje
diagnostyczne, nawet te kompilowane na czystym systemie i linkowane statycznie, ponieważ wszystkie
programy komunikują się z jądrem za pomocą tych samych wywołań systemowych. W większości
przypadków zawodzą również detektory rootkitów. Z tego wniosek, że dobrze napisany rootkit
sterownikowy może być zupełnie niewykrywalny w systemie! Jedynym w pełni skutecznym sposobem na
tego typu rootkity jest wyłączenie w jądrze systemu możliwości dynamicznego ładowania modułów.
Rootkity dla Linuksa cały czas ewoluują a stosowane przez nie metody stają się coraz bardziej
zaawansowane. W marcu 2009 roku na konferencji Black Hat został zaprezentowany zupełnie nowy typ
rootkita, polegający na wstrzyknięciu złośliwego kodu poprzez sterownik urządzenia /dev/mem czyli
pamięci systemowej. Występuje on w postaci biblioteki libmemrk i działa zarówno na 32-bitowych, jak i
64-bitowych wersjach systemu Linux. Również nie tak dawno, bo we wrześniu 2008 roku, firma Immunity
wypuściła innowacyjnego rootkita linuksowego o nazwie Debug Register, który działa w trybie jądra,
udając jego debugger. Nie modyfikuje on tablicy wywołań systemowych, wykorzystuje natomiast rejestry
uruchomieniowe 32-bitowych procesorów Intel, dzięki czemu jest zupełnie niewykrywalny przez programy
typu chkrootkit czy rkhunter.
Podobnie, jak w większości przypadków, źródła tego rootkita zostały udostępnione na licencji GPLv2, w
związku z czym każdy może go pobrać, zmodyfikować, skompilować i używać bez przeszkód. Takie
posunięcie ze strony Immunity, a także nagłośnienie sprawy przez różne portale internetowe sprawiło, że
teraz włamanie do systemu Linux staje się prostsze niż kiedykolwiek - narzędzie jest gotowe i tylko czeka,
aby ktoś je wykorzystał! Oczywiście nadal trzeba najpierw uzyskać odpowiednie przywileje w atakowanym
systemie, ale to kropla w morzu, w porównaniu z tym, co już zostało zrobione. Ponadto można się
spodziewać, że zarówno libmemrk, jak i Debug Register będą rozwijane i ulepszane, nie zawsze w celach
wyłącznie edukacyjnych - mimo, że z założenia są to projekty typu proof-of-concept...
Nauczmy pingwina latać
Oczywiście wszystko to, o czym napisano do tej pory nie przekreśla Linuksa jako bezpiecznego systemu
tylko uświadomia, że tak naprawdę to nie system stanowi o bezpieczeństwie, a użytkownik. Jeżeli ktoś jest
świadomy tego co robi, a także stosuje się do ogólnie przyjętych zasad "surfowania" po Sieci, nie jest
ważne, jaki system wybierze, bo przez swoje postępowanie przestaje być najsłabszym ogniwem w
procesie zabezpieczeń. Łatwiej będzie zaatakować nieświadomą ryzyka osobę, dodatkowo utwierdzoną
przez powszechne opinie o "nietykalności" Linuksa przez jakiekolwiek zagrożenia, niż osobę posiadającą
wiedzę o bezpieczeństwie w Sieci, pracującą na systemie Windows. Podobnie jak w przypadku systemu
Windows, taki i przy Linuksie można podjąć działania minimalizujące ryzyko zostania ofiarą szkodliwego
oprogramowania.
- Regularne aktualizacje. Aktualizacje systemu i oprogramowania mają największy wpływ na
bezpieczeństwo systemu Linux. Każdą dziurę można wykorzystać do nadania sobie wyższych uprawnień.
Służą
do
tego
exploity,
o
których
była
mowa
wcześniej.
- Repozytoria. Instalowanie aplikacji z repozytoriów jest niewątpliwie wygodne, jednak to, co wygodne nie
zawsze musi być bezpieczne. Powinniśmy zawsze pobierać tylko z oficjalnych repozytoriów. Nieoficjalne
repozytoria niosą ze sobą duże ryzyko, gdyż pobierając z nich program i instalując go na dysku robimy to z
pełnymi prawami, jednak nie możemy mieć 100% pewności, że dana aplikacja jest rzeczywiście tą, której
oczekujemy. W przeszłości bywały już takie sytuacje i dotyczyły nawet oficjalnych repozytoriów (o czym
była mowa przy okazji trojanów). Radą na to jest sprawdzanie sum kontrolnych MD5 oraz podpisów
cyfrowych.
- Oprogramowanie antywirusowe. Antywirus powinien być stosowany obowiązkowo, jeżeli system Linux
służy jako serwer (np. poczty). Wówczas pliki, jakie będą przez niego przechodzić będą na bieżąco
skanowane. E-maile, które w załącznikach posiadają złośliwy kod mogłyby być od razu usuwane. Nikt
przecież nie zagwarantuje, że poczta nie trafi do użytkownika, który pracuje na systemie podatnym na
infekcje.
Kilka słów na koniec
Mam nadzieję, że artykuł ten nie spowoduje spadku zaufania do systemów uniksowych, ponieważ nie to
było jego celem. Chciełbym podkreślić, jak istotna jest rola użytkownika i świadomość wykonywanych
przez niego operacji. Co prawda ryzyko padnięcia ofiarą ataku w systemie Linux jest dużo niższe aniżeli na
platformie Windows, jednak nigdy nie można wykluczyć, że to właśnie Twój system zostanie
skompromitowany. Doinformowany użytkownik to bardziej odpowiedzialny administrator, a właśnie
przekazywanie informacji o ryzyku było rolą tej prezentacji.