Czy Linux jest taki bezpieczny?

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.

Wśród niektórych użytkowników Linuksa panuje przekonanie, że Linux to twierdza nie do zdobycia, że 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"; cześć 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 naszym 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.

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.

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. O tym jednak napisaliśmy w odpowiedniej części artykułu.

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ą).

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 199. 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 _

Zanim przejdziemy do bezpośredniego opisu botnetu, który składał się z maszyn będących pod kontrolą Linuksa, chcielibyśmy pokrótce wyjaśnić czym jest botnet i jaka jest idea jego tworzenia.

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 mamy 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 psyb0. 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 00. 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.

Przykład logowania do modemu poprzez CLI (Command Line Interface):

_ BusyBox on localhost login: root Password: DSL Modem CLI Copyright (c) 2004 Texas Instruments, Inc. cli> shell Starting /bin/sh Type exit to return to the CLI BusyBox v0.61.pre (2007.02.27-08:37+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. # _ 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 Psyb0. 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 2. 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/200. 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.1. - 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.

_ Na koniu, przez tylne drzwi! Trojany i backdoory _

Jak już wspomnieliśmy, 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 200. 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 200. 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 198. 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 _

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 200. 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...

Oczywiście wszystko to, o czym pisaliśmy do tej pory nie przekreśla Linuksa jako bezpiecznego systemu. Próbujemy tylko uświadomić, ż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.

Mamy nadzieję, że artykuł ten nie spowoduje spadku zaufania do systemów uniksowych, ponieważ nie to było jego celem. Chcielibyśmy 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ą tego artykułu.

Autorzy:
Marta Janus, analityk zagrożeń, Kaspersky Lab Polska
Maciej Ziarek, analityk zagrożeń, Kaspersky Lab Polska