::::::::::. :::::::..   :::.,::::::   :::         ...     .        :   

    `;;;```.;;;;;;;``;;;;  ;;;;;;;''''   ;;;      .;;;;;;;.  ;;,.    ;;;  

     `]]nnn]]'  [[[,/[[['  [[[ [[cccc    [[[     ,[[     [[,[[[[, ,[[[[, 

      $$$""     $$$$$$c    $$$ $$""""    $$'     $$$,     $$$$$$$$$$$"$$$ 

      888o      888b "88bo,888 888oo,__ o88oo,.__"888,_ _,88P888 Y88" 888o

      YMMMb     MMMM   "W" MMM """"YUMMM""""YUMMM  "YMMMMMP" MMM  M'  "MMM



   prielom #22, 28.02.2004, prielom(zavinac)hysteria.sk, http://hysteria.sk/prielom/

obsah

intro

detekce kernelovych rootkitu

zabezpecenie routrov cisco

webhosting s chroot apachom

databazy telefonnych cisiel

preco nas buducnost nepotrebuje

board

intro

Za poslednych 20 rokov sa mnoho snov stalo utopiou a mnoho utopickych predstav dennou realitou.

Urcite uz kazdy pocul meno Aibo. Je to taka mala chodiaca hracka od Sony. Vacsina z vas tiez pocula meno Asimo. To je
taka velka chodiaca hracka od Hondy. Bohuzial bez tlupy podpornych inzinierov si ani nevrzne. Niektori z vas uz poculi
meno Monsieur II-P. To je asi centimetrovy robot s Bluetooth ovladanim a ultrazvukovymi vlnovymi piezomotormi na tri
gombikove baterie od Seiko-Epson. Skratka hracicka na zozratie pre manikov. Su vsak aj firmy, ktore sa s vyvojom
robotov nemazlia. Ano, robia to ako sucast vojenskeho vyskumu. Skuste si najst DARPA a ich sucasne projekty. Vyzdvihnem
len dva. SARGE - je to 4-kolesove vozidlo, maly autonomny terenny automobil. Prilozeny film obsahuje ukazku jazdy cez
mlaku po zablatenej ceste. Zvlastnostou je, ze kamera umiestnena na mieste vodica sa otaca smerom ku pravemu kraju
vozovky - zvyk, ktory mavaju profesionalni vodici. Nejaka ta striekajuca voda ho nerozhadze, hladi si prisne len svojej
cesty. SARGE je nadhernou ukazkou spravne aplikovanej robotiky. Zial, ma male uplatnenie. Trochu ine vozidielko,
FIREANT ma aj doraznu prakticku aplikaciu. Podoba sa na vacsi RC model, ale zdanie klame. Smrtelne klame. Okrem
schopnosti orientacie a dostavenia sa na urcene suradnice nesie aj tanier. Podla knihy "Zahady na zajtrajsok", povodne
napisanej v roku 1979, tvori zaklad samoformovatelnej bojovej hlavice (EFP) kovova doska v podobe taniera, ktoru vybuch
naloze na jej dne sformuje do podoby strely. V rychlosti az 3000 m/s bez skrupul prerazi do tanku. Dnes to mame aj s
videoukazkou. Fireant stoji za krickom a caka na prichod dialkovo riadeneho tanku. Z jeho vysielaneho videa vidiet
akesi stavove hlasenia o detekcii a ozbrojovani ("ARMED"). Nechapajuceho pozorovatela prekvapi velky vybuch v mieste
cihajuceho Fireanta. Nema pud sebazachovy. Druhe video, vysokorychlostne snimkovanie prierazu panciera je neuveritelne.
"Vlet" do utrob tanku netrva ani milisekundu. Vyskumnikov CalTech-u to asi neochromi, ich moderne technologie takymi
deviatimi machmi pohrdaju. Ich elektromagneticky urychlena strela dosiahne 20 machov. To je dost na snajpovanie tankov
kalibrom 7.62mm na kilometre. Alebo je to len utopia ?

Z analyz robotov vyplyva, ze ich najvacsou slabinou su ich konstrukteri. Napriklad sondy na Marse. Vsetky zacali
stracat signal len co sa vobec dostali na povrch. Hovorime: "Je to chyba Marsu, na nasej strane je vsetko v poriadku!"
Som proti. Vyskumnici navrhli SPIRIT tak, ze casom mu solarne clanky zapadnu prachom a nebudu dodavat energiu.
Nevymysleli mu prachovku. Nechceli ju tam (preco?). Pouzijem zvelicenie nasledujucim pribehom: Predstavte si seba na
palube kozmickej lode dakde na tazobnej misii vo vesmire. Prave sme objavili 2000-kilometrovy feritovy asteroid. Aby
sme urobili dokladny rozbor, vysleme sondu. Sonda po pristati v prasnatom povrchu straca s nasou lodou spojenie. Preco?
Po jej vyzdvihnuti sme zistili, ze jej nic nie je az na to, ze mala vysielaciu antenu pokrytu - ano, bol tam ten
drahocenny feritovy prach. Material s vysokou permeabilitou, ktory pozmenil vysielacie vlastnosti anteny zmenou
indukcnosti plosnych cievok. Ake jednoduche! Po ocisteni anteny sme sondu opartne posadili na asteroid. Fungovala
vyborne, ale po par hodinach znova stratila spojenie. Vysvitlo, ze i ta slaba atmosfera bola dostatocna na to, aby
vznikli akesi piesocne burky, ktore po zapade slnka znovu zaniesli antenu. Kazdopadne, merania boli uskutocnene a mohli
sme sa vzdialit od cenneho nalezu. Kazdopadne, musim im referovat o tazkostiach s vysielanim.

Upozornenie: informacie tu pouzite su uz urcite znacne zastarane, ale neobvykle. Kde je vsetko utajene je kazdy naznak
informacie prevratnou novinkou.

Errata: Americania uvadzaju ako zdroj problemov sondy prilis caste resetovanie. To nemohli postavit jednu z lacnejsich
materialov a bez maximalnej opatrnosti len na testy? Mali na to pustit bandu decak zakladnej skoly a to by mali vidiet
tie poruchy softwaru! A co takto zasypat sondu suchym ladom a este poliat flasou liehu? Teploty by dosiahli aj -100
stupnov Celzia. Potom by uz len stacilo obcasne zabuchat kladivom a sledovat co z toho vylezie. Taktiez: co je to za
architekturu co sa "nedokaze uplne vypnut a preto spotrebovava vela energie pocas spanku"? Inteligentna bateria predsa
posle svoj vlastny RAPORT medzi vysielacie data a v centre BUDU vediet, ze nieco nesedi. A co je to za zdroj, ktory si
vevyhandluje autoritu pocas hlbokej noci. Stacilo by: "Please shut down, there is no sun and -70 deg. C outside." O
minutu neskor staci pripomenut: "You have blown your reserves, now shut down!" O dalsiu minutu: "I warn you last time!"
No a o dalsiu minutu - nakolko nedostane ziadny OPODSTATNENY dovod na predlzenie dodavky mu vypne napajanie. Rano o
7:00 po vychode slnka ho zase pripoji, aby sa mohol nacas hlasit stredisku na Zemi.

Uplny zaver: Budem uprimny, zvladli to ako najlepsie vedeli. V projekte je zapojenych len malo osobnosti a 'deadline
was just too short'. Mars day was coming. Uvidime nabuduce v roku 2009, ako skonci vozitko Mars science laboratory.

Oniko, oniko (zavinac) hysteria (bodka) sk

navrat na obsah

co ty na to ? board

detekce kernelovych rootkitu

Doba patchnutych systemovych utilit je uz davno pryc.. Dneska leti kernelove
rootkity a urcite neni na skodu o nich neco vedet. V tomhle clanku se
pokusim vysvetlit ruzne metody vedouci k odhaleni takovychto rootkitu. V
clanku uvazuju OS Linux, jadra rady 2.4.x a architekturu i386.

prehled

Drive to byly vyhradne LKM (loadable kernel module) rootkity, ale ty uz pomalu
zacinaji vychazet z mody a jsou nahrazovany schopnejsimy. Tyto rootkity
patchuji primo systemova volani, takze at prohlizime soubory pomoci ls, mc nebo cimkoli jinym,
porad je vysledek stejny. Protoze pokud chce userspace aplikace zjistit
adresarovou strukturu, musi pouzit prislusne systemove volani.
Starsi typy byly zalozeny na prostem principu: loudnul se modul a zmenil adresy
v sys_call_table na vlastni verze systemovych volani. Mezi tyhle patri treba Adore,
Knark nebo KIS. Dumyslnejsi rootkity pozmeni obsluhu preruseni 0x80 (coz je
v linuxu prave systemove volani) tak, ze pouziva vlastni zmenenou sys_call_table. Tenhle
trik oblafne jednodussi detektory, protoze adresy syscallu v puvodni sys_call_table
souhlasi. Smula je, ze se ta sys_call_table uz nepouziva.. ;) Momentalne nevim
o zadnem LKM rootkitu, ktery presmerovava sys_call_table..

evoluce

Vyvojari jadra vsak u novych kernelu zrusili exportovani sys_call_table. Takze
vsechny tyto rootkity jsou mimo hru. Jinak ale nevim, ceho tim chteli dosahnout,
protoze v praxi to zadnou ochranu nepredstavuje... Staci si adresu sys_call_table
zjistit z kmem (pamet mame z LKM primo dostupnou) a ostatni je uz rutina. Taky
nikdo nerikal, ze syscally sou jedina vec k patchovani. Porad jsou
(a uz z principu by vzdycky mely byt) pristupne funkce pro praci s VFS..
Chvile zklamani pro zle hochy vyzbrojene LKM rootkity muzou prijit, pokud
v jadre neni zkompilovana podpora LKM. V tom pripade prichazeji na radu dnes
nejvyspelejsi rootkity, ktere patchuji systemova volani primo pres /dev/kmem.
Jedinym me znamym zastupcem v dobe psani clanku je cesky SucKIT, ktery jiste
vsichni znate (doufam ze ne ve zlem;). Ten navic nemeni volani primo v
sys_call_table, ale ve vlastni tabulce, kterou vnuti handleru preruseni 0x80..
ale o tom pozdeji.

detekce

Pojdme rovnou k veci. Jak zjistit pritomnost takovych rootkitu? Zacnu temi
jednodussimi zpusoby..

Snad i ty nejjednodussi LKM rootkity se dokazou skryt z vypisu lsmod nebo ksyms.
Nektere hooknou volani query_module, jine treba read tak, ze se pri
cteni z /proc/modules vynechaji.. Pokud ale /proc/modules budete cist znak
po znaku, nepoznaji, ze je jejich nazev v nem obsazeny. Takze napr.
dd if=/proc/modules bs=1 je vypise.

Rafinovanejsi rootkity, ktere presmerovavaji celou sys_call_table, snadno
odhalime jednoduchym testem.. Skuste patchnout nektere systemove volani a
pokud vase zmena nebude mit zadny vliv, znamena to, ze se vase upravene
volani nepouziva. Takze bud jste ho vazne nepouzili nebo sys_call_table,
ve ktere ste provadeli zmenu neni pouzivana, tzn. "neco" ji nejspis
presmerovalo.. Tohle samozrejme vyzaduje podporu LKM, coz muze byt obcas
zasadni problem..

Dalsi primitivni metody me uz nenapadaji, takze se nenapadne presuneme k
tem sofistikovanejsim. Tim mam na mysli metody vyuzivajici /dev/kmem. Pouzitim
LKM bysme si sice usetrili praci, jenze pro pouziti LKM musime mit samozrejme
podporu v jadre. Proto popisuju obecnejsi zpusob, ktery funguje z userspace
s i bez podpory modulu.


Vetsina dnesnich (mozna vsechny) kernelovych rootkitu meni systemova volani, takze
je dobry napad je zkontrolovat, jestli adresy syscallu souhlasi se adresami v
System.map nebo s adresami ulozenymi drive v dobe, kdy byl system zarucene cisty.
System.map si pokud mozno drive zalohujte, protoze neni problem ji zmenit, a
kontrolu provadejte se zalohou. Tahle metoda obevi "hloupejsi" rootkity typu
Knark, KIS nebo Adore. Pokud si adresu sys_call_table zjistime z handleru
int 0x80 (viz. o kus dal), pak adresy syscallu kontrolujeme v prave pouzivane
sys_call_table nezavisle na tom, zda je presmerovana nebo ne a tim se nam
podari odhalit i rootkity o neco mazanejsi (SucKIT napr.).

Docela dobra moznost je popisovana v Phracku (p59-0x0a.txt). Spocita se pocet
vykonavanych instrukci pri zavolani syscallu. Tahle metoda odhali kazdou zmenu,
nemusi byt vsak vzdy uplne jednoznacna. V kazdem volani je spousta podminek,
takze se jednotliva mereni mohou o par instrukci lisit. Pokud se ale ukaze, ze
pribylo treba 2000 instrukci, tak je celkem jasne, ze system byl zmenen..
I tento zpusob detekce muze teoreticky rootkit obejit, protoze se porad
spoleha na systemova volani (treba pri vypisu vysledku)..

praxe

A protoze nechci, aby tohle byl ciste teoreticky clanek (a tak povrchni, jaky byl doted),
podivame se na zpusob implementace nekterych detekcnich metod. Navic sem se o
nekterych dosud nezminil, takze je proberu tady.

Samozrejme pro praxi je treba znat aspon minimum teorie: sys_call_table[] je pole
256 pointeru na handlery systemovych volani. Pointer ma velikost 4B, takze od adresy sys_call_table
jsou po 4 bajtech umisteny adresy systemovych volani. Adresu sys_call_table
zjistime ze System.map, z /proc/ksyms nebo uplne nejlepe z handleru preruseni 0x80.
Kdyz vime, kde je v pameti ulozena sys_call_table, pak tedy neni problem zjistit adresy jednotlivych volani.
Pak uz staci porovnat tyto adresy s tema v System.map nebo s drive ulozenou zalohou..

No jo, ale kdyz nekdo zmeni adresu sys_call_table v int 0x80? Zpusob odhaleni
tehle zakernosti bude malinko odlisny nez v predchozim pripade. Adresu sys_call_table
totiz nebudeme zjistovat z /proc/ksyms ani ze System.map, ale primo z obsluhy
preruseni 0x80.

Instrukci SIDT zjistime obsah IDT registru, ktery obsahuje adresu zacatku IDT
a delku tabulky.

IDT (interrupt descriptor table) je (zjednodusene) tabulka
obsahujici 256 8mi bajtovych deskriptoru, kazdy z nich obsahuje mimo jine adresu
handleru daneho preruseni nebo uroven opravneni. Pro nase ucely staci
vedet, ze deskriptory jsou od zacatku IDT po 8mi bajtech a obsahuji adresu
handleru, pricemz prvni 2 bajty deskriptoru predstavuji dolni cast adresy a
posledni 2 bajty cast horni.

Takze nacteme z /dev/kmem deskriptor preruseni 0x80 (z adresy idtr.base + 8 * 0x80)
a zjistime adresu handleru daneho preruseni slozenim horni a dolni casti offsetu a v nem
najdeme adresu sys_call_table. Postup i zdrojove kody zjisteni adresy sys_call_table
jsou popsany uz v prielomu 17, clanek o patchovani linuxoveho /dev/kmem, takze nebudu
zbytecne opakovat a odkazu vas tam.. ;) No a kdyz zjistena adresa nesedi s adresou s /proc/ksyms, System.map nebo
se zalohovanou adresou, pak evidentne neni neco v poradku..

Kdyz tohoto zpusobu ziskani adresy sys_call_table vyuzijeme pri ziskavani adres
systemovych volani (namisto /proc/ksyms nebo System.map) mame zaruceno,
ze ziskame adresy prave pouzivanych systemovych volani.

Dale jsem zminoval jako jednu z moznosti patchnuti nejakeho syscallu a kontroly,
zda se nase zmena projevila.. Implementaci zde popisovat snad ani nebudu, postaci
jednoduchy LKM, ktery zmeni treba kill tak, ze pri zadani urcitych vstupnich
hodnot nam vrati urcite cislo, ktere po zavolani kill kontrolujeme.. Zakladni
principy a implementace patchovani syscallu pomoci LKM najdete treba
tady ;)

Pokud neco porovnavame s adresama v System.map, rozhodne se nespolehame na soubor, ktery
lezi celou dobu na disku! Muze ho kdokoli zmenit nebo smazat. Po nainstalovani
systemu nebo pred prvnim zapojenim do site nebo kompilaci jadra si udelame zalohu
System.map a tu schovame na bezpecne misto (na CD, schovane v zamcene bedne pod
posteli;).

paranoia

Zakernost rootkitu vsak muze jit jeste dal.. Pozmeni sys_read tak, ze
pri cteni z /dev/kmem zkontroluje pozici v souboru a velikost cteneho bufferu
a pokud zjisti, ze zrovna nekdo nahodou cte aktualni adresu sys_call_table,
tak mu predhodi puvodni spravnou adresu, kterou si pred zmenou ulozil. Odhaleni
tohoto ukryti bude velmi obtizne.. snad jen zmateni rootkitu tim, ze prectu vetsi kus dat
z nizsi adresy, obsahujici adresu sys_call_table a z techto dat ji potom vyextrahovat..
Ale i to se da obejit.. rootkit muze stejnym spusobem zjistit, zda-li je v danem bloku
dat adresa sys_call_table a tyhle 4 bajty prepsat... Jde jen o to, jak moc si autor
rootkitu pohraje se vsema moznostma, ktere na nej muze autor detektoru zkouset..
Takze pamatujte na to, ze kdyz vas rootkit detektor nic neobevi, jeste to neznamena,
ze ho tam nemate ;) Tyhle veci jsou dneska (vzhledem k _znamym_ rootkitum) zbytecna
paranoia. Ale za rok?

reload

Kvuli ruznym advanced skryvacim technikam je dobre delat i par testu na
priznaky cinnosti rootkitu. Dejme tomu, ze rootkit skryva procesy, ale je tak
dokonale skryty, ze to vypada, ze sys_call_table i jednotliva volani jsou
v poradku (nebo v poradku opravdu jsou a rootkit skryvani zarizuje jinak). Pak
skryte procesy ps sice nevypise, ale porad musi byt v pameti. Opet vyuzijeme
obrazu virtualni pameti, cili /dev/kmem.

Zjistime si adresu symbolu init_task_union, coz je adresa prvniho procesu v pameti (swapper s PID 0)
Zjednodusene bez overovani chyb a bez includu by to bylo nejak takhle:

	struct task_struct task;

	unsigned long addr, first_task;

	int fd;



	fd = open("/dev/kmem", O_RDONLY);

	first_task = get_symbol_addr("init_task_union");



	addr = first_task;

	

	do {

		lseek(fd, addr, SEEK_SET);

		read(fd, &task, sizeof(task));

		if (!is_in_pid_list(task.pid)) 

			printf("PID %d - %s with UID %d is hidden!", 

				task.pid, task.comm, task.uid);



	} while	((addr = (unsigned long) task.next_task) != first_task);

	

	close(fd);

Procesy sou ulozeny v kruhovem spojovem seznamu, takze nam staci adresa
jednoho procesu a z nej uz se postupne dostaneme na pozadovany proces. V tomto
pripade, jak je zrejme uz ze zdrojaku a predchozich vysvetlovani, projizdime
cely seznam a kontrolujeme, zda je PID procesu obsazen ve vypisu ps.

Funkce get_symbol_addr() vraci adresu symbolu, kterou zjisti ze System.map a funkce is_in_pid_list()
kontroluje, zda je dany pid obsazen ve vypisu ps. Tyhle funkce neexistuji, musite si je napsat, nebo
hrabnout po zdrojacich mojeho detektoru.

Tenhle zpusob vsak neni stoprocentni (ostatne jako vsechny dalsi zpusoby;). Pokud
rootkit proces "vypoji" ze seznamu, tak jej timhle samozrejme nenajdeme..

Ale jak pravi zname porekadlo "co nejde silou, jde jeste vetsi silou".. Takze musime
prohledat pamet a najit vsechno, co vypada jako struktura task_struct. Nejdriv
musime zjistit co prohledavat a co vlastne hledat. Podivame se, co se dela pri
spousteni noveho procesu treba pri fork() (kernel/fork.c)

int do_fork(unsigned long clone_flags, unsigned long stack_start,

	    struct pt_regs *regs, unsigned long stack_size)

{

	int retval;

	struct task_struct *p;

	...

	p = alloc_task_struct();

	if (!p)

		goto fork_out;

	...

}

Hmm.. to vypada, ze alloc_task_struct() nam bude alokovat pamet pro strukturu
task_struct ;] Tak si najdem co to dela..

[/usr/include]# grep -r " alloc_task_struct()" * 

asm/processor.h:#define alloc_task_struct() ((struct task_struct *) __get_free_pages(GFP_KERNEL,1))

...

takze vidime (no, kdybysme se zamysleli, tak nas to napade samo), ze na
kazdou strukturu se alokuje stranka pameti (coz je u Intelu 4kB). Takze
muzem kontrolovat vyskyt urcitych udaju jen jednou za 4kB pameti.

Jeste musime vedet co vlastne hledat.. podivejme se jak vypada task_struct (v linux/sched.h):

struct task_struct {

	volatile long state;	/* -1 unrunnable, 0 runnable, >0 stopped */

	unsigned long flags;	/* per process flags, defined below */

	int sigpending;

	mm_segment_t addr_limit;	/* thread address space:

					 	0-0xBFFFFFFF for user-thead

						0-0xFFFFFFFF for kernel-thread */

	struct exec_domain *exec_domain;

	volatile long need_resched;

	unsigned long ptrace;



	int lock_depth;		/* Lock depth */

	....

	a nasleduje dlouhy seznam jednotlivych prvku struktury... 

Prvku obsahuje task_struct docela hodne, takze mame spoustu moznosti.. Jako
prvni prvek struktury (takze prvni 4 bajty stranky) je stav procesu. A ten
jak vidime v komentari nabyva hodnot, ktere jen stezi zaplni cely long. Dalsi
dobra vec k rozpoznani je addr_limit, ktery muze nabyvat pouze 2 hodnot. Bud
0xffffffff nebo 0xc0000000 (je dobre se podivat, co tam je ve skutecnosti,
komentare muzou byt obcas nejasne). Struktura obsahuje i ruzne pointry na dalsi
struktury, ktere budou samozrejme v pameti pro kernel space, takze nad 0xc0000000.
Je tam spousta veci na overovani, chce to pozkouset, kdy to spolehlive najde
vsechny procesy a nic jineho nez procesy.

Takze zdrojak by moh vypadat treba takhle:

#define __KERNEL__

#include <linux/sched.h>

#undef __KERNEL__



#include <stdio.h>



#define PAGE_SHIFT	12

#define PAGE_SIZE	(1UL << PAGE_SHIFT)  /* to je  2^12 == 4096 */

#define NEXT		{addr += PAGE_SIZE; continue;}

#define KLIMIT		0xc0000000



int rkm(int fd, void *data, unsigned long offset, int size)

{

	if (lseek(fd, offset, SEEK_SET) != offset) return -1;

	if (read(fd, data, size) != size) return -1;

	return size;

}



int main() 

{

	struct task_struct;

	int fd;

	unsigned addr = 0xc0400000;

	int tmp;

	unsigned int tmpu;

	char name[17];

	

	fd = open("/dev/kmem", O_RDONLY);



	while (addr < 0xe0000000) {

		/* precte a overi stav potencialniho procesu */

		rkm(fd, &tmp, addr, sizeof(tmp));

		if (tmp > 100) NEXT;



		/* precte a overi addr_limit */

		rkm(fd, &tmpu, addr + 8 + sizeof(int), sizeof(tmpu));

		if (tmpu != 0xffffffff && tmpu != KLIMIT) NEXT;

		

		/* nacte celou strukturu task_struct */

		if (rkm(fd, &task, addr, sizeof(task)) != sizeof(task)) {

			perror(NULL);

			break;

		}

		/* overi pid */

		if (task.pid < 0) NEXT;

		

		/* overi ruzne adresy.. muzou byt bud NULL nebo ukazovat nekam do kernelspace */

		if ((unsigned)task.next_task < KLIMIT || 

		    ((unsigned)task.p_opptr < KLIMIT && task.p_opptr) ||

		    ((unsigned)task.p_pptr < KLIMIT && task.p_pptr) ||

		    ((unsigned)task.p_cptr < KLIMIT && task.p_cptr) ||

		    ((unsigned)task.p_ysptr < KLIMIT && task.p_ysptr)) NEXT;

		

		snprintf(name, 16, "%s", task.comm);

		printf("%dt%sn", task.pid, name);

		

		addr += PAGE_SIZE;

	}

	close(fd);

}

Muze se stat, ze pres kontroly proklouzne i neco jineho nez proces. V tom pripade
si pridejte jeste par testu, nebo se na vysledky podivejte. Vetsinou jde poznat,
zda jde skutecne o proces nebo ne (napr. jiz pouzity PID, misto jmena nejake nahodne znaky, a pod..)
Nalezene PIDy zkontrolujeme s vypisem ps a ty co v ps nejsou, jsou skryte...

moduly

Taky se hodi prohledat pamet a najit pripojene moduly. Tak se daji obejit
snad vsechny _bezne pouzivane_ metody skryvani LKM. K tomu opet potrebujeme neco, podle
ceho modul pozname.. Mrknem se do linux/module.h na strukturu struct module:

struct module

{

	unsigned long size_of_struct;	/* == sizeof(module) */

	struct module *next;

	const char *name;

	unsigned long size;

	....

Vidime, ze hned v prvni promenne je ulozena velikost struktury, ktera bude
samozrejme u vsech modulu stejna. Stejne jako u procesu i struktura module bude na
vlastni pametove strance, takze opet muzeme prohledavat po strankach, cimz
vyrazne snizime dobu hledani. Takze nam bude stacit overovat kazdy
4096ty long v pameti, jestli nahodou neobsahuje hodnotu sizeof(struct module).
Pokud ano, nacteme celou strukturu a muzeme si udelat jeste par testu, zda jde
skutecne o modul, treba flagy nebo nazev modulu (jestli jsme nacetli misto modulu
nejaky bordel, mame slusnou sanci, ze pri cteni nazvu vrati read chybu Bad address).


Samozrejme i tahle metoda se da vcelku jednoduse obejit.. staci, kdyz si
modul zapise do size_of_module nejake nahodne cislo a mame smulu :( Modul se
da samozrejme hledat i podle jinych veci nez size_of_module, ale stejne se
zase najde zpusob, jak ho zneviditelnit...

Pseudokod:

	#define PAGESIZE 4096

	

	unsigned addr, num;

	char prev_name[64];

	char name[64];

	struct module mod;



	/* adresa od ktere zacneme prohledavat */

	addr = 0xc4000000;

	kmem = open("/dev/kmem", O_RDONLY);

	

	while (addr < 0xf0000000) { 

		rkm(kmem, &num, addr, sizeof(num));

		if (num == sizeof(struct module)) {

			rkm(kmem, &mod, addr, sizeof(mod));



			/* kdyz neprecte to co ma, tak nejspis je blba adresa nazvu modulu, 

			   a to znamena, ze to co sme nacetli s nejvetsi pravdepodobnosti 

			   neni modul */

			if (rkm(kmem, &name, (unsigned)mod.name, 

				sizeof(name)) != sizeof(name)) continue;



			/* pokud by byly zapnute vsechny flagy najednou, tak maji

			   hodnotu 127 */

			if (mod.flags >= 128) continue;

			if (!strcmp(name, prev_name)) break;

			

			if (!in_mod_list(name))

				printf("Module %s is hiddenn", name);

			

			memcpy(prev_name, name, sizeof(prev_name));

			bzero(buf, sizeof(name));

		}

		addr += PAGESIZE;

	}

Metody odhaleni nejspis nejsou nikdy stoprocentni, protoze rootkit muze teoreticky
osetrit kazdou snahu o jeho detekci. Neni dobre se prilis spolehat na systemova
volani..

implementace

Jako ukazka implementace snad vsech popsanych metod (tedy krome pocitani poctu vykonanych instrukci) muze
slouzit muj rootkit detektor, ktery
obsahuje i par user-friendly featur navic jako bonus.. ;) Privitam veskere (pokud mozno konstruktivni)
pripominky, napady nebo navrhy tykajici se tohoto programu..

vize

A bude hur.. musime si uvedomit ze to, co tady popisuju, jsou porad variace na dnesni
metody skryvani. Jak budou ale vypadat zitra? Rootkity se pravdepodobne vykaslou
na systemova volani a prevezmou kontrolu na nizsi urovni. V nejblizsi dobe
bych to videl na hookovani funkci na urovni VFS (viz. napr. Phrack, p58-0x06). Z dnesnich
me znamych rootkitu pouziva hookovani funkci VFS napr. KIS na skryvani sitovych spojeni,
ale krome toho patchuje spoustu syscallu beznym zpusobem, takze je snadno detekovatelny.
Ale je docela mozne, ze se casem zacnou objevovat backdoory nebo rootkity, ktere
jdou jeste hloub. Jak je videt v poslednim Phracku (61), backdoorovat se da vsechno
mozne. V clanku 0x07 autor popisuje zpusob hooknuti page fault handleru (obsluha vypadku
pametove stranky), nebo p59-0x04 je popisovano hookovani handleru preruseni.. proc ne,
naco troskarit ze. Jen cas ukaze jakym smerem se bude ubirat vyvoj.

male srovnani..

.. dostupnych programu pro detekci kernelovych rootkitu (vcetne mojeho detektoru)
by mozna neskodilo, ale uz je to malinko offtopic, takze jim nebudu zbytecne
neprodluzoval tento clanek. Precist si ho muzete zde.

feedback

ircnet: #dump, #blackhole.sk (_2k_ nebo trace)

anonet: #talk, #dump

trace, trace (zavinac) hysteria (tecka) sk

navrat na obsah

co ty na to ? board

Zabezpecenie routrov Cisco

Hned na uvod by som rad povedal, ze tento clanok nebude plny najmodernejsich poznatkov,
mojich vlastnych vedeckych vyskumov a hackeri nebudu moct hned po precitani
clanku zasadnut za svoje 101-klavesove sustruhy a zacat hackovat routre.
Ide skor o systematicke spracovanie temy s vyuzitim zdrojov (pozri uplne dole)
s mojimi komentarmi a skusenostami s pracou s tymito zariadeniami.
Co sa tyka kvalitnych zdrojov, okrem [1], co je skvela priebezne aktualizovana
sablona konfiguracie, bola uz volne siritelna len publikacia [2]. Ale uz zial nie je,
Cisco sa ju rozhodlo spoplatnit. Stale si vsak mozete (a velmi to odporucam)
vygooglovat niekde poslednu free verziu 2.9.

Temou je zabezpecenie routrov Cisco, cize zamedzenie toho, aby utocnik mohol routru
zadavat prikazy, ziskavat z neho lubovolne informacie o jeho prevadzke alebo
jeho prevadzku celkom prerusit (DoS utoky). Nejdeme sa teda zaoberat temou,
ako pomocou Cisco routra zabezpecit vnutornu siet. Napriek tomu si neodpustim jednu
radu - pokial nie ste ISP (aj ISP vsak musia chranit vlastnu LAN a svoje servre)
- pouzite firewall. V topologii

internet - router - firewall - lokalna siet

router sprostredkuva lokalnej sieti pristup na internet, na druhej strane chrani seba
a firewall. Firewall chrani potom (okrem seba, to je samozrejmost) lokalnu siet.
V pripade pouzitia routra Cisco je mozne dohranim Firewall feature setu do routra
spojit router a firewall v jednom zariadeni, ale toto riesenie ma aj svoje slabiny.
Ak vas zaujima, akoze to Cisco chrani samo seba, citajte dalej.

1) Zabezpecenie pristupu do routra

Najvacsim snom utocnika na vas router je dostat sa k jeho prikazovemu riadku.
K tomu mu chyba (pokial nevie o nejakom softwarovom bugu, o ktorom ja neviem)
meno a heslo nejakeho uzivatela a rootovske heslo, v Cisco terminologii nazyvane
enable secret.

Prva vec, ktoru preto spravime je nastavenie tazko uhadnutelnych hesiel. Tuto
vec nejdem dalej rozoberat, je to vecna tema, zhodna s unixom. Dalej je dobre
vediet, ze ak Cisco nenakonfigurujeme spravne, bude si hesla ukladat bud clear-textovo,
nesifrovane, alebo s pouzitim lahko desifrovatelnej sifry. Preto zasadne pouzivame
prikazy

service password-encryption		! zapiname sifrovanie hesiel

no enable password			! zrusenie starej lahko desifrovatelnej formy

enable secret <vase enable heslo>	! bezpecne zasifrovane heslo

a ak to verzia IOSu dovoli (providerske verzie vyssie ako 12.0(18)S, 12.1(8a)E, 12.2(14)S)

username <vase uzivatelske meno> secret <vase heslo>	! MD5 forma ulozenia hesla

Moznost desifrovania hesla ulozeneho v konfiguracii netreba podcenovat, pretoze
konfiguracie sa casto backupuju, zostavaju na monitore admina, ked si ide do chladnicky
po dalsiu kolu, niektori uzivatelia mozu mat ciastocne pravo vidiet konfiguraciu atd.

Dalsim zakladnym krokom je nastavenie obmedzenia, z ktorych IP adries sa mozu hlasit
administratori do routra. Znemoznime tym utoky typu pokus-omyl a pomstu vyhodenych
kolegov. Vytvorime si standardny access-list, do ktoreho vlozime pocitace, pripadne siete
(s co najmensou netmaskou), ktore mozu na router pristupovat. Spomenieme si na adminov
ST, ktori umoznovali pristup na routre aj zo sieti svojich zakaznikov a pevne sa
rozhodneme, ze budeme chytrejsi. Prislusne prikazy:

no access-list 99				! zrusime stary access-list

access-list 99 permit <IP adresa vasho PC>

access-list 99 permit <IP adresa vasej admin LAN> <reverzna netmaska>

line vty 0 4

access-class 99 in

Pokial mate pristup k IOSu (operacnemu systemu Cisco zariadeni) s podporou SSH,
nevahajte a hned ju zapnite. Zamedzite tak odchyteniu hesla pomocou snifferov,
napr. pri nudzovych pristupoch z domu cez freeband, v skole atd.

crypto key generate rsa		! vygeneruju sa potrebne kluce



line vty 0 4

transport input ssh		! povoli ssh, zakaze telnet

Provideri a vacsie zakaznicke siete vyuzivaju dalsie dve techniky, este viac zvysujuce
bezpecnost. Prva, jednoduchsia, vyuziva privilege levels. Ak niektori pracovnici
potrebuju napriklad len kontrolovat funkcnost interfacov, dalsi ich konfigurovat
atd., netreba im dat plne privilegia. mozeme namiesto toho rozne prikazy priradit
roznym levelom a uzivatelov potom priradime do prislusneho levelu.

privilege exec level 6 show running

username pepa privilege 6 secret ...

Ukazkovy uzivatel Pepa takto ma moznost prezerat si konfiguraciu.

username chudak privilege 0 secret ...

sa moze akurat odhlasit alebo si precitat help o odhlasovani.

Druhou pokrocilou zalezitostou je Cisco AAA (Authentication, Authorization, Accounting).
Po nakonfigurovani TACACS+ servra (prosim nevyslovovat predo mnou po madarsky ako takac'!),
co sa da lahko spravit aj s free tacacsom na free unixe na cheap PC staci nakonfigurovat
vsetky hesla len raz a vsetky routre potom vyuzivaju tuto informaciu. Dalsou vyhodou
je moznost logovania jednotlivych prikazov, automaticke priradenie uzivatelov do
prislusnych privilege levelov, pripadne uplna kontrola nad mnozinou prikazov, ktoru moze
dany uzivatel pouzit.


Samozrejme, nie je potrebne pouzit vsetky tieto vlastnosti AAA, ale len tie, ktore naozaj
potrebujeme.


Dobrym napadom urcite je (najma v pripade vyssie spomenutej cheap varianty, ale v
profesionalnom prostredi kazdopadne) pouzit servre dva, zabezpecit medzi nimi
synchronizaciu dat a instruovat routre, aby ich pouzivali obidva.


V kazdom pripade si nakonfigurujeme nudzovy sposob autentikacie v pripade vypadku tacacsu,
a to lokalnu autentikaciu.

Zaujemcovia o AAA si mozu nastudovat problematiku napr. tu [3].

2) Vypnutie zbytocnych sluzieb

Defaultne bezi na Cisco routri v zavislosti od verzie IOSu viacero sluzieb, o ktorych si
kedysi Cisco inzinieri mysleli, ze nam ulahcia pracu. Odvtedy sa ich zdrojoveho kodu nikto
ani nedotkol a preto predstavuju bezpecnostne riziko.

Vsetky sluzby, ktore nutne nepotrebujeme pri prevadzke, hned vypneme.

no service tcp-small-servers	! echo, keygen atd.

no service udp-small-servers

no service dhcp

no ip http server		! kazdu chvilu je o nom bezpecnostne advisory

no ip http server-secure

no service pad

no ip source-route		! zakazat source-routing

no ip finger

no ip bootp server

no ip domain-lookup		! ak nepotrebujeme pristupovat k DNS

no snmp-server			! pokial nevyuzivame SNMP - nepravdepodobne

Pre kazdy interface mame tiez niekolko "no":

no ip redirects

no ip unreachables

no ip directed-broadcast

no ip proxy-arp			! zakerny prikaz, casto skryva miskonfiguracie siete. zrusit.

no ip mask-reply

Zvlastnou kapitolou je protokol CDP - Cisco Discovery Protocol. Za istych okolnosti je to velmi
uzitocny pomocnik, napriklad v hostingovych centrach a na inych miestach s hustou spletou kablov
a moznostou lahkeho omylu pri kabelazi nam vzdy povie, s akymi routrami/switchmi nas router susedi, na
ktorych portoch su prepojeni, typ a verziu softwaru nasho suseda. Pokial vsak CDP nutne nepotrebujeme,
je lepsie ho vypnut. Odporuca to aj samotne Cisco. Ak ho potrebujeme mat zapnuty, prinajmensom
ho vypneme smerom k zakaznikom a cudzim sietam.

no cdp run	! globalne vypne CDP



cdp run		! ak ho zapneme globalne, automaticky sa zapne na vsetkych interfacoch

interface Serial0

 no cdp enable	! zakazeme CDP napr. na interface Serial0

3) Monitoring routra

Ako iste viete, router nestaci len nakonfigurovat a nechat ho bezat, kym sa nepokazi, ale bezne
potrebujeme z neho ziskavat a vyhodnocovat udaje o jeho prevadzke - statistiky o chode
routra sameho, o prenesenych objemoch dat na jednotlivych interfacoch, o mimoriadnych udalostiach
a vypadkoch atd.

Na ziskavanie statistik z routra je najcastejsie vyuzivany protokol SNMP. Bezpecna konfiguracia vyzera
takto:

access-list 20 remark SNMP ACL		! vytvorime si SNMP access-list

access-list 20 permit <IP servra>	! povolime len server, ktory zbiera statistiky



snmp-server community <komunita> RO 20	! s komunitou zaobchadzame ako s heslom!

Vsimnime si 'RO' v poslednom prikaze, znamena Read-Only access, cize povolujeme len a len citanie.
SNMP protokol totiz umoznuje aj zapisovanie udajov a tym zadavanie prikazov routru. SNMP vsak
nie je connection-oriented a je lahke ho spoofovat, ak pozname komunitu. Preto sa vyhneme
zapisovaniu dat cez SNMP a v routri ho nepovolime.

V pripade, ze sa nemozeme vyhnut poskytnutiu SNMP pristupu zakaznikovi/partnerovi, obmedzime jeho
pristup k SNMP premennym cez tzv. views. Cela syntax je

snmp-server view <nazov view> <oid-tree> {included | excluded}

Pomocou serie takychto prikazov vytvorime v podstate access-list pre jednotlive polozky stromu
premennych v SNMP. Napriklad zakaznikovi povolime sledovat len jeho vlastny interface.
Toto view potom priradime k niektorej komunite a ACL:

snmp-server community <komunita> view <nazov view> RO <cislo ACL>

Aby sme sa vsak nezdrzovali len pri SNMP, pozrieme sa teraz na syslog. Syslog je nas stary znamy
z unixu. V podstate router posiela syslog servru (opat je k dispozicii free riesenie pre kazdy unix)
informacie o vynimocnych udalostiach, ako je vypadok linky, nadmerna teplota, zmena konfiguracie, chyba
v SW/HW atd. Aby mali nase logy zmysel, musime do nich dostat presny cas. Format casovej znacky v logu
nastavime napriklad takto:

service timestamps debug datetime msec show-timezone localtime

service timestamps log datetime msec show-timezone localtime

Presny cas do routra dostaneme cez NTP, co je skratka pre Network Time Protocol.
Bezpecne ho nastavime takto:

ntp authentication-key <cislo kluca> md5 <NTP kluc>	! opat tajne heslo medzi routrom a NTP servrom

ntp authenticate

ntp trusted-key <cislo kluca>

ntp server <IP servra>

ntp update-calendar		! pravidelne synchronizuj HW hodiny podla NTP

Ak nemame vlastny NTP server, poprosime svojho upstream providera alebo sa obhliadneme na internete.

K dalsim informaciam, ktore by nas mohli zaujimat, patria zadane prikazy z prikazoveho riadku.
V pripade fatalnej chyby niektoreho operatora sa takto vyhneme bitke kazdeho s kazdym a rovno prejdeme
na variantu "vsetci na jedneho". Toto nam umozni uz vyssie spominany TACACS.

4) Ochrana routra proti DoS

Aby mohol router bezchybne pracovat, potrebuje perfektne nacas stihat svoju pracu. Utok, ktory by
nadmerne zamestnal jeho procesor, by mohol vyradit spomalit a eventualne zastavit vsetok traffic,
pretoze router by sa venoval niecomu inemu a nie svojej primarnej cinnosti - routovaniu.

Vhodnym opatrenim je zakazanie logovania na konzolu, ktore poziera vela CPU:

no logging console	! v pripade potreby mozeme vzdy zapnut

a dame si pozor na riadky v access-liste, ktore obsahuju na konci slovicko "log". Tato nepochybne
uzitocna feature, ktora nam pocas utoku vie vela prezradit, dokaze lahko odstavit lubovolne velky
router generovanim logov.

Dalsou kategoriou bud DoS utokov alebo nespravnych konfiguracii su routovacie protokoly. Uz ste
niekedy dostali plnu BGP tabulku do routra s nedostatkom pamati? Ak ano a bolo to na zivom routri,
urcite ste si nadlho zapamatali priznaky: router sa podivne sprava, uplink sa rozbieha a opat pada,
nieco je vazne zle... Preto je dobre si ku kazdemu peerovi nastavit maximalny limit, kolko prefixov
nam moze poslat:

router bgp <cislo AS>

neighbor {ip adresa | nazov peer-groupy} maximum-prefix <maximum> [<threshold>] [warning-only]

Horsie je to s internymi routovacimi protokolmi, kde podobne moznosti nemame, a preto zasadne
s nikym cudzim inac ako cez BGP s mnozstvom filtrov nepeerujeme. V konfiguracii vsetkych
internych routovacich protokolov, ktore pouzivame, oznacime zakaznicke, peerovacie aj upstreamove
interfacy ako pasivne. Napriklad

router ospf 100

passive-interface Serial2/3:4

5) MotD

Podla vsetkych manualov, ktore som mal v ruke, je skvelou zbranou v rukach administratora
takzvany Message of the Day. Preto som sa aj ja rozhodol ho zaclenit do tohoto zoznamu bezpecnostnych
opatreni, aj ked zial nie na prislusne popredne miesto.

Ak chcete odstrasit strasneho hackera, ktory vam chce vliezt do routra a robit neplechu, nastavte
textovu spravu, ktora ho pri pokuse o prihlasenie bude varovat s kym ma docinenia a co mu spravite,
ked ho chytite. Syntax je nasledovna:

banner motd <Z>lubovolny odstrasujuci text<Z>

kde <Z> je oddelovaci znak, ktory sa nesmie vyskytovat v samotnej sprave, napr. # alebo %

6) Udrziavanie bezpecnostneho standardu

Tu nejdem hovorit o automatickych kontrolach konfiguracii, ktore by si spravne paranoidny administrator
urcite naprogramoval, ale o prehlade, ktory by si mal kazdy administrator, ktory to mysli s bezpecnostou
vazne, udrziavat.

Cisco vydava pravidelne bezpecnostne advisories, ktore je mozne citat na webe tu [4], alebo je mozne
ich odoberat e-mailom. O bugoch v Ciscu informuje aj BugTraq. Viem o minimalne jednom tohtorocnom bugu,
umoznujucom DoS, ktory zavaril vsetkym ISP a niektori sa pekne strapnili, ked vysvitlo, ze ho niekolko dni
ignorovali. Nie tak ini dobrodinci, ktori im zatial zastavili traffic na routroch. Dalsi bug sa tykal
uz len tych opatrnejsich, ktori pouzivaju SSH (ironia osudu).
Je teda potrebne studovat problematiku, sledovat upozornenia na bezpecnostne problemy v Cisco routroch
a pohotovo reagovat podla odporucani.

Nie je na zahodenie logovat a obcas kontrolovat zmeny v konfiguraciach. Pouzijeme pri tom SNMP trap
signalizujuci zmenu konfiguracie a CVS. Nielen kvoli potencialnym utocnikom, ale aj kvoli pripadnym
konfiguracnym chybam administratorov.

Dalsou dobrou praxou je out-of-band pristup do routrov (konzoly, ina managementska siet), ktory pride
administratorom vhod vzdy pri prebiehajucich DoS utokoch a vypadkoch liniek/routrov po ceste.

7) Pohlad "z druhej strany barikady"

Pohlad utocnika na Cisco routre sa v podstate da odvodit z predchadzajuceho textu. Kazda slabina,
ktoru ponecha administrator, je zaroven sancou pre hackera. Uvediem priklad, ako by mohol vyzerat
checklist, podla ktoreho by utocnik mohol postupovat:

- skusit sa telnetnut, skusit uhadnut meno/heslo - klasicke metody

- skusit to iste s SSH

- skusit hacknut, alebo zafloodovat TACACS+ server, alebo ho inac zhodit a skusit sa
prihlasit

- skusit pristup cez WWW, potom zautocit podla znamych vulnerabilities

- ak sme na connected routri, skusit nejaky utok na CDP (ziaden dobry
nepoznam, ale boli o tom advisories)

- skusit writnut cez SNMP nejaky pekny prikaz (tak je mozne po krokoch
ziskat vsetky prava)

- DoS utoky - od najstarsieho dobreho utoku - land.c cez tohtorocny
utok, cez ICMP flood na adresu routra, telnet flood na adresu routra
(ak tam maju log), preplnenie BGP tabulky, ak sme neighbor

Tento zoznam nie je kompletny, ale dava urcity obraz.

Uspesnemu utocnikovi sa po malej prechadzke po routri a ulozeni si konfiguracie v hlave objavi otazka
"A co dalej?". Tu je niekolko napadov, ako si zabezpeci, ze sa tam opat bude moct vratit a niekolko
tipov, co sa da robit dalej:

- desifrovat potencialne hesla, skusit ich na inych routroch/servroch

- ak router vyuziva lokalnu autentikaciu, vytvorit si vlastne konto, pripadne si zmenit heslo nejakeho
dlho nepouzivaneho loginu (z logu - show logging - sa to da lahko zistit). Povolit svoju IP adresu
v pripadnom access-liste na pristup do routra.

- ak je pouzity TACACS, zapnut debug IP packetov s access-listom zachycujucim len komunikaciu routra
s TACACS servrom a precitat si hesla inych administratorov

- zapnut nejaku sluzbu, o ktorej chybovosti vieme, napr. HTTP server. ak dana verzia bug neobsahuje,
mozeme risknut downgrade IOSu, nepredpokladam vsak, ze by takyto zasah zostal dlho nepovsimnuty.

- pomocou tunelov a policy-routingu sa da niektory druh trafficu tecuceho cez router presmerovat cez
niektory vlastny site na internete. ak uz cez nas tecie traffic potencialnej obete,
mame vobec vela zaujimavych zabaviek, ktore sa daju vyparatit, napriklad sniffovat, alebo sam odpovedat
na DNS a preposielat zakaznika na vlastne stranky, pokusit sa o nejaky man-in-the-middle
attack atd.

- ak je router ucastnikom interneho routovacieho protokolu, utocnik by mohol, a bolo by to od neho
velmi skarede, vyradit z cinnosti podporne systemy celej siete a tym ju znefunkcnit. obvykle totiz
byvaju servre ako DNS, TACACS, e-mail atd. na jednom ethernetovom segmente, a tak sa v routingu
nachadzaju s netmaskou vacsou ako jedna IP adresa, napriklad s maskou 255.255.255.0. Ked teda utocnik
vlozi do interneho routovacieho protokolu routy s maskou 255.255.255.255, budu mat tieto dlhsiu masku,
a preto budu preferovane. Takto odroutuje vsetky requesty na dane servre na seba a zahodi ich.
Potom sa nemoze nikto prihlasit na ziaden router (kvoli nefunkcnemu AAA), nikto nemoze browsovat/mailovat
kvoli nedostupnym DNS servrom atd.

- sposobit niektoremu zakaznikovi 50% packet-loss. To uz je len taka efektna certovina, ako niekoho
nahnevat, ale obcas mam na to aj sam chut. To sa rozbalancuje per-packet traffic medzi nepriatelovou
linkou a interfacom Null.

- nepochybujem, ze niektory sikovny citatel nam v diskusii napise nejake dalsie pekne napady

sim, sim (zavinac) hysteria (bodka) sk

Zdroje:

[1] Secure IOS Template - sucasna verzia 3.1 - http://www.cymru.com/Documents/secure-ios-template.html - 17.11.2003

[2] Cisco ISP Essentials - Essential IOS features every ISP should consider - v2.9 zo 6.6.2001

[3] http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/prod_configuration_guide09186a008017d583.html -
Cisco IOS Security Configuration Guide, Release 12.3

[4] http://www.cisco.com/en/US/products/products_security_advisory09186a00801d2d9d.shtml -
Cisco Product Security Advisories and Notices

navrat na obsah

co ty na to ? href="http://hysteria.sk/board/b.cgi?b=prielom22">board

webhosting s chroot apachom

Roky som na Internete prezival bez toho aby som mal k nemu pripojeny vlastny server pod vlastnou spravou. Presuval
som svoje WWW stranky a e-mailove schranky z pocitaca na pocitac. Intenzita presunov zavisela od vole majitelov
systemov.

Pri poslednom cirkuse okolo migracie domen v TLD .sk ma to prestalo bavit. Zakupil som si potrebny HW, nainstaloval SW
a zaniesol to k poskytovatelovi server housingu.

Aby bola cela sranda financne unosna, zacal som za mierny poplatok poskytovat sluzby kamaratom. Take tie zakladne, ved
to poznate, e-mailove schranky pre rozne adresy, priestor pre WWW stranky, shell ucet. A situacia sa zacala postupne
zhorsovat. Jeden chcel mat HTTP server s podporou servletov, dalsi si pridal PHP, perl, vyuzivanie MySQL atd.

Zanedlho som sa dostal do stavu, ked som musel pridavat virtualne servre, menit konfiguraciu Apache HTTP servra,
vytvarat nove ucty, nastavovat privilegia k databazam a tabulkam v MySQL, a to aj viackrat za den/denne.

Zabezpecenie servra rapidne klesalo. Apache aj MySQL bezali pod uctami
s obmedzenymi pravami, ale to uz snad maju vsetky OS ako default.
Mylit sa je ludske A programatori su toho dokazom. Na to, aby som riskoval, ze niekto vyhackuje data cez zle naprogramovany PHP skript, alebo pozmeni stranky vsetkych virtualnych servrov, som jednak paranoidny a jednak stary.

Preto som zacal hladat sposob ako od seba oddelit jednotlive virtualne WWW servre tak, aby si navzajom nemohli siahat
na data, pamat, databazy a podobne. Bohuzial mnou pouzivany HTTP server Apache od The
Apache Software Foundation to neumoznuje (dokaze nejaky HTTP server podobne veci? Ozvite sa, ak ste na nieco podobne
narazili.)

Jeden zo sposobov je zacat na nizsej aplikacnej urovni a kazdemu uzivatelovi vyhradit jeden OS. To mi vsak pripada ako
nahanat komara s puckou (to je take velke kladivo, ak by ste nevedeli).

V kazdom pripade, ak by ste chceli nechat bezat na jednom pocitaci simultanne viacere instancie operacneho systemu,
mozte to skusit pod Linuxom: User-mode Linux, href="http://www.vmware.com/">vmware. Pre Windows: Virtual
PC a vmware.

Na virtualne infrastruktury v Solarise si
este pockame.

Cely system som potreboval sprevadzkovat pod Linuxom, no aj napriek tomu som sa snazil aby bolo riesenie prenositelne
aj na ine OS (konkretne je v tomto texte spomenute riesenie pre Solaris 9).

Na riesenie som mal nasledujuce poziadavky:

minimalna interakcia spravcu systemu pri nastavovani parametrov HTTP
servra,
ochrana dat pouzivatelov (napr. chybne naprogramovany PHP skript nesmie
umoznit pristup k datam ostatnych pouzivatelov virtualnych servrov),
ochrana systemu (hacknutie HTTP servra nesmie umoznit pristup k OS),
pouzivatel musi mat moznost spravovat si svoj virtualny server sam.

Obmedzenia:

len jedna IP adresa pridelena servru pre pristup k Internetu,
neexistencia HTTP servra, ktory by poskytoval vlastnosti uvedene vyssie.
standartny HTTP server bezi na well-known porte 80, su potrebne privilegia na vytvorenie raw socketu.


Poziadavky 2 a 3 boli splnene tym, ze som premiestnil Apache server do chroot-u (na RedHat Linuxe je chroot sucastou
balika sh-utils, v Solarise 9 ho najdete v baliku SUNWcsu) v pouzivatelovom adresari a nechal na pouzivatelovi, nech si
ho spusta sam.

Vacsia cast prace administratora OS odpada, pretoze kazdy uzivatel je zodpovedny za obsah svojho konfiguracneho suboru
pre svoj Apache HTTP server (splnena poziadavka 1 a 4).

Ako si mozte precitat nizsie, obmedzenia sa daju obist spravnym navrhom riesenia a este poskytnu celkom prijemne
vedlajsie ucinky.

Kazdemu uzivatelovi som v systeme nakonfiguroval jednu lokalnu IP adresu, ktora sa pouziva len vnutorne na servri a neobjavuje sa na Internete (vybral som si neskromne siet 10.0.0.0) a vytvoril lokalne virtualne sietove interfaces.

V Linuxe som pouzil dummy interfaces, v Solarise to bude fungovat, ak vytvorite interface lo:?, kde ? je cislo
virtualneho interface. Pouzivatel moze na pridelenej lokalnej IP adrese pouzivat ktorykolvek port v rozsahu 1025-65535.

Cela adresarova struktura obsahujuca Apache server a k nemu potrebne veci (napr. perl pre cgi-bin scripty) je vytvorena
a spravovana administratorom. Kazdy pouzivatel ju ma namountovanu read-only vo svojom domacom adresari (pod Linuxom som
pouzil prikaz `mount --bind -o ro', pod Solarisom `mount -F lofs -o ro').

Konfiguracny subor Apache HTTP servru umoznuje vkladanie textu prikazom include, takze zakladne konfiguracne parametre
su ulozene v system-wide konfiguracnom subore (read-only pre pouzivatela) a je na uzivatelovi, co si ulozi do svojho
konfiguracneho suboru (read-write pre pouzivatela), ktory je includovany system-wide konfiguracnym suborom.

Usporiadanie suborov moze vyzerat nasledovne:

/chroot - adresar obsahuje strukturu Apache servra

/home/mikulas/chroot
- tento adresar sluzi ako / po spusteni prikazu chroot, jeho obsah je
nasledovny:

lrwxrwxrwx 1 mikulas mikulas    7 Jan 28 11:19 bin -> sys/bin

lrwxrwxrwx 1 mikulas mikulas    7 Jan 28 11:19 dev -> sys/dev

lrwxrwxrwx 1 mikulas mikulas    7 Jan 28 11:19 etc -> sys/etc

lrwxrwxrwx 1 mikulas mikulas    7 Jan 28 11:19 lib -> sys/lib

drwx------ 3 mikulas mikulas 4096 Jan 28 21:31 proc

lrwxrwxrwx 1 mikulas mikulas    8 Jan 28 11:19 sbin -> sys/sbin

drwxr-xr-x 9 root    root    4096 Jan 28 18:32 sys

lrwxrwxrwx 1 mikulas mikulas    8 Jan 28 11:19 tmp -> user/tmp

drwx------ 7 mikulas mikulas 4096 Jan 28 18:41 user

lrwxrwxrwx 1 mikulas mikulas    7 Jan 28 11:19 usr -> sys/usr

lrwxrwxrwx 1 mikulas mikulas    8 Jan 28 11:19 var -> user/var

/home/mikulas/chroot/sys - v tomto adresari je
namountovany read-only adresar /chroot.

/home/mikulas/chroot/user - adresar `user' je read-write pre pouzivatela a obsahuje napr. v system-wide httpd.conf
includovany konfigurak.

Malou komplikaciou je skutocnost, ze prikaz chroot moze uspesne
pouzit len root.

Na elimininaciu tohto problemu som pouzil sudo (v RedHat Linuxe sa nachadza v baliku sudo, v Solarise v baliku
SFWsudo). Napr. pre start Apache HTTP servra je potrebne pouzit prikaz:

sudo chroot /home/mikulas/chroot su - mikulas apachectl start

Text vyssie popisuje sposob ako dosiahnut stav, aby kazdemu pouzivatelovi mohol bezat chrootovany HTTP server na jeho
lokalnej IP adrese.

Aby sa k tymto servrom dostali poziadavky z Internetu, je potrebne podla obsahu HTTP requestu presmerovat z nasej
jedinej verejnej IP adresy pakety na prislusne IP adresy a spat.

K tomuto som pouzil squid (pre RedHat Linux balik squid, pre Solaris
SFWsquid) beziaci v "accelerator mode" a perl redirector, ktory prepisuje URL z Internetovej IP adresy/hostname na
lokalne adresy a porty. Samozrejme, ze squid bezi vo svojom sukromnom chroot prostredi.

Vyhody hore uvedeneho riesenia:


pouzitie jednoducho dostupneho OS a SW,
pomerne jednoduche upravy a prisposobenia pouziteho SW (na urovni
konfiguracnych suborov),
prenositelnost (demonstrovane na RedHat Linuxe a Solarise 9),
mozny transparentny upgrade (napr. prenos HTTP servrov na dedikovane pocitace),
zdarma.

Nevyhody:

nepodporovane (zdarma),
konfiguracia na roznych miestach (squid.conf, httpd.conf, sudoers, ...),
zataz systemu (pre cca 10 pouzivatelov je na AMD Athlon(tm) XP 1700+ procesore a 512 MB pamate pod RedHat Linuxom hore uvedene riesenie absolutne v pohode),
potreba vytvorit pouzivatelsky interface k prikazom na ovladanie HTTP servra,
potreba vytvorit startup script pre namountovanie chroot adresarov a start HTTP servrov po reboote.

V pripade zajmu rad zverejnim detaily celej implementacie.

Mikulas Papuca

navrat na obsah

co ty na to ? board

databazy telefonnych cisiel

intro

slovenskym internetom zase koluju databazy telefonnych cisiel eurotelu, orange aj st. tentokrat s pomerne cerstvymi
udajmi a naviac v niekolkych pripadoch okrem mena a adresy majitela obsahuju aj rodne cislo a cislo obcianky. pokial sa
nieco radikalne nezmeni v systeme akym slovenske firmy manazuju informacie o svojich zakaznikoch, nastane kolaps.
moze prist k zverejneniu velkeho mnozstva osobnych udajov a k naslednej strate dovery zakaznikov a trhu voci firmam,
elektronickym sluzbam, ci vseobecne voci informacnym technologiam..

ak by sa niekto z pomerne velkeho mnozstva ludi, ktori maju teraz tieto databazy k dispozicii rozhodol, ze ich zverejni
na internete, ochrana osobnych udajov by na nejaky cas uplne stratila zmysel. co by sa stalo ak by niekto na net
vyvesil napriklad zoznam vsetkych rodnych cisiel obcanov aj s menami ? malo by zmysel po tomto dni ochranovat rodne
cislo ako citlivy udaj ? alebo by stat vsetkych ludi "precisloval" ? co spravim ako obcan ak niekto zverejni na
internete vsetky udaje o mne vratane adresy, rodneho cisla, ci cisla mobilu ? nuz.. rychlo si zmenim cislo telefonu,
ale zmenim si aj rodne cislo ? nezmenim, aj o dvadsat rokov si ho bude moct niekto z tejto databazy vytiahnut a pouzit
ho na co ho napadne, lebo internet nezabuda.. data sa hned objavia na search enginoch, mirroroch, lokalnych diskoch..

databazky

databazky po nete vzdy kolovali, stacilo len poznat tych spravnych ludi. ale je to cim dalej tym horsie. tusim v
roku '97 pobehoval po nete asi prvy zoznam cisiel eurotelu. v novinach o tom bola kratka senzacna spravicka a potom sa
na to rychlo zabudlo. potom sa to iste prihodilo orange. potom zase. potom sa hovorilo o databazke slovenskej
poistovne, ktoru slohla skupina f. ta bola udajne aj na predaj. ked slovenske telekomunikacie spustili na webe online
zoznam cisiel, pocul som minimalne o troch pripadoch kedy im niekto dokazal pomocou sikovnych scriptov stiahnut z webu
cely zoznam telefonnych stanic (dalo sa searchovat na 3-pismenove stringy, ich vsetky kombinacie sa dali zbehnut za
jednu noc..) no a potom ich hackli triuhorky a na svete bola dalsia databaza. st samozrejme celu zalezitost
zbagatelizovali a o par dni sa na to zabudlo. medzitym koloval zoznam cisiel telefonnych automatov, nejake novsie
zoznamy orange a naposledy kompletny zoznam easy kariet a prima kariet s menami majitelov, adresami, rodnymi cislami a
cislami op. ako je to mozne ?

slovenskym firmam chyba koncept spravy identit svojich uzivatelov ci zakaznikov. treba si uvedomit jednu vec - vacsinu
tych databaz neziskali genialni hackeri zlozitymi technickymi prienikmi do firemnych sieti, ale si ich jednoducho
stiahol hocijaky interny zamestnanec danej firmy s poslabsou moralkou. firmy zaviedli rozne zakaznicke informacne
systemy (ZIS), ktore ale vo vacsine pripadov vobec nemaju zakomponovanu nejaku zlozitejsiu spravu identit zakaznikov.
proste cielom ZIS je aby kazdy zamestnanec videl vsetko o hocijakom zakaznikovi lebo tak je to jednoduchsie (t.j.
lacnejsie) a z pohladu biznisu vyhodnejsie. a tak sme sa dostali do stavu, ze napriklad u mobilneho operatora azda aj
zamestnanec na velmi nizkej stolicke z pohladu firemnej hierarchie dokaze vidiet a ukradnut citlive osobne udaje.
zjavne je tazke pre jednoduchsie zmyslajuceho zamestnanca odolat a nevyhladat si utajene cislo nejakej znamej
osobnosti.. alebo preco by si rovno nestiahol cely telefonny zoznam, ked mu to system umoznuje ? alebo neumoznuje ?
nie je cielom tohto clanku prehnane kydat na spominane firmy ked velmi malo pozname do akej miery naozaj tieto udaje
chrania.. ale ako je potom mozne ze sa skoro v pravidelnych intervaloch potuluju po nete nove a nove databazky ?

a bude to cim dalej tym horsie. informatika bude hrat coraz dolezitejsiu ulohu v nasom kazdodennom zivote. databazy sa
zacnu navzajom prepajat a spajat.. teraz ma jedna firma moje rodne cislo, druha firma ma moj zoznam telefonnych
hovorov, dalsia firma ma zoznam mojich oblubenych potravin a dalsia zase celu moju zdravotnu kartu.. casom azda
prepojenim tychto izolovanych datovych ostrovov vznikne databaza vsetkych databaz, kde bude o mne uplne vsetko.
a ak mi to niekto ukradne, ostanem nahy, nebudem mat co skryvat. z cisto datoveho pohladu budem desifrovany, nacitany a
verejne vysharovany..

riesenie

co s rozliatym mliekom ? no v prvom rade asi treba spominanym organizaciam naparit riadnu pokutu. zjavne porusili zakon
o ochrane osobnych udajov c.428/2002, na urade na ochranu osobnych udajov je mozne na nich podat staznost, dokonca
online (http://www.dataprotection.gov.sk/buxus/generate_page.php3?page_id=277). tak sup do toho, chodte si poklikat.

dolezitejsie je ale zabezpecit, aby sa taketo pripady prestali opakovat. cital som viackrat nazor, ze by mali mat
vsetky firmy nad isty financny obrat povinny bezpecnostny audit informatiky, tak ako maju dnes povinny napriklad
financny audit. zakony ale nezabezpecia ochranu citlivych dat na internete, hrozba pokuty nemoze byt jediny motivator.
realnejsi sa javi byt nazor publikovany v nedavnom cisle casopisu wired, aby sa vytvoril system pridelovania ratingu
komercnych firiem na zaklade ich schopnosti zabezpecit svoje citlive data
(http://www.wired.com/wired/archive/12.01/view_pr.html). tak by sa potom mohol vymysliet system podobny ratingu urovne
hotelov hviezdickami:

napriklad firma ktora by mala bezpecnost osobnych udajov na vysokej urovni by dostala styri hviezdicky, ina firma by
dostala len dve hviezdicky. zakaznici by radsej minali peniaze vo firmach s vacsim poctom hviezdiciek a tak by sa
trhove sily postarali o to aby sa uroven bezpecnosti zvysila vo vsetkych firmach..

firmy by mali vylepsit sposob akym narabaju s osobnymi udajmi. je potrebne prisnejsie urcit ktory zamestnanec moze
pozerat do akej urovne informacii. ked napriklad volam na hotline mobilneho operatora, azda nie je potrebne aby vedel
operator najst v databaze moje meno. mozno by stacilo aby videl aky mam predplateny program. ak by som mal problem
ohladne platenia faktur, mohol by ma prepojit zamestnancovi v uctarni ktory by zase nevidel aky mam predplateny
program, ale videl by iba ci som uhradil vsetky faktury. ani tento zamestnanec by nemusel vidiet moje prave meno,
stacilo by azda len nejake specialne pridelene cislo. a naco by vlastne nejaky pracovnik mobilneho operatora mal vidiet
moje rodne cislo alebo cislo obcianky ? tieto udaje by mohli byt viditelne len pre velmi uzky okruh zamestnancov..
alebo aj pre nikoho, naco je vlastne mobilnemu operatorovi moje rodne cislo ? no fakt neviem, ved ide len o to ze on mi
dava moznost pouzivat nejaku malu elektronicku vysielacku a ja mu za to platim.. a co ma do kelu s tym vsetkym spolocne
cislo mojej obcianky ? jednoducho je potrebne prisne zvazit business potrebu pristupu kazdeho jedneho zamestnanca k
tomu alebo tamtomu typu osobnych udajov zakaznikov. nenavrhujem nic nove - metodika existuje a su k dispozicii
softverove nastroje na riadenie zloziteho manazmentu identit zakaznikov. viz napriklad informacie na stranke
http://www.projectliberty.org/.

dalsim moznym riesenim by bolo vytvorenie nejakeho centralizovaneho spravcu identit obcanov. bola by to organizacia,
ktorej by som zveril udaje o svojej identite a tato organizacia by na zaklade mojho povolenia poskytovala tieto udaje
tretim stranam. ak by som si napriklad aktivoval SIM kartu u mobilneho operatora, ten by vobec nemusel poznat moje meno
,ci ine osobne udaje o mojej osobe. obratil by sa na spravcu mojej identity ktoremu by doveroval a ten by mu povedal
elektronickym sposobom len to co mobilny operator potrebuje vediet - ze som slusny clovek s trvalym bydliskom na uzemi
SR, ktory si plati svoje ucty... nic viac mu netreba.

otazka je akemu typu organizacie by sme vedeli doverovat so spravou nasich identit ? nuz, su minimalne dva typy
institucii ktore si za uplynule desatrocia vybudovali urcite lepsiu povest a doveru s ochranou osobnych udajov ako nase
telekomunikacne firmy - su to statne organizacie a banky. ked uz som zveril banke svoje peniaze, myslim ze by som
zvladol doverovat banke aj v oblasti dohladu nad mojou identitou. koniec koncov aj tak uz maju fotokopiu mojej
obcianky, rodne cislo, aj podpisovy vzor. naviac financny sektor pouziva zjavne radovo vyssi stupen zabezpecenia
osobnych udajov svojich klientov, ako ine firmy. poculi ste niekedy o tom ze by z nejakej slovenskej banky unikla
databaza vsetkych uctov s menami majitelov, rodnymi cislami, ci inymi datami ? ja nie. zato nasim telekomunikacnym
firmam sa to zjavne stava podchvilou..

co moze v tejto situacii spravit radovy obcan ? nuz, v suvislosti s telekomunikacnymi firmami je tu zopar
doporucenych obrannych tahov:



stazovat sa. hocijaka banda hax0rov ma tvoje rodne cislo, adresu, mozno aj cislo obcianky. skus to
vykricat svojmu mobilnemu operatorovi. alebo zmen operatora ak si myslis ze to ten druhy robi lepsie.

zahodit svoju existujucu SIM kartu a zohnat si anonymnu. daju sa kupit v bazaroch s mobilmi, alebo na inzerat.
alebo treba oslovit bezdomovca na ulici aby ju skocil do obchodu kupit.. dalsia moznost je zabehnut si do ceskej
republiky kde sa daju prepaid SIM karty kupit anonymne.

pohrat sa s IP telefoniou. zabudni na ST, hlasove sluzby na pevnej linke ti uz ponukne aj tvoj internet provider. a
ti zjavne nemaju az take problemy so spravou identit. a wi-fi mobilne telefony tu budu cochvila..



kto vlastne..

nevieme kto spominane databazky slohol, ani ci to boli interni zamestnanci spominanych operatorov (asi), alebo niekto
zvonka. hysteria.sk umoznuje svojim uzivatelom komunikovat a vymienat si subory ci poznatky uplne anonymne. myslime si
ale, ze je dolezite povedat svetu ze sa taketo veci deju. stat ani firmy vam to nepovedia.

hysteria crew, prielom (zavinac) hysteria (bodka) sk

navrat na obsah

co ty na to ? board

preco nas buducnost nepotrebuje.

Nase najsilnejsie technologie 21. storocia - robotika, geneticke inzinierstvo a nanotechnologie - hrozia spravit z
ludi ohrozeny druh.

Od momentu, ked som sa zacal podielat na tvorbe novych technologii ma zacali znepokojovat ich eticke rozmery. Ale bolo
to az na jesen v roku 1998, ked som si s hrozou uvedomil, ake velke nebezpecenstva nas cakaju v 21. storoci. Zaciatok
mojich obav sa datuje ku dnu mojho stretnutia s Rayom Kurzweilom, zasluzene slavnym vynalezcom prveho citacieho stroja
pre slepcov a mnohych dalsich uzasnych veci.

Ray i ja sme prednasali na konferencii Telecosm a stretol som ho nahodou pri hotelovom bare po skonceni nasich
prednasok. Sedel som tam s Johnom Searlem, filozofom z Berkeley studujucim vedomie. Zatial co sme hovorili, prisiel Ray
a zacal sa rozhovor, ktoreho tema ma prenasleduje dodnes.

Zmeskal som Rayovu prednasku a nasledny panel s Johnom a Rayom a oni teraz pokracovali presne tam, kde predtym
skoncili, ked Ra