Malicious scripts

[Osaban]

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.

[Rmus]

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:
-{ Quote: "
shell.Run "explorer.exe " &DeskPath &"\You Have Been Hacked!"
shell.Run "notepad.exe " &DeskPath &"\You Have Been Hacked!\Finjan Software Demo.txt"
" }-

----
rich

[Osaban]

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.

[Rmus]

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


195589
________________________________________________________________

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


195590
___________________________________________________________

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, (http://www.wilderssecurity.com/showpost.php?p=934060&postcount=30)
-{ Quote: "Re :Scripts/javascript I have yet to find a script that can infect a machine without code needing to execute for it to go live. If anyone knows different feel free to point me in the direction of a working example-" }-By "code needing to execute" he means binary code, which Execution Protection will block.

About script protection in general, you wrote:

-{ Quote: " Without an AV, a sandbox would be the only defence against any script." }-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

-{ Quote: " At press time, anti-virus coverage for malware that might exploit this bug is largely nonexistent." }-
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:

-{ Quote: "Do not rely on file-name extension filtering. In most cases, Windows will call Word to open a document even if the document has an unknown file extension. For example, if document.qwer contains the correct file header information, Windows will open document.qwer with Word. Filtering for common extensions such as .doc, and .dot will not detect all Word documents." }-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

[Pedro]

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

[Osaban]

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.

[Rmus]

-{ Quote: "Thanks Rich!
I remember you saying that you were opening word documents in word pad so that anything malicious wouldn't run." }-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

[Rmus]

Hello, Pedro,

-{ Quote: "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? " }-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.

-{ Quote: "BTW, Online Armor has a script blocker which seems to work like Wormguard (reading the description). Just thought you could want to know / test :)" }-Thanks for that info. Here is script that people with OA can test (it won't do anything):

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

195606
_____________________________________________________________________

----
rich

[Pedro]

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.

[Mrkvonic]

Hello,
A script can do a lot - the most basic thing being deleting files.
That is definitely malicious, even inadvertently.
Mrk

[Cerxes]

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

[Rasheed187]

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?

[kurchatovium]

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.

[Rmus]

-{ Quote: " ...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..." }-Here is an example from earlier this year:

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

-{ Quote: " But how to protect against these scripts? " }-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

195635
______________________________________________________________

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.

-{ Quote: " 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?" }-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

[Pedro]

Inside the browser, that i know of, besides whitelisting sites with NoScript, there's LinkScanner Pro with heuristics, and perhaps Firekeeper (alpha version).

[Rasheed187]

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

[herbalist]

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 (http://www.jasons-toolbox.com/programs.asp?Program=Script%20Sentry) 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 (http://www.answers.com/topic/win-file-association?cat=technology).

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

[lucas1985]

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.

[herbalist]

-{ Quote: "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." }-
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

[Pedro]

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

[Rmus]

-{ Quote: "Rich, In fact, there's that possibility that RunGuard solves your problem with WG, the FP's." }-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

[Pedro]

Aha, you want to try Firekeeper (http://firekeeper.mozdev.org/index.html) ;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).
197777

That and WebCleaner (http://webcleaner.sourceforge.net/). Since elio mentioned it, i kept an eye on it. It's Rambo Proxomitron.
-{ Quote: "The first feature that sets WebCleaner apart from other proxies is exact HTML filtering, and this removes a lot of advertisings. The filter does not just replace some strings, the proxy parses all HTML data. The parser is fast (written in C) and can cope with every broken HTML page out there; if the parser does not recognize HTML structures, it just passes the data over to the proxy until it recognizes a tag again. No valid HTML data is ever discarded or dropped.

Another feature is the JavaScript filtering: JavaScript data is executed in the integrated Spidermonkey JavaScript engine which is also used by the Mozilla browser suite. This eliminates all JavaScript obfuscation, popups, and document.write() stuff, but the other JavaScript functions still work as usual.

Exact HTML filtering has another good side-effect: it is possible to detect and prevent known security flaws in HTML processors. Several known (but not all) buffer overflow exploits or Denial of Service attacks are detected and fixed by the HtmlSecurity class.

If you find an HTML exploit that is not covered by the security filter, please let me know.

Furthermore, WebCleaner can filter SSL traffic used in https:// URLs. See the SSL gateway documentation for more info.
" }-
197773

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 (http://www.firewallguide.com/phishing.htm) 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).

[lucas1985]

I'm wondering how well WebCleaner would work on an UTM appliance. It could makes wonders.

[tlu]

-{ Quote: "@ 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. " }-
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 (http://www.mechbgon.com/srp/). 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.

-{ Quote: "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." }-Lots of XSS examples can be found here (http://sla.ckers.org/forum/list.php?2).
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.

[Pedro]

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.

[jrmhng]

Well for browser based scripts theres always noscript and FF.

For js and vbs you can just disable WSH right?

The real problem is scripts embedded into word docs and pdfs. Is there a solution to this?

[Rmus]

-{ Quote: "The real problem is scripts embedded into word docs and pdfs. Is there a solution to this?" }-It depends on what the script does. Anything is possible, but in all known attacks I've seen documented,
the payload is a malware executable, which of course is easily blocked.

This recent Adobe Reader .pdf attack:

http://isc.sans.org/diary.html?storyid=3958

-{ Quote: "A malicious PDF file served from IP address "85.17.221.2" (not active at this time) contains a malware specimen called Trojan, a variant of Zonebac." }-A write up last year of an MSWord attack:

http://www.eweek.com/article2/0,1895,1965042,00.asp

-{ Quote: "The exploit arrives as an ordinary Microsoft Word document attachment to an e-mail. However, when the document is launched by the user the vulnerability is triggered to drop a backdoor with rootkit features to mask itself from anti-virus scanners." }-Here is a nice analysis of how a payload is inserted into a Word document:

http://www.securityfocus.com/infocus/1874

-{ Quote: "3. Sample mechanism of an attack

Steps to exploitation:


Step 1: The targeted victim opens the malicious MS Word document via an email attachment or a web page.

Step 2: The malicious storage component (dropper program) within the OLE Structured Storage gets executed as the Word file is opened.

Step 3: The Trojan is dropped on the victim's system.

Step 4: The trojan operates with a backdoor which allows the remote attacker to collect system information, access the command shell and take screen shots and store them to %System%\Capture.bmp.

" }-It is very difficult to find such attacks to test, because

1) In case of a .pdf file, the attack is often directed at a particular version of the Reader, and may not work.
Also, every URL I've seen listed in an analysis has been taken down by the time it's posted.

2) In case of a Word attack, these are pretty much targeted to companies and organizations as email attacks, and no more information is forthcoming. I asked one Security Vendor for a copy of a malicious Word file they tested, and was told that it was propriatory property of the company.

Another thing to consider... these attacks require the user to click-to-open a malicious file. Ask yourself, Under what circumstances are you likely to encounter such a file, that is, what social engineering techniques would tempt you to open such a file?

If you are concerned about opening what you think is a legitimate .pdf or .doc file on a web site, or one received from a known source (the person may not know the document is infected), there are some other solutions:


1) pdf:

Alternate PDF readers are not a sure thing any more, as shown in the recent Foxit Reader vulnerability.

You can disable all but the necessary Plugins (Open and Print) in Acrobat Reader, so that no embedded code will run.

2) Word.doc:

==> using an older version of MSWord that won't run VBS code

==> open the documents in a text editor which will not run any code.



----
rich

[zopzop]

-{ Quote: "
2) Word.doc:

==> using an older version of MSWord that won't run VBS code

==> open the documents in a text editor which will not run any code.
" }-

what happens if you open the .doc (or .xls or other office document) in open office?

[Mrkvonic]

Hello,
Nothing happens.
Mrk

[MrBrian]

-{ Quote: "
The real problem is scripts embedded into word docs and pdfs. Is there a solution to this?" }-

You can disable scripting in both of these programs.

[MrBrian]

Software Restriction Policies can block standalone scripts. There are a number of extensions in my SRP Designated File Types, including .bat, .chm, .cmd, .hta, and .vb. You can add file extensions to this list.

[MrBrian]

A VBScript script embedded in a program document, such as a Word document, has the capability to create a .DLL that is then loaded into the program. Thus, you might wish to make sure your anti-executable solution can also deal with DLLs. SRP can handle this by using an Enforcement setting of 'All software files'. I have read that this may slow down your system though.

Source: http://blog.didierstevens.com/2008/06/09/quickpost-embedding-an-executable-in-a-vbscript/

[jrmhng]

Will this solution disable all malicious js and vbs scripts even in pdf and word?

Found at Microsoft Technet (http://www.microsoft.com/technet/scriptcenter/guide/sas_sbp_lhak.mspx?mfr=true)

-{ Quote: "
In more desperate circumstances, you can disable Windows Script Host; this will prevent users from running any scripts (including VBScript and JScript scripts) that rely on WSH.

To disable Windows Script Host, create one of the following two registry entries (REG_DWORD) and set the value to 0 (you need to create the entry, because it does not exist by default). To disable WSH for a particular user, create this entry:

HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled

To disable WSH for all users of a particular computer, create this entry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled

When enforced, the following message will be displayed any time a user attempts to run a WSH script:

Windows Script Host access is disabled on this machine. Contact your administrator for details.

This message box appear even if the user attempts to start the script from a batch file or using a designated script host (for example, by typing cscript.exe c:\scripts\myscript.vbs at the command prompt).

" }-

Also what are the potential side effects?

[MrBrian]

-{ Quote: "Will this solution disable all malicious js and vbs scripts even in pdf and word?
" }-

I don't believe doing this will affect pdf or office scripts, because they don't depend on WSH. If you don't wish to disable scripting in these programs, I believe that HIPS settings for Adobe Reader and the Office products could constrain what the embedded scripts can do, but I didn't personally test this.

[Pedro]

Yes. The script will instruct what the program (office/adobe) should do.

[jrmhng]

-{ Quote: "You can disable scripting in both of these programs." }-

I've found the JS options in adobe.

It is under Edit --> Preferences --> Javascript

However what about other scipts like vbs in PDFs? Is that possible?

What about in office 2007? Where are the settings?

[MrBrian]

-{ Quote: "I've found the JS options in adobe.

It is under Edit --> Preferences --> Javascript

However what about other scipts like vbs in PDFs? Is that possible?
" }-

Not that I know of.

If you get .chm files from untrusted sources, there are steps that can be taken to mitigate possible damage from opening them. Let me know if you want more details....

For Word, you can look at Tools->Macros->Security. This is for Word 2003 however.