Dotaz na zkušeného hackera či programátora

[jaojao]

Postižení touto nákazou asi moc nejásají http://en.wikipedia.org/wiki/TDL-4
(Přes 4.5 milión strojů byly infikováno v prvních třech měsících roku 2011....)

[Reklama]

[qcp]

Jak to tak ctu, tak infikovat mbr, bootblock apod. - To je prece zaklad uz od dob prvnich pocitacu... Jeste kdyz byly magnetofonove packy :-) potom to preslo na diskety, bootblock amiga, atari, msdos a ted zase mbr :-)

Ale kdo spustil ten rundl nebo zapsal o registru?

Ty. Tím, že jsi klikl na odkaz na nějakém pornu, nebo warezu.

pockej, to je prece blbost, abych klikl na odkaz a ten vykonal kod v mem pocitaci, to jsem si myslel, ze uz tak snadno nejde resp. poslednich 15 let proti tomu prece hlavne MS zaplatuje :-)

ze se tam natahne cosi do temp, to chapu, ale ze se to i rovnou spusti??? To mas vyzkousene a potvrzene nebo spekulujes?

[qcp]

TDL4 to je naprostá genialita. Evidentně to dělal profík/ci. Jeden kousek mám někde doma. Mám to místo porna
Základ je ale postavený na převratném nápadu Dereka Soedera Ryana Permeha (eEye BootRoot), aktivovat rootkit ještě před startem Windows a zavést do něj ovladač ještě před úplnou inicializací jádra.
Prostě paráda.

takhle pracuje spousta softu, truecrypt a spol, na sifrovanem disku s OS, take musi zavest driver vlastne jeste pred startem OS a i pred startem ntoskrnl nebo co se to vubec jako prvni dnes spousti a take muze prevzit heslo a klice z usb key atp...

Je mi jasne, ze na naprogramovani tohoto jsou potrebne urcite vyssi znalosti nizsich jazyku, akorat mi neni jasne, proc by i pak nemohl antivirak detekovat struktury v pameti ci na disku, vysvetli nekdo? Jak se muze ten rootkit zamaskovat, aby se na nej neslo dostat, byl neviditelny?

[Uziv00]

pockej, to je prece blbost, abych klikl na odkaz a ten vykonal kod v mem pocitaci, to jsem si myslel, ze uz tak snadno nejde resp. poslednich 15 let proti tomu prece hlavne MS zaplatuje :-)

Záplatuje, ale moc se mu to nedaří. Vždycky někdo najde další díru. A než se vytvoří další záplata, tak to nějakou dobu trvá.

[MiliNess]

Jak se muze ten rootkit zamaskovat, aby se na nej neslo dostat, byl neviditelny?

takhle pracuje spousta softu, truecrypt a spol, na sifrovanem disku s OS, take musi zavest driver vlastne jeste pred startem OS a i pred startem ntoskrnl nebo co se to vubec jako prvni dnes spousti a take muze prevzit heslo a klice z usb key atp...

Takhle daleko ale žádný soft před startem a při startu systému nezasahuje. (si zapal cígo, zase bude román)
TDL4 přepíše zaváděcí kód v MBR sektoru svým vlastním, který obsahuje dešifrovací smyčku a zašifrovaný kód, jehož hlavním úkolem je odskočit do sektoru někde na konci disku, kde má rootkit umístěn svůj vlastní oddíl s jednoduchým šifrovaným souborovým systémem (tam jsou umístěny všechny součásti rootkitu) a spustit speciální 16bitový zavaděč ldr16, jehož úkolem je hahákovat obsluhu přerušení INT13 BIOSu. Má tedy při zavádění Windows plnou kontrolu nad kopírováním systémových modulů do paměti.
Při zapnutí PC spustí zavaděč BIOSu upravený zaváděcí kód v MBR, ten se dešifruje, najde, nahraje do paměti a spustí ldr16, který zahákuje INT13 a vrátí řízení původnímu kódu z MBR, který má rootkit zazálohovaný ve svém šifrovaném oddílu. Ten dokončí svůj původní úkol - vyhledá aktivní oddíl, nahraje a spustí zavaděč svazku (VBR bootstrap), který zase nahraje a spustí bootmgr a ten spustí zavaděč OS Winload.exe (u XP místo bootmgr a winload.exe pouze ntldr). V této době už má ale rootkit díky háku na INT13 pod kontrolou všechny diskové operace.
Když winload.exe (ntldr) načítá do paměti moduly operačního systému, rootkit prohledává načítaná data z diskových sektorů a číhá na za normálních okolností docela nepotřebnou dynamickou knihovnu kdcom.dll (používanou při ladění systému). Jakmile zjistí, že je načítána do paměti, začne místo jejího kódu do paměti kopírovat kód svého 32/64bitového zavaděče ldr32/ldr64 (další komponenta skrytá v jeho šifrovaném oddílu). Zjistí o jaký systém se jedná a podle toho použije buď 32 bitový nebo 64 bitový zavaděč.
U Win Vista a výše navíc upravuje v paměti obraz BCD souboru, kde přenastavením jedné hodnoty vypne ověřování digitálního podpisu kdcom.dll. Po natažení modulu kdcom.dll je ověřování podpisů opět aktivováno. Na oko to tedy vypadá, že je v paměti digitálně podepsaná kdcom.dll, místo ní je tam ale úplně jiný modul.
Jak původní kdcom.dll, tak zavaděč rootkitu ldr32/ldr64, kterým je nahrazena, exportují stejné funkce. Jádro v první fázi inicializace systému automaticky volá funkci KdDebuggerInitialize1 z kdcom.dll. Zavolána je tedy automaticky KdDebuggerInitialize1 ldr23/ldr64, čímž je zajištěno spuštění loaderu a navíc je takto zabráněno ladění jádra, kdyby se někdo rozhodl podívat se z jiného počítače na start infikovaných Windows, protože dubugovací funkce v ldr32/ldr64 postrádají funkčnost původních z kdcom.dll.
Zavaděč ldr32/ldr64 slouží především k tomu, aby speciálním způsobem natáhl a spustil 32/64 bitový ovladač drv32/drv64 (opět podle verze systému), sloužící pro skrytí rootkitu, pro zajištění přístupu ke svému šifrovanému souborovému systému a také se stará o injektování své dynamické knihovny cmd.dll/cmd64.dll do každého procesu.
Ovladač drv32/drv64 zahákuje objekt zařízení fyzického disku, čímž opět kontroluje přístup k disku. Nyní již ne prostřednictvím INT13, ale tak, že se napíchne mezi ostatní ovladače, které spolupracují při vyřizování diskových operacích. Pokud někdo vznese požadavek na čtení obsahu infikovaného MBR sektoru, požadavek je rootkitem zachycen a ten místo obsahu infikovaného MBR sektoru vrátí obsah zazálohovaného čistého sektoru, kterou si při infikování udělal ve svém šifrovaném oddílu. Stejně tak skrývá svůj speciální oddíl na konci disku. Když bude zachycen pokus o čtení z této části disku, nebudou vrácena žádná data a vypadá to, že je místo prázdné.
Zahákování disku u TDL4 je provedeno na velmi nízké úrovni (ovladač portu disku), proto musí mít antivir vlastní metodu ke čtení diskových sektorů a nespoléhat se na infikovaný operační systém. Jinak obyčejný přepis zavaděče v MBR sektoru např. z Live CD nebo bootovací flešky, rootkit zlikviduje. Sice jeho komponenty zůstanou schované na disku, nemají se ale jak spustit. Leda by byl rootkit doplněn modulem spouštějícím se po startu počítače, který by se staral o novou infekci MBR.
Dynamická knihovna cmd.dll/cmd64.dll injektovaná do procesů může provádět libovolné kravinky. Obstarává např. vzdálené řízení rootkitu, může implementovat vzdálenou správu počítače (připojení do botnetu), zajistit aktualizaci rootkitu (rozšíření či změnu funkčnosti), vyhazovat reklamní okna, krást data, hesla, piny, stahovat a instalovat jiný malware, prakticky cokoliv. Defaultně injektovaná knihovna cmd.dll/cmd64.dll zvládá tyto vzdálené příkazy:
-stáhnout zašifrovaný soubor
-stáhnout a spustit soubor
-stáhnout zašifrovaný soubor, dešifrovat a spustit ho
-stáhnout nešifrovaný soubor
-zapisovat do svého konfiguračního souboru v šifrovaném oddílu
Tyhle funkce rootkitu stačí, aby si z netu stáhl novou verzi jakékoli své komponenty, pokud třeba autor objeví chybu v kódu, která by vedla k jeho odhalení a pod. Rootkit prostě běží v režimu jádra a je pánem počítače. Největší nebezpečí spočívá v tom, že pokud ho napíše profík a vymazlí si ho, uživatel se o infekci jen tak nedozví. V jeho zájmu je, co nejlépe se zamaskovat. Instalátor TDL4 jsem našel třeba v jednom keygenerátoru a díky slabině v systému nepotřebuje k instalaci rootkitu ani práva správce. A i kdyby, spousta uživatelů mu ta práva ochotně zapůjčí

Co se týká rootkitů, existuje spousta maskovacích technik. Např. hákování systémových služeb, objektů přerušení, tabulky deskriptorů přerušení, objektů jádra, úprava různých datových struktur a seznamů (např. seznam procesů) atd. Na 64 bitových systémech už je jich ale mnoho nepoužitelných, díky Kernel Patch Protection (PatchGuard) který hlídá integritu takových slabých míst.
TDL4 se ale PatchGuardu úspěšně vyhýbá a navíc elegantně obešel kontrolu digitálního podpisu ovladače. Zajímavý je na něm způsob spouštění a obcházení kontroly digitálního podpisu.

[akem]

Milinessi trošičku se Tě začínám bát...

[Uziv00]

Mazeec
Ale pokud můžu, zeptal bych se:
- kdysi dávno antiviry zmiňovaný INT13 hlídaly. Dokonce i pod DOSem. To už se dnes neděje?

[Wordstar14]

Ak este stale skumas "JAK", tak tu mas k tomu studijny material:
http://www.sba-research.org/wp-content/ ... d_2009.pdf

To co tu spominate su veci spred 25 rokov.
V odkazovanom materiale je dobre nastudovat aj suvisiace veci v zozname literatury na konci.

[qcp]

Wordstar14, to je stejně 3 roky starý a moc hutný na mě, nějaký výcuc by nebyl?

MiliNess, nekouřím, no děkuji za podrobný popis, kde jsi tohle našel? Na vytvoření neviditelné partition musí být také nějaký sofistikovaný způsob a nástroje na správu disku myslím by méohly zdetekovat gap (prázdné neviditelné místo. Pokud není alokováno standardním způsobem, lze přes něj vytvořit partišn a tím to máznout.

Další věc je, ten proces cmd, ten se spouští ze systému anebo z té partišn? Ptám se proto, že porovnat checksum (délku) s neinfikovanými verzemi by neměl být problém, OVŠEM POKUD JE V PAMĚTI NĚCO JINÉHO JAK NA DISKU...

------

tak switchneme tuhle diskusi na to, jak odhalit takové svinstva...

A já se musím posypat popel na hlavu, protože jsem zjistil oproti mému tvrzení v začátku vlákna, že mi v systému běží AVG viz příloha... asi tato obluda mi zpomaluje systém? Je ukrutně pomalý a jsem líný na reinstalaci, tak zvažuji, co bude efektivnější, zda čištění nebo reinstall... Takže je novou otázkou, jak je možné, že svinstvo "FBI" ze začátku tohoto vlákna se dovedlo spustit i přes AVG.

Linkněte mi někdo nějaký sofistikovanější monitor síťové aktivity ...

[Wordstar14]

No ved prave, to je uz vycuc z konferencii a materialov ludi zaoberajucich sa problematikou ako sa spusti kod z prehliadanej web stranky.

Neviem, ty chces este vycuc z vycucu ?
To jen nieco ako:
Mam v mojej banke pod tymto cislom ukryty poklad pozostavajuci zo zlata
Vycuc z toho by znel:
V niektorej banke je zlato.

[Wordstar14]

A nezabudni, ze MS kupil zhruba pred dvomi rokmi technologiu na streamovanie vzdialeneho uloziska, ktora sa momentalne testuje vo Win8.
Win9 (pripadne az Win10) sa uz nebude spustat z lokalneho media, ale zo servera v Microsofte. Ci to bude technologia, ktora pomoze odstranit zakerne aktivity na mizerne naprogramovanom OS ukaze cas. Jedeni co sa vie dopredu je to, ze legalita OS bude zarucena.

[MiliNess]

kdysi dávno antiviry zmiňovaný INT13 hlídaly. Dokonce i pod DOSem. To už se dnes neděje

Služby BIOSu se používají pouze v ranné fázi zavádění systému, kdy CPU běží v 16bitovém režimu. Služby BIOSu se dají volat pouze v reálném módu procesoru. V reálném módu se vykonávají pouze oba zavaděče a kousek loaderu. Loader brzy přepíná procesor do protected modu, pokud pak potřebuje volat některou službu BIOSu (včetně INT13) musí přepnou procesor zpět do reálného módu, což není moc efektivní způsob.
Po inicializaci jádra a HALu tedy přístup k disku začnou zajišťovat právě tyto dvě komponenty v součinnosti s dalšími ovladači a INT13 už si neškrtne. V době kdy by INT13 bylo třeba hlídat, ještě žádný antivir neexistuje. Neexistuje ani operační systém, ten se teprve staví. Případný antivir by musel používat podobnou techniku jako rootkit.
Ono by bylo všechno jednodušší, kdyby se do MBR sektoru dalo přistupovat pouze z režimu jádra. Pak by byla modifikace kódu v něm o dost obtížnější. Takhle může do MBR zapisovat běžná uživatelské aplikace, která má admin práva. Příkladem je třeba nástroj bootsect.exe verze 6. Je to často diskutovaný problém.

děkuji za podrobný popis, kde jsi tohle našel?

Na netu je o tom spousta informací, navíc jsem si úmyslně infikoval počítač, abych si mohl ověřit pár věcí, které mě zajímaly
Například bylo uváděno, že dropper (instalátor) ověřuje, zda není spuštěn na virtuálním počítači ověřováním hodnoty registru LDTR, která je v případě virtuálky nulová. Mě ale infikoval i virtuální počítač.

Na vytvoření neviditelné partition musí být také nějaký sofistikovaný způsob a nástroje na správu disku myslím by méohly zdetekovat gap (prázdné neviditelné místo. Pokud není alokováno standardním způsobem, lze přes něj vytvořit partišn a tím to máznout.

Není to klasický oddíl, jak ho znáš, je to pouze pár struktur obsahující názvy, velikosti a umístění komponent rootkitu. Je to takový souborový systém made in home.
Nejedná se ani o klasický oddíl, v tabulce rozdělení disku nemá záznam. Je to prostě pár sektorů na konci disku, se zašifrovanými daty.

Tohle je z TDL3, ale jinak je to stejné, jen je tam více modulů.

Z uživatelského režimu se k těm skrytým částem nemáš šanci dostat, pokus o čtení nebo zápis bude zmanipulovaný. Musel bys použít ovladač, který najde původní adresu handleru IRP_MJ_INTERNAL_DEVICE_CONTROL, sestaví vlastní pakety a přečte si skutečná data z disku. Další způsob kterým by se dalo řešit čtení/zápis na disk, který napadl jednoho známého (zdravím Martina Drába-Vrtule ) je přímý zápis na porty disku. Tedy poměrně náročné programování v režimu jádra.

Další věc je, ten proces cmd, ten se spouští ze systému anebo z té partišn? Ptám se proto, že porovnat checksum (délku) s neinfikovanými verzemi by neměl být problém, OVŠEM POKUD JE V PAMĚTI NĚCO JINÉHO JAK NA DISKU...

Není to proces, ale dynamická knihovna. Rootkit si projde seznam procesů a naočkuje ji do vybraných procesů. Hlídá si i vytváření nových procesů, které dle uvážení také infikuje. Tak se dostane kód rootkitu do adresového prostoru vybraných procesů, kde zahákuje různé API funkce některých systémových dll. Ta technika se používá už dlouho a jmenuje se dll injection. Dynamická knihovna cmd.dll je fyzicky umístěna také na šifrovaném oddílu rootkitu. Na disku kromě kódu v MBR není infikován žádný soubor, všechny změny se odehrávají až v paměti.
Jako cílové procesy si vybíral procesy internetových prohlížečů a procesu Windows update, to se ale může stále měnit.

Milinessi trošičku se Tě začínám bát...

Bu bu bu Já jsem hodnej čert