Commingling static data and executable code contributes to the prevalence of malware in modern computing environments. This problem frequently manifests itself through applications that are willing to execute scripts or programs embedded into documents. Historically, the word document referred to a file that stored only data; however many popular document formats now support the inclusion of code that the application can execute when the user opens the file. Here are just a few examples of software products that support macros—commands embedded into documents for the official purpose of enhancing the application, interacting with the user, or automating tasks:
These scriptable document types supporting macros are everywhere. Microsoft Word is, by far, the most popular of the applications that support macros. Therefore, its documents are an especially attractive target for macro viruses. A user, whether malicious or not, can embed macros in a Word document using the built-in Visual Basic Editor. This editor can be invoked by running Word and selecting Tools -> Macro -> Visual Basic Editor. To get a sense for how macro viruses infect a host document, let's examine how a specimen targeting Microsoft Word documents typically operates. A virus that attaches to a document needs to ensure that its code will be triggered by the user of the infected file. Otherwise, the virus won't run. To accomplish this task, viruses that target Word documents include subroutines with names that hold special significance to Microsoft Word. For example, if a document contains a subroutine called Document_Open(), then Microsoft Word will execute that routine as soon as the user opens the document. Another popular target is the Document_Close() subroutine, which is executed when the document is closed. In fact, these are the subroutines that the Melissa virus relied on back in 1999. When Melissa resided in a Word document, its code was located in the Document_Open() subroutine, which is automatically executed when a user opens a document. To ensure that it would stay on the machine and have a chance to infect other documents, Melissa then copied itself to the victim's Normal.dot file. This special file is processed by Word whenever the application starts up. Normal.dot contains the default template used for all newly created documents in Word, setting items like default margins and fonts. A virus embedded in Normal.dot is persistent, and remains active during each Microsoft Word session. When Melissa copied itself to Normal.dot, it saved its code as the Document_Close() routine; as a result, the virus's code was automatically inserted into every document that the victim saved during the session. There are numerous other routines that Word macro viruses can use as triggers. An abridged list includes the following candidates for infection:
A virus targeting Microsoft Excel spreadsheets works in a similar manner. To be in a position to infect new documents during a session, an Excel macro virus can copy itself into the Personal.xls file, which serves a similar purpose as the Normal.dot file in Microsoft Word. Laroux, the first virus that infected Excel documents, was discovered in 1996 and employed this technique. Laroux relied on Excel's auto_open() subroutine to automatically execute its code when the user opened the spreadsheet. Once activated, the virus invoked its own evil macro with the seemingly innocent name check_files() to proceed with the infection process. As an alternative to relying on Personal.xls, macro viruses can place an infected spreadsheet file into Excel's startup directory. By default, the path to the Excel startup directory in Office XP is C:\Program Files\Microsoft Office\Office10\XLStart, and Excel automatically loads all spreadsheets located there. The Triplicate virus (also known as Tristate), discovered in 1999, relied on this feature to ensure that its macros could infect newly opened spreadsheets. Triplicate is a particularly interesting malware specimen because it was the first macro virus to target several document types, and included the following propagation strategies:
Triplicate's code, embedded into the default templates in this way, would be automatically included in new presentations created by the victim. The virus added an invisible rectangle to the PowerPoint document that had the same size as the presentation's slides. It then created the actionhook() procedure, which PowerPoint would activate whenever the user clicked on the new shape. The virus then would be triggered when the user clicked anywhere on the slide. Imagine that: a Trojan horse shape added to a PowerPoint slide. Embedding executable code all over documents makes these kinds of attacks possible. A curious phenomenon among macro viruses is the inadvertent mutation of specimens when one virus merges with another. Consider Virus 1 that contains two subroutines: Document_Open() that is launched when the user opens the document, and Delete_Files() that is triggered when the virus executes its payload. When Virus 1 infects a document, it copies these macros to the new host file. Now consider an unrelated Virus 2 that has subroutines named Document_Open() and Mail_Files(). When a user already infected with Virus 1 opens a document that contains Virus 2, the macros present in Virus 2 will be copied to documents already infected with Virus 1. Depending on the implementation of the virus, contents of the Document_Open() macro from Virus 2 may be merged with the routine by the same name that originated from Virus 1. Therefore, the double-infected document will now contain three subroutines: Document_Open(), Delete_Files(), and Mail_Files(). It is capable of deleting as well as mailing files. The resulting offspring has characteristics of both of its parents, Virus 1 and Virus 2. This is an eerie phenomenon, reminiscent of sexual reproduction among biological species. Not all macro viruses can merge to produce a working specimen. However, those that function properly will exhibit new properties and might not even match antivirus signatures designed to detect their parents. Talk about genetic jumbling! This is one way in which computer viruses can evolve without the malware author's involvement: Specimens merge through cross-infection. Those that are detected by antivirus signatures and those that cannot replicate die off; those that exhibit superior characteristics survive and replicate. Charles Darwin's theory of natural selection has manifested itself in the computer virus world. A powerful combination of infection techniques was exhibited by the Navrhar virus that was first seen in 1997. In an unusual twist, this specimen was able to infect Microsoft Word documents as well as Windows device drivers. Documents infected with Navrhar triggered the virus via the AutoOpen() macro. This subroutine would then extract a malicious executable from the document's body that would proceed to infect device drivers. The operating system would run the infected driver after a reboot, which would load Navrhar into memory, and allow it to intercept any attempts to save Microsoft Word files [18]. Such viruses, which can infect different types of hosts (e.g., executable files, boot sectors, documents, device drivers, etc.), are called multipartite. This term reflects the malware's various parts scattered about in different areas of the machine. Think of a multipartite virus as a dandelion weed that has gone to seed. When the wind blows, little white tufts bearing seeds are spread all over the place. Some seeds land in the soil of the boot sector. Others focus on executable files. Still others look for documents. They are all parts of the same species, and each part can sprout into a weed that infects the other types. The most common targets for multipartite viruses are program files and boot sectors, but Navrhar demonstrated that the possibilities for combining virus host types are endless, subverting any type of files that include executable instructions. The popularity of macro viruses has grown significantly since they appeared in the wild around 1995. One of the reasons for this trend is the ease with which they can be written. Whereas viruses that infect executables and boot sectors are typically written using low-level machine language instructions or the C programming language, document infectors can be created via high-level scripting languages that are powerful and simple to learn. Because these scripting languages are interpreted by a program in real time, the malware author doesn't even need to compile the virus. Compounding the problem, the software required to create specimens that target Microsoft Office documents is even included with the product suite in the form of Visual Basic Editor. That's incredibly convenient for the bad guys. However, the onslaught doesn't stop there. Let's take a brief look at some other hosts for virus code.
|
|||||||||||||
Disclaimer
1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us or use the "Report this article" button on this page to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. |
|||||||||||||