Malicious scripts

Discussion in 'other security issues & news' started by Osaban, Dec 1, 2007.

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

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    I have a question for the experts: How is a malicious script going to harm a computer? More specifically is it going to affect the registry, in order to be effective?

    Thanks in advance for any explanations.
     
  2. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Until some experts join in, I'll post this link which has descriptions of some old script malware:

    http://www.viruslist.com/en/virusesdescribed?chapter=153313914

    As well as stand-alone files, malicious scripts, of course, can also be embedded in web pages, and in documents that can execute scripts (MSWord, .pdf files, for example)

    They can pretty much do anything the script author wants, including writing to the Registry, especially those using .inf files.

    You may remember a few years ago the finjan.vbs demo file which showed how such a script could work, including the use of shell.run to launch an executable:
    ----
    rich
     
    Last edited by a moderator: Dec 2, 2007
  3. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    So protecting the registry isn't enough, one needs an antivirus as AntiExecutable wouldn't stop some scripts. Without an AV, a sandbox would be the only defence against any script. Sorry I'm a bit confused between executing malware in general and executing scripts.
     
  4. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    For convenience, Executable Files are divided into two categories,

    1) Those which use binary code to execute commands, with file extensions such as

    • .exe
    • .dll
    • .scr

    code-dll.gif
    ________________________________________________________________

    2) Those which use plain text (scripts) to execute commands, with file extensions such as
    • .vbs
    • .js
    • .doc
    • .pdf

    code-js.gif
    ___________________________________________________________

    Execution protection will block unauthorized Executables (binary code) in Category 1) - these would be trojans and other such malware,

    but will not block Executables (scripts) in Category 2) such as .js files.

    However, consider a script which attempts to download|install|launch a binary code executable. A good example of this was the Acer exploit, posted by TNT. You can see that it is a script (plain text) which calls out using tftp.exe to download a binary executable file. Note that z.jpg is a spoofed executable file, copying itself as .exe once downloaded:

    http://img176.imageshack.us/img176/7342/8bx8.gif

    Execution protection will stop this script from allowing the executable file to download|run. (a software firewall also would have stopped this from connecting out)

    The reason I use the above Acer example -- a script which attempts to run a binary code executable -- is that in an earlier thread this year about Process Guard, the point was made that PG does not block scripts.

    But fcukdat wrote, (https://www.wilderssecurity.com/showpost.php?p=934060&postcount=30)
    By "code needing to execute" he means binary code, which Execution Protection will block.

    About script protection in general, you wrote:

    I wouldn't depend on AV. Regarding one of the MSWord exploits, eweek noted,,

    Third MS Word Code Execution Exploit Posted
    http://www.eweek.com/article2/0,1895,2072969,00.asp

    To me, the current script blocking programs are worthless because not all-inclusive, for they block by filetype, and do not analyze the script, in the manner that Anti-Executable performs code analysis for binary code executables.

    The weakness in filetype blocking is shown by the MSWord exploits. You would have to block the .doc extension, and then you couldn't open your own Word documents. However, even blocking .doc wouldn't help. From the eweek article:

    If you are concerned about scripts running shell code that might harm your computer -- as demonstrated in the finjan.vbs test file (are there any real working examples?), then (I assume) your Sandbox solution will work.

    Consider, though: how would such a file get on to your computer?


    ----
    rich
     
    Last edited: Dec 1, 2007
  5. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Hey Rich,
    i know you work on known cases, not theoretical scenarios. But based on above discussion, a script could set an executable to start with Windows, and/or disrupt the loading of security programs in order to execute a trojan for instance. Would this be possible?

    Regarding the question of how that script would land on a computer, that's part of the kind of policies you've been explaining all along of course.
    Never the less, if you need a working example, i do talk to people on messenger, open attachments from long time friends (humorous stuff, pdf's etc.). This can look loose, but it's really not. The computer is there for this also, and there are people from whom i don't open attachments (when you start to see patterns of careless website linking which you refuse to open, questionable attachments etc.).
    I ended up, in time, to whitelist people who know how to use the computer, and doubt all others, but there's always some kind of risk (who are they emailing besides me is out of my control, and so on).

    BTW, Online Armor has a script blocker which seems to work like Wormguard (reading the description). Just thought you could want to know / test :)
     
  6. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    Thanks Rich!

    Your exposition of differences in executables is very informative. For what I could understand a script blocker wouldn't really help because currently they can't analyse scripts. I remember you saying that you were opening word documents in word pad so that anything malicious wouldn't run.
     
  7. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    You are welcome.

    In cases where a person opens documents from other people as part of normal work, that solution was an easy preventative measure, negating worry about zero-day exploits in Word.


    ----
    rich
     
  8. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hello, Pedro,

    Yes, in fact a .vbs demo did just that - it put an entry in a Run Key in the Registry which, upon startup, would launch calculator. With Sandbox or Deep Freeze or something similar, it's a No-threat, of course, since nothing written to the Registry will remain on reboot.

    Thanks for that info. Here is script that people with OA can test (it won't do anything):
    Code:
    <SCRIPT LANGUAGE="VBScript">
      function fnCreateFolder()
          dim oShell    
          dim oFolder
          dim sDir
    
          sDir = "C:\SomePath" 
          set oShell = CreateObject("Shell.Application")
          set oFolder = oShell.NameSpace(sDir)  
      end function
     </SCRIPT>
    Put this script inside a Word document and see what happens. Here is WormGuard in action when attempting to open the document. I did not add any file extensions to the block list -- it's just WG's analysis engine flagging the file:

    script.gif
    _____________________________________________________________________

    ----
    rich
     
  9. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Thank you Rich. I've posted that info on an OA thread. I can't do it, not today anyway. I'd have to boot XP, and reinstall it, then reboot, not pleasant heh.
    Surely someone will try, maybe Peter.
     
  10. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,215
    Hello,
    A script can do a lot - the most basic thing being deleting files.
    That is definitely malicious, even inadvertently.
    Mrk
     
  11. Cerxes

    Cerxes Registered Member

    Joined:
    Sep 6, 2005
    Posts:
    581
    Location:
    Northern Europe
    ...and when you go to your favorite website and have javascript enabled in your browser for that specific site, you´ll become a potential target for malware scripts that can execute in your browser...

    I look forward reading the continuation of this interesting thread.

    /C.
     
  12. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    But how to protect against these scripts? On my PC, "Windows Scripting Host" can´t process scripts automaticly. Also, "macro protection" is enabled in MS Office. Do I need to do anything else?
     
  13. kurchatovium

    kurchatovium Registered Member

    Joined:
    Nov 23, 2007
    Posts:
    89
    I often turn off Java Script thing when I goto an unknown website especially if I am using explorer. Most of the time I have been burned by viruses or malware its cause of a Javascript type payload.
     
  14. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Here is an example from earlier this year:

    http://www.urs2.net/rsj/computing/tests/js/

    Several years ago, potential for misuse of scripts was talked about a lot. A couple of friends and I decided to investigate this, since we were helping people with their setups: was this a serious threat or not?

    We were evaluating several script blocking programs. I was interested in Wormguard, and the Wormguard thread had some interesting discussions going at this time.

    Except for Wormguard, the popular script blocking programs relied on blocking by file extension, the procedure being to modify the "Open" command of the selected filetypes in the Software Key in the Registry, in effect passing the command to the blocking program, rather than the default program for that filetype.

    This protection was initiated when the user double-clicked on a script filetype, such as javascript (.js), visual basic script (.vbs), and the user was prompted with different choices.

    We eliminated these types of programs, since

    1) We felt the probability of getting a malicious script file installed and then being clicked was next to nothing.

    2) Other types of documents use scripts, such as MSWord. If you block .doc, you’ll be prompted every time you open a Word document.

    3) They did not alert to scripts that were cached by the browser.

    Wormguard used an analysis engine, which provided a clever approach: if the file contained script language, it was flagged. Pretty neat. I posted a screen shot above, showing WG in action.

    I ended up discarding it for several reasons:

    1) Legitimate documents I opened were getting flagged

    wg-dot.gif
    ______________________________________________________________

    The weakness here is that WG can’t distinguish a between a good and bad script. Legitimate macros contain the same macro language as do malicious ones.

    WG does not create a white list of all documents with scripts. Just think of the immensity of the task of finding all documents that have scripts -- scripts use plain text language. True, you can add files to an exempt folder, but WG cautions against having too many. I estimated more than 100 files I would have to exempt if running WG, including my .dot templates, .bat files, and others.

    2) WormGuard does not analyze script files that come through the browser. This is because the file has to be on the hard disk and opened before WG is set into action. This doesn’t happen, because scripts files by default are rendered by the browser.

    Now, Anti-Executable’s Copy Prevention denies an executable file from even downloading. Even if Wormguard *could* do something like that, those web pages that require scripts wouldn’t function if they couldn't cache.

    Browsers now, of course, give the user the option to control scripting on web pages.

    In all of the exploits I’ve seen that use scripts, eventually the script sets in motion the downloading of an executable file, which is easily blocked. fcukdat, who does much more in depth testing, made the same assertion, which I quoted in above post. After all, that's how money is to be made: get that trojan installed to download ad/spyware, connect to a botnet, etc.

    For us, and the people we were working with, we concluded that the present script blocking programs do not offer any security for web-based scripts, and thus of no use to us. Time will tell if Webpage-analysis programs will be reliable.

    Remember, that disabling WSH just prevents from those filetypes already on your Hard Drive from running – (How often to you run script files? How likely are you to download and click on a malicious script file?) – and has no effect on script files cached by the browser.

    I’m not familiar with MSOffice Macro Protection. Does it rely on updating signatures? How often do you open some one else’s Word documents? Some browsers by default open documents on the web directly in the browser. You can configure the browser to pass the document to a text editor, which won’t run code, or save-to-disk, where you can then open in the program of your choice.

    Not mentioned in this thread is XSS, which has been covered in depth elsewhere in the forums.


    ----
    rich
     
    Last edited: Dec 2, 2007
  15. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Inside the browser, that i know of, besides whitelisting sites with NoScript, there's LinkScanner Pro with heuristics, and perhaps Firekeeper (alpha version).
     
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    @ Rmus

    Thanks for the feedback. As you could see I was mainly talking about script files and macros, who are both not allowed to run at my PC at all, I don´t trust them, and don´t need them. About scripting on the web, that´s a different story of coure, XSS is bad news, but I´m not really worried about malicious javascript which is used in remote code execution attacks.
     
  17. herbalist

    herbalist Guest

    Scripts serve many purposes and can be written to do most anything an installed program or trojan can do. They can be placed in a wide variety of files, including web pages, text and office documents, and e-mail. Scripts can be written to perform a wide variety of tasks, including:
    Reading, writing, or deleting registry files
    Creating, copying, deleting, or moving files and folders
    Accessing your mail handler
    Executing other programs, including system components.
    Changing files and hiding file types
    Scripts can be freestanding or inserted into files with the following extensions. This is by no means a complete list, but names the more common ones:
    .vbs .vbe .js
    .jse .wsh .wsf
    .shs .shb .hta
    .reg .doc .xls

    For more info, see http://msdn2.microsoft.com/en-us/library/ms536496.aspx
    Scroll down to "The Power of Trust: HTAs and Security" for a good explanation of why they're so potentially damaging.
    For scripts executed from your hard drive, Script Sentry intercepts the script by associating itself with the common file extensions used by scripts, making itself the default application instead of WSH. It allows you to view the script in notepad before deciding if you want to allow it. If you're confortable with changing file associations, you could also set Notepad as the default app for script file extensions and move WSH to the context menu for those extensions. This way you can keep WSH functional for whenever you want to use it without it automatically running every script. Detailed instructions for changing the file associations here.

    As for relying on an AV for defense against malicious scripts, they're only effective against ones that are known. HTAs are especially hard to defend against with AVs. An HTA can contain a simple command like open "thispage.com", harmless in itself but the page could be very nasty. To make the matter worse, a malicious script can be written in a couple of minutes, much faster than any AV can respond.
    Rick
     
    Last edited by a moderator: Dec 5, 2007
  18. lucas1985

    lucas1985 Retired Moderator

    Joined:
    Nov 9, 2006
    Posts:
    4,047
    Location:
    France, May 1968
    You can easily bypass Script Sentry/Script Defender by changing the extension. Windows will run the script, no matter the extension.
    But you could argue:
    - How does a script land on my system?
    - Why I would double click it?
    - My security setup as a whole (not hiding extensions, etc) handles this.
    These arguments are correct. My point is that intercepting scripts by extensions alone isn't a solution.
     
  19. herbalist

    herbalist Guest

    Definitely not a total solution but it covers a lot of them. As for the rest of the questions, there's all kinds of possibilities, especially if the user is factored in.

    "How does a script land on my system?"
    Dropped by a webpage, contained in an installer, delivered via another Internet Explorer exploit.

    "Why I would double click it?" It could be launched by an HTA or Javascript. For a lot of users, naming the script "Nude pictures of...." would be sufficient.

    I use enough scripts that disabling WSH wouldn't be practical for me. I use SSM and Script Sentry to prevent its misuse. Script Sentry serves as a filter and whitelisting tool for the scripts. SSM prevents anything but Script Sentry from launching WSH and limits what WSH can launch. Again, not a total solution but it covers the bulk of it.
    Rick
     
  20. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Rich, i just remembered that i tried RegRun's RunGuard, and it doesn't flag your script upon opening it. I only have Word viewer and OO in the computer tested, and tried both. I don't know if there are differences regarding Word.
    The file was created in OO if memory serves me right (this could make a difference), with doc extension.

    RunGuard does have another feature, which is to scan a file. I scanned and nothing malicious was found.
    Since it isn't malicious, it isn't a bad thing. In fact, there's that possibility that RunGuard solves your problem with WG, the FP's.
    The catch is: it is a suite of utilities and watchers, not just RG. Useful no doubt, but confusing (i got lost in it). If RunGuard is effective though, one could ask for a stand alone :)
     
  21. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hi Pedro,

    Thanks for checking on that.

    Even so, the principal shortcoming I've found with all of those programs is that they don't flag web-based scripts which are automatically interpreted by the browser.


    ----
    rich
     
  22. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Aha, you want to try Firekeeper :D
    Seriously though, it's really interesting. I want to know where this tool is heading. Check out the website, install it and see. It's GPL and fully configurable. It has some rules already there, and grouped by category. Like Whitelist and blacklist (empty), default, xss rules ("Rules to detect cross site scripting attacks") .. Check it out :) (as an approach, not as a stable solution).
    fk.jpg

    That and WebCleaner. Since elio mentioned it, i kept an eye on it. It's Rambo Proxomitron.
    shot2.jpg

    But from the Site Advisor type, LinkScanner Pro seems the best. It seems stable anyway, and tested by 3rd parties. There are perhaps 1 or 2 more of interest, but most are just known good/bad site listing..
    Here's a listing with links to their home pages and reviews. Robert Vamosi seems to test lots, so we can follow one guy and draw preliminary conclusions (that besides LS and Finjan SB, they're all pretty much blacklist managers).
     
    Last edited: Feb 16, 2008
  23. lucas1985

    lucas1985 Retired Moderator

    Joined:
    Nov 9, 2006
    Posts:
    4,047
    Location:
    France, May 1968
    I'm wondering how well WebCleaner would work on an UTM appliance. It could makes wonders.
     
  24. tlu

    tlu Guest

    A good method to prevent category #1 scripts, as Rmus put it in post #4, is a combination of LUA and SRP as described here. This approach cannot prevent category #2 scripts but they cannot seriously compromise your system since you're logged in as a limited user without write permission for the c:\Windows and c:\Program Files folders and for most parts of the registry.

    Lots of XSS examples can be found here.
    BTW: It makes a difference if you use IE or another browser like Firefox or Opera. A couple of other system applications (like Help and Desktop) use IE. To make this possible Microsoft extended the abilities of Javascript by creating JScript. JScript is as powerful as VBS: via FileSystemObject it can open or delete files, start applications, communicate with other processes etc. Thus, it's obvious that a security flaw affects very often many other aspects of the OS. Javascript (as used in, e.g, Firefox) is much more limited as it doesn't have a FileSystemObject and therefore no direct access to your local files. And, of course, Firefox (or any other browser) is not used for other system applications - a security flaw consequently won't affect other functionalities of the OS.
     
    Last edited by a moderator: Feb 17, 2008
  25. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Rich, i just tryed WG with that script and it didn't flag either.

    So i created it with MS Word and sure enough now it flags it. Whether i open with Writer or Word. The file created with Writer isn't flagged with Writer or Word. The script is highlighted on the Word created file, not in Writer's. Formatting is obviously fundamentally different, perhaps the doc created in Writer really doesn't do anything?

    If i open Word/Writer, and File-Open test file, it isn't flagged.. Heh.

    RegRun RunGuard still says it's clean.
     
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.