Don Giot de Windows interface BM-WII

62 Pages·2015·1.11 MB·Dutch

BM-WII: Het blokkeren van malware door isolatie van
de Windows interface
Don Giot
Promotor: prof. dr. ir. Bjorn De Sutter
Begeleiders: ir. Stijn Volckaert, dr. Bart Coppens, ir. Bert Abrath
Masterproef ingediend tot het behalen van de academische graad van
Master of Science in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Elektronica en Informatiesystemen
Voorzitter: prof. dr. ir. Rik Van de Walle
Faculteit Ingenieurswetenschappen en Architectuur
Academiejaar 2014-2015

BM-WII: Het blokkeren van malware door isolatie van
de Windows interface
Don Giot
Promotor: prof. dr. ir. Bjorn De Sutter
Begeleiders: ir. Stijn Volckaert, dr. Bart Coppens, ir. Bert Abrath
Masterproef ingediend tot het behalen van de academische graad van
Master of Science in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Elektronica en Informatiesystemen
Voorzitter: prof. dr. ir. Rik Van de Walle
Faculteit Ingenieurswetenschappen en Architectuur
Academiejaar 2014-2015
Toelating tot bruikleen
De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen
van de masterproef te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de
bepalingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron
uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.
The author gives permission to make this master dissertation available for consultation and
to copy parts of this master dissertation for personal use. In the case of any other use, the
copyright terms have to be respected, in particular with regard to the obligation to state
expressly the source when quoting results from this master dissertation.
17 juni 2015
Don Giot
iv
Dankwoord
Allereerst wil ik graag mijn promotor bedanken, prof. dr. ir. Bjorn De Sutter voor zijn be-
geleiding doorheen het jaar. Ook wil ik hem bedanken voor het opstarten van de Werkgroep
Ethical Hacking, waar ik mijn interesse voor het onderwerp van software beveiliging kon bot-
vieren. Daarnaast bedank ik graag mijn begeleiders ir. Stijn Volckaert en ir. Bert Abrath
voor hun hulp bij het tot stand brengen van deze thesis en het delen van hun kennis over
de werking van het Windows besturingssysteem. Ik leerde dit jaar enorm veel bij over het
hacken, aanpassenendoencrashenvanWindowsapplicaties, waarikzeerdankbaarvoorben.
Vervolgens wil ik graag iedereen uit de thesisruimte bedanken voor de aangename werksfeer
die er altijd te vinden was. Ik bedank hiervoor graag Jens, Ronald, Jonas en Bart, en natuur-
lijk ook Bert en Stijn, beide reeds vernoemd. Ook mijn twee collega’s op wie ik altijd kon
rekenen om mijn onzekerheden mee te delen, alsook mijn middageten, verdienen een plaats
in dit dankwoord: Joris en Thomas. Ik bedank hen graag voor de steun die ze me boden.
Ik bedank ook graag mijn ouders en broer, die niet meteen een directe invloed hadden op
deze thesis, maar dankzij wie mijn mentale gezondheid geen blijvende schade opliep bij het
werken aan deze scriptie.
Als laatste wil ik nog ´e´en iemand vermelden die me enorm veel steun bood tijdens dit avon-
tuur. Met liefde, Hannah.
v
Het blokkeren van malware door isolatie
van de Windows interface
door
Don Giot
Scriptie ingediend tot het behalen van de academische graad van
Master of Science in de ingenieurswetenschappen: Computerwetenschappen
Promotor: Prof. Dr. Ir. B. De Sutter
Scriptiebegeleiders:
Ir. B. Abrath, Ir. S. Volckaert
Vakgroep Elektronica en Informatiesystemen
Voorzitter: Prof. Dr. Ir. R. Van de Walle
Faculteit Ingenieurswetenschappen
Universiteit Gent
Academiejaar 2014–2015
Samenvatting
Huidige verdedigingstechnieken maken aanvallen via code-injectie zo goed als onmogelijk.
Om deze technieken te omzeilen, wordt de code aanwezig in het proces, en de functionaliteit
aangeboden door het besturingssysteem zoveel mogelijk hergebruikt. Het Windows systeem
stelt deze functionaliteit ter beschikking via dynamisch gelinkte bibliotheken. Een aanvaller
gaat informatielekken binnen het systeem gebruiken om de locatie van deze bibliotheken op
te sporen en ze te gebruiken in zijn aanval.
In deze scriptie worden informatielekken op het Windows besturingssysteem onderzocht op
hoe een aanvaller ze kan uitbuiten. De focus ligt op systeembibliotheken die altijd aanwezig
zijn binnen een procesruimte. We stellen in deze scriptie een tool voor die deze informatie-
lekken moet dichten. De tool gaat informatie verwijderen of encrypteren, naargelang of de
applicatie de informatie nodig heeft om een correcte werking te garanderen. De beschermin-
gen die worden ge¨ımplementeerd zijn werkzaam tijdens de initialisatie van proces en thread,
en worden gebundeld in een DLL.
Trefwoorden: Softwarebeveiliging, Informatielekken, Windows
vi
vii
Defeating Malware Through Windows Interface
Isolation
DonGiot
Supervisor(s): Prof. BjornDeSutter,Ir. BertAbrath,Ir. StijnVolckaert
Abstract—Thecurrenttrendindefendingagainstsoftwareexploitation SoftwareDEP[5],whichiscomparabletoW X,andmakesit
⊕
ispreventingcode-reusebydiversifyingtheprogramorguardingitscon- impossibleforanattackertoexecutecodethatwasinjectedinto
trolflow. However,acategoryofsoftwarevulnerabilitiesthatcanbeused
memory. StackCookies[6]areusedtoprotectaddressesonthe
tocircumventawiderangeofdefencesisinformationleakage.Throughan
stackfromoverflowattacks,whichmakesithardertodivertthe
informationleak,anattackercanexposethememorylayoutofaprogram,
whichinturncanleadtothediscoveryofexploitableweaknesses. Forthe control flow. Address Space Layout Randomisation [7] [8] as
Windowsoperatingsystem,locatingtheDLL’sexportedbythesystemcan
the name says, randomizes the address space and made it a lot
provideanattackerwithalotoffunctionalitytobuildanattack.Inthispa-
harderforattackerstofindimportantmemorystructures. How-
perweexaminedtheaddressspaceofaWindowsprocessandsearchedfor
informationleaksthatmakeittrivialforanattackertofindtheseDLL’s. ever, even with all these defences in place, several categories
Nextweproposeatoolthatpatchestheaddressspaceduringtheinitialisa- ofattacksarestilleffective. ReturnOrientedProgrammingisa
tionoftheprocessoritsthreadstoremoveorencryptthefoundleaks.Only
techniquethatreliesonthereuseofcodethatisalreadypresent
inafewcaseswillthetoolinfluencetheperformanceduringtheexecution
ofanapplication. Thereisalsoanoticeableperformanceoverheadforthe intheprocessaddressspace[9][10]. Informationleaksprovide
initialisationofathread. the attackers with the means to investigate the memory layout
Keywords—SoftwareSecurity,Windows,InformationLeakage andcontrolflowofanapplication,andtofindcodethatcanbe
reusedfortheirattack.
I. INTRODUCTION We narrow this down to reach the subject of this paper. Win-
dowsprovidesitssystemfunctionalitybyofferingasetofDLL’s
Sinceoursocietyisbasedonasoftwareinfrastructurewhere
(Dynamic-link libraries)[8]. An attacker can be sure that these
thevalueofcollectingandprocessingdatagrowsconstantly, it
librariesarepresentintheaddressspaceofanyapplicationrun-
becomesmoreinterestingforattackerstoexploitthisinfrastruc-
ningontheWindowsoperationsystem. ThankstoASLRhow-
ture. Not surprisingly, investing in software security also be-
ever, an attacker will not know the location of these libraries
comes more important to protect against and prevent software
beforehand. ByusinginformationleakspresentwithintheWin-
vulnerabilities. Alargeportionofthesevulnerabilitiesoriginate
dowsoperatingsystem,hecanderivethislocation,andwillhave
from the choice of which programming language was used to
allthesystemsfunctionalityavailableforhisattack. Inthispa-
buildtheapplication. Developinginlow-levellanguageslikeC
per we identify these information leaks and propose a tool to
and C++ is prone to produce memory corruption bugs [1][2],
remove or encrypt them in such a way that it only minimally
due to the lack of type-checking, bounds-checking or too little
influencestheapplication.
attentionforcorrectmemorymanagement.
Anattackerwillofteninjectapieceofcodeintotheapplication
II. INFORMATIONLEAKS
memory. Thispieceofcode,whichwecallshellcode[3],isthe
first step towards altering the behaviour of the program in the Weidentifythreeleaksthatcanbeusedbyanattackertodis-
attackers favour. The shellcode has two tasks to fulfil in order cover the location of the system libraries in memory. A first
tobesuccessful. Firstlyithastodiverttheexecutionflowofthe valuablesourceofinformationforanattackeristheprocessen-
application,whichcanbeachievedbyforexampleoverwriting vironment block (PEB). This is a data structure within the ad-
a return address on the stack [4]. Secondly, it has to guide the dress space of a process that is mainly used internally by the
executiontowardstheinjectedcode,byforexampleoverwriting Windows operating system [8][11]. It holds a range of data
the return address with the address of the start of that piece of structures that are relevant across the whole process. The data
code. structure that we focus on in this paper is the loaded module
A lot of defences have been proposed in the last 30 years to database,whichisastructurewithinthePEBthatholdstheloca-
defend against these kinds of attacks but only a few have been tionofallthelibrariesthatarepresentintheaddressspaceofthe
adopted on a wide scale. For example, Windows implements process. Eachlibrarythatthesystemloadsintheaddressspace
oftheprocessgetsregisteredinthisdatabase. DLL’sgetloaded III. THEDEFENCEDLL
intotheaddressspacewhentheprocessisbeinginitialisedand
the dependencies of the application with these libraries are be- We implemented a DLL that patches two of the discussed
ing resolved (an running application can also load a DLL with leaks, namelythePEBandthevulnerablestack. FortheSEH-
theloadlibraryfunctionwithinthesystemlibrarykernel32.dll). chain leak, we stumbled across a compatibility problem with
The location of the PEB can always be retrieved quite easily, alreadyimplementedguardsfortheSEH-chain. SincetheEH-
whichmeansanattackercanusethisdatastructuretoderivethe recordswithinthechainarealsostoredonthestack,anattacker
locationofthelibrariesheneeds. could use them to subvert the control flow of the application.
A second leak is present within the exception handling struc- He could overwrite the reference to an exception handler and
tures of the operating system. Windows implements a mech- then try and trigger an exception. When the exception dis-
anism called structured exception handling (SEH) [12]. This patcher passes control to the corrupt exception handler, the at-
mechanismusesalinkedlist(theSEH-chain)ofexceptionhan- tackwouldbesuccessful.Windowsimplementeddifferenttypes
dling records (EH-records). Each record holds a reference to of integrity guards to make sure the chain wasn’t overwritten
thenextrecordinthechainandareferencetoanexceptionhan- [13][14], which made developing a patch for it quite difficult.
dler. When the application raises an exception, the exception TheDLLwedevelopedpatchestheinitialisationprocedurefor
dispatcherwalkstheSEH-chaininsearchofahandlerthatisca- boththeprocessanditsthreads.ThePEB-patchsimplyremoves
pableofhandlingtheexception. Eachthreadintheprocesshas the registration from the loaded module database. However,
itsownchainandisbuiltduringtheinitialisationforthatthread. since we didn’t know the impact this would have on the sta-
ThelastEH-recordsintheSEH-chain,orinotherwords,thefirst bility of a running process because the registrations might be
EH-recordsthatareaddedtothechainarealwaysthesameones usedinternallybytheoperatingsystem,wetestedthispatchon
foreachthread,containingdefaultexceptionhandlersprovided severalpracticalapplicationstofindaconfigurationofregistra-
by the system. These default handlers are implemented by the tionsthatcouldberemovedwithoutdisruptingthem. Wefound
systemwhichmeansthereferencesinthelastrecordspointto- thattheregistrationforkernel32.dllcanberemovedentirely,but
wardssystemlibraries. Forexample,thesentinelelementinthe the registration for ntdll.dll could only be removed partially or
chain is the UnhandledExceptionFilter from ntdll.dll [8]. The else the process would execute in an endless loop. This is not
SEH-chainiseasilyaccessibleatanygiventimeduringtheexe- illogicalsincetheloadedmoduledatabaseisimplementedasa
cutionofthethread. Thismeansanattackercouldwalkthrough doubly-linkedlist, whichwouldindicatethattheprocessloops
theSEH-chaintofindthesentinelinthechain, anduseitsref- throughthislistforeverinsearchoftheregistrationofntdll.dll.
erence to UnhandledExceptionFilter to find the location of the OurDLLappliesthesecondpatch(forthestackleak)bymod-
ntdll.dlllibrary. ifyingthefunctionBaseThreadInitThunk[8]whichisthefunc-
The third leak originates from the initialisation procedure of a tionintheinitialisationroutinethatisresponsibleforcallingthe
threadwithinaprocess. Eachthreadisgivenitsownstack. The thread entry point (which is the start of the application code).
problem here is that the initialisation routines will have used Instead of calling the entry point, the function will now call a
this stack quite heavily before any application code is actually function within our DLL that applies two defences to protect
executed. Firstly, this results in a stack that is filled with rem- the stack after which our function calls the entry point for the
nants of stack frames from the initialisation. To put it differ- application. Thefirstdefencewillencryptalltheactiveframes
ently, the memory above the stack pointer doesn’t contain ran- on the call stack at that point, or in other words it encrypts all
dom garbage, but contains possible addresses (e.g. return ad- theframesbelongingtotheinitialisationcode. Thereasonthat
dresses) to system libraries that were involved in the initialisa- wecan’tjustdestroytheseframesisthatthethreadneedsthem
tion of the thread. An attacker could scan the stack in search toexitcleanly,andnotreturningproperlytooneofthosestack
of these addresses to locate the libraries. Secondly, this means framesmightleadtounstablebehaviour. TheDLLalsomakes
that the first call to the application code is not the first call of surethedecryptionisdoneintimebyusingthevectoredexcep-
thecallstack. Thebottomofthecallstackstillcontainsactive tionhandlingmechanismimplementedbyWindows[15]. This
stackframeswhichareframestowhichthesystemstillcanre- is an exception handling mechanism that supersedes the SEH
turnto, belongingtotheinitialisationroutines. Inthiscase, an mechanism and registers process wide exception handlers in-
attacker could walk through all the stack frames by using the steadofthreadspecificexceptionhandlers. Weengineertheen-
framepointerandfindtheframescreatedbyinitialisationfunc- cryptioninsuchawaythatreturningtoanencryptedstackframe
tionsimplementedwithinthesystemlibraries. resultsinanexception. ThehandlerregisteredbyourDLLwill
identify the exception as being one resulting from our encryp-
tion and will decrypt the stack frame and return control to the [7] PaXTeam.Paxaddressspacelayoutrandomization(aslr),2003.
application. [8] MarkRussinovich,DavidSolomon,andAlexIonescu. Windowsinternals.
PearsonEducation,2012.
Theseconddefencedealswiththeremnantstackframesthatare
[9] RyanRoemer,ErikBuchanan,HovavShacham,andStefanSavage.Return-
presentonthestackwhentheapplicationcodestarts.Justbefore orientedprogramming:Systems,languages,andapplications. ACMTrans-
callingtheentrypoint,thisdefencewillsimplycleanthemem- actionsonInformationandSystemSecurity(TISSEC),15(1):2,2012.
[10] Nergal.Theadvancedreturn-into-lib(c)exploits,apaxcasestudy,2001.
oryabovethestack. Byfindingoutthestacklimit,thedefence
[11] MattPietrek. Underthehood: Readinganotherprocessesenvironment.
simplystartspushingzeroesuntilthestacklimitisreached,after August,2004.MSDNMagazine.
[12] Matt Pietrek. Under the hood: A crash course
whichitrestoresthestackpointer. It’simportanttonotethatwe
on the depths of win32 structured exception handling.
consciously adapted the last function of the initialisation since
http://www.microsoft.com/msj/0197/exception/exception.aspx. January,
cleaning the stack any earlier would miss some of the remnant 1997.
[13] MattMiller. Preventingtheexploitationofsehoverwrites. Uninformed
stackframesoftheinitialisationatthethreadentrypoint.
Journal,5,2006.
[14] M Miller. Preventing the exploitation of structured exception han-
IV. EVALUATION
dler (seh) overwrites with sehop. Online]. Dispon´ıvel em: http://blogs.
technet. com/srd/archive/2009/02/02/preventingthe exploitationofsehover-
300 writeswithsehop.aspx.[U´ltimoacessoem:29Nov.,2009],2009.
[15] MattPietrek. Underthehood: Newvectoredexceptionhandlinginwin-
250 dowsxp.MSDNMagazine,2001.
ms)200
me(
Execution ti110500
50
0
No Patch Stack Patch PEB Patch Stack + PEB
Fig.1. Measuringtheinitialisationoverheadforthedifferentconfigurations.
We evaluated different configurations of our patches by
applying them to a browser (mozilla firefox) and running
javascript benchmarks (Kraken, Octane and SunSpider) with
these browsers. The three tested configurations were applying
onlythestackpatch,onlythePEBpatchorapplyingbothatthe
sametime.Wecomparedtheresultswiththebenchmarksrunon
anunpatchedbrowserandfoundthatthereisalmostnoperfor-
manceoverheadwhenapplyinganyofthetestedconfigurations.
Howeverwhenweonlymeasuredtheinitialisationoverhead(as
seen in figure 1), we couldobserve a performance overhead of
morethen33%whichmeansourdefenceDLLperformsbetter
forapplicationswithminimalthreading.
REFERENCES
[1] RichardFateman. Softwarefaultpreventionbylanguagechoice:Whycis
notmyfavoritelanguage.AdvancesinComputers,56:167–188,2002.
[2] Yves Younan. C and c++: vulnerabilities, exploits and counter-
measures. Security Research Group. Retrieved from http://secappdev.
org/handouts/2012/Yves%20Younan/C%20and%20C++%20vulnerabilit
ies.pdf,2013.
[3] JackKoziol,DavidLitchfield,DaveAitel,ChrisAnley,SinanEren,Neel
Mehta,andRileyHassell. Theshellcoder’shandbook. WileyIndianapolis,
2004.
[4] AlephOne.Smashingthestackforfunandprofit.Phrack,49,1996.
[5] J.N.RobEnderle.Thenewapproachtowindowssecurity,2004.
[6] CrispinCowan,SteveBeattie,RyanFinninDay,CaltonPu,PerryWagle,
andErikWalthinsen. Protectingsystemsfromstacksmashingattackswith
stackguard.InLinuxExpo.Citeseer,1999.