6 API’t, mis nullivad Windowsi turvalisuse

Üldiselt, kui alustada, siis ma ikka nö Windowsi sisemise eluga kursis alates win 95 ja mis kõige hullem, tee nii hea programm, kui vähegi suudad, on antud op.süsteemi jäetud API’d, mis programmi turvalisuse sisuliselt ära nullivad. Vista küll küsis kõike ja küsis veelkord kõike, aga kui mingi programm oli käivitatud, siis toimus kõik vanamoodi. Windowsis lihtne ntx tavauser ei saa programme modifitseerida , mis töötavad system kasutajanime all: ntx serviced. Samas saab ta modifitseerida programme mälus, mis töötavad tema õigusruumis. Troojakate lemmik explorer.exe sinna ikka lisatakse igasugust jura.

Vistas on tõesti ka mõiste Protected Processes. Minu arvates peaks enamus protsesse seda tüüpi olema, ükski teine protsess ei tohiks tulla teist “sodima”. Inside the Windows Vista Kernel: Part 3

Further, to prevent compromise from within, all executable code loaded into a protected process, including its executable image and DLLs, must be either signed by Microsoft (WHQL) with a Protected Environment (PE) flag, or if it’s an audio codec, signed by the developer with a DRM-signing certificate obtained from Microsoft. Because kernel-mode code can gain full access to any process, including protected processes, and 32-bit Windows allows unsigned kernel-mode code to load, the kernel provides an API for protected processes to query the “cleanliness” of the kernel-mode environment and use the result to unlock premium content only if no unsigned code is loaded.

API’d, mis on täiesti “saatanast”. Nende APIde kasutamine peaks nõudma kasvõi seda, et exe sertifitseeritud või midagi taolist.
SetWindowsHookEx Rõõmus API, ei tea kas meelega disainitud, et keyloggerid saaks tegutseda (WH_KEYBOARD/WH_KEYBOARD_LL/WH_JOURNALRECORD) ja firmad oma turvatarkvara tooteid müüa. Miks ma nii ütlen ?
On üks tore hook WH_DEBUG, seda kasutasin oma Pcturva programmi juures (2000 aastal), kui polnud veel korralikke keyloggerite avastajaid.

typedef struct {
DWORD idThread;
DWORD idThreadInstaller;
LPARAM lParam;
WPARAM wParam;
int code;
} DEBUGHOOKINFO, *PDEBUGHOOKINFO;

Nummi struktuuri, kas pole. Aga oih… idThreadInstaller Ühest hetkest NT’s maailmas hakkas see 0 näitama, et poleks kuidagi moodi võimalik teada saada, kes “haagi” paigaldas.

Tore ka sündmus, et see “haak” ning temaga seotud DLL laetakse kõikide protsesside külge. Osa tarkvarasid väidavad, et välistavad nö haake “user levelis”, tegelikkuses nende programmide efektiivsus sõltub, kas nad on esimesena käivitatud. Nad lihtsalt panevad ise ka “haagi” püsti, aga CallNextWindowsHooki ei edasta mingitel juhtudel. Siis ongi teised logijad pimeduses.

CreateRemoteThread

Creates a thread that runs in the virtual address space of another process.

Sisuliselt saad suvalise protsessi külge panna tööle oma lõime(d); kuna lõim protsessi küljes, ei keela lõimel mitte mingi asi olemasolevat protsessi muuta. Sõltub Windowsi SP, üldiselt mõnikord pead omale SE_DEBUG_PRIVILEGE õigused küsima.
Kuna antud kiu protseduur peab asuma samas protsessi mälupiirkonnas, siis tuleb appi järgmine protseduur.
WriteProcessMemory
Writes data to an area of memory in a specified process
Rõõmsalt saab kirjutada andmeid teise protsessi mälupiirkonda. Okei…kui väike mälukaitse peal, siis võtame sõbra VirtualProtectEx appi, muudame mälulehekülgede kaitseatribuute ja roheline tuli paistab.

VirtualProtectEx
Changes the protection on a region of committed pages in the virtual address space of a specified process.

Aga pole ilus kirjutada programmi koodi jooksvalt, eriti kui täpselt ei tea, mis seal toimub, siis tuleb appi järgmine API sõber
VirtualAllocEx
Reserves or commits a region of memory within the virtual address space of a specified process.

Temaga küsime teise protsessi piirkonda ühe lehekülje mälu või kui julged küsid kohe kaks 🙂

Nii ja nüüd teeme API piruka, mida troojakad tihti küpsetavad :

– esmalt otsime Psapi abil omale sobiva [ohvrist] protsessi, kelle koodipiirkonda lõim luua.
Küsime ka SE_DEBUG_PRIVILEGE õigused. Lahe, miskit anti… Kiul võiks olla ka mingi ülesanne, mida ta teise protsessi piirkonnas teeb. No loome pseudokoodi, mis laeb DLL faili, miks ma seda ei demostreeri, sest ma ei taha, keegi rumal teeks veel mõne troojaka. Küsime VirtualAllocEx sinna piirkonda mälu…Siis võtame ja kopeerime WriteProcessMemory abil selle DLL laadimise koodi mälupiirkonda, milles saime VirtualAllocEx apiga. Olemas…lahe.
CreateRemoteThread anname ette meie protsessi ning VirtualAllocEx abil saadud mälupiirkonna aadressi ja vuala, võime ntx explorer.exe või firefox.exe jne jne sundida laadima igasuguseid suvalisi DLL’e.

DebugActiveProcess
Ka paras katastroof “API”. Sisuliselt muutume debuggeriks, teine programm hakkab meile alluma. Ntx. mingi programm küsib seerianumbrit, EIP pointeri muutmisega hüpatakse sellest lihtsalt üle.

ReadProcessMemory
Reads data from an area of memory in a specified process

Järgmises kirjutises toon näite, kuidas programm saab kindlaks teha, kas tema IAT tabelit on muudetud.

Lisa kommentaar

Täida nõutavad väljad või kliki ikoonile, et sisse logida:

WordPress.com Logo

Sa kommenteerid kasutades oma WordPress.com kontot. Logi välja /  Muuda )

Google photo

Sa kommenteerid kasutades oma Google kontot. Logi välja /  Muuda )

Twitter picture

Sa kommenteerid kasutades oma Twitter kontot. Logi välja /  Muuda )

Facebook photo

Sa kommenteerid kasutades oma Facebook kontot. Logi välja /  Muuda )

Connecting to %s


%d bloggers like this: