Intervju: Peter Van Eeckhoutte

• :: 10. maj 2010

(english version)

Uvod:
Serijo pogovorov nadaljujemo z nekoliko nenavadnim intervjujem - Peter Van Eeckhoutte je večini bralcev, ki ne sledijo svetovni InfoSec sceni verjetno popolnoma neznano ime. Po mnenju poznavalcev pa se njegov renome na lestvici vrhunskih varnostnih raziskovalcev strmo vzpenja. Je avtor številnih izredno kvalitetnih vodičev o izkoriščanju prekoračitev medpomnilnika v Oknih ter ustanovitelj ekipe Corelan, skupine entuziastov, ki jih druži skupen interes: raziskovanje varnostnih pomanjkljivosti.

Slo-Tech: Se lahko na hitro predstavite našim bralcem?

Peter Van Eeckhoutte: Ime mi je Peter Van Eeckhoutte (to je tipično belgijsko ime, zato niti ne poskušajte izgovoriti mojega priimka :), na internetu pa sem poznan tudi pod nadimkom corelanc0d3r. Leta 1998 sem diplomiral iz uporabne informacijske tehnologije. Takrat so bila še vedno popularna razvojna okolja in programski jeziki, kot so npr. Clipper, C++, Cobol in RPG - mimogrede, dandanes lahko z obvladovanjem Cobola in RPG-ja mastno zaslužite. Čeprav smo se na faksu v glavnem osredotočali na analize in razvoj, sem kmalu spoznal, da nočem po cele dneve sedeti za računalnikom in programirati. Takrat sem imel tudi že kar nekaj izkušenj s strojno opremo in omrežji, zato so me leta 1997 v neki računalniški trgovini v domačem kraju zaposlili kot vodjo tehničnega servisa, tako da sem hkrati delal 8 ur na dan in še redno študiral. Da bi sebi in sodelavcem olajšal delo, sem napisal nekaj skript in orodij (v Visual Basicu 5 in 6, ASP-ju, itd.) za avtomatizacijo administrativnih in tehničnih postopkov.

Slo-Tech: In kdaj ste pristali v svetu računalniške varnosti? Ste imeli kak poseben motiv?

Peter Van Eeckhoutte: Nekega dne nam je ena od strank v servis prinesla računalnik, ki se je "čudno obnašal". Kar nekaj časa sem se ukvarjal z njim, nato pa sem ugotovil, da na njem teče program Back Orifice. Ker sem imel že nekaj izkušenj s programiranjem, sem poznal tisti navdušujoč občutek, ko ti uspe računalnik pripraviti, da počne nekaj, kar mu ukažeš. Ko pa sem odkril, kako se da zlorabiti razne aplikacije in operacijske sisteme, me je to še bolj pritegnilo. Ta incident z Back Orificom je zame povsem na novo definiral zgoraj omenjeno misel, da računalnik oziroma program pripraviš, da počne nekaj, kar mu ukažeš. Takrat sem se iz čistega programiranja usmeril bolj v računalniško varnost. Kar pa se tiče motivov, bi rekel, da sta ukaželjnost in vedoželjnost del mene, tako da tega ne morem ravno šteti za motiv. Kar zgodilo se je.


Slo-Tech: Katere strokovnjake za računalniško varnost posebej spoštujete? Je imel kateri od njih močan vpliv na vaše trenutno delo na področju računalniške varnosti?

Peter Van Eeckhoutte: Kar nekaj raziskovalcev s področja računalniške varnosti imam zelo v čislih. Vsakdo, ki si vzame čas in naredi pošteno raziskavo ter svoje izsledke deli s svetom, si zasluži spoštovanje. Brez takih raziskav in na internetu objavljenih izsledkov ter uporabljenih metod verjetno danes ne bi vedel vsega tega, kar vem. V nasprotju z nekaterimi drugimi vejami informacijske tehnologije se je na našem področju precej težko naučiti »hekati« in izkoriščati varnostne luknje, če se moraš tega učiti sam. Zmožen moraš biti razmišljati na drugačen način in imeti ogromno zakladnico znanja o tem, kako stvari delujejo. Z moje strani lahko rečem le, kapo dol ljudem, ki vlagajo svoj čas in trud v raziskovanje.

Slo-Tech: Na sceni računalniške varnosti ste dobro poznani po svojih izvrstnih vodnikih za izkoriščanje prekoračitev medpomnilnika,
predvsem zato, ker na samosvoj in jasen način predstavljate kompleksne teme, ki jim je zato relativno lahko slediti. Zakaj ste začeli pisati v takem stilu?

Peter Van Eeckhoutte: Ko sem začenjal spoznavati prekoračitve medpomnilnika, sem veliko informacij našel na internetu in v knjigah. Nisem prvi, ki piše o takih zadevah, niti se ne pretvarjam, da sem. Veliko takih knjig in člankov pa ima očitno hibo - prvi del je napisan spodobno, nato pa pride do silovitega preskoka. Na specifične preskoke je težko pokazati s prstom, težko jih je definirati, a so vseeno precej učinkoviti pri tem, da so mene in verjetno še koga odvrnili od nadaljnjega branja. Verjetno ima pri tem nekaj vpliva tudi stil, v katerem so napisane določene knjige, in pa dejstvo, da določene podrobnosti preprosto manjkajo. Lahko bi sicer razpredal o tem, da moraš na začetku učenja pač vztrajati in se bolj potruditi, a bodimo iskreni - ko se nečesa šele lotevaš, zelo ceniš nekaj dodatne pomoči (popolnoma odvečne preskoke v težavnosti pa malo manj). Konec koncev smo vsi le ljudje in nihče se ni rodil z vsem znanjem na svetu - oziroma s talentom, da se lahko vsega nauči čisto sam.

No, da dokončam to zgodbo: zaradi tega sem začel pisati svoje vodnike in v njih podal svoj pogled na neko temo. Če vprašate mene, novincem svetujem, naj najprej preberejo kak vodnik, nato pa naj se lotijo knjig. To jim bo morda pomagalo razumeti knjige, saj je v njih prav zares zbrano veliko podatkov. Če se komu zdi, da je kateri od mojih vodnikov na kakršenkoli način pomanjkljiv, naj mi to sporoči. Konstruktivne kritike in predlogov se nikoli ne branim.

Slo-Tech: Se vam ne zdi, da je na modernih operacijskih sistemih že zelo težko izkoriščati klasične prekoračitve medpomnilnika na skladu? So prekoračitve naslednja vrsta računalniških hroščev, ki jim grozi izumrtje, ali obstaja še dovolj možnosti za njihovo izkoriščanje?

Peter Van Eeckhoutte: V bistvu ne verjamem, da lahko obstaja uporabniku prijazen oz. uporaben, a hkrati 100 % varen sistem. Če na sistemu lahko namestiš in izvršiš kodo, se bo verjetno dalo tudi najti pomanjkljivosti in jih izkoristiti. Poglejte, koliko se je v zadnjih desetih letih vlagalo v varnost operacijskih sistemov, prevajalnikov in sklada, in kakšno je stanje danes.

Ljudje še vedno vsak dan odkrivajo in objavljajo kodo za izkoriščanje prekoračitve sklada - vsem zaščitnim mehanizmom in vanje vloženemu trudu navkljub. Po mojem mnenju dobre stare prekoračitve sklada še zdaleč niso mrtve. Obiti se da tako piškotke sklada kot tudi ASLR (Address space layout randomization) in NX (NoExecute) bit. Veliko aplikacij sploh ne uporablja /GS, ali pa uporabljajo skupne knjižnice drugih proizvajalcev oz. avtorjev, ki pa niso zaščitene s /SafeSEH, in tako dalje. Kljub vsem tem prizadevanjem pa dvomim, da bodo taki hrošči kaj kmalu zatrti. Če pa slučajno bodo, jih bodo pa nadomestili hrošči naslednje generacije, ki bodo prav tako ogrožali stabilnosti sistemov. Morda pa bo dalo stare vrzeli, npr. nepomembne DoS ranljivosti, zaradi novih tehnik kar naenkrat veliko bolje izkoriščati. Pomislite na unicode pomanjkljivosti ali dereferenciranje ničelnega kazalca (null-pointer dereference). Ljudje so dolgo mislili, da se tovrstnih pomanjkljivosti ne da izkoriščati. Veliko ljudi še danes misli tako. Nedolgo nazaj sva s Felixom "FX" Lindnerjem iz Phenoelita govorila o tem, da še dandanes veliko ljudi misli, da je prekoračitev medpomnilnika z unicode nizom nemogoče izkoristiti. To je preprosto žalostno. Dokazuje pa, da se splača iskati nove tehnike za zlorabo starih vrzeli.

Pa še nekaj: raziskovanje računalniške varnosti ni le hobi, ampak resen posel - tako za "poštene" hekerje kot za tiste z bolj ohlapnimi etičnimi načeli. Dokler bodo ljudje s tem lahko služili, se bodo raziskave nadaljevale.

Slo-Tech: Poleg vsega ste tudi vodja varnostne ekipe Corelan, skupine navdušencev nad računalniško varnostjo, ki se s tem ukvarja predvsem zaradi zabave in izkušenj. Kako pravzaprav poteka komunikacija med člani ekipe? Ali Corelan sodeluje tudi z drugimi skupinami ali renomiranimi raziskovalci?

Peter Van Eeckhoutte: Ah, pretiravate. Vodja se sliši tako nobel :) V bistvu sem samo začel pisati blog in osnoval ekipo, a smo kljub temu vsi člani ekipe enakopravni. Prav vsakogar spoštujem zaradi njegovih prispevkov in sposobnosti. Vsi smo kolegi in nas druži skupna želja po učenju, izobraževanju in širjenju znanja. Ker ima vsak od nas tudi redno službo in ker smo raztepeni po vsem svetu, je precej težko zbrati skupaj vse člane ekipe, da se o čem pogovorimo. Navkljub vsem tem preprekam pa precej uspešno sodelujemo in uporabljamo standardne komunikacijske kanale, npr. e-pošto, privaten IRC strežnik in podobno.

V tem trenutku ne sodelujemo z drugimi skupinami ali raziskovalci. Pa ne zato, ker ne bi hoteli, ampak zato, ker visoko cenimo naše vrednote in ne moremo vplivati na to, kaj počnejo drugi. Pa tudi ko kdo odkrije kako novo varnostno luknjo, je povsem običajna reakcija, da to najprej s ponosom in zadovoljstvom predstavi svoji majhni skupinici kolegov, šele nato pa te informacije objavi tudi javno. Seveda pa to niti pod slučajno ne pomeni, da drugih skupin ali raziskovalcev ne spoštujemo.

Slo-Tech: Katera orodja uporabljate pri svojem raziskovalnem delu? So katera od teh orodij spisali člani Corelana? Morda Corelan pri raziskovalnem delu uporablja lastna, interna oziroma še ne objavljena orodja?

Peter Van Eeckhoutte: V glavnem uporabljamo stvari, ki jih uporabljajo tudi vsi ostali, čeprav včasih spišemo kako namensko skripto, ki določeno stvar opravi hitreje :) Dober primer tega bi bil, če v kakem formatu datotek naletimo na kak "strukturni hrošč". Potem običajno sprogramiramo skriptico, ki nam pomaga najti podobne hrošče v drugih aplikacijah. Tu ni nobenih skrivnosti. V končni fazi pri raziskovanju programskih ranljivosti in razvijanju rešitev zanje ne gre za orodja. Orodja ti sicer omogočajo, da nekaj narediš hitreje, a moraš vseeno najprej kreativno uporabiti svoje možgane.

Še en primer skripte oziroma orodja, ki pomaga ljudem hitreje in bolj zanesljivo analizirati sesutja ter dokumentirati varnostne luknje, je "pvefindaddr", plugin (PyCommand), ki sem ga napisal za Immunity Debugger. Ta skripta je na voljo na Corelanovi spletni strani.
Čeprav je to orodje že javno izdano, nove različice in nove zmogljivosti skripte najprej preizkusimo interno. Trenutno preizkušamo nov modul, ki pomaga pri luščenju koristnih podatkov iz izkoriščanja povratka iz funkcij (ROP payload).


Očitno vas bom moral razočarati - prav nič posebnega ali skrivnostnega ne uporabljamo :) Najboljše in najbolj učinkovito orodje je zdrava pamet. Orodja sicer omogočajo doseganje ciljev, možgani pa so tisti, ki morajo cilj najprej določiti in dognati, kakšna je pot do njega.

Slo-Tech: Kakšen je standardni postopek Corelana pri objavljanju hroščev?

Peter Van Eeckhoutte: Mislim, da uporabljamo postopek, ki ga pogosto uporablja mnogo ljudi. Najprej stopimo v stik s proizvajalcem programske opreme in ga poskušamo prepričati, da mu želimo le pomagati pri odpravi hrošča (kako žalostno se to sliši...). Prva e-pošta seveda ne vsebuje nobenih tehničnih podatkov, le povezavo do naše politike razkrivanja in kategorijo ranljivosti. Nato mu damo dva tedna časa, da odgovori in pove, ali želi sodelovati z nami. To seveda ne pomeni, da mora v dveh tednih odpraviti napako. Če proizvajalec odgovori, mu damo priložnost, da hrošč odpravi in izda varnostni popravek, nato pa varnostno pomanjkljivost objavimo. Če ne odgovori, mu pošljemo še eno e-pošto. Če prezre tudi to, hrošč javno objavimo. Enostavno, a pošteno.

Slo-Tech: So Corelanu druga podjetja kdaj grozila s tožbami? Kako se spopadate s takimi situacijami? Imate na voljo kakega pravnega svetovalca?

Peter Van Eeckhoutte: Dobro vprašanje :) Ravno pred nekaj tedni smo naleteli na neko dansko firmo, ki smo ji sporočili, da ima v svoji aplikaciji varnostno luknjo. Odgovorili so nam, da se, prvič, ne strinjajo z našo politiko razkrivanja, in drugič, da nas bodo tožili.

Verjetno so nekateri takih stvari že vajeni, jaz pa sem kaj takega doživel prvič in sem bil šokiran. Mi jim delamo uslugo, oni nas pa hočejo zato tožiti?

Malce sem se pozanimal, govoril z odvetnikom, z nekom iz belgijskega Urada za računalniški kriminal in z ljudmi iz fundacije EFF (Electronic Frontier Foundation), ter prišel do zaključka, da ne počnemo prav nič spornega:

• Programske opreme nismo pridobili na nelegalen način. Preizkusno verzijo se da brezplačno naložiti s proizvajalčeve spletne strani.
• Pri odkrivanju in izkoriščanju hrošča nismo oškodovali ali ogrožali nobenih sistemov tretjih oseb.
• Moja temeljna pravica do svobode govora mi omogoča, da izsledke svojih raziskav objavim na svoji spletni strani.

Vse to so samo moje ugotovitve, saj nimam dovolj sredstev, da bi najel vojsko odvetnikov. Precej gotov pa sem, da ne počnemo prav nič nelegalnega.

Podjetju sem odpisal, da mu želimo pomagati in da ne vemo, zakaj smo bili deležni tako agresivne reakcije. V odgovoru so mi povedali, da te svoje aplikacije nič več ne podpirajo in razvijajo (a jo kljub temu še na prej prodajajo na svoji spletni strani) in da jim ni jasno, zakaj smo se vtaknili ravno v ta program, ki ga "itak vsi uporabljajo le v varnem okolju". Očitno so prepričani, da tega programa nihče ne namesti na računalnik, ki je povezan na internet, in da se jim zdi možnost vdora od znotraj neobstoječa. Zato sem primer zaključil, izsledke pa objavil na naši spletni strani.

To je šolski primer situacije, zaradi katere ljudje začnejo razmišljati o tem, da bi prenehali z odgovornim razkrivanjem. A moram v isti sapi tudi povedati, da smo dobili že veliko e-pošte od prodajalcev in razvijalcev tako velikih kot majhnih podjetij, ki so se nam iskreno zahvalili za naš trud in odgovornost. Vsem zagnanim raziskovalcem računalniške varnosti torej polagam na srce, da naj se ne vdajo, da naj se spominjajo hvaležnih strank in da naj svojo jezo do nehvaležnežev pretvorijo v motivacijo za iskanje novih hroščev.
Vsem prodajalcem in razvijalcem pa sporočam, da jim delamo uslugo. Ne jezite se na nas, saj ste bili vi tisti, ki ste naredili napako.

Slo-Tech: Lahko kdorkoli postane član ekipe Corelan ali imate stroge kriterije za članstvo? Kako sploh poteka pridružitveni postopek? Kako sankcionirate nepoštene člane?

Peter Van Eeckhoutte: Ekipa Corelan ni nobena skrivnostna združba, vseeno pa to še ne pomeni, da se ji lahko pridruži kdorkoli. Ukvarjamo se namreč s potencialno občutljivimi podatki (0-day exploiti oz. svežimi varnostnimi luknjami), zato je potrebno spoštovati nekaj pravil in vrednot, ki so vsem članom ekipe zelo pomembna. Če bi v ekipo sprejeli vsakogar, bi te vrednote lahko zvodenele, tega pa nočem. Ena od naših najpomembnejših vrednot je izobraževanje, podajanje svojega znanja naprej in pomoč drugim ljudem. Če vas kaj muči, lahko skočite na naš forum in tam postavite svoje vprašanje, pa vam bomo poskušali pomagati (pa naj bo vprašanje še tako začetniško). Če pa vas zanimajo je 0-day vrzeli in hudi exploiti zanje, vas moram spet razočarati: po našem mnenju exploit ni najpomembnejši. Najpomembnejša je varnostna luknja. Exploit le pomaga prepričati ljudi, da se da varnostno luknjo izkoristiti, a kljub temu šteje le in samo varnostna luknja sama.

Da se vrnem nazaj na Corelan; v ekipi imamo kar precejšnje število članov. Težko je vzdrževati ravnotežje med manjšim številom članov (manj idej) in večjim številom (večje tveganje za neželeno razkritje). Če začutimo potrebo po novih članih, običajno spremljamo določene repozitorije, IRC kanale, spletne forume in podobno, ter skušamo na podlagi delovanja članov ugotoviti, kdo bi znal biti primeren za nas.

Kar pa se tiče nepoštenih članov, je situacija taka: ne moremo si privoščiti, da bi kdo širil interne informacije, ki še niso zrele za javnost, ali da bi prišlo do konflikta interesov. Celotna ekipa temelji na medsebojnem spoštovanju in zaupanju. Če kak član prekrši naše zaupanje, ga načeloma takoj vržemo ven. Po drugi strani pa sam močno verjamem v popravne izpite, tako da vsak incident obravnavamo posebej.

Slo-Tech: Je Corelan kdaj prodal kak svež hrošč preprodajalcem? Bi kdaj prodali razvpit 0-day exploit? Bi kdaj javno razkrili kako varnostno luknjo - če razvijalec ne bi pokazal nobenega zanimanja do njene odprave - če bi to ogrozilo veliko končnih uporabnikov?

Peter Van Eeckhoutte: Nikoli nismo prodajali informacij o varnostnih luknjah. Eden od razlogov za to je, da bi bilo zelo težko razdeliti denar med vse člane ekipe, ne da bi zaradi tega nastajale obsežne razprave, zaradi katerih bi znal kdo ekipo tudi zapustiti. Ni vredno. Spoštovanje, zaupanje, prijateljstvo so bolj pomembni in vredni veliko več. Ker v igri ni denarja, se lahko bolj osredotočimo na svoje lastne motive in vrednote.

Ljudje, ki prodajajo hrošče, me ne motijo - vsaj dokler tudi oni ne težijo meni zaradi mojih odgovornih razkritij :) Ko proizvajalca oz. razvijalca kontaktiramo glede varnostne luknje, mu skušamo nazorno predstaviti, da ta hrošč ogroža njihove stranke. Če to ne zaleže, nimamo nobenih zadržkov pred javnim razkritjem varnostne luknje. To se morda ne ujema popolnoma s konceptom odgovornega razkritja, vendar se res potrudimo pri prepričevanju odgovornih. Če pa jim ni mar za to, morajo to izvedeti tudi njihove stranke in se po lastni presoji odločiti za alternativno programsko opremo. Konec koncev je ta varnostna luknja v hekerskem podzemlju morda že znana - in če je ne razkrijemo mi, jo bo morda nekdo drug.

Slo-Tech: Verjamete v odgovorno razkritje? Se vam zdi, da je to tisto pravo?

Peter Van Eeckhoutte: Odgovorno razkrivanje je po mojem skromnem mnenju zelo pomembno. Kot sem omenil že prej, se mi zdi, da se moramo osredotočati na hrošče in ne na iskanje načinov za izkoriščanje hroščev. Corelan obstaja zato, da pomaga in programe dela bolj varne, ne pa zato, da bi ekipa pisala hude exploite in se z njimi bahala naokrog. Pri razkritju je tako - ne glede na vrsto razkritja - da je to vedno posledica dejstva, da v kodi že obstaja varnostna luknja, ki si jo odkril prav ti, raziskovalec. Če razvijalcem vsaj daš možnost, da varnostno luknjo odpravijo, preden javno objaviš podrobnosti, se mi zdi to pošteno. Če pa že vnaprej predvidevaš, da jim bo vseeno oz. da je ne bodo odpravili v nekem kratkem času, pa ne. Tega ne moreš zagotovo vedeti, če ne poskusiš in jim ne daš možnosti, da odgovorijo na tvoje opozorilo ter se lotijo odpravljanja težave. Seveda nihče ne more predvideti, kako se bodo razvijalci odzvali in ali bi se odpravljanja hrošča lotili hitreje, če bi bila varnostna luknja objavljena, ne da bi bili o tem prej obveščeni.

V bistvu pa to sploh ni važno, saj vem, da v 99,99 % primerov razvijalci z malce sreče kar sami popravijo varnostno luknjo. Žal pa pri obvestilu o hrošču skoraj nihče ne gre preverjat celotne izvorne kode. Če pa nikomur ne bi sporočili ničesar, pa prav zagotovo čisto nihče ne bi šel preverjat celotne izvorne kode. Poleg tega morda varnostne luknje tudi ne bi uspeli odpraviti, saj vsi razvijalci pač ne spremljajo mailing list za računalniško varnost. Če nič drugega, jim z neposrednim obvestilom damo vsaj možnost, da odpravijo varnostno luknjo, še preden jo kdo izkoristi (če je ni že). Tako kot mnogo ljudi tudi sam vsak dan uporabljam veliko bolj ali manj znanih aplikacij in pričakujem, da bodo njihove varnostne luknje zakrpane, še preden nekdo najde način, da jih izkoristi. Zato je po mojem odgovorno razkritje pošteno.

Kljub vsem razkritjem pa smo žal še svetlobna leta od rešitve bistva večine varnostnih lukenj. V programski opremi je prisotnih veliko hroščev, to je dejstvo - pa ne zato, ker bi jih programer tja vnesel namerno, temveč zato, ker morda ne zna pisati varne kode. Povedati hočem, da se situacija ne bo bistveno spremenila vse dotlej, dokler varno programiranje ne bo postalo del vsakega programerskega tečaja in programerske knjige.

Projekt OWASP (Open Web Application Security Project) si močno prizadeva za sodelovanje s šolami in drugimi institucijami. To je res fin projekt, ki si zasluži veliko spoštovanja in podpore. Vseeno pa še zdaleč nismo tam, kjer bi morali biti. Morda bi se morali raziskovalci računalniške varnosti povezati s podjetji, ki nudijo tečaje varnega programiranja, in to omeniti tudi v priporočilih, ki jih pošiljajo prodajalcem in razvijalcem. Namesto da hrošč samo odpravimo (to je seveda odvisno od narave hrošča), bi lahko razvijalcem povedali, da naj hrošč odpravijo in jim ponudimo možnost nadaljnjega izobraževanja iz varnega programiranja. To se dejansko sliši kar zanimivo - če bi kako podjetje rado na tak način sodelovalo s Corelanom, naj me kontaktira, pa se bomo dogovorili za nekakšno partnerstvo, ki bi pokrilo stroške našega spletnega strežnika in internetnega priključka :)

Slo-Tech: Corelan je nedavno razkril nekaj varnostnih lukenj, povezanih z obdelavo .zip datotek. Kako ste pravzaprav odkrili te hrošče?

Peter Van Eeckhoutte: Pravzaprav smo nanje naleteli precej po naključju. Eden od naših članov (mr_me) se ukvarja s proučevanjem datotečnih formatov in je med ukvarjanjem s formatom .zip ugotovil, da eno od polj v glavi (header field) kaže na velikost imena datoteke znotraj .zip datoteke. To polje v glavi je torej povečal na tako velikost, da ga operacijski sistem ni več prepoznal, popravil nekaj odmikov v formatu in v .zip datoteko pravzaprav stlačil zelo dolgo ime datoteke. Prav neverjetno je bilo videti, koliko programov za obdelavo .zip datotek se je ob tem preprosto zrušilo. Večina velikih, priznanih aplikacij je sicer preživela, ogromno število drugih programov pa ne.

Slo-Tech: Se vam zdi, da je hrošče lažje najti s statično analizo oz. prečesavanjem izvorne kode, ali z dinamično analizo in naključnim preizkušanjem (fuzzing)?

Peter Van Eeckhoutte: Nobena od teh dveh tehnik ni enostavnejša od druge. Če bi obstajalo orodje, ki bi omogočalo znatno enostavnejšo uporabo določenega pristopa, bi ga začelo uporabljati več ljudi in posledično bi se zmanjšalo število odkritih hroščev, saj bi tudi proizvajalci začeli uporabljati enako orodje za iskanje in odpravljanje hroščev. Obstajajo sicer določena orodja, ki poenostavijo naključno preizkušanje, a se uspešnost odkrivanja hroščev sčasoma lahko zniža.

Izvorna koda ni vedno dosegljiva, sploh pri večini komercialnih aplikacij. In tudi če je na voljo, je analiziranje kode lahko zelo zahtevna naloga. Varnostnih lukenj ni težko spregledati. Z 200-vrstično kodo se lahko ukvarjaš cel dan, da v njej najdeš pomanjkljivost. In tudi če po vsem tem misliš, da je z izvorno kodo vse v redu, lahko vanjo vnese varnostno luknjo tudi prevajalnik, pa si spet pogorel. Je pa res, da če imaš dostop do izvorne kode in je v njej hrošč, ga boš z dovolj truda tudi našel. Uspeh zagotovljen.

Obratni inženiring aplikacij ali popravkov zanje predstavlja še enega od možnih pristopov, a podobno kot analiziranje izvorne kode tudi ta zahteva mojstrsko poznavanje mnogih tehnik in jezikov, preden v kodi lahko začneš iskati hrošče. Tudi ta pristop je zahteven, a daje rezultate.

Zadnje čase se veliko govori okrog naključnega preizkušanja. Nekateri trdijo, da naključno preizkušanje na slepo (dumb fuzzing) ni več učinkovito - kljub temu pa še danes z le nekaj vrsticami kode odkrivamo velike hrošče v velikih aplikacijah. Drugi zagovarjajo pametno naključno preizkušanje (smart fuzzing), pri katerem moraš dobro poznati datotečni format oz. mrežni protokol in se igrati s polji, biti in vrednostmi, da vidiš, kako se na to odzove aplikacija. Tudi ta pristop deluje. Seveda moraš tudi pri tem najprej ugotoviti, kako delujejo določeni formati oz. protokoli, morda moraš sprogramirati lastno orodje za naključno preizkušanje, ali pa za to uporabiti pogosto zelo kompleksna programska ogrodja. Ta pristop pogosto prinaša boljše rezultate od naključnega preizkušanja na slepo. Veliko aplikacij že zdaj dobro prenaša vnos naključnih podatkov, a to še vedno ne pomeni, da ne bodo pokleknile pred vnosom točno določenih podatkov v točno določena polja. Ta pristop je verjetno bolj uspešen od naključnega preizkušanja na slepo.

Novejše tehnike obsegajo kombinacijo statične analize, osamitve zanimivih funkcij in iskanja šibkih točk v programu s pomočjo naključnih permutacij pomnilnika (in-memory-fuzzing using data tainting). Slišati je zapleteno, in tudi je, saj pot do rešitve niti slučajno ni enostavna. Rešitev te dileme bom prepustil strokovnjakom za fuzzing, saj še ni jasno, ali ta teorija sploh prinaša uporabne rezultate. Vse te tehnike pa zahtevajo zelo specifična znanja ter veliko časa in predanosti. "Hekanje" se morda sliši zabavno, a je v resnici zahteven in časovno potraten posel, otroci.

V Corelanu uporabljamo kombinacijo slepega in pametnega naključnega preizkušanja, pa tudi analiziranje izvorne kode. Trenutno nimamo dovolj strokovnjakov za obratni inženiring, zato hrošče lovimo v glavnem le s temi tremi tehnikami. Za to je na voljo mnogo orodij, relativno enostavno pa je tudi spisati lastna orodja, če so potrebna.

Slo-Tech: Aprila ste se udeležili konference BlackHatEU v Barceloni. Nam lahko orišete, kako poteka taka konferenca? So bile tam razkrite kake nove tehnike za izkoriščanje varnostnih lukenj?

Peter Van Eeckhoutte: Konference BlackHat ponujajo res dobro kombinacijo visoko specializiranih ter tehnično podrobnih predavanj. Letošnja konferenca je imela po tri predavanja hkrati (lani sta hkrati potekali po dve predavanji), tako da se je bilo težje odločiti, česa se boš udeležil, hkrati pa so se predavatelji lahko bolj poglobili v svojo temo. Najbolj všeč mi je bilo vzdušje, ki je vladalo na konferenci. Poleg tega, da tam srečaš ljudi, s katerimi si bil čez leto le v elektronskem stiku, sem bil (znova) prijetno presenečen, da so ljudje svoje ege (vsaj tisti, ki so imeli prevelike) pustili doma in da so bili vsi prijazni, sproščeni ter pripravljeni na pogovore. To se mi je zdelo res fino.

Nekaj predavanj je bilo posvečenih tudi (novim) tehnikam za izkoriščanje varnostnih lukenj:

• Clickjacking (uporabnik misli, da klikne na en element, v resnici pa klikne na drugega, ki je skrit pod prvim).
• Oracle padding napad
• Universal XSS (cross-scripting) napad
• Oracle MITM (man-in-the-middle) napad

Všeč mi je bilo tudi predavanje o tem, kako Adobe upravlja s kopico (heap management), prav v svojo kategorijo pa je sodilo predavanje Felixa "FX" Lindnerja o pomanjkljivostih Adobovega flash formata. Zdaj se bo morda našlo več ljudi, ki bodo ponujali dobre oz. strukturne rešitve za določene varnostne luknje.


Kot sem omenil že prej, nas čaka še precej dela, preden bodo hrošči odpravljeni. Namesto da samo pritiskamo na proizvajalce in razvijalce, bi morali pritiskati nanje in hkrati začeti razmišljati o generičnih varnostnih mehanizmih. Vem, da bo to svet obrnilo na glavo, a je na dolgi rok to morda edina rešitev.

Slo-Tech: Škoda bi bilo, če bi se vaši vodniki na neizmernem spletu izgubili. Imate kakšne načrte, da bi jih izdali tudi v papirni obliki? Boste kmalu napisali kakšen nov vodnik?

Peter Van Eeckhoutte: Eden od mojih ciljev za leti 2010 in 2011 je prenova mojih vodnikov, v katere bom vključil novejše tehnike, nato pa jih bom poskusil ponuditi tudi v papirni obliki. Še preden pa se lotim tega, moram dokončati svoje delo na izkoriščanju varnostnih lukenj v Win32, ki vključujejo prekoračitve kopice in izkoriščanje povratka iz funkcij. Toliko dela, pa tako malo časa! :)

Slo-Tech: Kaj bi svetovali ljudem, ki se lotevajo raziskovanja računalniške varnosti?

Peter Van Eeckhoutte:

• Najprej se naučite, kako stvari delujejo, preden se naučite, kako se jih da pokvariti.
• Bodite pripravljeni, da boste v to morali vložiti ogromno časa. Bodite osredotočeni in ne vdajte se.
• Začnite od začetka in pri osnovah. Nikar se ne poskušajte potapljati, če še plavati ne znate.
• Ob pravem času postavljajte prava vprašanja.

Zadnje čase smo videli nekaj res zanimivih tehnik (izkoriščanje povratka iz funkcij, razprševanje kopice oz. heap spraying, itd.), a tega nikar ne poskušajte sami, če se ne spoznate na izkoriščanje varnostnih lukenj. Sprejmite dejstvo, da se morate najprej naučiti osnov, pa boste nekoč dosegli tudi napredne trike. Če povem drugače: če ne veste, kako v osnovi deluje prekoračitev medpomnilnika, se nikar ne lotevajte razprševanja kopice.

Slo-Tech: Pa še klasično vprašanje za na konec: ima Corelan v svojem repozitoriju kakšen 0-day exploit in ali nam lahko zaupate kaj več o njem? :)

Peter Van Eeckhoutte: Na zalogi imamo kar nekaj 0-day exploitov, a če vam jih izdam, ne bodo več tako zelo 0-day :)


Petru Van Eeckhouttu se zahvaljujemo za intervju.