Faronics Anti-Executable v3 Beta

AE2 is not once caused my XP Pro system a single glitch, and coupled with ScriptDefender that pretty much locks down intruding attempts from various sources built into a windows system.

All the best for v3, but as long as v2 continues to work as it always has, i don't see upsetting my set up or taking a chance on bugs.

EASTER

 

AE has one, anything what isn't whitelisted, is killed immediately. Only the user can install not-whitelisted executables by turning AE off. It's no secret that the user himself is the weakest link in any security setup.

 

bypass.dll is here to proove you wrong Erik unfortunately :/

i second that nothing goes as far as 100%

 

bypass.dll was installed while AE = ON and on HIGH ? I want to verify this myself, can you send it to me by email ?

 

Oh have we hit a nerve now

Let's us know the results by all means, but i lay odds that little POC CANNOT evade EQS! That's why i use a HIPS on all my units unless i have a system just for watching FLV and other DVD cinemas.

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

EASTER

 

1. Open AE
2. Click on the Configuration Tab
3. Set the level on HIGH
4. And you will read that AE protects you against unauthorized DRIVERS and .DLL-files.

That's why I want to test this myself, otherwise I don't believe it. I don't trust second hand information.

PS: after reading your link, bypass.dll was installed with level = LOW and then it's possible to install an unauthorized .DLL-file, but my level = HIGH all the time. I'm a professional newbie+
Killdisk, robodog, robotdog, ... were also tested without AE, otherwise they couldn't do the test.

So AE has a detection rate of 100%.

 

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

This cannot be done with AE's copy protection enabled.

If you want to test with a .dll, I have one on my server. It's renamed to Schannel
for a test of a recent Safari vulnerability:

hxxp://www.urs2.net/rsj/computing/tests/8js/schannel.dll

Here is the file recently scanned, showing it is clean:

http://www.urs2.net/rsj/computing/tests/8js/schannel-scan.gif

Attempting to download the .dll will bring up a Download Prompt box. AE will not permit you to download.

If you want to make the test more interesting, I made an .html file that will attempt to download the file
by remote code execution, bypassing the Download Prompt.

(In a real exploit, if the file can sneak in, a script could attempt to run it.)

It requires IE6 to work:

hxxp://www.urs2.net/rsj/computing/tests/8js/happy-dll.html

AE will flag the attempt. The "Reason: Copy" means here, copy to disk (Download):


_________________________________________________________________

That test in the other thread reminds me of the firewall leaktests, where you have to disable your security
to permit the trojan test executable to download. What is the sense in that?

 

I for one always enjoy your tests and especially screens of AE in action. I use IE6 and it's likely i will always use IE6 because it's never gave me a single problem in XP unlike 98, even though i keep on hand an older Opera browser for those sites that deliberately close when they detect the browser is IE, and i run into plenty of those. LoL

Can you imagine if AE decided to incorporate script defenses like what is exhibited in AnalogX's ScriptDefender?

I suppose since MS is migrating more away from this type potential danger the need will become less for defense against scripts, but i used to see batch, vbs, and a number of other scripts that made very efficient use of intruding into Windows and causing all sorts of issues. They can still be realized on NT units we use in XP and i suppose to a greater or lesser extent Server systems.

EASTER

 

Did you try the test?

In my view, it would be pretty weak, since ScriptDefender (SD) works by flagging by file extension and file association, and as such, is effective in protecting against yourself -- or another person sitting at your computer -- from accidently clicking to open a script file, and not much more.

Consider working from a Command Prompt. The command "start" executes the file by extension and association from within Windows.
With SD enabled, it effectively blocks. Using your favorite .vbs test file:


____________________________________________________

However, if I use the command "wscript.exe" then neither file extension nor association come into play.
Windows does not participate in the execution, so SD doesn't know that anything is going on:


____________________________________________________

This is further proved if I change the file extension to a non-script type:


____________________________________________________

Now, to simulate a real exploit using the above. On my USB drive I put an autorun.inf file and a .vbs file.
This resembles the old "Switchblade" USB exploit:

Code:

[autorun]
wscript /e:vbscript start.vbs

.......

set shell = CreateObject("WScript.Shell")
shell.Run "calc.exe"

If I attempt to open the .vbs file directly, SD intervenes:


_________________________________________________________________________

But if I reconnect the drive, the Autorun.inf file executes wscript.exe and the calculator is started:


_______________________________________________________

You should run your own test just to confirm, or discover that something quirky is going on at my end!

The only sure way that I've found to keep scripts from running is to disable Windows Script Host in the Registry.

And we haven't even considered Browsers scripts - much more dangerous and likely to be encountered, in my view.

It would be a daunting task for AE to develop such a program to analyze script code. I communicated with Faronics about this in the early days of the release of AE, and the response was that it was an interesting concept, but because of the different script languages, very difficult to overcome.

In executable code, there is just binary language.


---

 

Makes a whole lot of sense Rmus, and again so many thanks for screening the pics along with your factual details and the reason AE doesn't in fact add scripting. IE is a funny beast, and it's simplicity makes it obviously the ideal arena for compromising the system thru scripts that utilize IE to the fullest.

I don't particularly favor disabling the scripting host at all, but you bring up some serious prospects as to the lack of alternatives to prevent this app from easily carrying out whatever instructions are commanded for it to make.

EASTER

 

Hi Easter,

You've obviously seen a lot of malware attacks.

Can you describe some that utilize scripts? Understanding how they are triggered, what the payload is, etc,
will help to figure out a way to prevent them.

--

 

Rmus,
ScriptDefender is not an option, it has a serious uninstall bug corrupting my system, proven by another member as well.

I disabled Scripting Host, which is responsible for executing files with the following extensions : js, jse, vbe, vbs, wsf, wsh.
Firefox has NoScript and is an untrusted application in DW. Is that enough ?

 

From the attacks I've seen, I say yes. This would seem to cover both types of script exploits.

How did you disable Scripting Host?

--

 

Using XP-AntiSpy, a little program with a number of security settings and one of them is Scripting Host.

EDIT:
It seems to work, try to run "eventquery.vbs", one of the scripts in Windows.
Got this warning message :
"Windows Script Host access is disabled on this machine. Contact your administrator for details."
I didn't contact him, because I'm the administrator.

 

here is a download link to a simple little portable exe that will disable or re enable scripting host.

http://service1.symantec.com/sarc/sarc.nsf/html/pf/win.script.hosting.html

Modified download link. lucas1985

 

Yes, I just looked and see that I have it from a short trial a while back. Rather neat.

Checking/unchecking the setting changes the Registry Entry. It saves having to set up your own Registry File.

Last evening I was discussing this scripts stuff with a friend, who remarked
that I should consider .bat files, which are executed by cmd.exe, not WSH.

Using my AutorRun.inf example, I'll substitute a .bat file:

Code:

[autorun]
open=1.bat

.....

@Echo HELLO!
@Echo I just started your Calculator!!!!!!
calc
PAUSE

cls

_________________________________________________________

If I disable cmd.exe, the attack does not work:


_________________________________________________________

If disabling these programs (WSH and Command Prompt) is something a person wants to do, it's easy
with Registry Files to toggle Enable/Disable.

I'm not sure if XP-antispy allows for disabling the command prompt.

Script files don't seem to be used so much any more in attacks.

Why be so fancy when a la Storm, malware people can just send an
enticing email, knowing that many people will click, and many people have
no protection against a trojan attack.

Proof is seen in the size of the Storm Botnet.

---

 

XP-AntiSpy doesn't disable the command prompt, I can still run it.
You can disable "regedit", not sure if that is a benefit or not. I don't like to cripple my system too much.

 

This is an important consideration, IMO.

The amount of "tweaking" and "hardening" of the system one does really depends on one's comfort level, how probable it is that you think you will encounter this or that type of attack.

You proceed accordingly.

There are many hypothetical vulnerabilities. How many of them become real attacks?

For example, I've asked Easter in an above post for what he knows of current attacks using script files.
We can include .bat files also.

---

 

I don't mind blocking scripts, but there is a difference with AE.
AE doesn't cripple my system and every authorized executable can run without problems.
If I disable Scripting Host, my system is crippled, because I can't run the good scripts in my system anymore and that's what bothering me. It's not because I run scripts all the time, I don't even do this, but it's the principle that counts.

 

@ErikAlbert

Script Defender DOES NOT corrupt your system, at least it never has mine, it just has a lazy bug on uninstall that won't return your previous script associations right back as they were before applying it's protection. If you visit Doug Knox's website and download his .reg files that return those associations back to defaults, i don't see any problem for you to run it again.

I tested this and it works, and thats the only reason i don't have a problem using Script Defender again. If i decide to take it out, i then just simply click on whichever file association is screwed up and it's right back to normal defaults again.

In fact i go as far as cleaning out the registry of any entries it leaves behind that says ScriptDefender just to be sure nothing is wasting registry space too.

I wouldn't be too timid as long as you keep a folder of those reg files to return your scripts back to normal again. It's really very simple.

 

I don't want to discuss this. ScriptDefender is no option, let them fix that serious bug first. I'm not going to learn how to fix the errors caused by a software that doesn't work properly.

 

From the description:

This is misleading, for it is not really disabling/enabling WSH; rather, it prevents those classes from executing from within Windows. This will prevent stuff like vbs loveletter:

http://en.wikipedia.org/wiki/ILOVEYOU

But this does not prevent executing by a command use of wscript.exe.

Therefore, since most attacks (most recent USB) use an autorun file with the wscript.exe command,
this utility will not prevent the attack, as I just confirmed:






__________________________________________________________________

Enabling/Disabling WSH itself in the Registry -- either with a utility like XP-antispy, or directly with .reg files --
is the only sure way that I've seen (so far) to block all ways of executing a script file.

I'm with you on this.

Two at the university use selective blocking. They disable it when using files from students' portable media.
In their view, other than that, the threat is not worth worrying about.

The comfort level, again!

Another approach, rather than disabling WSH, is to analyze what the attack methods are. (Still waiting to hear from Easter -- or anyone)

That is, how can a malicious script file become executed remotely?

The only recent ones I've seen are triggered by AutoRun.inf files. If you have disabled AutoRun for your USB drive with TweakUI,
Windows cannot read the AutoRun.inf file on that drive.

For some, this is enough.

The comfort level again!


---

 

I'll have to drudge up some of my old scripts on another drive so pls be patient untill i can get to them, but i have a massive collection (old) of vbs, bat, hta, etc files that some of them were written quite cleverly. Cleverly enough to easily invade a system and create, delete, copy, you name it, all sorts of disturbing behavior. On XP we also have to beware of scripts that can make use of ntvdm.exe to invade the registry. There are strict limits on just how far scripts can go, mentioned was cmd or the console, that's another path to evading the more common (and simple to detect) activity intended to interact maliciously should a script tap into that channel.

Thanks EASTER

 

I know that there are lots of script files out there that can be used for malicious means.

What I want are how they are used in specific attacks (non-browser for this discussion) - how are they remotely triggered.

We can talk all day about what script files can to. Like what a rootkit can do. I want to know how to prevent them from being executed.

Until we can see specific attacks (like the USB picture frame and pen drive attacks, for example) everything is hypothetical.

---

 

That is what I want to know too, but it has to be a solution, that doesn't affect the good scripts in my system. I've been searching on the internet, so far nothing.