Malmacros

[Dave Neve]

Hi

As I'm using more and more macros taken off sites and given to me, I am
beginning to wonder about 'security'.

I've got a rough idea that if I inspect a macro before running it and I see
things like 'find and delete', then I suppose that the macro is 'dodgy'.

I'd like to know a bit more about evaluating macros and if code can be
hidden etc.

I've done an experiment with a macro on a .doc converted to htlm and it was
surprising.

In html I couldn't see the macro or any trace of it but if I clicked on
'Modify with Word, the macro was in the .doc and still working (counter
displays number of times doc is opened)

The file name in the title bar was 'name of document'.htm-Microsoft Word
(some sort of hybrid?)

Can htlm's be used to carry code which is harmful?

In brief, what should I look out for???

Dave Neve

 

[Jezebel]

The short answer is 'if in doubt, delete it'.

If you're inspecting macros, there are two types of thing to watch for: 1)
direct damage, where the macro itself does bad things, and 2) indirect,
where the macro calls something else that does bad things.

Here are some of the things to check for --

- File system commands: can be used to delete or overwrite critical files or
even format your disk
- Shell() statements: can be used to initiate other, potentially malicious,
applications
- API calls: can be used with extreme malice, eg to turn off the CPU cooling
fan
- 'as Object' declarations: can be used to call malicious functions, send
email, etc
- ActiveX controls on forms: can be used to do pretty well anything,
including Internet upload and download

If the macro is supplied as an add-in rather than simply as code, you should
also check the project references.

And of course, always test the macro on a disposable document, with the
template backed-up. In my experience, incompetence is much more common than
malice. There are instruction sequences that, under some circumstances, will
irretrievably scramble your document and its template.

 

[Charles Kenyon]

Adding to Jezebel's excellent checklist, there is not any malicious code on
the MVP site (as of the time this is written) and all code there is tested.
No malicious code would be posted there but you never know what future
vulnerabilities web sites may suffer. That doesn't mean it will work
perfectly but if it was regularly destroying documents or systems, it would
not stay there. The same is true of code on my site and that of the MVPs
(although my code is tested far less than that which appears on the MVP
site).

In some ways, it is like the question of trust and knowledge. There are
people whose code I will trust to not damage my system or documents. (I do
not include Microsoft programmers in this group even though I use Windows
and Office Update.) Others, I will look at the code on an isolated system
and analyze it. If I can't figure out what a macro is doing and its from a
non-commercial source, I won't run it. More often than not, I'm sure I lose
by taking this precaution. I've lived (barely) through system failures and
don't want to risk another to the extent I can help it.

As Jezebel said, the most likely problem is negligence rather than malice.
And the negligence may simply be running code designed on one system on
another system that is not the same, and no two systems seem to be the same
these days. If you read these newsgroups for very long you will find that a
large number of problems can be solved by turning off the Office plug-in in
Norton AntiVirus and uninstalling Addins written by Microsoft or Scansoft so
commercial software is no guarantee of good code, either.

 

[Howard Kaikow]

A benign macro can contain exactly the same types of structures/statements
as a malevolent macro.
All the items mentioned below are oft used in benign code.

There's no way distinguish between benign and malevolent code without
studying the details of the code.

Folkes worry too much about macros, the real damage gets done by executable
files as there is no way to examine their code, unless one wishes to
examine machine/assembler code from a reverse engineering effort.

Do not use any software from unknown sources.
Do not use any code without first passing it thru an auntie virus program,
but note that AV software can give false positives and can only detect known
viri.
Further protection requires learning how to understand macro code and/or
paying somebody to look at the code for you.

 

[Dave Neve]

Hi

Thanks for not one but three answers.

However, nothing on the htlm aspect.

Any chance of a few words on this cos (see my previos question please)

Regards

 

[Peter Hewett]

Hi Dave Neve

Html can carry embedded scripts (java/vbscript) it's part of what makes a lot of smart web
pages work.

A lot of java can be fairly impenetrable as it's often written to be as physically compact
as possible. This means single letter variable names, multi line statements and NO
comments!

Most of the serious Office related malware out "there" are VBA macro viruses. They are
some of the most complex and sophisticated code you'll come across. But if you do don't
expect to understand it. I believe most of the current macro viruses are self encrypting
polymorphs. Simple fingerprinting or signature detection does not work with them. If you
saw the source code you probably would not even recognise it as such.

Cheers - Peter

Hi

Thanks for not one but three answers.

However, nothing on the htlm aspect.

Any chance of a few words on this cos (see my previos question please)

Regards

HTH + Cheers - Peter

 

[Jezebel]

I think there may be a confusion of terminology here. There's no way you can
write a 'self-encrypting polymorph' in VBA.

 

[Peter Hewett]

Hi Jezebel

I'll refer you to an authority rather than answer that myself. But self encryption is an
integral part of the polymorphic or metamorphic behavior of a virus.

Quote: <The virus code is processed line-by-line, with the encryption key being generated
only once for a line. Different lines use different encryption keys.>

If you're interested check out:

Polymorphic Macro Viruses, Part One
http://www.securityfocus.com/infocus/1635

Polymorphic Macro Viruses, Part Two
http://www.securityfocus.com/infocus/1638

Cheers -Peter

I think there may be a confusion of terminology here. There's no way you can
write a 'self-encrypting polymorph' in VBA.

HTH + Cheers - Peter