Dlaczego pingwiny 偶yj膮 d艂u偶ej, czyli o atakach na Linuksa

  • Marta Janus
    Analityk zagro偶e艅, Kaspersky Lab Polska
  • Maciej Ziarek
    Analityk zagro偶e艅, Kaspersky Lab Polska

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 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 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: http://viruslist.pl/weblog.html?weblogid=545.

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. 1. Popularno艣膰 system贸w operacyjnych, kwiecie艅 2008 r.


Rys. 2. Popularno艣膰 system贸w operacyjnych, kwiecie艅 2009 r.

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.


Rys. 3. Wzrost popularno艣ci Linuksa na przestrzeni lat 2006 - 2009

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

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

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


Rys. 4. Przyk艂adowy botnet

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

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


Rys. 5. Schemat w艂amania do systemu Linux

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

Niewidzialny wr贸g. Rootkity dla systemu Linux

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


Rys. 6. Podzia艂 rootkit贸w dla systemu Linux

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.


Rys. 7. Zasada dzia艂ania rootkita sterownikowego

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

Kilka s艂贸w na koniec

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.

殴r贸d艂o:
Kaspersky Lab