Macro Virus Protection in the Microsoft Office Line

The Microsoft Office programs are the most well known and widely-used programs in the world. They are also the most vulnerable targets for macro virus infection. One could easily blame Microsoft for not doing anything to prevent the virus threat; however, to do so would be to overlook the efforts that the software giant has made to diminish these threats. This is the first of two articles that will review some of the macro viruses that have targeted MS Office products. This series will also analyze some of the efforts made by Microsoft to contain the macro virus situation and attempt to point out what they did right and what they did wrong. This article will look at some of the earlier Microsoft products, such as Word 2.0, Word 97, Office 97 and Office 97 Service Release 1. Word 2.0 The first Microsoft Office product that was sophisticated enough for macro virus creation was Word 2.0, which came with the first version of WordBASIC. Fortunately, virus writers did not realize this potential until the appearance of the first Word 6 macro viruses in 1995. Then a couple of Word 2 proof-of-concept viruses, Polite and WiederOffnen were written; however, by then Word 2 was going obsolete, so these viruses went mostly unnoticed. In the summer of 1995, Concept started its spread all over the world, changing the game once and for all. As Microsoft had an undisputable role in the spread of this particular virus, they soon (i.e. within a year) came up with solutions. First they issued the infamous ScanProt macro virus protection utility macros (there were at least 4 versions of them.) They shouldn't have - these utilities provided protection only against Concept, ignoring the fact that by then there were about a dozen of Word macro viruses back then. In fact, this protection macro created a dangerous false sense of security: users thought that using ScanProt would protect them from all macro viruses, while it was only effective against Concept (although, in all fairness to Microsoft, this particular virus was the most widespread back then.) Users who tried to install SCANPROT to protect themselves at the first sign of macro virus infection overlooked this fact. This action usually did not affect the virus, except that some of its macros may have been overwritten by SCANPROT's AutoOpen or AutoClose macro. The result was that some viruses, such as Colors and Muck, remained viable even with some of their macros being overwritten by SCANPROT. This mating effect resulted in dozens of new virus variants. MS Word 7.0a Realizing the serious threat that macro viruses posed, Microsoft released a patched version Word 7.0a relatively quickly (although they never cared to update Word 6.0.) This version included a macro virus warning box (shown below). The only problem is that, contrary to what the message box stated, it was not a macro virus warning box, it was not even a macro warning box; rather, it was a customization warning box. In fact, there were several problems with this implementation: The user was warned even if the opened document contained only personalized menu items or command bar buttons. The reason for this is not clear; however, the fact that the macros, command bar and menu bar customizations are stored together in the same structure within the Word document, could point out to laziness in coding and design. The warning came up even if the document contained innocent macro programs. Several companies used utility macros to improve productivity, as these macros also fired the warning, the users soon became annoyed and disabled the warning. It was possible to turn off this warning feature outside Word, by simply changing the value of a single registry key. Figure one: the Microsoft Macro Virus Warning Box MS Office 97 Except for one "leftover", the original release of Office 97 didn't provide additional protection measures against macro viruses. The "leftover" came out accidentally, when some of the virus scanners found WWINTL32.DLL, part of the standard Office 97 installation, infected with macro virus - which is clearly a nonsense. So what happened? The transition from Word 7.0 to Word 97 was a huge step as far as macro programming was concerned. The WordBASIC interpreter, used in the older version was replaced with VBA, which was already in use in Excel 5, in order to establish a unified macro development environment in all Office applications. With this development, the entire development environment, including the macro code storage mechanism and the programming language itself, changed. In order to provide some compatibility for the WordBASIC macro utilities, Word 97 introduced internal macro conversion that converted the WordBASIC code to VBA code. This was a great opportunity to prevent Word 6 viruses from upconversion. Otherwise Word itself would have just generated new virus variants. So Microsoft built in a simple filter that tried to determine whether the macro to be converted belonged to a virus or not. If the macro was found to belong to a known virus, it was removed from the upconverted document without any warning or information. Unfortunately, there were several shortcomings of this method, including: It used simple pattern matching signature scanning; It worked only on a per-macro basis. As a result, from an upconverted Concept sample the AutoOpen, AAAZAO and AAAZFS macros were removed, while the Payload macro was upconverted happily; It only provided detection for only a limited number of viruses (the static database linked into a DLL provided no possibility for further updates); and, The virus signatures were stored in unencrypted format. As a result, some scanners, which were not careful enough to search for macro signatures only in places where they could normally occur, could pick up these signatures and raise false virus alerts. Nevertheless, this was good enough to prevent the vast majority of existing Word 6 viruses to spread under Word 97. Well, almost. It turned out that at the very early beta versions this upcoversion virus check was not implemented, so a couple of popular Word 6 viruses could upconvert after all. All in all these did not make much impact. There was another change in Office 97 that, as a side effect, prevented Word 6 viruses that use execute-only (encrypted macro) from spreading. Word 6/7 provided a (very, very weak) macro-level protection in the form of execute-only macros. In Office 97, only the entire project could be protected with a password. What should happen, when someone wants to copy macros from a protected project to an unprotected project? (This is exactly the case when a virus with protected macros attempts to copy macros to the unprotected global template.) Either the protected project should be converted to unprotected, in which case VBA developers will lose protection on their copyrighted utility products, or the global template should be converted to protected, in which case users will be angry for not being able to modify their macros. The solution is very simple. It is not possible to copy macros from a protected project. Therefore, even if a Word 6 virus using execute-only macros was upconverted to a Word 97 virus, it would have a protected VBA project, and it wouldn't be able to infect further documents. MS Office 97 Service Release 1 An unheralded improvement came with Service Release 1, which indicated a major change in Microsoft's attitude. Instead of external patches and blocks, they went to the heart of the problem: the VBA object model itself. Before procedure further, let me clarify what VBA is. It consists of at least the following major components: Programming language and development environment Several automation objects and framework for processing application events Storage mechanism for VBA code It is important to state that VBA itself provides the VBIDE object model, which contains the infamous VBProject object with several methods for injecting code into macro storages. It is not implemented in the VBA licensee application; it is an intrinsic VBA feature. However, it can be optionally hidden from Automation. This is the key factor in an application's susceptibility to macro viruses. If a VBA application exposes this interface then it is an easy target for macro viruses. If hides it, then it is safe. Currently only WordPerfect chose to be on the safe side, which is reflected in the number of known WordPerfect VBA macro viruses. Others are all potentially vulnerable: MSOffice, Visio and AutoCAD 2000 have already been infected. VBA makes it easy and comfortable for applications to define application and document level events that can be handled in the macro. As these events are defined, driven by practical reasons (e.g. it is reasonable to implement an action hook when the current document is closed), most of them are implemented in each VBA licensee application although the actual names could be somewhat different. These events allow VBA viruses to activate on specific actions, e.g. when the application is closed (Application_Quit) or the document containing the VBA code is being closed (Document_BeforeClose). It is important to understand that the application object model and the VBE object model are two separate object models. The VBE object model provides several methods for manipulating VBA code. Office 97 SR-1 disabled only one of these methods, the use of the OrganizerCopy and the WORDBASIC.MacroCopy (which was the upconverted version of WordBASIC's MacroCopy) method to copy macrocode from the normal template into the active document. The opposite way was left open, so that the self-installing utility macros would still work after this security improvement. Up to that point all of the known Office 97 macro viruses used the OrganizerCopy method to spread, so this limitation effectively stopped them. These old-style viruses were able to infect the global template. They could even execute any destructive or annoying payload they had, but they could not infect further documents. Only the following error message was displayed (not showing any sign that a virus was acting). This solution was better than the previous ones for several reasons: It prevented viruses and only viruses from running. Self-installing utility macros kept working with this patch installed, while viruses were effectively stopped It was not possible to switch it off. It restricts the vulnerable VBA object model, and nothing else However, it did not stop the virus writers, who soon found alternative methods to insert virus code into VBA projects. As effective as it was, the restriction introduced in SR1 was not an ultimate solution. For some reason, it still allowed a couple other methods for manipulating VB project code, including importing text files or test strings into a module. Both tricks were soon discovered and intensively employed by virus writers in WM97.Strangedays or members of the WM97.Class family. In the Next Installment? This concludes our look at the macro viruses that affected earlier Microsoft Word and Office products. In the next installment of this series, we will examine MS Office 2000, the new version of Microsoft Office, codenamed Office XP, and Outlook. To read Macro Virus Protection in the Microsoft Office Line, Part Two, click here.