Detection vs Threat Prevention

complete isolationism isn't practical but is safe at least and

=that is the way you belive or want to belive it,if you are positive person you feel positive or v-severse it is very simple if you want to be at least secure spend some cash in good products like DefenseWall,blue point,appguard and a good scaner like prevx with a pair of any of two of those you will achieve at least 99.99 % security

 

Yes, understood. However, I am always interested in hearing different approaches. Personally, from what little you state here I am probably doing something similar. I know for me, having images, understanding where breaches can occur and minimizing those are primary. But it is as you say, at some point you must trust a file. For example, there is a post about a new application in alpha stage called process blocker. I don't know the author, but it seemed like a nice application. So I contacted him and downloaded it. My system is clean, I use ShadowDefender to keep it that way. I don't have an AV or firewall. I do have SBIE, but this program will probably not be best suited in a sandbox.

Unlike the program this thread is about, or appguard or dw, I actually want to execute this application. But how am I to know if the author is legit or what? The answer is of course that I cannot. Is AV or any scanner really going to give me peace of mind? If the author has just created some malware/virii, scanners cannot help.

In fairness, it could be feasible to use a HIPS to monitor what this new executable wants to do. But this executable is itself a process blocker, capable of hooking and terminating. So, how do I really know? For me, I have an image. But more, I own vmWare. So I drop it in there and examine it. Luckily I understand enough to know what to look for. I run a program that watches for file/registry changes as well if needed.

Your point has been echoed by many. Once I really want to execute something, especially if it needs admin, there is really no practical way of knowing what will happen. You could RE the application and examine it, but really who has time for that? Or knows enogh to fully comprehend.

I think tools like scanners/av/hips/etc can have thier place, but if the end result for many is that they will elevate an executable to admin, then it will happen. For me I go crazy when I use HIPS these days. I would rather watch what happens and restore an image if needed than go through all the popups.

Oh, btw, that little alpha program is quite nice. While still at alpha stage, and not a swiss army knife utility, it is clean and to the point. It shall be interesting to see where it goes.

Sul.

 

there's more to impossibility than just belief, and if you think otherwise then i have some cremated grandparents i'd like you to reanimate.

i think you're oversimplifying things, but if it works for you then i won't belabour the point.

 

just install a default-denny/anti-exe program in their pcs and problem solve

 

not so sure about that. it might not be suited to sandboxie, but i would imagine it would do fine in vmware (later on it looks like you came to that conclusion as well - perhaps you don't consider the guest environment a sandbox?).

well, since you expressed interest in what i do, i'll tell you what i'd do in this case. i'd pass on running the app. i avoid experimenting with new software if i can help it. if there's a function i need to perform and i don't already have software that does it then i go looking and i look at the reputation the software has (something this new would have next to none), but if i already have software to do it then i don't go looking for other software to do it. and of course, if i must experiment with new software i do so in a sandbox.

 

Yikes! That's a bit harsh.

 

From my point of view, computer security is made out to be much more complicated than it needs to be.

There are two ways undesirable stuff gets onto a computer:

• It sneaks in by some type of remote code execution
  
  
• It is permitted entrance by the user

The first is the easiest to prevent, and the various forums at Wilders are a source of many effective solutions.

The second is more problematical, since it depends on the user making a decision. It seems to me there are two options:

• You trust a scanner
  
  
• You trust your judgment, source of purchase/download

Do you realize if everyone followed this policy, the success of rogue AV malware (the most popular current malware) would drop to almost zero!

----
rich

 

Looking at exploits keeps things in perspective, and is one way of determining what is needed in the way of prevention. This method may not be for everyone, but it does get you involved with micro-control over what can execute on your computer, starting from the premise that nothing is allowed to install automatically.

Looking at remote code execution methods:

1) The exploit has to get past the firewall

I don't check my logs so much anymore, since it's all the same stuff. For example, probes to the trojan/worm ports:

​

Conficker, if you remember, used ports 445 and 139. If they are closed, the exploit fails


2) The remote code execution exploit has to get past the browser

This has been preached for a long time by Mrkvonic, and most recently, voiced by a certain researcher of Blue Pill fame:

A Strategy For Protection
http://www.tomshardware.com/reviews/joanna-rutkowska-rootkit,2356-6.html

I have yet to find a web-embedded malware exploit that gets past a properly configured browser.

When a redirection-to-rogue site exploit surfaced last year, I went to the URL and was redirected to a blank page:

​

Why? Because the exploit required javascript to start the fake scan and with scripting configured per site, the exploit is dead in the water.

Code:

<[B][COLOR="DarkRed"]script[/COLOR][/B]

function stateaction(state, data)

case [B]'BEGINSCAN':
[COLOR="DarkRed"]startScan[/COLOR]();[/B]

Same thing with a current PDF exploit:

Code:

<[B][COLOR="DarkRed"]script[/COLOR][/B]
name = navigator.[B][COLOR="DarkRed"]plugins[/COLOR][/B][i].name;

if((name.indexOf("Adobe Acrobat") 
document.write('<[B][COLOR="DarkRed"]iframe src="pdf.pdf[/COLOR][/B]"></iframe>');
</script 

A blank page:

​

3) The remote code execution exploit has to use a USB or CDRom drive

This type is easily prevented by firm policies and procedures, such as:

Use only the non-U3 smart drive type of flash drive

This type will not execute an autorun.inf file. What if it became infected with a USB virus when using it on another computer? When connecting the flash drive at home, navigating to the drive using Windows Explorer -- not My Computer -- will reveal any nasty surprises and not execute anything:

​

Use the same procedure with untrusted/unknown CDs

Suppose I purchase a music CD? Since I keep autorun enabled for normal work, I will suppress autorun/autoplay in this case by holding down the Shift key, then navigate to the CD drive in Windows Explorer to view the contents. I made such a CD to test:

​

Nasty malware present, but sits there helpless. Time to have a talk with the store manager (if this were a commercial CD).

This scenario could also occur when trading home-burned CDs with other people.

Autorun exploits have been around since Win9x days, and all these years people have fiddled and tweaked autorun, worried and fretted out of fear of this type of exploit, when all that is necessary is a simple procedure that denies the autorun.inf instructions from executing.

Remote Code execution exploits are greatly exaggerated, due in part to the sensational nature of the attack-by-stealth. But they don't require much at all in the way of prevention:

• Having a properly configured firewall
  
  
• Having a properly configured browser
  
  
• Setting up secure policies and procedures

As has been mentioned by myself and others, you don't see this basic type of prevention discussed much in the mainstream press.

To Sully: In the spirit of keeping thing simple, you can't get much more bare-bones than this!

Should nothing more be added for protection against remote code execution exploits? This depends on many factors, and one could argue for some protection in case of an accident, as with the above CD example:

​

----
rich

 

In my previous post, I suggested a bare-bones approach to remote code execution exploits. Another large window of infection: What about when I decide whether or not to download/purchase and install something?

All types of methods are used by people, ranging from multiple scanning, to running in a sandbox, to running in a VM.

In another post, kwismer wrote,

This has been a policy of mine since Win9x days. How many remember the many freeware and shareware sites? We always asked around in the newsgroups how people like such and such. It wasn't so much about the fear of malware, but just if the program was stable. And we were always curious about other people's opinions.

Many have been infected by rogue security software, and not just by the drive-by attacks. People have actually decided to download/install those programs. Those sites are well-designed and can easily fool the unawares. But a simple internet search for the program name would reveal the scam. See this thread:

Screen Shots of Current Rogues
https://www.wilderssecurity.com/showthread.php?t=244067

So, relying on one's judgment, intuition, reputation of the vendor is the primary method used by many I know in making these decisions.

Many have been infected with files such as P2P, codecs, pirated music and videos. Here, we are in another world, and users have to rely on the hope that a scanner will identify something as malware. A perusal of the hijack forums shows this not to be reliable.

Protecting against this type of attack can be simple or complicated, depending upon the user's mindset: we usually choose what gives us the best peace of mind.

----
rich

 

Good info

 

Cool stuff

 

harsh but true. right on the main page of the site there is an untrue statement of 'fact' about viruses.

if you folks don't even know the basics about what you're protecting against then why should anyone trust you to protect their systems?

the only other page i checked out was the "what makes bluepoint security different?" blog post and it contained this piece of pure snakeoil:

compare that to the old-school av snakeoil that says things like "our product prevents 100% of viruses past, present, and future". whoever writes the copy for your site really needs to be better informed about what not to say.

 

forget about reading statements,they are boring anyway(any statements) just install BPS try it your self and be convince,it really works or if you dont like bps try Defensewall hips after installing one of those 2 try to install malware and see the results and then judge

 

also forgot to mention appguard is another good choice for prevention this is a killer program

http://www.blueridgenetworks.com/products/appguard.php

 

i repeat again 3 principles we have to consider
1)prevention=the most important of all
2)detention= this is where some fails
3)removal= there are some good tools handy

 

somehow an endorsement from someone who clearly throws caution to the wind (trying software without giving it's efficacy due consideration) and ignores clues about competence (those statements you think are boring) doesn't instill confidence in me.

but it does tell me something useful about you. thanks for that

 

oh boy there we go again ok read that is fine but remenber to try the software and then draw any conclusions of the software i encourage you to try it,you wont be disapointed and maybe some thing good come out of it to cover the gap of yours

 

did you check this one out?
http://www.blueridgenetworks.com/products/appguard.php
i recomend to you it is also good for prevention

 

If you're afraid to try new solutions, how will you ever advance your knowledge? Personally, I get my hands dirty with several products a week. I couldn't care less about marketing materials, I test products by fire and I encourage others to do so with ours. How many vendors would recommend that? When testing I ask a few questions. Can they protect the vm or not? Is the vm crashing after malicious code execution? Are they allowing process creation meanwhile telling the user the item has been prevented? Are they blocking after code execution or before? Can I design a threat in the lab that would allow me to simply turn off or bypass the security product?

Throwing caution to the wind is how discoveries are made and how we advance. I do it on a daily basis (in a lab of course!).

 

ummm - by reading? features and capabilities should be adequately documented by the vendor and tested by competent testing organizations.

you encourage people to expose themselves to otherwise unnecessary risk in order to test the efficacy of your software? that doesn't sound very responsible.

hopefully very few.

i don't suppose you caught the irony in that statement.

you throw caution to the wind - in a controlled environment.

 

Are you aware that many new malware are virtual system aware? You may run all the tests / trial by fire inside one of these VM you have running and it will pass with flying colors until it gets into a non-VM system. My recommendation is that you purchase a couple of economical computers, hard drives and imaging software to run these tests on your software before you conclude that they pass all of your tests. I am surprised that many here test under VM systems which is creating a false sense of security while malware writers are setting up their code to sniff them out.

 

i had hear that there are some malware(rootkits)that can bypassed even the VM and trashing the systems that is good idea to use imaging software and maybe this software can not work some times so having the bootable cd will be a good idea and start fresh again

 

I hate to tell you but reading is only going to take your knowledge so far in the security industry. I'm sure if you read the marketing documentation about the unnamed product I tested in the video earlier in this thread, they'd tell you they protected you from malware, viruses etc as they all do. As you can see in the video, marketing and documentation often has nothing to do with the real world.

Our product is being tested by several indepedant testing groups as we speak, agree with you there.

I encourage people to look beyond the hype and test products in a lab environment, yes.

 

Good point. Most of the "vm aware" threats out there that I'm aware of are designed to shut themselves down to prevent reverse engineering of themselves. It was a good move on the malware writers part, it hinders researchers ability to analyze them in a vm environment.

I'm comfortable testing in a vm environment as ours is a baremetal solution running on linux as the host, in a windows environment, may be more of a concern.

 

a) i'm not really part of the security industry, per se.
b) that really depends on what one reads.

i don't trust marketing people as far as i can throw them (and i look forward to having the opportunity to do so). also, marketing and documentation aren't supposed to have anything to do with each other. documentation is supposed to be unbiased facts (not even judgments, just facts) while marketing is almost always lies.

when i read documentation i'm looking for descriptions of how things work, not how well they work. by knowing how things work i can determine how they fail.

i also encourage people to look beyond the hype, but i'm realistic about my expectations regarding their access to a lab. most don't have one, nor the competence to test security software safely. i have done this sort of experimentation in the past, but i don't expect most people to be able to do it safely. they're just not well versed enough on the necessary precautions.