Could anti-exe programs prevent applications from executing unknown dlls?

@r41p41,

Welcome on Wilders.
It's nice to see people who are aware of the limitations of security products.

 

@r41p41,

Same here. Welcome on Wilders.
Thanks for the feedback. Also appreciate an expert's analysis on the discussion.

 

Yep, you are correct, sorry about that, I was in a rush and missed that part. I will post right now, thank you.

 

Sounds to me like the bounty should be $10 million then .......... I am sure you will get plenty of responses to that.

 

10 million Zimbabwean dollar

 

First I do want to echo the sentiments from the two previous posts... welcome to Wilders! It sounds like you know what you are talking about, so your input will be extremely helpful to everyone. It will be nice to have an expert's opinion, and I am certain everyone will appreciate that, so thank you.

Sorry, I did not notice that you offered to create a POC, I was in a rush, I just wanted to give my first impressions right after I read your post. Yes, I would appreciate it a great deal if you could create POC that can bypass our AppCertDLL. But if it takes too much time, there is no point since VS 3.0 now has the mini-filter KMD. If you want to take a look at that, that might be a better use of your time, but that is completely up to you.

About UAC... also keep in mind, 91-92% of all users disable UAC (this is the actual number that I have posted many times on the VoodooShield? thread). I actually had high hopes for UAC when it was announced before Vista was released, and it has improved with each version of Windows, but it has a major design flaw... the affirmative user prompt (among other serious issues from a usability standpoint). And I was sick and tired of my clients getting viruses, and late one night while removing viruses from 2 client's computers I had a simple idea of placing a toggling desktop shield gadget / computer lock on the desktop. It would toggle to ON when a web app was launched and lock the computer... but I did not want the computer to be locked all of the time so that it could automatically learn new good processes and build the whitelist on the fly. Keep in mind, we can always add more security mechanisms to the lock... VS, along with all software is a work in progress.

If UAC would have been designed and implemented correctly, then there never would have been a VoodooShield.

The attack you described might work, but then again, we might be surprised. I would be extremely curious to find out, but really it does not matter since we have moved on to the KMD. The AppCertDll was a "stop gap" / bridge that served its purpose, and allowed me to build out VS, without potentially creating BSOD and other issues on users computers.

Anyway, the attack you described looks like a targeted attack to me, since it looks like the goal is to kill VS... am I understanding your attack correctly? If so, I guess the better question is this... can VS 2.0 be bypassed with a non targeted attack? I knew we would not be on any hackers radar for quite some time, so it was not a concern of mine. So I figured the AppCertDll would buy us time until we had the chance to finish adding features and also implement the KMD, and during this time, we would not be subject to a targeted attack since we are not on any hackers radar. It was either that, or try to implement the KMD early on, and risk BSOD and the like.

So my question is... can you bypass our AppCertDLL with a non targeted attack? And do you agree that using the AppCertDll as a temporary solution was the correct thing to do until the KMD was implemented, given my limited coding abilities? I mean, is that logical to you?

There are a lot of things that I would love to do with VS, but there are only so many hours in the day.

I believe that the only time that I have called people out to bypass VS is when they suggest that something can bypass it, without providing a demonstration.

About the bounty, how much are we talking? For a targeted attack, I would hope that you would agree that a bounty is not appropriate. However, if you can provide a non targeted attack, like the ones we see in the wild, sure, I would be game... depending on how much the bounty is. I am not going to spend a lot of money just to see if our previous version is bypassable, although I might be interested in doing so with VS 3.0 .

So how difficult would it be to provide a non targeted attack for the AppCertDll in VS 2.0?

Also, aside from VS's 2.0's AppCertDll, like assuming that it was bulletproof, how would you bypass VS?

Thanks again for your help, I really do appreciate it!

 

Hehehe, how funny. I would enter that contest if it was $10 million, although I am certain that r41p41 would beat me to the punch .

 

Well said .

 

Here is a quote from the article:

"Pandemiya is spread by exploit kits via Drive-by Download attacks, and uses a Portable Executable (PE) infector, that writes itself into a special Registry key (AppCertDlls) which allows the malware to inject its code in every new process created."

It uses the same process creation detection mechanism that VS uses, so wouldn't VS 2.0 block the PE that it dropped? Kind of like if you had 2 VS's running on the same system, the one that started first is king of the hill and will block the other, right?

 

If someone states that they can bypass a security soft, but then beats around the bush and offers no sample to verify the bypass, then what does that tell you ?

Trying to patch all vulnerabilities in any security soft is an OCD fantasy... it isn't practical and it isn't how the security soft industry works and, more importantly, would only increase security very marginally at the expense of some sort of serious associated, unintended problems.

I am not saying VS cannot be bypassed. IF there is a serious hole, then it should be fixed. However, fixing arcane vulnerabilities that are difficult to exploit is a complete waste of time... since no malware author in their right mind is going to put forth the time and effort to exploit them in the first place. To do so would almost virtually guarantee them a take of $0...

There has to be a balance between what is theoretically possible and the reality of the way things actually work.

 

I totally agree!

Also, as far as I remember, the only time that I have ever challenged someone to bypass VS is when they post somewhere that it can be bypassed. So then I challenge them to find something that will bypass it, which is a totally different than me saying "write a targeted attack that will bypass VS."

However, if he, or anyone else can write an non targeting attack that will bypass VS, then that is definitely a bypass.

I am not even sure why we are talking about the AppCertDll anyway, considering that mentioned that VS 3.0 uses the KMD when I provided him with the test requirements... ESPECIALLY if we are just talking hypothetical!!!!!!!

 

Wow, so many comments. i hope i get moderator approval soon, because i plan on commenting in future.
Dan, kindly read my post. i clearly state bypasses in 2 ways. targeted and non targeted.
i am just trying to save my time and your money. Actually just my time which is quite limited.
Judging from your comments i can assume you don't possess much UM or KM details, so i will dumb down the logic for you.
The way you block process right now is primitive, and why i call it such?
Because when you are evaluating whether to execute the process or not, its already executed in suspended state and just waiting to get Resumed.
From the path to ntdll!ZwCreateUserProcess to your callback N number of things can be done to make sure that you never receive a callback and your product will be bypassed. I dont know how people at wilder security forums are, i am not trying to say your protection is **** i am just highlighting the holes in the system which is designed bad architecturally, because in order to block process from executing you are using a callback which gives you control between a New Process's Thread state from Suspended to Ready. If you show this comment to your developer i am sure he will make you understand what i am saying.
and for the record, bug bounty is always targeted, though in your case generic bypass is available.
Another thing, and i would stress on this if i am not late for office
No security product is perfect, but we must try to reach perfection.
No security product is good, if you are preventing user mode exploits/malwares from executing while your code also lies in user mode.
If there is no barrier between your code and Malicious code, your product is nearly useless and malicious code can just use OS features to bypass you.
If there is a barrier a malicious code must exploit your code because OS features won't apply.
I think i highlight that when i bypassed EMET, MBAE and Hitman.
now, considering you use minifilter logic in VS 3.0. when it comes out i am sure if the code is implemented properly there would be no bypass other than finding mistakes in your driver and exploiting them.
Bypass is something which can be done by finding existing OS features and subverting your product.
Exploit is something which can be done by finding mistakes in your code, because the system is so designed that OS features cannot be used to subvert your product.
Kindly note that.
PS: your pipe CPNSpecialxxx is quite insecure. kindly look into that.

Thank you

 

Cool, let's make this super simple.

Would you agree that the way VS 2.0 implemented the AppCertDll was sufficient to use as a temporary solution, to give us time to properly implement the mini filter KMD? That is, would you expect for it to block the vast majority of threats seen in the wild? If your answer is yes, then I see no reason in discussing the AppCertDll anymore. FYI, the VS 2.0 implementation has been tested against several thousands of threats on MDL and malcode, and it was never bypassed.

If you want to have a quick look at VS 3.0 when it is ready tomorrow or the next day, that would be cool, then you can PM me on what you think a fair bounty would be to try to bypass it.

 

I am just a guy showing you holes in your product.
As of the question "how many threats bypassed/detected in the wild", thats really a marketing thing and not my area of expertise.
i only looked at VS because some guy posted a comment on my blog asking, how is VS? Plus MDL and malcode are public feeds, i am sure if you get a VT key you will find many samples you won't detect.
Anyway VS bypass won't be seen in the wild unless your product becomes too main stream. I tried my hand at EMET why? because its too mainstream.
i am sure when your product gets used at that high % and when Govt puts it in mandatory installation list, i would love to do it for free.
Right now, i'd go for a bug bounty. Awaiting VS 3.0 release and a bounty reward if possible.

 

So, what you're saying is... any anti-x app that pops up a prompt with options such as "Block" or "Allow", all have the same flaw?... which means any time user input is required to confirm something, it creates a potential security hole (not referring to professional vs common sense, but rather the Suspended/Ready thread state)?... which means no matter which way we look or whatever setup we have, we're up ~ Snipped as per TOS ~ creek without a paddle?

How about white/black list ruleset apps such as Bouncer or Smart Object Blocker, which sit high up in the kernel list (I think just below Shadow Defender), which do not rely on user input via prompts? Would rulesets provide the same issues faced with Suspended/Ready thread states via callbacks?

Hell, I'll permanently relocate every person living in my street if you can bypass Shadow Defender. Don't ask for a cash bounty, money doesn't get me throbbing...

 

i hope i am not starting a war here but What i am saying is, if any malicious code exists in same space and has access (rwx) to the same space where a guard application/code is present. Then don't call that robust or . Also the prompt box can be clicked on by using SendMessage() so unless the window is protected by some layer, user is in trouble.
Bypasses can be 2 ways
1. you can bypass validation of a security software
2. you can subvert the routine and mess up the execution control so security software never gets a chance to validate.
This flaw here is because of usage of Appcert registry key, and i dont know what shadowdefender is to comment on its capability.
Perhaps i will take a look.

 

ShadowDefender is in essence a VM. Really don't know why it comes up in discussions like this since it is entirely different technology. For me way to much overhead. Also this type of software has been problematic in the past. Just doing an image backup periodically gives me the same protection and I don't have to pay a yearly subscription for that.

Shadow Defender can run your system in a virtual environment called 'Shadow Mode'. 'Shadow Mode' redirects each system change to a virtual environment with no change to your real environment. If you experience malicious activities and/or unwanted changes, perform a reboot to restore your system back to its original state, as if nothing happened.​

Ref.: http://www.shadowdefender.com/

 

But the transportation costs for over a ton worth of stuff from there would be very costly ................

 

personally i think its better to have a private solution and keep it to yourself than rely on something public and paid.

 

That's a good point. Security through obsecurity ...................

 

I do agree that our pipe for VS 2.0 is not as secure as it probably should be, but the developer who wrote the AppCertDll implementation for VS 2.0 assured me that everything was secure. I barely can read C++, let alone develop anything useful in it. What would be interesting would be a conversation between you and him. He is a smart dude and I bet there is a good chance that he would point out something that you are overlooking. When I have the extra money, I will post a bounty and see what you can do to bypass VS's AppCertDll, mainly just out of curiosity. I do not think it would be as easy as you think it is.

You said "Anyway VS bypass won't be seen in the wild unless your product becomes too main stream." That is what I mean by a targeted attack. I read your suggested attack method again, and understand it a little more now. But I am not still seeing the part where a generic AppCertDll bypass will bypass VS 2.0, without knowing SOMETHING about VS 2.0.

I knew your first point of attack would be the AppCertDll, and that is why I mentioned that we are implementing a KMD in VS 3.0. I was hoping that by mentioning this, you would not focus on the AppCertDll since it is being replaced, but rather focus on the rest of the code, since a lot of that we are keeping. That is what I am MUCH more interested in... whether that can be bypassed or not.

All of this is hypothetical, so when VS 3.0 is ready, if you want to take a quick 20 minute look at it and give us your initial impressions, that would be really cool! Again, thank you for your help!

Please PM me on what you think a fair bounty would be for VS 2.0 and 3.0 after you look at it. I just want to get an idea of how much we are talking, because if we are not talking some crazy amount, I might be able to afford it now.

 

Not at all, dude! While the conversations can become quite spirited at times, we are all on the same team and in the end will reach a consensus. I just think that a PoC / demonstration is a lot less frustrating for everyone than hypothetical conversations. Conversations like these are the most interesting ones to me, and I hope no one takes anything personally, and I hope we all learn something as a result.

 

Yep, until you can properly implement a mini filter KMD .