Test Your Security For Script Blocking

[Rmus]

In another thread, Easter mentioned that EQS blocks scripts.

http://www.wilderssecurity.com/showthread.php?p=1204127#post1204127

I sent him a PM and asked him to test specifically for blocking scripts launched by Remote Code Execution from external media.

I thought that others might want to do the test with your current security, so I decided to post the test here.

It involves making an AutoRun.inf file and a .vbs file to test for .vbs scripts; And the same for .bat files.

.vbs

AutoRun.inf


[Autorun]
UseAutoPlay=1
shellexecute=wscript.exe test.vbs


test.vbs file:


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


Burn both files to a CD, let the CD run, and post your results with screen shots showing
the alert message from your security.

-OR-

Put the files on a U3 type of USB media and connect it to the computer.


.bat

Autorun.inf file:


[Autorun]
UseAutoPlay=1
shellexecute=cmd.exe test.bat


test.bat file:


@ECHO OFF
Echo.
ECHO Hello!!!!!!!!!!!!!!!!!!
Echo.
PAUSE
CLS


These can test two things:

1) With Autorun.inf files *not* blocked, see how you are protected from running of .vbs and .bat files by remote code execution

2) Enable your blocking of Autorun.inf files to test that this Autorun.inf file is prevented from running.


----
rich

[EASTER]

Cool beans!

I have to step away from the forums for a bit to run it so will show something on the results soon.

I have CD's handy but i also have my C: folder set to run autorun.inf files, but i see your interest is in "remote" as in external source so i'll burn it to a blank and see what pans out here.

EASTER

[aigle]

-{ Quote: "In another thread, Easter mentioned that EQS blocks scripts.
" }-
As far as I know EQS or other such HIPS does not block scripts.

[Rmus]

What about blocking cmd.exe or wscript.exe from running those files from external media?


----
rich

[aigle]

Hi Rmus! These autoplay not working on my CDs. >:(

I tried this:
-{ Quote: "
[autorun]
OPEN=test.bat
" }-

Actually CFP has a lot of default rules that I have deleted so I can,t say on default settings how it will do. Even my own rules were flawed. I have tweaked the rules and after tweaks, this is what I get( after tweaking my rules I will repeat).

198586
198587
198588
198589

Edit: Sorry I am in hurry now. Might explain the pop ups later- not sure- dead busy. There is GesWall.s security alert as well( CD isolation rule- untrusted CD Rom).

Note: I allowed all.

[aigle]

I don,t know how can I run autoplay for vbs file.

[EASTER]

OK, anyone with EQS 3.41 "AND" 4.0 (beta) should obviously get this alert as i did immediately, you can see the "TARGET" file Wscript.exe is preparing to run. command(finjan.vbs)

This is just a quick starter result, i'm going to see if this is the only stopping point or not because after i allowed it took a little while but it did copy to the newly created desktop folder here some files.

Oh yeah. this is finjan vbscript test not the delete volume yet.

In case someone with EQS notices and wonders about the alert text at the top of the prompt, ACTIVATING PROGRAM ACTIVITY Options: Pass/Deny, that's my own doing instead of the default info EQS shows normally. I done something similar like this with ALL the alerts in order to indicate EXACTLY what the EQS code is signifying instead of the casual information it always shows. Makes for me each particular alert/identification more exact.

[aigle]

With EQS:

[Rmus]

-{ Quote: "Hi Rmus! These autoplay not working on my CDs.

I tried this:

-{ Quote: "[autorun]
OPEN=test.bat" }-

I don,t know how can I run autoplay for vbs file." }-Please use the AutoRun.inf files I posted above.

From your screen shot, it looks like the .bat file executed?


----
rich

[Rmus]

-{ Quote: "OK, anyone with EQS 3.41 "AND" 4.0 (beta) should obviously get this alert as i did immediately, you can see the "TARGET" file Wscript.exe is preparing to run. " }-As I understand your alert, wscript.exe is prevented from running, rather than just blocking a .vbs file.

This is an important distinction (more on that later).


----
rich

[EASTER]

-{ Quote: "As I understand your alert, wscript.exe is prevented from running, rather than just blocking a .vbs file.

This is an important distinction (more on that later).


----
rich" }-

Ok, i think i see what your arriving at regarding distinction. :)

Keep in mind that Scripts alone cannot run at all without a supporting SOURCE which equalz an Executable on windows platform, just like a .txt and the like files are dormant without the executable Notepad.exe to drive it.

The same applies to .bat, cmd, etc which depend on Windows Command Console and so forth.

[aigle]

vbs file with EQS n CFP, it did not run automatically. I have to click on USB memory stick icon.

198593
198596
198594
198595

[aigle]

-{ Quote: "Please use the AutoRun.inf files I posted above. " }-

Did not work well.
-{ Quote: "
From your screen shot, it looks like the .bat file executed?
" }-
I allowed everyl alert in all cases to see all the alerts.

[Rmus]

-{ Quote: "Did not work well.

I allowed everyl alert in all cases to see all the alerts." }-OK, thanks. It looks like EQS successfully blocks wscript.exe and cmd.exe from running without permission.


----
rich

[aigle]

Eaxctly same with CFP.

[Rmus]

-{ Quote: "You wrote, "As I understand your alert, wscript.exe is prevented from running, rather than just blocking a .vbs file."

Ok, i think i see what your arriving at regarding distinction. :)

Keep in mind that Scripts alone cannot run at all without a supporting SOURCE which equalz an Executable on windows platform, just like a .txt and the like files are dormant without the executable Notepad.exe to drive it.

The same applies to .bat, cmd, etc which depend on Windows Command Console and so forth." }-This is why programs like Script Defender don't work for launching scripts using wscript.exe from external media. This is also true for WormGuard.

SD intercepts the command to launch a .vbs or .bat file when the file is double-clicked on the hard drive
by modifying the Registry to pass the command directly to SD rather than to wscript.exe or cmd.exe:

198601
_____________________________________________________________

198602
_____________________________________________________________

I've never seen the usefulness of this type of program, since for malware to run in this way,
two conditions are required:

1) the malicious script file has to somehow get onto the computer

2) the user has to decide to double-click the file

More dangerous are

1) scripts embedded in a web page which are interpreted automatically by the browser, and not by wscript.exe.
The solution here is to block scripts with browser settings.

2) scripts that run by cmd.exe or wscript.exe automatically via Remote Code Execution from removable media such as

==> USB flash drive of the U3 type which emulate a CD and can run an AutoRun.inf file

==> other USB devices such as a digital picture frame which also uses AutoRun.inf file

Here, there are two solutions

1) Block the running of the AutoRun.inf file. Notice I didn't say, "block autorun" because with the AutoPlay command, the AutoRun.inf file may or may not execute, depending on what settings one uses to block.

2) Block the running of wscript.exe and cmd.exe - the "supporting SOURCE" as you put it.

With EQS and Comodo, as I look at the screen shots, the alert message prompts for Allow or Deny.

For those without those types of programs who prefer a simple Default Deny solution, one way is to create .reg files to toggle the enabling/disabling of wscript.exe and cmd.exe so that any attempt to run a file that uses these executables when disabled will be Denied by default:


198605
_____________________________________________________

198606
_____________________________________________________

This method is used by faculty who transfer files to students' USB drives.
Students may not know their drives are infected. (this goes back to the days of floppy drives)

Others may suggest another solution.

The examples of AutoRun.inf files I gave in the first post are based on known USB exploits
going back to Switchblade, and have been seen in other digital media.

It's evident that this method of attack requires the user to connect an unknown USB device.

Finally, since all of the known USB exploits attempt to install a malicious executable file,
employing White Listing will effectively block this, if all else faile.


----
rich

[Mrkvonic]

Hello,

Script blocking is ... well, ok ... but quite a few production experiments use scripts to automate procedures and decrease the workload on the user.

Blocking scripts (or even the command line) feels like escaping from reality. I think disabling automated launching of scripts is more reasonable - rather than blocking the scripts themselves.

Mrk

[Rmus]

I agree, which is why I prefer to toggle the settings, as I like AutoRun to be automatic when I use my own CDs/USB media.

Then, just disable when using unknown media.


----
rich

[Rasheed187]

I will perhaps test it later, but I doubt that this stuff would work on my machine. Firstly, cmd.exe and wscript.exe can´t launch automaticly, secondly, BAT files can´t launch at all (blocked by SRP), and thirdly, I have removed the "autorun" option from all drives (A to Z).

[Rmus]

Yes, SRP is another good option that secures against this.

-{ Quote: "and thirdly, I have removed the "autorun" option from all drives (A to Z)." }-Can you explain how you do this? Is it a SRP setting?


----
rich

[Mrkvonic]

Hello,

Start > run > gpedit.msc
Computer Configuration > Administrative Templates > System
Turn off Autoplay - set to Enabled - meaning the option is enabled, which is fact turns off Autoplay.

Furthermore, you need to disable CD-ROM play.

Administrative Templates > Windows Components > IE > Advanced Page
Allow active content from CD - set to Disabled.

IE is misleading - points to entire Explorer thingie, to the best of my knowledge.

Furthermore, you can disable via registry.

Finally, add disallowed entry for autorun.inf under SRP:
Computer Configuration > Windows Settings > SRP > Additional Rules
Create new rule, by name, disallowed

Hope this explains...

Also, you might like this:
http://www.dedoimedo.com/computers/policies.html

Mrk

[Rmus]

For those who don't have XP-Pro, TweakUI is easy to configure.
Note that you have to disable the drive, and not just drive type
in order to prevent the AutoPlay command from running in the AutoRun.inf file:


198614
___________________________________________________



----
rich

[Pedro]

Ok, i tried it in VirtualBox. I couldn't make it "autorun", but double-clicking the vbs from the "drive" gave me a prompt from RunGuard (RegRun). Wormguard didn't make a peep as you said.
198615

The bat one is only blocked by SSM by blocking cmd. Which is honest in my case, sort of, since cmd is blocked in disconnect UI, and set to ask when connected.

EDIT: Script Sentry seems to block it as well (?). I say seems, since it's not autoplay. But it does block when WG didn't. (again ?)
198616

[lucas1985]

-{ Quote: "But it does block when WG didn't. (again ?)
198616" }-
Remember that WG analyzes the content/instructions of the script. If it doesn't find any malicious code, it doesn't alert.

[Rmus]

-{ Quote: "EDIT: Script Sentry seems to block it as well (?). I say seems, since it's not autoplay. But it does block when WG didn't. (again ?)" }-You can simulate the action of the AutoRun.inf file by opening Start|Run and type (using your drive letter)

wscript.exe D:\test.vbs

and click OK

or do the same thing from a command prompt,

to see what Script Sentry will do.


----
rich

[Pedro]

I tried it with Script Sentry's vbs test file instead of the above, and WG does block. So it's not a problem of detecting the vbs from a CD (wouldn't make sense anyway), but that the 'paranoid' WG doesn't warn about a vbs that executes a program.
Yet it detects SS's test:

(attachment in progress..)
unable to upload, for some reason

[Pedro]

-{ Quote: "You can simulate the action of the AutoRun.inf file by opening Start|Run and type (using your drive letter)

wscript.exe D:\test.vbs

and click OK

or do the same thing from a command prompt,

to see what Script Sentry will do. " }-
Nothing, just like RunGuard. Some lights are turning on, thank you Rich. :)

Tried WG with the Script Sentry's test file (detected by WG by doubleclicking the file) and nothing as well.

So, none of these programs are "complete".

[Rmus]

-{ Quote: "So, none of these programs are "complete"." }-You could also say in this way, that none of these programs will prevent a remote command on removable media from launching the script.

BTW - using a CD for testing AutoRun.inf mirrors what a U3 device would do; a U3 device has

-{ Quote: "A read-only ISO 9660 volume on an emulated CD-ROM drive with an autorun configuration to execute the U3 LaunchPad," }-To summarize: there are three ingredients in some of these digital media exploits:

1) script files

2) binary executable files

3) method of launching the files - AutoRun.inf

Using USB media exploits, which are posted in many places on the internet: Here is one.

The USB drive contains an AutoRun.inf file, a .vbs file, a .bat file, and various binary executable files and .dat files (for collecting data).

The AutoRun.inf file gets the ball rolling:

AutoRun.inf


[AutoRun]
UseAutoPlay=1
open=wscript go.vbs

The .vbs file includes this:

go.vbs


Shell.Run ".\System\SRC\go.bat
Shell.Run ".\LaunchU3.exe -a"

The go.bat file has 281 lines and does the work of collecting data. Excerpt:

go.bat


:: SET LOG PATHS
IF NOT EXIST %1\System\Logs\%computername% (
MD %1\System\Logs\%computername%

Prevention

1) AutoRun: disabling the drive prevents the AutoPlay from running. Just disabling AutoRun by the old Registry tweaks will not work - depending, of course, on what else a user may have tweaked. Most home systems would be vulnerable with systems with standard configuration. Use of Policies, or TweakUI will work.

2) Scripts: disabling wscript.exe and cmd.exe will prevent scripts from running from both local and remote locations, either by Registry tweaks or Policies, or a security program that does one or the other for you.

3) Binary executable: any White List program or Policies will block the executable in the .vbs file above from running.

These exploits depend on the user connecting a USB U3 device which has been modified by a malware writer:

-{ Quote: "The Launchpad software on a U3 device can be replaced using 3rd party tools, allowing it to Autoplay any software that is able to fit onto the device. (wikipedia article)" }- Another USB exploit on digital picture frames and pen drives uses a different type of AutoRun.inf file omitting a script. This was discussed in another thread, but bears mentioning here because it is immune to the trick of holding down the Shift key as the media is connected to the computer:


[autorun]
open=kwjkpww.exe
shell\open=Open
shell\open\Command=kwjkpww.exe
shell\open\Default=1
shell\explore=Explore
shell\explore\Command=kwjkpww.exe

Holding down the Shift Key will prevent the execution of the first line of the file, but the shell commands will be written to the Registry effectively overriding the 'Open' and 'Explore' actions on the right-click context menu, and the double-clicking of the drive icon to open the drive to view the contents. Any of those actions will launch the executable.

Preventative measures as above will block this.

Use of shell commands is documented in any AutoRun.inf tutorial. It's a useful feature for setting up specific commands on the context menu when using your external USB drive, for example: every time you connect the drive, those commands will appear on the context menu.

Like many useful Windows functions, they have been abused by malware writers.

In considering different preventative measures, one should take into account the likelihood of encountering an unknown USB device with malware installed. Do you regularly let others connect their pendrive, flashdrive, to your computer to transfer files?

A friend who teaches does, and rather than keeping everything always disabled, she uses TweakUI to disable AutoPlay on drives when she has her laptop at school. Not all students have U3 drives, of course, and those who do may not know that their drive is infected.

Another consideration: every such exploit that has been documented attempts to download a binary executable file -- easily prevented by Polices, or any number of Default-Deny White List solutions available today.

Close examination of this type of exploit leads to the conclusion that it has been overly hyped by the mainstream media -- the recent San Francisco Chronicle story being a good example. This is not to downplay the fact that many were victims of the exploit, but understanding how the exploit works, and knowing the preventative measures available, dispel the mystery and dark-sided slant given to this story. If everyone here makes just one person aware of what this exploit is and how to prevent, that is one less victim on the scoreboard.

Finally, SanDisk and Microsoft are developing a new technology which will replace U3. We'll have to see what surprises are in store when this is released:

http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3782


----
rich

[Kees1958]

-{ Quote: "What about blocking cmd.exe or wscript.exe from running those files from external media?


----
rich" }-

Rich I added Script\defender as an untrusted application in DefenseWall, always used to do this in GeSWall also, DefenseWall and GeSWall can also be set to run any file as untrusted when coming from removable sources. This pretty much covers it, I think.

[Rasheed187]

-{ Quote: "Can you explain how you do this? Is it a SRP setting?" }-

@ Rmus, I forgot that you can also do this via TweakUI, and group policies, as is already mentioned. But I´m using a tool called "1st Security Agent", it´s quite an extensive tweaking/Windows hardening tool, and no, I didn´t pay the 70 bucks, no further comment. ;D

http://www.softpedia.com/get/Security/Lockdown/1st-Security-Agent.shtml

[Cerxes]

-{ Quote: "...I added Script\defender as an untrusted application in DefenseWall..." }-
...and those using OA could check the "Run Safer" option for both cmd.exe and wscript.exe where you can add other security protections and permissions as well, in regard to the above tests.

/C.

[Dogbiscuit]

-{ Quote: "For those who don't have XP-Pro, TweakUI is easy to configure.
Note that you have to disable the drive, and not just drive type
in order to prevent the AutoPlay command from running in the AutoRun.inf file:
" }-

Using TweakUI prevents AutoPlay in an admin account when configured from an admin account (unchecked all drives under "Enable Autoplay on Drives", and both "Autoplay Drive Types").

But doing the above doesn't seem to prevent AutoPlay in any LUAs, nor is trying to configure TweakUI in the same way from an LUA even possible, since the drives are not even listed under AutoPlay.

Am I missing something?

[Cerxes]

-{ Quote: "...But doing the above doesn't seem to prevent AutoPlay in any LUAs, nor is trying to configure TweakUI in the same way from an LUA even possible, since the drives are not even listed under AutoPlay..." }-
If you follow Mrkvonic's instruction from post #21 earlier in this thread, you will disable autoplay for every drive in all your accounts.

/C.

[Rmus]

-{ Quote: "But doing the above doesn't seem to prevent AutoPlay in any LUAs, nor is trying to configure TweakUI in the same way from an LUA even possible, since the drives are not even listed under AutoPlay.

Am I missing something?" }-Since TweakUI is a User Interface for modifying the Registry, it's logical that a LUA wouldn't have access to it.

Did you try configuring TweakUI as an Administrator, then logging in as an LUA and testing to see if AutoPlay is disabled?


----
rich

[chrisretusn]

I think the easiest way to prevent this is keep autorun.inf from starting in the first place. I have autorun.inf disabled using this registry key.


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

[Dogbiscuit]

Rmus, yes I tried that.

[Rmus]

-{ Quote: "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
" }-That's a pretty brutal hack - OK if you want AutoRun.inf disabled permanently, but doesn't work as a toggle because it requires a reboot to clear.


----
rich

[Rmus]

-{ Quote: "Rmus, yes I tried that." }-And...??

[Dogbiscuit]

Using TweakUI: AutoPlay still functions under LUAs (but not under the admin account).

[chrisretusn]

-{ Quote: "That's a pretty brutal hack - OK if you want AutoRun.inf disabled permanently, but doesn't work as a toggle because it requires a reboot to clear. " }-
Brutal but effective. I can always start the CD manually like we all did before the days of autorun.inf

Helps eliminate those pesky autorun.inf viruses that sometimes show up in camera memory sticks, USB Flash drives, even cell phones.

[Pedro]

If i just do d:\test.vbs , all three (RunGuard, WormGuard and Script Sentry) warn me and block.
Since you call specifically "wscript.exe test.vbs" , it's bypassing Windows way of finding the associated program and none of them block.

I think nonetheless that these are the best. Until someone finds another one :) . Script Defender allows us to choose what extensions to intercept, but that about it.
SS gives a good summary of what it finds suspicious or not :
-{ Quote: "Warning! This file may:
-Open text files
-Execute other programs
.." }-
WG offers a more in depth description besides a similar summary as above (ranges from too general and error prone to specifics) :
-{ Quote: "Risk assessment: Uncertain
*>Potentially hostile DOS instructions found inside this file " }-
-{ Quote: "Risk Assessment: Maximum - Extremely Vulnerable Situation.

*>Contains suspicious string: infect
(...)
*>Script Analysis: Security risks detected.
WormGuard Script Analysis:
> Contains suspicious string: "infect"
> Accesses the file system." }-
RG failed to produce details, but it could derive from a- VM environment or b-they're all running at the same time :)
There is a field to produce an analysis, so it should have one.
All three allow to read the source, and until they are called, 0% CPU.
SS is more basic, WG and RG can detect embedded scripts in doc files and so on. SS has uninstall issues, so better use ZSoft Uninstaller or something.

RunGuard is still being developed. It needs, imho, to emerge from that suite as a standalone and continue to improve.
I've found RegRun to be confusing, and the first time i opened it, 4 or 5 windows popped, making it a short nightmare to understand. I believe it could be useful for someone, but only after quite some time of using it.

Of course, SSM free allows you to block all this (except scripts in docs and so on). But it's not flexible enough in case you regularly use scripts.

[EASTER]

The very first action i take after buying a SanDisk with U3 is that i remove it entirely and thus make the Pen Drive a single removable one.

I never did like that U3 crap they built into them. Too risky and time consuming at that.

[Rmus]

-{ Quote: "The very first action i take after buying a SanDisk with U3 is that i remove it entirely " }-What is your procedure?


----
rich

[EASTER]

-{ Quote: "What is your procedure?


----
rich" }-

Good question, i forgot right off hand but i think i simply used Unlocker to break the hold of the U3 then simply deleted it, leaving only the whole Pen Drive as a single removable Rmus.

I have done this twice already in the last 6 months. I hate the extra crap they used as a duo partition type set up, i wanted and only need the single removable Pen Drive to store my apps on, not all that password protection garb they added and all that.

I know it was very easy. I'll pick up another one as soon as this weather breaks here and pluck that U3 off it too.

[Rmus]

I figured you had an effecive method!

Isn't it less expensive to purchase a regular (non-U3) pen drive?


----
rich

[Mrkvonic]

Hello,

I've noticed that most drives are now sold with U3. It's a marketing thing, like pushing Vista. But the uninstaller apps, whether U3 general or Sandisk specific, work fine. Of course, you can also try using Linux to kill that hidden partition.

If you find non-U3 disk, good for you. But if not, it's 2 minutes to remove the crap.

Mrk

[Pedro]

-{ Quote: "
SS is more basic, WG and RG can detect embedded scripts in doc files and so on. " }-
It just occurred to me that DOC and XLS extensions were greyed out possibly because i didn't have Office on the VM. With Office, the options are available, and Script Sentry does block your doc embedded script Rich. It says "No problems were found" in green.
I can optionally set it to "automatically run DOC/XLS Files if no warnings are found" and similarly for files as well (vbs and so on).
It's not basic after all.

I don't know what to make of it when it needs Office though. It seems more application specific in comparison with WG/RG, i don't know if that makes a difference in terms of generic script protection.
But i like the fact that it can flag all scripts or just the ones that it finds suspicious. I'm keeping the installer :)

[Rmus]

-{ Quote: "If you find non-U3 disk, good for you. But if not, it's 2 minutes to remove the crap." }-Several weeks ago I went to a local Office Supply Store looking for one. None were found, and not only that, 2 employees I spoke with did not know what U3 was.

I was looking for one to test AutoRun exploits, but realized I could simulate a U3 device by using a CD.


----
rich

[EASTER]

-{ Quote: "I figured you had an effecive method!

Isn't it less expensive to purchase a regular (non-U3) pen drive?


----
rich" }-

That depends on your geographical area i think, but the last 2 Pen Drives i bought were from of all places K-Mart and a 1 GB was only 9.99 On-Sale and were PNY Attache brands.

Compared to U3 SanDisk, yeah i would say thats a bargain.

I'm also leery of running apps directly from them and choose instead to copy/move apps with them because the last time i run apps ON THEM regularly, that USB Pen died out a lot sooner then i expected.

[Kees1958]

-{ Quote: "This is why programs like Script Defender don't work for launching scripts using wscript.exe from external media. This is also true for WormGuard.

are

1) scripts embedded in a web page which are interpreted automatically by the browser, and not by wscript.exe.
The solution here is to block scripts with browser settings.

2) scripts that run by cmd.exe or wscript.exe automatically via Remote Code Execution from removable media such as

==> USB flash drive of the U3 type which emulate a CD and can run an AutoRun.inf file

==> other USB devices such as a digital picture frame which also uses AutoRun.inf file

Here, there are two solutions

" }-

Another solutions is to run them all untrusted wIth GeSWall and DefenseWall.

:)