Test Your Security For Script Blocking

Discussion in 'other security issues & news' started by Rmus, Mar 16, 2008.

Thread Status:
Not open for further replies.
  1. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    In another thread, Easter mentioned that EQS blocks scripts.

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

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

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

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

    Code:
    @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
     
    Last edited: Mar 16, 2008
  2. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    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
     
  3. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    As far as I know EQS or other such HIPS does not block scripts.
     
  4. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    What about blocking cmd.exe or wscript.exe from running those files from external media?


    ----
    rich
     
  5. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    Hi Rmus! These autoplay not working on my CDs. :mad:

    I tried this:
    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).

    2008-03-17_065625.jpg
    2008-03-17_065636.jpg
    2008-03-17_065645.jpg
    2008-03-17_065653.jpg

    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.
     
    Last edited: Mar 17, 2008
  6. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    I don,t know how can I run autoplay for vbs file.
     
  7. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    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.
     

    Attached Files:

    • b.jpg
      b.jpg
      File size:
      25.7 KB
      Views:
      1,085
  8. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    With EQS:
     

    Attached Files:

  9. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Please use the AutoRun.inf files I posted above.

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


    ----
    rich
     
    Last edited: Mar 17, 2008
  10. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    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
     
  11. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    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.
     
  12. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    vbs file with EQS n CFP, it did not run automatically. I have to click on USB memory stick icon.

    eqs.JPG
    1 (2).jpg
    1.jpg
    1 (1).jpg
     
  13. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    Did not work well.
    I allowed everyl alert in all cases to see all the alerts.
     
  14. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    OK, thanks. It looks like EQS successfully blocks wscript.exe and cmd.exe from running without permission.


    ----
    rich
     
  15. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,164
    Location:
    UK / Pakistan
    Eaxctly same with CFP.
     
  16. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    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:

    bat_reg.gif
    _____________________________________________________________

    bat_2.gif
    _____________________________________________________________

    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:


    cmd-disable.gif
    _____________________________________________________

    wscript-disable.gif
    _____________________________________________________

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

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,215
    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
     
  18. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    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
     
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    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).
     
  20. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Yes, SRP is another good option that secures against this.

    Can you explain how you do this? Is it a SRP setting?


    ----
    rich
     
  21. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,215
    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
     
  22. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    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:


    TweakDrives.gif
    ___________________________________________________



    ----
    rich
     
  23. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    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.
    vbs.png

    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 ?)
    ss-vbs-test.png
     
    Last edited: Mar 17, 2008
  24. lucas1985

    lucas1985 Retired Moderator

    Joined:
    Nov 9, 2006
    Posts:
    4,047
    Location:
    France, May 1968
    Remember that WG analyzes the content/instructions of the script. If it doesn't find any malicious code, it doesn't alert.
     
  25. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    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
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.