SI23251A - Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija - Google Patents

Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija Download PDF

Info

Publication number
SI23251A
SI23251A SI200900380A SI200900380A SI23251A SI 23251 A SI23251 A SI 23251A SI 200900380 A SI200900380 A SI 200900380A SI 200900380 A SI200900380 A SI 200900380A SI 23251 A SI23251 A SI 23251A
Authority
SI
Slovenia
Prior art keywords
file
current working
working directory
function
executable
Prior art date
Application number
SI200900380A
Other languages
English (en)
Inventor
Mitja Kolšek
alamun Stanka Ĺ
kofiÄŤ Jure Ĺ
Original Assignee
Acros D.O.O.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Acros D.O.O. filed Critical Acros D.O.O.
Priority to SI200900380A priority Critical patent/SI23251A/sl
Priority to US12/960,507 priority patent/US20110145924A1/en
Publication of SI23251A publication Critical patent/SI23251A/sl

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/554Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Abstract

Opisan je postopek, ki rešuje problem zaznavanja in preprečevanja nalaganja izvršljivih datotek iz trenutnega delovnega direktorija. Postopek poteka na procesorju splošne uporabnosti in predstavlja tehnično rešitev tehničnega problema, saj sicer splošno programabilni procesor z naborom ukazov in izvedbo korakov spremeni v vsakič po izumu novo konfiguracijo, primerno za reševanje zgoraj opisanega tehničnega problema. Bistvo opisanega postopka odkrivanja opisane ranljivosti je v tem, da se z opazovanjem(ang. "monitoring") klicev in argumentov sistemskih ali aplikacijskih funkcij, ki igrajo ključno vlogo pri nalaganju izvršljivih datotek, zazna, da računalniški program ali operacijski sistem bodisi je poskusil, bo poskusil ali pa ravnokar poskuša nalagati ali zaganjati izvršljivo datoteko iz trenutnega delovnega direktorija. Bistvo postopka preprečevanja izrabe opisane ranljivosti je v tem, da se postopek (pasivnega, za procese nemotečega) odkrivanja te ranljivosti nadgradi z aktivnim posegom vdelovanje računalniškega programa ali operacijskega sistema tako, da se prepreči nalaganje ali zaganjanje izvršljive datoteke. Dodatno podajamo metode za omejevanje izrabe opisane ranljivosti, ki bodisi omejujejo nalaganje ali zaganjanje izvršljivih datotek iz trenutnega delovnega direktorija bodisi omejujejo ali preprečujejo nastavljanje trenutnega delovnega direktorija na datotečna mesta, na katerih bi lahko zlonamerna oseba ustvarila izvršljivo datoteko.

Description

Postopek zaznavanja in preprečevanja nalaganja izvršljivih datotek iz trenutnega delovnega direktorija
Področje tehnike
Izum sodi v področje aplikacijskih sistemov za samodejno odkrivanje in odpravljanje ranljivosti v programski opremi z opazovanjem in spreminjanjem delovanja/obnašanja programske kode, znanim iz stanja tehnike, primeroma http://en.wikipedia,org/wiki/lnstrumentation_(computer_programming) ali zamenjavo izvršnih datotek operacijskega sistema, in zaznavanjem dogodkov, ki indicirajo prisotnost ranljivosti.
Tehnični problem
Tehnični problem, ki ga rešuje ta izum, je vprašanje, ali je mogoče izvesti postopek avtomatiziranega odkrivanja okoliščin (ranljivosti) v programski opremi, ki potencialno omogočajo zlonamerno podtikanje izvršljivih datotek in njihovo nalaganje iz trenutnega delovnega direktorija, ter preprečevanje izrabe takšnih ranljivosti.
Sodobna programska oprema vsebuje veliko različnih ranljivosti, ki lahko zlonamernim osebam omogočijo razne nezaželjene aktivnosti, kot so na primer kraja podatkov, sprememba ali uničenje leteh, onesposobitev razpoložljivosti storitev ali nameščanje sovražne kode na računalnike in računalniško opremo uporabnikov in organizacij.
Ta vloga obravnava specifično vrsto napada, t.i. »podtikanje izvršljivih datotek v trenutnem delovnem direktoriju«, kjer zlonamerna oseba povzroči nalaganje sovražne programske knjižnice (npr. DLL datoteke) ali zagon sovražnega računalniškega programa (npr. ΕΧΕ datoteke) iz trenutnega delovnega • · direktorija na uporabnikovem računalniku. Podtikanje izvršljivih datotek vključuje dva koraka: (a) nastavitev ene ali več sovražnih izvršljivih datotek na neko datotečno mesto in (b) zaganjanje teh datotek s strani enega ali več procesov na računalniku.
Takšen napad je mogoč zaradi ranljivih postopkov nalaganja izvršljivih datotek, ki so vgrajeni v kodo operacijskega sistema Microsoft Windows (vključno z Windows 2000, Windows NT, Windows 2003, Windows XP, Windows Vista in Windows 7) in pripadajoče programske knjižnice.
Postopki nalaganja izvršljivih datotek se rahlo razlikujejo med verzijami Windows operacijskih sistemov in so odvisni tudi od nameščenih popravkov operacijskega sistema in nastavitev sistema. Prav tako se postopki razlikujejo za nalaganje programskih knjižnic in izvršljivih računalniških programov. Vsem postopkom nalaganja izvršljivih datotek pa je skupno, da v primeru, ko je datoteka naslovljena relativno (ni enolično naslovljena s t.i. »polno« oz. absolutno potjo na mediju), sprožijo iskanje izvršljive datoteke glede na podano relativno ime in sicer na vnaprej določenih lokacijah v vnaprej določenem vrstnem redu (te lokacije so dokumentirane na Microsoftovih internetnih straneh). Ko je izvršljiva datoteka najdena, jo sistem ali proces naloži in, če je potrebno, izvrši del njene kode. Lokacije, kjer sistem ali proces išče zahtevano izvršljivo datoteko, so praviloma naslednje:
1. »matični direktorij«, v katerem je osnovna programska datoteka procesa, ki sproža nalaganje zahtevane izvršljive datoteke;
2. sistemski direktoriji (npr. C: \Windows, C:\Windows\System32 in C: \Windows\System);
3. trenutni delovni direktorij (ang. »current vvorkingdirectory«) in
4. nekateri drugi direktoriji, ki tukaj niso pomembni.
Vrstni red iskanja je lahko tudi drugačen od navedenega, iskalni postopek pa tudi ne vključuje nujno vseh navedenih lokacij.
V matični direktorij in v sistemske direktorije zaradi privzetih varnostnih omejitev zlonamerna oseba praviloma ne more nastaviti sovražne izvršljive datoteke, kar je z varnostnega vidika dobro. Ranljivost postopkov nalaganja izvršljivih datotek pa je v tem, da seznam lokacij, kjer sistem ali proces išče relativno naslovljeno izvršljivo datoteko, vključuje tudi t.i. trenutni delovni direktorij (ang. »current vvorking directory«), na katerega pa je v odvisnosti od tega, kam v trenutku nalaganja izvršljive datoteke kaže, mogoče nastaviti sovražno izvršljivo datoteko in tako povzročiti, da jo sistem ali proces • · naloži namesto legitimne izvršljive datoteke - ter izvrši njeno kodo. Sistem ali proces bo naložil izvršljivo datoteko iz trenutnega delovnega direktorija le, če je ne bo našel na »prioritetnih« lokacijah, t.j. lokacijah, kjer jo poskuša najti pred tem.
Obstaja veliko načinov, kako za nek proces nastaviti trenutni delovni direktorij na lokacijo, na katero lahko piše tudi zlonamerna oseba. Najočitnejši način ponuja sistemska aplikacija Windows Explorer (primarno okolje za delo z datotekami in namizjem v sistemu Windows), ki nastavi trenutni delovni direktorij na lokacijo datoteke, na katero uporabnik dvoklikne. Tako na primer pri dvokliku na ikono Microsoft Word dokumenta Windows Explorer zažene aplikacijo Microsoft Word, nastavi njen trenutni delovni direktorij na lokacijo Microsoft Word datoteke in odpre to datoteko v zagnani aplikaciji. Če aplikacija kasneje poskuša naložiti ali zagnati kakršnokoli izvršljivo datoteko in te izvršljive datoteke ni niti v matičnem direktoriju aplikacije niti v sistemskih direktorijih, jo poskusi naložiti iz trenutnega delovnega direktorija. Ta pa je lahko zaradi prej opisanega delovanja Windows Explorerja v tistem trenutku na lokaciji, na katero lahko piše tudi zlonamerna oseba (npr. mapa v skupni rabi - ang. »shared folder«) in tako se na uporabnikovem računalniku naloži in zažene sovražna izvršljiva datoteka s sovražno kodo.
Opisana ranljivost je prisotna v velikem številu široko uporabljenih aplikacij, trenutno pa ni nobenega splošno poznanega postopka za njeno učinkovito zaznavanje.
Stanje tehnike
Za odkrivanje določenih ranljivosti v spletnih storivah in spletnih aplikacijah so na voljo številna komercialna in brezplačna orodja, ki spletnim strežnikom pošiljajo različne zahtevke in glede na odzive z različno stopnjo zanesljivosti sklepajo o prisotnosti danih ranljivosti.
Avtomatizirano zaznavanje ranljivosti v splošni programski opremi se dandanes izvaja predvsem z avtomatiziranim pregledom izvorne kode ali izvršljivih datotek te programske opreme. Le peščica orodij uporablja za zaznavanje ranljivosti opazovanje računalniških procesov v času izvajanja (ang. »run time«).
Eno najnaprednejših tovrstnih orodij je Microsoft Application Verifier (»Microsoft Application Verifier«http://www.microsoft.com/downloads/details.aspx?FamilylD=C4A25AB9-649D-4AiBB4A7-C9D8B095DF18&displaylang=en ali Microsoft, »Testing Applications with AppVerifier« • · http://msdn,microsoft.com/libra ry/default.asp?uri=/library/enus/dnappcom/html/AppVerifier.asp), ki omogoča opazovanje računalniških procesov v okolju Windows in zaznavanje določenih ranljivosti, npr. ustvarjanje sistemskih objektov z neustrezno kontrolo dostopa ali uporabo neinicializiranih spremenljivk. To orodje ne zaznava ranljivosti, ki jo obravnavata izum.
Sistem Microsoft Windows ponuja funkcijo SetDllDirectory, s katero lahko programer vpliva na postopek nalaganja programskih knjižnic in sicer tako, da s to funkcijo nastavi direktorij, ki bo v postopku iskanja programske knjižnice uporabljen namesto trenutnega delovnega direktorija. Ta funkcija ne vpliva na postopek nalaganja ali zaganjanja računalniških programov.
Microsoftova dokumentacija ne opisuje nobenega načina za preprečevanje nalaganja izvršljivih datotek iz trenutnega delovnega direktorija na sistemski osnovi (za vse procese). Mogoče je sicer sistemsko vplivati na obnašanje funkcije SearchPath prek vrednosti v registru in tako določiti, ali bo ta funkcija iskano datoteko najprej iskala v trenutnem delovnem direktoriju ali ne, vendar že Microsoft sam zaradi varnostnih razlogov odsvetuje uporabo te funkcije za lociranje programskih knjižnic.
Stanje tehnike je razvidno tudi iz naslednjih virov:
1. Viri [1] Wi ki pedia, »Instrumentation (Computer programming)« http://en.wi ki pedia.org/wi ki/lnstrumentation_(computer_programming) [2] Microsoft, »Dynamic-Link Li brary Search Order« http://msdn.microsoft.com/en-us/libra ry/ms682586(VS.85).aspx [3] Microsoft, »CreateProcess Function« http://msdn.microsoft.com/en-us/libra ry/ms682425(VS.85).aspx [4] Microsoft, »ShellExecute Function« http://msdn.microsoft.com/en-us/library/bb762153(VS.85),aspx [5] Microsoft, »WinExec Function« • · • ·
http://msdn.microsoft.com/en-us/library/ms687393(VS.85),aspx [6] Microsoft, »Microsoft Application Verifier« http://www.microsoft.com/downloads/details.aspx?FamilylD=C4A25AB9-649D-4AlB-
B4A7-C9D8B095DF18&displaylang=en [7] Microsoft, »Testing Applications with AppVerifier« http://msdn.microsoft.com/libra ry/default.asp?url=/library/enus/dnappcom/html/AppVerifier.asp [8] Microsoft, »CreateProcessAsUser Function« http://msdn.microsoft.com/en-us/library/ms682429(VS.85).aspx [9] Microsoft, »CreateProcessVVithLogonVV Function« http://msdn.microsoft.com/en-us/library/ms682431(VS.85).aspx [10] Microsoft, »CreateProcessWithTokenW Function« http://msdn.microsoft.com/en-us/libraty/ms682434(VS.85).aspx [11] Microsoft, »LoadLibrary Function« http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx [12] Microsoft, »LoadLibraryEx Function« http://msdn.microsoft.com/en-us/library/ms684179(VS.85).aspx [13] Microsoft, »ShellExecuteEx Function« http://msdn.microsoft,com/en-us/libraty/bb762154(VS.85).aspx [14] Ivo Ivanov, »API Hooking Revealed« http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5667 [15] Microsoft, »NtQueryAttributesFile Function« http://msdn.microsoft.com/en-us/library/cc512135(VS.85).aspx [16] Microsoft, »SearchPath Function« http://msdn. microsoft.com/en-us/libra ry/aa365527(VS.85).aspx • ·
Opis nove rešitve
Zgoraj opisan tehnični problem rešuje postopek za zaznavanje in preprečevanje nalaganja izvršljivih datotek iz trenutnega delovnega direktorija. Postopek poteka na procesorju splošne uporabnosti in predstavlja tehnično rešitev tehničnega problema, saj sicer splošno programabilni procesor z naborom ukazov in izvedbo korakov spremeni v vsakič po izumu novo konfiguracijo, primerno za reševanje zgoraj opisanega tehničnega problema.
Bistvo opisanega postopka odkrivanja opisane ranljivosti je v tem, da se z opazovanjem (ang. »monitoring«) klicev in argumentov sistemskih ali aplikacijskih funkcij, ki igrajo ključno vlogo pri nalaganju izvršljivih datotek, zazna, da računalniški program ali operacijski sistem bodisi je poskusil, bo poskusil ali pa ravnokar poskuša nalagati ali zaganjati izvršljivo datoteko iz trenutnega delovnega direktorija.
Bistvo postopka preprečevanja izrabe opisane ranljivosti je v tem, da se postopek odkrivanja te ranljivosti nadgradi z aktivnim posegom v delovanje računalniškega programa ali operacijskega sistema tako, da se prepreči nalaganje ali zaganjanje izvršljive datoteke.
Dodatno podajamo metode za omejevanje izrabe opisane ranljivosti, ki bodisi omejujejo nalaganje ali zaganjanje izvršljivih datotek iz trenutnega delovnega direktorija bodisi omejujejo ali preprečujejo nastavljanje trenutnega delovnega direktorija na datotečna mesta, na katerih bi lahko zlonamerna oseba nastavila izvršljivo datoteko. Značilni primeri takšnih datotečnih mest so:
- omrežna pot oz. mapa v skupni rabi (ang. »shared folder«);
- odstranljiv medij (ang. »removable storage«), npr. CD-ROM ali USB disk ali
- lokalni direktorij na računalniku, katerega pravice dostopa dovoljujejo nizko-privilegiranemu lokalnemu ali oddaljenemu uporabniku ustvarjanje izvršljivih datotek.
V nadaljevanju izraz »datotečno mesto, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko«, predstavlja datotečno mesto ali več datotečnih mest, ki so lahko definirana eksplicitno, z vzorci, v enem ali več seznamih, z zunanjimi viri, s programsko logiko ali s poljubno kombinacijo naštetega. Izraz »datotečno mesto, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke« pa pomeni vsa preostala datotečna mesta.
Zaznavanje oziroma opazovanje klicev in argumentov funkcij ter spreminjanje obnašanja funkcij se izvede s katerokoli izmed znanih tehnik ali poljubno kombinacijo le-teh, na primer:
instrumentacija (ang. »instrumentation«) Wikipedia, »instrumentation (Computer programming)« http://en.wikipedia.org/wiki/lnstrumentation_(computer_programming),
- zamenjava knjižnic (ang. »DLL replacement«),
- zamenjava izvršljivih programov (ang. »binaiy replacement«), redirekcija knjižnic (ang. »DLL redirection«),
- krpanje tabele naslovov uvoženih funkcij (ang. »Import address table patching«),
- krpanje kode funkcij v izvršljivih datotekah (ang. »function patching«, »code overwriti ng«),
- sprememba klicev ali kode funkcij v izvorni ali izvršni kodi knjižnic, uporaba posredniških knjižnic (ang. »Proxy DLL«),
- API pripenjanje (ang. »API hooking«) [14] Ivo Ivanov, »API Hooking Revealed« http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5667
- pripenjanje na sistemske klice (ang. »system call hooking«).
Usposobljen strokovnjak za razvoj programske opreme v okolju Windows lahko s pomočjo javno dostopnih dokumentov, primerov kode in knjižnic sorazmerno enostavno implementira tovrstno opazovanje ali spremembo obnašanja katerekoli izvožene (ang. »exported«) funkcije v katerikoli izvršljivi datoteki.
Pri odkrivanju ranljivosti na podtikanje izvršljivi h datotek se opiramo na opazovanje klicev naslednjih funkcij, bodisi v uporabniškem prostoru (ang. »user space«) ali jedrnem prostoru (ang. »kernel space«):
• LoadLibraryAin LoadLibraryW
LoadLibraryExA in LoadLibraryExW • · • LdrLoadDll • NtQueryAttributesFile • RtlAppendUnicodeStringToString • NtCreateSection in ZwCreateSection • NtCreateProcess in ZwCreateProcess • CreateProcessAin CreateProcessW • CreateProcessAsUserAin CreateProcessAsUserW • CreateProcessWithLogonW • CreateProcessWithTokenW • CreateProcessInternalAin CreateProcessInternalW • WinExec • ShellExecuteAinShellExecuteW • ShellExecuteEx,ShellExecuteExAinShellExecuteExW ali • drugih funkcij, ki so funkcionalno enakovredne naštetim oz. opravljajo sorodno vlogo v postopkih nalaganja ali zaganjanja izvršljivih datotek.
V nadaljevanju »relativna pot« (ang. »relative path«) za razliko od »absolutne« ali »polne« poti pomeni pot do datoteke, ki ni enolično določena in se zato nanaša na neko izhodiščno pot ali več izhodiščnih poti, ki se jih v postopku dostopanja do datoteke pripne na njen začetek in tako dobi absolutno pot. Na primer, »test\test.exe« in »test.exe« sta relativni poti, medtem ko je »c:\test\test.exe« absolutna oz. polna pot.
V nadaljevanju je opisano zaznavanje in preprečevanje nalaganja programskih knjižnic iz trenutnega delovnega direktorija, najprej v splošnem in nato še z opisom posameznih izvedbenih primerov.
Zaznavanje in preprečevanje nalaganja programskih knjižnic iz trenutnega delovnega direktorija izvedemo s poljubno kombinacijo spodaj naštetih postopkov.
Postopek 1: Zaznavamo klice ene ali obeh funkcij LoadLibraryA, LoadLibraryW. Če je pot do programske knjižnice (argument lpFileName) relativna, ob vstopu v funkcijo s preverjanjem obstoja datotek na datotečnem sistemu vnaprej preverimo, ali bo postopek iskanja programske knjižnice, ki se bo izvedel, to programsko knjižnico našel na kateri od lokacij v iskalni poti, preden jo bo poskusil najti v trenutnem delovnem direktoriju. Če datoteke z ustreznim imenom na teh »prednostnih« lokacijah v iskalni poti ni, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija.
Postopek la: Nadgradnja postopka 1, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da nalaganje programske knjižnice iz trenutnega delovnega direktorija ne bo uspelo pa se njena koda ne bo zagnala (npr. spremenimo pot do programske knjižnice);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek nalaganja programske knjižnice.
Postopek 2: Zaznavamo klice ene ali obeh funkcij LoadLibraryExA, LoadLibraryExW. Če je pot do programske knjižnice (argument lpFileName) relativna, ob vstopu v funkcijo s preverjanjem obstoja datotek na datotečnem sistemu vnaprej preverimo, ali bo postopek iskanja programske knjižnice, ki se bo izvedel, to programsko knjižnico našel na kateri od lokacij v iskalni poti, preden jo bo poskusil najti v trenutnem delovnem direktoriju. Če datoteke z ustreznim imenom na teh »prednostnih« lokacijah v iskalni poti ni, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija.
• · • t « · « · · · · · ··«· ·«*«« · · «t · » ··· ·*·· ·· *·
Postopek 2.1: Enako kot postopek 2, le da preverimo tudi, če podane zastavice (argument dwFlags) določajo nalaganje programske knjižnice na izvršljiv način.
Postopek 2a: Nadgradnja postopkov 2 in 2.1, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da nalaganje programske knjižnice iz trenutnega delovnega direktorija ne bo uspelo ali pa se njena koda ne bo zagnala (npr. spremenimo pot do programske knjižnice ali podane zastavice);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek nalaganja programske knjižnice.
Postopek 3: Zaznavamo klice funkcije LdrLoadDll. Če je ime programske knjižnice (argument ModuleFileName) relativno, ob vstopu v funkcijo s preverjanjem obstoja datotek na datotečnem sistemu vnaprej preverimo, ali bo postopek iskanja programske knjižnice, ki se bo izvedel, to programsko knjižnico našel na kateri od lokacij v iskalni poti (argument PathToFile - lokacije so navedene po vrsten redu poskušanja in ločene s podpičjem), preden jo bo poskusil najti v trenutnem delovnem direktoriju (označenem kot lokacija ».«). Če datoteke z ustreznim imenom na lokacijah v iskalni poti pred trenutnim delovnim direktorijem ni, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija.
Postopek 3.1: Enako kot postopek 3, le da preverimo tudi, če podane zastavice (argument Flags) določajo nalaganje programske knjižnice na izvršljiv način.
• · · ·
Postopek 3a: Nadgradnja postopkov 3 in 3.1, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da nalaganje programske knjižnice iz trenutnega delovnega direktorija ne bo uspelo ali pa se njena koda ne bo zagnala (npr. spremenimo ime programske knjižnice, spremenimo podane zastavice ali iz iskalne poti odstranimo trenutni delovni direktorij - lokacije».«);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek nalaganja programske knjižnice.
Postopek 4: Zaznavamo klice funkcije NtQueryAttributesFile. Če je podana pot do datoteke (član ObjectName argumenta ObjectAttributes) relativna in iz imena datoteke sklepamo, da gre za izvršljivo datoteko (npr. datoteka ima končnico »DLL« ali »EXE«), je verjetno, da se bo izvedel poskus nalaganja programske knjižnice ali poskus zagona računalniškega programa iz trenutnega delovnega direktorija.
Postopek 4.1: Zaznavamo klice funkcije NtQueryAttributesFile v okviru postopka nalaganja programske knjižnice: ob vstopu v to funkcijo ugotovimo, če je v teku postopek nalaganja programske knjižnice in če je hkrati tudi podana pot do datoteke (član ObjectName argumenta ObjectAttributes) relativna. Če sta oba pogoja izpolnjena, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija. Ugotavljanje, ali je v teku postopek nalaganja programske knjižnice, izvedemo na enega od naslednjih načinov:
• ob zaznavi klicev ene ali večih izmed funkcij LoadLibraryA, LoadLibraryW, LoadLibraryExA , LoadLibraryExW ali LdrLoadDll zapišemo začasno oznako (npr. v pomnilnik procesa, v register ali na disk), da je v teku postopek nalaganja programske knjižnice tako, da bo ta oznaka dostopna tudi iz funkcije NtQueryAttributes File.
• ob zaznavi klicev ene ali večih izmed funkcij LoadLibraryA, LoadLibraryW, LoadLibraryExA , LoadLibraryExW ali LdrLoadDll zapišemo začasno oznako (npr. v pomnilnik procesa, v register ali na disk), da je v teku postopek nalaganja programske knjižnice tako, da bo ta oznaka dostopna tudi iz funkcije NtQueryAttributesFile, ob tem pa to oznako dodatno pogojujemo s tem, da morajo morebitne podane zastavice (argument dwFlags funkcije LoadLibraryEx oziroma argument Flags funkcije LdrLoadDll) določati nalaganje programske knjižnice na izvršljiv način.
• med izvajanjem funkcije NtQueryAttributesFile pregledamo sklad klicev (ang. »call stack«) in tako ugotovimo, ali je ta funkcija posredno ali neposredno klicana s strani katere od funkcij LoadLibraryA, LoadLibraryW, LoadLibraryExA , LoadLibraryExW ali LdrLoadDll.
Postopek 4a: Nadgradnja postopkov 4 in 4.1, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da bo funkcija klicatelju vrnila kodo napake, ki bo le-temu pomenila, da datoteka ne obstaja ali je ni mogoče odpreti;
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke;
• prekinemo izvajanje klicane funkcije in s tem postopek preverjanja prisotnosti programske knjižnice v trenutnem delovnem direktoriju ali • kličoči funkciji vrnemo kodo napake, ki pomeni, da datoteka ne obstaja ali je ni mogoče odpreti;
Postopek 5: Zaznavamo klice funkcije RtlAppendUnicodeStringToString v okviru postopka nalaganja programske knjižnice: ob vstopu v to funkcijo ugotovimo, če je v teku postopek nalaganja programske knjižnice in če je ciljni niz (pivi argument te funkcije) enak»./«(pika in poševnica). Če sta oba pogoja izpolnjena, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz • · · » · <
• · • · trenutnega delovnega direktorija. Ugotavljanje, ali je v teku postopek nalaganja programske knjižnice, izvedemo enako kotv postopku 4.1.
Postopek 5a: Nadgradnja postopka 5, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da sestavljen znakovni niz, ki ga funkcija vrne, ne bo predstavljal poti do obstoječe programske knjižnice v trenutnem delovnem direktor·ju;
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke;
• prekinemo izvajanje klicane funkcije in s tem postopek preverjanja prisotnosti programske knjižnice v trenutnem delovnem direktoriju ali • kličoči funkciji vrnemo znakovni niz, ki ne predstavlja poti do obstoječe programske knjižnice v trenutnem delovnem direktoriju.
Postopek 6: Zaznavamo klice ene ali obeh funkcij NtCreateSection, ZwCreateSection (NtCreateSection lahko tudi v jedru operacijskega sistema). Če podano ime objekta (član ObjectName argumenta ObjectAttributes) navaja relativno pot do programske knjižnice ali absolutno pot znotraj trenutnega delovnega direktorija, to pomeni, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija.
Postopek 6a: Nadgradnja postopka 6, kjer po ugotovitvi, da se bo izvedel poskus nalaganja programske knjižnice iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da ime objekta ne predstavlja poti do obstoječe programske knjižnice v trenutnem delovnem direktoriju;
• · • ·
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke;
• prekinemo izvajanje klicane funkcije in s tem postopek nalaganja programske knjižnice ali • kličoči funkciji vrnemo kodo napake, ki pomeni, da nalaganje programske knjižnice ni uspelo.
V nadaljevanju je opisano postopek zaznavanja in preprečevanja zaganjanja izvršljivih računalniških pogramov iz trenutnega delovnega direktorija
Zaznavanje in preprečevanje zaganjanja izvršljivih računalniških pogramov iz trenutnega delovnega direktorija izvedemo s poljubno kombinacijo spodaj naštetih postopkov.
Postopek 7: Zaznavamo klice ene ali večih izmed funkcij CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW,
CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW. Če je podana pot do računalniškega programa (argument IpApplicationName) relativna, to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
Postopek 7.1: Zaznavamo klice ene ali večih izmed funkcij CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW,
CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW. Če pot do računalniškega programa ni podana (argument IpApplicationName ima vrednost NULL), podana komandna vrstica (argument lpCommandLine) pa navaja relativno pot do računalniškega programa, ob vstopu v funkcijo preverimo, ali na datotečnem sistemu obstaja datoteka z imenom tega računalniškega programa v direktoriju, kjer se nahaja izvršljiva datoteka tekočega procesa. Če takšna datoteka ne obstaja, to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
« ·
Postopek 7a: Nadgradnja postopkov 7 in 7.1, kjer po ugotovitvi, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da zaganjanje računalniškega programa ne bo uspelo (npr. postavimo vrednost argumenta IpApplicationName na znakovni niz, ki ne predstavlja poti do računalniškega programa v trenutnem delovnem direktoriju);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek zaganjanja računalniškega programa.
Postopek 8: Zaznavamo klice funkcije winExec. Če podana komandna vrstica (argument lpCmdLine) navaja relativno pot do računalniškega programa, ob vstopu v funkcijo preverimo, ali na datotečnem sistemu obstaja datoteka z imenom tega računalniškega programa v direktoriju, kjer se nahaja izvršljiva datoteka tekočega procesa. Če takšna datoteka ne obstaja, to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
Postopek 8a: Nadgradnja postopka 8, kjer po ugotovitvi, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da zaganjanje računalniškega programa ne bo uspelo (npr. postavimo vrednost argumenta lpCmdLine na znakovni niz, ki se ne začne s potjo do računalniškega programa v trenutnem delovnem direktoriju);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek zaganjanja računalniškega programa.
Postopek 9: Zaznavamo klice ene ali večih izmed funkcij ShellExecuteA, ShellExecuteW, ShellExecuteEx, ShellExecuteExA, ShellExecuteExW. Če sta izpolnjena prva dva ali vsi trije od naslednjih pogojev:
1. podana datoteka (lpFile) je relativna pot do izvršljivega računalniškega programa,
2. podan direktorij (lpDirectory) ima vrednost NULL in
3. podana operacija (lpOperation) je null ali »open«, to pomeni, da se bo verjetno izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
Postopek 9a: Nadgradnja postopka 9, kjer po ugotovitvi, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da zaganjanje računalniškega programa ne bo uspelo (npr. postavimo vrednost argumenta lpFile na znakovni niz, ki ne predstavlja relativne ali absolutne poti do računalniškega programa v trenutnem delovnem direktoriju);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek zaganjanja računalniškega programa.
Postopek 10: Zaznavamo klice ene ali obeh funkcij NtCreateProcess, ZwCreateProcess (NtCreateProcess lahko tudi v jedru operacijskega sistema). Če podano ime procesa (član ObjectName argumenta ObjectAttributes) navaja relativno pot do računalniškega programa ali « · · · absolutno pot znotraj trenutnega delovnega direktorija, to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
Postopek lOa: Nadgradnja postopka 10, kjer po ugotovitvi, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da zaganjanje računalniškega programa ne bo uspelo (npr. postavimo vrednost člana ObjectName argumenta ObjectAttributes na znakovni niz, ki ne predstavlja relativne ali absolutne poti do računalniškega programa v trenutnem delovnem di rektori j u);
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek zaganjanja računalniškega programa.
• kličoči funkciji vrnemo kodo napake, ki pomeni, da nalaganje računalniškega programa ni uspelo.
Postopek 11: Zaznavamo klice funkcije NtQueryAttributesFile. Če je podana pot do datoteke (član ObjectName argumenta ObjectAttributes) relativna in iz imena datoteke sklepamo, da gre za računalniški program (npr. datoteka ima končnico »EXE«), to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija.
Postopek 11.1: Zaznavamo klice funkcije NtQueryAttributesFile v okviru postopka zaganjanja računalniškega programa: ob vstopu v to funkcijo ugotovimo, če je v teku postopek zaganjanja računalniškega programa in če je hkrati tudi podana pot do datoteke (član ObjectName argumenta ObjectAttributes) relativna. Če sta oba pogoja izpolnjena, to pomeni, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija. Ugotavljanje, ali je v teku postopek zaganjanja računalniškega programa, izvedemo na enega od naslednjih načinov:
• · • * • ob zaznavi klicev ene ali večih izmed funkcij CreateProcessA, CreateProcessW,
CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW,
CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW ali
WinExec zapišemo začasno oznako, da je v teku postopek zaganjanja računalniškega programa tako, da bo ta oznaka dostopna tudi iz funkcije NtQueryAttributesFile (npr. v pomnilnik procesa, v register ali na disk).
• med izvajanjem funkcije NtQueryAttributesFile pregledamo sklad klicev (ang. »call stack«) in tako ugotovimo, ali je ta funkcija posredno ali neposredno klicana s strani katere od funkcij CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW, CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW ali WinExec.
Postopek lla: Nadgradnja postopkov 11 in 11.1, kjer po ugotovitvi, da se bo izvedel poskus zaganjanja računalniškega programa iz trenutnega delovnega direktorija, to preprečimo tako, da pogojno ali brezpogojno naredimo nekaj od naslednjega:
• spremenimo prejete argumente klicane funkcije tako, da bo funkcija klicatelju vrnila kodo napake, ki bo le-temu pomenila, da računalniški program ne obstaja ali je ni mogoče odpreti;
• postavimo trenutni delovni direktorij na lokacijo, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke ali • prekinemo izvajanje klicane funkcije in s tem postopek preverjanja prisotnosti računalniškega programa v trenutnem delovnem direktoriju.
Postopek 12: Zaznavamo klice ene ali več izmed funkcij, ki sodelujejo v procesih nalaganja ali zaganjanja izvršljivih datotek in je iz njihovih argumentov mogoče razbrati ime in pot izvršljive datoteke, ki se nalaga oziroma zaganja: Če je ta pot relativna, pred nadaljevanjem izvajanja takšne funkcije v trenutnem delovnem direktoriju ustvarimo »podtaknjeno« datoteko z imenom izvršljive datoteke, ki se nalaga oziroma zaganja, potem pa ugotovimo, ali je bila ta datoteka v resnici • · • ·
naložena oziroma zagnana. Ugotavljanje, ali je bila ta datoteka v resnici naložena oziroma zagnana, izvedemo na enega od naslednjih načinov:
• opazujemo uporabo datotečnega sistema, npr. z monitorjem datotečnega sistema (ang. »file system monitor«) ali monitorjem aplikacijskih klicev (ang. »API call monitor«);
• »podtaknjeno« datoteko naredimo izvršljivo in zaznamo zagon njene kode ali kode drugih izvršljivih datotek, ki jih zažene, tako, da ta koda sporoči, zapiše ali prikaže dokaz o svojem zagonu ali o tem kakorkoli drugače opozori uporabnika.
V nadaljevanju so opisane druge metode preprečevanja nalaganja programskih knjižnic in zaganjanja izvršljivih računalniških pogramov iz trenutnega delovnega direktorija
Omejevanje in preprečevanje nalaganja programskih knjižnic in zaganjanja izvršljivih računalniških pogramov iz trenutnega delovnega direktorija je mogoče tudi z uporabo poljubne kombinacije naslednjih metod, samostojno ali v poljubni kombinaciji z doslej opisanimi postopki.
• V nekaterih ali vseh obstoječih procesih enkrat ali večkrat, pogojno ali brezpogojno, povzročimo klic funkcije SetDllDirectory s praznim nizom ali nizom, ki kaže na datotečno mesto, kjer zlonamerna oseba ne more ustvariti izvršljive datoteke.
• Spremenimo obnašanje mehanizma nalaganja izvršljivih datotek tako, da se le-te - bodisi pod določenimi pogoji ali pa sploh - ne nalagajo iz trenutnega delovnega direktorija, kadar je ta nastavljen na datotečno mesto, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko.
• V izvorni kodi izvršljivih datotek operacijskega sistema spremenimo obnašanje mehanizma nalaganja izvršljivih datotek tako, da se le-teh - bodisi pod določenimi pogoji ali pa sploh ne nalaga iz trenutnega delovnega direktorija, kadar je ta nastavljen na datotečno mesto, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko. (Dokler je izvorna koda operacijskega sistema Microsoft Windows javno nedostopna, lahko takšno spremembo izvedejo le razvijalci v Microsoftu.) • ·
• Spremenimo obnašanje ene ali več funkcij izmed LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, LdrLoadDll tako, da se morebitne okoljske spremenljivke (npr. »%SystemPath%«) v vhodnem argumentu lpFileName samodejno »razrešijo« (nadomestijo z znakovnim nizom iz sistemskega okolja, ki ga predstavljajo), preden se v postopku iskanja programske knjižnice uporabijo v »nerazrešeni« obliki.
• V izvorni kodi izvršljivih datotek operacijskega sistema spremenimo obnašanje ene ali več funkcij izmed LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, LdrLoadDll tako, da se morebitne okoljske spremenljivke (npr. »%SystemPath%«) v vhodnem argumentu lpFileName samodejno »razrešijo« (nadomestijo z znakovnim nizom iz sistemskega okolja, ki ga predstavljajo), preden se v postopku iskanja programske knjižnice uporabijo v »nerazrešeni« obliki. (Dokler je izvorna koda operacijskega sistema Microsoft Windows javno nedostopna, lahko takšno spremembo izvedejo le razvijalci v Microsoftu.)
Obravnavano ranljivost je mogoče omejiti tudi tako, da se prepreči ali omeji nastavljanje trenutnega delovnega direktorija na datotečna mesta, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko. To je mogoče narediti z naslednjimi metodami:
• V nekaterih ali vseh obstoječih procesih enkrat ali večkrat pogojno ali brezpogojno povzročimo nastavitev trenutnega delovnega direktorija na datotečno mesto, kjer zlonamerna oseba ne more ustvarjati izvršljive datoteke.
• Z opazovanjem ene ali več izmed funkcij ShellExecuteA, ShellExecuteW, ShellExecuteEx,
ShellExecuteExA, ShellExecuteExW in spremembo argumenta lpDirectory ali z opazovanjem ene ali več izmed funkcij CreateProcessA, CreateProcessttf, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW,
CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW in spremembo argumenta lpCurrentDirectory spremenimo obnašanje nekaterih ali vseh Windows aplikacij tako, da pogojno ali brezpogojno ne nastavljajo trenutnega delovnega direktorija na datotečna mesta, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko.
S to metodo lahko spremenimo tudi obnašanje aplikacije Windows Explorer tako, da ob uporabnikovem dvokliku na neko datoteko ne nastavlja trenutnega delovnega direktorija na lokacijo te datoteke za aplikacijo, ki to datoteko odpira.
• V izvorni kodi izvršljivih datotek operacijskega sistema spremenimo obnašanje ene ali več izmed funkcij ShellExecuteA, ShellExecuteW, ShellExecuteEx, ShellExecuteExA, ShellExecuteExW, CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW, CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW tako, da pogojno ali brezpogojno ne nastavljajo trenutnega delovnega direktorija na datotečna mesta, kjer bi lahko zlonamerna oseba ustvarila izvršljivo datoteko. (Dokler je izvorna koda operacijskega sistema Microsoft Windows javno nedostopna, lahko takšno spremembo izvedejo le razvijalci v Microsoftu.) • V izvorni kodi izvršljivih datotek operacijskega sistema spremenimo obnašanje aplikacije Windows Explorer tako, da ob uporabnikovem dvokliku na neko datoteko ne nastavi trenutnega delovnega direktorija na lokacijo te datoteke za aplikacijo, ki to datoteko odpira. (Dokler je izvorna koda operacijskega sistema Microsoft Windows javno nedostopna, lahko takšno spremembo izvedejo le razvijalci v Microsoftu.)
V nadaljevanju je opisan izvedbeni primer zaznavanja ranljivosti za podtikanje programskih knjižnic.
S tehniko pripenjanja opazujemo klice funkcije LdrLoadDll. Ko tekoči proces bodisi eksplicitno bodisi implicitno zahteva nalaganje programske knjižnice, se pokliče funkcija LdrLoadDll. Ta funkcija vrne rezultat ti pa NTSTATUS in prejme sledeče argumente:
1. niz datotečnih poti, po katerih naj išče programsko knjižnico;
2. zastavice, ki določajo način nalaganja programske knjižnice (zastavice se ujemajo z vrednostmi zastavic, ki jih kot argument prejema funkcija LoadLibraryEx);
3. ime programske knjižnice (ime je lahko relativna ali absolutna pot) in
4. kazalec na pomnilnik, v katerega se vme »ročaj« (ang. »handle«).
Ob vstopu v funkcijo LdrLoadDll so pomembne naslednje okoliščine:
• Programske knjižnice se lahko v pomnilnik nalagajo na dva načina: kot izvedljiv odsek (ang. »section«) ali kot podatkovni odsek. Zlonamerna programska koda se lahko izvrši le, če se programska knjižnica nalaga v pomnilnik kot izvedljiv odsek, zato je nalaganje programske knjižnice kot podatkovni vir neprimerno manj nevarno.
• Če funkcija LdrLoadDll kot argument prejme absolutno pot do programske knjižnice, se bo iskanje omejilo le na podano absolutno pot, kar posledično onemogoča podtikanje v trenutni delovni direktorij.
• Niz poti, ki jih kot argument prejme funkcija LdrLoadDll (posamezne poti so med seboj ločene s podpičjem) ponavadi vsebuje tudi trenutni delovni direktorij (v nizu zaznamovan s piko).
Glede na zgoraj navedeno je nadaljno opazovanje postopka nalaganja programske knjižnice smiselno le, če so izpolnjeni sledeči pogoji:
1. programska knjižnica se glede na zastavice (argument Flags) v pomnilnik nalaga kot izvedljiv odsek,
2. ime programske knjižnice (argument ModuleFileName) je relativno in
3. prejeta iskalna pot (argument PathToFile) vsebuje tudi trenutni delovni direktorij (».«).
Če so vsi trije pogoji izpolnjeni, v globalno spremenljivko zapišemo, da smo v postopku nalaganja programske knjižnice, nato pa s tehniko pripenjanja opazujemo klice funkcije NtQueryAttributesFile, ki se zgodijo kot posledica izvajanja funkcije LdrLoadDll (v funkciji NtQueryAttributesFile preverimo, ali globalna spremenljivka označuje, da smo v postopku nalaganja programske knjižnice).
Klici funkcije NtQueryAttributesFile se v večini primerov vršijo v vrstnem redu, ki ga predpisuje iskalna pot, ki je kot argument PathToFile predana funkciji LdrLoadDll.
Funkcija NtQueryAttributesFile vrne rezultat tipa NTSTATUS in prejme dva argumenta: kazalec na strukturo tipa OBJECT_ATTRIBUTES in kazalec na strukturo tipa FILE_BASIC_INFORMATION, v kateri vrne izhodne podatke. Za nas je relevanten samo prvi argument, iz katerega lahko razberemo pot do datoteke, za katero se vrši povpraševanje. Struktura tipa OBJECTATTRIBUTES ima 6 članov, vendar je za nas pomemben samo član ObjectName tipa PUNICODE_STRING (kazalec na strukturo tipa UNICODE STRING). S tem podatkom lahko za vsak klic funkcije NtQueryAttributesFile ugotovimo, po kateri datoteki povprašuje in ali je njena podana pot relativna (pot ne vsebuje korenskega direktorija) ali absolutna (pot vsebuje korenski direktorij). Če torej v postopku nalaganja programske knjižnice funkcija NtQueryAttributesFile kot argument prejme strukturo, v kateri je pot do datoteke podana relativno, lako z visoko zanesljivostjo trdimo, da gre za primer poskusa nalaganja programske knjižnice iz trenutnega delovnega direktorija - in da je zato proces ranljiv za podtikanje programskih knjižnic. V tem trenutku lahko nalaganje programske knjižnice iz delovnega direktorija tudi preprečimo, saj je dejansko nalaganje programske knjižnice odvisno od rezultata, ki ga funkcija NtQueryAttributesFile vrne. Če klicu funkcije spremenimo rezultat iz 0x00000000 statussuccess (kar pomeni, da datoteka obstaja) v 0xC0000034 STATUS OB JECT NAME NOT FOUND (kar pomeni, da datoteka ne obstaja), se nalaganje te programske knjižnice iz trenutnega delovnega direktorija ne bo izvedlo.
V nadaljevanju je opisan izvedbeni primer zaznavanja ranljivosti za podtikanje izvršljivih računalniških programov.
Ko nek proces želi pognati drugega, lahko to stori s klicem ene izmed naslednjih funkcij: CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW, CreateProcessWithTokenW, CreateProcessInternalA,
CreateProcessInternalW ali WinExec. Vsaka od teh funkcij vrne vrednost tipa BOOL in prejme več argumentov, vendar je za nas pomembna samo pot do izvršljivega računalniškega programa, ki je lahko podana absolutno ali relativno. V primeru, da je pot podana relativno, obstaja velika verjetnost, da je proces ranljiv za podtikanje izvršljivih računalniških programov. Vse navedene funkcije (oziroma njihove »podfunkcije«, angleško »subfunction«) v tem primeru najprej s klici funkcije NtQueryAttributesFile preverijo obstoj zahtevane izvršljive datoteke v matičnem direktoriju (direktoriju, v katerem se nahaja programska datoteka kličočega procesa). Če iskane datoteke tam • · ne najdejo, s ponovnim klicem funkcije NtQueryAttributesFile preverijo obstoj zahtevane izvršljive datoteke v trenutnem delovnem direktoriju - in jo v primeru, da tam obstaja, tudi preslikajo v pomnilnik in izvedejo.
Zaznavanje ranljivosti deluje tako, da s pripenjanjem opazujemo klice vseh navedenih funkcij in v njih v globalno spremenljivko zapišemo, da smo v postopku nalaganja izvršljivega računalniškega programa, nato pa s tehniko pripenjanja opazujemo klice funkcije NtQueryAttributesFile, ki se zgodijo kot posledica izvajanja teh funkcij (v funkciji NtQueryAttributesFile preverimo, ali globalna spremenljivka označuje, da smo v postopku nalaganja izvršljivega računalniškega programa).
Če v postopku nalaganja izvršljivega računalniškega programa funkcija NtQueryAttributesFile prejme kot argument relativno pot do datoteke, lahko z veliko zanesljivostjo ugotovimo, da se bo zagnal izvršljiv računalniški program iz trenutnega delovnega direktorija. V tem trenutku lahko zagon izvršljivega računalniškega programa iz trenutnega delovnega direktorija preprečimo na enak način kot v predhodnem primeru izvedbe - z nastavitvijo rezultata na 0xC0000034 STATUS OBJECT NAME NOT FOUND.

Claims (15)

  1. PATENTNI ZAHTEVKI
    1. Postopek zaznavanja in/ali preprečevanja nalaganja izvršljivih datotek iz trenutnega delovnega direktorija, izveden kot računalniški program za programiranje splošno programabilnega procesorja, na osnovi relativne poti in pričakovanega vrstnega reda iskanja teh datotek, značilen po tem, da se opazujejo klici ene ali več izmed funkcij programskega okolja Windows, bodisi v uporabniškem bodisi v jedrnem prostoru, in se na osnovi relativne poti do posamezne izvršljive datoteke, ki jo dobijo v vhodnem argumentu, in pričakovanega vrstnega reda iskanja te datoteke v iskalni poti, pri čemer datoteke z ustreznim imenom na prednostnih lokacijah v iskalni poti ni, ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija, ali , alternativno, da v nekaterih ali vseh obstoječih procesih na računalniku enkrat ali večkrat, pogojno ali brezpogojno, povzroči klic funkcije SetDllDirectory s praznim nizom ali nizom, ki kaže na datotečno mesto, ki je lahko definirano eksplicitno, z vzorci, v enem ali več seznamih, z zunanjimi viri, s programsko logiko ali s poljubno kombinacijo naštetega, pri čemer je za to datotečno mesto značilno, da zlonamerna oseba verjetno nanj ne more namestiti izvršljive datoteke.
  2. 2. Postopek po zahtevku 1, značilen po tem, da se opazujejo klici katere od funkcij
    LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, LdrLoadDll, NtCreateSection, ZwCreateSection, CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW,
    CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW, WinExec, ShellExecuteA, ShellExecuteW, ShellExecuteEx, ShellExecuteExA, ShellExecuteExW, NtCreateProcess ali ZwCreateProcess in se na osnovi relativne poti do datoteke, ki jo posamezna funkcija dobi v vhodnem argumentu, ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija.
    • * · ·
  3. 3. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici funkcije NtQueryAttributesFile in se na osnovi relativne poti do datoteke, ki jo dobi v vhodnem argumentu, in končnice imena te datoteke ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija.
  4. 4. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici funkcije NtQueryAttributesFile in se na osnovi ugotovitve, da se v trenutku klica te funkcije izvaja postopek nalaganja programske knjižnice, in na osnovi relativne poti do datoteke, ki jo funkcija NtQueryAttributesFile dobi v vhodnem argumentu, ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija.
  5. 5. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici funkcije RtlAppendUnicodeStringToString in se na osnovi ugotovitve, da se v trenutku klica te funkcije izvaja postopek nalaganja programske knjižnice, in na osnovi tega, da je ciljni niz (prvi argument funkcije RtlAppendUnicodeStringToString) enak »./«, ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija.
  6. 6. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici funkcije NtQueryAttributesFile in se na osnovi ugotovitve, da se v trenutku klica te funkcije izvaja postopek nalaganja računalniškega programa, in na osnovi relativne poti do datoteke, ki jo funkcija NtQueryAttributesFile dobi v vhodnem argumentu, ugotovi, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija.
  7. 7. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se po ugotavljanju poskusa nalaganja ali zaganjanja izvršljive datoteke, le-to prepreči s katerimkoli od sledečih ravnanj ali njih kombinacijo:
    - sprememba argumentov opazovane funkcije,
    - prestavitev trenutnega delovnega direktorija,
    - prekinitev izvajanja opazovane funkcije,
    - vračanje takšne kode napake kličoči funkciji, da le-ta ne bo poskusila naložiti ali zagnati izvršljive datoteke..
  8. 8. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se po ugotavljanju, da se bo izvedel poskus nalaganja ali zaganjanja izvršljive datoteke iz trenutnega delovnega direktorija, na datotečnem sistemu samodejno ustvari datoteka, za katero je bilo ugotovljeno, da se bo naložila ali zagnala, ter se z opazovanjem uporabe te datoteke ali z izvajanjem kode, ki se zaradi te datoteke izvede, ugotovi, da bi se sovražna izvršljiva datoteka v trenutnem delovnem direktoriju res naložila ali zagnala.
  9. 9. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da na sistemskem nivoju, za procese, spremeni obnašanje mehanizma nalaganja izvršljivih datotek tako, da se le-te bodisi pod določenimi pogoji ali pa sploh - ne nalagajo iz trenutnega delovnega direktorija.
  10. 10. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da na sistemskem nivoju, za procese, spremeni obnašanje ene ali več funkcij izmed LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, LdrLoadDll tako, da se morebitne okoljske spremenljivke (npr. »%SystemPath%«) v vhodnem argumentu lpFileName samodejno »razrešijo« (nadomestijo z znakovnim nizom iz sistemskega okolja, ki ga predstavljajo), preden se v postopku iskanja programske knjižnice uporabijo v »nerazrešeni« obliki.
  11. 11. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da v nekaterih ali vseh obstoječih procesih enkrat ali večkrat, pogojno ali brezpogojno, povzroči nastavitev trenutnega delovnega direktorija na datotečno mesto, ki je lahko definirano eksplicitno, z vzorci, v enem ali več seznamih, s programsko logiko ali s poljubno kombinacijo naštetega.
  12. 12. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici ene ali večih izmed funkcij ShellExecuteA, ShellExecuteW, ShellExecuteEx, ShellExecuteExA, ShellExecuteExW in se s pogojno ali brezpogojno spremembo argumenta lpDirectory prepreči nastavljanje trenutnega delovnega direktorija na določena datotečna mesta, ki so lahko definirana eksplicitno, z vzorci, v enem ali več seznamih, s programsko logiko ali s poljubno kombinacijo naštetega.
  13. 13. Postopek po kateremkoli prejšnjem zahtevku, značilen po tem, da se opazujejo klici ene ali večih izmed funkcij CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserW, CreateProcessWithLogonW, CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW in se s pogojno ali brezpogojno spremembo argumenta lpCurrentDirectory prepreči nastavljanje trenutnega delovnega direktorija na določena datotečna mesta, ki so lahko definirana eksplicitno, z vzorci, v enem ali več seznamih, s programsko logiko ali s poljubno kombinacijo naštetega.
  14. 14. Postopek po kateremkoli prejšnjem zahtevku, ki obsega spremembo obnašanja operacijskega sistema ali pripadajočih izvršljivih datotek, značilna po tem, da ena ali več izmed funkcij ShellExecuteA, ShellExecuteW, ShellExecuteEx, ShellExecuteExA, ShellExecuteExW, CreateProcessA, CreateProcessW, CreateProcessAsUserA, CreateProcessAsUserii, CreateProcessWithLogonW, CreateProcessWithTokenW, CreateProcessInternalA, CreateProcessInternalW pogojno ali brezpogojno ne nastavlja trenutnega delovnega direktorija na določena datotečna mesta, ki so lahko definirana eksplicitno, z vzorci, v enem ali več seznamih, s programsko logiko ali s poljubno kombinacijo naštetega.
  15. 15. Postopek po kateremkoli prejšnjem zahtevku, ki obsega spremembo obnašanja operacijskega sistema ali pripadajočih izvršljivih datotek, značilna po tem, da aplikacija » · * ·····«· · · · ·
    Windows Explorer ob uporabnikovem dvokliku na neko datoteko ne nastavi trenutnega delovnega direktorija na lokacijo te datoteke za aplikacijo, ki to datoteko odpira.
SI200900380A 2009-12-11 2009-12-11 Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija SI23251A (sl)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SI200900380A SI23251A (sl) 2009-12-11 2009-12-11 Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija
US12/960,507 US20110145924A1 (en) 2009-12-11 2010-12-05 Method for detection and prevention of loading executable files from the current working directory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
SI200900380A SI23251A (sl) 2009-12-11 2009-12-11 Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija

Publications (1)

Publication Number Publication Date
SI23251A true SI23251A (sl) 2011-06-30

Family

ID=44144449

Family Applications (1)

Application Number Title Priority Date Filing Date
SI200900380A SI23251A (sl) 2009-12-11 2009-12-11 Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija

Country Status (2)

Country Link
US (1) US20110145924A1 (sl)
SI (1) SI23251A (sl)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9268945B2 (en) * 2010-03-19 2016-02-23 Contrast Security, Llc Detection of vulnerabilities in computer systems
US8949991B2 (en) * 2011-01-28 2015-02-03 International Business Machines Corporation Testing web services that are accessible via service oriented architecture (SOA) interceptors
US9527049B2 (en) 2012-06-20 2016-12-27 Bio-Rad Laboratories, Inc. Stabilized droplets for calibration and testing
CN102855430B (zh) * 2012-08-23 2015-04-15 福建升腾资讯有限公司 基于Windows系统的进程黑白名单控制方法
US10284591B2 (en) 2014-01-27 2019-05-07 Webroot Inc. Detecting and preventing execution of software exploits
US10121004B2 (en) * 2015-10-07 2018-11-06 Electronics And Telecommunications Research Institute Apparatus and method for monitoring virtual machine based on hypervisor
CN108629197B (zh) * 2017-03-21 2020-07-28 中国航发商用航空发动机有限责任公司 用于集成环境的文件访问控制方法及系统
US10698666B2 (en) * 2017-12-29 2020-06-30 Microsoft Technology Licensing, Llc Automatically building software projects
CN110879775A (zh) * 2018-09-06 2020-03-13 山东华软金盾软件股份有限公司 一种基于Windows10系统下的截获用户文件打开的系统及方法
CN111208986B (zh) * 2018-11-21 2023-04-07 北京国双科技有限公司 变量的处理方法及装置、存储介质及处理器
CN109726547A (zh) * 2019-01-28 2019-05-07 北京和利时工业软件有限公司 一种文件执行管理方法及相关装置
CN114499962B (zh) * 2021-12-24 2023-09-08 深圳开源互联网安全技术有限公司 文件检测方法、装置、计算机设备和存储介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7296274B2 (en) * 1999-11-15 2007-11-13 Sandia National Laboratories Method and apparatus providing deception and/or altered execution of logic in an information system
US20020178375A1 (en) * 2001-01-31 2002-11-28 Harris Corporation Method and system for protecting against malicious mobile code
US20030140253A1 (en) * 2001-11-16 2003-07-24 Mark Crosbie Method of and apparatus for detecting creation of set user identification (setuid) files, and computer program for enabling such detection
US7669059B2 (en) * 2004-03-23 2010-02-23 Network Equipment Technologies, Inc. Method and apparatus for detection of hostile software
US8108937B1 (en) * 2004-04-26 2012-01-31 Symantec Corporation Robustly regulating access to executable class registry entries
US7587724B2 (en) * 2005-07-13 2009-09-08 Symantec Corporation Kernel validation layer
US7913092B1 (en) * 2005-12-29 2011-03-22 At&T Intellectual Property Ii, L.P. System and method for enforcing application security policies using authenticated system calls
US9171157B2 (en) * 2006-03-28 2015-10-27 Blue Coat Systems, Inc. Method and system for tracking access to application data and preventing data exploitation by malicious programs
US7392544B1 (en) * 2007-12-18 2008-06-24 Kaspersky Lab, Zao Method and system for anti-malware scanning with variable scan settings
US9594901B2 (en) * 2008-12-02 2017-03-14 At&T Intellectual Property I, L.P. Methods, systems, and products for secure access to file system structures
US8341631B2 (en) * 2009-04-10 2012-12-25 Open Invention Network Llc System and method for application isolation
US8307435B1 (en) * 2010-02-18 2012-11-06 Symantec Corporation Software object corruption detection

Also Published As

Publication number Publication date
US20110145924A1 (en) 2011-06-16

Similar Documents

Publication Publication Date Title
SI23251A (sl) Postopek zaznavanja in preprečevanja nalagnja izvršljivih datotek iz trenutnega delovnega direktorija
AU2014348812B2 (en) Improved control flow integrity system and method
CA2465880C (en) Operating system abstraction and protection layer
EP2443553B1 (en) Annotating virtual application processes
US20150163231A1 (en) System and method for reducing load on an operating system when executing antivirus operations
US20060123412A1 (en) Self-describing artifacts and application abstractions
US20130239214A1 (en) Method for detecting and removing malware
WO2014155036A1 (en) Suspicious program detection
US20100186093A1 (en) Portable mass storage device with hooking process
CN103001947A (zh) 一种程序处理方法和系统
CN102999720A (zh) 程序鉴别方法和系统
EP3462356B1 (en) Using indirection to facilitate software upgrades
CN113391874A (zh) 一种虚拟机检测对抗方法、装置、电子设备及存储介质
US8627305B1 (en) System, method, and computer program product for hooking code inserted into an address space of a new process
CN102999721A (zh) 一种程序处理方法和系统
CN102857519A (zh) 主动防御系统
EP2881883B1 (en) System and method for reducing load on an operating system when executing antivirus operations
WO2016126206A1 (en) Method for obfuscation of code using return oriented programming
Kwon et al. Static detection of unsafe component loadings
Erdélyi Hide’n’seek? anatomy of stealth malware
US20220035920A1 (en) Systems and methods for automatically generating malware countermeasures
US8607348B1 (en) Process boundary isolation using constrained processes
US20220035911A1 (en) Active signaling in response to attacks on a transformed binary
US11663333B2 (en) Cloud-based systems and methods for detecting and removing rootkit
US10223413B2 (en) Capturing components of an application using a static post-installation analysis of the system

Legal Events

Date Code Title Description
OO00 Grant of patent

Effective date: 20110722

KO00 Lapse of patent

Effective date: 20180807