Vulnerabilities in Application Whitelisting: Malware Case Studies

[Music]

All right. Hi everybody. Thanks for coming to the vulnerabilities and application whitelisting malware case studies talk. I'm Jared. This is Joe. Make sure you talk nice and loud. I mean seriously cuz I don't think we have microphones working in here, right? Can everyone hear me? Loud. No. No. We're happy to be here at Bsides Las Vegas. Thank you for hosting us. Seriously, it's our first time in Vegas or you haven't been to Blackhead or Defcon before. We're happy we got to the chance to speak here at Bides. Uh we greatly appreciate it. Uh you know, the proving grounds is our chance to try and get our faces known. Even if you don't like our faces, hopefully we can stick

around and do this some more. That's about it. Thanks for comment. Seriously though, this is uh one of our first talks. So, uh I'm all about trying to be positive. So, high five. And then we'll get into the meeting. So, today what we promise you, we'll talk a little bit about malware as a threat. We'll talk about application whitelisting and the inherent vulnerabilities with that type of security. We'll show you two demos of how you can break application whitelisting using persistent malware. And we're going to talk about some situ security suggestions so you don't have to get home. In case you didn't know, it's dangerous out there and there's a lot of malware out there.

It's a fat squirrel. It is a fat squirrel. Just make sure it's it's symbolic for the a lot of malware out there. Problem is as security people malware avoids all your conventional security measures. It's not really anything new but it keeps happening. So different approaches are created by some people in these rooms. And two of the ones that are, you know, talked about a lot is application whitelisting like a white alligator and behavioral analysis. But the malware issue still remains. These two types of solutions have not been widely adopted yet. So you're still relying on the conventional anti virus, your firewalls, network security to try and solve what can be an endpoint security problem. So what we broke it down to is four

types of malware techniques that can uh the impact they can have on new security solutions. And what we think malware can do quite easily is one cause unwanted behavior. So as soon as it gets the the machine, it can make the machine do things it wasn't intended to do and have that be disturbing your productivity or the system's productivity. It can disable the security product you actually put on the machine by attacking it outright. It can bypass the means of detection and it can also uh directly alter the security product and make it its own almost. So with that we come up to the topic of application whitelisting. I'm going to turn it over to Joe and he's

going to do the demos for you and I'll pass out licorice. Hello everyone. So there we go. All right. So we're going to be talking about application whitelisting specifically here. And for those who don't already know, application whitelisting is kind of taking the opposite approach of signaturebased antivirus. So instead of assuming everything you don't know is actually safe, you're going to assume everything you haven't explicitly said is safe is an actual danger. And this is accomplished in one of a few ways, but generally it'll have either some sort of prevention mode where something that is unknown isn't allowed to run at all, or there might be a prompt mode where it'll ask the user if something unknown wants

to run, do they want them to allow that to run? Or it'll just outright uh audit the event, allowing it to run, but at least giving that information back to a security department. So, this approach does have some legitimate advantages over blacklisting solutions. Uh, it's capable of stopping zero days because zero days are new pieces of malware that you haven't seen before. Um, it is also able to block things regardless of how they were launched. So, it doesn't matter if a user is downloading it from a uh is if it's a driveby download attack or if it's some sort of malicious email or anything of that variety, it's going to work. So, even though it's

quite effective in some ways, there's still ways to beat it. um even in its most secure mode of operation where it's blocking things in real time. So, a few ways you can go about it. First, you can be on the computer before that product's even installed, which gives you the ability to either block it from being installed in the first place. So, if you see an installation fail, you might automatically assume that a security product isn't designed very well, yell at the vendor, and then just continue on your way. or it might modify the installation in some way so that it grandfathers in all that malicious software that was there presently which is typically the way application

whitelisting products work. If it was already there it's going to allow it to run. Uh another way to bypass application whitisting is to exploit an existing application that you said is legitimate. So you might have something like Internet Explorer, Microsoft Office, Adobe Acrobat, Java. All of these are vectors by which clever individuals are capable of running malicious code that runs on the endpoint. And then the other two ways um that compromise this and that these aren't the only ones but uh that we'll explore in the demo is to look at the certificate based exploits those signing certificates that are used to authorize applications to run on the system or to simply take advantage of the

architecture of uh application whitelisting solutions in order to slip your own kernel level driver underneath. So with that, we're going to switch over to the demo portion and hope it actually goes accordingly. So what we have here is a VM that I've loaded with an application whitelisting product and I tested a few different ones. These techniques are accomplished in different ways but uh able to be run against all of them um for for the purpose of the demonstration and not to pick out any vendors. I'm not displaying which one it is, but you'll see kind of the consequences of it. Um, now there's a few assumptions I'm going into here just because we don't have time to cover

it in great depth. Uh, first of all, I'm going to assume that some malicious code is able to take place or some malicious action is able to take place. So, either you've exploited an existing application on a computer, you've hacked directly into it in some way, have physical access to the computer, something of that variety. Uh second is that when you're taking those malicious actions, you have some administrative access to the computer and then also you're able to either bypass UAC or uh trick a user into allowing those behaviors. So the first thing we're going to do is just show that um application whisting solutions are going to allow legitimate applications to run. And the way this is

often accomplished is to say, okay, this is a certificate from a known uh legitimate software organization and we're going to permit it. So in this case, you got Procman uh released by CIS internals. It's trusted. I added it to the certificate store that this particular product uses to authorize applications to run on the system and it's going to allow it to run. Uh from the outside, it might look like a malicious piece of software. It's installing a driver. It's monitoring a bunch of activities on the computer. uh cross loop. It's an RDP application. Again, we added its legitimate certificates to the certificate store for this product. I have them listed here. Uh and then it allows it to run.

Then we have this fake malware .exe I created. And when you try to launch it, the application whitelisting product is going to intercept that attempt to execute the product and say you don't have permission to do it in this case. So this application isn't going to get to run its malicious code on the system. It does that because it does not have a current signature for it saying it's a legitimate application nor does it trust the particular certificate that I put on it. So you know I created the very legitimate digital certificate from the fake malware. Uh but since this is not a trusted one it's not going to allow it to run. Similarly we have this other

application that has no digital certificate on it and if you try to run it it's not going to work. So what we want to do is we want to exploit the fact that these products are reliant on these signing certificates in order to authorize legitimate applications. And the way we're going to do that is we're going to change where this product looks for its certificates. So what I'm going to do is I'm going to redirect this particular product certificate store to the uh fake search store that I've put on the desktop. And what I'm going to do now is move the legitimate or the uh malicious certificate into here. And then then I'm going to put in a registry key

that causes the switch to happen. And then we're going to restart the computer, see what the effects of that are. So the reason the reason this happens is because in order to keep a list of what's allowed to run on the computer, it needs to keep some local version of it. If you don't have a local version, it doesn't know what's allowed to start at boot up time. So by taking advantage of the fact that it's stored locally on disk and working around that, we can point it to a new location. So in this particular case, I've created a search store on the desktop. I've changed some settings in the registry and on the file system to

point to that location. And now it's going to be reading from a location I'm capable of altering directly because most of these products realize that these certificate stores are an important area of the computer. and if they're compromised in some way, it's going to be an issue. So, in order to um you know, they'll put in protections like if you try to drag a file in there directly, it's not going to work. Uh but they usually don't go to the extent of uh protecting against some of these more aggressive registry based mechanisms or file permissions based ways of modifying it. And then what you're going to see is when we come in, we're going to have the

ability to accomplish a few things that you would deem malicious. So we'll log in here first. And the first thing it can do with control of a certificate store is to perform a denial of service attack. So you have legitimate applications that you want to be running in your environment. They might be, you know, things as simple as Microsoft Office or other security products you're using. So my fake search store doesn't have the permissions for any of the uh for the proc or cross loop uh applications. So if I go to run these all of a sudden I can't run these legitimate applications that are needed in my environment which is at the very least a inconvenience uh but can do

widespread damage. And from an outsider perspective, is there a convincing way for you to know that this isn't isn't a failure of the actual security product, but someone had actually hacked it? And the answer to that in most cases is no. Um, the more malicious thing you can do is put in the uh a certificate for a malicious file you have controlled. So in this case, we have this fake malware .exe and now we're capable of running this where we weren't able to run it before. Um, now we didn't add any sort of certificate for this other one. So, it's going to be blocked as usual. But what this allows us to do is subvert the

sort of protection that was being offered just by taking control of this search store. So, you might not want to deny, you know, you might not want to deny those legitimate applications to run because that might be a clue. So, we'll add those back in. Now, these are able to run again slowly. So both of these are able to run again, but I'm also able to run my malicious application anytime I want, add new certificates to it anytime I want. And basically I have control over this system without any sort of additional measures necessary and in a way that if you don't go and put fake search store directly on the desktop is probably going to go undetected by your security

organization. So that's kind of the first part and that's one of these particular exploits you can put into effect. Uh for another one, we're going to actually take advantage of the um we're going to take advantage of the uh we're going to take advantage of the architecture of these products. So what we're going to do is these these products are designed with driver drivers. They all have a kernel level driver that's responsible for uh intercepting any call that happens to launch a file. And when that happens, they investigate the file, see if it's a known legitimate one. If it's not, block access to that particular file and don't allow it to run. Now, this effect is

particularly effective because kernel level drivers load at a low level. Uh, but it does have some additional issues and can be uh broken. So if you're capable of in manually inserting a driver at a lower level than where that other driver was loaded, the legitimate security one, it's going to get all of those file system calls before you ever have a chance to take a look at them. And that's what we're going to do here. We're going to subvert that sort of mechanism by putting ourselves in at a lower altitude. Before I continue, are there any questions about either the initial technique or sort of how these drivers work? You're you're assuming an exploit before you get to the desktop that you

want to attack. You're assuming an exploit at the AD level or console level to get to the management console for the application whitisting service. Okay. So you asked if it we're assuming that you're a capable of exploiting or you assume that we have to exploit something at an Amy level in order to accomplish this. uh because it's stored on local file system storage, having administrator rights and then escalating is going to allow you to compromise that without requiring any credentials. And then from that position, if you really want to and now you're going to steal passwords and credentials. So, um were there any other questions? All right, cool. So, we'll continue from there. Um we'll just to show real quick

uh the the product's back to working in its full capacity. It's blocking the malicious file. And what we're going to do is install our own driver at a lower level. And um some of you might be familiar that Windows 7 has put in measures that don't allow you to run a driver that hasn't been digitally signed. And the idea is well, if it hasn't been signed, you know, you're not going to be able to get your malicious piece of software signed. So that's going to offer some level of protection. Now, there's some clever people who have gone around this, but I found there's a more elegant way to approach it, which is simply take advantage of the fact

that there are legitimate drivers out there that you can take and repurpose for your own needs. So, because drivers are so difficult to write and if you have any flaws in them, there's entire companies that have products that just extend driver type functionality to lower level or to higher level processes. So what I did is I took one of those specific ones in this case uh called callback filter and I'm going to use its driver to um perpetrate my exploit. So what I'll do first is I'll move the driver into the system 32 directory drivers folder where most drivers end up. Then I'm going to add a registry entry that creates the um creates the entry for the driver service

to run properly. Then what I'm going to do is create another additional entry that's necessary for drivers specifically. And if you try to do it on your own, what you're going to see is that Windows is going to block it. It's going to tell you you can't directly access this area of the U registry. And the reason for this is because they want to force you to go through their driver mechanism in order to sort of verify that you're dealing with a legitimate driver. Uh unfortunately, the method of protection is particularly weak. So if we go into permissions, go to advanced and take ownership of the registry key ourself, we now have the ability to control who and what is

capable of seeing these particular uh or modifying these particular areas of the registry. So all of a sudden this entry we couldn't add before now can be added. And then for additional measure, what we're going to do is show that uh with this driver, I'm capable of denying access to certain things. So just for a real simple demonstration, we're going to deny access to a very specific text file on the desktop. So I create a demo text file that you're uh capable of reading now. And then I have another one that we'll use kind of as a control to show that those are still visible on the computer. So what we'll do now that this

driver is in place is we'll try to load it into memory. And what you'll see is that the application whip listing product is still working. So we're not going to be able to do it. So Microsoft gives you this way of loading it. Um from the command line, you can try to load this driver into memory. And what it's going to say is that access is denied. So it's going to tell you, okay, you can't load this particular driver into memory. I know it's something that's bad. You know, we're not going to allow this. Unfortunately, because we took advantage of the fact that this driver is going to run at a lower level, we're going to be able to

um come in before the application whitelisting product has an opportunity to block it the next time we come back into Windows. So, what can you do when you put a driver in at a lower altitude than these other drivers? You're capable of modifying. Well, you get the first crack at any information. So any file that's open, any folder that's open, registry modification, things of that variety, you're capable of not only seeing, but you're capable of modifying the output. So the information that gets received by an application whitelisting product is now completely within your control. So you can exhibit or you can implement rootkit type functionality on the computer. And from that point, you basically can mask whatever malware you

want, add new things onto it, download new things, doesn't really matter at that point. you you pretty much subverted any protection that has been in place at that point. And the reason you can kind of get away with this is security products play by the rules. They're supposed to sit at a certain level, certain altitude uh of where they run, but when you create a malicious driver, you're not bound by the same restrictions. You can go to a lower altitude and know that you're capable of taking advantage of that. So what we do here is come back in and then we try to launch the uh we try to load that driver into memory again. Um

before I do that, are there any questions? Okay. Uh the rec files you just imported uh very simple. The first one just registered the service. Yep. Yeah. First one registered the service. The second one registered the driver element of the service and the third one was a uh productspecific way of um denying access to a particular file. So what we'll do now is open up that command and we'll try to load the driver into memory and it's going to tell you an instance of the service is already running because now it's running. So you have this application weight listing product. It's still doing its job. It's working as intended, but it's not stopping this very low-level extremely powerful driver

that you managed to slip in underneath it. And then kind of the, you know, you can still see the the text file for comparison purposes, but if you try to open this text file that I've restricted access to specifically, now all of a sudden you can't do it. So, this is just one way of demonstrating that you kind of gain control over the computer and can now, you know, deny access to files, make them appear as though they're all their files, make them appear as though they're signed by a different authority than they actually are. There's a tremendous amount of confidence you have that in place. So, that's the uh demonstration portion of the u of the

talk. Are there any questions around the demonstration? All right, cool. So the point of this is not to be all like doom and gloom about it. The reality is any security product is going to have some sort of vulnerabilities associated with it. And it's what you do with that knowledge that's really important. And to that effect, you know, if anyone has, you know, their own experiences they want to reflect on here as I'm going on, think I'm completely off base on something, please call me out on it. Feel free to interject whenever. But I from the view of someone who writes security software for a living, this is kind of my takeaway from uh dealing with products that are going

to have vulnerabilities. Uh so the first thing and most important thing in my mind is to educate yourself on the technologies you're using. If you don't do that, you're kind of screwed. Like you don't know what you need to protect against on your own, what additional measures need to be put into place unless you have an appreciation for how these uh products actually function. And for me, I think the best place to start in that sort of uh in that sort of exercise is to actually go to your vendor and talk to them directly. Ask what vulnerabilities are present in the product. What do I need to do in order to better secure myself when I'm using this? Uh, from my

perspective in the industry, it's, you know, I'd love if more people would come and approach me and ask those sorts of questions because you're able to have a much better dialogue and see if the product's an actual fit for an environment when you go through that sort of exercise. So, I think that's kind of the first and most important step and for me, you have to know what kind of questions you want to ask. So, the first one in my mind is what inherent vulnerabilities are present in a specific approach. So, and by inherent vulnerabilities, I mean what is what are they designed to do and what are they designed not to do. You know, you're

going to be in a bad position if you expect signaturebased um you know uh AV to protect you from unknown threats. It's not what it's designed to do. If that's your expectation, you're putting yourself in a bad position. So, reach out, ask where those vulnerabilities exist. Um you know, with AV, it's unknown malware. with application whitelisting. It might be exploiting a whitelisted application that you previously allowed. Then with that information, you can kind of ask go to the next step which is you know what vulnerabilities are exposed from these ease of use features. And by that I mean when you have when you engage some of these like management features that are supposed to make it

easier to manage your product or have less impact on the end user. A lot of times they're there to make your life easier but expose additional security vulnerabilities. Uh the certificates are a great example of this in the demonstration. It's exceedingly hard to manage an application whitelisting product without these sort of signing certificates that allow you to um allow you to authorize legitimate applications. But those same certificates can create a giant security hole, you know, and kind of on a little rant here. Um like public key cryptography is a excellent technology of what it's designed to do. It's, you know, the backbone of a lot of important uh, you know, web based and networkbased transmission. The problem is, I think

there's this temptation in the industry now to misuse it or use it in a way it wasn't originally designed to do. You know, public key cryptography is supposed to say, let's take a trusted point A, a trusted point B, and ensure that this untrusted connection in the middle is capable or isn't capable of tampering it with it in some way. But this breaks down if you no longer trust your point A. In this particular instance, that's your vendor. If your vendor has in some way been compromised, you can no longer trust their digital signing certificates. And Stuckset is an excellent example of this as a way of compromising an organization. It went into J Micron, took its digital signing

certificate, signed a piece of malware with it, and now products that thought that J Micron certificate was safe or allowing malware into their organization. And these organizations, these software vendors are typically some of the most difficult ones to secure because you're dealing with a lot of administrators. You're dealing with environments where there's constantly cho code turn. So you always have new executive roles. you always have um really low-level functionality that needs to be exposed and used for these people to do their jobs. So trying to protect them with AB is not going to work. Trying to put an application whip listing product in is going to be difficult and even behavioral methods can fail. So these

are particularly vulnerable organizations and you know even one step further people who are developing particularly sophisticated malware tend to be good coders. So if they really want to go get a job with an organization that has a particularly valuable science certificate and infiltrate from the inside in order to gain access to it. So that's kind of one problem with it. And then if you don't trust your point B, which in this case is an endpoint to give you a valid reading of that certificate, then you can't trust that you're not running malicious code on your computer. And the demonstration is an example of that. you were able to kind of trick it into uh certifying code on the endpoint that

shouldn't have been trusted to begin with. Um so those are two like two areas where it's to ask about vulnerabilities in the product and then kind of the next one I think is important is how are how can the product be attacked directly. You know, above all, a security vendor should know what how their product is capable of being attacked. And it's an increasingly common tactic among malware to simply go directly at the security product because a product that is not working or not reporting is suddenly not of much use. So if you don't know how it can be directly attacked, you don't know what you need to protect against. Um, so ultimately this is this is one of these

difficult conversations because I think most security vendors aren't really willing to discuss these things openly and the industry kind of needs to take more of a hard line on it. You're not in a position to do your job properly if you don't know where these vulnerabilities are. So there needs to be a better dialogue between vendors and a willingness on their part to actually disclose the information. And I'd say to take it as far as you can to a certain extent. If a vendor is not willing to you know under NDA with all the prop appropriate uh precautions in place tell you what you need to do to secure your organization with their product then

maybe you want to look elsewhere for your security needs. So next once you have that education what do you do with it? Because it's you know it's not enough to simply know where the vulnerabilities are in these products. you actually have to kind of take it that one step further. And I think it's tempting, you know, and you know, you get your shiny new toy, you just want to play with it, put it out there, and not really worry about it. But the simple fact of the matter is there are steps that can be taken by you to better protect yourself uh when you know what these vulnerabilities are on specific products. So going back to sort of the

vulnerabilities I pointed out, inherent vulnerabilities are particularly tough ones to kind of solve on your own. These are, you know, you're either forced to choose whether or not it's worth investing budget into finding or buying an existing product in order to meet a need or using some existing tool that exists within your organization in order to cover the deficiencies of that product um or even developing it yourself. So, you can attempt to do that, but this is probably one of the trickiest areas to make any sort of progress. Um, I would advise, you know, at least taking a look at it. Sometimes people have tools that had capabilities they weren't aware of. Uh, for instance, in the demonstration,

if you had some tool that was capable of just watching and detecting when new drivers were added to a computer, it would be easy to see that something had inserted itself in there that was unexpected and then you'd know that there was um, you know, some sort of breach that at least begged further investigation. um if you don't have a tool that's capable of doing it, you need to ask whether it's worthwhile to actually, you know, develop it yourself or to buy any other tool out there. So when we looked at the industry, we said, okay, this is, you know, we're not happy with it, but we don't expect everyone else to run off, start a company, and try to address

the problem in a different way. That's not very realistic. but you can at least be better aware of what you need to uh keep an eye on and what types of um vulnerabilities that are going to be an issue for you. Um I think a place where you can actually make more progress is by looking at areas where um like vulnerabilities that come as a result of the ease of use features. So, if you don't need a specific ease of use feature, disable it because if you leave it open, you've created a hole that something can drive itself through that is completely unnecessary and isn't really buying you anything. And then on the same note, if in the case of like

signing certificates, if it's something that is so large of a potential hole for you that you can't work, you know, if the product won't work without that, it won't function. It won't, you know, it won't be manageable in your environment, you need to really determine whether or not it's worth running that specific application in your environment because it's not without value. But at the same time, if you're making all these assumptions about what's legitimate and what's not based on those sorts of faulty uh faulty assumptions, you're going to be in trouble. So I think that's an area where you can make a lot of easy progress with it. And then uh probably the last area I think where you

can actually address some of the vulnerabilities that exist is in the direct attack vein. So malware wants to directly attack security products that are present on the computer. Uh it might seem a little bit counterintuitive, but organizations are actually better able to stop and detect those attacks than the security vendors who create the software themselves. And the reason for that is because a malware developer is able to go out, go to the shelf, buy a security product, install it in a virtual machine, test their exploits. If it works, they release it and it's going to bypass it. If it doesn't, they don't and they look for something else. So anything that's like inherently incorporated into the product is

something that is going to be bypassed in some capacity or they'll just ignore that particular area. What you can do with some simple tools is try to take advantage of the fact that you anything you put into place can't just be bought off the shelf and tested against. You can put in measures that won't be detected or won't be known by the people who are developing this malware and this gives you a greater advantage. So for instance, you could script a attack of some sort. You might move a malicious file or a test file onto each of your endpoints in your environment and just see if it's reported properly. If it's reported and you know you confirm

through the secondary channel that all the endpoints are reporting properly, you have that peace of mind. If you see that some of them aren't reporting what should have been removed, then you know you have a potential leak. You have either a malfunctioning security product which you want to know about. you have some network connectivity issue which would again lend itself to a particular or potential issue or you have a you know an actual malware attack that took place on the computer so you gain some additional piece of information from it. Um similarly you could go one step further you know um a lot of products will simply be shut off by now or they'll kill them in running process and

what you can do is create a application whose job is simply to see if a process terminates in an unexpected way. If a process terminates in an unexpected way, report it through some secondary channel. And then you're going to have that information available to inform you that either a product crashed, which is important, or that something was directly attacked or that one of your users decided that AB sucks. I'm going to turn it off. So these sort of like secondary channels are more secure than what a security vendor is ever going to be able to offer you just because you need to either suffer some sort of internal attack um for that to be detected and bypassed or they would have

had to infiltrate and get some insider knowledge in order to uh perpetrate that type of attack. So that's the uh overall um view of security at least from my perspective. But I don't know if you any of you kind of have similar views. If you have con, you know, dissenting views, um, comments and questions are certainly welcome. Questions, get drink tickets. To mention that I don't want a drink ticket, but I have a question. Okay. I'm Cyber Jungle Radio, so it would be unethical for me to take a drink ticket. Okay. For a question. Did you look at um Microsoft active directory tool to do application whitelisting? Uh yes. So did you test that one out? If you check the third

party vendor whitelisting apps only. Uh we tested uh this particular exploit was against a third uh third party whitelisting app. The question was whether or not we tested Microsoft uh application whitelisting. Uh when we did it, we did test Microsoft as well. There are some there are vulnerabilities that exist in that as well. Less so on the search store side of things, more on the fact that you can um kind of exploit uh Microsoft's own um let me think of how to phrase that properly. Uh the driverbased mechanism was one that was capable of working because it was dependent on a similar uh assumption as to what level it loaded. And then also um I forget there was

there was another certificate store um sort of type exploit that you were capable of doing that I can't off the top of my head. So was the reg key that you changed a product specific reg key for where to look for the certificate or was that a system key? Okay. So you asked if that was pointed towards a product specific reg key when I switched the certificate store location. Uh in this particular case what I did was I created an alternative directory. So this product protected its certificate store. I created one in another location and a junction point that pointed to the one on the desktop. Then I used a pending file rename operation in order to switch

those when the computer rebooted. And now all of a sudden you have it pointing to a new location. Uh how many different products did you see those two vulnerabilities? Uh you asked how many different products I saw those vulnerabilities and do you feel you feel cheated over there? my question. Give him a drink ticket. I think we tested four or five total. Um I I saw it definitively personally in like three products that I was capable of doing the bypasses on. Not not using the exact same techniques, but ultimately they're storing this information either on the registry or directly on disk. And it's it's either a matter of compromising that specific products registry or doing things like

junction point magic where you get it to redirect to another location that it isn't protecting with its own hard hardcoded uh driver protection mechanisms. Did you contact the individual vendors of the application list of products to disclose this problem to them? We have not disclosed these specific vulnerabilities to these uh vendors at the moment. It is a consideration but we're also in the boat of quite frankly I think they're known to a certain extent too. I mean they're difficult problems to solve honestly like especially like the kernel like the kernel level uh you know different altitude one isn't something that is prevented other than putting in a totally new method of protection. Yeah. Yeah. So did you actually have to

go out of your way to redirect the certificate store or could you actually just force install the certificates to the trusted stores? So what I did in this particular case is I redirected it. Uh I did try to directly he asked if I tried to directly um you know edit just drag certificates directly in that didn't work because they're you know they're expecting that sort of attack vector. I believe on this particular product I tried like a pending file move operation to move it into there. It was also aware of that particular method of bypass. Um yeah, one of the other things to consider is there's other ways of deleting without going through the registry directly where you register

through other certificate utilities and writing without having to go through red or red scripts. Correct. Yeah. And there Yeah. So the suggestion was you can actually do it in other ways without having to rely on the registry and in a lot of cases that's true. It's kind of a um you know case by case sort of basis. So this particular product was one where if you knew the there's a command line utility that allows you to switch it into like an update mode of sorts and it password protects it because you want it to be password protected. But I found that if you uh strip the permissions off of the file, then all of a sudden it

couldn't read its password file. It operated as though it had no password and now you have complete access to the utility that allows you to configure it. So I mean major security holes things that should have been caught weren't but you know they're they're not a you know they're oversight is common unfortunately so you pointed yeah question back there. Okay. You're good. All right Jared you pick the next one. So how'd you get uh access to to each individual product trial versions largely actually? Yeah, I tried to test them against their full like full-fledged network complete versions cuz there there are some differences. Um ultimately at the end of the day it is stored locally on the file system. So

there's vulnerabilities there. It's a matter of how much reporting and auditing you do of your application whitelisting product in addition to you know sort of compromises that take place. in test bit 9. Um I I will not comment on any specific. [Music] Uh any other questions? Um in in your list of things to look for in products you said to look for things that don't use certificates. Um what are the alternatives you see? Um well not even not even necessarily avoid anything that uses certificates. Just be aware of the fact that if you're relying solely on a certificate as a means of authorizing something or uh considering it legitimate, it's going to be something that's increasingly exploited

by malware developers. We're already seeing a rise in that sort of activity. Um from a purely biased standpoint, you know, what I um what I advocate is anti-persistence. um focusing on eliminating malware's ability to persist just because ultimately that is one of the most valuable behaviors uh malware can have. That's what allows it to operate and effectively accomplish most of its objectives and those are less noisy areas. You know, application whitelisting says any single application that's launched whether one bit has changed or you know a million bits have changed requires some new form of authorization. Whereas the number of ways that legitimate applications start themselves automatically when you reboot your computer are fairly limited. For

most like user level applications, they're not needed at all. And for the, you know, more sophisticated applications like security um, you know, security tools and things of that variety, they're not going in there constantly modifying those specific areas. So you have a lower noise sort of approach to it. Doesn't explicitly require certificates in order to be something that's actually manageable. Anyone else? [Music] Well, thank you very much. Appreciate you guys coming out. Feel free to stop by. There's more electric in the back. And and before you go again, I'd like to thank Besides and I'd also like to thank our mentor Eric aka Johnny Bravo for helping us. If you were unhappy, blame him. Excellent advice. Thank you.