![]() |
![]() ![]() |
![]() |
Winword.Concept is a remarkably friendly virus, which happily infects across platforms. Yes, that’s right, Macintosh, MS-DOS, Windows NT -- if it runs MS Word, it can be infected. Thus, people using mail interfaces which make use of the Word application can get a virus by reading electronic mail. The statement 'You cannot get a virus by reading your mail' is no longer true. You can.
Perhaps calling the techniques used by this virus a ‘new concept’ is not totally accurate. We knew this type of vulnerability in a macro language would be exploited sooner or later. Perhaps we can consider ourselves fortunate that the virus has no destructive payload: its only obvious problem is an inability, in some cases, to save work - it could be worse.
Apparently non-malicious in intent, Winword.Concept nevertheless introduces us to a new threat. In the past, we have seen fast infectors, polymorphics, stealth. This virus merely uses incredibly simple techniques to replicate and hide from the user, once a file is infected.
The appearance of this virus presents anti-virus product developers with a challenge in implementing detection, as, rather than spreading by infecting more traditional types of 'executable' code, it adds itself as a small macro to Word templates. This allows the virus to infect and spread utilising files with any extension; as long as they are in Word format.
As applications become increasingly complicated, they have begun to resemble mini-operating systems, supporting their own little file system and command set. MS Word has its own programming language, WordBasic, which, as the name implies, is reminiscent of 'real' BASIC. Although program-ming with WordBasic is not described in the Word manual, further information can be obtained by using the on-line help facilities, or by ordering the MS Word Developer's Kit.
Thus, every document has the potential to carry code which represents 'executable' instructions in the Word environment. However, this still doesn't explain how these instructions come to be run. After all, even if a document contains a set of macros, they have to be explicitly run, right?
Wrong.
In its default configuration, whenever Word opens a document, it searches for the presence of a macro named AutoOpen and executes its contents. This is carried out without asking or alerting the user, and so is usually a completely transparent process. The user is aware only that he has successfully opened another document; another triumph of the computer age!
In general, the AutoOpen macro will set up the working environment required by the document or the user. However, Word has no concept of privilege and allows the macro to make permanent changes to the way it functions. This is a powerful and useful feature, and one which is open to a great deal of misuse.
In the case of Winword.Concept, the AutoOpen macro first checks to see if the virus is already active on this computer, by searching the environment for the presence of a macro named 'PayLoad'. If this is present, execution aborts.
A second check is made for the presence of a macro named 'FileSaveAs'; if found, the virus sets an internal flag, and again aborts infection. The internal flag used by the virus to signify this is called 'TooMuchTrouble', possibly indicating that if the user already has a macro named 'FileSaveAs', it is simply too much trouble to continue and infect the system.
If these tests are passed, the virus adds four new macros to the user's 'global document template'. This is stored in a file named NORMAL.DOT, and is a general purpose template for any document.
To quote from the Word manual: 'Unless you select another template when you create a new document, Word will base the document on the Normal template.' The four new macros are AAAZAO, AAAZFS, PayLoad and FileSaveAs (the contents of the FileSaveAs macro are simply copied from the virus' macro AAAZFS).
The virus displays a dialog box upon infection, containing what appears to be an infection counter, but which displays the number '1' no matter how many infections you generate. On examination of the macro code, it is observed that this is due to sloppy programming on the virus author's part.
Once this message box is clicked on, the virus is resident, and execution of its 'bootstrap' macro finishes. Once resident, the virus code is activated whenever the user attempts to save a file using 'File/Save As', as this function has been ‘enhanced’ by the addition of a FileSaveAs macro. Whenever the user selects this option, the virus creates an AutoOpen macro in the new document, and copies the contents of the macro AAAZAO into it. The macros AAAZFS, AAAZAO and PayLoad are also created and copied into the new document.
Thus, the virus code is added to all those documents which are stored using File/Save As, and it is ready and waiting to spread when that document is sent to another unsuspecting user. There are two things worth noting: the macro called 'PayLoad' is never executed, and it contains only the following text:
Sub MAINThe name of this macro is not an empty threat: examination of the virus code and the WordBasic language shows that it would require a trivial alteration to make the PayLoad macro active and to give it a wide variety of different functions.
Checking whether a copy of Word already contains the virus is trivial. Start the program, and select the Macro option under the Tools menu, choosing Macros Available in 'All Active Templates' option.
This displays a list of macros currently installed on the computer; if AAAZAO, AAAZFS, FileSaveAs, and PayLoad are present, the machine is infected. Highlight each of the virus' macros in turn and select the Delete option. This removes the virus, but does not solve the problem of the infected files on the system.
There are other ways to detect this virus in files. One is to add user-defined virus strings to anti-virus programs which have this feature. The user can add '3A 41 41 41 5A 41 4F' and/or '3A 41 41 41 5A 46 53', scanning all files. These scan strings are the hex representation of the ASCII strings ':AAAZAO' and ':AAAZFS', and will be found in any document containing that text.
Since .DOT and .DOC files are not typically scanned, it is important to remember to add them to the list of file types to be scanned. If you suspect you have this virus, you may want to scan all files, as your users may have changed the filename extensions after saving the files.
Alternatively, you can search every document on your system for the strings (and the rest of the virus) using a disk editor. This could prove a lengthy process and is not recommended.
If you find these strings in a Word document, further checks must be made. Unfortunately, these are difficult, as the virus is composed entirely of plain text, making it difficult for someone without knowledge of Word to decide whether even a Word document which contains these text strings is the virus itself, or a message warning of the virus' presence.
One definitive way to determine whether the document is infected is to open it using Word, though this is counterproductive. My suggestion is that if you find the macros listed above active within Word, call your anti-virus software vendor, who should be able to talk you through a fix.
You can restore infected documents to their pre-infected state manually. To do this, with your infected document loaded, do the following:
Manual removal of the virus via other methods is best performed by someone experienced in Word document structure.
Automated detection and removal of the virus is offered by several vendors, including Command Software Systems ; its fix, Wvfix.zip is available free of charge from the Command/F-Prot library section of the NCSA Anti-Virus vendor forum on CompuServe, or via anonymous FTP from ftp.commandcom.com (questions/comments may be mailed to winword@commandcom.com, and will probably end up in my mailbox).
The techniques used by this virus are so simple that any idiot could use them to construct similar viruses. If history is an indicator, we can expect to see more of this type of virus.
While a short-term fix is available, the ease of creation and modification means that we must find a long-term solution to this general threat. As far as I can see, the most likely way will be to alert the user to any changes made to his global settings. While this will not prevent such a virus from spreading, it will provide users with some warning before their application is reconfigured.
Security is no longer the realm of the OS developer; application programmers should keep a careful eye on the possible misuse of the extra functionality they are providing.
![]() |
![]() ![]() |
![]() |
![]() |
Virus Bulletin: Concept / webmaster@virusbtn.com | © 1998 Virus Bulletin Ltd. |