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

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

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.

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

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)

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.

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

"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

Lorem ipsum