Abusing Security Products to Bypass Windows Protections

[Music] hey everybody Welcome to bsides SF day number two glad to have you I know it's still early you know I'm still in bed usually at this time so um welcome glad to have you glad you could make it today um we got some awesome talks again today um starting off off to today um well first of all just want to again thank our sponsors I can see on the the all the signs we appreciate all all that they've done to us done for us um one of the other um want to mention that we have a raffle today at lunch so if you haven't already uh put your business card or name in that uh there's

a couple of Raffles on there one for some fitbits uh one for a GoPro from paloto networks uh fitbits from Fitbit the pal networks is a Pro and we also have some books from no starch press um so make sure to go put your name in the raffle uh sometime before lunch um and you need to be present to win for those uh the other thing um uh let's try to think what else uh yeah so feedback um if you have feedback about the conference you should go to bides sf.com feedback um if you have any feedback about the sessions that you go in if on the schedule there's a feedback survey button that you can click to provide

feedback um now this is sedating The Watch Dog abusing security products to bypass Windows protection um the two speakers are uh toer bitten uh he has more than 12 years of experience in security research he focuses on original research such as Mau reversing hostile code and extreme Packers um his prior role he served as a low-level security researcher at the national electronic warfare research and Simulation Center um they re won an excellence in Innovation awards for complex security pro projects um UD yeah UD Udi sorry I'm terrible at names udy is CTO of ins Silo uh he has more than 15 years of experience in security with a proven track record in leading cuttingedge cyber security R&D

projects um he spearheaded the direction of the cyber security uh unit at the national electronic warfare simulation research and Simulation Center um and served as CTO um and he's done lots of other things so let's give a warm welcome to um the guys from ins Sil thank [Applause] okay so uh first of all I'm sorry about the colors we used a lot of green and apparently it's doesn't show that well uh so let's start you are enough about us so I just continue so uh today I'm going to talk we're going to talk a lot about uh function hooking uh more specifically inline hooking uh we'll talk about the research we did and and uh exactly how those things work how

hooking works and uh then we talk about uh injection techniques and uh some security issues we found we'll do a demo to show that it actually a real issue and uh then present some security tools that we've written uh to uh do this research so just a few things about hooking so generally the purpose of hooking is to intercept the API call and augment their behavior change change what the things they do uh almost every security product out there uses uh hooks in some way I mean anti exploitation tools normally H hook all kind of memory function and post related functions to detect uh exploitation almost a all AV products uh use hooking and personal

firewalls commodor and Zone alarm all of these uh and uh it's also used a lot in uh non-security products uh more a lot of application Performance Tools uh use hooking to monitor the time that takes to functions to execute and things like that and uh also uh Microsoft uh application virtualization technology does that uh Citrix do it a lot lot of products use it and uh Mel does it as well mostly for uh main the browser techniques so what we did in this rearch is that we took about a dozen security products and we checked out the imple the implementation of the hooking uh mechanism the hooking engines the way they inject and uh uh from now on I'm

going to talk about hooking engine which is usually the DL that the security products uh uh inject into the product and uh we also talk about canel to user DL injections because uh these are the techniques that are usually used to get the soing engine into the processes uh which are being monitored by the security vendors so uh uh hooking on 32bit uh processes is uh very straightforward I mean it starts off normally by disassembling the few first instruction of the function prologue then allocate some uh code stab in memory copy the PO instructions to the code stab and then page the patch the prologue with jump instruction uh to the hooking functions which later can use the uh the code stab

to call the original function uh so this is these are a few Snippets from uh windbg of uh uh the way it works uh so this is an example of Internet connect function before it is being hooked you can see it in the upper side of the screen uh it has the uh pretty much regular prologue the move move pushp and uh setting the stock frame and after the hook is set these instructions are replaced with a jump to the function uh that hooks uh that hooks that function uh so if we follow the instructions on the hooking functions we can see that there's a call to the Cod stab in this instance the hooking

functions starts by calling it so this why it's in the start of the function uh and we can see the copit instructions in the in the codes Tab and uh followed immediately with a jump uh to where the code the code of the original function continues uh um so normally 32bit Hing should be uh straightforward but there are other techniques uh like uh one bite patching uh just setting some kind of illegal instruction or break one instruction in the beginning of the function and setting an exception Handler to catch that uh this is usually I guess it's only done by mware I've never seen a legitimate hooking engine that does that uh there's also a hot patching uh

mechanism of Microsoft that they uh use to enable uh patching of security vulnerabilities without needing to update the uh the DLS uh so the way it works instead of uh replacing the entire prologue you just replace the movie IDI instruction that you can see in almost every uh API call in Windows with a short jump the short jump leads to a long a far jump which is located right above the function uh prologue uh however there are some possible complications when uh try to hook even in 32bit uh so these are just a few examples one of them is uh when in a case where we have a relative jump or relative call in the first few

instruction of the instructions of the function this means that the Hing the hooking engines must fix the the instructions before after copying it to the step because the since the instruction will recite in some other address uh it must uh its uh Target must change accordingly uh this normally happens when for when two hooking hin trying to hook the same function uh another issue that uh can happen is that you try to hook some very short function let's say some some function that just returns zero so sorry ax CX and R or something like that and then you don't have enough bytes in the function to set the long jump uh so sometimes it's not really

possible to make this kind of uh hooks uh at least not with the normal method and some sometimes uh you can just disassemble afterwards and see that this instructions are not being used uh the first the third issue here is is a bit more complex and uh what actually happens is could happen is that some uh jump inside the function leads to the prologue of the function not even the first instruction in the PO just let's say the second instruction or the third instruction uh and the problem is that uh when you set the when you patch the prologue uh it it will create illegal instruction for the for the jump now as far as I most pretty much every hooking

engine I know don't doesn't really know how to handle this uh this kind of function and uh even worse is that uh in order to detect that the problem exist you have to disassemble the entire function because you can't tell just by looking at the if this exists uh the good thing is that it's it's extremely rare and uh it as far as I know never happens on regular exported functions uh so uh continuing to 64-bit hooking uh in 64bit the things are a bit more complex because you can't get anywhere you want just with a five by jumps jump instructions since it's limited to uh 2 GB range uh so the process is a bit

different uh start of disassembling the prologue then you usually allocate some kind of trampoline code and the and the code stab you r a trampoline which is usually something like move absolute address to Rax register and then jump jump to Rax and uh copy the prologue instructions to the code stab and Patch the with the jump and when the uh the the jump leads to the small to the trampoline and that's one way to solve it uh we can see in this example exactly the way it's done this time it's Internet connect a uh so before the hook we can see the the prologue after the hook it was uh actually in this case the

hooking engine uh patched 10 bytes from the from the function though it could probably did it in only five uh so there's the jump instruct instruction to some code stabs which is pretty close in address to to where the function resides and uh we can also see there's some kind of Pop instruction over there which I'll explain in a minute and uh and the trampoline code which is exactly what I showed before which leads to the actual hooking function uh so if we follow it the same way I did we did in the 32bit uh we'll get to the code stab and we can see uh that there is an extra push Rex here that's a to accommodate

for the pop uh which follows uh so this is pretty simple as well uh there are other techniques to make uh to to do to achieve this uh one uh nice technique is to push a 32-bit address and then return this only takes six bytes and uh uh it's only requirement is that the uh hook that the hooking function will be in 32bit address or that the uh if you if you are able to to do it uh just put uh a trampol line in a 32bit address uh another technique which preserves all registers the format techniques I I showed don't preserve all register because it has to use RX in order to do the jump so that's a nice te Click by uh

Nikolai uh the way it works is by pushing a 32bit value to the stock because it's a 64-bit machine then 8 Bits n eight bytes are going to be allocated on the stock then uh push the high DW uh set the highd world in the in the stock and return which is uh which is absolute jump to 64-bit address with without changing any register uh so uh the complication in 64bit hooking is pretty much the same like in 32 bits the the main difference is that there are much more instruction which are uh relative to the location of the instruction because 64bit assembly supports uh RP plus offset address in uh so those need to be handled as well by

the hooking engine so just a quick recap the inline looking is probably the most uh common method used in uh real life products it's rather intrusive uh and exist in most endpoint products to you can follow those links to read more information about hooking hey guys um so Kel injection techniques um Kel injection techniques mainly used to inject DLS from the Kel to user mode processes um it's also very common in sandbox Escape shell codes after a successful exploitation of a privilege escalation vulnerabilities and also to inject code to protected processes um there are much less technique than user mode than user mode injections and it's much less documented um than the user mode one um it's used

both by malware and security [Music] vendors um the user APC is basically is the most common Kel injection technique used uh it's used by several Mal families like zero access like TDL um and as I said also in Shell book uh sandbox Escape shell codes um and ve very common in security vendors like antiviruses like AVG Kaspersky and also uh application performance and application monitoring uh products um searching Google you can find a very well documentation uh on the technique and also some uh leaked source code um mainly for malware samples and uh and families um so basically it's very easy to the implementation is very easy all you need to do is register load image

call back using a notify routine um then you need to write a payload that will load basically that will load a DL using the LD o dll or load Library functions and then use the APC function the initial and the insert Q APC routines in order to get code execution so this is how it looks like from a leak source code of of TDL um so in this function basically we uh we set uh the load image callback you can see the function uh SEL in red after that this is basically preparing the payload this is the dll which will be injected to the Target process um here you can see that the virtual AOG basically form the kernel so

allocate a memory ins inside the target process and then you can see the S strr copy basically copying the DL from the disk to memory and the last section is using the initialize um and insert Q APC routines in order to get the code execution if you check on the right side you can see the the load Library um and the inmemory uh parameter is and the inmemory DL as the parameters entry point patching um it's a very interesting technique it's not very common but we think it's very interesting H it was first as far as we know it was first used by Dooku by the Dooku malware um you can find here the link you can you

can go inside there is a full documentation of the malware and the technique so the implementation is B very easily basically you need to set a load image call back uh using the notify routine and wait for the main module to load once loaded you need to write the payload inside the target process and then you need to replace the image entry point with a jump to the payload once the payload executes all you need to do is basically restore the code of the original entry point and jump to the o to the original entry point the second one so this is how it looks like in a patched Internet Explorer if you check on the left side you can see the jump

instruction this is basically the code that this is the patch function and if we take it from the right side you can see there is a jump if you follow the jump you can see uh the function prologue the push EVP Etc and then there is another jump so if you follow the jump you can see it's Cel in red the first one and there is a combination of the load Lo load library and M Copy functions basically it will load the dll this is the hooking engine um in the middle there is a there is a use of the M Copy M Copy routine in order to restore the original bytes of the entry

point and at at the bottom there is a jump to the OE to the original entry Point UT table uh patching it's it's a very another very interesting technique um as far as we know we were the first one to published it last year in besides Las Vegas uh before that it was undocumented um as far as we know it was never used by malware all only in security vendors um like CCH like truster and the Microsoft Microsoft opv um a very similar uh method of implementation can be used the TLs data directory instead of the input table so let's see how it looks like um so again you need to register a load image call

back using the notify routine and wait for the main module to load once the main module was loaded you need to allocate a memory um inside the target process for the new table um and then you take the old table with the new row the new record inside and copy to the uh new allocated space um you need to point the input directory uh RVA to point to the new table and once once it's done once the DL is loaded all you need to do is fix um basically the AV of the input directory to point to the old table and the DL is loaded so this is how it looks like in in a patch to

Internet Explorer on the left side you can see that the import directory RVA is basically pointing outside of the image and on the right side you can see the new row that was added to the table this one and we call it anti D us user 32 patching technique um it's a very interesting one it's used only by security render we saw it um a few months ago um the technique is basically based on again register load image call back using the notify routine and we need to wait for ndl to be loaded once ndl is loaded we need to write the payload to the Target process um once it's done we need to replace um the prologue of LD load

Library um with a jump instruction basically the jump will point to to the payload and once the payload is lo once the D is loaded the payload is loaded uh you need to restore uh the original bites of the LDL L dlm and jump to it so this is how it looks like in a debugger um I know it's hard to see but believe me um this is a patched uh this is a patched fun function from Uso 32 uh dll um there is a move a move address to and then jump to a ex um so once the jump uh is done we can see another jump you have a few nobes and then another

another move address to aex and then jump eex register and then you jump to the payload inside the payload you have a load Library which will which will basically load uh the dll of the of the antivirus in this case um from a full path so a quick summary so kernel injection is mainly used to inject DLS from the kernel to use mode processes very common in antiviruses and security products and also in malware um for security products this is the way they load the hooking engine basically this is the dll um in order to intercept and do whatever they need inside the process memory um because of the imple the complexity of the implementation they

are PR to lots of mistakes okay so uh what we did is uh to look for a Poss security issues in the way these things are implemented so uh we will we saw about six issues and uh the first one is uh unsafe injection methods so uh some of the implementations uh instead of loading a DL from absolute path use the relative path to the DL this means that in the techer can just uh uh put his own DL in a in the Target in in a hooked process folder and the security product will load the tech D instead of his own DL this is a classic Ding and uh it's a nice way to gain

persistency because uh and to disable the the specific security vendor in the specific process because uh each time it's loads the security product will not load and the attackers will be there uh another issue that we saw is that uh well that was this was only one vendor and uh it's uh it's a bit weird that they chose to do it uh but they put in the app data folder under local vendor uh the DL that's been injected to every process in the system uh and it was not protected in any way not by a driver not by permission no protection at all so uh this also can be easily replaced by an teer and be used uh to get consistency

on the mine so we think that's uh has quite High severity because uh it's so easy to do those things uh and it's a bit negligence by the by the vendors that these things can happen uh another thing that's quite severe is that uh it happened at least in two vendors that we saw is that the the canel to user injection mechanism allocated in a constant address writeable and executable memory uh which means that it practically bypasses uh uh Windows protection I mean aslr can easily be uh bypassed because uh those uh code stubs normally contain pointers to critical o functions for example the library uh memory functions like uh anti virtual allocate memory anti virtual

protect memory uh all these functions so when can directly call this and uh and use it so aslr is pretty much meaningless in this case uh and the attacker doesn't really even have to allocate his own uh uh code stops in memory because he can just reuse the writeable code steps that the vendor set set up for him so it makes exploitation much much easier all you need to do is to write to a constant address uh the code uh and find a way to jump to it if this place is uh contains a uh hook stabs so overwriting some hook stab means that the next time that the this function is going to call be called the the teer

code will execute uh this is a a really bad issue um so uh another thing that we think it's quite uh quite severe is the uh to allocate Cod the predictable address even if it is not writable uh the reason that it's problematic because it's still uh practically bypasses SLR uh it's uh the techer can normally bypass the hooks so because all it needs to do is to call the the code the Cod stabs and in all the cases we saw they were on a constant offsets which means that uh uh in order to let's say bypass some anti exploitation uh uh vendor that uh hooked let's say virtual protect function all you need to do is to call

the right the the offset in the in his code stabs uh to to call the functions and completely bypass the the protection uh and also some of the code can also be used as part of a rchain uh normally the r chain can be really simple because uh you are already have all the functions uh you want in a constant location so building it is far easier than uh the normal scenario today um so uh the next uh the next two issues are a bit uh not that severe but still exist and that's the leaving the code stop themselves writable and executable uh so a teer that gained the ability to read and write from arbitrary

memory can probably use that to bypass control flow guard uh in Windows by uh uh just overwriting the hook stab and uh then uh causing the function to execute uh because the control flow guard uh allows the attacker to call uh fun uh functions uh uh prologue so it will just execute the te care code uh generally we don't think it's that much of an issue because uh a teer that was able to get arbitrary read and right will probably succeed to execute code anyways so uh but still uh we don't we don't think that security vendors should uh should add the issues to the uh add possibilities to the attacker uh and another thing that we

saw which was a bit surprising because we didn't even look for it uh is that some vendors leave the actual hooked functions as writeable uh this is not that significant as well because it can probably be used only to bypass CFG or something like that but uh it's probably shows a bit laziness by this this kind of vend because restoring the protection on the page is just making another call and uh apparently some of them don't do that um and that's uh pretty much it so now we're going to go on to see a demo and the way it can be exploited in a real life

scenario okay so let's see how it looks

like perfect okay um so hopefully you will be able to see everything um so what I have here basically is a Windows 7 I have one of the um one of the top five antiviruses installed here um so let's see the vulnerability basically let's open a US mode process let's take Adobe for an example you can see it right okay um let's open immunity debugger let's attach to the process

great okay let's go to memory and we have it here you can see basically this is the address yeah I know it's a problem but again believe me this is the address that was basically um this is the code Stu that was injected from the Kel so it's an constant predictable address um the permission is read by execute so basically what I have here I have a full page let's go inside and you can see the stab okay so you can see the stab at the top um I don't know a few bytes and then you have a full page read write execute I can go down and you can see that I have lots of space basically what I need

to do is just take my shell code copy to this space and I can override the stab of the antivirus if I if I want if not just copy it uh to another offset and then jump to my payload and we are done um so let's see how it looks like so I have the PDF let's give it some execute okay let's open a PDF file okay I have it here let's put a break point when a new dll is loaded so we can see the rchain break on new module okay let's load the

dll okay we need to wait basically till ICU cnv which is this is the DL we took the r Gadget uh from um so let's wait till it will load it will take a few

seconds I guess you can't see the name okay I think in the 2DS one

more

okay okay and another one okay so ICU CV basically is loaded um so let's go to CP VI let's put a break point on the first Gadget and we have it here okay let's give it to execute and now the D is loaded and the break point was hit so we are on the first Gadget um let's step inside second Gadget third another one another one and this is the most interesting this is the rep instruction so basically right now I'm taking my shell code and copy it to the allocated space of the antivirus so I have it here let's go and follow the address in the dump um so you can see it at the bottom uh if I will go up you can

see the stab this is the stab of the antivirus and again I have a full page so I I didn't want to override the stop so I want it to be nice um so let's give it let's put a breakpoint after the rep okay and you can see the Shell Code at the bottom here okay so let's give a few instruction another one another one another one and I'm inside the Shell Code let's give it an execute and I have the Cal so basically what we did there was a predictable read write execute uh page a full memory page inside uh a US mode process it was allocated by by the one of the antiviruses that I have it um

so again full page just just took the Shell Code few rope gadgets copied uh the Shell Code inside the memory and executed let switch

back okay so just just a small recap of uh the things uh we talked about uh um it's uh about six security issues that we saw and uh in in different hooking engines and uh to for for for This research we developed a few tools to make it easier for us I mean debugging each hooking engine is the and installing each of the vendors is it's pretty time consuming so we Tred to automate it as much as possible so the first tool we wrote was meant to find the places in memory which is readable writable and executable uh you can get this tool in a in a website and well it's pretty simple all it does is to compare memory maps of

the of processes I mean you just open Internet Explorer take all the places in uh Internet Explorer where there was uh executable writable memory and then compare it to another instance of this process um to be 100% certain that the issue exists you should usually reboot the machine uh and uh this is uh the way we we saw these issues uh and uh another tool that will be released uh uh shortly is a tool to scan and uh to scan for a hooks in a process and uh try to track the code in the hooking function as best as we could it's like B best effort I mean uh to detect hooks what we did is to compare

the uh inmemory image to the on disk image so whenever we found and exported functions with some kind of diff in the prologue uh we started to try to trace this code and get all the related the code chunks uh and we also checked for each of these functions if the code of the function itself is writable and executable and then you get a a nice table of potentially unsafe locations uh there's also a bit manual work I mean uh uh you have to do it a few times to find constant addresses uh to to find issues like predictable memory locations and things like that that uh and uh that's pretty much it so uh just to sum things up uh so almost

every vendor has this capability and one of the funny things that we saw is that most of them Implement uh their own Hing engine from scretch and that's a that's a bit weird because there are a lot of Open Source uh engines out there and there also commercial uh hooking engine out there and still each vendors try to uh develop his own hooking engine and his own Canal injection methods uh which probably the reason that uh uh most of these issues exist especially things like the we saw in the in the first issue with the uh unsafe injections I mean those are issues that were that are known for years now and doing that just means that

uh the vent pretty much neglected this entire aspect of the of the injection and the and hooking into the processes uh and uh generally we think that when Vendo do uh complex and intrusive operations they should also security do some kind of security audit for this because some of the things were really easy to find and some of them were surprising I mean when we started this we never expected to find something like predictable readable writable executable uh this is clearly a bad practice which pretty much bypasses lots of mitigations that Microsoft uh uh tries worked hard to put in the in the operating systems uh we also found issue in almost every vendor we tested I mean uh the

only reason that we not mentioning names right now is because not all of the issues that we've seen are fully patched most of them already are most of the vendors were also very uh cooperative and uh uh and the work was uh uh was working with them was great but uh uh the funny thing was that on some of them it was quite clear that the security uh uh research team is not part of the process and probably only the development team was part of the process because on at least two or three of them uh we got uh the same issues after the they gave us patches to to retest and so for example for the predictable writable

executable code uh we got a patch and they just removed the writable bit from the from the location so you still had uh Place uh you can reuse code and by SL SLR with uh so the clear solution to this kind of uh thing is to just uh free the memory after you finished injection there is no reason to leave it there and it still took three Cycles until it's totally worked and this happened several vendors uh and uh so that's pretty much it uh we're going to release all the details and all the uh extra the things that that are kind of missing gu now in in a few days and if you have questions

now is good

time you have a

question I'm sorry I can't hear what you

saying

someone inject to the tool itself um actually the tool scans itself but uh uh so unless someone T Cod ah okay sorry so the hook scans itself as well but so if if it was hooked it's on its own so it should be detected but uh it's not something we really put a lot of effort into [Music] so thank you thank

you want to thank our speakers appreciate it and again on uh behalf of security bides and Fitbit you want to present you with these fitbits thank you very thank you thank you so much sorry about the pink screen on the other good is

[Music] yours [Music]

now