Download: CoverIntro

TEMAT MIESIĄCA
Wirusy w Linuksie
Jak działają linuksowe wirusy
BEZPIECZNIE?
Twórcy wirusów twierdzą, że jesteśmy obiektem ataku, niektórzy działacze
Open Source mówią jednak, że nie mamy się czym martwić. Jak naprawdę
wygląda kwestia wirusów w Linuksie? TOMASZ KOJM
W
iększość z nas ma świadomość, że
Linux nie jest tak podatny na ataki wirusów jak Windows, ale jeśli
wydaje Ci się, że linuksowe wirusy w ogóle nie
istnieją, powinieneś się nad tym głębiej
zastanowić. Podobnie jak w innych systemach
operacyjnych, tak i w przypadku Linuksa
twórcy wirusów mają wiele możliwości
zainfekowania go. Ostrożność i przestrzeganie
kilku prostych przykazań pozwalają jednak
ograniczyć zakres zniszczeń. W tym artykule
opisujemy kilka przykładów działania linuksowych wirusów i podajemy wskazówki dotyczące zabezpieczania systemu.
Teoretyczny
wirus linuksowy
Większość dystrybucji Linuksa zawiera gzexe, małe narzędzie kompresujące pliki wykonywalne i automatycznie rozpakowujące je
w momencie uruchomienia. Możesz na przykład skopiować plik /bin/date do katalogu
/tmp i uruchomić gzexe /tmp/date, aby spakować wskazany plik wykonywalny. Rozmiary
plików /bin/date i /tmp/date powinny się różnić – drugi z nich powinien być zauważalnie
mniejszy. Teraz spróbuj uruchomić oba pliki. Dostrzegasz jakąś różnicę?
Na początku każdego programu spakowanego za pomocą gzexe znajduje się specjalny
fragment. Jeżeli otworzysz plik /tmp/date
w swoim ulubionym edytorze, zauważysz, że
nagłówek pliku to skrypt powłoki. Poniżej
nagłówka znajdują się dane binarne, zawierające skompresowany program. Kod powłoki odpowiada za rozpakowanie danych do
pliku tymczasowego i wykonanie go. Cały
proces jest niewidoczny dla użytkownika
końcowego, a na szybkich komputerach
opóźnienie uruchamiania skompresowanych
plików jest marginalne.
14
NUMER 24 LUTY 2006
Pomyślmy teraz o zmodyfikowaniu
skryptowego nagłówka pliku, tak aby przed
rozpakowaniem i uruchomieniem oryginalnego pliku wykonywał następujące zadania:
■ wyszukiwał w zmiennej $PATH losowy
plik wykonywalny z prawami zapisu (lub należący do bieżącego użytkownika), nie będący skryptem powłoki;
■ kompresował (np. za pomocą kodu ze
skryptu powłoki gzexe) dany plik wykonywalny, dodając do niego ten sam zmodyfikowany
nagłówek pliku.
Zmodyfikowany w ten sposób
nagłówek pliku odpowiada podanej
w Wikipedii definicji, zgodnie
z którą wirus to „program, który
powiela się bez zgody użytkownika, dołączając się do innych pro-
WWW.LINUX-MAGAZINE.PL
gramów lub dokumentów” [1]. Nazwijmy go
Linux.Gzipper.
Powyższy przykład uzmysławia fakt, że
stworzenie prostego wirusa pod Linuksa
nie stanowi wielkiego wyzwania. Jest
więc oczywiste, że twórcy wirusów mogą używać bardziej
wyrafinowanych
metod.
Format linuksowych plików wykonywalnych,
ELF (Executable and Linking Format) jest
bardzo podobny do formatu PE (Portable
Executable), wykorzystywanego przez Microsoft Windows i ma niemal takie same cechy.
Oznacza to, że twórcy wirusów mogą stosować
wiele zaawansowanych technik infekowania
plików wykonywalnych, które opracowali w
ciągu ostatniej dekady dla plików PE. Oczywiście, istnieje już kilka wirusów skutecznie
zarażających pliki ELF. Co więcej, niektóre
wirusy mogą infekować zarówno pliki PE, jak
ELF. Jednakże nawet najbardziej zaawansowane wirusy linuksowe staną przed tym samym problemem, co nasz prosty Gzipper: nie
tak łatwo uszkodzić coś w Linuksie.
Wrodzona
ochrona antywirusowa
Twórcy wirusów wykorzystują fakt, że
większość użytkowników komercyjnych
Listing 1:
Wszystko zaczyna się od zainfekowanego pliku
testuser@testsystem:~/testfiles$ ls -l
total 727
-rwxr-xr-x 1 testuser testuser 49084 Sep 4 03:32 cp
-rw-r-r- 1 testuser testuser
651 Jul 28 2004 crontab
-rwxr-xr-x 1 testuser testuser 88038 Nov 6 17:51 date.infected
-rw-r-r- 1 testuser testuser
1489 Feb 10 2004 fam.conf
-rw-r-r- 1 testuser testuser
292 Jun 18 02:05 hosts
-rwxr-xr-x 1 testuser testuser 71996 Sep 4 03:32 ls
-rw-r-r- 1 testuser testuser
1426 Nov 6 01:44 passwd
testuser@testsystem:~/testfiles$ clamscan -no-summary
/home/testuser/testfiles/cp: OK
/home/testuser/testfiles/ls: OK
/home/testuser/testfiles/crontab: OK
/home/testuser/testfiles/hosts: OK
/home/testuser/testfiles/fam.conf: OK
/home/testuser/testfiles/date.infected: Linux.Rst.A FOUND
/home/testuser/testfiles/passwd: OK
Listing 2: Rozprzestrzenianie się wirusa
testuser@testsystem:~/testfiles$ ./date.infected
Sun Nov 6 18:02:46 CET 2005
testuser@testsystem:~/testfiles$ ls -l
total 1010
-rwxr-xr-x 1 testuser testuser 97890 Nov 6 18:02 cp
-rw-r-r- 1 testuser testuser
651 Jul 28 2004 crontab
-rwxr-xr-x 1 testuser testuser 88038 Nov 6 17:51 date.infected
-rw-r-r- 1 testuser testuser
1489 Feb 10 2004 fam.conf
-rw-r-r- 1 testuser testuser
292 Jun 18 02:05 hosts
-rwxr-xr-x 1 testuser testuser 120802 Nov 6 18:02 ls
-rw-r-r- 1 testuser testuser
1426 Nov 6 01:44 passwd
testuser@testsystem:~/testfiles$ clamscan -no-summary
/home/testuser/testfiles/cp: Linux.Rst.A FOUND
/home/testuser/testfiles/ls: Linux.Rst.A FOUND
/home/testuser/testfiles/crontab: OK
/home/testuser/testfiles/hosts: OK
/home/testuser/testfiles/fam.conf: OK
/home/testuser/testfiles/date.infected: Linux.Rst.A FOUND
/home/testuser/testfiles/passwd: OK
WWW.LINUX-MAGAZINE.PL
Wirusy w Linuksie
TEMAT MIESIĄCA
Listing 3: Otwarcie tylnego wejścia
testuser@testsystem:~/testfiles$ ps aux
USER
PID %CPU %MEM
VSZ
RSS TTY
STAT START
[...]
testuser 28000 0.0 0.1
2116
876 ?
S
18:02
[...]
testuser@testsystem:~/testfiles$ netstat -upan
[...]
udp
0
0 0.0.0.0:5503
0.0.0.0:*
systemów operacyjnych jest przyzwyczajona do pracy na wysokim poziomie uprawnień, umożliwiającym bezpośrednie manipulowanie krytycznymi zasobami systemowymi.
W Linuksie, i ogólnie w Uniksie, fundamentalną zasadą jest używanie konta roota
tylko do czynności administracyjnych, nigdy do zwykłej pracy. Jeżeli tylko zasada ta
TIME COMMAND
0:00 ./date.infected
jest przestrzegana, większość wirusów nie
może wyrządzić żadnych globalnych szkód,
ponieważ mechanizm praw dostępu do plików chroni system i pliki poszczególnych
użytkowników. Oczywiście, wirus może
próbować wykorzystać luki w bezpieczeństwie systemu, aby uzyskać większe
przywileje; systemy bez zainstalowanych
poprawek są jednak podatne na wszelkie
Listing 4: Kompilacja Hello, World
testuser@testsystem:~/hello$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello world!\n");
return 0;
}
testuser@testsystem:~/hello$ gcc hello.c -o hello1
testuser@testsystem:~/hello$ ./hello1
Hello world!
testuser@testsystem:~/hello$ ls -l
total 12
-rw-r-r- 1 testuser testuser 100 Nov 6 18:46 hello.c
-rwxr-xr-x 1 testuser testuser 7340 Nov 6 18:50 hello1
Listing 5: Svat jako root
root@testsystem:~/Svat# clamscan -no-summary
/home/root/Svat/svat: Linux.Svat.C FOUND
root@testsystem:~/Svat# ls -l /usr/local/include
total 0
root@testsystem:~/Svat# ./svat
Example file infected with Svat.
root@testsystem:~/Svat# ls -l /usr/local/include
total 16
-rw-r-r- 1 root root
14614 Nov 6 19:10 stdio.h
16
NUMER 24 LUTY 2006
WWW.LINUX-MAGAZINE.PL
28000/date.infected
inne rodzaje ataków, nie tylko na infekcje
wirusowe.
Nasz teoretyczny Gzipper szuka
w zmiennej $PATH posiadających prawa
zapisu plików wykonywalnych, które mógłby zainfekować. Jeżeli zostanie uruchomiony przez osobę nie mającą uprawnień administratora, będzie w stanie zainfekować tylko programy, które do niej należą lub do
których ma ona prawa zapisu – prawie na
pewno nie uda mu się rozprzestrzenić poza
środowisko danego użytkownika. Niestety,
niektóre „przyjazne dla użytkownika” dystrybucje Linuksa promują zły model – jednego użytkownika o dużych uprawnieniach, co otwiera furtkę atakom wirusowym
i umożliwia wirusom infekowanie kluczowych części systemu operacyjnego. Takie
dystrybucje powinno się raczej określać
mianem „przyjaznych dla wirusów”.
Wiele twarzy Linuksa
Rozprzestrzenianie się wirusów utrudnia
także liczba dystrybucji Linuksa i obsługiwanych przez nie architektur oraz wiele różnic
technicznych między nimi. Rzecz jasna, binarny wirus skompilowany na platformę x86
nie będzie działał na komputerze z procesorem SPARC – i odwrotnie. Nawet „przenośne” wirusy, napisane w językach skryptowych, takich jak Perl, mogą nie uruchomić
się, jeżeli zależą od elementów niedostępnych w systemie ofiary.
Problemy
z rozprzestrzenianiem
Zwykłe wirusy, w odróżnieniu od robaków,
nie mają zdolności samodzielnego rozprzestrzeniania się między systemami komputerowymi. Mogą przenosić się tylko wraz
z plikami, które zostały przez nie
zainfekowane. Obecnie większość użytkowników i administratorów Linuksa instaluje
wyłącznie oprogramowanie zawarte w swoich
TEMAT MIESIĄCA
Wirusy w Linuksie
dystrybucjach lub pochodzące z oficjalnych,
uznawanych za wiarygodne źródeł.
Dodatkowo oficjalne pakiety są zwykle podpisane cyfrowo i można je zweryfikować
przed instalacją.
Niestety, nawet najlepsze mechanizmy nie
stanowią pełnej ochrony przed błędami popełnianymi przez człowieka.
We wrześniu 2005 r. okazało się, że oficjalne koreańskie wersje Mozilla Suite
1.7.6 i Thunderbirda 1.0.2 dla Linuksa zainfekowane są wirusem Linux.RST.B. Był to
poważny incydent, ponieważ przeglądarka
WWW jest najczęściej instalowana globalnie, z konta roota, aby była dostępna dla
wszystkich użytkowników w danym systemie. Uruchomienie zainfekowanego pakietu z uprzywilejowanego konta pozwalało wirusowi na zainfekowanie plików systemowych. Fundacja Mozilla opublikowała ko-
awarię systemu, prawdziwe wirusy nie są tak
łagodne jak Gzipper.
Wirus RST, którym zarażony został pakiet
Mozilla Suite, jest jednym z takich groźnych
wirusów i prawdopodobnie najskuteczniejszym z nich. Pierwsza wersja tego wirusa została wykryta pod koniec 2001 r. Jego nazwa
jest skrótem od „Remote Shell Trojan”
i pochodzi od „ładunku” wirusa, pozwalającego na zdalny dostep do zainfekowanej
maszyny. Po uruchomieniu RST próbuje zainfekować pliki wykonywalne w bieżącym
katalogu, a jeżeli ma wystarczające uprawnienia, zaraża także pliki systemowe w katalogu /bin. Na Listingu 1 prezentujemy katalog, w którym znajdują się pliki niezarażone
i jeden plik zainfekowany przez wirusa. Uruchomienie pliku date.infected z konta użytkownika nieposiadającego uprawnień skutkuje zarażeniem plików wykonywalnych
Listing 6: Kompilacja i infekcja
testuser@testsystem:~/hello$ gcc hello.c -o hello2
testuser@testsystem:~/hello$ ls -l
total 28
-rw-r-r- 1 testuser testuser 100 Nov 6 18:46 hello.c
-rwxr-xr-x 1 testuser testuser 7340 Nov 6 18:50 hello1
-rwxr-xr-x 1 testuser testuser 13558 Nov 6 19:26 hello2
testuser@testsystem:~/hello$ clamscan -no-summary
/home/testuser/hello/hello1: OK
/home/testuser/hello/hello2: Linux.Svat.C FOUND
/home/testuser/hello/hello.c: OK
munikat dotyczący bezpieczeństwa, zalecając użytkownikom z Korei, którzy zainstalowali zainfekowane programy, sprawdzenie
swoich systemów za pomocą skanera antywirusowego [2].
Takie wypadki na razie zdarzają się niezmiernie rzadko, prawdopodobnie jednak
w przyszłości, gdy coraz więcej oprogramowania (zwłaszcza komercyjnego) będzie
można pobrać z wielu niezależnych
serwisów, ich częstotliwość wzrośnie.
Dwa przykłady
Wirusy komputerowe bardzo często zawierają tzw. „ładunek” (payload), który
odpowiedzialny jest za wykonanie pewnego
specjalnego działania podczas rozprzestrzeniania się. W przypadku wirusa Linux.Gzipper było to kompresowanie plików przed ich
zainfekowaniem. Podczas gdy w niektórych
przypadkach nawet takie potencjalnie niewinne ładunki spowodować mogą poważną
18
NUMER 24 LUTY 2006
w bieżącym katalogu (Listing 2). Co więcej,
wirus „odpala” swój ładunek i otwiera „tylne
wejście” – serwer nasłuchujący na porcie
protokołu UDP (Listing 3). Atakujący, znający specjalny protokół komunikacji
z wirusem, może teraz przejąć kontrolę nad
tym tylnym wejściem i uruchomić w zainfekowanym systemie zdalną powłokę.
Nie ma zbyt wielu wirusów dla Linuksa
i większość z nich nie działa równie skutecznie jak RST. Niektóre wykorzystują jednak
bardzo interesujące techniki infekcji. Przykładem takiego wirusa jest Linux.Svat. Zamiast bezpośrednio zarażać, próbuje tak
zmodyfikować system operacyjny, aby to on
tworzył zainfekowane pliki. Na Listingu
4 przedstawiamy proces kompilacji typowego programu „Hello, World”. Idea działania
wirusa Svat bazuje na sposobie pracy kompilatora. Kiedy GCC trafi na makro #include<file.h>, szuka najpierw pliku nagłówkowego file.h w katalogu /usr/local/include,
WWW.LINUX-MAGAZINE.PL
a potem w katalogu /usr/include – w tym właśnie katalogu instalowane są wszystkie ważne pliki nagłówkowe. Jednym z najczęściej
używanych jest plik stdio.h.
Jak pokazano na Listingu 5, kiedy plik zainfekowany wirusem Linux.Svat uruchomiony zostaje z prawami roota, instaluje nowy
plik nagłówkowy w katalogu /usr/local/include. Nowy plik stdio.h zawiera odnośnik do
oryginalnego pliku i dodatkowo przedefiniowuje funkcję systemową close (), która przed
zamknięciem plików wywołuje teraz procedurę wirusa virfunc (). Procedura zawiera błędy: jeżeli nie ma praw zapisu do katalogu
/usr/local/include, spowoduje naruszenie
ochrony pamięci – niechlujnie napisany kod
ogranicza szanse powielania się wirusa.
Jak pokazano na Listingu 6, procedura zarażania będzie teraz dołączana do każdego
nowo kompilowanego pliku, używającego
hello.c. Ponieważ nasz przykładowy plik hello.c nie wywołuje funkcji close (), kod wirusa
w hello2 nie zostanie nigdy uruchomiony.
„Bezpieczny Hex”
– przykazania dla Linuksa
Zasady ochrony przed wirusami w Linuksie
są podobne do reguł obowiązujących w innych systemach operacyjnych. Wszyscy użytkownicy i administratorzy powinni przestrzegać następujących przykazań:
1. Nigdy nie używaj konta roota do zwykłej
pracy.
2. Unikaj uruchamiania programów nieznanego pochodzenia. Sprawdzaj je najpierw za pomocą skanerów rootkitów i antywirusowych.
3. Uważnie sprawdzaj każdy plik przed
uruchomieniem go z konta roota.
4. Uaktualniaj swój system operacyjny.
Regularnie instaluj oficjalne aktualizacje dotyczące bezpieczeństwa.
5. Chroń swoje środowisko, używając trudnych do odgadnięcia haseł i innych zabezpieczeń.
6. Śledź zmiany w systemie za pomocą narzędzi sprawdzających integralność systemu
plików. ■
INFO
[1] Wirus komputerowy - Wikipedia, wolna
encyklopedia http://pl.wikipedia.org/wiki/Wirus_komputerowy
[2] Mozilla Security Center, komunikaty dotyczące bezpieczeństwa (21 września 2005 r.)
http://www.mozilla.org/security/