Detection vs Threat Prevention

That's exactly how I think when I look to test out a product. When I'm testing out a sandboxing/AE/whitelisting solution, I know it's going to be quite difficult to bypass them with malicious code. Usually the only way I can bypass them, is to look for design/implementation flaws which everyone has at some level of course, but I'm in a fight with a strong methodology right off the bat (human factor aside). Now, when I think about heuristic and signature solutions, I know before I even get to the lab to test them how to evade them easily and to me that's a huge problem that needs to be corrected. Evade the behavior detection and if your not on the "list", right on through. Specific products aside, that's my issue with the state of things today.

 

Sorry, but it's your testing is nothing to do with the real world. Yes, you did ban me at your youtube channel instead of answering my questions against your "Hacking DefenseWall in 60 seconds" video, but if you think it will help you to sell more copies- ha, will see...

 

You're correct, I believe it had to do with assuming network drives and shares are safe sources by default. In the real world, those two sources are some of the most common infection vectors. You were banned because your comments were unprofessional and rude. I know everyone is passionate about their solution as blood, sweat and tears go into them so I don't blame you for reacting the way you did. You could however, as a vendor have contacted us directly.

 

i don't think it's as difficult to bypass an application whitelist as you make it out to be.

just as known-malware scanning can only prevent/detect known-malware, application whitelisting can only control the execution of known-program-types. you merely have to think outside the box about what constitutes a program. there are a limitless supply of possible program-types so the fact that there are some that application whitelisting misses is neither a design flaw nor an implementation flaw. it's simply a fact of life.

that's no more a problem than the one i just specified with application whitelisting. in fact it's directly comparable. both blacklists and whitelists depend on knowing something and that dependency can be exploited.

and to be honest, it's easier to update a scanner's signature database than it is to add control for a new type of program to an application whitelist.

the ease of exploiting a knowledge dependency is only a problem if you don't have compensating controls that lack such a dependency.

 

Real world example?

This would only hold true if the solution in question looked for certain file extensions to block.

 

that is why a good AV with about 99 percent detection will always be the way to go. This specialty products are nice, but after trying them, the old verbage of scanning slows my computer down is bunk. They all slow my computer down.

 

of what? an obscure program type (any data file will do, and that's just the start) or an attack that uses this concept (whitelisting isn't high profile enough yet for attackers to concern themselves with this yet)?

not so. the process of execution itself can take on an infinite number of forms. something that's supposed to block execution first has to know what to block. this has nothing to do with file extensions.

 

I think I see your point, meaning for example an html file becomes malicious in one way or another?

There are only so many avenues to execute code on a given os, stand at the proper doors and you can prevent execution of pretty much any code type without targeting data types.

I do think you bring up an interesting point, I just can't think of an example threat that whitelisting wouldn't have prevented and even that would be a major step in the right direction. As you've stated, that doesn't mean it's impossible. It does however mean to me, the malware writers are going to have to work for it, instead of just walking on through as they are used to now.

 

this is what one thinks when one is operating under the classical notions of what code is and what execution is. however, when you come to terms with the reality that there is no intrinsic difference between data and code, that there is no intrinsic difference between data processing and execution, then you will realize that there is no limit to the number of avenues through which code can execute.

for any sequence of bytes there exists an infinite number of possible programs that will treat that particular sequence of bytes as one or more instructions (and thus a program in and of itself). as there are an infinite number of operation combinations you can perform on that sequence of bytes, the number of ways those bytes can be treated as code is likewise infinite.

 

Excellent points. I wonder myself if malware makers are thinking much the same. I see a lot of vendors mentioning their testing is done within virtualization, it makes me wonder if they are really replicating effects for a real time user. I guess they would have a long day installing images without VM and so on.

 

Good article, but consider that the source has a revenue stream that depends upon you believing that whitelisting isn't a more effective solution...

There are various other av manufactures that have stated publicly that their methods aren't solving the problem. I think testers are the most keenly aware as they see the failures first hand.

http://www.scmagazineus.com/whitelisting--white-horse-or-white-lie/article/35903/


I'm comfortable with stating that a properly implemented whitelisting solution is easily capable of preventing 99% of the malware targeted at windows systems in the past 20 years to the present day. That's a claim that heuristics and signatures based solutions will never be able to claim.

Just my opinion, nothings perfect and never will be, but there are major improvements over current mainstream av tech out there. To me, the model just makes sense, especially in a corporate environment.

 

I think this is why whitelisting and AE tech by itself is fairly useless, if the user has no information, how are they to make a decision?

However, imho whitelisting should be your first line of defense; not heuristics, not av. As far as the statement that whitelisting companies don't disassemble or reverse engineer threats in the lab to determine safety, I can only speak for ours and I can tell you we do on a daily basis. We are more of a hybrid approach then most though.

 

I was going to mention awhile back, what if a whitelisted application suddenly installs a trojan or a problem toolbar and so on, but thought that might have been too obvious.

So I do somewhat agree with the article, regardless where the guy comes from, that disassembling programs would take much more time and would be quite labour intensive. Companies relying on whitelisting would still have to rely on quality AVs as well for analysis, yes probably not all the time, but AVs would still be of use. I know Joe from prevx spoke to me how he disassembles malicious programs, and the process he goes through.

I think the most important part to me, is how the user interprets the information. An AV (signature or cloud-based) with 90 per cent detection, that provides clear alerts and minimal inconvenience, might cause a problem for a user if a threat gets through, say once a year. The percentage the threat is of the most serious kind would be even lower - more frequently, they're of the fake rogue AV kind (not saying serious threats don't get through, but a lot of the time they can be cleaned up with another AV, or removed manually).

But programs with higher prevention, bringing the user up to 99 per cent prevention, might, and I stress the might, cause an average user a problem more than once a year if the alert information displayed pops up too frequently and doesn't provide enough detail for the user to make the correct choice. The second program could provide too many prompts, creating some frustration or confusion, then affecting a user's convenience, and their 'joy' of being online.

All depends not on which program is best (or has the highest detection/prevention). If it's choice A or B, doesn't matter, but what matters is which program suits the user's skill level, the user can understand, and which program the user can live with.

 

What are you preventing against?

Missing from this discussion on prevention is much about specific scenarios that the user is likely to encounter. What do need to protect against?

What is malware targeting these days? If you said, the operating system, or the browser, you are not up to date. See this thread ronjor posted today:

Security Pros Are Focused on the Wrong Threats
https://www.wilderssecurity.com/showthread.php?t=253458

The article mentions the just released report by sans.org. While the report focusses on organizations, I suspect it applies a lot to the home user. In their current Diary, we read:

This is not new if you have followed the current exploits in the wild. In fact, a current very successful exploit doesn't even target an application: the redirection to a malware site from a site compromised by SQL injection, or from an altered link on a Search Engine page.

Unfortunately, most mainstream coverage of these exploits does not provide effective preventative measures.

Let's take the redirect exploit from a Search Engine result, to a site with a rogue security product to offer.

Here is a Yahoo link, with the URL appended at the end:

​

and the redirect to the malware site:

​

Normally, I see a blank page, but here, the code loads a static .gif image of a scanner. Note that there is nothing filled in, since the fake animated scan depends on javascript to run.

Why don't articles describing these exploits stress that if you configure the browser to permit javascript on sites you authorize, that these redirection exploits fail to start? You can make the case that a properly configured browser is all you need.

Nonetheless, most want something to intervene in case of an accident, since if javascript were enabled and the fake scan started, users have reported that attempting to leave the site by clicking the X actually installed the rogue software. And so I provided a screen shot from a similar exploit:

​

Now, I encourage everyone to read the article on White Listing cited in a previous post, and you will understand why I abandoned the use of this term some time ago, since it has all sorts of connotations -- more than one meaning or usage.

All I want is protection in place that will block any executable that is not already installed on my computer from trying to sneak in by remote code execution. Call it "white listing" or "purple shoes", it doesn't matter. Getting bogged down in terminology detracts from getting down to the specifics of prevention against exploits and developing a secure strategy.

The targeted applications mentioned in the sans.org report use specially crafted documents to trigger the vulnerability in the application. Files such as PDF, SWF, DOC, RTF have been commonly seen in the wild.

I gave an example in an earlier post of a PDF file used in a web-based attack, triggered by the browser using remote code execution.

Question: is this a browser attack? Strictly speaking, No, because code in the browser is not being exploited. Browser configurations permitting javascript and plugins do the triggering, and as such, these exploits work against any browser.

So, what about opening a PDF or Office document you have downloaded, or that arrives by email? From one report:

Well, maybe not. I never found a single analysis that provided useful information about preventing an exploit like this from being successful. All we read was, "keep your Reader up to date" or "keep your AV up to date." "Switch to Foxit." (Foxit had many PDF files that exploited it)

So, I did my own analysis earlier this year which I've referred to before. While the first part covers the web-based attack, the last two items would also prevent the exploit from succeeding if such a file were executed by the user:

http://www.urs2.net/rsj/computing/tests/pdf/

You will note my comment at the end that the concept of using a non-executable file to trigger an exploit in an application is not new. Understanding the concept provides the knowledge that leads to deciding how to protect.

For the Office Document files, sans.org caught an exploit earlier this year, and I was able to test the file.

https://www.wilderssecurity.com/showthread.php?t=244726

Note that in addition to my own protection in both of these cases using Anti-Executable, others tested successfully with SRP and Sandbox.

It doesn't matter which product, as long as the user is confident that it takes care of the problem.​

Getting bogged down in discussions of "which is better" is silly. Choose something you think works for you and gives you your peace of mind, and be done with it!

Sometimes these discussions of products remind me of similar ones on camera forums, such as,"Which is better glass: Nikon or Canon?" As a photographer friend of mine likes to say, "Show me your photographs."

Much as been said already about absolutes, and certainty. Scientists will tell you that there are no certain facts, only hypotheses waiting to be disproved.

And so, in a previous post, I did not say,

"Proper browser configuration will prevent all web-based malware attacks."

Rather, I stated,

"I have yet to see a web-based malware attack that gets past a properly-configured browser."

As far as blocking a malware executable in the case where an exploit does get past a non-properly configured browser, I have yet to see one succeed when either SRP or some type of execution prevention is in place.

Dealing with what is going on in the real world should be the starting point of discussions on prevention. What do you want to protect against? How can you best set up a strategy which leads to selecting types of products? Talking in broad generalities, worrying about Proofs of Concept that appear daily, marveling at the games played at hacker conventions, and throwing loaded words around, just clouds the issue and leads to useless and fruitless, often heated arguments.

As far as choosing to download/install stuff: the idea of some gigantic White List is absurd, and black lists (scanners) have repeatedly been shown to be unreliable. Yet, scanning a product will make someone feel good if it passes!

One has to decide what gives the best peace of mind. In an educational institution with which I'm familiar, and in my own case, checking the reputation of the product and vendor has served well for many years.

Neither is 100% secure. So what? It's how you feel that counts, so you do what you have to do and get on with your computing life!

----
rich

 

3000 years ago we knew the earth was flat
150 years ago we knew flight was impossible
50 years ago we knew landing on the moon was impossible
Today, there are still those that know solving the malware problem is impossible.

You can only tell someone so many times.

 

Re: What are you preventing against?

I couldn't agree more.

This works for me, too!

 

Great post Rmus.

I agree most people can rely on a properly configured browser and checking the reputation of a product before initiating any downloads. And using some common sense.

More browsers should have the feature to turn javascript on/off more easily for the average user. I just realised, thanks to your post, under 'appearance' then 'buttons', I dragged the option of turning javascript on/off straight down to the Opera status bar.

 

So your saying that all viruses can be eliminated with a properly configured browser. I hate to be harsh but I wouldn't hire you as a IT manager

 

maybe not all, but a hell of a lot of it.

 

I guess it was enough for the government project ( F22 project that got hacked and data was stolen) or the electric grid that got hacked that makes your power, that was enough. There is a real need here for Good Security application that obviously have not been addressed. I don't feel comfortable with UK hackers selling social security numbers on the net.

 

well the diff between the government and a home user is the government wukd be a high priority target unlike a single home PC. government is probly under cyber attack around the clock unlike a home PC.

 

Thanks for that tip! Which version of Opera are you using?

----
rich

 

I would hate to be harsh also, since that is not what I said!

----
rich