Script Defender Remake?

[EASTER]

Is anyone in favor, including either product developers or freelances that a script interceptor along the lines of AnalogX's now abandoned SD would be worth the effort to compile for that little extra security coverages? And perhaps even leaving open (if possible) where a user could add thir own 3 letter or number extension that would be flagged like ScriptDefender is done in the past for some file associations?

I often sympathized with ErikAlbert over the abandonment of this project since it seemed a very well rounded script catcher that was completely configurable. Script Sentry and others of course are limited in scope in comparison, and am very curious why this simple little prevention type app could be left undone since on uninstall it doesn't exactly return your associations back to their normal defaults as expected.

I taken the effort to gather ALL the .reg scripts courtesy Doug Knox & Kelly's just so if i decide to uninstall i won't be left in a complete panic and frustration as whay Erik experienced with it.

Other then that, is there a reason why a useful small app of this nature just doesn't get the press or attention that it really seems to deserve seeing as it would go a long way in preventing malicious script attacks if compiled to exercise some form of either damage or disruption.

Just curious on what everyone's take is on this. Is it at all worthwhile you think for a developer to fashion something on this order as a separate application?

Although i haven't research as much as i wish i should have up to now i have made a ADS on my own machine that launches an ADS executable via vbs & batch file or both and they work flawlessly. (I use a toy named Rubberball.exe) as the executable.

Taken from this URL:
http://www.cknow.com/vtutor/NTFSADSViruses.html

{QUOTE-> NTFS ADS Viruses
The NT File System (NTFS) contains within it a system called Alternate Data Streams (ADS). This subsystem allows additional data to be linked to a file. The additional data, however, is not always apparent to the user. Windows Explorer and the DIRectory command do not show you the ADS; other file tools (e.g., COPY and MOVE) will recognize and process the attached ADS file.


Note: Alternate Data Streams can attach to a directory as well as a file. Some rootkits (e.g., Mailbot) establish themselves in this way.

Virus Use
An alternate stream file can be an executable and executed in a variety of ways. For our purposes here the files can be exploited by viruses that make their way into files saved as part of the normal stream. In one such exploit the virus (Streams) creates a copy of itself as a temporary EXE file and then copies the original EXE file as an ADS file attached to the temporary EXE file. The temporary EXE file is then renamed to the original EXE name. Now, when the user tries to run the original file they actually run the virus which does its thing and then sends the original program file to the operating system which then runs the program. The only thing you might see is a slight delay in program start.

For a virus like Streams you should not just delete an infected file. If you do the original file will also be lost as it's attached. If your anti-virus software does not provide a recovery utility you will have to use the CAT utility in a manner similar to that described above:

CAT filename.exe:STR newname.exe (this copies the original file to "newname.exe")

COPY /B newname.exe filename.exe (this copies "newname.exe" back to its original name and overwrites the virus)

The virus can be operating system specific. Streams, for example, checks for Windows 2000 and only runs if it's found.

There are other ways a virus might use an alternate data stream. It could, for example, hide most of its code attached to files not normally scanned by virus scanners (e.g., INI or other text files). Only a small executable that extracts the virus would have to be visible and might be easier to hide. There are more malicious things a virus could do as well (please don't ask).

Summary
The NT File System allows alternate data streams to exist attached to files but invisible to some normal file-handling utilities.
Viruses can exploit the NTFS ADS system in a variety of ways. <-QUOTE}

EASTER

[EASTER]

Is there not even a suggestion or opinion on this or do you feel like other apps or SRP are good enough to supercede the need for such a program.

Really would appreciate any constructive feedback or experiences that might be relevant to this type of interest.

Thanks

EASTER

[Pedro]

SRP makes Script Defender basically useless and inferior.

Script Sentry has something extra (it analyses the script rather than just warn on anything, and it can analyze macros), though its usefulness is also limited.

[jmonge]

does drivesentry blocks scripts virus well?any experience?

[MikeNAS]

{QUOTE-> does drivesentry blocks scripts virus well?any experience? <-QUOTE}

Maybe you don't even want to test it...

http://www.wilderssecurity.com/showpost.php?p=1286622&postcount=340

http://www.wilderssecurity.com/showpost.php?p=1286658&postcount=346

[jmonge]

{QUOTE-> Maybe you don't even want to test it...

http://www.wilderssecurity.com/showpost.php?p=1286622&postcount=340

http://www.wilderssecurity.com/showpost.php?p=1286658&postcount=346 <-QUOTE}
mmmmmmmm ??? :doubt:

[Rmus]

{QUOTE-> Is anyone in favor, including either product developers or freelances that a script interceptor along the lines of AnalogX's now abandoned SD would be worth the effort to compile for that little extra security coverages? And perhaps even leaving open (if possible) where a user could add thir own 3 letter or number extension that would be flagged like ScriptDefender is done in the past for some file associations? <-QUOTE}In thinking about 'security coverages' - to use your phrase - I consider the attack vectors. For scripts, they include

1) Scripts triggered by the Browser and/or plugins and similar applications

2) Scripts triggered by macros in MSOffice documents

3) Scripts that get onto the computer and the user clicks to open/run

4) Scripts triggered by autorun.inf files on removable media

We can eliminate 1) since that security is covered by the Browser security configurations

For 2) I believe that current Office applications have Macro protection which alert if a document contains macros.

Script Defender and similar protect well against 3) but protection against this attack mode can also be covered by common sense which should say, Why do I want to open an unknown script file? Or more basic, How will such a file get onto my computer in the first place?

Script Defender will protect against 4) if a Windows command is used to open the file. But, as discussed in another thread, all attacks I've seen use Shell commands and the script engine to start the attack.

Consider:



Autorun.inf
[autorun]
shellexecute=wscript.exe start.vbs

start.vbs

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


So SD will not block this attack:

201746
__________________________________________________

There are other more effective ways of blocking this type of attack. Therefore, I conlude for myself
that programs like Script Defender would not add to security coverage.

My Motto: The fewer applications to fiddle with, the better.

---

[EASTER]

All valid points, and leads me back again to HIPS because if anything were to contain let's say an executable designed to release a script that could delete the entire system, even on reboot as Hard Drive Killer does (I have a copy). This malware completely obliterated a Windows 98 unit once by me accidently clicking on the batch file, in a matter of seconds it went to work and unbekowns to me and confirmed by the virus author, it's designed deliberately for a user to panic and shut down the PC, only to find on start up it finishes the job. It's now been compiled into an executable to drop a script (vbs) or (batch) to do it's thing.

AE would immediately block it, a HIPS would immediately suspend it long enough to investigate it.

Script Defender is probably old hat by now but it offers me anyway an alternative just in case of a security program glitch or for lack of a better term, a "miss".

I haven't tried it with SRP yet.

EASTER

[jmonge]

{QUOTE-> All valid points, and leads me back again to HIPS because if anything were to contain let's say an executable designed to release a script that could delete the entire system, even on reboot as Hard Drive Killer does (I have a copy). This malware completely obliterated a Windows 98 unit once by me accidently clicking on the batch file, in a matter of seconds it went to work and unbekowns to me and confirmed by the virus author, it's designed deliberately for a user to panic and shut down the PC, only to find on start up it finishes the job. It's now been compiled into an executable to drop a script (vbs) or (batch) to do it's thing.

AE would immediately block it, a HIPS would immediately suspend it long enough to investigate it.

Script Defender is probably old hat by now but it offers me anyway an alternative just in case of a security program glitch or for lack of a better term, a "miss".

I haven't tried it with SRP yet.

EASTER <-QUOTE}

i am having a hard time to find a security software that can prevent or block
a cross-site attack malware kind.does Anti Executable Blocks this type of attack?thanks in advance.

[Pedro]

{QUOTE->
I haven't tried it with SRP yet.
<-QUOTE}
It will block it if you use a LUA.

[Toby75]

{QUOTE-> It will block it if you use a LUA. <-QUOTE}

Wouldn't SRP prompt as admin?

[EASTER]

Either/or and irregardless, i would personally (and i don't think i'm in the minority completely) really like to see ScriptDefender remade again if nothing else by someone new, even Script Sentry is been left behind. I know HIPS + SRP likely make them of little use for most anymore, but it sure couldn't hurt to have such an app like i described where you could even add your own 3 letter/number extension and it jump up and alert on it.

I just admire these old style apps and the fact they can still be of some use even on NT systems today.

EASTER

[doktornotor]

{QUOTE->


Autorun.inf
[autorun]
shellexecute=wscript.exe start.vbs

start.vbs

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


So SD will not block this attack:
<-QUOTE}

Pardon me, but this is no attack... this is a feature. If you dislike autorun, then disable it in operating system, instead of complaining that third-party apps don't block legitimate functionality. :blink:

[Peter2150]

{QUOTE-> Either/or and irregardless, i would personally (and i don't think i'm in the minority completely) really like to see ScriptDefender remade again if nothing else by someone new, even Script Sentry is been left behind. I know HIPS + SRP likely make them of little use for most anymore, but it sure couldn't hurt to have such an app like i described where you could even add your own 3 letter/number extension and it jump up and alert on it.

I just admire these old style apps and the fact they can still be of some use even on NT systems today.

EASTER <-QUOTE}

Easter, you need a reality check. You acknowledge they are of little use, but wish someone would develop one. Okay so a developer says he needs 2000 sales at $30 to make it viable. You gonna cough up the $60000? That's the heart of the problem.

Pete

[EASTER]

{QUOTE-> Easter, you need a reality check. You acknowledge they are of little use, but wish someone would develop one. Okay so a developer says he needs 2000 sales at $30 to make it viable. You gonna cough up the $60000? That's the heart of the problem.

Pete <-QUOTE}

Pete, with all do respect, you need a reality check. Older apps are as efficient now as they were eons again, well at least some of them are. And you're way off base in your figures and obviously don't favor freeware developers and freelancers because of the almighty dollar thats lodge in the brain.

Not everyone needs greats amount of greenbacks to compile programs, then i guess you never compile any yourself personally but rather rely on forking over for commercial interests without hesitation, and thats all and good for those who have it to throw around.

EASTER

[Pedro]

{QUOTE-> Wouldn't SRP prompt as admin? <-QUOTE}
AFAIK, SRP does not prompt ever. It blocks.

If you configure SRP to skip Administrators, then SRP does not block for administrators.
If you apply SRP for all including admins, it will block, only admins can write to Program Files and Windows folders - where normally SRP allows execution (it really depends on configuration, but it's the 'default' in a way).

See here: http://www.mechbgon.com/srp/

[Rmus]

[refering to using USB/Autorun to launch a script file]

{QUOTE-> Pardon me, but this is no attack... this is a feature. If you dislike autorun, then disable it in operating system, instead of complaining that third-party apps don't block legitimate functionality. :blink: <-QUOTE}It's an attack, albeit one that exploits the open door of a feature.

I stated,

{QUOTE-> There are other more effective ways of blocking this type of attack. <-QUOTE}and disabling Autorun is one of several ways.

---

[Peter2150]

{QUOTE-> Pete, with all do respect, you need a reality check. Older apps are as efficient now as they were eons again, well at least some of them are. And you're way off base in your figures and obviously don't favor freeware developers and freelancers because of the almighty dollar thats lodge in the brain.

Not everyone needs greats amount of greenbacks to compile programs, then i guess you never compile any yourself personally but rather rely on forking over for commercial interests without hesitation, and thats all and good for those who have it to throw around.

EASTER <-QUOTE}

Easter, I have no quarrel that in many cases older programs are better. But if your logic was correct you wouldn't have to be asking for the script programs you'd have them. Obviously for whatever the reason it isn't worth anyone's time.

[Pedro]

I think there would be some use for a good script blocker, just not a 'Script Defender remake'.
I look at the best, imo Script Sentry and WormGuard, and i think something better along these lines would be useful.

They're sort of an Antivirus, for scripts, but with very generic heuristics (if i can call it that, don't know).
They detect a script being executed, block it, analyze it and tell us what these could do - open a file, delete a file, execute a program, etc.

The best use for a script blocker is of course blocking the possibility of a script running without our knowledge. A whitelist for scripts.

As they stand, they can be bypassed (run a script in cmd and it will pass, CD with autorun..). But this can surely be improved.

Then, they have to add languages and interpreters to detect, analyze and block. Not trivial.
And perhaps they could introduce better, more intelligent rules for the analysis, like delete a file + system32.

All in all, an AV does/could do this, perhaps in some advanced settings - as this arises many FP's; SS and WG flag innocent scripts as well as bad ones, but the user is given a bit of information on the reason.

It's getting late, and my brain is failing right now. I'm missing something.

[EASTER]

{QUOTE-> AFAIK, SRP does not prompt ever. It blocks.

If you configure SRP to skip Administrators, then SRP does not block for administrators.
If you apply SRP for all including admins, it will block, only admins can write to Program Files and Windows folders - where normally SRP allows execution (it really depends on configuration, but it's the 'default' in a way).

See here: http://www.mechbgon.com/srp/ <-QUOTE}

And just by chance, and it's happened before with Microsoft Systems, what happens if something, let's say a destructive malware app or even some script bypasses SRP, then what?

There are plenty of intelligent computer minds out there that likely could easily disable it as easy as malware authors blow the tires off System Restore, and you're right, theres no PROMPT, it just blocks, so if it was happened to become bypassed or rendered disabled by some cruel & clever means, the user would never know about it.

EASTER

[EASTER]

{QUOTE-> Easter, I have no quarrel that in many cases older programs are better. But if your logic was correct you wouldn't have to be asking for the script programs you'd have them. Obviously for whatever the reason it isn't worth anyone's time. <-QUOTE}

Unfortunately it does seem the case, at least for the time being as regards open-source or commercial developers to bother with such an app. But i recall ErikAlbert going heads over heels about this app untill he uninstalled it and found what SD's associations were covered not working anymore. Of course theres a simple workaround for that and it's not that big a deal for someone willing to apply the default reg files and such to restore them.

I know some like yourself find it much easier just to use SandboxIE and thats a potent app PERIOD!

Just so you don't get the wrong idea, the applying of ScriptDefender and wishful thinking on seeing it remade again is purely for research purposes on this end. But if it was redone by someone i think it would be a great addition to script protection for users interested in running less security apps.

Then again, AV's and other "resident" AS apps i think have taken a huge bite out of those type virus script writers efforts as well as HIPS has done, and all but have rendered them completely useless. SRP too.

EASTER

[Pedro]

{QUOTE-> And just by chance, and it's happened before with Microsoft Systems, what happens if something, let's say a destructive malware app or even some script bypasses SRP, then what?

There are plenty of intelligent computer minds out there that likely could easily disable it as easy as malware authors blow the tires off System Restore, and you're right, theres no PROMPT, it just blocks, so if it was happened to become bypassed or rendered disabled by some cruel & clever means, the user would never know about it. <-QUOTE}
Lets separate the issues:

If it's an exe, vbs, dll - it's blocked, unless there's a bug. Saying a bug is possible leads nowhere.

If it's a script not blocked by SRP, sure.
These are interpreted by some program allowed in SRP (if i'm wrong someone correct me), and probably can be adjusted in that program (Word has a good policy for macros for instance).
If that program doesn't have such feature, it's where such script blocker could prove useful - but forget Script Defender, it's very basic.
And at least they are limited by the LUA.

Finally you say that if it doesn't prompt, it doesn't prompt when it fails either. Is this correct?
If it is, note that this is the same for HIPS as well. Do you disagree?

Then there's exploits. I really don't know how to think on it, other than "at least it's limited by the OS".

[muf]

The application you are looking for already exists. Regrun RunGuard does everything ScriptDefender and WormGuard does, and more. It's been around for years and i've used it for years. Your test script for running the calculator was easily stopped by it.

muf

[Rmus]

Can you post a screenshot of the alert you got with the test script?

---

[muf]

{QUOTE-> Can you post a screenshot of the alert you got with the test script?

--- <-QUOTE}

As requested.

muf

[muf]

I also let it auto run from a cd i burned the files to.

[Pedro]

I forgot about RegRun. RunGuard+WG+Script Sentry :P

Last time i tried i couldn't make it autorun. Now it does, and i see Runguard's alert as well.

If i open cmd, and type 'wscript start.vbs' i get no alert, calc executed.
So it's not the same thing.

The thing about Runguard is that it comes with RegRun. I never got along with that. From installation it's window after window opening non-stop. All kinds of settings and options.
He should make a standalone.

[muf]

{QUOTE-> If i open cmd, and type 'wscript start.vbs' i get no alert, calc executed. <-QUOTE}

I concur. Initializing the command this way does in fact open calc without RunGuard stopping it. Although if you add cmd.exe to the blacklist within RunGuard then the cmd can not run in the first place.

muf

[Rmus]

Thanks, muf, for confirming about the command prompt.

{QUOTE-> I also let it auto run from a cd i burned the files to. <-QUOTE}Can you post the contents of the autorun file you used?

---

[EASTER]

{QUOTE-> The application you are looking for already exists. Regrun RunGuard does everything ScriptDefender and WormGuard does, and more. It's been around for years and i've used it for years. Your test script for running the calculator was easily stopped by it.

muf <-QUOTE}

Thanks muf for filling us in on that, but is this a totally separate app, or is integrated into Greatis entire anti program?

All that site shows as a headliner is...............
RegGuard protects Windows startup registry keys from changing.

{QUOTE-> RegRun RunGuard Analyze script files (VBS, JS), Microsoft Office files, registry files or HTML files before execution. <-QUOTE}

My question is just how many it can cover, theres over time been a pletora of invasion into scripts like CHM, HLP, etc. to name a few. And from what i seen theres a definite limit to how many associations/extensions that they can cover.

Then lists registry entries it covers, any HIPS can do that and cover much more. (Curious)

EASTER

[muf]

{QUOTE-> Can you post the contents of the autorun file you used?

--- <-QUOTE}

Here's a screenie of the contents of the cd and each of the files open in notepad.

[muf]

{QUOTE-> Thanks muf for filling us in on that, but is this a totally separate app, or is integrated into Greatis entire anti program? <-QUOTE}

It is integrated within Regrun as part of the suite. http://www.greatis.com/security/detail.htm#FULL
It appears that RunGuard is only available on Gold and Platinum version's.

{QUOTE->
My question is just how many it can cover, theres over time been a pletora of invasion into scripts like CHM, HLP, etc. to name a few. And from what i seen theres a definite limit to how many associations/extensions that they can cover.

Then lists registry entries it covers, any HIPS can do that and cover much more. (Curious)
<-QUOTE}

It has set file types it monitors, but you can add more to the blacklist. As far as I can see, you could put any number of files types in the blacklist. Doesn't appear to be a limit.

See these screenies.

[Rmus]

Hello muf,

It doesn't make sense to me that RegRun alerts to the autorun command using

shellexecute=wscript.exe,

yet does not alert when wscript.exe is run from a command prompt.

Can you change the filename start.vbs to start.jnk and run again from your CD using this autorun.inf file:

------------------------------
[AutoRun]
wscript /e:vbscript "start.jnk"
------------------------------

thanks,


----
rich

[muf]

{QUOTE-> Hello muf,

It doesn't make sense to me that RegRun alerts to the autorun command using

shellexecute=wscript.exe,

yet does not alert when wscript.exe is run from a command prompt.

Can you change the filename start.vbs to start.jnk and run again from your CD using this autorun.inf file:

------------------------------
[AutoRun]
wscript /e:vbscript "start.jnk"
------------------------------

thanks,


----
rich <-QUOTE}

Ok, I did what you said but that makes no sense really as Regrun is not designed to stop .jnk files. I popped the disc in and it opened the folder up that contains both files. It didn't run the start.jnk file. Not sure what result you were hoping for tbh.

muf

[Rmus]

Sorry, muf,

I gave you the wrong syntax for the Autorun.inf file. It should be

--------------------------------------------------------
[Autorun]
shellexecute=wscript.exe /e:vbscript "start.jnk"
--------------------------------------------------------


Would you also test with start.vbs again using:


----------------------------------------------
[autorun]
open=wscript.exe /e:vbscript "start.vbs"
----------------------------------------------


{QUOTE-> Not sure what result you were hoping for tbh. <-QUOTE}I'll explain when I see these results!


thanks,


----
rich

[muf]

{QUOTE-> Sorry, muf,

I gave you the wrong syntax for the Autorun.inf file. It should be

--------------------------------------------------------
[Autorun]
shellexecute=wscript.exe /e:vbscript "start.jnk"
--------------------------------------------------------


Would you also test with start.vbs again using:


----------------------------------------------
[autorun]
open=wscript.exe /e:vbscript "start.vbs"
----------------------------------------------


I'll explain when I see these results!


thanks,


----
rich <-QUOTE}

Rich,

I tried both methods as you requested. Pleased to let you know that with this particular script the calculator ran and RunGuard did not alert. 'Pleased' may not be the term I mean, but I suspect this result will give you some satisfactory information.

muf

[Rmus]

Thanks, muf.

Here are the results and comments about the different Autorun.inf commands:

1)
----------------------------------------------
Alert from RunGuard:
shellexecute=wscript.exe start.vbs

No Alert:
shellexecute=wscript.exe /e:vbscript "start.jnk"
-------------------------------------------------

This confirms what you said about RegRun watching for .vbs files. A spoofed scripting file will run because the script engine command with correct parameters is not concerned about file extensions.

But "open=start.jnk" will not work because that command uses Windows to associate the file extension with a program, and of course, there is nothing associated with .jnk.

2)
------------------------------------------------
Alert:
shellexecute=wscript.exe start.vbs

No Alert:
open=wscript.exe /e:vbscript "start.vbs"
------------------------------------------------

This is interesting, because Script Defender does not alert to the command, shellexecute=
Shellexecute is a Windows API command, so perhaps RegRun is looking deeper than the other script blocking programs? This would be an interesting question for greatis.com.

The command open=wscript.exe
passes directly to the script engine, in the same way cmd.exe does (not using Windows file associations),
and none of the script blocking programs will alert.

The solution, as you surmised, is to block or black list cmd.exe, and by deduction, also wscript.exe

Should one be concerned about this? Analyses of some recent USB pen drive and picture frame exploits where the autorun.inf file is listed do not show a .vbs file.

Typical autorun.inf file seen in security analyses:

[autorun]
open=kwjkpww.exe
shell\open=Open
shell\open\Command=kwjkpww.exe
shell\explore=Explore
shell\explore\Command=kwjkpww.exe
However, the Switchblade and Hacksaw USB exploits did use a .vbs file, and their autorun.inf files showed:

[autorun]
open=wscript go.vbs
This would bypass script blocking programs.

Some other exploits also use autorun.inf and .vbs files, but unfortunately, the analyses do not list the contents of the autorun.inf file so we don't know the commands used. Here is one:

Worm:VBS/AutoRun.B
http://www.f-secure.com/v-descs/worm_vbs_autorun_b.shtml
{QUOTE-> The autorun.inf causes the __.vbs file to be executed when an infected drive
is accessed with a computer that has autorun enabled on the drive in question. <-QUOTE}Other preventative measures for this type of exploit include:

==> disabling AutoRun;

==> having a policy of not permitting other people's USB devices on your computer;

==> avoiding U3-type USB flash drives (autorun doesn't work on non-U3 types). If you used your non-U3 type flash drive to copy some files from another person's computer which was infected with a USB virus, the virus would install on your flash drive but would not run on your computer. To confirm, I put a USB exploit on my non-U3 flash drive and the Autorun.inf file does not run when I plug it into my computer.

==> others _______________?

Some References

infections on pendrive
http://www.computing.net/answers/security/infections-on-pendrive/19560.html

Security Watch Island Hopping
http://technet.microsoft.com/en-us/magazine/cc137730.aspx

CES Risk: Free USB Flash Drives
http://www.informationweek.com/news/security/cybercrime/showArticle.jhtml?articleID=205210426


---