Hlavní navigace

Názory k článku Bezpečnostní střípky za 32. týden roku 2006

  • Článek je starý, nové názory již nelze přidávat.
  • 14. 8. 2006 16:38

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    Guess what is going to paged now… some unused drivers :) [...]
    We need to ask kernel to be kind enough and execute our driver’s routine (whose code we have just replaced in pagefile)

    LOOOL :-D

    "Getting the real time" :-)

    SVMCHECK

    V podstate obdoba HMAC.

    Ad. nedetekovatelnost: aby bol VMM rootkit uzitocny pre vzdialeneho utocnika, musi s nim nejak komunikovat, tj. zvonka budu vidiet pakety (napr. na switchi/routeri), ktore tam nemaju byt (aj ked zase, ked som sa parkrat pozrel co Win dokaze vygenerovat za pakety, tak mi prislo, ze ich tam aspon polka nema byt ;-)). Jedina nedetekovatelnost je, ze by sa utocnik stal pocitacom a rozkazoval mu, ale to zase nepotrebuje VMM rootkit ;-]

  • 14. 8. 2006 16:51

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    Viz. http://technology.guardian.co.uk/news/story/0,,1838751,00.html

    (a ze to neni jedina sprava svojho druhu, oni odvodzuju sifrovacie kluce zo strasne malej mnoziny, ako napr. rodne cislo, atd. Skuste vysvetlit colnikovi, ze vam hackli pas, ked je presvedceny, ze je "bezpecny".) Plus maju v tych cipoch byt zabudovane nejake PRNG, aby response bola vzdy "ina", ale presny popis cipu som nevidel. No ked to dokaze precitat "spravna masinka", tak urcite to dokaze nejaka "fake masinka", je otazkou casu kedy ju postavia ;-)

    Inak casom (tyzden, dva, mesiac...) by sa mali objavit nejake videa a prepisy zo seminara "Cestovani a ochrana soukromi" (organizovali http://www.IuRe.org, http://www.FoeBuD.org a ini), kde sa preberali oi. nove biometricke pasy v CR.
  • 18. 8. 2006 11:35

    shadow (neregistrovaný)
    K tomu článku na guardian.co.uk - viz taky originální článek na http://www.wired.com/news/technology/0,71521-0.html?tw=wn_index_8.
    Tam se dočtete, že ten německý "expert" naklonoval svůj vlastní (německý) e-pas, který proti tomu není nijak chráněn. Dále Lukas Grunwald je opravdu odborník z nejpovolanějších - zabýval se touto problematikou 14 dní, měl asi chlapec studovat o trošku déle, třeba by se někde dočetl, že podle mezinárodních standardů je ochrana proti klonování volitelná a Německo ji ve svých e-pasech nepoužívá. Opravdu úspěch!!!
    A ještě poslední poznámka - sice si svůj e-pas naklonoval, ale pouze 1:1, nemohl v něm změnit žádný údaj, jinak by porušil elektronický podpis. K čemu by pak případnému útočníkovi taková věrná kopie byla e-pasu, když si jí nemůže upravit pro svou potřebu????
    Dále v textu pletete dohromady hrušky s jablkama - máte zřejmě na mysli šifrovací klíče, které slouží k šifrování komunikace mezi čipem a čtečkou a které se opravdu odvozují z určité omezené množiny informací. To ale nijak nesouvisí s elektronickým podpisem údajů uložených v čipu, který zajišťuje integritu (a neměnnost) údajů - tento podpis vystavuje důvěryhodná organizace (vydavatel e-pasu) a je založen na PKI (asymetrická kryptografie, dostatečně dlouhé klíče, ...).
    Přesný popis čipu ani nikdy neuvidíte, pochybuji, že by výrobci dali svůj know-how veřejně k dispozici. Proč by to dělali???
  • 15. 8. 2006 13:25

    who cares (neregistrovaný)
    nerozumis smyslu rootkitu - tady nejde o komunikaci s okolim
    problemem pilulky ze virtualizace os
    1)je slozita (viz Xen)
    2)vzdy zpomaluje - z principu JE detekovatelna
    s virtualizaci prichazi "atestace" a to je zajimavejsi (napr http://www.jesusmolina.com/TCGblog/archives/7)
  • 15. 8. 2006 15:24

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    Neboj, viem co je rootkit :-) Rootkit skryva procesy/subory/network connectiony atd. Ale naco je dobry rootkit, ktory sice je rootkit ale nic ine nerobi?

    1) jasne
    2) spomaluje o kolko... to je prave ta sranda. V tom paperi je pisane, ze rootkit moze v pohode ovplyvnit TSC aj RTC => napr. RDTSC instrukcia moc nepomoze a hodinkami sa to mera blbo. Nicmene je pravda, ze dostatocne jemnym meranim by sa dal urcite zistit. Existuje este kopa trikov - emulacia IOMMU, trap interrupt, atd.

    Njn, trusted computing. Ak sa to vymkne z ruk, tak uz ziadny Linux uz nespustime (nepredpokladam, ze by sa tak stalo). Digitalne podpisy (a la DSA) su prilis zlozite na zapis do kratkej (E(P))ROM, ak sa spravne pamatam, tak sa na to chcela pouzit obdoba HMAC.
  • 15. 8. 2006 16:46

    who cares (neregistrovaný)
    "Ale naco je dobry rootkit, ktory sice je rootkit ale nic ine nerobi?" - to ma tak vypadat ze nic nerobi ;) ve skutecnosti treba kontroluje jestli neripujes mp3, to zalezi pripad od pripadu

    "hodinkami sa to mera blbo"
    proc? proste udelas ulohu ktera bezi treba hodinu

    muzes nejak rozvest tu detekci pilulky pomoci trap interruptu?
  • 15. 8. 2006 22:11

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    "to ma tak vypadat ze nic nerobi ;) ve skutecnosti treba kontroluje jestli neripujes mp3, to zalezi pripad od pripadu"
    OK, moze byt, v tom pripade sa pri ripovanie prezradi :-) Bud to musi poslat po sieti alebo niekde ulozit. Samozrejme user si nic nemusi vsimnut ak to napr. nasype na nejake obskurne miesto na HDD/FS.

    "proc? proste udelas ulohu ktera bezi treba hodinu"
    To je sice mozne, ale pri takom dlhom case sa do merania zacnu hrabat obsluhy IRQ, obsluhy pagefaultov, atd., takze meranie bude hodne skreslene - zavisi, kolko CPU casu sa stravi na vykonavani rootkitu v porovnani s ostatnym kodom. Nehovorim samozrejme, ze sa to detekovat neda, len ze je to fakt obtiazne.

    "muzes nejak rozvest tu detekci pilulky pomoci trap interruptu?"
    Tym som myslel skor prevenciu spustenia rootkitu, takto:

    Detektor si nahodi trap flag a zavesi svoj handler na trap interrupt. Pri kazdej vykonavanej instrukcii detektor porovna instrukciu oproti IOMMU instrukciam. Ak sa spravne pamatam zo specifikacie IOMMU, tak IOMMU prikazy su proste MOV (resp. iny pamatovy presun) na urcitu adresu. Detektor by sledoval taketo instrukcie a pripadne zarval alebo zakilloval proces. Nie je to bohvieako casovo efektivne. Ale samotne IOMMU drzi log vykonanych IOMMU instrukcii a je mozne nastavit nejaky interrupt pri zavolani IOMMU instrukcie (co by bola efektivnejsia prevencia).

    Ked je uz rootkit zavedeny, tak trap interrupt uz asi moc nepomoze, pretoze je v inom VM kontexte nez rootkit. Aj ked mozno by fungovalo pocitanie instrukcii via trap interrupt (trapny INC nejakeho countera). Neviem presne ako procesor spracovava instrukcie viacerych VM (ci napr. spustenie instrukcii na jednom VM spomali druhy VM, ono to nejak suvisi s afinitou, ale az tak dobre sa v tych novych procesoroch nevyznam). Pocitanim cez trap interrupt by sa napr. vylucili obsluhy inych preruseni (pagefault, IRQ), pretoze vtedy su prerusenia zakazane (az na nemaskovatelne prerusenia, double fault exception, general protection fault, plus mozno este nejake).

    Ten trik s trap interruptom som prvykrat videl hrozne davno v nejakom DOSovom polymorfnom vire (nazov si uz nepamatam), ten pouzival trap interrupt, aby mohol mat polymorfny kod v pamati. Samotny kod obsluhy trap interruptu bol polymorfny pri zavedeni, napr. ADD AL,0x10 vymenil za SUB AL,0xF0. Nejake neskorsie varianty menili aj kod trap interruptu za behu. Potom doslo Pentium so spekulativnym vykonavanim instrukcii a tie viry to rozbilo ;-) pretoze stary kod bol este nacachovany v cache procesoru a zmena RAM sa neprejavila v zmene cache hned. Virus writeri si tusim pomohli long jumpom, ktory flushol cache procesoru.

    IMHO je lepsia prevencia (napr. sledovanie IOMMU) nez neskorsia detekcia. Autor rootkitu moze do kodu pridat detekciu trebars toho trap interrupt kodu, alebo TF vypnut vnutri nejakeho prerusenia (zmenou flagov na zasobniku, takze pri IRET sa loadnu flagy s vypnutym TF). To je ta nekonecne vojna virov s antivirmi ;-)

    No inak ked ste spomenuli to ripovanie mp3, tak ma hned napadlo, ze Win ten rootkit zavedie hned pri starte :-D
  • 15. 8. 2006 22:48

    who cares (neregistrovaný)
    neni jednodussi prevence spusteni rootkitu disablovat virtualizaci v biosu?

    ad zkresleni mereni - neni pravda, nektere veci trvaji VM mnohem dele (napr. velka iterace rdtsc - pokud ji rootkit musi pokazde zmenit), a pak to jiz obtizne neni

    verim ze se objevi kupa dalsich metod jak zjistit tenhle druh rootkitu, rozhodne neni 100% undetectable ;)

    btw sranda jsou taky bios rootkity - ty preziji reinstal - jen nevim jestli uz je neco takoveho "in the wild" (cemu pak ma clovek verit kdyz ne biosu? :)
  • 16. 8. 2006 12:44

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    ad zkresleni mereni - neni pravda, nektere veci trvaji VM mnohem dele (napr. velka iterace rdtsc - pokud ji rootkit musi pokazde zmenit), a pak to jiz obtizne neni
    verim ze se objevi kupa dalsich metod jak zjistit tenhle druh rootkitu, rozhodne neni 100% undetectable ;)

    Jasne, ked vam niekto nemeni kod rootkitu pod nohami, tak sa detekovat urcite da :-) Inak TSC sa nezdiela medzi VM, tj. kazda VM ma vlastny TSC, nie?

    btw sranda jsou taky bios rootkity - ty preziji reinstal - jen nevim jestli uz je neco takoveho "in the wild" (cemu pak ma clovek verit kdyz ne biosu? :)

    Nebol by som si isty, ci sa da verit biosu v prvom rade ;-) Vsetci pozname jak existovali (existuju?) univerzalne BIOS hesla, atd. Raz som mal 60 GB IBM disk a staru dosku, ktorej bios nechcel zrat disky > 32 GB, nainstaloval som si taku IBM utilitku (ontrack tusim), aby to bios rozdychal. Predal som komp po case, ale toho ontracku sa neslo ani za boha zbavit. dd if=/dev/zero of=/dev/hda a nic ;-] Ono to bolo skryte v nejakej divnej casti disku, asi HPA alebo nejakej EPROMke.

    Ad bios rootkity: keby si mam tipnut, tak par ich uz beha in the wild. Existuje aj jeden projekt flashovania biosu orezanym linuxom, potom sa tam da ssh-cknut a nastavovat bios na dialku (jeden clovek to potreboval aby nemusel cluster obletovat s klavesnicou). Je tam vycet nejakych dosiek, ktore su podporovane.

    O kvalite biosoveho kodu obecne si ziadne iluzie nerobim, videl som uz par "podivnych dosiek". Raz som skusal pisat vlastny extender (za cias dosu) a skoncil som prave pri volani biosovskych rutin via virtual 8086 mode. Odtial sa mi to zdala uz taka prasarna, ze som radsej isiel kodit nieco ine, ale hlavne ze som tam mal pekne komentare, hehe :-0 Nastastie z hier sa dal vysekavat DOS/4GW, DOS/16M a potom sa objavil aj PMODE/W, to bol skvely a konfigurovatelny extender.

    Ja som k doske dostal take PCI (?) blikatko, ktore diagnostikuje LED-kami POST error kody, mozno by sa to dalo prepajkovat, aby to hovorilo viac. Urcite tomu by som veril viac nez co mi ukazuje bios :-)

  • 16. 8. 2006 19:08

    who cares (neregistrovaný)
    "Jasne, ked vam niekto nemeni kod rootkitu pod nohami, tak sa detekovat urcite da :-) Inak TSC sa nezdiela medzi VM, tj. kazda VM ma vlastny TSC, nie?"
    pokud mluvim o detekci pilulky, tak je jedno jestli se kod meni, zpomalovat z principu bude porad - a s tim casovanim: vice o metode pise bugcheck na rootkit.com

    a jeste k tem biosum: experti se hadaji, jestli se da vetsina biosu flashovat - jedni rikaji ze ano, druzi ze ne. co si o tom myslite?

    bios kod pry nebyl pro kazdeho, ale acpi uz je high-level
  • 17. 8. 2006 2:14

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    "pokud mluvim o detekci pilulky, tak je jedno jestli se kod meni, zpomalovat z principu bude porad - a s tim casovanim: vice o metode pise bugcheck na rootkit.com"

    Tvrdim, ze ked vam meni kod zivy clovek pod nohami a je dostatocne (nekonecne) rychly, tak nemate takmer sancu rootkit zistit. Pripadne sa mozme porozpravat o detailoch pri pive :-) Zpomalovat urcite bude, to je jasne, pointa je, ako to merat. Mail \nahodnybordel ondrej \dalsinahodnybordel \tecka \ziadnyescapevynechajpodtrzitko_mikle \zavinac \blabla_vynechaj_blabla_gmail.com (sorry, ale boti). Som vacsinu casu v Pha.

    "a jeste k tem biosum: experti se hadaji, jestli se da vetsina biosu flashovat - jedni rikaji ze ano, druzi ze ne. co si o tom myslite?"
    Zavisi, ako definujete "vacsinu biosov". Viem, ze od cca Pentia 90 sa cez 'REP OUTSB' nasypanim nul na port CMOS dala CMOS uplne zblbnut. Raz si tak jeden typek (znamy) skoro usmazil CPU ;-) Ak existuju updaty k BIOSu danej dosky, tak sa urcite flashovat vlastnym kodom da, vacsinou ide o i686 instrukcie.
  • 17. 8. 2006 2:16

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    BTW, rootkit.com som si pozeral este nez J. Rutkowska zverejnila podrobne pdf o BluePill.
  • 16. 8. 2006 12:49

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    "neni jednodussi prevence spusteni rootkitu disablovat virtualizaci v biosu?"

    No urcite je, ale keby mam ten procesor, tak by som aj vedel vyuzit vyhody virtualizacie. Minimalne na take uchylne experimenty, ze pustit si 2 OS (trebars Linux a FreeBSD), v jednom si spustit nejaku GUI X app, pretunelovat cez localhost (tu virtualnu sietovku) X forwarding a chvilu sa tym bavit *-)
  • 16. 8. 2006 13:57

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    Jasne, Xen znam, mne sa akurat paci predstava, ze to bezi priamo v zeleze :-)
  • 16. 8. 2006 13:59

    su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
    Tych Virtualizakov je cela kopa, vlastne kazdy "emulator" - od dosboxu cez wine cez xen/vmware cez userland linux (...fuse, zx spectrum/amiga/... emulator) az po to Virtualizaka Zelezneho ;-]
  • 23. 8. 2016 11:59

    Nikdo (neregistrovaný) ---.iinfo.cz

    Lorem ipsum