Test Your Security For Script Blocking

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

 

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".

 

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

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

Code:

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

The .vbs file includes this:

go.vbs

Code:

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

Code:

:: 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:

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:

Code:

[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

 

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.

 

@ 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.

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

 

...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.

 

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?

 

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.

 

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

 

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.

[noparse]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYSoesNotExist"
[/noparse]

 

Rmus, yes I tried that.

 

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

 

And...??

 

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

 

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.

 

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 :

WG offers a more in depth description besides a similar summary as above (ranges from too general and error prone to specifics) :

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.

 

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.

 

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.

 

I figured you had an effecive method!

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


----
rich

 

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

 

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

 

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

 

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.

 

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