David Harley, Robert Slade, Urs Gattiker
McGraw-Hill Companies
ISBN 0-0721-3090-3
September 2001
Download PDF (49.94Mb) (You need to be registered on forum)
Osborne/McGraw-HillMcGraw-Hill/Osborne
A division of McGrawHill companies
Copyright © 2001 by The McGraw-Hill Companies, Inc. All rights reserved. Manufactured in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps.
McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212) 9044069.
TERMS OF USE
This is a copyrighted work and The McGraw-Hill Companies, Inc. ("McGraw-Hill") and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill's prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms.
THE WORK IS PROVIDED "AS IS". McGRAW-HlLL AND IT'S LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise.
DOI: 10.1036/0072228180
It has been said, in regard to computer network communities, that no community is worthy of the name until it has had a wedding and a funeral. We, in the computer virus research tribe, have had both. We will not embarrass the newlyweds here. We wish, however, to dedicate this book to the memory of Ysrael Radai and Harold Joseph Highland. Their contributions to our field, and to so many others, are appreciated, and they will be sorely missed.
To the Meeter Machine, and its viral output.
- Robert Slade
To my daughter Katie, my constant reminder that computer security should not be confused with real life. Now, perhaps, we'll have time to play Monopoly. Also to my mother, Gwendoline Harley, for being an honorary parent to Katie when I had to find time for Baby Book.
- David Harley
Dedicated to my friends Inger Marie, Melanie, Lars, Rainer, Stefano, and all my current and past students who continue in keeping me going when obstacles seem insurmountable.
- Urs Gattiker
David and Rob asked me to write a foreword to this new book. I've corresponded with both over the years, and their work with viruses has been of great value to many of us. After browsing a draft of their comprehensive effort, I am pleased at the amount of useful information they present in such an accessible manner (although, as an academic, I wish they provided more specific references to their sources - something to look forward to in the second edition). In fact, their book is so comprehensive, I wondered what I could address that they had not already covered. However, as I thought more about it, I realized that they haven't completely addressed what is yet to come. To understand the future, it helps to consider the past as context. Thus, I will reflect some on the past and how it relates to the present. After that, I challenge you to read this book with thoughts of what the present portends for the future - and how your awareness and action may have an effect. As George Santayana wrote, "Those who forget the past are condemned to fulfill it". (Yes, that is the correct quote. Many people cite it incorrectly.)
Twelve years ago, I coauthored the first general, English-language technical reference on computer viruses ("Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats," by E. H. Spafford, K. A. Heaphy, and D. J. Ferbrache, ADAPSO (now ITAA), 1989). At that time, there were fewer than 100 viruses in general circulation - about 75 for DOS/Windows, 20 for the Apple Macintosh, and a few dozen for other platforms, including the Amiga. This had grown from the first virus in the wild, the Elk Cloner virus for Apple II computers in 1982, through a half-dozen new viruses for the Intel-based platform in 1986-1988, to the IBM Christmas Tree EXEC worm/virus, and then to the Morris Internet and WANK worms.
As of mid-2001, there are thousands of computer viruses - perhaps as many as 75,000. Some vendors claim to receive reports of as many as 20 new viruses a week. In fact, with the ease of creating macro viruses for popular email and word processing software, the rate at which new viruses are being reported appears to be increasing. Throw the various worms, Trojan horses, backdoors, and other malware into the mix, and the numbers grow even larger.
If you do a little analysis of the historical data, you can project the trends of the past two decades forward with some statistical tools. Within a few short years, we will be seeing a new worm or virus released more frequently than once every hour. How is anyone going to keep up with that rate of attack? What defences can we possibly employ? And how much of our processing power will we need to employ to gain reasonable protection?
It really didn't have to be like this.
Fred Cohen wrote extensively about computer viruses in the 1980s, but only a few people seemed to pay attention. The late Harold Highland focused attention on viruses in his editorials in Computers & Security, along with publishing articles on viruses. The book I coauthored, along with other references of the time, warned about good computer hygiene and the potential for future problems. At many conferences and workshops, we discussed the future of computer viruses and malware. In 1990 and 1991, both Harold and I made presentations at the NYC DPMA Virus conferences (the premier virus research meetings of the time) on macro viruses, and their potential - long before the emergence of the Concept virus.
However, several of the major software vendors failed to send anyone to those meetings, nor did they appear to read any of the security publications. The vendors told researchers that viruses weren't their concern, because only a few of their customers had problems with them at the time.
One major company in particular was notably absent from the scene, and the results are painfully obvious today. For instance, that company designed features into its software that helped viruses spread more easily, despite warnings to the contrary. That same software company labelled the first major macro virus a "prank", and apparently never tried to find or discipline the employee who wrote it. Can you guess which company that might be? Here's a hint: more than 99 percent of all known computer viruses and worms run solely on its products, out of proportion to its actual share of the market. Here's another hint: the Melissa and LoveBug incidents affecting its software and causing billions of dollars of damage were almost identical in overall nature to the extensively documented Christmas Tree EXEC incident in 1987. Today's problems should surprise only those who forgot the past - or never bothered to learn it.
Unfortunately, the dominant software architecture that runs our national defences, underlies our public utilities, powers our government agencies, and supports our banks, medical establishments, and educational organizations is also from this same company. Our whole computing infrastructure is highly vulnerable to malware as a result. And in addition to being susceptible to computer viruses, those products seem to be subject to a never-ending stream of critical security patches, many as a result of sloppy coding (for example, buffer overflows) that have been known for decades to present security problems. We are now operating in a world where a 12-year-old with a web browser and a text editor can run self-duplicating software to execute network attack scripts - software that can disrupt a government agency or multinational corporation. If some attack software isn't on a WWW site this week, then all an attacker needs to do is wait a few weeks for a few more vulnerabilities and attacks to be discovered and posted.
Remember the Aztecs? They ruled a mighty empire until exposure to a few hundred Spaniards with smallpox and measles incapacitated or killed 90 percent of their population and left them too weak to resist conquest. With no immunity, they were easy pickings for a vastly smaller (and weaker) force. Do you think we might have something to learn from the past?
Of course, the fault is not solely that of the software vendors. Consumers are not demanding better quality, are not making informed choices, and are not holding vendors accountable for shoddy goods. Thus, vendors are providing what the consumers seem to want to buy without complaint, and it is hard to fault them (completely) for that. Many computer users today accept computer viruses, crashes, and security flaws as a standard part of their everyday computing existence. They don't understand other alternatives, or they think the cost of switching to something else will be too high. However, before long, the cost of anti-virus and security software, recovery efforts, incident response, and Help Desks will overwhelm the cost of the systems to which they are so attached. Then what?
We also have a real problem with effective deterrence by way of penalizing the authors of malware. Since 1980,1 am aware of fewer than 10 people who have been charged and convicted in a criminal court for writing malware. I am aware of only two civil suits for damages. Given the attitudes expressed by authors of viruses (see Chapter 15), what is being done to deter them? Without some credible threat of exposure and penalty, it seems unlikely we will reduce the population of virus writers. In fact, as more computers come online, the tools become more accessible, and the attitude continues that viruses are a part of "business as usual", we should expect the number of authors to increase, perhaps even faster than it already has.
So, we have an environment that is very susceptible to viruses, vendors to whom security has historically seemed to be a secondary concern (if it has been a concern at all), consumers who accept the pitiful status quo as normal, and perpetrators who have no credible fear of reprisal. Is it any wonder that the anti-virus vendors are profiting... and are necessary?
Despite all that has happened, I do not believe that the future needs to be like the past. Each of us can make a difference. We can start by modifying our own behavior:
Armies that stuck with cavalry because of their investment in saddles, stables, and training received a rude awakening in the first half of the 20th century, when the tank and machine gun were widely deployed. Having a platform immune to common security threats is a competitive advantage in any arena, even if it costs more and requires some additional training to employ.
So, as you read through all the history and advice compiled in this book by these accomplished researchers, keep your eyes and mind open for hints on how to design your own protection and shape the future. Resolve to make a new future as one who remembers the past, and actually learns from the experiences of others.
Safe computing, all.
- spaf
July 2001
Eugene H. Spafford is a professor of computer sciences at Purdue University, a professor of philosophy, and is director of the Center for Education Research Information Assurance and Security (CERIAS). CERIAS is a campuswide multidisciplinary centre, with a broadly focused mission to explore issues related to protecting information and information resources. Spaf has written extensively about information security, software engineering, and professional ethics.
Spafford is a fellow of the Association for Computing Machinery (ACM), fellow of the American Association for the Advancement of Science (AAAS), fellow of the Institute of Electrical and Electronics Engineers (IEEE), and is a charter recipient of the Computer Society's Golden Core Award. In 2000, he was named as a CISSP, honoris causa. Among his many activities, he is co-chair of the ACM's US Public Policy Committee, a member of the board of directors of the Computing Research Association, and a member of the US Air Force Scientific Advisory Board. He was the year 2000 recipient of the National Institute of Standards and Technology/National Center for Standards and Certification (MST/NCSC) National Computer Systems Security Award, generally regarded as the field's most significant honour in information security research. In 2001, he was named as one of the recipients of the Charles B. Murphy Awards, Purdue University's highest award for outstanding undergraduate teaching. In 2001, he was elected to the Information Systems Security Association (ISSA) Hall of Fame, and he was awarded the William Hugh Murray medal of the National Colloquium for Information Systems Security Education (NCISSE) for his contributions to research and education in infosec.
Rob Slade is a data communications and security specialist from North Vancouver, British Columbia, Canada.
His research into computer viral programs began when they first appeared as a major problem "in the wild". Acting initially as the unofficial archivist for the budding research community, he has since become known for "Mr. Slade's lists". One of the working group for the VIRUS-L FAQ, he has produced a series of review and tutorial articles that have been published as Robert Slade's Guide to Computer Viruses. He is the founder of the DECUS Canada Security SIG. He still considers data security to be a minor sideline, and was astounded to hear himself referred to recently as a "leader" in the security community.
Rob is more widely known for his series of technical book reviews. If you would rather not have to scour USENET looking for them, you can now place yourself on a mailing list to receive new ones either by sending any message to techbooks-subscribe@egroups.com or by visiting the eGroups web site at www.egroups.com/list/techbooks/, which also has an archive of recent postings. Full archives of the book reviews are kindly hosted by both Victoria Telecommunity Net at http://victoria.tc.ca/techrev/mnbk.htm and the Computer Underground Digest at Northern Illinois University (http://sun.soci.niu.edu/~rslade/mnbk.htm). The reviews form the basis of a column in TeleManagement (www.angustel.ca/teleman/tm.html).
At present, he takes every available opportunity to teach operating systems to his grandchildren. He is married to the world's best executive secretary, which is probably the only reason he actually got the book finished. His next book will be a computer security glossary. It is next to impossible to get him to take "bio" writing seriously.
Rob Slade can be reached as rslade@sprint.ca or rslade@vcn.bc.ca.
David Harley has a work history more chequered than most chessboards, embracing music, nursing, various aspects of the building trade, computing, and administration. He worked from 1989 to 2001 at the Imperial Cancer Research Fund in London, originally as an administrator and programmer, then as a network engineer and support analyst, latterly as a security specialist. He now works for the United Kingdom's NHS Information Authority as Support Services Manager, where he still specializes in security, but is now allowed to express himself more pompously.
He is an active member of EICAR (the European Institute for Computer Anti-Virus Research) and a charter member of AVIEN (the Anti-Virus Information Exchange Network), where he is participating in projects concerned with certification of anti-virus personnel and virus analysis, not to mention the Disciplinary Committee, which is much less exciting than it sounds.
His other affiliations include the WildList Organization and ICSA Labs, where he is working on Apple Macintosh-related security projects. He has something of a reputation as an expert in the Mac arena, largely because no one else actually cares about Macs except those who don't own an Umbrella. He maintains a number of security-focused web sites (when time allows), including Mac Virus II.
His previous security-related writing includes several Internet FAQs, a curious assortment of conference papers, magazine articles, chapters on viruses and Trojan horses for the third edition of Maximum Security, and a chapter on security and healthcare for the fourth edition of the Computer Security Handbook (with Paul Brusil).
His hobbies include parenting, flippancy, blues guitar, not getting to the opera, and spending money he doesn't have on software he doesn't have time to use. His ambitions include getting a life and returning to some nontechnical writing.
David Harley can be reached as macvirus@dircon.co.uk.
Urs Gattiker is Obel Family Foundation Professor of Innovation and Technology Management at the University of Aalborg. His previous positions include Stanford Center for Organization Research, the Melbourne Business School, the University of Lethbridge, the University of the German Federal Armed Forces at Hamburg, and the Aarhus School of Business. He is a member of the supervisory board of KonNet GmbH (Germany), and a member of Bankinvest's Advisory Board for its BI Technology A/S' IT Venture Fund (http://www.BankInvest.dk). He also is a board member of various organizations, including B2B Agro Scandinavia A/S, Naventi A/S, Vigilante Inc. (USA), and Vupti A/S.
His books include Technology Management and Organizations (Sage, 1990), and The Internet as a Diverse Community: Cultural, Organizational and Political Issues (Lawrence Erlbaum, 2001); he is currently writing Electronic Patient Records, Internet and Data Security with Inger Marie Giversen and Christine Orshesky (Lawrence Erlbaum). He has recently edited a book with Laurie Larwood, Impact Analysis: How Research Can Enter Application and Make a Difference (Lawrence Erlbaum, 1999) and is currently writing on a book about entrepreneurship and start-ups.
Gattiker served as Chair for the Technology & Innovation and Research Method divisions of the U.S. Academy of Management (the leading association for academics and consultants in management in the United States). He is one of the founders and was an executive member of the Canadian Association for the Management of Technology (CANMOT), now the Innovation Management Association of Canada (IMAC) and the Technology Management Division of the Administrative Sciences Association of Canada (ASAC). Gattiker also chairs the Task Force for Trust and e-Commerce of the European Institute for Computer Anti-Virus Research (EICAR) and is a member of EICAR's Scientific Advisory Board as well as the EICAR Board.
He is currently spearheading the efforts of a virtual research organization on e-commerce, new media, and technology policy. Research and white papers can be found at http://Papers.WebUrb.net.
Urs Gattiker can be reached as WebUrs@WebUrb.net.
Christine M. Orshesky, with more than ten years of information security experience, has supported information security efforts, including malware protection and incident response at various government and corporate organizations. Her most notable responsibility included managing malware response initiatives for the Department of Defense at the Pentagon. After her experiences there, Orshesky founded i-secure Corporation to provide vendor-neutral malware-protection strategies and education. She has participated in numerous information security and other industry conferences, and maintains her professional certifications in information security and quality assurance.
We owe too much to too many people to list them all. In particular, we must mention our families, for their patience and support through a long and demanding project.
We acknowledge the work of many people at Virus Bulletin, AVIEN, EICAR, ICSA Labs, the WildList Organization, the Universities of Hamburg, Tampere, and Magdeburg, and the anti-virus (AV) companies. Thank you for your expertise, for your help, and just for holding the line. We can't possibly list everyone who deserves a mention, but any such list would have to include a number of people who may not have contributed directly to this book, but without whose hard work and generosity in sharing information, our work would have been even harder. We list just a few here, and in no particular order: Alan Solomon, Paul Ducklin, Vesselin Bontchev, Jimmy Kuo, Sarah Gordon, Robert Vibert, Henri Delger, Joe Wells, Larry Bridwell, Bruce Burrell, Shane Coursen, Nick FitzGerald, and Graham Cluley. We also thank Rob Rosenberger and George Smith, for not letting anyone get away with anything; those virus writers and former virus writers who felt it was worth maintaining a dialogue and discussing the issues; and the volunteers of VIRUS-L, alt.comp.virus, alt.comp .antivirus, security-focus, and elsewhere, who continue to provide help and advice because so many people seem to need it. We don't always agree with them, but their public-spiritedness makes a real difference.
A book is almost always a team effort. This one is no exception - fortunately, given the difficulties that arose during the production stage. Many people deserve credit: Urs, for kicking the project off in the first place; David, for attempting to keep the thing in some sort of order; Rob, for holding it together when family illness and a drastic change of career and location nearly knocked David off the project altogether; Christine, whose contributions went far beyond technical review; Spaf, for saying what needed to be said (as always); the long-suffering production team at Osborne, for their never-ending struggle to keep an overstretched and sometimes irascible team of authors focused; and Gloria, for copyediting services beyond the call of marital duty.
We intend to make available high-quality and broadly useful information about malicious software (malware) in general, viruses in particular, and about anti-virus/anti-malware technology and its application in the real world and in the context of general security. We also want to ensure that we cover the most contemporary trends in regard to viruses and malware, which have diverged significantly in recent years from traditional forms. Finally, while we are particularly addressing systems administrators and IT managers, we want to make sure that this material is available for any computer user, and not just those who have made a special study of the field.
Perhaps even more urgently, we mean to counter the extremely poor information that bedevils the security field in general and the virus field in particular. To this end, we include not only analysis of threats and countermeasures, but also information on sources of further information with some indication as to our assessment of their reliability.
We also hope to be the first authors ever to make a million out of a book on computer viruses, but we're not counting on it.
This book isn't quite like the majority of works on security. Many security volumes are good sources of information on other areas of security, yet inaccurate on virus specifics.
General security books are also often inclined to a full-disclosure mode, which isn't altogether appropriate for a virus book. Not that we necessarily advocate the paternalist, "Gods and Ants" mindset that characterizes some sectors of the anti-virus industry, who usually lean towards the nondisclosure end of the continuum. We hope that you will, as far as possible, test what we tell you and make up your own mind. But the greatest disclosure problem in virus literature concerns actual virus code.
The indiscriminate inclusion of virus code (existing or new) in previous books and elsewhere has, in our opinion, been of more use to the aspiring virus writer than to the hard-pressed systems administrator. As Gene Spafford has famously said, showing people how to pour sugar into the gas tank doesn't teach them much about auto mechanics. You have to know a bit about how viruses operate in order to protect against them, but the finer details of virus coding are completely irrelevant. So we won't publish virus code (let alone original virus code).
Roll-your-own viruses are generally the opposite of helpful, except in very carefully controlled circumstances. We can't say that no bona fide researcher ever modified or created a virus to test a concept (though some highly capable individuals will not do so under any circumstances, and some companies flatly forbid it). However, publishing viable virus code is not where we want to go.
Dissecting individual viruses doesn't give you the means of defending against all viruses. You can't implement countermeasures to their maximum effect without knowing more than a little about the attacks. However, most readers will rely heavily on commercial solutions, although we hope you won't put this book down convinced that anti-virus is always enough. We consider it generally more useful to concentrate on the details of evaluation and implementation of solutions than the minutiae of a few of the tens of thousands of viruses and variants. Where we do focus on particular viruses, we will be more concerned with their significance in terms of social impact and the defensive measures they necessitate than with the fine detail of their code.
However, we will tell you more than enough about virus mechanisms to understand what the threat is, and, more importantly, how commercial anti-virus software protects against it. Furthermore, unlike most vendor manuals and web sites, we'll tell you about some cracks that anti-virus software can't paste over. Virus authors are already exploiting these, directly or indirectly, and you'll need to know about them too if you're to maximize your own security.
Roll-your-own anti-virus software is a pretty limited option: systems administrators and home users may be able to block certain classes of threat, but can't compete with the professionals at detecting and disinfecting the tens of thousands of distinct known viruses. We are aware of attempts to sell books on the premise that "If you read this, you can write your own anti-virus software, and the security vendors will be lining up to give you a job". This premise is based on the mother of all fallacies. You can fill in some of the gaps left by commercial anti-virus products. You can sometimes bypass the need for commercial products by avoiding vulnerable operating systems, applications and utilities, or configurations. You can (at a price) use generic defences, such as change detection software, rather than distribute definitions updates as new viruses are discovered. What you can't do is compete with the industry on its own terms on detecting known viruses. The chances are you don't have the time or access to every new virus.
Isn't virus management a security issue? Of course it is, and it's best implemented within the context of a holistic security strategy, when it's done right by people who know viruses as well as or better than they do other areas of security. Unfortunately, people who are competent in some areas of security sometimes overestimate their own competence in other areas, and viruses seem to attract a particularly virulent brand of ultracrepidarianism ("acting or speaking outside one's ability or knowledge"). (A tip of the hat here to Rob Rosenberger, whose article on "False Authority Syndrome" first introduced at least one of us to the word; you can find the article at www.vmyths.com/fas/fasl.cfm.) Of course, this principle also works the other way. For instance, only the bravest, most nervous, or least experienced systems administrator is likely to let an anti-virus vendor write his or her firewall policy, however good the product may be.
This book also differs a little from other virus books. After all, aren't there enough virus books already? Well, there are good virus books, and there are recent virus books, and at the time of starting this project, these are disjoint sets. Unfortunately, the most accurate books aren't usually current, so that they miss out on some of the issues that have come to concern us all since. Meanwhile, most of the current books aren't accurate. One or two exceptions are noted in the book, but not here, since we want to keep you focused on buying this one...
Neither do we think that we've included everything you'll ever need to know, but this book is as up-to-date, accurate, and comprehensive as we can make it, and that in itself makes it somewhat unique. Just to make sure we don't have to eat those words, we include at the end of Chapter 19 information on hot issues that started to warm up as we were completing the last few chapters. Mind your fingers.
This book is also somewhat different as regards its target audience. There is a notable absence of books in this area that are aimed specifically at the information technology (IT) professional with a "need to know" about virus management. This group might include systems and network administrators, security analysts and specialist anti-virus engineers, other support engineers, power users, management, the computing press, and even students of computer science. We aim to redress that deficit. However, this book makes few assumptions about levels of technical knowledge (though it rather assumes that you use computers). Home computer users or non-specialists within corporate organizations will also be able to follow this book and benefit according to their needs. Education is a vital component in the fight against virus infestations. We expect that technical managers should be able to hand this book (marked as to appropriate chapters) to the ordinary office worker or executive, and raise his or her awareness of specific topics.
The book isn't intended for anti-virus professionals within the industry: full-time, competent researchers, virus analysts, and such will not need us to fill them in on the technical detail of their own jobs. On the other hand, much time spent in conversation with anti-virus sales staff and marketroids has convinced us that knowledge of one product is no substitute for knowledge of product-nonspecific virus/anti-virus technology. Often, these people aren't even aware that they're selling you what they have, not what you need, and that their sales pitches are based on fallacies as much as facts. (Q: What's the difference between a computer salesperson and a used-car salesperson? A: A car salesperson can usually drive, and knows when he or she is lying to you.) Furthermore, we can think of some high-powered anti-virus researchers who have yet to learn that knowledge of that technology is only part of virus management. If we can't rely on the vendor information providers to get it right, we can at least hope that you'll be better equipped to evaluate their expertise once you've read this book.
The clarion calls "Trust me: I'm a vendor" or "Trust me: I'm a consultant", or even "Trust me: I'm an Instant Expert" make no more sense than "Trust me: I'm a virus writer". We don't want you to trust anyone (even us) because of who that person claims to be, or what he or she claims to know. Too many people are already willing to relieve you of all responsibility for your virus problems. We aim to empower you to make at least one decision about virus management yourself. If that decision is to hire others to deal with the problem, at least make that decision on the basis of your own knowledge, not on wishful thinking (yours or theirs).
Clearly, this isn't a book for virus writers, either. We've already explained our reluctance to demonstrate or reproduce certain types of code, so the book will be of little use to the kind of virus writer who makes trivial modifications to existing code to make his or her own variant. Yes, we know that lots of legitimate and useful code is based on other people's code. In our experience, though:
Perhaps a virus writer will catch a passing idea from something mentioned here and develop it into something startlingly novel, and possibly malevolent. This is one of the risks taken by all writers in the security field. We can take a stand on not publishing what is useful only to the bad guys, but most technical information is value-free. If it's useful to you, it might be useful to your enemy too. We take each case on its own merits.
Sometimes, anti-virus researchers play off-duty games (usually at security conferences), such as testing each other's help lines or swapping nightmare scenarios. In general, we intend to keep our nightmares to ourselves unless there is something you can do about them right now.
The book is divided into five main parts, as described in the following sections.
Malware takes many forms, and we'll deal with nearly all of them. However, single instances of malware are not necessarily or even usually dealt with individually. Although we will sometimes suggest a specific approach to a specific type of problem, usually we explore general classes of malware, then (in Part II) the general classes of anti-malware technology that can be used to deal with them.
We intend this book to be useful to a wide range of computer users, including (indeed, especially) the highly computer-literate. However, experience indicates that it's unsafe to assume that expertise in one field of computer use, including security (or systems administration and security), necessarily indicates expertise in anti-virus issues. We therefore start with some baseline definitions, just to ensure that we all understand approximately the same thing when we talk of key concepts like Trojan horses, viruses, worms, damage, and infection. If you are familiar with older books and other resources on the subject, not all this material will be new to you. However, Part I does reflect recent trends in the way we think about older threats, which may be of interest in its own right. We will of course focus on current threats and classes of threat. These are likely to be of particular interest given that they have appeared since the first wave of classic texts, and are therefore not covered there, while recent books have generally demonstrated a poor grasp of the technology and its implications. A detailed analysis of classes and subclasses of malware follows in later chapters, while malware meriting individual attention is examined in detail in Part III.
Part II considers anti-virus and anti-malware technology in detail, then goes on to discuss their real-world application within the enterprise.
In Part III we provide a detailed look at some specific virus/malware incidents - what makes them noteworthy, and what lessons can we learn from them.
Part IV looks at social issues. We believe that viruses are a social problem, and social problems cannot be solved by purely technological means. Sadly, it will take more than this book to solve the social problems of which computer vandalism is a small component. Certainly, though, the virus management professional cannot afford to ignore the human dimension, whether it concerns the vandals themselves or their victims. Part IV also contains the summary of summaries and the "stop press" chapter.
The final part includes a detailed glossary and some extra material donated by the authors and others.
There is a fair amount of reading in this book, and some suggestions for hands-on work on systems protection. The book won't turn you into a top-flight anti-virus expert, but if that's your ambition, reading the book straight through will certainly give you a reasonable grounding and links to enough further information to keep you going for years. You may be accustomed to books like this coming with a CD full of free software and documentation. This doesn't work very well with anti-virus software, since by the time the book hits the bookshelves, many programs will already be out of date. Our experience suggests that making anti-virus software available for evaluation can actually become counterproductive as it gets increasingly past the software's sell-by date. Furthermore, while there is some freeware and shareware that we have no hesitation in recommending, it's probably better to give you pointers to current versions and information. We can do this better from a dynamic information source - that is, the web site - than we can from a CD, which may go out of date between the date of press and the publication of the book. We specifically mention free software in Chapter 8, and on web pages at the following sites:
You can also check for updated web links at these sites:
We hope these sites will keep you safe enough to read the rest of the book.
IN THIS CHAPTER:
You might call this the executive summary of the whole book, or the two-minute guide to viruses and related problems. This chapter may not tell you anything you do not already know, but bear with us. The computer security field is over-populated by "instant experts" who "know everything" about security in general and viruses in particular, without actually having done the research. We therefore prefer to level the playing field a little with some basic definitions to ensure that you are not "infected" with some of the misconceptions perpetuated by some sectors of the press and other undependable resources.
NOTE
This may sound anti-journalist. In fact, we all know responsible, capable journalists. We even know computer journalists wbo could reasonably be described as virus experts (and we turn in the occasional article ourselves). However, a journalist without specific expertise in a particular area is bigbly reliant upon the quality of information received from others, and some bave been very unfortunate in their choice of expert informants on anti-virus issues. In this way, misinformation from individuals who should have known better has become widely distributed.
This chapter does not go into full details of virus and other mechanisms, but is restricted to broad principles. Malicious software (malware) is an area where there are very few indisputable definitions, and misconceptions are rife, so we prefer to start with a few simple baseline definitions. We will proceed to the heavy-duty jargon and hair-splitting later.
Some examples in Chapter 2 will give you an idea of how viruses can work, and more details are given on actual viral operations in Chapters 3, 4, and 5. Part III includes detailed case studies.
We already have said, and will in the future say, unkind things about other virus "experts", the media, various software companies, other virus book authors, and a few other people as well. Are we a bunch of arrogant twits who think we alone have the secret knowledge? Not at all. (Well, we would say that, wouldn't we?) We know dozens of legitimate virus experts, some of whom have quite literally forgotten more about specific technical fields than we will ever know.
The problem is that the computer virus field has generated an enormous amount of misinformation and myth. In fact, one entire subject of research is that of the "virus hoax", which we'll discuss in more detail later in the book. Frankly, we aren't completely certain why legends and lies have become so prevalent in the discussion of viruses. (We' 11 give you some more thoughts on that later.) The plain fact is that the vast majority of articles in the general media and even computer trade media (better than 97 percent according to one of our collections) contain significant and substantial fallacies. We are not talking about trivial errors such as the wrong date for the discovery of a virus or a slight mistake in the wording of a message. We are talking about the central thesis of essays that are not only flatly wrong, but that recommend to computer users that they take steps more detrimental to computer operation than the viruses themselves.
Some people who buy this book may be real virus experts. (And to our colleagues, we say hello again, and be kind in your reviews, OK?) Some of you may sincerely regard yourselves as experts in this field, having worked hard to gain knowledge and experience. In such a case, you might take offence at some of what we say and at being put in the same box as those instant experts whose expertise is based on misapprehension and guesswork. To those of you who are feeling offended at this point, we hope that you will keep an open mind and stay with us. Bear in mind that we have, between us, somewhere near 30 years of full-time research. That's not just X years since we first saw a virus. That's full-time, serious study, often in addition to our regular jobs. As we say, we have met, along the way and in that time, dozens of virus experts. However, we have also met thousands of "instant experts" with just enough experience behind them to illustrate the truth of the saying that a little knowledge is a dangerous thing.
Even between us, we don't know everything about viruses. We are going to be as careful as we can, but there are going to be some errors in this book. (We hope they are small enough not to cause you trouble.) Yet, we're willing to bet that you've been told some unbelievable things about viruses - we certainly have. Please be patient while we challenge some of those common and misplaced assumptions.
A major problem with viruses, as we shall try to make clear in this and the next chapter, lies in the fact they are not automatically identifiable. Viruses, or any kind of self-reproducing programs, only use functions that are used by other programs and that are necessary for other operations. Admittedly, the use of certain functions can suggest viral (self-replicating) activity. Indeed, detecting such functionality is one of the ways in which some anti-virus software attempts to detect new, hitherto unknown viruses.
However, the fact that this comes under the umbrella term "heuristic analysis" indicates a basic problem. Heuristic means a "rule of thumb", or proof by trial and error. Heuristic analysis is in part a scoring system. We define criteria, then we note that the suspect program meets or exceeds a threshold score, suggesting that it is viral. What those criteria are, and how a scanner establishes conformity or non-conformity with those criteria, will be explored in due course. However, it has been demonstrated that it is impossible to write a program that can analyse a file and state with 100 percent certainty that it is or isn't viral. (This demonstration actually bears closer examination, but we'll save that for Chapter 4.)
Furthermore, there is no absolute test for malice, making it effectively impossible to detect hitherto unknown non-viral malicious software (such as Trojan horses) automatically. We can't say that a given program is malicious just by analysing the code, even if we can say it replicates, and we can sometimes only confirm replication by testing.
By malware, we mean (primarily) viruses, worms, and Trojan horses, and those are the main types considered in this chapter. However, other subclasses will also be considered in Chapters 3, 4, and 5.
By virus, we mean a program meeting the much-used definition included by Dr. Frederick Cohen in A Short Course on Computer Viruses: "...a program that can 'infect' other programs by modifying them to include a, possibly evolved, copy of itself".
By infect, we mean that a virus inserts itself into the chain of command, so that attempting to execute a legitimate program results in the execution of the virus as well as (or instead of) the program.
We do not define every program that destroys or steals data as a virus. A virus need not have any sort of payload (malicious or otherwise). That is, it doesn't have to do anything explicitly or deliberately damaging; it doesn't even have to operate covertly (though most of them do); all it has to do is replicate. We will not, therefore, call programs that cause damage "viruses" if they don't replicate. We might call them Trojan horses, but that's a discussion for later. We will not assume that a virus causes any intentional damage (though it can be argued that all viruses do some collateral damage).
We are assuming here a common tripartite model of virus structure; that is, we assume up to three main component mechanisms:
As previously indicated, only the presence of the infection mechanism is mandatory if the program is to be defined as viral: payload and trigger are optional. Be aware, though, that this is a somewhat simplified model: in some circumstances the dissemination of the viral program itself may be described as the payload. Some worms (and we'll get to defining worms shortly) have been described in this way. Furthermore, if the virus is at all selective about the circumstances under which it will attempt to infect, the infection mechanism may also be said to incorporate a trigger.
By virus damage, we mean, primarily, one or more of the following:
Attempts to conceal the presence of the virus (or other malware) may also entail a measure of intentional or accidental damage as the environment is manipulated or reconfigured. Examples include the following:
However, the physical manifestations of a virus are often trivial. Viruses certainly exist that inflict savage, intentional damage on the victim system, and they are in some cases widely distributed. However, many exemplify the maxim that by not killing its host, a parasite tends to enhance its own chances of long-term survival. The most damaging aspects of viruses, in general, are social rather than technical. Social damage includes such phenomena as:
Hold that thought: we'll have much more to say on social implications in Part IV.
We are particularly anxious to avoid the common confusion between infection and damage. Virus incidents are often reported in terms of damage, where infection would be a more appropriate term. We would also prefer to distinguish between the presence of a virus on a system and an actual infection. A computer user may have dozens of infected attachments sitting within his or her mail Inbox. However, as long as none of the infected programs are actually run (that is, the infective code is not executed), the system is not said to be infected. Infective objects in this state of dormancy are sometimes described as latent viruses.
Use of the term latency in this context may invite confusion, since it is sometimes used in networking (especially in the context of firewalls) to indicate delay rather than inactivity. In the networking context, the usage probably derives from the use of the term "latency period" in neurology to refer to the delay between the moment a nerve impulse reaches a muscle fibre and the moment that fibre starts to contract. In fact, the notion of latency as entailing delay has its uses in discussion of virus issues, so dormancy may be a better term.
A special case of dormancy occurs when a virus is found on a system on which it cannot be executed. For example, a PC-specific program infected by a PC-specific file virus cannot normally be executed on a UNIX server or a Macintosh, but may nevertheless be found in an FTP directory or as a mail attachment. The risk here is that such a virus might later be passed on to a system on which the viral code could be executed, even though the replicative code is not executed at this stage of its dissemination. This mechanism is sometimes referred to as heterogeneous virus transmission, though it closely parallels the mechanism that drives the dissemination of other malware.
NOTE
A number of papers and presentations by Peter Radatti bave alluded to tbis phenomenon, including the 1992 paper "Heterogeneous computer viruses in a networked UNIX environment" (Proceedings of the First International Virus Prevention Conference and Exhibition (NCSA), Washington, DC).
Viruses that use concealment mechanisms are often described as stealth viruses. This term has become so popularly debased as to include virtually any virus that neither asks permission to infect nor announces its presence by a characteristic message, graphic, sound effect, and so on. Stealth methods and classification are discussed in Chapter 3.
Despite the tendency of the media and instant experts to scream "Arggghhh!!! It's a stealth virus!", stealth and stealth classification are, while technically interesting, of little consequence to the everyday user of anti-virus software. Once a virus has been analysed by an anti-virus vendor's researchers, circumvention of any novel stealth techniques it uses is incorporated into the process of adding recognition of that virus to a scanner's capabilities. Nonetheless, the tricks used by viruses to conceal their presence can have implications for their victims that disinfection by an anti-virus program may not address. Viruses and worms may introduce changes into the environment, such as modification of Word menus or the Windows Registry, that anti-virus software cannot (or in some instances chooses not to) reverse as part of the disinfection process.
Another word that inspires panic in the press is polymorphism, a concept poorly understood by instant experts and generally overestimated in its long-term impact on the malware problem in general. A polymorphic ("many shaped") virus attempts to make detection of its presence more difficult by changing its "shape" from one infection to another. (The mechanisms for achieving such shape-shifting will be considered later.) This is often mistaken (not only by the press, but by writers of low-grade books on security and/or viruses) as meaning that the virus becomes a different virus or virus variant at each infection. This is not the case. A polymorphic remains the same virus but cannot be detected by looking for a characteristic scan string within the possibly infected file (or other infectable object). The code remains essentially the same, but the expression is different, so that the same program is represented by a different sequence of bytes.
This by no means indicates, however, that polymorphic viruses are undetectable, though the first examples contributed to the disappearance of a number of early anti-virus products published by vendors who couldn't handle the problem. It does mean, of course, that the anti-virus programmer has to think beyond grep-like scanning of infectable objects using pattern matching with regular expressions.
NOTE
grep, egrep, and fgrep ore a group of UNIX took used to search text files for lines that match regular expressions, as defined in the next section of this chapter. Similar (and similarly named) tools have heen created to run under DOS, Windows, and other operating systems. The scripting language awk (also found as nawk and gawkj and editing tools such as sed and vi also support regular expressions. Jhe perl language combines the functionality (and in some cases the syntax) of these and other tools, and is available for many platforms. We should make it clear that these tools do not all use the same sets of regular expressions, still less in exactly the same way.
No, although UNIX has its issues with viruses too, whatever the Linux zealots may say, and we'll consider those too, in the fullness of time. Indeed, we've already discussed one of them: the question of heterogeneous virus transmission. However, the UNIX shell programmer's obsession with regular expression parsing can also help us to understand how scanner technology works on platforms other than UNIX.
Simple scanning for fixed strings (sequences of text or binary characters) is Stone-Age technology, and no competent modern virus scanner relies exclusively on it. UNIX-like regular expressions involve applying search or filtering criteria that mix normal characters with special metacharacters to find not only fixed strings, but also relevant variations, thus allowing a far more flexible approach to pattern matching. Tools like grep, awk, and perl allow you to search for a character by string using criteria such as:
^.fruitcake[^0-9]\.$
This expression would be Really Useful for searching a text file for lines consisting of
The metacharacters used here include "^" (beginning of line), "." (any single character), "[^0-9]" (any character not included in the set of characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9), "" (treat the next character as a literal period character, not a metacharacter denoting any character), and "$" (end of line). Thus, either of the following lines will match:
%fruitcake&. XfruitcakeX.
The following lines will not match:
%fruitcake&. Plus any other text whatsoever.
(No line break after the period character.)
%FRUITCAKE&.
(Literal string "FRUITCAKE" is not the same as the string "fruitcake".)
Xfruitcake7.
(Character following literal string is numeric.)
Finding a set of circumstances under which looking for this particular expression would ever be useful (let alone in the context of virus detection) is left as an exercise for the reader. Furthermore, grepping a text file for a string isn't exactly the same as scanning a binary file for a search string. In fact, looking for a text string (even where the virus author is considerate enough to provide one) inside a (possibly) infected binary file is, more often than not, neither efficient nor dependable. However, it may not surprise you that we can find uses for tools like grep in virus management to fill in some of the corners that commercial anti-virus products don't quite reach, such as the management of log files.
By worm, we mean a self-replicating program that may or may not be a virus. We'll discuss the finer distinctions later. For the moment, we'll use the following rough-and-ready definition: a program that usually spreads across networks and doesn't attach itself parasitically to another program. (However, it can be said to "infect" an operating system, a mail application, or a network, if you really want to make your life complicated.) Be aware, though, that many anti-virus researchers regard worms as a special case of virus, not a completely different class of malware. In fact, we'd go so far as to say that an insistence on maintaining an artificial and unspecified distinction between the two species often suggests the sort of instant expert whose (selfl-perceived authority exceeds his or her actual knowledge. Furthermore, many of the current malicious programs described popularly as worms may be more properly regarded as viruses or as worm/virus hybrids: Melissa or MTX, for example. (Both Melissa and MTX are considered at length in Part III.) Certainly, most experts consider the Internet Worm of 1988 and today's email worms to be beasts of quite a different colour, both in concept and in execution.
When we refer to a Trojan horse (or a Trojan, for short), we mean something that probably isn't a virus, or a worm, because it doesn't self-replicate. That is, it can only move from system to system if someone is persuaded to move it deliberately, since it doesn't include a programmed infection routine. However, worms are sometimes described by vendors as Trojans, and some people regard viruses as a special case of Trojan. Both these arguments are defensible, but such usage confuses the issue somewhat. Certainly, if we ever use a term like "Trojan horse virus" in this book, we'll probably be quoting a hoax rather than using it in all seriousness. If not, you'll be entitled to ask for your money back (though you probably won't get it).
Trojan horses are often defined as "programs that claim to do something useful or desirable, and may do so, but also perform actions that the victim wouldn't expect or want". These actions may include payloads such as password stealing or out-and-out destruction.
However, this presumption of malice is not common to all researchers. Some use the term "accidental Trojan" to describe programs that include an undesirable effect the programmer did not intend to include. Such a problem may be differentiated from other software bugs by their severity, such as a situation that results in the destruction of data, for example. A particularly notorious (and apt) illustration of this idea is documented in Vesselin Bontchev's "Vircing" the InVircible, a highly critical analysis of InVircible, a generic anti-virus product. Bontchev reported that running some of the tools in this product suite during testing resulted in the deletion of a legitimate data file with the filename SOFIA. This problem appears to have arisen because of the undocumented use of a temporary file of the same name by InVircible. The effect caused Dr. Bontchev to classify it "as a Trojan Horse destroying data" without going so far as to accuse the program's author of deliberate malice.
NOTE
InVircible is a product that stands somewhat outside the mainstream of anti-virus technology. Its author, Zvi Netiv, has a forceful personality and an aggressive approach to marketing that has resulted in fierce controversy. Jhe war between Mr. Netiv and the rest of the industry is interesting, hut a little beyond the scope of this chapter. In later chapters we will consider in more depth the ideological and technical differences between generic and virus-specific approaches to virus management. We will, however, avoid dwelling on the flame wars and personality clashes associated with specific products.
How many viruses are there? Well, it depends on what and how you measure, of course. This may be a good point at which to note that many of the objects detected by anti-virus software are not actually viruses at all. We'll come back to what else they may be in the next chapter.
Of those objects that really are bona fide viruses, most will never be seen on your desktop or anywhere else within your organization, unless someone goes out of his or her way to collect them. At the time of writing, anti-virus vendors are claiming to detect between 50,000 and 60,000 PC viruses. This is a somewhat spurious claim, incidentally, but we'll take that particular diversion further down the line. However, the WildList Organization's report for July 2001 lists 698, including the Supplemental List as well as the WildList proper, which lists only 214. Who is correct?
NOTE
The WildList Organization is a volunteer group consisting of a number of anti-virus researchers who are well-placed and well-qualified to contribute information concerning viruses currently seen in the field. We will look more closely at this organization in Chapter 8.
Actually, neither total is (nor can be) strictly correct, but the WildList is a much better guide than vendor marketing as to which viruses seriously threaten your organization. The vendor's packaging massively overstates the problem (in a sense) by claiming detection of all the viruses that are known to exist (and some variants and non-viruses that shouldn't be quoted, from a purist point of view). The WildList and Supplemental List include viruses that have been reported by businesses and other computer users as spreading on their systems, and that have been verified by the highly qualified anti-virus professionals who report to the WildList Organization. By definition, these lists understate the problem, because there are always viruses that are "out there" in the field but that haven't made the list yet. However, the difference between the viruses that constitute the WildList and those that are out there but not included in the WildList is usually assumed to be measurable in hundreds rather than in tens of thousands. This does not mean that the vendors are purposely misleading you, by the way (at least, not always). It simply means that the problem is too complex to be served well in the context of this introduction. If you want to know more right now, you'll have to skip ahead to Chapter 3 (on virus epidemiology in general) and Chapter 8 (on information gathering and risk assessment).
So let's go back to the question we asked at the beginning of this section. How many viruses are there? Answer: tens of thousands, by almost anyone's reckoning. How many should you be concerned about? All of them, since you can't tell whether one of them might get lucky and escape into "the wild". However, it makes sense to worry more about those that are known to be in the field now, especially those conspicuous enough to have made the WildList. What do we mean by in the wild! To quote Paul Ducklin (of Sophos, the UK anti-virus company), we mean viruses that are "spreading as a result of normal day-to-day operations on and between the computers of unsuspecting users". (Seethe WildList Organization's FAQ (Frequently Asked Questions) document at http://www.wildlist.org/faq.htm). Viruses found only in collections, e-zines, or VX (Virus eXchange) web sites are not considered to be in the wild. Such viruses are sometimes described as "zoo viruses" or even "in the zoo".
The terms "in the wild", "In the Wild", and "ItW" lead to a certain amount of confusion, and we should try to clarify our usage of these terms:
Finally, here's a brief summary of what anti-virus programs are and how they work. We're keeping the details in reserve for Part II, but a cursory scan of almost any anti-virus software comparative review indicates that we can't assume that you already have a realistic broad understanding of anti-virus technology. We don't mean you personally, of course, but the guy next to you reading over your shoulder. (Especially if he happens to be a journalist.)
There are two main streams of anti-virus thinking: virus-specific and generic. By virus-specific, we mean what is sometimes referred to as Known Virus Scanning (KVS). This means that every time a new virus or variant is discovered, it is analysed and a suitable identifying pattern is extracted. Virus-specific scanners are then (if necessary) modified so that they will detect and identify that specific virus or variant using that pattern. Generic scanners detect viruses (hopefully), but don't identify them (at least, not exactly). Whereas a virus-specific scanner says "Object X is infected with the Y virus", a generic scanner says "Object X is (or may be) infected with an unidentified virus". Clearly, it's easier for a virus-specific scanner to disinfect, where disinfection is possible. A generic scanner is more likely to suggest that you discard or replace the (possibly) infected object X, or else that you check it with a virus-specific scanner.
However, some (most, these days) virus-specific scanners can also use a generic technique called heuristic analysis to detect new (unknown) viruses. Simplistically, they look for indications of virus infection in object X by seeing what the code actually does. This is closely allied to behaviour monitoring and behaviour blocking. The differences and resemblances between these techniques are beyond the scope of this introductory chapter, but we'll have lots to say on the subject later.
NOTE
There is an important distinction here between disinfection and detection. Some products don't disinfect all classes of viruses, and commercial virus-specific scanners can't usually disinfect all the viruses they detect - some types of infection are not repairable. Jhe word disinfection implies that the virus code has been removed from the infected object. However, this does not necessarily indicate that the object has been returned to its pre-infection state. Nor does it mean that the object will necessarily function as it did before it was infected, although it will in many cases. It does not mean that the environment in which the infected object exists is restored to its former state, either, nor that all the damage caused by the infection or the payload is reversed.
Scanners are broadly divided into two main types: on-access (real-time) scanners, and on-demand scanners. Real-time scanners are memory-resident: they check infectable objects (files, diskettes, system areas) as they are accessed. On-demand scanners may also check one or more files, disks or other media, or whole systems, but they aren't memory-resident. Either the user calls them as needed (when you want to verify that a CD you just received is virus-free, for instance), or else they're called by scheduling software at predetermined times. They may also be called by the operating system at fixed times, by an entry in AUTOEXEC.BAT, for instance.
We know of many people in management positions (including security managers) who would know a great deal more than they do now if they were to read this chapter. However, we've probably said enough to indicate that the virus-management problem is far too complex to allow the anti-virus professional to hope that clicking on the Anti-Virus icon will solve all his or her problems. Certainly, if you have the deep joy to be a systems administrator or security professional, we have a lot more to share with you. In Chapter 2, we take a look at some historical background.
IN THIS CHAPTER:
A major problem in providing a history of viruses lies in knowing where to start. Some people have insisted that they were writing viral programs as far back as 1956. Since computers then had very little similarity to computers now, and since the methods of use were so different, these claims have to be taken with a very large grain of salt. There are some operations that could have been considered viral, such as the opcode in early machines that simply copied itself into the next memory location. (This was used to overwrite the entire memory space, leaving it in a known state.) However, only by the most strained definition of "virus" can these functions be seen as similar to modern viruses.
NOTE
An opcode in assembly language is the part of an instruction or directive that identifies the specific operation to he performed. (An instruction is a statement to he translated into machine language; a directive is a statement that gives directions to the assembler.)
On the other hand, as we shall also see, computer viruses have changed radically in the 15 years that they have been widely known. Certain patterns do, though, tend to recur.
Much of this chapter will concentrate on the MS-DOS and Windows platforms. Viruses have been written for just about every major, full-blown computer operating system (with the possible exception of CP/M). However, as you will see, the basic viral ideas remain the same. In addition, the prevalence of viruses has little to do with questions of operating system design or even security. Viruses are, in general, most frequent in those operating systems that are most widely used. The Wintel platform (Windows running on a PC driven by an Intel processor or equivalent) has the dubious honour of having the greatest number of viral examples.
With this history, we intend to give you a very basic overview of fundamental virus concepts. Although the technology is changing constantly, the underlying ideas never change very much at all. The story starts before viruses were known, or even contemplated, at least under that name.
While there is no proof that true viruses existed in the early days of computing, it is important to note certain programs and activities that did. These exercises and studies probably did not presage the development of viruses themselves, but they did influence opinions and later examinations.
As computer technology advanced, it became possible to run more than one program at a time on a single machine. In even the most rudimentary multitasking environment, it was important that each program be contained within certain bounds, known as partitions. Programs would perform inappropriate operations on the data, or on other programs belonging to different procedures, or would transfer control to random areas and try to execute data as program instructions.
NOTE
Because the design of most computers is based on what is known as von Neumann architecture, there is no inherent difference between data and programs. Thus, there is no way to tell the difference between a scrap of data and a section of program without trying either to run it or to make sense of it.
Programs that encroach upon another program's personal space in this way tend to generate random operations and damage. (Even now, we can see all the Windows support engineers out there nodding and muttering "protection fault" and wincing.) Attempts to trace the "path" of damage or operation would show random patterns of memory locations. Plotting these on a printout map of the memory made irregular curving traces, which began and ended suddenly. Since these looked like holes in worm-eaten wood, the model became known as a "wormhole" pattern, and the rogue programs were sometimes known as "worms".
Nowadays, the term worm is often used for viral programs that spread by some method other than attachment to, or association with, other program files. However, this use of the word probably derives from the Shoch and Hupp experiment that resulted in the Xerox worm, which we discuss later in this chapter. Rogue programs that created wormhole damage were haphazard mistakes, and very little like today's premeditated viral programs, except that they wreaked havoc where they shouldn't have.
Programmers being the individuals they are, the development of such rogue programs became a subject of contests, specifically the game of "Core Wars". In this game, program is run to set up an environment like the core memory of older computers. A standard set of computer opcodes, known as Redstone Code (because the simulator version was developed at the Redstone missile development or testing facility of the US military) or just Redcode, is used to build programs that which then do battle with each other within the simulated environment. The program's objective is survival, rather than reproduction and spread. However, virus researchers have an interest in the use of such tactics as attack, avoidance, and replication, as well as the trade-off between complexity of design and chance of destruction.
For example, a very simple, but effective, Core Wars program is one referred to as an Imp. An Imp simply tries to run through the memory, overwriting locations as it goes. Since it is very small, an Imp is hard to find and kill. Larger programs may have more sophisticated means of detecting other programs, or of defending against attacks, but, because of their size, are more likely to have part of the program destroyed by an Imp. In the same way, small and simple viruses have sometimes been more successful at surviving and reproducing than more complicated programs.
Core Wars is most widely known due to a series of articles done by A. K. Dewdney in his "Computer Recreations" column in Scientific American. The first of these articles was printed in the March 1984 issue. Images of these articles can be found at http://www.koth.org/info/sciam/. More details on Core Wars can be found at these sites:
We have given one possible derivation of the term "worm". There is another, and this is the one that is more likely the source of the current definition of the word in the field of computer virology. It is interesting that two completely separate routes should give rise to the same term and that the meanings should complement so well. It is also interesting, given the ongoing debate as to whether viruses can ever be useful, that this story arises from an early attempt to use viral programming for beneficial purposes.
NOTE
Vesselin Bontchev has written a useful paper on the non-usefulness of "good" viruses. You can find it at a number of sites:
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/goodvirjip
http://www. virusbtn. com/OtherPapers/GoodVir/
Fred Cohen, to whom we'll introduce you shortly, has taken an opposite view in books such as A Short Course on Computer Viruses.
John Shoch and Jon Hupp were researchers at Xerox PARC in Palo Alto, California, where one of the earliest examples of a local area network (LAN) had been set up. They were interested in the concept of distributed processing, the ability of computers to work cooperatively on single or related tasks. Specifically, they were testing an experimental program whose function was to check other computers on the network to see if they were active.
If a computer were idle after normal working hours, for example, the program would submit a copy of itself to the idle machine. In this way, the original program would spawn multiple copies of itself to idle machines in order to make use of the CPU time, which would otherwise go to waste. This system was a precursor of systems that have now become very popular on the Internet and have already made significant contributions in fields such as encryption and decryption. A problem can be broken down into small chunks, and if each sub-problem can be addressed and resolved on one of the machines on a network, this is functionally equivalent to running a single, large program. However, the actual processing is done by small program segments working on individual machines, rather than by sharing a single processor. Since biological worms are defined by the fact that they have segmented bodies, Shoch and Hupp called this new type of program a "worm". In many references, you will also find mention of John Brurmer's novel, Shockwave Rider. This book refers to a "tapeworm" program that could be said to have some resemblance to the cumulative computing effort.
Alas, the experiment, at that time, was not an altogether unqualified success. One night, a programming error was made. This glitch caused the computers running the worm program to hang, and since the program had been sent to many computers over the course of the night, the researchers arrived in the morning to find an institution full of dead computers. This program became known as the Xerox worm or, in many references, the "infamous Xerox worm". Shoch and Hupp detailed their experiences in a paper published in the March 1982 issue of the Communications of the ACM ("The Worm Programs - Early Experience with a Distributed Computation").
As noted, the Shoch and Hupp worm program did reproduce by submitting itself to other computers, but it was written as part of research in the field of distributed computing. The program had no malicious or security-breaking intent. Nor did it attempt to hide its presence or operation. On the other hand, as we pointed out in Chapter 1, neither malicious intent, nor covert operation, constitute defining characteristics of a virus (or worm).
NOTE
Some abstract notes are available at bttp://ftp.unina.it/pub/docs/rfc/ien/ien159.txt. A German account is available at http://www.cert.dfn.de/tutorial/wuermer/kap211.html, and can be roughly translated by AltaVista's Babelfisb (bttp://world.altavista.com/).
The earliest case of a virus, as we know them to today, that actually succeeded in the wild, goes back to late 1981. In fairness, this activity does not appear to have been noted by many until long after the fact. Those who have followed Apple's "Think different" advertising campaign may not be surprised that an earlier generation of Apple hardware "gave birth" to this novel concept.
We have reports of two very similar programs with almost identical features and histories. Here, for the sake of simplicity, we will discuss the first one that was related on the Internet. The other instance was startlingly similar, even to the state in which it took place.
The idea was sparked by a speculation regarding "evolution" and "natural selection" in pirated copies of games at Texas A&M: the "reproduction" of preferred games and the "extinction" of poor ones. This led to considerations of programs that reproduced on their own, and the term "computer virus" was apparently used in the context of that idea. There is no obvious reason to doubt the author's contention that there was no malice involved. At the time, it was one originator's belief that a virus had to be relatively "benign" in order to survive. Indeed, there is some truth in that assertion, though it can't be described as an absolute. Viruses with no destructive payload do tend to survive better over the long haul.
Apple II computer diskettes of that time, when formatted in the normal way, always contained the disk operating system.
The programmer attempted to find the minimum change that would make a viral version of the operating system, and then tried to find an "optimal" viral DOS. A group came up with the first version of such a virus in early 1982, but didn't let it spread because of side-effects. The second version was allowed to "spread" to a limited extent through the disks of group members.
Eventually, the virus escaped into the general Apple user population. It was only then observed that the additional code length caused some programs, and one computer game in particular, to crash. A third version was written, and the developers made strenuous efforts to avoid the memory problems. This version was subsequently found to have spread into disk populations previously considered to be uninfected, but no adverse reactions were ever reported.
This virus seems to have been written around 1983. It became well known in the Apple community, probably because of the message (in doggerel verse) that it presented. It also created nuisances in the computer, such as displaying the wrong file type, inverting the video, and clicking the speaker. The virus worked only under AppleDOS 3.3; any other disks, such as those based on HackerDos, DiversiDos, and ProDOS, tended to be rendered unusable. The author is known, and his claims to have intended no real harm appear credible. All damage generated by the virus seems due to simple carelessness.
By way of an epilogue, in 1989 a virus appeared for the then-current Apple IIGS and ProDOS. Apple users were used to rebooting in order to change operating systems or boot special disks. Load Runner trapped the reset command (holding down the CONTROL key plus the COMMAND (Apple) key plus the RESET key) and, when it was issued, wrote itself to the diskette in the drive, thus surviving a reset.
Fred Cohen first presented his ideas to a graduate class in information security in 1983, and history credits his seminar advisor, Len Adleman, with the assignment of the term 'Virus" to Cohen's concept. Of course, this isn't Adleman's only claim to fame. The RSA encryption algorithm derives its name from those of its inventors: Rivest, Shamir, and Adleman. Cohen did extensive theoretical research, and he also set up and performed numerous practical experiments regarding viral-type programs. Cohen's first virus paper was published in 1984, and his dissertation was presented in 1986 as part of the requirements for a doctorate in electrical engineering from the University of Southern California. This work is foundational, and any serious student of viral programs disregards it at his or her own risk. Cohen's maj or contributions lie in the foundations of basic theory and analysis in virus research, and the development of the defensive techniques that have historically been most effective and are now the most widely implemented. His work experimentally demonstrated and theoretically resolved vital issues. He outlined every basic antiviral concept that is now in use; despite what vendors may tell you, nobody has ever found any other way to deal with viruses.
Dr. Cohen's definition of a computer virus as "a program that can 'infect' other programs by modifying them to include a, possibly evolved, copy of itself is generally accepted as a standard. Indeed, we couldn't get through Chapter 1 without quoting it. Occasionally, it is unclear as to whether it can include, say, boot-sector viral programs, or entities such as the uiternet/UMX/Morris Worm. It is not, however, fair to Dr. Cohen to hold him responsible for the misuse of his work by others. The definition given above was an attempt, in the 1984 paper, to express a mathematical concept in English. The English version is only an approximation.
Fred Cohen's work was never given the credit or value it deserved. From the very beginning, systems administrators and the security community have seen his work as either negative or as an academic curiosity. In addition, viruses have advanced the plot of many a book or movie, and Cohen has never received a royally check from Hollywood. Viruses even save the world on occasion, but no one phones Fred to thank him. This situation is decidedly odd, but it may have been aggravated by the perception of Cohen as a bit of a grouch. Fred's friends, however, argue against the negative characterization, noting that he has a very keen sense of humour. This last is amply demonstrated in A Short Course on Computer Viruses, a book that goes a long way towards bridging the gap between the practicalities of virus and anti-virus technology, and their theoretical, mathematical basis.
This overview is the merest introduction to his work. Indeed, computer virology plays little part in his more recent writing. The most important aspects of his early work are the demonstration of the universality of risk and the limitations of protection. His practical work proved the technical feasibility of a viral attack in any computing environment more complex and interactive than a pocket calculator. (This feat was achieved within a closed environment and could not, by its nature, have predicted the social and psychological factors that have contributed to the pandemic spread of viral programs in the wild.) Equally important, his theoretical study proved that the "universal" and purely automatic detection of a virus is impractical. Although monitoring and analytical programs have a place in the antiviral pantheon, this fact means that they, and all other antiviral software, can never give 100 percent guaranteed protection.
You can find out more about Dr. Cohen and his more recent work in other areas of security at http://www.all.net/.
1986 was not only the year in which Fred Cohen presented his dissertation, it was also the year in which Ralf Burger demonstrated VIRDEM, a .COM infector. Over the next few years, many more .COM and .EXE infectors would be written than boot-sector infectors, but parasitic file viruses were comparatively unsuccessful at spreading in the wild (with some very notable exceptions, including Jerusalem, discussed later in this chapter). This trend has changed course in recent years, however, with the advance of the email worm/virus juggernaut.
The Brain virus is probably the earliest PC virus, and at one time, it was the most widespread of PC viral programs. Extensive study has been done on the Brain family. In spite of this, and in spite of the existence of address and phone number information for the supposed author, we still have only second-hand reports of the production of the virus. Consequently, little can be said with absolute certainty about its origins.
Brain is a boot-sector infector (BSI), somewhat longer than some more recent BSIs. Brain occupies three sectors itself, and, as is usual with BSIs, repositions the normal boot sector in order to mimic the boot process. As the boot sector is only a single sector, Brain, in infecting a disk, reserves two additional sectors on the disk for the remainder of itself, plus a third for the original boot sector. This is done by occupying unused space on the diskette and then marking those sectors as "bad" so that they will not be used and overwritten. The "original" Brain virus is relatively harmless. It does not infect hard disks or disks with formats other than 360K. (Other variants are less careful and can overlay FAT and data areas.)
The Brain family is prolific, although less so than Jerusalem, for instance.
NOTE
Seemingly, any successful virus spawns a plague of copies if virus-writer wannabes use it as a template. This has become more so as macro viruses and other script viruses bave made virus coding easier. Jbe code requires less programming knowledge and no specialized development tools. In addition, wben and if interpreted viruses go wild, they tend to spread faster and farther, and the actual code is often freely available (including to people who aren't actually looking for it).
Again, like the Jerusalem virus, it seems that one of the lesser variants of Brain might be the "original". The Ashar version appears to be somewhat less sophisticated than the most common Brain, but Brain contains text that makes no sense unless Brain is derived from ashar. Brain contains other timing information: a "copyright" date of 1986 and an apparent "version" number of 9.0.
By 1987, the virus scene was heating up. Bernt Fix's disassembly of the Vienna virus was included in Ralph Burger's book Computer Viruses: A High Tech Disease, published in that year, though the code for Burger's own VIRDEM was not included. VIRDEM did spawn a number of variants, but was never any real threat or of major importance in the wild, unlike the widely copied Vienna.
The Lehigh virus, on the other hand, was described in the book, although its real impact outside Lehigh University was virtually non-existent. Lehigh was the first file infector that came to public attention, but the virus only infected the COMMAND.COM file, which rather restricted its capacity to spread. After infecting four disks, Lehigh would erase all data on all disks in the machine at the time.
This immediate, and fairly devastating, payload ensured that Lehigh would be noticed. The same factors guaranteed that the virus would be actively pursued and eliminated. It received a great deal of publicity, and had a direct impact on the anti-virus scene. Ken van Wyk, who was working at Lehigh at the time, and later went on to join CERT (the Computer Emergency Response Team), set up the VIRUS-L/comp.virus mailing list and newsgroup. Moderated by Ken, and then by Nick FitzGerald, later an editor of Virus Bulletin, VIRUS-L became an extremely useful resource for the exchange of anti-virus information, but it hasn't been consistently active for some years.
Stoned/New Zealand, one of the most successful boot-sector viruses ever, was written at the University of Wellington. (The other main contender for most common boot-sector virus is Form, which appeared a little later.) Written by a student, and apparently let loose by the author's brother, the virus had no damaging payload, and a minimal display payload. The infection mechanism was sturdy, and the code had few incompatibilities with normal computer operations. All of these factors contributed to the success of the virus in the wild, and also meant that it was used as a model for many other variants. Stoned and its derivatives are considered at length in Part III.
Cascade was the first encrypted virus. The encryption was an early and very simple form of polymorphism. Only the decryptor stub was detectable by "signature scanning". The self-encryption idea was developed subsequently (mostly by Mark Washburn, author of the V2P polymorphic virus family) into the use of variable encryption as a polymorphic mechanism. However, Cascade is probably best remembered for the visual effect it displays (letters "falling" out of their proper place on the screen into a heap at the bottom of the screen).
Rob Slade started to collect some messages about an intriguing new idea in operating system function: that of programs which copied themselves. By making this compilation available to interested security mavens, he accidentally became the unofficial archivist of what eventually became the international virus research community.
CHRISTMA EXEC, an email worm specific to IBM mainframes, was a precursor of the Windows scripting viruses of the late 1990s. It promised a Christmas card for the user, and did actually draw a vaguely coniferous shape on the terminal screen, using a scripting language called REXX. This screen display meant that the virus was sometimes known as 'The Christmas Tree", but there is also an MS-DOS virus called "Christmas Tree", which appears to have been written in homage to the original.
Characteristics CHRISTMA had in common with the later scripting viruses included the use of social engineering in the subject header (to stop the victim from reading the REXX code), self-mailing to everyone in the victim's address book, and exploitation of the trusted source fallacy.
NOTE
To this day, we hear of people puzzled to find that they're infected hy an email worm, despite opening only attachments received from people they know. Moral: trusting the person doesn't mean you have to trust the object. In general, people receive viruses and similar threats from other victims, not directly from the virus creator: that's one of the major weaknesses exploited by self-replicating malware. You have to trust not only the intentions of everyone you deal with, but also their ability to protect themselves from infection.
The attempt to fool the user distinguishes CHRISTMA EXEC from the Internet Worm that appeared almost a year later. The Internet Worm and other related beasts, as well as some of the more recent Linux viruses, tried to use system functions and programming bugs in order to avoid alerting or involving the user at all.
The first Amiga virus seems to have appeared in late 1987. It was essentially a boot-sector infector (boot-block, for the Amiga - it actually uses two sectors). It employs a form of stealth, and so may well be modelled after the MS-DOS Brain virus. The virus had message text that was displayed on occasion, and probably referred to the movie "2010", which had been released in 1984: "Something wonderful has happened Your AMIGA is alive !!!"
Scores, a Macintosh system virus, was apparently intended to target a specific company (EDS, in Dallas, Texas). This incident is discussed at some length in Part III.
The first instances of the Jerusalem virus were discovered in the wild late in 1987. It was known variously as "Israeli" (because of the initial discovery in Israel by Yisrael Radai), "PLO" (because of supposed terrorist intentions), "1813" (for the infective length), "suMsDos" (after a text string found in the body of virus code), and a variety of other names (for other reasons). Jerusalem had a destructive payload programmed into it, but it also had an unintended bug which led to early detection: Jerusalem would infect the same file again and again, leading to a noticeable increase in file size for some programs. This led to the common assertion that viruses can be detected by changes in file size, even though most other file infectors are tiny scraps of code in comparison to their targets. Of course, even a few bytes difference between file sizes might denote virus infection. Indeed, an increased size is one of the heuristics used by some generic anti-virus software, but only one, and by no means the most important.
While Lehigh did infect program files, it was limited to only one specific file, COMMAND.COM, because of both targeting and the infection mechanism. Jerusalem was the first MS-DOS virus to infect the full range of program files, including both COM and EXE formats. In addition, the basic infective code in Jerusalem is remarkably clear and straightforward, and three early versions - sURIV 1, sURIV 2, and sURIV 3, respectively - demonstrate how to infect .COM files, .EXE files, and both. Therefore, Jerusalem has become the precursor to a whole family of viruses. Initially, copycat virus writers merely changed trigger dates for the destructive payload, but eventually the infection module was found in a variety of other viruses with other payloads. Jerusalem itself spread worldwide, but also lives on in many other file-infecting viruses.
NOTE
In fact, most of the viruses in the late 1980s did spawn such virus families, and did pioneer various virus technologies. Jherefore, we have covered more of the detaib in the chapters dealing with case studies in Part III. For the remainder of Chapter 2, we will only he touching on highlights, and following broad trends, particularly for standard file and boot-sector infectors.
Jerusalem is thus an important milestone on the virus road, and will be considered in greater length with the case studies in Chapter 12.
The MacMag Macintosh virus was the first major infection for that platform. MacMag earned several other firsts, such as the first time a virus was written on commission, the first use of a non-viral "dropper", and the first time a perceived data file was used for transmission. It also infected several thousand release copies of Aldus Freehand - probably the first instance of commercial software being infected before it left the pressing plant.
The virus was instigated, though not written, by the editor of MacMag magazine, probably as a publicity stunt. Internal evidence in the code does seem to suggest the name of someone else as the author. No damaging payload was included with the program, although it did have a message designed to trigger on a certain date.
Part of the spread of MacMag was facilitated by a file that purported to contain information about new Macintosh models that were due to be released near to that time. The file was a HyperCard stack, a type of free-form database with graphical and other features. ("Stack" is the term for a HyperCard data file, a reference to a stack of cards.) Most users saw HyperCard stacks only as data, but it was possible to associate programming functions with and in the stacks. The MacMag virus is said to be the first example of a HyperCard virus, but HyperCard was only used to "drop" the virus into a system; the infective mechanism did not use HyperCard, and MacMag did not infect other HyperCard stacks.
One interesting vector was traced from a game, to a party, to a consultant, and then to the companies using the consultant. One of those companies was Aldus, and the master copy of the disks containing the Freehand program became infected. The infected disk was duplicated and distributed to dealers. Fortunately, the company, very responsibly, admitted to the problem as soon as it was discovered, and so further spread was minimized. Few companies in similar situations have acted with the same degree of integrity.
IBM entered the research field when their site at Lehulpe in Belgium was infected with Cascade. While IBM's anti-virus technology is now channelled through Symantec, the impact of their research has been and continues to be considerable.
Utility software guru Peter Norton was quoted in Insight as saying that computer viruses were an urban myth, like the alligators said to inhabit the sewers of New York. Later, however, he lent his name to what became one of the top-selling anti-virus programs.
The Internet Worm, also known as the Morris Worm (after the author) and the UNIX Worm (after the targeted operating system) swept through UNIX-based systems and brought the Internet to a near-halt in the early part of November. This was probably the first mention most people ever heard of the computer virus phenomenon. News stories about the event appeared in the general media, and, for many years afterward, no news story about viruses failed to mention the Internet Worm, regardless of the fact that it used technologies radically different from the other, more common, viruses.
The Internet Worm exploited a number of known weaknesses and loopholes in the networking and email software common to UNIX systems connected to the Internet. It used these vulnerabilities to transmit itself to new systems and to start running new copies of itself. Other parts of the program would then try to guess at common passwords and try to increase the level of privilege on the new target. In contrast to most viruses, the Internet Worm did not rely on any user actions at all, except for laziness on the part of managers who did not patch known problems, and account holders who chose bad passwords.
Using many of the same ideas, the WANK.COM and HI.COM worms spread through DEC (Digital Equipment Corporation) VAX model computers running an operating system known as VMS.
On the Atari ST computer, most disks were not bootable. (Hard disks were common by this time, and usually the system would be booted from the hard drive.) However, Atari disks had a boot sector, and it was read in order to obtain information about the format of the disk. If the first byte of the boot sector had a value of 60H, then the boot sector was marked as executable, and the contents would be run. In early 1988, an Atari ST virus appeared. It used the boot sector, and it only infected floppy disks. However, if a disk was present in the floppy drive when the computer booted up, the virus was executed before the system loaded from the hard drive. (Because bootable disks were few, leaving a floppy in the drive seems to have been a common practice.) The virus would copy itself to each uninfected floppy disk, and would add this infection to a counter. When the counter reached a certain number, the virus would trigger a payload that overwrote the system areas of the disk.
The late 1980s and early 1990s saw the development of many technologies within the basic virus model that had been laid down in earlier years.
Eugene Spafford' s "Crisis and Aftermath" and Rochlis and Eichin's "With Microscope and Tweezers: the Worm from MIT's Perspective" (both in Communications of the ACM) analysed the Morris Worm of the previous year. A number of CHRISTMA EXEC knockoff worms appeared. The WANK worm infected VMS systems using techniques synthesized from the Morris Worm and HI.COM.
Jerusalem panic struck as the virus's next trigger date (Friday, 13to January, 1989) approached. Indeed, every Friday the 13th became Jerusalem panic day for years afterwards. Datacrime (or Columbus Day) became one of the first media viruses (a virus that is mostly significant because of the media attention it attracts) later in the year. Datacrime was a minor variant of Jerusalem, and, like its ancestor, triggered on Friday the 13th. In October, Friday the 13th fell near the Columbus Day weekend, and this fact seemed to capture media attention. There was no other reason to pay particular attention to the Datacrime virus.
Virus Bulletin, still the most significant publication in the anti-virus field, was launched.
Dark Avenger's eponymous virus, better known among the research community as Eddie, introduced the concept of slow random damage as a virus payload. Thus, scrupulous backup procedures ceased to be a universal cure for virus damage, if they ever had been. The program stayed resident in memory once it had been run, and not only infected programs that were invoked, but also files as they were opened or copied. The Bulgarian author included programming targeting the Bulgarian virus researcher, Vesselin Bontchev.
NOTE
Dark Avenger was ugly, but innovative (the virus, that is): it also introduced the concept of fast infection. A memory-resident virus that infects files as they are opened for reading can spread quickly across a PC's hard disk (or, under the right circumstances, a network). Later viruses used modifications of this technique, such as infecting all executahles in the current directory, or in all directories listed hy the DOS PATH variable.
Frodo, the first full-stealth parasitic (file) virus, was detected in Israel. Also known as 4096 or 4K because of the length of the code, it attempted to hide the increase in the length of files from the user. While the virus was active in memory, any directory listing of files, as well as certain other utilities, would only show the original file size. However, because this was not consistent with the number of sectors being used to store the files, cross-linking of infected files would occur in the system areas of the disk. In addition, because of the way the virus chose targets, data files would sometimes be corrupted. Frodo contained a message payload, but all known versions contain bugs, and it is unlikely that it ever successfully displayed the message without hanging the host machine.
Dr. Popp distributed his AIDS information diskette, which used a Trojan mechanism in an attempt to extort money for the recovery of the victim's data. The disk, purporting to be information on the user's risk of AIDS, did present a quiz in the foreground, but would also encrypt the contents of the hard disk. A message would then pop up saying that the free trial period was over, and that in order to recover your information, you would have to pay a licence fee to obtain the key. The AIDS Trojan is the subject of a case study in Part III.
In October of 1989, an interesting virus was demonstrated at an Amiga Users Group meeting. Referred to as the 2608 virus, after the length of the code, this program would associate itself with the first program in the start-up sequence. However, the file did not simply append itself to the original file, as most viruses did at that time. Instead, it copied the first program into the devs directory, and copied itself into the old position in the directory. When the computer was started, the virus would run, and would then call the real command. Some subsequent Amiga viruses, such as Smiley, worked the same way. This technique is similar to a function later used in an MS-DOS virus family called DIR, which caused file directory entries to point to the virus, which in turn pointed to the original file. More recently, some malware has varied the technique further by changing the Windows Registry to point to the virus code, which then passes control to the legitimate program.
Commodore's reaction to the news of early Amiga malware was to dismiss the whole subject as a hoax. Later, they moved on to ignoring the issue altogether. The Amiga has also been more or less ignored by commercial anti-virus vendors, but the number of Amiga viruses is surprisingly high (higher than the number of native Macintosh viruses, for example).
NOTE
Doesn't this contradict our earlier assertion that the frequency with which viruses are found on a given platform is related to how widely used that platform is? First, we didn't state it as an immutable law: after all, someone with the time, programming skills, and inclination to swamp a relatively little-used platform might do so with the express intention of disproving such a "law". Second, the total of viruses to which the Macintosh is subject far exceeds the number associated with the Amiga. The Amiga does not support Microsoft Word, and so has not been subject to the flood of Word and other macro viruses that have appeared since 1995. Macintosh versions of Word, however, have supported first WordBasic and later Visual Basic for Applications since version 6.0. While macro virus payloads are usually PC-specific, many (even most) macro viruses can and do infect irrespective of whether they are executed on a Macintosh. Since 1995, unprotected Macs (or machines on which protection has not been consistently updated) have been a major channel for the dissemination of Office macro viruses. This issue is explored in much greater depth in Appendix B.
In 1990, polymorphic viruses started to make serious waves, using technologies more complex than simple self-encryption. Without a definite decryption stub, these more advanced forms were slightly harder to detect. This had a number of consequences: vendors who couldn't handle variable decryption started to look for alternative careers, and false alarms began to be a serious problem.
One of the first of the new breed was Whale: a virus so complex and unwieldy that it was practically impossible to get it to replicate, so it never really made it into the wild. However, as an exercise in making a virus difficult to analyse, it became somewhat notorious. The virus was also one of the longest found up to that time, with over nine thousand bytes of code. In spite of the size of the program, it only produced some thirty different forms.
Bulgaria gave the world what may have been the first virus-exchange bulletin board.
Flip/Omicron became, arguably, the first successful multipartite virus, infecting .COM and .EXE files, as well as the Master Boot Record. However, the infection could only spread further via .EXE files. In addition to a poor infective mechanism, Flip had a number of other coding errors, and infected systems generally developed errors with cross-linking of files. The name Flip came from the payload of the virus: at a certain time and day of the month, the monitor display on infected systems would flip horizontally.
EICAR (European Institute for Computer Anti-virus Research) was founded in Hamburg and became a forum for cooperation between vendors, academics, and corporate customers.
Peter Norton got over his disbelief in viruses enough to lend his name to Symantec's new anti-virus program - Norton Anti Virus.
Harold Highland's Computer Virus Handbook was published. Although dated in certain specifics, the book contains a wealth of research and opinion that is still valid today. It was a compilation work, as were, oddly enough, both Peter Derming's Computers Under Attack and Lance Hoffman's Rogue Programs, published the same year.
In 1990, as now, there were myriad requests for information as to which current anti-virus program was "the best". Since no one else seemed to be responding, Rob Slade started his longstanding series of reviews of anti-virus programs.
Michelangelo, a seriously destructive boot sector virus, was first identified in February of 1991. Based on the solid infection mechanism of the Stoned virus, it carried a destructive payload that would use random information to overwrite the first 256 tracks of the disk used to boot the computer. Usually this would be the hard disk, and these areas contained most of the system information for the computer.
The name "Michelangelo" was assigned solely based on the trigger date of 6to March, which was the birthday of the Renaissance artist. No formal identification has been made of the author, although there are strong indications that the virus was written and released in Taiwan.
The total number of known viruses climbed towards a thousand. More and more anti-virus programs appeared, as did more VX (Virus eXchange) bulletin boards.
Tequila, the first widespread polymorphic virus, seems to have been based on the earlier Flip. Tequila contained a number of viral technologies, including multipartite form, stealth, and variable encryption polymorphism. Like its predecessor, Flip, Tequila could result in cross-linking. File corruption often resulted from attempts to deal with the problem.
At about the same time, another virus to use variable encryption was Maltese Amoeba. It was a standard file infector, but carried a somewhat destructive payload, overwriting the first sector of available disks on two days a year. Slightly before work began on the first version of the VIRUS-L FAQ (to which he became a contributor), Rob Slade began to publish a weekly series of computer virus tutorials on the Internet and on FidoNet.
NOTE
Before the popularization of the Internet, bulletin hoard systems (BBSs) were the most popular means of mass communication. FidoNet was a means of communication between BBS users, somewhat similar to the way that the Internet links networks. Jhis communication included not only mail, hut echomail, which extends the availability of local discussion topics to anyone on FidoNet. By the time the World Wide Web started to take off, there were tens of thousands of bulletin boards connected in this way, but interest has declined as Internet take-up has accelerated. A number of FidoNet discussion echoes have dealt specifically with pro-virus and anti-virus issues.
The Saddam virus used the Commodore Amiga's validation function (run on new disks) for reproduction and infection. It would place itself on a disk, identified as the validator program. When an infected disk was inserted, the system would, for some reason, use the validator program on the disk, and thus infect itself. The computer was infected simply by putting an infected disk in the drive, without the operator running any programs. This virus seems to have appeared in the spring of 1991. The operation of the virus was very similar to the earlier WDEF virus on the Mac, and it included a form of stealth, to hide its existence.
Interestingly, there was also a Saddam (or S ADAM) virus for MS-DOS at the same time. Although the virus contained numerous bugs (including egregious spelling errors in the message payload), it was never a major problem.
The VCL (Virus Creation Laboratory) virus authoring package allowed virus generation capability to those with no programming skills at all. VCL didn't exhibit much coding proficiency, and generic detection of VCL viruses presented no problems. Virus creation or authoring "kits" can create thousands of different viruses, but the base code modules used are all the same. The infective code for any virus created by such a kit is generally identical to every other virus produced by the same "laboratory", and detection of one can generally detect all of them. We must note, however, that the recent VBSWG virus generator is something of an exception. Some products are more successful than others at detecting new viruses generated from that particular kit.
Michelangelo became something of an epidemic (see the case study in Part III), although it didn't quite live up to its advance publicity. Nevertheless, thousands of systems went down on the day it triggered, and perhaps there would have been many more if the publicity hadn't been so widespread before the trigger date. Michelangelo became another media virus, and this led to a very strange denouement. Since the media played up the story, many people were encouraged to check for viruses, in some cases for the first time. When cases of Michelangelo were detected, they were, of course, eliminated. Therefore, while millions of instances of the virus were found, only a few (possibly less than a million) triggered on what the media saw as "Michelangelo Day": 6th March, 1992. When the world did not end, the media, oddly disappointed, did an about-face, and decided that Michelangelo was some type of hoax.
NOTE
In fact, Michelangelo was present and active in the wild for many years thereafter. In the mid-1990s it constituted the major infection in some countries. Michelangelo still survives to this day, although, because of changing computer patterns, in greatly reduced numbers.
One PC company in the UK distributed a number of brand-new PCs with this particular shard of "added value" (one of which ended up on David Harley's desk). A couple of anti-virus companies caused a certain amount of distress by issuing free Michelangelo "special editions" of their software without making it clear that Michelangelo was the only virus they could detect.
Dark Avenger (or one of a number of virus authors who may have used this "handle") released the Self Mutating Engine (MtE): not a virus itself, but a means of adding polymorphism to a virus with a minimum of coding. Fortunately, the MtE left a signature, and therefore became a generic means of identifying a suspected virus.
The same author's Commander Bomber made the job of virus detection harder by forcing the scanner either to scan the whole file or to "step through" the code. Instead of inserting code or a pointer at the beginning or end (referred to in the research community as the "top and tail") of the infected program, the virus body was inserted, as fragments, in the middle of the file. The pieces were connected to each other by a complicated series of links. This was a nuisance at the time, but a useful addition to the scanner's armoury as technology advanced on both sides of the AV/VX divide. The virus itself was rather simple, despite its enormous code size, infecting only .COM files.
In the summer of 1992, another Atari boot-sector virus appeared, carrying a message indicating that it was an antiviral program. It is possible that the code was intended to be a kind of (incompetent) anti-virus, since it would overwrite any existing boot-sector virus. However, since the common Atari boot-sector viruses of the time only wrote to disks that were not already executable, it was more virulent than most viruses on that platform. As with other attempts at antiviral viruses, this was a failure. (It's not uncommon, either, for virus-infected files or virus droppers to masquerade as anti-virus software.)
Trident Polymorphic Engine (TPE), Nuke Encryption Device (NED), and Dark Angel's Multiple Encryption (DAME) built on the work started by Dark Avenger in MtE. None caused the end of virus signature scanning as we know it.
MS-DOS version 6 was released, incorporating the not-very-good Microsoft Anti-Virus (MSAV), based on a not-very-good product owned by Central Point, which was acquired and eventually dropped by Symantec. The package contained an extremely weak "on-access" component, which has become famous primarily because it encouraged virus writers to include a short section of code that turned off the target system's antiviral protection.
NOTE
Yisrael Radai's review of MSAVis reprinted in Pamela Kane's book PC Security and Virus Protection Handbook (M&J Press, 1994). His essay is a textbook example of a solid product review, and is an amusing read even if you bave no responsibility for antiviral protection.
Joe Wells posted the first WildList, an attempt to list and track the activity of viruses known to be out in the field and causing problems. The WildList Organization, which grew out of this list, was discussed in Chapter 1, and we will return to it in Part II.
IBM researchers Jeffrey Kephart, Stephen White, and David Chess published their paper on "Computers and Epidemiology". Anti-virus researchers have always been attracted by the application of an epidemiological model based on biological infection mechanisms. In biological life, a body invaded by pathogenic organisms from outside identifies and reacts against these assaults automatically. The use of this model has led to the introduction of models of virus management based on biological immune systems. Recently, some have wondered whether a model based on metastasis (the spread of a malignant growth from its point of origin) might be a more appropriate model for recent malware than the traditional pathogenic infection model. In fact, both models have their uses, the former being more generic, and the latter reacting more quickly.
In June of 1993, Fuck, an extremely malicious Amiga virus, was released.
NOTE
Look, it's not our fault. That's what the darned thing was called. Actually, a number of viruses have heen blessed with this unattractive name, including a formerly widespread Macintosh virus. In addition to finding names in this book that some might find offensive, you will also notice, as we provide more details of specific viruses, that many messages and text inclusions in the hody of the virus contain errors in grammar and spelling. In the interests of accuracy, and because the specific strings can he used to identify the presence of a virus, we have left the messages as they are, warts and all. In all quotations, any mistakes you see are deliberate.
It was initially spread by a Trojan dropper program that was advertised as a program to check your modem. The virus would replace a system file called loadWB. The viral code would be run when the computer started, and it would then call the real system file. The virus would wait out a time period determined by the screen refresh rate, and would then start overwriting the disk with the titular obscenity, eventually trashing everything.
Like other viruses of that general era, this one checked for the presence of a popular antiviral program and, if found, turned it off.
Black Baron's Smeg.Pathogen and Smeg.Queeg caused real (albeit overstated) damage to some corporates. If Pathogen's payload was triggered, a message was displayed that included the words '"Smoke me a kipper, I'll be back for breakfast...' Unfortunately some of your data won't!!!!!!" and then the first 256 cylinders of the hard disk were trashed.
Kaos4 was posted to a newsgroup specializing in erotic pictures. This was not the last time this particular vector was exploited, of course. Indeed, some victims of the later Hare virus were caused additional embarrassment. Not understanding how quickly a virus can be passed on by secondary infection, people assumed that they were infected as a result of haunting unsavoury newsgroups.
Virus hoaxes, by no means new, became a serious problem with the rise and rise and rise of the Good Times alert, followed by a wave of copycat hoaxes. In fact, most current hoaxes can still be said to belong to this group, conforming as they do to a stereotyped pattern. "Don't open email with such and such a title: it contains a virus that will perform sundry devastating acts. Send this on to everyone you know." Virus hoaxes have been somewhat neglected by the anti-virus community in the last couple of years, but continue to be a major problem. We will consider that problem at some length in Chapter 16.
The first edition of Robert Slade's Guide to Computer Viruses was published. (And the title was not his idea.)
Christopher Pile (the Black Baron, see 1994) was convicted and imprisoned under the UK's Computer Misuse Act. (Did ever a virus writer have a more appropriate surname?) Somewhat depressingly, the next highly publicized arraignment of a virus author was not until that of the author of Melissa in 1999.
The Good Times FAQ (Frequently Asked Questions) document was released, as was Version 2 of the VIRUS-L FAQ (see Appendix A). At this time, many former inhabitants of comp.virus had migrated during a period of dormancy to the altogether wilder (unmoderated) newsgroup alt.comp.virus. At about this time also, at the suggestion of Dr. Alan Solomon, work started on the alt.comp.virus FAQ. (The FAQ was drafted, edited, and maintained by David Harley, but, like the VIRUS-L FAQ, included material contributed by some major names in anti-virus research.)
Wm.Concept, the "first" macro virus, was closely followed by several more MS Word (and MS Excel) viruses. Arguably, the first macro viruses in the wild were earlier Macintosh HyperCard infectors. There had also been unpublicized test viruses using macro languages such as Lotus 123, but Microsoft Office viruses changed the whole profile of the industry, which took a fair while to weather the change. Concept appears to have originated within Microsoft, which for a while referred to it as a "prank macro" rather than a virus. (No-one else was willing to accept the Microsoft assessment.)
The original version of Concept carried a comment, "That's enough to prove my point", buried in its code, instead of a payload. It became the most widespread virus in the world for a while, and spawned a major virus subclass that continues to trouble PC and Macintosh users.
Protection against the very first Word viruses was relatively easy to achieve by disabling automacros, which took only a line or two of WordBasic, and several experts quickly published appropriate code. Eugene Kaspersky, a prominent anti-virus researcher, published a Microsoft Word template containing protective macros: dishearteningly, a subverted version of this file appeared soon afterwards on a web site, infected with the then unknown Nuclear macro virus. Of course, virus authors soon found other methods of infection.
Introducing proper detection of macro viruses into scanner technology, however, proved a major, time-consuming undertaking: indeed, changes to Office file formats and the macro language technology that underpins MS Office applications continue to provide researchers with interesting little puzzles.
NOTE
Proof-of-concept viruses have become something of a growth industry in their own right. Viruses have heen written simply to prove that a specific loophole exists. However, the author gets the "glory" ofheing the first to exploit the vulnerability, irrespective of the likelihood of having a virus achieve widespread dissemination. Thus, viruses have heen written for applications, such as MS PowerPoint or MS Access, that support Visual Basic for Applications (VBA) or related macro languages such as CorelScript, even though they are not normally associated with the routine exchange of macro-infected documents.
More macro viruses appeared, inevitably. Boza, a mediocre file virus, materialized. Its only real importance was that it was the first Windows 95 virus using the new PE-EXE format, rather than the earlier MS-DOS .EXE structure. Hare was also launched via USENET, and was probably more significant as a media virus than for its actual impact. Laroux became the first MS Excel infector to be a real problem in the wild.
The second NCSA/ICSA survey was conducted in 1996, and from this year on, it became a yearly event.
PC users began to become accustomed to the idea that macro viruses are here to stay: Mac users, and others, acclimated to the idea that viruses were mostly a PC problem, continued to put their trust in Disinfectant and Gatekeeper. However, since neither program detected Microsoft Word or Excel macro viruses, macro epidemics started to build up across the Mac/PC divide. David Harley began work on the "Viruses and the Mac" FAQ, in the hope of addressing this problem.
Some people still have trouble understanding that a macro virus can be problem on any hardware platform supporting applications that themselves support the relevant macro language. In other words, macro viruses aren't necessarily specific to a single hardware architecture or operating system. In fact, as more applications (including some not published by Microsoft) offer support for Visual Basic for Applications (VBA), it may even be a little misleading to say that macro viruses are application-specific.
Good Times and a number of related hoaxes continued to resonate, and the 1997 Virus Bulletin conference included several related papers (as well as a presentation on Mac issues by David Harley).
"Stormbringer", an ex-virus writer, delivered a presentation to the assembled industry representatives on why they should give him a job as an anti-virus developer. In vain - it seems no company thought his (genuine) programming skills were worth the bad publicity they were likely to reap by employing someone from the Dark Side.
Away from the conference circuit, "Red Team" started to blur the borders between hoaxes, spam, and real viruses. It exploited the fear inspired by Good Times, and offered an alleged anti-virus program that was actually a virus dropper.
AOL trojans became a growth industry. Worm revival began slowly with mIRC worms, using the automated functions in that particular Internet Relay Chat client, and email-aware macro viruses.
Most experts regard the second wave of worms as qualitatively different from the first wave (such as the Internet Worm), in that they don't usually spread independently of any action on the part of the user. That is, they must persuade the victim in some way to "invite them in" by running an infective program. Older worms were more likely to exploit programmatic loopholes, and they infected vulnerable systems autonomously.
Esperanto was a PC virus widely hyped as a cross-platform virus (that is, it was alleged to infect Macs too). Some virus encyclopaedias continue to compound this error, derived from the writer's boastful and wishful thinking.
Joke/prank programs were becoming a serious nuisance: less because of their alleged destructive or replicative properties than because anti-virus products insist on flagging them as viruses.
The AutoStart worm/virus became the first significant Macintosh-specific threat in many years. It was first noticed on the Pacific Rim, but quickly spread to the US and Europe. Several variants were seen, some of them severely destructive. SevenDust and a handful of other Mac viruses were discovered shortly afterwards, suggesting a short-lived revival of interest in the creation of Macintosh malware.
CIH (Spacefiller, Chernobyl) was first reported in June. It was most noticeable for the ugliness of the pay load carried by some variants. On its trigger date, it would attempt to rewrite the flash BIOS. (If it succeeded, the PC would become unbootable.) Since the BIOS chip cannot economically be replaced on some motherboards, it was sometimes necessary to replace the entire motherboard. For many years, there have been discussions about viruses destroying hardware. Technically, CIH trashes firmware, not hardware, but the distinction was, for many victims, completely academic. The virus would also trash the victim's hard disk.
Network Associates acquired Dr. Solomon's, and many users of the Dr. Solomon's product range started to vote with their feet. This was probably due to widespread distrust of the McAfee brand name, which already belonged to NAI.
The first edition of Back Orifice was released in early 1999, or possibly late in 1998. Back Orifice is a curious program. It is definitely not a virus, though anti-virus software usually identifies it as such. Its creators don't even want it to be seen as a Trojan, and a later edition, BO2K (Back Orifice 2000), was promoted as legitimate commercial software. To clarify the situation requires some deliberation.
Commercial "remote-access" programs, such as PC Anywhere, have been available for many years. These programs make it possible to connect home and office computers in such a way that your office computer can be run from your keyboard and screen at home. This gives you access to all the programs and files on your office machine. In fact, the programs that you run are executing on your office computer - only the interface information is being communicated between the two systems. In addition, of course, network functions like RAS (Remote Access Service) on Microsoft Windows computers allow access to information on one computer from another, even over the Internet.
Back Orifice permits similar functions, except that the access can be achieved without the user of the computer being aware of the situation. The program is designed such that once Back Orifice is run on a computer, it installs itself as a service and alerts some remote user that the computer is accessible. Therefore, it is only necessary to get someone to run an unknown program, once, and their computer is open to you. In network support situations, "some remote user" is defined as the technical support worker, and "someone" is the user having difficulty. But in security breaking circumstances, "some remote user" is the attacker, and "someone" is the victim. A similar function was used to gain access to Microsoft's own computer network in late 2000.
Back Orifice is not a virus, but it can certainly be defined as a Trojan, and in the most classic sense. Once you have run a copy of Back Orifice on your computer, the enemy is inside, controlling operations, and can even turn off anti-penetration systems.
Melissa, a macro virus/worm hybrid, was perhaps the first of the modern "fast burners": viruses/worms that go global in hours, or less, spreading quickly enough to cause mail-server "meltdown" on some sites. Melissa achieved this effect by mailing itself to the first 50 entries in each victim's address book. It spawned many imitators and variants, due both to the publicity and to the fact that, like a macro virus, it carried its own source code. Its impact can be compared to that of the CHRISTMA EXEC and Morris worms. These, too, spread within hours, although they infected a specific subset of users. (The same could be said of Melissa, except that the subset was rather larger.) The impact of the earlier worms was similar to that of Melissa, although not as widespread since the 'Net wasn't as big in those days. We should reiterate, however, that researchers differentiate between first-generation worms like the Morris worm, many of which are self-launching, and the current generation, most of which can't execute if the victim is cautious.
Happy99 (Ska) took a firm hold on the world's email. Spanska, its author, likes to give good value, so when the virus is launched it displays a graphic representation of a fireworks display and a Happy New Year 1999 message. It replaces WSOCK32.DLL with itself in order to make use of email functions. Fortunately, the original library is kept under the name WSOCK32.SKA, so recovery is generally fairly simple. Each time the victim sends email, a second message including the virus as an attachment is sent to the same recipient. Happy99 is also compatible with USENET news, so when you send a message to a newsgroup, a second posting will also be made in your name and with the same subject, but containing the virus.
PrettyPark spreads via the victim's address book, but also via IRC (Internet Relay Chat). If it is able to spread this way, the virus author is able to use the program's back-door functionality to harvest information about the victim's system. One of PrettyPark's unpleasant side-effects was that Registry changes introduced by the virus impeded its removal with anti-virus software, once the antiviral was updated to recognize the virus. In some cases, once the update had been applied, the memory-resident scanner blocked an on-demand scanner from loading (and therefore from removing the virus), since the latter was perceived as being infected - the nature of the Registry modification made it seem as though all .EXE files were infected, since the virus was executed before the .EXE.
Script viruses started to creep out from under rocks. BubbleBoy fulfilled the Good Times dream of a virus that can infect just by mail being read. (But this happened only if you used Outlook, and Microsoft issued patches to repair that particular security hole.)
In the fall, trinoo (or tr1n00), one of the first pre-programmed distributed denial of service (DDoS) packages, became available on malware distribution sites. DDoS systems are not viruses, but we'll talk more about them in relation to the year 2000 at the end of this chapter.
ExploreZip was notable for a number of reasons. It masqueraded as a self-extracting zip file and piggy-backed valid messages by using a subject line that made it look like a reply to legitimate mail. It also looked for shared network drives, installing itself on shares giving access to other computers in a local or wide area network.
Shared volumes have long been a vector for virus infection. However, the fact that ExploreZip uses the function means that it is able to evade the commonplace precautions of mail hygiene, such as avoiding opening attachments. It does not matter how paranoid A is about opening attachments: if A grants B significant write access to his workstation or server through a shared volume, B's lack of similar caution can render A just as vulnerable (albeit indirectly) to an initially email-borne attack.
ExploreZip also carries a damaging payload, erasing the data contained in certain types of files. Shared drives, even if uninfected, can also have files truncated. This virus enjoyed a return to the charts later in the year when variants packed with diverse compression packages appeared, requiring anti-virus vendors to update their detection.
Everyone covered their heads in anticipation of the breakdown of civilization as we know it on New Year's Day, 2000. Consultants and other Instant Experts described (sometimes in absurd detail) an incoming wave of Millennium viruses, despite the protests of anti-virus experts who expected no such deluge. There were minor indications that some virus writers tried to instigate a massive flood of viruses and other malware. Some companies chose to hibernate for days or even weeks in the hope that things would still work when they were switched back on.
No millennium virus worth mentioning appeared, despite the hyperbole. A handful of minor viruses, Trojans, and hoaxes spread, however, by taking advantage of the prevailing panic.
REVS (Rapid Exchange of Virus Samples) was launched in an attempt to improve industry response time to "fast burner" viruses/worms, such as Melissa.
Wireless application protocol (WAP) malware started to look like a real possibility, and personal digital assistant (PDA) malware appeared. Palm/Phage, though rare, was capable of infecting the Palm OS, while the (also rare) Trojan horse Palm/Liberty-A deleted Palm OS applications. While there is no known virus that uses Psion's EPOC operating system at the time of this writing, anti-virus products for wireless devices and WAP gateways were already being announced as the year drew towards an end.
In February of 2000, the general public first became aware of DDoS (distributed denial of service) attacks when a number of major commercial servers were affected. Denial of service (DoS) has long been known as a risk in computer security circles, but has not been the subject of much public discussion. News reports and marketroids have referred to them as viruses, but DDoS systems and attacks are not viral, and, so far, have not involved viruses. DDoS attacks are considered in detail in Chapter 3, which deals with malware technology.
NOTE
Occasionally, there is confusion between the acronyms DOS and DoS - note the capitalization. DOS normally stands for disk operating system. The acronym is often used as shorthand for MS-DOS, Microsoft's venerable operating system. It has no etymological connection with denial of service (DoS) attacks.
VBS/KAKworm took the BubbleBoy concept (a virus that could infect on reading email, and that didn't need an attachment) into the wild (it was one of the most commonly reported viruses of the year). Like BubbleBoy, it exploits a vulnerability (Scriptlet. Typelib) in Internet Explorer that can be fixed by downloading and applying a software patch described in Microsoft's Security Bulletin MS99-032. In pre-patch versions of Internet Explorer, it was possible for the infective code to be executed just by opening or previewing an infected message. The infective script is contained in the signature, but isn't seen by the victim, as no displayable text is present. The script is, however, very noticeable in other mail clients. KAKworm is considered in detail in Part III.
Curiously enough, KAKworm corresponds more closely to the old-style Morris-type worm than most recent worms or viruses since it doesn't have to trick the victim into executing it.
In spring, a virus author's fancy lightly turns to thoughts of love. The Love Bug (LoveLetter) virus appeared on 4to May and spread faster and further than Melissa. Several variants appeared almost immediately, due in part to the wide availability of the original VBScript code. The first widespread version mailed itself out to everyone in a victim's address book, attached to a message with the subject line ILOVEYOU. The message body read "kindly check the attached LOVELETTER coming from me". The attachment itself used the file name LOVE-LETTER-FOR-YOU.TXT.vbs. The trick of giving an attachment two extensions has grown very common. In this instance, the first extension suggests a harmless, non-executable text file, in the hope that the second extension (indicating the real nature of the file) won't be seen by the victim.
All charges against Onel de Guzman, suspected of having released and possibly written the virus, were dropped by the Manila Department of Justice several months later. Phillipine authorities said that, under the laws in force at the time of the incident, sufficient evidence could not be produced to successfully prosecute the case.
LoveLetter uses Outlook to spread and, like other Visual Basic Script (VBScript) viruses, can only execute if the Windows S cript Host is active and enabled. LoveLetter and its many variants will be examined at some length in Part III.
Since worms have to work harder to persuade the victim to execute the malicious program, the term "social engineering" was bandied about a lot. There's a paradox here. As we've previously mentioned, the first generation of worms tended to be more autonomous. Yet conventional viruses don't usually need social engineering in this sense, since they (mostly) piggyback legitimate code, and are executed as a result of an attempt to execute legitimate code. In some respects, most of the current generation of worms resembles Trojan horses in needing to trick victims into colluding in their own downfall. In fact, many vendors and general security discussion lists nowadays are often referring to what we would call worms when they use the term Trojan horses.
NOTE
Social engineering is a term that has attracted a wide range of definitions, some of them mutually exclusive. In this context, we offer a definition from David Harley's Social Engineering FAQ: "Psychological manipulation of an individual or set ofindividuab to produce a desired effect on their behaviour." A summarized version of the Social Engineering FAQ is included in the resources section of this hook, and the subject is also discussed in depth in Chapter 16.
Stages of Life introduced a mild polymorphic twist. Many sites had noted that LoveLetter variants could be blocked at the mail gateway by discarding mail with a characteristic subject field, without the use of specialized filtering software. Stages varied the subject line by using one of 12 possible permutations, some of which were general enough to result in the discarding of legitimate messages if filtering wasn't carefully set. The attachment, a shell scrap file called LIFE_STAGES.TXT.SHS, introduced an additional complication in that the SHS extension can remain hidden in Windows even if Windows Explorer is set to show file extensions. If executed, the virus created a number of randomly named SHS files, the number of possible names being in the thousands.
CNET, the sprawling information technology product portal, published an anti-virus product review in September that plumbed new depths in incompetence. Inept reviews are nothing new, of course, but this one triggered a concerted response from the anti-virus community. Joe Wells, founder of the WildList Organization and editor of WarLab Journal, wrote an open letter to CNET's editorial staff, to which a number of anti-virus professionals added their signatures. The letter contended that the review "did antivirus product users a major disservice" and argued that case at some length.
NOTE
You can find out more about both the review and the open letter at http://www.warlabs.org/portal/advisories.html. Some signatories of the letter also carry copies of the letter on their web sites, including one of the authors of tbis book (http://www.sherpasoft.org.uk/).
We will consider some of the problems and issues of comparative testing at length in Chapter 9. Naturally, we'd like you to have the best possible information on testing: you wouldn't believe how deleterious an incompetent review is to an expert's blood pressure.
This virus/worm hybrid first came to light around the end of August, but chose the end of September, when most of the big guns of anti-virus research were at the annual Virus Bulletin conference, to "get lucky". MTX also made some use of the "double extension" trick: when it mailed itself out from a victim's account, the attachment was given a number of potentially misleading names. In many cases, a first extension suggested a JPEG or a text file, but the second extension was .PIF, indicating an executable file. While the actual file format was that of an EXE, not a PIF, this did not, of course, stop the program from being executed. Files with the .PIF extension can include many objects, including executable code. MTX was notable for the fact that it blocked browser access to some anti-virus vendor web sites, infected some files with the virus component, and replaced others with files with the worm component (necessitating replacement from the Windows installation CD). The author had gone to some lengths to make its removal difficult.
Feliz Navidad ("Happy Christmas") was in some respects a very lame virus, a brilliant example of a virus author who couldn't be bothered to test his creation. If the victim was rash enough to execute the infective mail attachment, the Windows Registry was tweaked so that any time an .EXE file was run, the virus was executed first. However, the file name referenced in the Registry was not the name given to the file actually dropped by NAVIDAD.EXE, so after the PC was rebooted, it became virtually unusable, since no .EXE file could be executed (including virus scanners). You might think that this would restrict the spread of the virus, but since the virus managed to fire itself off as soon as it infected, this was not necessarily so.
Unfortunately, the author proved abler at social engineering than at Quality Assurance. The worm mailed itself out as if it were a reply to mail previously received by the victim. Since it homed in on received messages that included an attachment, normally cautious recipients were primed to expect an attachment in the "reply". Happily, the virus proved rather simple to remove with a little Registry editing and the manual removal of a couple of files. Less happily, an "improved" version followed in due course.
W32.Prolin caused a certain amount of confusion when one anti-virus vendor chose to call it Shockwave. It is not a "Shockwave virus", but is distributed as an .EXE file that claimed to be a "great Shockwave flash movie". Its author seems to have intended some social engineering in a traditional sense, as well as in terms of manipulating the victim into executing the program in the first place. .Zip, .MP3, and JPG files are moved to the root directory and renamed by having the string "change at least now to LINUX" appended to the existing extension. It also generates a text file with a hectoring message:
Hi, guess you have got the message. I have kept a list of files that I have infected under this. If you are smart enough just reverse back the process. I could have done far better damage, I could have even completely wiped your harddisk. Remember this is a warning & get it sound and clear... - The Penguin
What would we do without the superior intellects of virus writers to remind us of the need to take precautions against - er, virus writers?
Several viruses that emerged in 2000 suggested a movement towards a new type of functionality. A number of recent viruses include in their code the ability to make calls to a specific web or ftp site in order to download files. (Probably the most widely known example is the Love Bug, which attempted to fetch a file from a site in the Philippines.) In some cases, the file to be downloaded is an additional payload for the virus, made available separately in order to reduce the size of the virus itself, thereby making it less conspicuous. In other cases, the file may be an updated version of the virus, so that the author can continue to "improve" his (or her) creation while it is out in the wild.
Late in the year, Hybris demonstrated an additional use of this technique. The virus appears to be built in a very modular fashion, and the downloading function can be used to replace missing or damaged modules. The modular construction also makes updating quite simple, and new features can very easily be plugged into the virus. W32.Music attempted to call updates somewhat similarly, but from specific sites.
Fortunately, it is easy to detect the operation of such downloading functions, and to determine the sites and files being called. Once these facts are known, requests to site administrators to remove the files, or to remove access to the sites, are generally honoured quite quickly. Once the sites or files have been removed, the danger of updating is eliminated. Sadly, the danger of updating viruses cannot be completely disregarded.
There are other, less easily identifiable means of communication over the Internet. Hybris already uses USENET news postings for some of its downloads. Other viruses have called on the functions of IRC (Internet Relay Chat) with a range of automated "bot" technologies little known to casual users. Anonymizing remailers can be used in various ways. (Lest this seem a slap at the cypherpunk movement, please note that commercial "free email" servers like Hotmail have already been variously misused.)
Opening a channel of communication between an infected system and a remote system outside the control of the victim offers possibilities beyond allowing the virus author to track the progress of his or her creation, updating modules, or transferring confidential data. The very fact that the victim system uses that channel announces its vulnerability and reveals host information, not only to the controlling system, but to other software probing for open ports (for example). This, in turn, can inspire and enable other directed attacks using the vulnerabilities detected.
History continues, but chapters and books have to end at some point. New viruses, and new virus technologies, are constantly evolving. As this book is in preparation, a virus has been seen that advertises and spreads itself using one of the popular peer-to-peer file-sharing systems. Some new Linux viruses have appeared, using network vulnerabilities in a manner similar to that of the old Internet/Morris/UNIX Worm. There has even been a file-infecting virus compatible with both the Microsoft Windows and Linux executable file types.
But publishing deadlines beckon, so we must leave you with one final exhortation. Keep watching.
It does not take much familiarity with Internet technology to see where some of these trends are leading. Virus writing is heading for a convergence with other forms of electronic vandalism. Email viruses such as Melissa and Love Bug (only slower, and thus less noticeable) can be used to launch self-updating viruses, incorporating some form of polymorphism from a modular updating capability. Payloads can include backdoor programs, such as that carried by Back Orifice (which can be used to take remote control of any net-connected computer), or client-side "zombie" programs for large-scale distributed denial of service attacks. In fact, viruses with some sort of backdoor functionality, such as "calling home" to send back data about the victim system and its owner, have become increasingly common over recent years. (W97M/Marker and W32/Babylonia are high-profile examples.)
Thus, anti-virus technology is no longer simply about keeping your own computers safe. (It never was, actually, and we'll explore this thought further when we consider that technology at length in Chapter 6.) Anti-virus practices now have a larger role to play in the security of the connected computing environment as a whole.
To understand anti-virus technology, we must first examine virus technology more closely.
IN THIS CHAPTER:
The term malware covers a wide range of threats, most of them addressed, to some degree, by anti-virus software. In fact, the software we generically describe as "anti-virus software" delivers both more and less than it promises. Most antiviral software detects more than just viruses. Even single-shot anti-virus programs that recognize only one virus need to distinguish between uninfected and infected objects. On the other hand, no anti-virus program consistently detects all known malware. Strictly speaking, no anti-virus software can even detect all known viruses (if only because of the time lag between encountering a new threat and adding detection to the program).
What about programs that claim to detect all known and unknown viruses? (Such programs were memorably characterized by Padgett Peterson with the acronym TOAST, from a product advertised as "The Only Antivirus Software That Won't Be Obsolete By The Time You Finish Reading This Ad".) We need to clarify terms a little at this point, by jumping ahead to the topic of anti-virus technology, covered in much more detail in Part II of this book. In particular, we must distinguish between detection and identification. Virus-specific scanners detect and identify known viruses, and, where appropriate, remove them. Some products may be able to detect some unknown viruses, but they don't detect the presence of all unknown viruses. Generic products may detect (or block without detecting) all viruses (known and unknown), or at least all viruses in a certain class. However, they don't identify them. This has two major implications. Firstly, 100 percent correct detection of all unknown viruses is not compatible with zero percent incorrect identification of all non-viruses: that is, some non-viruses will be incorrectly identified as viruses. Secondly, what you can disinfect is limited by what you can identify. If you conclude from this that detecting viruses is only part of the solution of virus management, we will not disagree. But more of that later.
First, we must look at what computers are and what they do - briefly, and at a level of abstraction that most computer users don't normally need to consider. The functions that we ask of computers tend to fall into a number of general categories, including copying, automatic operation, and "decision" making.
Computers are great at copying. This makes them useful for storing and communicating data and for much of the "information processing" that we ask them to do, such as word processing. Computers are also great for the automation of repetitive tasks. Programming allows computers to perform the same tasks, in the same way, with only one initiating call. Indeed, we can, on occasion, eliminate the need for the call to be initiated by the computer user, as programs can be designed to use available data to make "decisions" without user intervention. Finally, computer processors need not be specially built for each task assigned to them: computers are multipurpose tools that can do as many jobs as there are programs available to them.
All computer operations and programs are comprised of these main components. All computer operations and programs, in various combinations, can also fulfil many more specific functions. It is no coincidence that it is these same functions that allow computer viral programs to operate.
The first and defining function of a viral program is to reproduce - in other words, to copy. This copying operation must be automatic, since the operator is not an actively informed party to the function. In most cases, the viral program must come to some decision about when and whether to infect a program or disk, or when to deliver a payload. All of these operations must be performed regardless of the intended purpose of the specific computer.
It should thus be clear that computer viral programs use the most basic of computer functions and operations. It should also be clear that no additional, unique functions are necessary for the operation of viral programs. Not only is it extremely difficult to differentiate computer viral programs from valid programs, but there can be no single identifying feature that can be used for such distinction. Without running the program, or simulating its operation, there is no way to say that this program is viral and that one is valid.
These difficulties in identification also indicate that it is very hard to defend against intrusion by viral programs. If you want guaranteed protection, you can follow Jeff Richards' Laws of Data Security:
On the other hand, as is often said, "a ship in a harbour is safe, but that is not what ships are built for". A completely protected computer is safe, but it is not useful. A computer in operation is a useful device, but it is vulnerable. The prudent operator will learn the reality and extent of the dangers and will take appropriate precautions, while still taking advantage of the uses of the machine. Tools such as Word and Outlook are very attractive to users because of the wide range of functionality they offer. However, the security community has had to accept, grudgingly, the axiom that "if the choice is between functionality and security, functionality will win out". Unfortunately, the way in which functionality is extended in these products has the negative side-effect of reducing security.
Furthermore, as we have noted in Chapter 2, Fred Cohen proved that there is no absolute means of identifying an unknown virus on sight. Don't look for the Holy Grail or Silver Bullet of anti-virus protection. You, and your customers, are going to have to keep your eyes open.
However, if you pay due attention to where and how viruses act, you stand a far better chance of spotting a possibly malicious anomaly.
We must address the technical definition of the difference between viruses. Because it is so very hard to determine even what a virus is, researchers have agreed that two viruses are different if, when infecting the same object under the same circumstances, they differ by as much as a single bit.
NOTE
An exact definition runs along the lines of "two viruses are different if they differ, even by a single bit, in their constant code and data areas" (Vesselin Bontchev, Methodology of Computer Anti-Virus Research; University of Hamburg, 1998). However, researchers also generally agree that this definition isn't entirely useful under all circumstances. The change of a single hit may create a serious difference between the behaviour of two viruses, whereas major changes to the content of the viral code may entail no behavioural changes. (Some viral programs use this fact as a means of concealment.) Nor does differentiation between two samples necessarily affect the way in which they are detected or even disinfected by a known-virus scanner.
Under this definition, there are generally agreed to be tens of thousands of computer viruses: around 60,000 as this book was written, and possibly close to 100,000 by the time it is published. If we didn't include the proviso about infecting under the same circumstances, the number would range into the billions, since polymorphic viruses present themselves in many different ways, depending upon such circumstances as encoding keys. However, subsequent instances of a polymorphic (shape-changing) virus are not variants, since they originate from exactly the same program.
It is also agreed that most viruses can be grouped into families, and that they have major similarities within families. In some cases, all that is changed between one variant and another is some text message, which has no bearing on how the virus is programmed or operates. One virus, for example, contains the text "Legalise Marijuana" buried within it. A variant in the same family has simply had the spelling changed to read "Legalize". Other changes can be more significant, of course. Nonetheless, experienced researchers can point out similarities between different viruses. In some cases, they may be able to say when one virus derives directly from another, which was the original and which the derivative version, and whether the changes were made by the original programmer.
As we hinted in Chapter 1, the number of detected viruses claimed by anti-virus vendors is seriously suspect. Apart from the difficulties previously described, this number reflects a difference in the way virus variants have been counted by anti-virus vendors playing the "numbers game". In 1998, anti-virus researchers received a CD containing around 14,000 "new" viruses. However, they were kit viruses, generated by a construction program. Previously, kit viruses were not counted as individual viruses, since they can be detected by a "generic" driver or definition, and don't require individual detection for each created virus. However, one vendor chose to claim them as 14,000 new viruses. Other vendors protested, but followed suit, anticipating loss of market share if they were perceived as less successful at detecting overall numbers of viruses. Moral: the number of viruses claimed by a given product is mostly a marketing issue, not statistical.
NOTE
Peter Morley's article 'The Biggie" (Virus Bulletin, November 1998) gives more information on this incident of inflated claims. Paul Ducklin's conference paper "Counting Viruses" explores the issues that complicate attempts to standardize virus-counting metrics (Virus Bulletin 1999 Conference Proceedings). We describe kit viruses in more detail later in this chapter, in the "Generators" section.
Of greater significance is the fact that not all viruses are equally successful in spreading, or even reproduce as intended. Therefore, the tens of thousands of viruses that exist reduce to a few hundred that have actually made an impact in the real world of computers and users. These viruses are said to be "in the wild", in the same sense that animals in the wild run free and unchecked. As we've already indicated in Chapter 2, however, the question of "wildness" is far less straightforward than is implied by that simple definition.
Distinctions must be made between different animals (and viruses) that are in the wild. In the animal kingdom, there are thousands of viable species (that is, species that aren't on the verge of extinction, although, as human beings, we seem to be trying to reduce that total on an ongoing basis). Some are regularly seen even in cities (pigeons, rats, cockroaches); some are only seen by people who visit zoos or spend time in the native habitats of those species; some are never seen except, perhaps, by their Creator. The virus situation is somewhat similar.
A comparatively small number of viruses is known to be commonly found wild, though not necessarily in all parts of the globe. These are carefully classified, and sightings are confirmed by the WildList Organization.
There are viruses known to be wild, according to Paul Ducklin's definition in Chapter 1 ("spreading as a result of normal day-to-day operations on and between the computers of unsuspecting users"), but not so carefully classified or reported. The WildList is not a complete list of all viruses in the wild, for geographical and chronological reasons - not all regions are well served by WildList reporters, and viruses are in the wild before they are verified and make the WildList. At the other end of the chronological scale, viruses become, in some sense, extinct. Sometimes the virus is, in itself, time-limited and ceases to spread and/or trigger accordingly. Sometimes the environment that enables it to spread declines in popularity, or is modified so that it becomes more hostile to a given virus or class of viruses. Nonetheless, viruses that are no longer formally in the wild may still exist somewhere, on an unchecked floppy disk or a VX web site.
Finally, there are viruses in zoos (viruses that exist as source code, or as samples in electronic magazines, or on web sites, or in collections, but that are never seen spreading between the desktops of unknowing computer users), and their number exceeds that of feral viruses by tens of thousands (unlike animal species, which are much more numerous in the wild).
It is possible, perhaps, that the number of zoo viruses represents the tip of a much larger iceberg. Given that replication is the whole point of a virus's existence, though, this seems unlikely. No doubt there are viruses that are known only to their creators. However, given the vanity and craving for attention that characterizes so many virus writers, we doubt that such viral programs exist in large quantities. Does this mean that you only need to worry about a handful of viruses? Unfortunately, the answer is no. Unlike extinct species of animals, computer viruses can be resurrected at any time. Even time-limited examples can be given a new lease on life simply by turning back the system clock. In addition, many successful viruses target, and can turn off, anti-virus protection. Once that happens, you are subject to attack by many of the less-successful programs, should they somehow find their way onto such a system. The most usual justification for including detection of all known viruses, though, is that we never know when a zoo virus might "get lucky" and find its way into the wild. We will discuss this more fully in Part II.
NOTE
Increasingly, anti-virus researchers are coming round to the idea that adding detection for every virus as it appears may be counter-productive. Joe Wells's paper on the subject, found at http://www.warlabs.com/journal/v1_i1/oldschool.html, may seem an extreme statement at present. Its assertion that "the more viruses an anti-virus product detects the worse it is" is somewhat against the flow, but rather persuasive. Less contentiously, David Harley has suggested a number of times that an anti-virus product that offered scanning for zoo viruses as an option, rather than as a default, might make itself quite a few friends. However, that's an argument we'll consider when we discuss the evaluation of anti-virus software in Chapter 9.
You will note that we have already spoken of viruses, worms, Trojan horses, and other forms of malware. Researchers frequently use malware as the term for all classes of malicious software, or programs that are designed with a malicious intent, as opposed to merely being poor implementations of legitimate software.
Vendors of anti-virus software do not always agree on what should be detected and reported to the user.
Most anti-virus programs of the scanning type detect both viruses and worms. After all, even those who don't consider worms to be a special case of virus consider both classes of malware to be primarily self-reproducing programs. However, some anti-virus programs are unable to examine all the types of objects that worms can affect but that viruses cannot. In this case, the decision to exclude certain types of malware depends on a technicality.
In other cases, the decision is made on a psychological basis. Should anti-virus programs, intended to detect programs that reproduce, report the existence of Trojans, which cannot?
NOTE
Sometimes modern worm/virus hybrids are defined as Trojans because they rely on tricking the recipient of infected email into opening an attachment. We understand this viewpoint, but prefer to define such programs according to their replicative function. Indeed, Ian Whalley ("Talking Trojan", Virus Bulletin, June 1998) has suggested abandoning the term Trojan altogether in favour of the less catchy (but also less ambiguous) non-replicative malware. The term malware is sometimes used specifically in the context of non-replicative malicious software, especially Trojans. We prefer to avoid this usage: if we do use the term in this sense, we will qualify it as "non-replicative" in accordance with Whalley's suggestion.
There is already enough confusion between the different types of malicious software: should an anti-virus program add to the problem, on the basis that it should try to report on any security problem? And, if that is the case, should anti-virus software try to report on intrusion detection, and other tenuously connected security issues? In general, anti-virus software reports (more or less) all viruses known to it and a selection of known Trojans. Many programs also report some ambiguous objects, such as remote-access tools and DDoS agents (both of which we will consider at length later in this chapter, but which could be described as Trojans or Trojan-like).
An even more difficult decision arises in the case of prank or joke programs. If a user is running an anti-virus program and suddenly crabs start running around the windows and "eating" the screen, will the user lose faith in the anti-virus software and stop using it? Obviously some vendors think so, since they alert on joke programs, such as CokeGift (Geschenk), which does nothing more sinister than offer the "victim" the computer's CD tray as a holder for canned soft drinks. On the other hand, if anti-virus software reports the existence of a joke program, will the user panic, even when the message clearly states that the file is only a prank? Probably we will only know the answer to this when scanners stop reporting jokes with confusing messages such as "!! IFile myjoke.exe is infected with the virus W95.Joke.MyJoke", or "Virus Myjoke.exe is not a virus". These examples are fictitious, but they are no sillier than messages put up by real anti-virus software. Anti-virus scanners detect joke programs because corporate customers wish to detect time-wasting, and because some jokes mislead the victim into believing that they are real Trojans or viruses. However, other vendors choose not to detect such programs.
Nonetheless, jokes are no joke. While working on this chapter, David Harley became aware of email with the Bearded Trojan attached sent to one of his customers. Bearded does no intentional damage to files or file systems: it changes the Windows desktop to a graphic of a female nude. Potentially offensive or embarrassing, but not, you might think, exactly dangerous. However, in the environment in which the mail was received, a policy is in force forbidding the use of company resources for non-business use, especially where there is a suggestion of pornography. Damage to file systems is by no means the only possible destructive consequence of malware.
Computer viral programs are not a "natural" occurrence. Viruses are programs written by programmers. They do not just appear through some kind of electronic evolution. Viral programs are written, deliberately, by people. (Having studied the beasts almost from their inception, Rob Slade was rather startled when a young, intelligent, well-educated executive proposed to him that viruses had somehow "just grown" like their biological counterparts.)
NOTE
There are, for instance, many hundreds of variants of some Word 6.0 macro infectors that are all "spontaneous" mutations of the original code, which in no sense came into being "accidentally". It is widely accepted, however, that macro viruses have proven to be highly susceptible to mutation and corruption by such factors as the accidental capture of legitimate macros and unrelated viral macros, and incomplete disinfection by anti-virus products.
Most people are now aware of the term "computer virus" even if they don't use computers. However, it is often the case that those who are otherwise technically literate do not understand some of the implications of the name. A virus is an entity that uses the resources of the host to spread and reproduce itself, usually without informed operator action. Let us stress here the word "informed". A virus cannot run completely of its own volition. The computer user must always take some action, even if it is only to turn the computer on. This is the major strength of a virus: it uses normal computer operations to do its dirty work, and so there is no single unique characteristic that can be used to identify a previously unknown viral program.
NOTE
We have stated that covert action is not a defining characteristic of a virus. A few viruses have asked permission before infecting. (They don't seem to have heen particularly successful in terms of widespread propagation.)
Fred Cohen was the first to formally define the virus phenomenon. His original definition covers only those sections of code that, when active, attach themselves to other programs. This definition is sometimes thought to neglect many of the programs that have been most successful in the wild, such as boot-sector infecting viruses and macro viruses. Some people still insist on a strict interpretation of Cohen's definition and use other terms, such as worm and bacterium, for those viral programs that do not attach themselves directly to programs (though Cohen himself described worms as a "special case" of virus). Most, however, agree that a virus is any program that attaches in some way to an object that contains, or has the reasonable potential to contain, other programming. This definition allows us to include boot-sector viruses (since boot sectors generally do contain a program), but also macro viruses, which infect an object that at the time of infection often contains no code.
The term worm has become more widely used (not always correctly) in relation to network and email related programs. Do you think we overstate the problem of getting people to agree on a definition of what a virus is? If you have a few spare years, you can have some fun by getting together a group of academically oriented computer people, and asking them to agree on a formal definition of what a "program" is.
If one program is a virus, what are two of them called? Given that the term is still in the realm of slang, this debate has been the longest, silliest, and most bitter debate in the whole field of computer virus research. Various linguistic "experts" have called for virae, vira, viri, virii, viren, and virides. The correct plural in biology for virus has always been viruses, and that is, in fact, the most common usage among computer virus researchers. Virus authors, distributors, and collectors tend to prefer virii, though there is no etymological basis for that particular plural form. Although the word virus was normally used in the singular in Latin (as a mass noun meaning poison), the plural viri seems to have been used occasionally, though inviting confusion with the plural of vir (man). We are not aware that this usage has ever been found in biology. Viren is probably imported from the German. Robert Slade's personal favourite, however, is the suggestion that it is one virus, two virii, three viriii, four viriv... Viriiii might be more appropriate for computer-using clockmakers, who usually use IIII rather than IV on clock faces. A tip of the hat goes to Ed Fenton for drawing our attention to that horological quirk.
Viral programs cannot be considered a joke. Many may have been written as pranks, but even those that were not intended to do any damage have had bugs. The original author of Stoned knew nothing of certain drive specifications, and yet the virus causes unintended damage to some disk formats. It appears that the trashing of data by the Ogre/Disk Killer virus, one of the most damaging viruses, was originally intended to be reversible, but is not, thanks to an error on the part of the programmer. Any program that makes changes to the computer system without the knowledge of the user can cause problems, the more so when the program is designed to keep spreading those changes to other systems. Form is a fairly trivial boot-sector virus that caused no significant damage to systems when it was written, a fact that no doubt has a bearing on its continued survival in the field, many years after. However, because it infects the DOS boot record rather than the partition sector, it can, unlike most boot-sector infectors, prevent a PC running Windows NT - an operating system that didn't exist at that time - from booting.
NOTE
This doesn't let the author of Form off any hooks, though. Even at the end of the 1980s, not all PCs were running versions of MS-DOS or PC-DOS. Any virus writer who says, "I don't know what the effects of this virus will be on all the systems it might infect..." is also saying "...and I don't care". Of course, no programmer can claim to know that their program will work properly on every possible system, but honourable programmers offer support when trouble occurs. In fairness, it's not unknown for a virus author to offer some help to someone accidentally infected or sustaining unanticipated damage as a result of infection.
As noted in Chapter 2, there are many variant meanings proposed for the term worm. However, most virus researchers now accept (sometimes reluctantly) the term as applied to a viral or reproductive program that copies and spreads itself without associating with a particular host program. More specifically, a worm usually spreads over network links from one machine to another.
Worms have been around since the beginning of the virus plague in the wild. CHRISTMA EXEC and the Morris Internet Worm are two examples. More recently, there have been the mail storms associated with Melissa and the Love Bug. Note that there are technical differences between some first-generation worms, not all of which require user intervention to spread, and more recent worms, which usually rely on some form of social engineering to trick the victim into running them.
Worms generally spread extremely rapidly, and the modern examples are challenging the traditional models of virus spread. Because of the explosive nature of worms, they have caught the attention and imagination of the news media. Therefore, when non-specialists think of viruses, they are often thinking in terms of what may be better described as worms.
Carey Nachenberg has suggested a classification scheme for worms along the following lines ("Computer Parasitology", Ninth International Virus Bulletin Conference Proceedings, 1999).
By transport mechanism:
By launching mechanism:
Aside from the rapidity of their spread and some specifics about detection (many worms are easily detected at the mail gateway even without virus-specific software), the differences between worms and viruses are slightly academic. From the perspective of the average user or systems administrator, worms and viruses can generally be considered together.
When speaking publicly on the virus problem, we are frequently asked what our favourite viruses are. (From our perspective, this is a curious question, along the lines of "What way would you most like to be tortured to death?") When Rob Slade first encountered the question, he replied that his favourite virus was Pentagon. Why Pentagon? Simple. It doesn't reproduce. It doesn't work. Many programs were intended to be viruses, but fail to qualify. All virus collections contain programs that were obviously supposed to reproduce, but don't. Some researchers carefully weed them out of their collections, but most vendors feel they have to detect non-viruses because they are in other collections. Since software reviewers often use badly maintained collections to test anti-virus software, vendors are obliged to detect objects they know to be harmless. The alternative is to be penalized while less scrupulously constructed products earn the Editor's Choice awards.
Virus programmers include some of the sloppiest coders in the world (and, given the state of many legitimate programs we've had to use, review, or support, that is saying a great deal). In some viruses, the payload never triggers, although failure of the payload doesn't disqualify them as viruses. In some attempted viruses, the reproductive function never triggers. Sometimes the infective mechanism triggers but fails to attach the infective code to the host program. In other cases, the virus may attach to the host program, but in such a way that the code is never executed. Programs that match this last case are normally categorized as intended viruses, or just as intendeds (much to the irritation of the authors' spellcheckers). We must distinguish here between attempted viruses that fail to reproduce unto the third and fourth generation, and viruses that fail to reproduce under some circumstances. For example, a VBA virus that flourishes on PCs running Office 97 but fails to replicate beyond the global template on a Mac running Office 98 is not an intended. It is a virus, but one that is not viable on all of the same platforms as its host application.
On occasion, of course, the code is so badly messed up that you simply have no idea what the author was trying to do. Usually, though, it is not difficult to see what was intended, and where it went wrong. In one virus, it is readily apparent that the programmer wanted the damaging payload to trigger on Sundays. The virus waits for the seventh day of the week. And waits. And waits. Computers start counting at zero (unless they're told otherwise), and DOS's Get Date function returns a value between 0 and 6, not 1 and 7. Furthermore, it returns a value of 0 for Sunday, not 6. Do you still believe that virus writers are programming geniuses?
Of course, sometimes the errors don't work out to anyone's advantage. Some mistakes create more serious problems. The Michelangelo destructive payload may have been intended to overwrite the whole hard disk. Instead, it reportedly sticks in an infinite loop (not to be confused with the "nth complexity binary loop" associated with the Good Times hoax): however, that doesn't work to anyone's advantage, either. The Morris Worm was obviously intended to be a slow infector, except that Morris inverted two factors. Instead of sending out a copy of itself every once in a while, it exploded, and drew attention to itself by bringing down systems with sheer overload.
Intendeds may be a failure to meet the programmer's actual purpose, but it is common for a viable virus to become corrupted as it spreads from system to system. In this instance, the virus is modified under circumstances the virus author didn't or couldn't anticipate, or didn't bother to allow for. Since such modifications are accidental, they rarely offer a Darwinian "improvement" to the viability of the virus, but they don't always prevent it from replicating either. This is particularly (not exclusively) characteristic of macro viruses. The original virus (or rather, a later instance of the virus) is modified by some transient system glitch. Causes may include inadequate disinfection (this happened frequently in the early days of macro-virus detection), picking up legitimate macros from an infected machine, or losing one or more component macros. Anti-virus programs normally detect known instances of corrupted viruses, just as they do intended viruses.
Corrupted non-viral programs may also find their way into poorly maintained virus collections, perhaps because someone assumed that they were corrupt because they'd been infected by an unknown virus. Anti-virus programs may detect corrupted non-viral programs and other non-viral objects (even text files) known to exist in widely available virus collections, for the reasons already discussed. That is, to avoid being penalized by incompetent testers in comparative reviews.
This is a rarely used term for an infrequently met phenomenon. A germ is a first-generation virus - an instance of a virus that hasn't yet infected anything - and it is not generated by the normal process of infection. A germ is, that is, the original infective object (or an exact copy) created by the virus author, or by someone with access to the original source code. For instance, a file virus that has not yet infected a program may exist as only the virus code. Again, we must distinguish between germs and droppers (discussed next), both of which are different from worms that "infect" by spreading copies of the original, which don't attach to a host file. Germs are most likely to be found in collections and are detected by anti-virus software for that reason. A germ cannot meaningfully be described as being in the wild.
A dropper is not itself a virus, but a program written expressly to install a virus, especially a boot-sector virus. We do not describe a virus-infected program as a dropper, since the program was not written specifically for the purpose. What if a dropper program is infected with another virus? The answer depends on the context. If the program was written to install virus A and only virus A, then it remains a dropper, even when infected with virus B. However, it is still not a dropper for virus B. Confused? You should be.
A dropper may be designed as a sort of Trojan, though in this case the term injector is sometimes preferred. The victim is tricked into running a program that does not, itself, replicate, but that has a malicious payload. Red Team has been described in these terms. However, droppers have often been intended as a convenient means of transport, most commonly of boot-sector viruses, rather than as a means of covert introduction to a system.
It's often said that boot sector viruses cannot infect across networks, which is more-or-less accurate. However, they can be transported across networks, either by a dropper or as a binary image of an infected disk. BSIs (boot-sector infectors) are examined in more detail later in Chapter 5. Initially a dropper would have been used to spread boot-sector viruses via online systems. A BSI dropper would place the virus in active memory, thus allowing it to infect the hard disk, and subsequently spread via disk sharing.
Anti-virus software detects known germs, droppers, and injectors because of their possible use as Trojans, and, of course, because they're found in collections.
Quite early on in the development of anti-virus technology, customers wanted to test whether their anti-virus programs were installed and working properly. Some vendors introduced detection of test "viruses" into their software. Such programs were not viruses (they didn't replicate), but they contained an arbitrary string (sequence of characters) that triggered an alert similar (but not always identical) to that triggered by real viruses. Originally, each vendor who adopted this approach used a product-specific test string and instructed customers on how to use it in a test file. This was considered preferable to supplying the test virus as a ready-made file that would trigger an alert at inconvenient times. Later, this approach was consolidated into the EICAR test-string. This is a sequence of ASCII characters that can be typed into a file with a text editor, but that constitutes a stand-alone DOS program that will be recognized by most anti-virus products as a "test virus". The EICAR test string is:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Running the file displays the text
EICAR-STANDARD-ANTIVIRUS-TEST-FILE!
In the meantime, some individuals produced "neutered" versions of real viruses, or even "harmless" real viruses, for similar purposes; however, most virus experts loathe this approach, and we'll explore the reasons for that in some detail in Chapter 9. (We'll also examine the use of the EICAR test string more closely.) Nonetheless, simulated viruses are often detected by anti-virus programs, since the vendors are aware that their products are liable to be tested against such simulations.
In the early 1990s, some virus writers started producing virus creation kits, or generators. These programs allow you to create viruses, simply by selecting the functions you want from a menu. No programming skills needed. Now you, too, can create a destructive menace. Equal-opportunity vandalism.
In reality, of course, all that was happening was that certain pre-programmed modules were being added together. No new virus could be produced by the generators, since the user was simply connecting existing bits together. For example, the Virus Creation Laboratory (VCL) could not create a macro virus because macro viruses hadn't been invented when this generator was developed. (There have been macro-virus kits since, but they have made little real impact.) In fact, VCL wasn't that good at creating file viruses: many of the attempted viruses it created were not viable.
A number of virus kits exist, especially for the creation of DOS file infectors and macro infectors, but they have never made much of a splash. Given a finite set of modules, the kit could only produce a finite set of viruses. In fact, it was rather easy to detect any virus produced from the generators, since every module was detectable by scanning for a search string. Therefore, even "new" viruses generated from the lab could be detected before they were created. For example, some scanners detected the Kournikova virus at first sight, using a generic driver or advanced heuristics, though it took others a little while to catch up. In short, even the competent generators don't merit the superstitious fear they sometimes inspire.
At an EICAR conference in 1999, a vendor representative was heard to whimper, "This is anti-virus software, not anti-Trojan software". Anti-virus vendors have good reason for wishing they'd kept out of the Trojan arena from the beginning: the species presents considerable difficulties, not least of definition.
Trojan horses are often described as programs that pretend to do one thing while performing another unadvertised and unwanted action. Common modern usage is to describe them as non-replicating malware, or as programs with a payload but no automatic replication mechanism.
This description is useful for distinguishing between viruses and Trojans, but it depends on an implicit assumption of malicious intent. How do we detect an unknown virus? We can't say for sure that a program is replicative algorithmically, but we can do a test run, as heuristic engines do. How do we detect an unknown Trojan? Not by trial and failure. If we know that a program formats a hard disk, that tells us nothing about the author's intent, malicious or otherwise - it could be a Trojan, or it could be a systems utility. It could even be a systems utility that has been trojanized (the term trojaned is sometimes used) by describing it as doing something quite different from disk formatting. However, examining the file or stepping through the code only tells us that it formats a disk. It doesn't tell us anything about the author's intent, the supplier's intent, or the recipient's expectations.
NOTE
Trojans are sometimes defined, according to the action they perform, as destructive or password-stealing. However, it's common for the same program to attempt both actions. Indeed, an attack intended to gain unauthorized access or disclosure might well cause some destruction with the intention of covering the intruder's tracks. Destructive Trojans range from simple batch files, shell scripts, IRC scripts, and the like, that call a system command such as rm or format, to more sophisticated compiled programs. Their basic modus operandi, however, tends to be simple and immediate destruction. Password stealers are more accurately regarded as a subset of a whole range of privacy-invasive threats, concerned with stealing access rather than direct destruction. They include AOL password stealers, backdoor Trojans, Remote Access Tools, and rootkits, all of which are considered in the following sections.
Viruses and worms are sometimes described as "special cases" of Trojans. This is defensible: you can describe a virus-infected object as being in some sense trojanized. However, we prefer to distinguish between viruses and Trojans according to their ability to replicate, as it seems less confusing. Worms still constitute a problem: self-launching worms might be considered truly auto-replicative, but most modern worms rely on tricking a victim into running a program that installs the worm or virus and triggers the mechanism for mailing it on. Some sources, including anti-virus vendors, therefore equate worms and Trojans. Even worse, some malware can be described as being in some sense multipartite, combining a virus, a worm, and a Trojan (MTX has been described in these terms). We suspect that most readers will be less concerned with these niceties than with the practical issues of defending against all these threats, so we will observe that the terminological problem exists, rather than try to solve it.
We don't consider Easter Eggs (harmless code concealed in production software by the original production team) as Trojans here. This is not necessarily because we like the idea of having a flight simulator concealed in our spreadsheet applications, but because anti-virus software doesn't usually target such things.
Joke programs are considered separately in this and the following chapters. Installation routines and other programs that pass back information to the manufacturer without the knowledge of the user might be considered Trojans, and we sometimes see security alerts concerning such phenomena, but they aren't usually detected by anti-virus software. Accidental Trojans were touched upon in Chapter 1, and the concept is not explored further here (mainly because anti-virus software doesn't usually detect them).
Trojan programs used to be spread almost entirely via public-access electronic bulletin board systems (BBSs). Obviously, a damaging program that can be identified is unlikely to be distributed through a medium in which the donor can be held to account. Some BBSs were hangouts for software pirates, and acted as distribution points for security-breaking tips and utilities. Pirate BBS systems have now been replaced by a variety of (generally short-lived) web sites and FTP download archives ("warez servers"). These sites are usually killed as soon as system managers find them, but given the ease of establishing personal web pages, a few dozen may be in operation on any given day.
Did you know that there is a flight simulator concealed in Microsoft Excel 97? To access this game use the following (presented by Larry Werring in the RISKS-FORUM Digest mailing list, edition 19.53 on 5th January, 1998):
We're not going to go into detail about how to run the game. If you want, you can play with it yourself. The point is, what is a game doing inside the spreadsheet program? There is no reason for the inclusion of this code, even granted the opinion that software bloat is not always a bad thing. But this game, the code for it, the graphics, and other extraneous pieces, are taking up space on millions of computers. Most users of those computers have no idea the function is there.
This says something about quality control at Microsoft. Here is an undocumented feature, and a rather large one, coming out of a widely used office product. However, Microsoft is not the only company at fault. You can find a large number of such concealed functions at various web sites, including the following:
However, this also says something about security. Take another look at those instructions. Think anybody would be likely to do all this in the course of a day's work? But with millions of curious computer users out there, even this type of sequence is going to be found out. Which means that any kind of security bug, no matter how deeply buried, is eventually going to be found. Probably by the wrong people first.
The original tie-in of Trojan and pirate software has led to confusion between Trojan programs, viral programs, and system crackers, and this false association has proven extremely resistant to correction. It has also led to a view of BBSs, and, by extension, all download sites, as distribution points for viral programs. (One paper's computer columnist, normally better versed than this, dismissed the availability of anti-virus software to combat Michelangelo by saying that no self-respecting company would ever use a BBS.) This bias continued to survive for many years, in spite of the fact that the most successful viral programs at the time, boot-sector viruses, could not be transmitted over BBS systems in normal use.
We have suggested that Trojans normally include an element of pretence, or social engineering. The extent of the pretence may vary greatly. Many of the early PC Trojans relied merely on a deceptive filename and description on a bulletin board. Login Trojans, popular among university students in mainframe days, mimicked the screen display and the prompts of the normal login program. They often passed the username and password along to the valid login program at the same time as they captured the user data. Other Trojans may or may not contain actual code that does what the Trojan is supposed to do, while performing additional and unpleasant acts that the victim does not expect. Many distinguish between Trojans and joke or prank programs on the basis that Trojans are always malicious. As we shall see, however, this distinction is sometimes rather fuzzy.
One oft-quoted example of a Trojan is 1989's AIDS Information Diskette, often incorrectly identified in both the general and computer-trade press as a virus. Not to be confused with the fairly rare AIDS I and II computer viruses, the AIDS trojan program appears to have been part of a well-organized extortion attempt, as discussed in Chapter 2. The "evaluation disks" were shipped to medical organizations in England and Europe with covers, documentation, and licence agreements, just like any real commercial product. When installed and run, the program did give information and an evaluation of the subject's risk of getting AIDS. However, it also modified the boot sequence so that after 90 reboots of the computer, all files on the disk were encrypted. The user was informed that, in order to get the decryption key, a "licence fee" had to be paid.
Trojan horse programs, especially destructive Trojans, are sometimes referred to as Arf, Arf or Gotcha programs. The phrases are taken from the screen messages presented by one of the first examples, distributed as a program that would enable graphics on early TTL monitors. This would have been quite a feat, if it had actually been possible. Instead, it presented its message and erased the contents of the hard drive.
While a Trojan without a payload would be a sorry piece of malware, that payload doesn't have to include sheer destruction. It might, for instance, entail data leakage without direct harm to the original data.
Versions have been written for microcomputers as well, appearing to be network login screens. A number of these have also been designed for the World Wide Web, pretending to be a popular web site in order to steal passwords for that site. In recent years, it has become common to distinguish password stealers as a separate class of malware so that some software is specified as detecting both Trojans (that is, destructive Trojans) and password stealers.
Not all password stealers use fake login screens: some use simple social engineering. The most prominent examples of this group are AOL password stealers, many hundreds of which have been reported. Some anti-virus software detects these routinely, not only by signature recognition, but also heuristically. However, the simplest heuristic works well in this context. If anyone from any company or system that you legitimately use sends an email message asking for a username and password, they almost certainly are not entitled to it. System administrators normally have privileges beyond those accorded to other system users, and they are able to do any work they need to do on another user's account without needing to know that user's password.
One of the factors involved in the success of malicious programs is a study of the mindset of the user - a study of the psychology or sociology of the computer community. Since the spread of viral programs usually requires some activity, however innocent in appearance, from the operator, looking at the security-breaking aspects of other programs can give us some insights.
Password stealers simulating a login program may send back a message to the user that the login has been denied. Most users will accept this as an indication that they have either made a mistake in entering the login data or that there is some unknown fault in the system. Few users question the message, even after repeated refusals. Some programs are sophisticated enough to pass the login information on to another spawned process: few users know to check the level of nesting of processes.
This type of activity has recently been repeated in less innocuous fashion. Criminals have been known to build false fronts for automated teller machines at banks. These devices fit over the regular machines and are similar in appearance. The false fronts will accept cards, prompt for the holder's personal identity number (PIN), and then give a message about some problem and a suggestion to contact the bank in the morning. After a few hours, the crooks collect the device, remove the cards, read the stored PINs, and spend a few hours extracting as much cash as possible at legitimate bank machines using the cards and access codes thus collected. Clearly, this isn't a problem that anti-virus vendors can be expected to do much about.
Backdoor or trapdoor are terms normally used to describe a means of accessing a system with privileges higher than those normally granted to ordinary users. It's not uncommon, for example, to use such a privileged account during system or program development: sometimes it is left in production software, deliberately or otherwise. It would be unusual for anti-virus software to detect such a security breach. More recently, however, the term has been used in the context of backdoor Trojans, which we consider at length in the "Remote-Access Tools (RATs)" section later in this chapter.
A famous, if relatively harmless, prank in earlier computers was the cookie program which ran on PDP series computers. This program would halt the operation in progress and present a message requesting a cookie.
Despite the fact that this program became rather widely known as a joke, it is often reported in security books as a virus. The original cookie program had no reproductive functions, however. It barely even qualifies as a Trojan, although it could certainly be regarded as a nuisance.
NOTE
The cookies in this case were strictly virtual and had nothing to do with the "cookies" used by web sites to track visitors. The latter type of cookie is accused from time to time of being a security risk. In fact, such cookies are little globs of data rather than code: even if they contained a program (malicious or otherwise), it is hard to see how that program could actually be executed. There are, certainly, privacy issues associated with web cookies; however, these are not really in the scope of this chapter.
There were consistent reports of viral programs following this pattern, including a very detailed report of a Spanish Cookie virus. None of us has ever seen this virus, although one of us has been assured that it really exists. There have been commercially produced joke packages offering "Stupid Mac (or PC) Tricks". There are countless pranks available as shareware or freeware. Some make the computer appear to insult the user; some use sound effects or voices; some use special visual effects. A common characteristic of such pranks is that the computer is, in some way, apparently non-functional. Many pretend to have detected some kind of fault in the computer (and some pretend to rectify such faults, of course making things worse). One such program in our own field was PARASCAN, the paranoid scanner. This reported large numbers of very strange viral programs, none of which, oddly, have ever appeared on the WildList.
It can be argued that, aside from temporary aberrations of heart rate and blood pressure, pranks do no damage, and that they can be distinguished from Trojans on that basis. However, some researchers refer to accidental Trojans, whose intent is non-malicious but whose effect is destructive.
At the same time, some joke programs are clearly meant to do psychological damage. Some use "gotcha" messages to trick the victim into believing that they have lost all their files. Furthermore, a victim may be prompted by such a message to take ill-advised action in an attempt to recover "lost" data or to stop data from being lost in the first place, resulting in actual damage. For instance, a panicking victim might lose data or even access to the system by hitting the reset button while the joke displays its symptoms. Most joke programs (and non-programs, such as virus hoaxes) are plainly meant to humiliate the victim when they realize that they've been duped, thus asserting the superiority of the joker or hoaxer.
UltraCool, for example, claims that "A LOW level Hard Disk format will precede [sic] in 27 seconds if cancel button is not pressed", but keeps moving the Cancel button away from the mouse cursor until the countdown reaches zero. (It then displays a "Just kidding..." message.)
Pranks have, in various ways, entered the realm of virus mythology. The PDP-series cookie prank, as noted, has given rise to all manner of reports of a cookie virus. There is also the crabs program. This initially ran on the Xerox Star system and was later ported to Apple and Atari systems. More of a screen saver than anything else, it was sometimes reported by careless security writers as a class of viral programs that attack video displays. A similar program in the MS-DOS world was BUGRES, which was reported as a virus by a major commercial anti-virus program. This is how pranks do most damage: in addition to causing time to be spent getting rid of a prank on a system, they tend to generate calls to researchers, and waste not only time, but bandwidth.
Joke programs have become a major cause of annoyance, even where there is no apparent malice intended. Thus arises the difficulty of deciding whether to alert the user to prank programs on the computer. A program like this doesn't do any harm, and so generating a warning might be considered a false alarm. On the other hand, anti-virus developers don't want to have to contend with a bunch of calls about a new virus every time somebody rediscovers BUGRES. Yet CokeGift probably holds the world record for protests to the industry from consultants and systems administrators who are called out to remove an essentially harmless program from PCs when anti-virus software has reported infection by the "Joke/CokeGift Virus" or some similarly misleading message.
Some vendors decline to detect jokes like this as a matter of policy. Others detect jokes because "they may frighten victims" or "to discourage the promiscuous exchange of executable programs". A few offer a choice, and some are even considering modifying their alert messages, by not describing non-viruses as viruses, in order to reduce the Panic Factor. We recommend that you find out, before you deploy anti-virus software, whether the package detects pranks or not. Alert users to the fact that scanners can find joke software, and tell them to read the screen messages carefully.
Anti-virus vendor web sites are seriously inconsistent about the information they offer on jokes, and there is no standard nomenclature or reporting mechanism for such software. If you feel the need to research this topic further, here are some resources:
WARNING
Use at your own risk! Apart from the annoyance caused by the way in which they are reported by some scanners, pranks have heen used to spread Trojans or viruses in the past.
A difficult subject to pin down is that of remote-control software. Some people would like to refer to the programs as remote-access Trojans, while the "developers" would rather have them called remote-access (or remote-administration) tools (RATs). A moment of thought will make the problem plain: all networking software can, in a sense, be considered to be remote-access tools. We have file transfer sites and clients, web servers and browsers, and terminal-emulation software that allows a microcomputer user to log on to a distant computer and use it as if he or she were on site.
Many remote-access programs are available commercially, ranging from simple file-copying utilities, such as LapLink, to full remote-operation packages, like PC Anywhere. The RATs considered to be in the malware camp tend to fall somewhere in the middle of the spectrum. Once a client, such as Back Orifice, is installed on the target computer, the controlling computer is able to obtain information about the victim system, such as which programs and processes are currently running, and what files and directories it contains. The master computer will be able to download files from, and upload files to, the target. The control computer will also be able to submit commands to the victim, allowing the distant operator to control a range of activities. This activity goes on without any alert being received by the owner or operator of the targeted system.
NOTE
The authors of some RAT programs assert that the software is not malicious. As "proof", they point out that such packages have valid uses. This is quite true. RAT programs can he used to support computers over a LAN and even over the Internet. When a user rings technical support, the support person can connect to the actual machine, and then gather information and diagnose and treat problems without having to rely on questionable data and actions from customers who may have very little computer knowledge. However, RAT programs are not necessarily configurable to prevent misuse of the remote-access capability, and they are designed in such a way that the malicious use of the software is quite easy and transparent to the victim. The authors of such programs have also been known to attempt to legitimize them by introducing a charge for the software. This reassures potential victims. It also allows the authors to complain about monopolistic security vendors impeding legitimate business interests if they advertise detection of such programs.
When a RAT program has been executed on a computer, it can install itself in such a way as to be active every time the computer is subsequently turned on. Information is sent back to the controlling computer noting that the system is active. The user of the command computer is then able to explore the target, escalate access to other resources requiring a higher level of privilege, and install other software, such as DDoS zombies, if so desired.
Once more, it should be noted that remote-access tools are not viral. When the software is active, though, the master computer can submit commands to send the installation program on, via network transfer or email, to other machines. These programs must be executed on the other machines, but a little social engineering via email can be enough to accomplish this.
A denial of service (DoS) attack generally does not attempt to crack security on a computer system or network. It tries to use up some resource, and thus deny that service to legitimate functions or users. For example, a massive spam (unsolicited email) or mail bomb attack might be considered a denial of service attack, because it ties up the network connection and also uses up great amounts of disk space for the mail queue. No security is broken, and no data are corrupted, but the computer system cannot be used for its intended purpose.
Other types of denial of service attacks might entail trying to log on to the target computer, thus using up processing time as the host tries to validate the requests. The most sophisticated of such attacks send network-control messages that request the host to contact some other machine to verify information. These requests must be honoured, because they are part of the dynamic configuration process of the Internet, but the DoS attacks use fake addresses, and therefore the host computers make repeated attempts to connect to computers that don't exist.
A distributed denial of service (DDoS) attack goes one step further. By sending out Trojan programs, crackers try to gain at least partial control of a number (possibly thousands) of computers. At the designated time, the master computer sends a very short command message to those computers running the Trojan server or agent software. Thus one computer starts and controls hundreds, thousands, or tens of thousands of computers, all sending some kind of DoS attack to a given target. One computer sending DoS packets to a huge site like Yahoo is nothing more than a nuisance. But with hundreds of computers participating, the effect is greatly magnified.
DDoS programs do not conform to commonly accepted definitions of the term virus, but anti-virus packages often detect them. At one point, DDoS was called a flood network attack, from the name given to the second program to employ the concept. The structure of a DDoS attack requires a master computer to control the attack, a target of the attack, and a number of computers in the middle that the master computer uses to generate the attack. These computers in between the master and the target are variously called agents or clients, but are usually referred to as running zombie programs.
So, do the attackers own hundreds of computers? By no means: however, by distributing Trojan programs, crackers try to gain at least partial control of many computers, which may number in the thousands or even tens of thousands. The zombie software is generally only a single program, which can be emailed to potential suckers or, preferably, is posted on USENET newsgroups with names such as Sheila_gets_undressed.exe. The zombie program, when run, installs itself on the computer and then notifies the master computer that another agent is in place. It usually also generates a spurious error message so that the user doesn't suspect anything when Sheila fails to perform as expected.
DDoS programs are not viral, and managing them is a systems issue, not just a desktop issue. Nevertheless, checking for zombie software not only helps to protect you and your system, but lowers the risk of attacks on others, as well. It is your responsibility and it is in your best interest to ensure that no zombie programs are active on any of your machines. If your computers are used to launch an assault on some other system, you could be liable for damages. In addition, although it is a very bad idea, some people talk about launching retaliatory strikes in the case of a DDoS attack.
Why is retaliation a bad idea? All of the DoS attack packets are being launched by zombie computers. The master computer never sends a packet directly to the target. Therefore, striking back will only ever hit zombie machines, which, aside from a little negligence, are probably all owned by completely innocent victims. In any case, computer security reprisals are generally a bad idea. Attacking anyone is likely to render you liable to prosecution or a lawsuit. Floods of mail storms, spam, and attack packets only use up bandwidth, reduce cooperation, and ultimately damage the networks that you are trying to use in the first place.
For more information on DDoS attacks and programs, you can look up information at any of these sites:
A rootkit is a suite of trojanized system applications that might be substituted for the untrojanized originals. Such programs can include monitoring utilities and system processes gimmicked so that they don't draw attention to illegitimate processes. They can also include utilities modified to enable an intruder to escalate account privileges or to hide other component files. They are mostly associated with UNIX, but examples have been reported for Windows NT. Anti-virus programs have not, until recently, routinely detected such programs (in general) but there's no absolute reason why they shouldn't. The recent upsurge of Linux worms that use social engineering and other techniques to persuade users to execute a program that installs a rootkit has ensured that vendors with a Linux product have begun to lead the way in the detection of such programs.
No, these aren't the virus hoaxes that we talked about in Chapter 2. The false alarms we are talking about here are programming and implementation bugs. We know it will come as a shock, but we have to tell you: anti-virus software is not perfect. When we discuss the evaluation of anti-virus software in Chapter 9, we will go into more detail about the two major problems: false positives and false negatives. For the moment, false positive alerts are what are commonly known as false alarms. That is, a virus is reported where none exists. A false negative is an instance of a virus not being reported where one does exist.
Known-virus scanners are the most popular type of anti-virus software, and they generally identify viruses by name and specific variant, although the latter is not always reported. Unfortunately, the only way to be absolutely sure that you have a specific virus is to have a complete copy of each of the tens of thousands of known viruses in a database that is accessed by the scanning program. (This is sometimes called exact identification.) Given the number of viruses and a rough estimate of the average size, such a database would probably require many hundreds of megabytes of disk space. Even that wouldn't be sufficient, though, since there are small changes to viruses depending on the object that they are infecting, which would entail multiple database entries. Polymorphic viruses might require thousands, even billions, of entries for each, just to be sure of finding every single match. Even for a large corporation, having this volume of data for anti-virus protection is unrealistic, and the processing overhead would be gigantic.
Developers of anti-virus software therefore take shortcuts. Or, to put it a little more kindly, all known-virus scanning is to some extent heuristic. Anti-virus researchers look for a reasonably short scan string that is unique to the virus and that does not appear in other software. Careful vendors will try to find more than one such string, and will also calculate a digital signature of the whole virus. However, every once in a while, some arithmetic fluke is going to identify an oddball self-booting game floppy disk as the Stoned virus.
Of course, some developers take more shortcuts than others. If a vendor just looks for the first relatively complicated string, it won't necessarily be unique. In one infamous case, a major anti-virus vendor found a nice, seemingly arbitrary, string in a virus that was written in a high-level language. The string was quite arbitrary, since it didn't do much: it was an identifier routinely included by a particular compiler. The scanner concerned suddenly started flagging all kinds of innocent programs as being infected. All these programs had been put together using the same compiler.
Once we move beyond the virus-specific scanning into generic anti-virus programs, the problem becomes more acute. Activity monitors, change-detection software, and heuristic scanners (all of which we will discuss in more detail in Part II of this book) look for what might be termed circumstantial evidence of viruses. Although these procedures can find new viruses that are not yet known in terms of scan strings, they aren't perfect. They are vulnerable both to false positives and to false negatives.
Therefore, any anti-virus program is, sooner or later, likely to give a false alarm. Be aware, then, that not every alert you get will be valid. On the various virus-discussion mailing lists and newsgroups, we are quite used to questions of the form "I have the X virus, but it is supposed to do/be Y, and I don't have that on my system. How come?" The standard answer you will receive to all such questions is, "Have you tried another scanner?" Using a second anti-virus program to confirm the report of the first is standard practice.
It is, perhaps, inevitable that we have been obliged from time to time to jump ahead to consider elements of anti-virus technology. Indeed, almost the whole of this chapter has been based on the implicit assumption that malicious software is what anti-virus software detects. This is, of course, an extraordinarily naive assumption, and not universally held, even among non-experts. Looking at a recent comparative review of anti-virus products in a non-specialist magazine, we find in the features table, under "Type of software", that a variety of software types and functions are listed:
Elsewhere, we often see virus scanners, Trojan detectors, personal firewalls, intrusion-detection software, and anti-spam software stuffed into the same bag. There is some justification for describing some of the packages associated with spam generation as malware, and it is possible to regard virus scanning as a special case of content filtering. However, we have not felt it appropriate to discuss the more social and less technological elements of content analysis in detail in this chapter: instead, we shall consider them further in Part IV, when we turn to social issues. It is misleading and short-sighted to consider perimeter protection in isolation from viruses and Trojans, and we will discuss the integration of anti-virus technology with other security software in due course. Before we even discuss core anti-virus technology, however, we must take a closer look at virus technology, which is, after all, the main subject of the book.
IN THIS CHAPTER:
We now come to some specifics of virus operation and activity. This section of the book may appear to be rather intricate, particularly for those who have not previously studied the inner functions of operating systems. However, it provides a background for understanding how, exactly, viruses do what they do. This, in turn, shows where computers are vulnerable to virus attacks, and where viruses are vulnerable to detection and prevention or removal.
For any of you who are expecting to learn how to program a virus in this or the following chapter: you bought the wrong book (and we did warn you in the introduction!). To make a virus requires some knowledge about programming and operating system (or possibly Microsoft Word or Outlook) internals. Having that knowledge, however, doesn't protect you against viruses, any more than being a gunsmith gives you an edge in making flak jackets.
NOTE
The truth is that most virus writers are less accurately compared to gunsmiths than to amateur hit-men: their skill level is just about sufficient to fire a sawn-off shotgun. While many virus writers play up to the image of the misunderstood or diabolical genius running rings around the men in suits, most viruses are trivial modifications of someone else's code, and may or may not work. We have a rich store of anecdotes concerning "kOOl dOOds"posting to alt.comp.virus and other traditional hangouts of the ethically challenged, who needed help to compile or assemble a virus. This doesn't mean that virus writers are never capable of competent code, or better. Nor does it mean that virus writers are never capable of useful input into ethical or technical discussions of anti-virus matters, and even corporate virus management. However, the notion that the people who write viruses know the most about them is a complete myth.
Unfortunately, the converse happens to be true: knowing how to protect against viruses can help a programmer build a better virus. The information in this chapter might assist those who know how to make viruses to design "better" ones. We feel that the risk is worth it, since we hope to support more system administrators than virus writers. We also consider that many people in the virus-writing game are there because they don't understand the consequence of their actions, and that some wouldn't consider themselves virus-writers, as such. We have in mind "white hat" virus writers such as system administrators and product reviewers who are compiling or otherwise modifying existing viruses for purposes of experimentation.
NOTE
Sarah Gordon's paper "The Generic Virus Writer //"(Virus Bulletin Conference Proceedings, September 1996) addresses some of the issues associated with virus writers who diverge from the "spotty adolescent" stereotype. We will return to this subject in Part IV of this book, and we will particularly point out the problems with inappropriate virus modification for experimental purposes. The paper is also available at http://www.research.ihm.com/antivirus/SciPapers/Gordon/GVWILhtml and is referenced at Sarah's own site at http://www.badguys.org/.
Our objective in this chapter is to present enough information about virus components and functions to enable you to make smart decisions about getting protection for your computer, system, or network. While we use pseudo-code from time to time to illustrate a point, that's as far as we go.
While we hope that any computer user should be able to understand this chapter, a background with computer internals will be a big help in putting this information to practical use. For example, knowing the structure of program files will give you a clearer picture of the differences between viruses and worms. Knowing how the operating system handles a call for an executable file will help you comprehend the different ways a companion virus can work. For obvious reasons, we are not going to include a full discussion of all the internal operations of all the operating systems that are available. We will try to provide some examples, mostly from the Wintel world, in order to explain the basic ideas for those without a serious technical background. Those who do know the inside details, for whatever operating system they use, should be able to extrapolate from the information given to their own environments.
How do you write a virus? And what language do you use? These are standard questions on alt.comp.virus, and they rarely earn a friendly answer from either side of the black hat/white hat divide. However, while this is not intended to be a programming text (far less a virus-writing primer), we need to make sure that you understand some basics (no pun intended).
Human beings don't generally write programs in raw machine code any more. Programs are written in a higher-level computer language, ranging from the inscrutable abbreviations of assembler language to those that attempt to emulate "natural language" as spoken by human beings. Clearly, there has to be some sort of translation process into the binary code that a computer can understand.
An assembler translates assembly language programs into machine-readable code. Assembly language is as near "to the metal" (low level) as most people go. High-level languages (HLLs) use two basic approaches to translation. A compiler evaluates the syntactical correctness of a whole program and outputs it as machine language, whereas an interpreter scans and executes a program one statement at a time. In the land of PCs, we tend to think in terms of compiled stand-alone programs (.COM and .EXE files), drivers (.VxD files), or support files such as overlay files, and link libraries such as .DLL files.
NOTE
On no account should the preceding be taken as implying that only a handful of traditional file-type extensions (.DOC, .COM, .EXE, .OVL, and so on) are vulnerable to virus attack. Many files with quite different name extensions have the same format as .EXE files (.SCR screensavers, for instance), and are just as vulnerable. Many people are now aware that .VBS denotes a Visual Basic script file. Fewer people are equally wary of files with a .VB, .VBE, or .VBX extension. In fact, Robert Vihert lists nearly 200 types of infectahle objects in The Enterprise Anti-Virus Book (Segura Solutions, 2000) and doesn't claim that list to be all-inclusive.
Most early PC viruses were written in PC assembler, with a few compiled in high-level languages such as C or Turbo Pascal. In fact, even now many virus writers regard proficiency in assembler as a necessary qualification for admittance to the Worshipful Order of Computer Vandals, and don't talk to people who are presumed not to qualify (especially anti-virus people). The following snippet of assembler language code illustrates a simple variation of the traditional Hello World program. As well as giving you a feel for what an assembly language program looks like, if it is assembled to a .COM file and executed, it displays a suitable response to assembler zealots.
code segment ; define a code segment (one stack only) for a .COM ; for an .EXE we'd have more work to do here. assume CS:code, DS:code ; set code and data segment registers to this segment org 100h ; because it's a .COM file we have to reserve ; 100 bytes for the PSP (Program Segment Prefix) start: ; 'just' a label mov ah,9 ; load AH with value 9h INT 21H ; Function 9H writes a character string ; to standard output mov dx, offset message ; load character string int 21h ; go ahead and do it mov ah,4ch ; INT 21H Function 4C terminates process int 21h ; do it message DB 'Get a life.$' ; this is our character string. It may seem ; counter-intuitive to declare a constant ; at the end, but it shortens the code. In a more ; complex program, we'd have to be more careful ; with forward references. code ends ; end of segment end start ; all done.
By contrast, the following Turbo Pascal code compiles to a program that displays the same message.
program raspberry;
const
BiteMe = 'Get a life'; {declare string constant}
begin
writeln(BiteMe); {Display string}
end.
Clearly, this is much easier to read (and to write - it's one of the few programs in our repertoire to compile correctly the first time). However, assembler (assembly language) has its advantages. It can be used to perform tasks not easily achieved in high level languages. Turbo Pascal would not be the language of choice for writing a boot-sector virus, for instance, and assembler is potentially much more compact. The previous assembly language program weighs in at 30 bytes when assembled and linked, whereas the Pascal version compiles to 1,920 bytes. A compiled (Turbo) BASIC version runs to 34,992 bytes!
In real life, this is less dramatic than it sounds. DOS allocates disk space to each file in clusters (allocation units), and a cluster is one or more sectors. On a FAT16, 32MB hard disk (hard though it is to find such a thing nowadays), a cluster is equivalent to four sectors or 2,048 bytes. Thus, our assembly language program and Pascal program would essentially take up the same amount of space, despite the disparity in file length. On a 32GB FAT32 partition, the cluster size is 32,768 bytes, so our BASIC version is just a little too large for a single cluster. It therefore occupies two clusters, so that it is effectively only twice as long as the 30 byte assembler program.
In the context of parasitic programs, however, file length can make a serious difference. Most computer users nowadays don't take much notice of file length details, even in a purely DOS environment. Recent versions of the Windows environment go to some lengths to shield the user from such minutiae (not to mention other trivia, such as filename extensions, much to the virus writer's advantage). However, in the early days of PC viruses (when a 10MB hard disk cost several hundred dollars and a directory listing was, by default, ridiculously detailed), small file changes could be quite noticeable in directory listings.
C:\WINDOWS>dir \*.com
Volume in drive C is PC DISK
Volume Serial Number is 3AF1-41A7
Directory of C:\
COMMAND COM 93,812 08-24-96 11:11a COMMAND.COM
1 file(s) 93,812 bytes
0 dir(s) 61,571,072 bytes free
C:\WINDOWS>
In this context, the compactness of an assembly language program could be advantageous in reducing the size discrepancy between an infected object and the same object in its uninfected state, compared to a virus that added several kilobytes or more to an infected program. By the end of the millennium, however, 10GB hard drives were considered entry-level, even UNIX had become an almost exclusively GUI environment, and uninfected Word documents quickly grew to sizes that ten years before would have been considered gross for a major word-processing application. Second-generation worms, distributed as stand-alone programs, exploited social-engineering techniques to trick victims into running malicious software masquerading as legitimate software, so that size became virtually irrelevant. Thus, compiled high-level languages such as C++ and Delphi became increasingly popular among virus and worm authors.
Of course, not all high-level languages are compiled. It's perfectly possible to write a virus in an interpreted language such as MSBASIC or QBasic, for instance. Indeed, it's possible to call a program from the command line or a batch file almost as if it were a stand-alone, compiled program. Visual Basic programs can be run quasi-independently as long as the run-time module is available on the system.
It's possible to write a virus in just about any language with minimal file input/output capabilities, though the likelihood of such a virus spreading far is another matter. Trojans written in Visual Basic, especially password stealers, became common in the latter half of the 1990s. As we write this book, WordBasic and Visual Basic for Applications, the native languages of most macro viruses, have become the most popular interpreted languages among virus writers, followed shortly by VBScript.
As noted in Chapter 1, computer viruses are considered to have three parts to their structure: the infection mechanism, the trigger, and the payload. We will not go into elaborate detail on the constituent parts, since this is a book on protection against viruses, rather than a treatise on how to build them. However, keeping the model in mind will help you to read and understand virus warnings.
The first, and only necessary, part of the structure is the infection mechanism. This is the code that allows the virus to reproduce, and thus to be a virus. The infection mechanism itself has a number of parts to it.
The first function is to search for, or detect, an appropriate object to infect. The search may be active, as in the case of some file infectors that take directory listings in order to find programs of appropriate size and format. Alternatively, the search may be passive, as in the case of macro viruses that infect each document as it is saved.
There may be additional decisions taken once such an object is found. Some viruses (sparse infectors) actually may try to slow the rate of infection in order to avoid detection. Fast infectors, on the other hand, aim to infect as many objects as possible, in as short a time as possible. Most viruses will check to see if the object has already been infected with a test like the following pseudo-code (multiple infections tend to be rather conspicuous):
BEGIN IF (infectable_object_found) AND (object_not_already_infected) THEN (infect_object) END
The next action will be the installation of a copy of the virus code into the infectable object itself. This may entail one or more of a number of operations, depending on the virus or worm type:
There are additional sub-functions at this step as well, such as the movement of the original boot sector to a new location, or the addition of jump codes in an infected program file to point to the virus code. There may also be changes to system files, to try to ensure that the virus will be run every time the computer is turned on.
At the time of infection, a number of steps may be taken to try to keep the virus safe from detection. The original file-creation date may be conserved and used to reset the directory listing, in order to avoid a change in date. The virus may have its form changed, in some kind of polymorphism. The active portion of the virus may take charge of certain system interrupts, in order to make false reports when someone tries to look for a change to the system. There may also be prompts or alerts generated, in an attempt to make any odd behaviour noticed by the user appear to be part of a normal, or at least innocent, computer error.
The second major component of a virus is the payload trigger. The virus may look for a certain number of infections, a certain date and/or time, a certain piece of text, or may simply blow up the first time it is used. (For obvious reasons, these latter viruses are not widespread.) As noted, a virus does not necessarily need to have either a trigger or a payload. A virus with a trigger and payload but no replication mechanism is not, in fact, a virus, but may well be described as a Trojan. A simple trigger mechanism might work like this:
BEGIN IF (date_is_Friday_13th) THEN (set_trigger_status_to_yes) END
The payload mechanism is similarly simple in conception:
BEGIN IF (trigger_status_is_yes) THEN (execute_payload) END
If a virus does have a trigger, then it usually has a payload (the term warhead is sometimes preferred). The payload can be anything, from a simple, one-time message, to a complicated graphical display, to reformatting of the hard disk, to mailing a copy of the virus to addresses in the victim's address book. However, the bigger the payload, the more likely it is that the virus will be noticed. You may have seen lists of symptoms to watch for. Some signs often quoted include text messages, ambulances running across the screen, and letters falling down to the bottom of the screen.
NOTE
We admit that the virus-fighter's use of the terms warhead and payload to describe what a virus actually does is somewhat imprecise. After all, we differentiate between a bomb, a flare, and a firework: we don't usually describe them all as bombs with different types of warhead. The term payload differs significantly from the way it is normally used in the transport context: it would be nonsensical to talk of the total weight of viruses carried. However, this usage is well established, and we make no apology for following it.
Nonetheless, checking for payloads isn't a very good way to detect (let alone keep free of) viruses. The most successful viruses are generally far less conspicuous. Sometimes the only time a characteristic display is observed is when the virus first infects (as with WM/Concept, for instance). Most times, there is no display at all, and it's only when anti-virus software sounds an alert that a problem is noticed, thus inspiring the Berkeleyesque thought that sometimes there is only a virus problem because anti-virus software perceives the presence of a virus.
NOTE
Bishop Berkeley (1685-1753) denied the existence of matter, maintaining that material objects exist only because they are perceived.
Some of the most successful viruses are sub-clinical in their effects: they have no payload, and their presence causes no significant effect on the health of the victim system, except the psychological damage to the system's owner who is then identified as a Typhoid Mary. Many viruses have less impact on victim systems than the common cold does on human beings.
NOTE
Typhoid Mary was the popular nickname for Mary Mallon, a cook who carried typhoid without showing any of the symptoms herself. She died in 1938 under permanent detention, having refused to give up serving food.
We have to wonder whether it's helpful that all viruses are regarded as if they were the computer equivalent of Ebola or Marburg. The panic that results from routine detection of unremarkable viruses may be more damaging (at least psychologically) than the presence of the virus on the infected system could ever be. We don't suggest completely abandoning attempts to detect and remove viruses, of course, but less disinformation about the nature of the threat would remove much of its sting.
Why are viral programs special? What is it about the simple fact that they reproduce that puts them in a class by themselves? There is no shortage of malware (malicious software) out there. Trojans and logic bombs were known long before viral programs existed, and they continue to flourish. Why can we not simply classify viral programs as another form of Trojan?
A Trojan program relies upon other programs to do the copying necessary for it to spread beyond an initial target. The dangers (and the results) are self-limiting. If a friend gives you a Trojan and it triggers, you lose trust in that friend. It is very seldom that you will be hit from the same source twice. Trojan writers like to use bulletin boards, web sites, or file archives, but even those methods of transmission are limited. A non-anonymous posting of a Trojan program will usually get an individual barred from archive sites.
These types of malware, therefore, can generally present an attack from a single point. As any military strategist can tell you, defence against such an attack is straightforward. Intelligence, in the form of advice from other users, can help to eliminate the attack before it starts.
In theory, at any rate, the closely-related worm problem is easy to address. If you don't allow any unverified program received by email to execute, irrespective of how well you know and trust the sender, most worms can't become established. The fact that worms continue to be effective only demonstrates the continued success of social engineering in overriding common sense.
NOTE
We must stress that the activation or execution of the virus is not the same as the activation of the payload that a virus may carry. For example, the payload of the original Stoned virus was a message, which appeared on the screen saying "Your PC is now Stoned!" This message only appeared when the PC was rebooted, and even then only one in eight times. The virus, however, was active and infectious all the time, once the hard disk had heen infected.
The virus has three main possibilities for the moment of infection: direct action (one-shot), during program run (while-called), or from then on (memory-resident). A resident virus may remain in memory but be actively infecting only when a disk is accessed. A while-called virus may infect a new program only when a directory is changed, for example.
One-shot (direct-action) viral programs get only one chance to propagate on each run of the infected program. The viral code will seek out and infect a target program. The viruses then pass control to the original program and perform no further actions. These are, of course, the simplest of the viral programs. Mainframe mail viruses are generally of this type.
Resident viral programs (often, and somewhat misleadingly, referred to as terminate-and-stay-resident, or TSR, viruses) become active when an infected program is run (at boot time for BSIs), and remain active until the computer is rebooted or turned off. Note that some viral programs (Joshi, for example) trap the rebooting sequence, which is normally called when you press CTRL-ALT-DEL on an MS-DOS PC, and are thus able to survive a warm boot.
The most successful of pre-Windows file infectors, the Jerusalem virus, was memory-resident, as are all boot-sector viruses. (The boot sector is never called in normal operation once the boot process is completed, so the virus can only be called if it stays in memory.)
If a DOS virus is active in memory, it can be difficult to disinfect a file or disk. (In fact, file disinfection is a contentious issue at the best of times, but we'll get back to that in Part II of this book.) No sooner is the file cleaned than it becomes a suitable target for reinfection, unless there is an anti-virus product already in memory preventing further execution of the infective code. Attempts to disinfect a hard disk may be as extreme as performing a low-level format. Even if this were ever necessary, it's perfectly possible that when a high-level format was executed subsequently, the disk might be infected all over again. Nonetheless, many products are capable of detecting and cleaning some viruses while still in memory, even in DOS.
The term TSR is applied to DOS programs that pop up when a "hot key" is pressed (Borland Sidekick, for example) while another application is running, or that execute in the background, like the PRINT command. Such programs use the MS-DOS TSR function (INT 21h Function 31h or INT 27h) to leave a portion of their own code in memory. Hardware interrupts (INT stands for interrupt), such as INT 9h (the keyboard handler), are intercepted by pop-up TSRs so that the program "knows" when its presence is required. The application of this idea to viral software has obvious advantages. Joshi, for instance, intercepts 9h to trap the CTRL-ALT-DEL reboot sequence and survive a warm boot. File viruses intercept various sub-functions of INT 21h for purposes of infection and/or concealment. Boot-sector viruses tend to hook INT 13h, which handles low-level disk access.
NOTE
DOS TSR programming is beyond the scope of this hook. Two useful resources are Undocumented DOS, by Andrew Schulman et al. (Addison Wesley), which has pointers to further in-depth information, and Ray Duncan's Advanced MS-DOS Programming (Microsoft Press). (Neither of these books makes the smallest reference to virus programming, by the way.)
In a modern, Windows-based environment, the mechanisms of memory-resident viruses are different, though the principles are similar. A Windows-savvy file infector is not constrained by the same limitations of available space as a DOS TSR program, and it doesn't have to worry about the niceties of directly accessing DOS services. It may be implemented as a VxD (virtual device driver) or NT service.
Calls to the Windows application programming interface (API) are handled with varying degrees of transparency by a high-level language rather than raw assembly language, since compact, fast code is less of an issue now than in the days of DOS. (The assumption that assembler is necessarily faster than compiled code is not altogether well founded, but that's a discussion for a completely different book.) Mail-borne viruses and worms often use Windows scripting and messaging services to scan and parasitize email, and Internet traffic may be directly or indirectly monitored to harvest mail addresses not in the victim's address book. (Hybris does something like this.)
A hybrid or while-called virus will activate when the infected program is called. It will then pass partial control to the original program. The virus, however, will remain operational during the time that the infected program is running. It is only a slight "progression" from residence while an infected program is running to a fully memory-resident virus, independent of the original infective file.
Macro viruses may be considered somewhat similarly. A Word macro virus is effectively memory-resident by virtue of having infected the global template, which is normally resident and referenced as long as Word is active. In an unprotected environment, this allows the virus to infect documents as they are created or opened for editing, and also to implement stealth measures, such as substituting its own code for standard menu options.
Fred Cohen described the virus threat in terms of three characteristics:
It is usually considered a truism in virus research that viruses are prevalent in those operating systems that are used by the most people. There are more Wintel viruses than Mac viruses because more people have and use Wintel machines. In the same way, even within a particular operating system, a virus that uses general functions is more successful than one with special requirements.
For example, one of the earliest viruses is called Lehigh, since it was discovered at Lehigh University. The Lehigh virus only infects the COMMAND.COM file, which exists on bootable DOS disks. Even at the time Lehigh was written, hard disks were becoming common, and bootable DOS disks were becoming less so. This factor, along with Lehigh's extremely dangerous and visible payload, ensured that the virus was never discovered in the field outside of the university campus.
Generality is not limited to operating systems, and in virus research, the term platform has a greater range than in any other computer field. Word macro viruses have been enormously successful, partly because they operate in Microsoft Office on both Windows and Mac systems. The recent spates of email viruses are not, strictly speaking, Windows scripts, but rather Windows/Outlook scripts. If you use, for example, the Pegasus email program, your system might be damaged, but you will not send forth any more copies of the worms.
Other factors can limit the extent of a virus. Boot-sector infectors can only spread via infected disks. Therefore, it was rather interesting, in the early 1990s, to note that the Stoned virus was far and away the most common virus in North America, while Form held a commanding lead in the UK. Throughout the history of virus research, similar geographic pools of infection have been noted. At the same time, the Michelangelo virus, probably starting from a base in Taiwan, spread worldwide in little over six months.
It is interesting to note that the model of virus infection is starting to change. Viruses of the Stoned family, including Michelangelo and Monkey, persisted for years. Indeed, they can still be found in the field. Melissa and the Love Bug spread worldwide within hours, but aside from variants, it is comparatively rare to find them today in the field; hence, the frequent contemporary use of the term fast burner.
Viruses can also "die" for other reasons. At one point, the Macintosh WDEF virus was extremely infective, since any disk, inserted at any time, into a running Mac would have the WDEF resource read and run. This behaviour was changed in Mac OS 7, and the WDEF virus, deprived of its main entry point, is now considered a mild historical curiosity. (On the other hand, since modern commercial anti-virus software needs a comparatively recent version of the operating system to run, who knows what old-time system viruses are still lurking on obsolete systems?)
Out in the PC mainstream, though, things may be changing further. Traditional boot-sector viruses have become rarer - or at least reported instances of them have. New BSIs are rarely seen, and older ones have a rapidly decreasing "market share". Newer operating systems (OS/2, Windows NT, Windows 2000) can be damaged by boot-sector infectors, but don't generally allow them to replicate.
Network and mail viral programs carry, in a sense, their own payloads. The reproduction of the programs themselves uses the resources of the hosts affected and, in the cases of both the Morris Internet and CHRISTMA worms, went so far as to deny service by using all available computing or communications resources.
Most other viral programs seem to be written "for their own sake" - a kind of electronic, self-writing, self-replicating graffiti. However, even these can do unintended damage. Of those viral programs that do include a payload mechanism, relatively few carry a deliberately damaging payload. Those that do attempt to erase infected programs or disks are, fortunately, self-limiting, though the more successful examples give themselves time to fan out to other systems before trashing the currently infected system.
The most iniquitous form of payload is, perhaps, the gradual corruption over time of the environment or of data. The term data diddling is sometimes used in this context, not altogether appropriately. The term is also used when data are modified for fraudulent purposes. However, slow corruption from a virus is generally just destructive: the author derives no benefit except the kick of knowing that damage has been done. Dark Avenger gets much of the "credit" for this innovation: the Dark Avenger viruses and Nomenklatura specifically target those careful souls who back up data regularly. In this case, data files are corrupted, not infected, and the damage is more-or-less random, so anti-virus software can neither detect nor repair affected files, even after the presence of the virus is known. Any backup subsequent to the initial infection is unreliable at best, useless at worst. And, of course, it's often impossible for the victim to ascertain which backups predate the infection, even if exist.
Characteristically, macro viruses modify data within infected files, so identification of the infection gives some indication of the integrity status of the infected file. Clearly, it's unsafe to trust the integrity of the data contained in a file infected by a virus that makes random modifications, and anti-virus software can't usually be expected to reverse random changes. Of course, many macro viruses don't make any modifications to actual data, so removal of infected or corrupted macros is often sufficient to reverse the effects of the virus. However, this isn't always the case. Removal of viral macros isn't enough to restore menu options such as Tools I Macro (removed by WM/Cap, for instance), or to reverse the effects of a virus that passwords Word files. Furthermore, it would be unsafe to assume that a currently uninfected document has never been infected or otherwise touched by malicious software. A disinfected document may have been left with unnoticed modifications, or even fragments of viral code.
NOTE
This, incidentally, is one of the disadvantages of the (understandable) urge to deal with virus infections as transparently as possible. If infected data files are "transparently" detected and cleaned by anti-virus software (whether at the perimeter or the desktop), can you trust the product to completely reverse the effects of the infection? We will return to that thought in Part II of this book, but will just point out now that if you can't, you might be better off going against the flow and discarding infected files instead of disinfecting them.
We have spoken of damaging payloads in viruses, and should probably address that topic more carefully. Viruses can do any kind of damage that software can do. This includes overwriting data, erasing files, scrambling system information, reformatting disks, disabling security systems, corrupting software, or killing program processes.
NOTE
In principle, a virus can do anything that other software can do: hence the persistent idea of "useful" viruses, such as the maintenance viruses described hy Cohen. It's a sad reflection of human nature, however, that most authors of viruses and other malware prefer payloads that are at best trivial, at worst damaging.
Primary damage is normally associated with viruses and other malicious code not identified and prevented from executing at the point of entry, and can be defined as damage to systems and data caused when the computing environment is modified by virus or Trojan attack.
A virus can cause significant damage simply by being installed, independently of delivering any payload. This type of primary damage frequently arises from boundary conditions not taken into account by the virus author.
Viruses that don't normally cause visible damage on older DOS or Windows systems can suddenly cause difficulties if it becomes necessary to remove them from a FAT32 system. They may damage an executable file by modifying it in such a way that the operating environment will no longer run it, or they may bring down a PC running Windows NT by displacement or encryption of system areas.
Irrespective of payload, just the presence of the virus may be enough to cause damage. Theft of memory may result in loss of functionality and performance: some code may no longer run. A spectacular example is that of the first version of the Navidad worm. After an infected system was rebooted, a combination of a logical error in the code and the use of a change in the Registry meant that no file with the filename extension .EXE could be run.
Theft of disk space may have the same effects. Data, application files, or system areas may be partly or totally overwritten, and infected files may no longer function properly.
Theft of clock cycles may result in a noticeable slowing of processes, time-critical processes may behave unpredictably, and resource-intensive software may lose functionality and performance.
General incompatibility and destabilization may give rise to the following symptoms:
NOTE
Any "real" virus entails some form of "damage": that is, impact on performance in one or more of the classes of impact described in the preceding list. Both real and imagined viruses (the latter including those described in hoax alerts) can also have psychosocial consequences. Assessing the real impact of a perceived threat can he a serious drain on systems administrators, the Help Desk, management, and users or clients. Damage due to inappropriate reaction to a perceived threat is better considered as secondary damage.
Direct damage can be considered in terms of the classic tripartite security model (Availability, Integrity, Confidentiality). Viruses and malware have an impact across all three areas described by this model, as well as other areas, such as accountability. The type of damage that might be caused includes the following:
Viruses, in particular, often have a more trivial payload, such as a visual or audio effect or message, which in itself may not merit classification as primary damage.
Malware may also do damage that might be better considered as psychological. All viruses can be described in these terms, since discovering that one's system is infected is potentially frightening. If one is perceived by others to be a virus carrier, the consequences are at least embarrassing. This phenomenon is further explored in the next section ("Secondary Damage"). However, some malware is specifically designed to have a psychological effect (fear, amusement, titillation, and so on). Malware displaying a message announcing its intention to reformat the hard drive could thus be described as doing direct psychological damage. In general, this is characteristic of Trojans and jokes rather than viruses.
Unfortunately, a computer user faced with some visible symptom may react inappropriately and cause more damage than the virus itself does. This is a manifestation of what might be called secondary damage, which can be defined as:
There is one type of damage missing from the previous lists. Software does not usually damage hardware, though it remains a possibility. The myth of viral programs damaging hardware seems to be one of the more enduring. No viral program yet found has been designed to damage hardware. However, it is possible for certain pieces of hardware to be damaged by programming.
Certain older types of display monitors (notably early IBM monochrome graphics adapters) could be made to "freeze" the sweep of the electron beam, and thus burn in a section of the screen phosphors. No one has ever burned a hole in a monitor, nor have they ever caused one to overheat and blow up because of software.
Except for some very specific and limited functions dealing with powering down in advanced computers, power supplies cannot be addressed by software. No one has ever "melted down" a power supply with software.
As with any physical or mechanical devices, printers can be damaged by getting them to do any one thing for too long. This, of course, depends upon the machine running unattended for a long time. Some disk drives can be damaged by "pushing" the heads beyond normal limits. Some IDE controllers and drives do not allow for the calls used to generate a low-level format of earlier types of hard drive. If such a call is made on a system with an IDE controller, the results are uncertain. The drive will not be formatted, but it may not be left in a usable state. IDE drive manufacturers have not always shipped programs for low-level formatting, and so a call for a low-level format on an IDE drive appears, to the normal user, no different from hardware damage. As this has become known in the user community, more IDE manufacturers have made such formatting software generally available.
The CIH/Spacefiller virus, while it doesn't literally destroy hardware, can effectively render some PCs unusable by writing garbage to a flashable BIOS chip. In some cases, it may be cheaper to discard a flashtrashed motherboard than to replace a soldered BIOS, and in this case the distinction between hardware and firmware damage starts to look pretty academic. Furthermore, BIOS chips are only one instance of the use of flash EPROMs.
In fact, CIH was by no means the first virus capable of conning the victim into discarding apparently dysfunctional hardware. However, no useful statistics exist as to how many serviceable hard disks have been dumped as a result of virus action.
A number of security-related phenomena have been described as various types of bombs, with varying degrees of justification and relevance to this chapter and to the anatomy of malware in general. We have included several in the hope of reducing confusion.
A logic bomb is a routine or set of routines that are activated when a particular set of conditions is met (for example, the nth time the program is executed), and may be a component of a virus or Trojan. A logic bomb might also be inserted into a legitimate program as a precursor to blackmail, or pre-emptive revenge in anticipation of dismissal, or with some sort of backdoor functionality. (Backdoors are described in Chapter 3.) Clearly, anti-virus software is unlikely to be useful in the context of such one-off programs.
Time bombs are a special case of logic bomb, where the trigger condition is a particular time and/or date.
ANSI bombs are not viral, in that they do not reproduce, and have never been particularly common. They may be considered Trojans or logic bombs. An ANSI bomb is a sequence of characters that is interpreted by ANSIS YS as redefining a key, or keys, on the keyboard. Thereafter, these keys will not send the normally assigned characters, but rather the redefined string. This string may contain any ASCII characters, including <RETURN> and multiple commands. Therefore, the space bar, for example, can be redefined to:
"DEL *.*<cr><cr>"
This sequence would, in an MS-DOS environment, delete all files in the current directory.
ANSI bombs can be carried in normal text files or messages. They are triggered when text is sent to the "console" device while ANSI emulation is active, normally by reading the file with the TYPE command. Reading a text file with a word processor generally does not port the data to the console, since the text is interpreted by the word processor before it is displayed to the screen. Only a very few older word processors use the ANSI.SYS program for screen control. However, reading an email message with a terminal program that uses ANSI.SYS could have the same effect, as could extraction of an archived file that contains the ANSI sequence in the text comment header.
Reading all text files with an editor, a file viewer such as list, or a word processor is a protection against ANSI bombs, but it still leaves the possibility of being affected. The best protection is to remove ANSI.SYS from the system and not to use terminal emulators or other programs that require it. You can also replace ANSI.SYS with shareware versions that do not have the key-binding mechanism. In fact, very few programs still in use require ANSI.SYS to be present, which is fortunate, as anti-virus software rarely offers any protection against this particular, albeit uncommon, threat.
ANSI bombs apart, ANSI.SYS is not intended for use with modern versions of Windows, though it continues to be supplied.
NOTE
In the RISKS-FORUM Digest (March 1988:6-42), there was a story ahout the use of the intelligent features of Wyse 75 terminals. This was a specific instance of the use of peripherals for security cracking. The Wyse terminal in question had a feature that allowed keys to be remapped from the host system, and another feature that permitted the keys to be called for from the host. Thus, the subject lines in email messages could present commands that would remap a key to correspond to a command, and then have the command submitted by the terminal. With only a little thought, an email virus could he written taking advantage of this fact. This is quite similar to the phenomena of ANSI bombs on MS-DOS machines that, while not viral, use the ANSI.SYS key remapping facility to assign deletion or formatting commands to specific keys.
These are mail abuses that anti-virus software cannot realistically address. A mail bomb is a denial of service attack performed by bombarding the victim's mailbox with email messages. A subscription bomb achieves a similar effect by subscribing victims to a multiplicity of mailing lists so that they receive an avalanche of mail from the lists. These threats are mentioned here for completeness, and in the hope of reducing confusion.
While some of the content of this chapter has been fairly low-level, we have so far focused on the effects of infection rather than on the internal mechanisms of malicious software. Next, we complete our survey of the virus problem with a closer look at virus anatomy.
IN THIS CHAPTER:
We have considered in some depth the effects of virus infection, and given an overview of virus structures. We must now move from basic anatomy to physiology. It is no more possible to understand viruses fully by a study of their basic structure than it is to understand human biology by the study of the skeleton.
We have pointed out several times that covert operation is not a defining characteristic of computer viruses. However, it is an almost universal characteristic, for the compelling reason that covert operation is generally a prerequisite for the dissemination of malicious software. (Though we sometimes suspect that if a malicious program arrived as an attachment that said "Danger! Do not execute this program: it will trash your system!!!" a number of people would still try to run it, just to see if it really did.) Since self-concealment is a major contributing factor to the size of the virus problem, it occupies a considerable proportion of this chapter. First, however, we must look in more detail at virus types and infection mechanisms.
We have noted that operating platforms for viruses don't have to be linked to operating systems. Microsoft Office, whether running on Wintel or Mac, can spread macro viruses. At the other end of the hardware/software spectrum, some viruses thought to be DOS viruses are not. Most boot-sector infectors aren't DOS viruses, but BIOS viruses, specific to hardware rather than the operating system.
A boot-sector virus runs when the boot sector is executed, and this is before DOS, or any other operating system, gets a chance to start. (We'll get to the details of that in a moment.) A BSI runs before any program on the disk, and, therefore, the only programming that starts earlier is the ROM (read-only memory) BIOS (basic input/output system) programming required by all ISA machines. (ISA - Industry Standard Architecture - is the rather pretentious title for the basic design of IBM PC compatibility.)
NOTE
There are, of course, other operating systems that use this same architecture, such as Windows, OS/2, and Linux. We have seen boot-sector viruses happily infect OS/2 and NT machines. However, if the infected machine's operating system does not use the interrupts trapped by the virus, the BSI won't proceed to infect diskettes accessed subsequently by the PC. This doesn't mean that there are no NT virus problems, as we are sometimes told. File viruses and macro viruses can often execute and infect just as well on an NT platform as on a Windows 95 PC.
Most people think of viral programs in terms of a variation on Cohen's definition: that is, a virus is a program that always "attaches" to another program. This has given rise to misconceptions concerning boot-sector infectors.
Boot-sector infecting viral programs do (in a sense) attach to another program. Most people are unaware of the fact that there is a program on every disk, even those that are blank (that is, contain no files). Every formatted disk has a boot sector, located at the first physical sector (or logical sector, in the case of a hard drive). When the computer is booted, the BIOS programming looks for a disk, and then runs whatever happens to be in the boot sector of that disk as a program.
In most cases, with non-bootable disks, the program placed there by the formatting process simply displays a message informing the user that the disk is not bootable. However, any viral program that places itself in that boot-sector position on the disk will be the first thing, other than BIOS code, to be executed when the computer starts up. Once installed onto a system, BSIs will copy themselves onto floppy disks and infect a new host computer when the "target" machine is booted (usually inadvertently) with one of the infected diskettes in the A: drive.
BSI terminology is derived from MS-DOS systems, and this leads to some additional confusion. The first physical sector on a hard drive is not the operating-system boot sector. The hard drive's boot sector is the first logical sector. The number one position on a hard drive is the Master Boot Record (MBR). The MBR contains the partition table - the data specifying the type of hard disk and the partitioning information. The terms "Master Boot Record", "partition table", and "partition boot record" are often used interchangeably, although they are not exactly the same thing. Some viral programs, such as the Stoned virus, always attack the physical first sector: the boot sector on floppy disks and the Master Boot Record on hard disks. Thus, viral programs that always attack the boot sector might be termed "pure" BSIs, whereas programs like Stoned might be referred to as an "MBR type" of BSI. The term boot-sector infector is used for all of them, though, since all of them infect the boot sector on floppy disks.
In saying that every disk has a boot sector, we are using the term "boot sector" in its most generic sense. In the MS-DOS environment, "boot sector" has a more limited technical definition, and a hard disk actually starts with a Master Boot Record rather than a boot sector. In either case, however, one system area gives the computer some definition of the disk and information about the next step in the boot sequence.
In most cases, the boot sector does not point to the next step in the boot sequence, because system files are not available on most diskettes. In the case of a bootable disk, the "bootable" sector points to the location of files containing both the programming necessary for input and output activity and a program for the interpretation of operating-system commands. A data, or non-bootable, disk may simply contain information on the disk specification, and a small program informing the system, or operator, that the disk is "not a system disk".
The important points, however, are that there is a program in every boot sector, and that the boot program isn't visible in normal operation. There is no entry for it in the directory listing of the disk, and therefore most people are not aware that it exists.
The existence of a boot sector on every disk is the major strength of boot-sector infecting viral programs, and it is a psychological, rather than a technical, advantage. Because a "data disk" does not contain any recognizable "programming", it is often seen as safe. However, there is, in fact, a "hidden" program on the disk, and it can be infected.
NOTE
We should clarify the fact that in the MS-DOS world, "hidden" also has a technical meaning as a file attribute. Files with that attribute are invisible to the casual observer, and are also a little more difficult to modify. However, this should not be taken as offering significant protection against viruses: most virus authors have learned by now how to modify file attributes.
Boot-sector infectors either displace or replace the existing boot sector. Usually they move it to another location on the disk. This means that the viral program gets first crack at control of the computer before most protective measures have a chance to kick in. It installs itself in memory and then passes control to the original boot sector. Thus, the disk appears to behave normally unless the virus carries some noticeable payload.
A BSI, to be effective at all, must be memory-resident. However, because BSIs modify the environment pre-emptively when the PC powers up, and make changes to system areas that are not normally seen, their changes are often undetected in normal operation.
When the machine is first powered up, there is a certain amount of programming contained in boot ROM. The amount varies greatly between different types of machines, but this programming describes the most central devices, such as the screen and keyboard, and points to the location of disk drives. These operations allow the system to make use of those peripherals.
The boot record (or boot sector) contains further information about the structure of the disk and the location of subsequent operating system files. Because this information is in the form of a program rather than data, and because this sector is writable, in order to allow for different structures, the boot record is vulnerable to attack or change. BSIs may overwrite either the boot record or the boot sector, and may or may not move the original boot sector or record to another location on the disk. The repositioning of the original sector's program allows the viral program to "pretend" that everything is as it was by presenting the original sector code for inspection rather than the infected code.
This pretence is not absolute. A computer with an active viral program will differ in some way from the normal environment. The original sector position will contain different information than is normally located at that address. The viral program will need to "hook" certain vectors for its own use in order to monitor activity in the computer and to execute its infection and payload mechanisms. The virus occupies a certain portion of memory, and its presence may be deduced from the unavailability of that memory.
These indicators are not conclusive, though. There may be various reasons why the top-of-memory marker is set to indicate less than 640KB on a DOS machine. Each different type of disk drive, and each drive of the same type that is partitioned differently, will have a different boot record. As operating systems or versions change, so will the boot sector.
It is possible, however, to compare any machine with itself in a "known clean" state. Indeed, this is the foundation of change detection or integrity checking as an antiviral measure and technology. By saving information about the environment after a minimal clean boot and comparing this with subsequent boots, changes can be detected and the user alerted to a potential problem. The boot record can also be replaced with a program that will check the state of the disk, memory, and interrupt table in order to detect the changes that a virus must make. (A program like this can also function as the foundation of a security system that cannot be avoided by "escaping" out of the boot sequence.)
Obtaining the state of the environment immediately after the boot sector code has been run is not as easy as it might sound at first. The computer, while functional, does not have all the parts of the operating system installed at this point, and it is the "higher" levels of the operating system with which users generally interact. Even low-level code may not be able to access information on programs not yet executed.
There are some interesting variations in the boot process with implications for security on other platforms. Macintosh-specific system viruses are rarely reported today, with a few notable exceptions (AutoStart, SevenDust, MacSimpsons), and they are not considered further in this chapter. This isn't to say that there is no virus problem on Macs: Microsoft Office macro viruses continue to constitute a major Mac problem, although it's not the same problem as we see in the PC world.
NOTE
The whole issue of virus management on Macintosh computers is examined in depth hy David Harley in the "Viruses & the Macintosh" FAQ, which is included as Appendix B in this hook. The subject is also examined in more detail in the 1997 Virus Bulletin Conference paper "Macs and Macros", available at http://www.sherpasoft.org.uk/MacSupporters/macvir.html.
The Atari computer may reserve up to six sectors for the boot sector: only one is ever used in the normal course of events. This, of course, provides an excellent hiding place for a virus. The additional five sectors can contain a reasonably capable virus, and there is no danger of overwriting other files, nor any need for the virus to try to avoid detection from file size changes.
However, most Atari programs, and even boot disks, do not require any executable code in the boot sector. Start-up files, including system accessories, are placed in a standard directory, and all such files found in the directory are run at boot time. Many Atari anti-virus programs do nothing more than overwrite executable boot sectors. The overwriting action will eliminate any boot-sector viruses (although it will not provide protection against any that may be installed in the start directory). Since Atari computers are able to read MS-DOS formatted disks, some of these antiviral utilities may corrupt DOS disks.
We have already pointed out that an Intel-based PC running UNIX (for example, Linux, 386BSD, SCO UNIX, and so on) can also be infected by a boot-sector virus if booted from an infected disk. The same goes for PCs hosting other operating systems, such as NetWare and Windows NT, of course. Such systems are not usually associated with secondary infection (that is, viruses won't fan out to other systems), since the viruses are not usually able to infect floppy disks (although systems with multiple operating systems open up interesting possibilities). However, infection of the boot sector may be enough to cause noticeable damage.
NOTE
There are very few non-experimental UNIX viruses at present, although this situation is beginning to change with the massive increase of interest in the operating system among corporate and home users. In the past, UNIX viruses tended to be shell scripts rather than binary executables, since scripts are far more portable - UNIX runs on a wide range of system architectures. There have been some UNIX-specific worm incidents, most notably the Morris Worm (a.k.a. the Internet Worm) of 1988. Some Linux viruses exist (as binary executables, rather than shell scripts), but they are not widespread. As this chapter is being written, the Ramen worm, which infects Red Hat Linux 6.2 and 7.0 installations, is known to be in the wild. UNIX servers running as web servers and HP servers are still considered a major potential source of files infected with viruses specific to other platforms, even if they are not directly infectable themselves. This problem is sometimes referred to as the "latent virus" problem, or "heterogeneous virus transmission".
On MS-DOS computers with extended partitioning of the hard disk, the Master Boot Record may be read while accessing a different logical drive. It is therefore possible, even if the computer has been booted from a clean floppy disk, for an infection on a drive to show up in memory. Although there is almost no chance that a virus will become active in this way, such partitioning will often trigger a "virus in memory" alert from scanning programs.
BSIs were the most "successful" of traditional viral programs in terms of the number of copies made and the number of systems infected. This may seem odd, given that BSIs can only make, at most, one copy per disk.
On the other hand, once they are "installed" on a hard drive or boot disk, BSIs are always active, since they start at boot time and remain in memory, if the operating system allows for that type of activity. Unless the system is booted from a clean disk, the virus will continuously infect any and all disks that are proper targets for it.
It is sometimes possible for more than one boot virus to infect a disk. This scenario is sometimes referred to as a cocktail. Some cocktails conflict in their use of the same areas of the disk. Some combinations (such as Stoned and Michelangelo) can render the system unbootable, and thus alert the user to a problem.
NOTE
Some sources advocate the use of the DOS command FDISK with the /MBR switch, thereby rewriting part of the MBR but leaving the partition tahle intact, as a generic means of dealing with boot-sector viruses. This actually works much of the time, but we cannot recommend it. First, it doesn't help with pure BSIs (such as Form) that don't infect the hoot sector. Second, if it's done with the wrong virus in memory (Monkey, for instance), the system can become inaccessible. We'll return to this issue in Part II of this hook.
Let's consider the continuation of the boot sequence that we started earlier. When setting up antiviral defences, it is important to know the sequence of events in the boot process in order to know which programs will protect to which level. The MS-DOS sequence provides the clearest example, and those knowledgeable in other systems can use the illustrations it provides to analyse the specific details of their own systems. This becomes a bit of a grey area, since we are no longer dealing with hardware-specific boot sectors but aren't yet into ordinary files, which are the subject of the next section.
The last part of the boot-sector program points to the files or areas on the disk containing the next step in the start-up sequence. At this point, of course, the specific files and steps begin to diverge greatly from one operating system to another. However, it is common for operating systems to have hidden files along this route that may be subject to viral attack. Given that these files are not evident to the user, they are even more vulnerable - not to attack, but to an undetected change.
After the Master Boot Record and boot sector have been read and executed, MS-DOS normally runs two additional programs that set up input/output routines and the most basic operating system. (As these programs are called by the boot sector, it is possible to reroute this process to call specialized driver programs first or at the same time. Some esoteric disk drives use such a process.) After they have run, the system has sufficient information to interpret a text file (CONFIG.SYS) that contains listings of various additional programming that the user wishes to have in order to run specialized hardware.
After the programs listed in CONFIG.SYS are run, the command interpreter is invoked. The standard MS-DOS interpreter is COMMAND.COM, but this may be changed by an entry in the CONFIG.SYS file. After COMMAND.COM is run, the AUTOEXEC.BAT batch file is run, if it exists. AUTOEXEC.BAT is the most commonly created and modified boot file, and many users and antiviral program authors see this as the point at which to intervene. It should be clear by now, however, that many possible points of intervention are open to the virus before AUTOEXEC.BAT is run.
In spite of the greater number of entry points, viruses that attack the programs of the boot sequence are rare and not very successful. For one thing, while every disk has a boot sector, not every disk has a full boot sequence. For another, different versions of a given operating system may have different files in this sequence. (For example, the hidden files have different names in MS-DOS, PC-DOS, and DR-DOS.) Finally, viral programs that can infect ordinary program files may not work on boot-sequence files, and vice versa.
Even though Windows 95, 98, NT, and 2000 use some of the same filenames as MS-DOS, their functionality and importance to the operating system's start-up sequence have been drastically modified. The DOS sequence is described here as an example, not as a definitive description. It is, however, a sequence assumed by many older viruses. A more generic summary of the PC boot sequence is given in the "Typical PC Boot Sequence" sidebar.
In general, PCs boot up according to the following sequence of events:
File-infecting viral programs are variously known as file viruses or parasitic viruses.
NOTE
The term link virus is sometimes used in the context of platforms other than PCs. We prefer to avoid this usage, however, since the term link virus or linking virus is also sometimes used by PC-centric researchers to refer to viruses (most notably DIR-II) that are more often described as cluster viruses.
File viruses link, or attach, to their program file targets in many different ways. There are, in fact, four main ways to attach code to an existing program.
File- or pro gram-infecting viral programs, while possibly not as numerous as BSIs in terms of actual infections, represent the greatest number of known viral strains, at least in the PC world. This may be due to the fact that file infectors are not as constrained in size as BSIs or that file infectors do not require the detailed knowledge of system internals that may be necessary for effective boot-sector viral programs. As "easier" routes to malware programming are discovered (Microsoft Office macro viruses, AOL password stealers, VBScript viruses), there are fewer viruses that require extensive knowledge and industry on the part of virus writers.
File-infecting viruses spread by adding code to, or associating code with, existing executable files. (It can be argued that macro viruses are a special case of file infector, but we consider them separately later in this chapter.) File infectors become active when an infected program is run. Whereas BSIs must be memory-resident in order to spread, file-infecting programs have more options in terms of infection. This means that there is greater scope for writing file-infecting viral programs, but it also means that there may be fewer opportunities for a given virus to reproduce itself.
With two exceptions, file-infecting viral programs must, of necessity, make some kind of change in the target file. If normal DOS calls are used to write to the target file, the file-creation date will be changed. If code is added to it, the file size will change. Even if areas of the file are overwritten in such a way that the file length remains unchanged, a parity, checksum, cyclic redundancy, or Hamming code check should be able to detect the fact that there has been some change. The Lehigh and Jerusalem viral programs, the first to become widely known to the research community on the Internet, were both initially identified by changes they made to target files (Jerusalem being widely known by its length - 1813). Change detection, therefore, remains a viable means of virus detection on the part of antiviral software producers, though it is not often used currently.
Because change detection does not require sophisticated programming (in some cases, no programming at all), virus writers have attempted to camouflage changes where they can. It is not a difficult task to avoid making changes to the file creation date, or to return the date to its original value. It is also possible to overlay the original code of the program so that the file is not increased in size. Many virus authors have also been using stealth programming to bypass the operating system and return only the original, unchanged, values when a request for information is made.
In DOS there are three main types of executable programs that can be called directly from the command-line prompt: files with .BAT, .COM, and .EXE filename extensions. Even in DOS there are many other types of files that can contain executable code; Windows environments however, not only increase the range of files that can contain code, but the range of ways in which such files can be called.
Executable files with .BAT filename extensions are referred to as batch files, although they have little in common with the batch processing of mainframe computers. Batch files are text files with collections of DOS commands, and are thus restricted to the operations that are possible with those commands. They are similar in concept to shell scripts, which are widely used on some multi-user operating systems (especially UNIX), but are comparatively limited in functionality. .BAT file viruses have been written, but they are generally regarded only as curiosities.
.COM and .EXE files are the "real" programs. They are structures of machine instructions, or opcodes. Of the two, .COM files are much more basic. A .COM file is a fairly straightforward list of opcodes with no reference to outside files and few jumps from one section of code to another. .COM files are therefore much simpler to infect, not least because they always start from the same address.
An .EXE program has a more complicated structure. For example, it starts out with a section of data describing the structure of the program. This data section has a length that can vary, but only in multiples of a specific size. Viruses that infect .EXE programs have to make changes to this data section and, depending on the original size, have to increase its length. Therefore, virus-infected .EXE files do not increase by a specific length related to the virus, as is the case with .COM files, but have an increase that partly depends upon the structure of the original program.
Windows 1, 2, and 3.x generally ran DOS programs without too much problem, and the program structures for Windows-specific programs were only marginally more complex. However, with Windows 32-bit versions (Windows 95, 98, NT, Me, and 2000) the programs began to use a new format, called PE-EXE (Portable Executables). DOS viruses could usually infect Windows 1, 2, and 3 version programs, though the functionality of those programs was often impaired. PE-EXE files are sufficiently different that the techniques used by old .COM and .EXE infectors no longer work, although there are viruses that can infect all types of .EXE files.
Most file viruses place the bulk of the viral code towards the end of the program file, with a jump sequence at the beginning of the file that points to the main body of the virus. Some viral code attaches to the beginning of the file - this is simpler in concept, but actually more difficult in execution. These two techniques are known as appending and prepending, respectively, but these terms are used less now than in years past.
Adding code at the beginning of the original program ensures that the viral code is run whenever the program is run. (This also ensures that the virus is run before the program runs, giving the virus priority in terms of operation, possible conflicts, and detection.) By adding code to the beginning of the program, it is possible to avoid any change to the original code. It is, however, necessary to alter at least the file/disk allocation table to ensure that the program call starts with the viral code, and that the viral code is not overwritten by other changes to the disk or files. Also, while the original code may be left unchanged, the file will nevertheless be altered, and unless techniques are used to disguise this, the file will show a different creation date, size, and image.
It is also possible to add viral code to the end of the original program and still ensure that the viral code is run before that of the original program. All that is necessary is to alter the file header information to reflect the fact that you want to start executing the file towards the end, rather than at the normal location. At the end of the viral code, another jump returns operation to the original program.
This kind of operation is not as odd as it may sound. It is not even uncommon. A legacy from the days of mainframe "paging" of memory, it is used in a great many MS-DOS executables, either in single .EXE files or in overlays. It is, therefore, not a coding indication that can be used to identify viral type programs or infected files.
Appending, or prepending, viral code to an existing program avoids the problems of damage and potential failure to run, which plague the overwriting type of viral programs. Even these viral programs, however, are not foolproof. Programs that load in very non-standard ways use the header information that the viral programs alter. Although not originally designed for virus detection, the "Program abort - invalid file header" message thus generated is an indication of viral infection, though not a very reliable one. In a complex operating environment such as Windows, there are all too many possible non-viral reasons why a program may stop functioning properly.
Some viral programs do not attach to the beginning or end of the file, but write their code into the target program itself. Most often this is done by simply overwriting whatever is there already. Most of the time, the virus will also make a modification to the beginning of the program that points to the virus, but on occasion the virus will rely on chance for a computer operation to stumble upon the code and run it.
Of course, if a virus has overwritten existing code, the original target program is damaged, and there is little or no possibility of recovery other than by deleting the infected file and restoring from a clean backup copy. However, some overwriting viruses are known to look for strings of null (or NUL) characters that may provide a space to overwrite. If such a string can be identified, the viral code can be removed and replaced with nulls again. (The Lehigh virus, for example, attaches "behind" the COMMAND.COM file, in a sense, but overwrites slack space at the end of the file so as not to change the file size. The details of this virus will be explained in Chapter 12.)
Overwriting existing code is a very simplistic answer to the problem of adding code to an existing program without changing the file size. By simply overlaying code that is already on the disk, the original size remains unchanged. There are a few problems with this approach. The most obvious is that preserving file size is an ineffective means of avoiding detection. Probably no competent anti-virus program using generic techniques would check file size alone, without checking content, if only by a simple checksum.
Then there is the problem of how to make sure the virus is called when the infected program is run. If the code is just inserted anywhere, it may not be in a part of the program that is used every time the program is run. (Every programmer is aware of the Pareto Principle's application here: 20 percent of the code does 80 percent of the work. Some code never gets called at all.) It is possible, by an analysis of the target program's code, to find an entry point that is used extensively. It is also possible, and a lot easier, to place a jump at the beginning of the program that points to the viral code.
The second problem is much more difficult to deal with. If the virus code overwrites existing portions of the program code, how do you know whether the loss of that program code is fatal to the target program? Analysis of this type, on the original code, is very difficult indeed. Successful overwriting viral programs tend to be short and to look for extensive strings of NUL characters to replace (ZeroHunt is an example). The NUL characters tend to be used to reserve stack space, and thus are not vital to the program. However, even if the original code is not vital to the program, it may cause the program to exhibit strange behaviours if replaced, and thus lead to detection of the viral infection.
We should also mention the Nina virus, which overwrites the beginning of a file, and the Phoenix family, which overwrites a random section of a file. Both Nina and Phoenix append the overwritten part to the end of the infected file. The Number of the Beast/512 virus and 1963 both overwrite the beginning of the file and then move the contents of the overwritten section beyond the physical end of the file into a portion of the last cluster that the file occupies. The clusters are always of a fixed size, and because it is very unusual for a file to exactly match a multiple of the cluster size, there is generally some space past the "end" of the file that is, essentially, invisible to the operating system.
While overwriting viral programs solve the (trivial and often irrelevant) problem of maintaining file size, they bring with them some inherent problems, which appear, at this time, to severely limit their effectiveness. To this date, while many overwriting viruses have been written, none have enjoyed great success nor have they become major, widespread problems.
There is still one class of overwriting virus that we have not yet considered, and this is perhaps the lowest form of virus writing. Some virus authors bypass the comparative complexities of the overwriting techniques just described by using code like this:
if (infectable_obkect_exists) then (replace_object_with_self)
Such code makes it easier to guarantee that the infected program is viable. However, the fact that no attempt is made to preserve the functionality of the target program drastically restricts the chances that such a virus will survive. The non-functioning program draws attention to the presence of a problem, even if the implication of a viral program is overlooked. In fact, it can happen that the infected file can be replaced by a fresh copy without the victim ever realizing what the problem actually was, though in such a case the possibility of reinfection remains. Where such an overwriter is detected by conventional anti-virus software, it's normally only possible to erase the infected file. It can be replaced, but not repaired.
Recent worms have modified this approach by targeting and overwriting specific program files (characteristically, .DLL files associated with email). The replacement file has the functionality of the file it replaces, but is modified (subverted) to suit the purpose of the worm (that is, to propagate itself). We must distinguish here between this type of overwriting (as performed by MTX) and that performed by LoveLetter.A, which replaces graphics files with VBScripts but doesn't attempt to maintain the original content of the graphics files.
In the world of prependers, the Rat virus uses a technique similar to overwriting. .EXE file headers are always multiples of 512 bytes in size, so there is often an unused block of space in the header, itself, that the Rat assumes to be available. The sURIV 2.01 works a bit harder: it moves the body of the file and inserts itself between the header and original file, and then changes the relocation information in the header.
DIR-II, often referred to as a cluster virus, takes a different approach. The viral code is written to one section of the disk, the last available cluster (even if the cluster is already in use). Directory and file-allocation information is altered in such a way that all programs seem to start in that one section of the disk, enabling the viral code to be executed without its being directly attached to any of those programs. Because of the convoluted way this virus works, it is possible to "lose" all the programs on the disk by attempting to "repair" them.
NOTE
This doesn't mean it isn't possible to repair infected files, by the way. In spite of tbe fearsome reputation that DIR-II originally acquired, it is actually rather easy to detect and remove - it doesn't even require anti-virus software - as long as you know bow it works.
At one time, this type of operation was referred to as a FAT virus, because of the change made to the File Allocation Table (FAT). However, this usage is confusing, since it can be misinterpreted as meaning that the FAT itself becomes infected.
The most successful and current variation on this theme involves modifying the Registry so that when a given file type is called (characteristically, any .EXE file), the virus is also executed. This trick has been used by a number of recent viruses and worms. Time and again in computer virology, we encounter this principle of misdirection. Like an illusionist, the virus writer attempts to distract us with smoke and mirrors from the real mechanism at work. Companion viruses provide a particularly interesting example of misdirection.
The simplest way for a viral program to avoid the detection that results from modifying the code of an existing program is to not modify the original program. The virus must then find another way to insert itself into the chain of command so that it will still be called when the (unmodified) original file is called. Companion viruses take advantage of a feature of the MS-DOS operating system. As we've previously indicated, three types of executable file are recognized at the MS-DOS command line, denoted by the .COM, .EXE, and .BAT filename extensions.
Because the different extensions provide an additional means to distinguish a file, three different executable files under MS-DOS can exist in the same directory with the same filename, but different filename extensions: for example, MYFILE.COM, MYFILE.EXE, and MYFILE.BAT. Normally, a program is only invoked by calling the filename; the extension is "filled in" by the operating system.
How, then, does the computer decide which of these three to run? It uses the following rules of precedence. First, a search is made for an "internal" command listed in the command interpreter. If that succeeds, that command is run. Thus, under MS-DOS, when you give the command DIR, the system generally runs the directory-listing subroutine provided by COMMAND.COM, even if a file named DIR.COM exists. If the search for an internal command does not succeed, the computer looks for a file with that filename and a .COM extension, then an .EXE extension, and then a .BAT extension. At each stage, if the search succeeds, the file is run; if it fails, it goes to the next level. Thus, in MS-DOS, .COM takes precedence over .EXE, which takes precedence over .BAT. A companion virus can thus "infect" a MYFILE.EXE file by making a copy of itself called MYFILE.COM. MYFILE.COM file will take precedence, and typing MYFILE at the DOS prompt will always call the virus first. In order to avoid detection, the viral file will generally end with a call to the original program, and the viral program's file attribute is set to "hidden" so that the program is invisible to a cursory directory listing. Variations on this scenario include renaming the original file and giving the virus file the name of the original file.
Fortunately, companion viral programs are by no means perfect. For one thing, they are limited to acting on those programs that are lower in the order of precedence. For another, the hidden attribute is relatively easy to overcome (particularly in MS-DOS), and an alphabetical listing of files will quickly turn up the anomaly of identical names. (Oddly, antiviral packages generally do little to alert the user to duplicate filenames. Often the user will be asked to validate a file without any suggestion that something might be amiss if the file has not just been added to the system.)
There is a valid argument that says that companion (or spawning) viral programs are not viral at all. Companion viral programs certainly do not link to existing program code, at least not in a physical way. They use a certain provision of the system to trick you into running them rather than the program you meant to run. Thus, they might be said to be closer in definition to a Trojan.
On the other hand, companion viruses do reproduce. They also form, in a sense, a logical link with existing programs. They certainly behave in a viral fashion by inserting themselves into the chain of command.
In GUI operating systems, it is possible for a virus to take precedence by overlaying an existing icon with another that is either transparent or identical to the first. Windows provides some additional means for companion viruses to operate, since it has a rather complicated sequence for searching directories when an executable program is called, and some of the "early" directories are almost completely unused.
At first glance, file infectors have many advantages over BSIs. There are many more program files on a given system than boot sectors and, therefore, more opportunities or targets for infection. Also, multiple copies of a given virus can reside on any system. While some viral programs may conflict in the use of memory or interrupts, multiple viral programs can often quite happily infect the same program file. Files can also be transferred via bulletin boards, web sites, and networks. On the other hand, a virus that has infected a file must still wait until that file is executed in order to be successful.
Most people trade data far more readily than they do programs, and, in the olden days, that meant they passed around diskettes, which could be infected by boot-sector infectors. (In trading Microsoft Office documents, of course, they may be trading both data and viruses. However, the perception of Word documents and Excel spreadsheets as data rather than as potential hosts for programs means that they are freely traded, whether by email, between networked machines, or on removable media such as diskettes.)
Removable media provide a better vector for BSIs (except that BSIs are restricted to diskette exchange), than for file infectors. Also, program files tend to be passed in "archived" form, usually as zip files, and even if the program becomes infected on one system, the original archive, itself, is unaffected. Usually the original archive is passed along, rather than a re-archived copy that might have become infected. Unless the original archive was infected, it will likely not become a vector, even if it passes through an infected system.
BSIs, therefore, have certain advantages, while file infectors have others. To get the greatest "spread", a virus writer wants to build a virus that will infect both files and boot sectors - a multipartite virus. In practice, these programs have had some success, but they have not spread as widely as you might expect. Multipartite, or dual-infection, viral programs have the potential to infect both program files and boot sectors, which expands the range of possible vectors. Dual infections can theoretically travel on any disk, and multiple copies may travel on a disk if program files are present. Multipartite infectors can also usually travel on networks and via files passed over bulletin board systems and other communications channels.
Are multipartite infectors a terrible new threat? Well, no. They've been around for a few years now. Why haven't they taken over the world?
There are disadvantages, as well as advantages, to multipartite viral programs. One of the major disadvantages is complexity. A number of file infectors infect only one type of program file, an MS-DOS .COM file, for example. A virus that infects both .COM and .EXE files generally has more than twice the code of one that infects .COM files alone. The virus must not only know how to deal with both file types, but also how to distinguish between the target files. The same logic holds true for multipartite infectors. The virus must carry with it the means to infect two radically different types of targets, as well as the means to identify two very different types of potential hosts. The necessary size of the program is much larger, as is the requirement for processing. The multipartite virus can be reduced in size, but this generally means a reduction in function as well.
Classic "file and boot" infectors are not actually the only multipartite viruses. There have long been examples, for instance, of macro viruses that install DOS file viruses. The current generation of worms illustrates a disturbing trend towards multipartite configurations. MTX, for example, spreads both as a non-parasitic worm and as a file virus. Multipartite worms are likely to survive better than the previous multipartite generation, because they work in an environment where file size matters less. Recent versions of Windows demand generous resources (disk space, main memory, processor speed). The truism that programs expand to fill the available workspace is as true of malware (and anti-virus software) as it is of office applications.
The choice of targets might seem to be an easy matter, but the reality is slightly more complex. The most effective means of spreading would be a "get-everything" policy, but this might also lead to conflicts and detection. Some programs might choose to alternate: a program infector would infect boot sectors, and a boot-sector infector would infect program files. This seems reasonable, until you realize that it merely makes the virus sequentially a BSI or a file infector in alternating generations. Statistically, this means that it will be slightly less effective than a boot-sector virus, rather than more.
Macro viruses dominated the mid-1990s (since the emergence of WM/Concept in 1995, though Concept was not, strictly speaking, the first macro virus). As the decade came to an end, virus writers turned their attention to other scripting environments, especially VBScript.
Macro viruses are currently, as they have been since their inception, restricted primarily to Microsoft Office applications. Many are associated with Word, most of the rest with Excel. There are a handful of viruses for other Office applications (proof-of-concept viruses, mostly). A few other proof-of-concept viruses are associated with non-Microsoft products using licensed versions of Visual Basic for Applications (AutoCAD) or a similar macro language (CorelSCRIPT, for instance). Some examples of unrelated macro malware (Lotus 123 Trojans, and HyperCard infectors, for instance) exist. Not all Office-based malware is viral: there are Trojans and virus generators, too. We will start off with some general discussion of macro viruses, and then move into specifics of the Microsoft technology.
Macros were originally intended to be small items of user-defined (or definable) programming that automated routine tasks. In fact, older applications often had no way of writing or editing macro code directly. The only way to create a macro was to record a series of actions (keystrokes and mouse movements) that could be played back as required later, but not edited.
While some people make distinctions between macros, scripts, and programs, the differences are largely matters of degree in terms of breadth of functionality, ease of use, and connection to a given application. Macros and scripts are supposed to be small, simple, easy to use, and they are generally interpreted, rather than compiled, so they carry their own source code. However, Visual Basic for Applications (VBA) and similar languages are full-blown programming languages whose functionality exceeds that of many older compiled or interpreted languages.
NOTE
The fact that macro viruses carry their own source code doesn't necessarily make them easier to spot. Like QBasic and GW-BASIC before them, VBA and most of its siblings have the ability to save code in an encrypted format (what GW-BASIC used to call "protected" files, and WordBasic called "execute-only" macros). Microsoft Office viruses generally go to some lengths to "hide" their presence (though to the practised eye, the absence of macro-related menu options can be something of a giveaway). Furthermore, they take advantage of an execute-only macro's ability to prevent the VBA editor from loading it for examination.
Macros or scripts, in order to be run, have to be executed by an appropriate application. They are (in principle) application-specific rather than specific to a particular hardware platform, operating system, or operating environment. In practice, though, they are restricted to platforms that support the host application. In some cases, the virus may be a stand-alone program, as in the case of Microsoft Windows shell scrap objects or Windows Script Host (WSH) files. However, in most cases, it is an advantage to be able to associate the macro with a data file or object. Thus, you can hide a JavaScript program in an HTML email, or a Word macro in a Word document file.
Actually, you can't put a Word macro into a document file in older versions of Word. However, you can put data into a macro template file. A template file should have a .DOT extension in DOS or Windows, but Microsoft doesn't want to bother you with those details. As a result, it is quite possible to create a file with a macro and some data in it, call it a document, and have Word figure out that there is executable content. And run it. In more recent versions of Word, documents containing macros are legitimate and distinct from templates.
You can create names for macros in Word, and some names are better than others. If a macro is named "AutoOpen", for example, it will run every time the associated file is opened. If you called it "FileSaveAs", it will perform the action specified every time the Save As item is chosen from the File menu. Therefore, virus writers can create files that appear, to the user, to be documents, but which can automatically perform some operation when read in the Word program, and which can change the functions of Word itself.
Macros can also be persistent. The global template file (called NORMAL.DOT in DOS and Windows versions - on the Macintosh, where filename extensions are less significant, it's just called NORMAL) contains those macros that you want to use in different documents. It is quite possible for a macro to copy itself into that global template file, thus sticking around long after the original infective document has been deleted.
VBA is a very functional language. Some purists would insist that it no longer qualifies as a macro language: certainly it no longer allows you the quick and dirty operations that macros were intended for, before the advent of programming Wizards. However, it is definitely capable of producing some of the most damaging viral programming on the planet.
As noted earlier, the difference between macros and scripts is one of degree. The difference between macro viruses and script viruses generally lies in the details of the virus itself. As noted earlier, the difference between macros and scripts is one of degree. The difference between macro viruses and script viruses likewise generally lies in the details of the virus itself. Certainly, the difference between a VBA macro and a VBA script, both contained in an ostensible document, is definitely one for the internals books.
At the moment, the difference between what is considered a script virus and what is considered a macro virus generally turns on the association with a data file. If it is buried in a .DOC or .XLS file, it is a macro; if it comes as a .VBS attachment in an email, it is a script.
Viral programs have almost no defence at all against disinfection. Ninety-nine percent of viral programs are almost trivially simple to get rid of - simply replace the infected file (or boot sector) with an original copy. Some more recent boot-sector and system viruses require slightly more knowledge in order to perform effective disinfection, but few require drastic measures. The same is not, unfortunately, true of worms. Some recent worms (MTX springs to mind) are awkward to remove, and it is unsafe to rely upon anti-virus software to do the whole job. Note that disinfection is not the same as complete recovery from the changes made by a virus.
NOTE
Far from their image as the predators of the computer world, viral programs behave much more like prey. Their survival is dependent upon two primary factors: reproductive ability and avoidance of detection. Viruses are more like the rabbits of the computer kingdom, except that stopping them can he as simple as basic computer hygiene. Exercising caution with disks and files from outside and keeping anti-virus software up-to-date is easier than culling virus authors with myxomatosis. If only life were really so simple.
Using the standard system calls to modify a file leaves very definite traces. The change in a file's creation or last-modified date is probably more noticeable than a growth in file size. File size is rather meaningless, whereas dates and times do have significance for users. Changing the date back to its original value, however, is not a major programming challenge. Adding code while avoiding a change in file size is more difficult, but not impossible. Overwriting existing code and adding code to "unused" portions of the file or disk are two possible methods discussed in the "File Infectors" section of this chapter.
Some viral programs, or rather, virus authors, rely on psychological factors. There are a number of examples of viral programs that will not infect program files under a certain minimum size, knowing that an additional 2KB is much more noticeable on a 5KB utility than on a 300KB spreadsheet. Not only because in the former case 2KB represents a 40 percent increase and in the latter case less than 1 percent, but because it's normal for data files to increase their size, whereas it is not for system utilities or applications.
In a sense these are all stealth technologies, but this term is most often used for programs that attempt to avoid detection by trapping calls to read the disk and "lying" to the interrogating program. By so doing, they avoid any kind of detection that relies upon perusal of the disk. The disk gives back only that information regarding file dates, sizes, and makeup appropriate to the original situation, providing, of course, that the virus is active at the time of checking. Although this stealth method avoids any kind of "disk" detection, including checksumming and signature scanning, it leaves traces in the computer's memory that can be detected. (Some viral programs also try to "cover their tracks" by watching for any analysis of the area they occupy in memory and crashing the system if it occurs, but this tends to be rather noticeable behaviour.)
Although the majority of viral programs spread via disk boot sectors, the infection of programs, Word documents, and email attachments, it is possible (and nowadays increasingly common) to use other means of replication. The important factor is the ability of a system component to submit information, which is then run as a program. It is, therefore, possible for terminals, peripherals, and network devices to operate as viral vectors.
NOTE
To quote Fred Cohen, "Three basic things allow viruses to spread: sharing, programming, and changes. All we have to do is eliminate those three things and we will be perfectly free of viruses". (A Short Course on Computer Viruses, second edition.)
In order to function as a viral vector, a peripheral device needs three features (or components):
Once those conditions are met, any peripheral, be it printer, modem, disk pack, or terminal, can act as a means of replication and spread.
However, as with hardware damage, there is a major weakness in the use of peripherals as viral vectors. Peripheral command sets, particularly those dealing with the more powerful functions, tend to be very hardware-specific. In the case of the programmable function keys mentioned in Chapter 4, one command set was used for Teleray terminals, for example, while another was used for Wyse terminals. The commands for these terminals are not interchangeable, although the functions are almost identical. This is an advantage of the current incoherent computing environment. However, as open-systems initiatives gain strength, many new viral vectors may become possible.
Peripherals are not the only unusual vectors for viral programs. Consider the common boot sector. A knowledge of the structure of the boot (and Master Boot) sectors and boot sequence is practically a prerequisite for any serious viral study. However, the VIRUS-L mailing list and FidoNet discussion echoes (the equivalent to a bulletin board) were formerly inundated with frequent postings by users claiming to have contracted Stoned (or Michelangelo, or Monkey, or...), to have deleted all the files on the disk, and yet to still be infected! To the vast majority of users, the fact that a program can be located at a physical position on the disk but not be referenced by the file directory list is a foreign concept. This confusion may contribute to the longstanding success of boot-sector infectors. (Some boot-sector viruses still in the wild date back to the 1980s.)
The boot sector on any write-enabled disk, and the partition boot record on a hard disk, are accessible to dedicated amateurs armed with utility software. However, there are other places to hide code or data on a disk, and these are not as easily examined. It is quite possible to format an additional track outside the normal range, for example. In order to avoid problems between drives with variations in tolerance, the software does not push the limits of the hardware. There are various programs for MS-DOS and other operating systems that provide greater storage on the same-sized disks.
In addition to tracks outside of and between normal formats, there is substantial space between the sectors on a disk (slack space), and there are programs that can increase the number of sectors so as to increase the space on disk. However, it is also possible to use the additional space without formatting additional sectors by writing information to slack space. Commercial software sometimes uses this technique for copy protection purposes. Both of these hiding places are so well concealed that viral programs infecting them never have a chance to become active. Viral code using these techniques has to provide the means to access the extra tracks or extra sector space, and then use the hiding space in order to store additional code.
Some hiding places are definitely a part of the system, while not being necessarily obvious. The Mac OS, for example, associates a number of resources with each program and data file. Most of these resources can have code associated with them, and therefore provide a number of additional hooks for viral access. It is interesting to note that undocumented features in the 32-bit versions of Windows are starting to allow the same type of function and are being identified as potential security risks.
A virus usually contains some kind of identifiable string or code that can be used to identify it. Even if the virus is new or polymorphic, it still adds its code to the infected program, thus adding to the size of the program. If the virus overwrites original code so that it does not add to the length of the file and even tries to match a "checksum" calculated on the code overwritten, a sophisticated cyclic redundancy check (CRC) will still find a change. So how can a virus hide from all of these detection mechanisms? By tricking the operating system into concealing the virus's "footprint", the changes it has made in the environment.
Stealth technology, as applied to computer viral programs, most broadly refers to all the various means that viral programs use to hide themselves. Specifically, however, it refers to the trapping mechanisms that viral programs use to avoid detection. These mechanisms are only effective once the virus is active in the computer (active in memory). The virus will trap calls intended to read the data on the disk and in response return only the information that the original, uninfected, program would have returned.
Viral programs can trap all functions that perform disk access in order to hide the fact that the virus is copying itself to the disk under the cover of a directory listing. Viral programs can also trap system calls in order to evade detection. Some viral programs will sense an effort to read the section of memory that they occupy and will cause the system to hang. Others trap all reading of disk information and will return only the original information for a file or disk.
Because of possible differences in hardware, and also because these functions are generally fairly standard, the manipulation of the disk (whether by a virus or a legitimate application) is accomplished by calls to the operating system and underlying software and hardware, rather than being performed directly by applications. The operating system provides standard system calls and hooks to the required functions. When a program wishes to read data from the disk, it asks the operating system to do it by calling a standard operating system function.
However, since the function is standard, virus writers know it as well. Code inserted at the standard address can redirect the call to code provided by the virus. This stealth code may indeed use the original programming provided by the operating system, but it filters the data returned to the calling program. If an infected file is being read, the infection simply does not appear in the information that the calling program receives.
Stealth is a technology, not a virus per se, though the name Stealth has been applied to individual viruses from time to time. Most viral programs implement stealth in one form or another. Stealth is not, in fact, limited to viral programs. Antiviral software, and even utilities, use similar means to avoid compatibility problems with the wide range of computers and programs now operating (though the preferred term in this case is transparency). Stealth mechanisms have sometimes been classified as follows:
Somewhat related to stealth technology is the concept of tunnelling. Again, this is a technology, not a virus per se, and one that is used in both viral and antiviral programs.
Before there were viral programs, there were Trojans. Anti-Trojan software was (and is) largely based on change detection, or else on activity monitoring and the restriction of operations (activity blocking), much as is done by a number of antiviral programs today. Activity monitors do not really monitor activity: they place traps and interrupts at certain points in the operating system. Certain system calls are either potentially dangerous themselves (such as the function that formats a disk) or are precursors to dangerous activities. Therefore, when a program calls one of these functions, the activity monitor is triggered. Again, this relies upon the fact that operating-system functions must be made available in a known location so that valid programs can use them. The activity monitor can then alert the user, and the user can choose to stop the action or to allow the action, in which case the original operating-system code is run.
Since the state of the system is generally well known, a virus can be written to examine these system entry points, and it can tunnel or trace back along the programming associated with the system call. If an activity-monitoring program is found (and this generally means anything other than the original operating-system code), the trap can be reset to point to the original system call. The activity-monitor program is now bypassed, and will not trigger - at least, not for that particular function.
This same type of activity can be used against viral programs. Viruses often trap certain system calls in order to trigger infection activities. Antiviral software can tunnel along the various interrupts, looking for changes. Viral programs can thus be disarmed.
Anyone who has ever tried to manage accounts on mainframes or local area networks (LANs) will recognize that there is a constant battle between the aspects of security and user friendliness in computer use. This tension arises from the definition of the two functions. If a computer is easy to use, it is easy to misuse. If a password is hard to guess, it is hard to remember. If access to information is simple for the owner, it is simple for the cracker.
NOTE
This axiom often gives rise to two fake corollaries. First, the reverse - that those systems that are difficult to use must therefore he more secure - does not hold. Second, many people assume that restricting the availability of information about a system will make that system secure. While this application of the STO (Security Through Obscurity) strategy may work in the short term, its effectiveness as protection is limited. Indeed, it often has the unfortunate side effect of making information less accessible to those who should have it, such as systems managers, while slowing the attackers only marginally.
User-friendly programs and operating systems tend to hide information from the user. There are two reasons for this. In order to reduce clutter and the amount of information that a user needs to operate a given system, it is necessary to remove options and, to a certain extent, functionality. A user-friendly system is also more complex in terms of its own programming. In order for the computer to behave intuitively, it must be able to accommodate the many counter-intuitive ways that people work. Therefore, the most basic levels of a graphical user interface system tend to be more complex than the corresponding levels of a command-line interface system. These levels are hidden from the user by additional intervening layers, which also add more complexity. (Hence the rule of thumb that the easier an operating system is to use, the harder it is to program.)
The additional layers in an operating system, and the fact that a great deal of management takes place automatically, without the user's awareness, furnish the ideal environment for a viral program. Since many legitimate and necessary operations and changes are performed without the user's knowledge, viral operations can also proceed at a level completely hidden from the user. Also, because the user is largely unaware of the structure and operations of the computer, changes to that structure and operation are difficult to detect.
Virus-specific or known-virus scanning software is, for all of its limitations, still the most widely used type of antiviral software. The idea behind this software is that you can identify a virus by a unique scan string or (less correctly) signature within the virus that will not be found in any other program. There is an art to the choice of a scan string. Code is preferable to text, which may easily be altered - some variants differ only by trivial modifications of text messages from the original virus. The code should also be integral to the operation of the virus. Ideally, you want a string that may identify future mutations of this virus, as well as the current infection. Once you have a suitable signature, you can identify the virus.
Unless, that is, the virus changes in some way so that it doesn't contain a constant pattern that can always be used for identification.
This is the idea behind polymorphism. There are a number of ways to change the "shape" of a virus. One way is to start with a simple "random" number, such as the value of the seconds field of the system time when the infection occurs. Then perform a simple encryption on the value of each byte in the viral code. Only a short chunk is left at the beginning to decrypt the rest of the virus when the time comes to activate it. Encryption can be used in other ways: encrypting a regular, but arbitrary, number of bytes, or encrypting most of the code as a whole, rather than on a per-byte basis. From a scanning point of view, this isn't too much of a problem. Extracting an identifiable string from the code of the decryptor/loader stub is quite possible. This signature can be used to check for the presence of the virus.
In programming, there are always at least half a dozen means to the same end. Many programming functions are commutative - it doesn't matter in what order certain operations are performed. This means that very small chunks of code, pieces too small to be used in isolation as scan strings, can be rearranged in a different order each time the virus infects a new object. Meaningful instructions can be randomly interspersed with instructions that perform some non-essential task, or do nothing at all (a NOP, or null operation). Single instructions or subroutines can be replaced with different but functionally identical instructions or subroutines. These approaches may be combined with one or more encryption routines to produce a variable decryptor/loader that can't easily be scanned by using a fixed scan string.
A distinction tends to be made between the first, and limited, self-encrypting viral programs, and the later, more sophisticated, polymorphs. Earlier, self-encrypting viral programs had limited numbers of variants: even the enormous Whale virus had fewer than 40 distinct forms. However, it was noticeable for the layers of obfuscation put in the way of anyone trying to analyse it in detail. (It isn't actually necessary to analyse Whale to that level of detail in order to detect it, of course.) Later polymorphic viruses have been more prolific: Tremor is calculated to have almost 6,000,000,000 forms.
An even later development was the polymorphic "engine". This is not a virus as such, but code that can be added to any virus in order to make it polymorphic. The most widely known of these is the Mutating Engine, known as MtE, written by one of the virus writers who used the "handle" Dark Avenger. There is no MtE (or DAME: Dark Avenger's Mutating Engine) virus - only other viral programs that have had the code attached. MtE is not the only such program around; many others have been developed, such as TPE (Trident Polymorphic Engine).
Polymorphic engines are sometimes confused with virus kits, or generators, which we dealt with in Chapter 3. The polymorphic engine, if properly attached to the original virus, will re-form the viral code on each new infection. A virus kit is a program to automate the actual writing of a virus - the user picks characteristics from a menu of choices, and the kit program sticks together pre-programmed pieces of code to make a virus. A polymorphic engine, then, is code added to a virus to make the same virus change its appearance each time it reproduces. A virus kit is a non-replicating, non-viral program that automates the process of generating viral programs, each with different characteristics. Unless polymorphism is one of the available options, viral programs produced by a kit will retain their signatures from that point on.
Fortunately, polymorphism in any form and at any level has not been that great a threat, despite the superstitious dread that the term arouses in non-experts. Polymorphs are as easily detected by change-detection and activity-monitoring software as any other viruses. Even virus-specific scanners have not (in the long term) had great difficulty dealing with polymorphic programs, though some scanners that were unable to adapt to early polymorphic threats have become (deservedly) extinct. The early self-encrypting programs usually provided readily identifiable signatures, since the decryptor stub had to be left unencrypted. Even those programs that performed significant encryption or used variable encryption routines generally had only a few forms, which could all be recognized. Later polymorphs are sometimes more difficult to analyse and identify initially, but algorithmic analysis, as opposed to pure signature scanning, is generally successful. Indeed, in the case of the polymorphic engines, the use of these encryption techniques has sometimes been advantageous to the antiviral researcher. When you can identify the MtE code, you can also identify, as a virus, every new virus to which it is attached.
Recently, a less sophisticated form of polymorphism has been seen in the worm arena. One of the side effects of the Love Bug epidemic was that system administrators were encouraged to block at the mail gateway email attachments that had particular filenames associated with particular email Subject headers. Inevitably, malware authors were inspired to introduce a measure of polymorphism into worm creation. Some subsequent worms have been characterized by variable Subject headers and filenames. It is likely that some malware authors will continue to develop this theme.
Social engineering refers to breaking security through non-technical means. In fact, social engineering has always been a very effective computer-cracking tool, and is used extensively in all manner of viruses and Trojans. Despite the fancy name, social engineering refers to plain, old-fashioned, garden-variety fraud and psychological manipulation. Social engineers are con men (and women), and deceit is the oldest (remember talking snakes in gardens?) and most banal form of crime that exists. There is absolutely nothing novel about computer crime: only the tools have changed.
NOTE
The original Trojan horse, as recounted in Virgil's Aeneid, was a great piece of social engineering. Can't get through the walls? Pretend to go away and leave a jolly great trophy outside the walls of your enemy. If they are stupid enough to drag your troops into the city, you're laughing. Trojan programs do the same thing. Would anybody run a program labelled "Erase the whole disk immediately?" Of course not. So you call it "Greatest sexxx scenes" instead. Gets 'em every time.
Old-style viruses don't need extensive social engineering, since they are designed to spread without needing to trick the victim into executing a program they would not otherwise execute. Most of the programs we currently refer to (with varying degrees of accuracy) as worms, however, would not usually be executed unless some means of deception was employed. In Nachenberg's terminology, they are not self-launching. Another way of looking at the whole virus issue is to regard social engineering as integral to the ability of a virus to spread promiscuously without the knowledge of the victims who pass it on, since the trickery depends on the ability of the malicious program to infect legitimate code. Most people don't receive viruses from a computer vandal with a black eye patch and a cutlass between his teeth, but from a friend or colleague. They trust the infective object because they trust the sender.
Boot-sector infectors relied on the fact that most people had hard disks, and most diskettes were not bootable. Most computer users did not know that all DOS disks, including diskettes, contained a program in the boot sector. Nobody bothered about whether you put a diskette in the drive before the computer was turned on. There was no possible problem: if the computer told you "Non-system disk", you just ejected it and hit any key - except that, by that time, the virus on an infected diskette had already taken hold on your computer.
By the time Word macro viruses came along, the virus community had been telling people for many years that you couldn't get a virus from data, only from programs. Microsoft, however, found a way to include executable content in what was supposedly a data file. Thus, macro viruses took off like a rocket. (After all, you didn't have to check .DOC files, since they were just data.)
NOTE
Other word processors have macro languages, so why is it that only Word and Excel get successful macro viruses? One reason is the huge functionality built into WordBasic and Visual Basic for Applications: more features than any sane person would ever use in a word processor. The other factor, however, is that Word can have both macros and data in the same file. A WordPerfect macro is stored in a separate file, and you'd tend to notice if someone tried to get you to run this macro when you were supposedly just trying to read the document. To be fair, Microsoft didn't invent the concept of combining programs and data in the same file: PostScript and spreadsheets have done something similar for years, and experimental spreadsheet viruses had heen known for some time previously.
Email viruses and worms use social engineering extensively. The original CHRISTMA EXEC worm displayed all its code clearly, if people only looked at it. However, the accompanying message stated that browsing the code was no fun at all, and suggested that the victim just run it. And most people did just that.
More recently, Melissa used extensive social engineering. For starters, it was posted on alt.sex, a great place to find a lot of people with, shall we say, a lack of discrimination. It was posted as a document supposedly containing passwords for pay sex sites. (Oh, good, sex and something for free.) When active, it mailed itself from your email program to people in your address book. In other words, it would always come from someone you knew: someone you could probably trust. The subject line is "Important Message From: [name of sender]" with the name taken from the registration settings, so the message is 1) generic, 2) important, and 3) again, from someone you know. The text of the body states "Here is that document you asked for ... don't show anyone else ;-)". The document obviously has to do with some prior conversation (that you have, for the moment, forgotten), and it is confidential. This makes it irresistible.
Love Bug used much the same features (who can resist a love letter from an unknown admirer?) with one addition: the filename of the attachment was LOVE_LETTER_FOR_YOU.TXT.vbs. Obviously you were supposed to notice the .TXT extension. Text files are harmless. The fact that the last extension, in spite of its lowercase unimportance, is the "real" extension was generally ignored. Again, the code was clearly visible to anyone who cared to look at it (and the fact that it contained a routine called InfectFiles was, one would think, something of a giveaway).
NOTE
But what if you really can't even program well enough to modify an easy worm like Melissa? One possibility is to warn people ahout the virus you wish you could write. Tell them there is a terrible virus on the loose, and it is just going to destroy everything. Tell them to tell everybody they know to stop reading email and avoid this horrible plague. Be sure to give your virus a good name, though. Maybe something like "Good Times". We will have much more to say about Good Times and other hoaxes in Part IV of this book.
The most recent example of a social-engineering virus is unlikely to do anybody any harm, but it replicates nicely. In the wake of Melissa and the Love Bug, an email joke started doing the rounds. Most variants note that it is the "honour system" virus. If you feel left out of the latest email virus furor, you are invited to randomly delete half the files on your computer, and send the joke message off to everyone you know. (While computer virology is not a suitable pastime for the humorously disadvantaged, we feel we have been delighted enough by this particular example of gallows humour. And it's still a chain letter. Please don't send us any more.)
It may seem odd that we have not offered a technical section dealing specifically with worm technology in this chapter, especially in view of the fact that email viruses and worms constitute one of the major current threats. However, the class "worm" is at a higher level of abstraction than the subclasses addressed here, such as file viruses and macro viruses. The term worm may be applied to particular examples of a wide range of malware, including script viruses, macro viruses, file viruses, overwriters, and even Trojans. In fact, worms exemplify the trend towards convergence to which we have alluded previously. It seems to us to be more useful to examine particular examples of the breed in more detail than to attempt to impose a contextual strait] acket onto viral programs that may or may not meet a particular definition.
There are all kinds of subtle variations on the themes covered in this chapter, and some less-subtle ploys that will only become obvious after some virus writer explores techniques not yet used. However, it is important to note that the most successful viral programs, in terms of numbers of infections, are not necessarily the new models, but the older and often less-sophisticated versions. On the one hand, this indicates that novelty is not necessarily a viral survival factor. On the other hand, it points out, in a rather depressing manner, that most computer users are still not employing even the most basic forms of antiviral protection.
This has been a long introduction to a complex subject. Now that we have considered the technological basis on which current malicious software is based, it is time to look at the technology for countering it, and see how best to use it.
IN THIS CHAPTER:
What is anti-virus software? Better, what do you want (or expect) your anti-virus software to do? When we ask this question in a seminar context, the first answer is almost inevitably, "To stop viruses". Here comes the first disappointment: anti-virus software can't "stop" viruses, any more than a police station can "stop" crime. In a perfect world, a global social engineering programme (as social scientists understand it, rather than hackers) might attempt to educate computer users of all ages and persuasions in the mysteries of "ethical" computing. However, it is not realistic to expect the application of a purely technological approach to individual systems to solve what is essentially a special case of a worldwide social problem.
If we take this discussion a little further, we generally find that what the respondent to our question actually means is "to stop viruses on my desktop or on the desktops of my users". Well, we can't all be altruists. Most people just don't want to be bothered with malware at all; they want anti-virus software (and maybe other defensive measures) to take care of all virus protection totally transparently. Such solutions might work for some individuals, but really would not work at all for corporate institutions, even if they were technically feasible. In real life, of course, they are not at all feasible. It can be proved formally that it is not possible to detect all viruses, let alone block them.
Total transparency is approximately equal to a process like this:
A moment's thought suggests that this process might not be the optimal strategy. It's probably based on the assumption that A is an evil malware author sending malicious programs to B, a potential victim. Viruses and worms are sometimes injected into the mainstream (into the wild, if not Into the Wild) this way. However, most people who receive worms and viruses get them from people they trust-colleagues, friends and relatives - people who are indeed fellow victims, not villains. If A is an innocent party, it may damage a social or commercial relationship if communications are bounced back with no explanation or a curt automatic message, or simply not acknowledged. Wouldn't B want to let A know that A has a problem (and, if possible, what it is, and even how to deal with it)? Wouldn't B want to know that a trusted party has become (knowingly or unknowingly) a vector for incoming malware? You may recall that we said in Chapter 2 that anti-virus technology is not all about keeping your own computer safe. Alerting other people to the fact that they're virus victims is not an act of altruism (or not exclusively); it can benefit you too, in the following ways:
Perhaps we have been asking the wrong question here. We need to broaden it from "What do you want anti-virus/anti-malware software to do for you?" to "How do you want to manage virus incidents?" When we ask this, we often find that what people really want is based on unrealistic expectations of the software available to them. We usually find that what they really, really want is a combination of some or all of the following goals:
The question then becomes, how realistic are these expectations? While some are attainable, they are not attainable by all anti-virus software, they are not necessarily fully attainable by anti-virus software, and they are not necessarily reconcilable with the desire for complete transparency.
The degree to which customer expectations are at variance with the technology available deserves more attention than we can give it here. The European Institute for Computer Anti-virus Research (EICAR) has undertaken an initiative to improve information security by a closer binding of customer needs (and expectations) and actual functionality. The first stage of the EICAR Anti-Virus Enhancement Program (EAVEP) is a survey, presented to the EICAR conference in March 2001, of the views of network and system administrators, security officers, and other technical decision makers on what weaknesses they perceive in current technology. Similarly, the Anti-Virus Information Exchange Network (AVIEN) is increasingly drawing attention to the shortfall between what vendors are happy to offer and what customers really want.
Virus management is often seen as exclusively (or primarily) a desktop issue. Indeed, for a home user, this perspective offers probably the only way of looking at the problem that makes sense. In the corporate environment, virus management may be seen as (primarily) a networks/systems issue. However, the virus/malware problem ranges across desktop management, LAN management, and Internet/intranet/extranet management, as well as less obvious areas such as human resources management. Only by defining the problem globally is it possible to work towards holistic solutions that cross boundaries within the organization, rather than relying on piecemeal relief of individual symptoms. To this end, anti-malware technology and the functionality behind it are considered in some detail in this chapter. We will also consider how anti-virus technology might be better mapped to the client organization's needs. The chapter generally considers anti-malware technology in terms of functional specification rather than in terms of detailed implementation. After all, anti-virus vendors are unusually secretive about some aspects of the ways in which their products work. They are concerned not only with keeping proprietary code hidden from potential rivals, but also with staying a step or two ahead of the virus writers.
Management of viruses and other malicious software is sometimes divided into two main areas: proactive anti-virus measures and reactive incident management (sometimes referred to as "playing first" and "playing second"). Strictly speaking, this distinction is illusory. All anti-virus software is essentially reactive - that is, it exists only because viruses and other programmed threats existed first. That somewhat academic point aside, it is common to distinguish between virus-specific scanning or Known Virus Scanning (KVS) on the one hand and generic measures on the other, as if they were on opposite sides of the proactive/reactive divide. This distinction is also illusory. For example, change detection, the most commonly used generic approach, can be considered more reactive than a virus-specific scanner that denies entry proactively to a recognized virus by discarding it at the mail gateway.
The essential distinction here is between detection of viruses at (or before) the point of entry and identification of viruses after they have entered the protected environment. However, anti-virus software leans towards the reactive. The most popular technology is based on the identification and disinfection of a virus either at the point of entry or after it has entered the system. We prefer to consider the technological aspects of anti-virus software in terms of three main approaches: pre-emptive measures, virus-specific measures or KVS, and generic detection:
Creating policies or educating users in safe practices can reduce the risk of becoming infected, even when a virus enters the organization. There are many possible pre-emptive measures:
Such measures can be very effective at addressing aspects of anti-virus damage that reactive anti-virus software doesn't deal with very well, and we'll return to them in due course. However, they have two major drawbacks. First, they may impair productivity. Second, we should recall the latent virus problem. In this scenario, the virus is inactive in the protected environment. However, since the virus has not been detected or known, it may become active again if that environment is modified or if an infected file or disk is transferred to a vulnerable environment. (Such a transfer of infected material via an uninfectable environment is sometimes referred to as heterogeneous virus transmission.)
Some measures are similar in intent but less effective in practice. For example, it's possible to reduce the risk of macro virus infection in Word 6 and above by disabling auto macros and using built-in or add-in measures to block all macro execution unless explicitly permitted by the user (or authenticated by digital certificate, for instance). However, it is not possible to eliminate the risk entirely. The binding of the underlying macro language to the application interface and infrastructure precludes the complete "turning off of the macro language that would be necessary for full security.
You can use access-control software suites to minimize the possibility of a virus or Trojan gaining entry, by enforcing authentication of program files, disks, users, or any combination of the three. (By program files, incidentally, we imply not only unequivocal applications but also data objects, such as Word documents, that can also contain program code in the form of macros.) This approach is sometimes combined with virus-specific or generic scanning. Applying such a "moat and wall," or multilayered strategy, can be much more effective than using only one of these approaches, but the strategy's success in avoiding threats has to be balanced against the probable impairment of performance that multilayering entails.
One formerly popular scenario works like this: individual workstations belong to a domain or group of machines on which access-control software is installed. The software blocks the use of unvalidated diskettes on standard workstations. To be validated, a diskette must be authenticated on a "gateway" machine, which checks and modifies the diskette and its contents so that it can be used on workstations within that group. This series of checks may include scanning with one or more anti-virus scanners (or other anti-malware measures), in which case the operation is hybrid rather than purely proactive. This scenario can be regarded as an instance of what is sometimes referred to as integrity management. This is a more systems-based approach to managing malicious code that is not entirely focussed on specialized virus-specific software, even though it is likely to involve the deployment of such software.
We should, however, note a significant difference between access control as it is used in this example and access control as it is sometimes understood by systems administrators. Access-control systems determine the appropriate allocation of access privileges to individuals, and grant systems access to authenticated individuals. In other words, if the system recognizes an individual, he or she is allowed to use that system to the extent that the user's privileges allow. However, as by now we hope to have convinced you, authenticating the individual is not enough in the virus/malware arena, since viruses and worms are usually spread (unwittingly) by trusted individuals. Confirming the identity of the individual doesn't tell us anything about his or her good intentions, though we would usually hope that the human resources department has applied the appropriate checks. It tells us still less about the individual's competence at following security guidelines, or the currency and acuity of his or her anti-virus measures.
In short, trusting the individual is not necessarily sufficient justification for trusting modifications in the local environment introduced by that individual. Organizations are aware of this principle in other contexts; for example, a group with a change management policy will not authorize a privileged individual to make changes in a "live" environment without the appropriate checks and balances. However, many administrators (or their managers) lack sufficient knowledge of the virus field to enable them to apply the same principles in the area of code integrity management. Like most computer users, they fall into the trap of trusting the object because they trust the individual. "I don't open attachments from people I don't know", usually means, "I do open attachments from people I do know". The problem here is that much of the difficulty of managing current worms and viruses lies in the fact that most people will not receive infected material from strangers with malicious intentions. Rather, they will receive them from people they know and trust, and who are unaware that they are being used as a channel for transmission of malicious code.
There are a number of ways specific to the hardware by which to secure a PC. Most of these involve the so-called CMOS (Complementary Metal Oxide Semiconductor) settings, pieces of information stored in CMOS memory that govern how your computer runs at a basic level.
The first, and easiest, is the boot order sequence. On older computers, the default CMOS setting would be to check for a bootable disk in the first floppy drive (A) of the machine, and then, if no diskette was found, to boot from the hard disk. This method, of course, allowed boot sector viruses to infect machines if an infected floppy had been left in the drive of the machine when it shut down or rebooted. Later, it became possible to configure a setting to change the boot order so that the hard drive was always accessed first. It was even possible to force the computer to boot only from the hard drive, regardless of whether there was a diskette in the first floppy drive and whether it was bootable. Nowadays there are other selectable settings, including booting from a CD-ROM or over a network.
An additional security feature is password protection. This feature is of little use in antiviral protection. In some cases, it is of little use at all. We recall one computer where the password protection didn't appear to protect anything except the password. However, in most cases, modern CMOS passwords prevent anyone else from booting up your computer and using it in your absence.
NOTE
Tbis CMOS password protection is by no means absolute. It is relatively simple for a knowledgeable person to remove tbe password protection from even tbe best of systems, and ways of doing so are widely documented. The DISKSECURE anti-virus program bas a password protection feature that is much harder to get around, as do other programs that encrypt some or all of tbe hard disk.
It is often held in the security field that whatever software can do, software can undo. Therefore, any anti-virus software can be circumvented by a virus that targets vulnerabilities in the software. Viruses that target weaknesses in specific anti-virus software are sometimes called retroviruses, although this mechanism is not an altogether appropriate analogy for the biological model from which it is borrowed.
NOTE
In biology, a retrovirus contains RNA (ribonucleic acid). Genetic material from the virus is inserted into the host's DMA (deoxyribonucleic acid). Computer retroviruses, however, conceal their presence from antiviral agents in ways that are product-specific. They might he described as anti-virus-specific.
The converse also holds: no virus is impossible to remove from an infected system, although removal is not always cost-effective and does not always restore the system to full functionality.
There are some hardware antiviral measures. Indeed, the simplest one is the write-protect tab on floppy disks and certain types of removeable cartridge drives. Virus researchers have long wanted someone to make hard drives (or CD-RW drives) with write-protect switches, but this approach has not found favour. There are also some specific examples of antiviral hardware. Most are activity blocking systems - very fancy forms of write protection. One involved a very specific configuration of the motherboard and the system support chips. Various "secure" computers have also been built. None of these systems has had much success.
Chipaway was a simple antiviral system designed by Trend, makers of the PC-cillin antiviral packages. Chipaway, as the name suggests, was intended to be included with the BIOS programming in the ROM chip. It primarily addressed some basic types of boot-sector viruses. Someone at Trend, though, had either an unfortunate sense of humour or a lack of facility with the English language. When active, the Chipaway system would tell the user that his or her computer had the Chipaway virus. Other antiviral companies had many calls asking about the Chipaway virus - which, of course, did not actually exist.
A more recent device uses a hardware/software hybrid approach to the problem of worms and viruses. StopIT consists of an internal PC card and a hardware device that sits between the modem and the Internet. Network traffic is scanned against an automatically updated internal database of definitions. Whether this product offers improved security and/or performance over an on-access scanner is a debatable question, and one that doesn't seem to have been taken up.
It is frequently suggested (with a variable degree of flippancy) that the easiest way to render an environment virus proof is to avoid Microsoft operating systems or applications. While there is enough truth in this assertion so as to be embarrassing to Microsoft, this solution is rather like reducing fire risks by removing all oxygen from the atmosphere. Right now, most of the market for desktop and laptop operating systems and network file servers seems to belong to Microsoft. Even in more rarified atmospheres, such as those occupied by firewall servers and web servers, Microsoft has a substantial presence. In environments where Microsoft's presence is less obvious, such as the Macintosh world - Macs probably still constitute the nearest thing to a competitive operating system - Microsoft applications (including Word, Excel, Outlook, and Internet Explorer) are almost as predominant as they are on PCs. Even the Linux success story owes something to the availability of a Microsoft-compatible Office suite (StarOffice).
NOTE
You might have noted certain statements in this hook that indicate a lack of enthusiasm for Microsoft software. Are we saying these things because we are fanatical Mac, Linux, VMS, OS/400, or CP/M devotees, and we seek to trash the evil empire? No. We say these things because they are true. And because we have been paid enormous sums to spearhead a return to dominance of the Commodore Pet.
There is some software, the use of which places you at higher risk of virus infection. This is a simple fact. As we have noted, the more widely an operating system is used, the more likely it is that someone has written a virus for it. The same is true for application platforms, such as email programs and word processors. But there are other factors that can increase or decrease risk. What you choose to use is, of course, up to you. But we would be remiss in our responsibility if we did not point out that certain software designs are more dangerous than others.
Microsoft Windows is the most widely used desktop operating system by a considerable margin. It is, therefore, the one currently most subject to attack, in terms of the number of people attempting to produce malware. However, specific strategic factors render Windows more vulnerable than it needs to be. It may be necessary to point out that the assumption of the overriding importance of security is far from universal, except possibly among security specialists. Financial analysts are inclined to resent the restrictions that a highly secure environment imposes on the pursuit of business aims. Management often pays lip service to the importance of security in meetings and reports, but cuts corners on implementation. Computer users frequently resent the obtrusiveness of most security measures.
Windows continues to stress ease of use above any consideration of security, despite having outgrown its origins on single-user systems, where security is rarely a primary consideration. Windows 95, 98, and Me are less secure than MS-DOS, in that they can give the user a sense of false security. Time and again, people tirelessly type in their Windows password, unaware that simply pressing the ESCAPE key would be just as effective for many systems. This lack of intrinsic security is less acute with Windows NT and 2000, which have the same basic security features as older multi-user systems, though an "out-of-the-box" configuration is not noticeably secure. However, this was often true of older systems, too.
Windows also tries, as much as possible, to hide system information from the user. In most cases, users can obtain information about the system and ongoing processes easily enough - if they know where to look. By default, the system automates many processes that allow access to the system. For example, network access and resource sharing are generally enabled by default, and must be turned off if the user does not want to make access available. This makes it very easy to set up networks, but it also means that access can be permitted over dedicated Internet links without the user even being aware of the fact.
Microsoft holds the source code for the operating system closed (as opposed to open-source systems) and has consistently refused to document a great many functions of the package. This is, of course, the corporation's right as a business with proprietary information, but it does mean that finding security holes is a matter of hit-and-miss testing rather than direct analysis of code.
Microsoft is trying to tighten the links between its operating system and its applications. This interrelation between platform and programs is behind a number of the recent email viruses. Outlook and Internet Explorer cannot be easily secured, since they use programming that is also foundational to the operating system. Making a change to the operating system can affect applications and computer operations in a variety of ways, and therefore patches for security bugs have to be made very tentatively and tested extensively before being released. More than once Microsoft has released a patch for one problem, only to create another. Microsoft also tries (not altogether unreasonably) to make the minimum change necessary to fix the current problem, often leaving related loopholes still open in the software. Where Microsoft offers a major fix, it may be either a fix to the wrong problem or so extreme as to reduce drastically the functionality of the product. The latter occurred with a security patch for Outlook, which turned a highly relaxed mail client into a monster that refused to allow access to any attachment with an .EXE filename extension.
Microsoft is not the only company in the world with software subject to security weaknesses, and it isn't even the worst. In fact, anti-virus software is often subject to analogous problems, for some of the same reasons. Vendors are aware that customers often value transparency above security, and may be tempted to set unsafe defaults so that an out-of-the box installation is fast and unobtrusive, but not very good at detecting viruses. For instance, the Novell version of a highly rated scanner (now extinct) by default checked only the standard system directories on a server. While it is reasonable to check files that are accessed by all users (such as LOGIN.EXE), it has to be remembered that on a competent server installation, everyday users don't have write permission to such files. In general, they can write only to directories they own or of which they share ownership, and these are the directories in which infected games, Word documents, and so on are most likely to be found.
There are some general guidelines of which you should be aware. The more automated a system is, the more it does for you without asking, and the greater the possibility of a security problem, particularly one involving viruses. The more difficult it is to look at the internals of a system, the less secure it is. The more flash and glitz on the surface, the less solid the underlying structure may be - although, the history of programming offers many examples of programs that are neither flashy nor stable.
In general, you can use Windows and reduce your risk of virus infection by using other software. Microsoft Word is almost the only platform susceptible to macro viruses; WordPerfect is largely free of them. If you want something that looks like Word, there is the StarOffice package, which is also less expensive than Word. Outlook is the major platform for email viruses, but other email programs are available. For example, Pegasus is a highly functional product available for free. Internet Explorer appears to have the greatest problem with active content; Netscape, Opera, Mosaic, and many others are safer.
Some of the problems with Windows do not allow for an easy solution. One of the recent email viruses used the shell scrap object file format. This format can contain just about anything: the Windows system will execute text, binary data, programming, and any active content in this format. In addition, Windows does not display the file extensions for shell scrap object files, even if you request that Windows display all file extensions. The icon for a shell scrap file differs very subtly from that for a text file; most users would not notice the difference.
NOTE
To see the difference for yourself, open Notepad. Type in some text (a word or two is fine) and then save the file in the C:\TEMP directory. Save the file under the names "test1.ini", "test2.txt", and "test3.txt.shs". Remember that you will have to put quotation marks around the filename or Notepad will just add .TXT to each filename. Now look at the directory with Windows Explorer. Note that the icons are superficially similar, although the Type column identifies them correctly. (You will have to select Details under the View menu in order to see the Type column: by default it is not displayed.) Note also that, regardless of your settings, the "test3.txt.shs" file will display as "test3.txt". You can force Windows to display the scrap object extension, but only by making a change to the Registry. (Edit the Registry entry HKEY_CLASSES_ROOT\ShellScrap from NeverShowExt to AlwaysShowExt. Remember to back up your Registry before doing any work on it: editing the Registry can get you in a lot of trouble.)
Microsoft's attitude regarding these security issues is interesting. In the late 1990s, the company was taken to task about the number of security problems associated with its product line. In one particular speech, Steve Ballmer reportedly admitted that the products were insecure. He said that Microsoft made insecure products because Microsoft made what the market wanted, and the market didn't want security. Ballmer went on to say that he could prove his assertion, given that Microsoft wasn't broke; if people wanted secure products, they would buy other products that were secure, and Microsoft would go broke.
All antiviral software fits into one or more of three main categories. Scanners read information on disk and in memory, looking for recognizable patterns characteristic of a known virus. Activity monitors examine operations as they occur in the computer, sounding the alarm when a possibly dangerous event happens. Change-detection software takes a snapshot of the details of the system, alerting the user when some modification has been made. In general, anti-virus software performs one or more of the following functions, according to the class of software to which it belongs and how it is configured:
What does disinfection mean? It certainly doesn't mean that everything is put back to exactly the same state it was in before the virus infected the host object. Some effects of infection or triggering of a payload can't be reversed, and others, such as Registry changes, while reversible, are not characteristically addressed by anti-virus software. A few vendors offer "single-shot" tools to remove well-entrenched viruses such as these rather than attempting to incorporate removal of such recalcitrant viruses into their main scanner.
Checksum disinfectors are unsuitable in environments where a virus infection is known to be present, suspected of being present, or could be present. This type of software uses checksum, CRC, hamming, or image calculations that must be done while the software is clean, since this software only tries to return the disk, drive, or program files to an "original" state. Even then, checksum disinfectors have a very low success rate and would undoubtedly fail any test created to measure a set of "cleaning" programs. Heuristic disinfectors are even worse; they sometimes harm "good" programs. While disinfection is often not recommended, in some situations you want to keep an existing program rather than replace it with an original copy, which may not contain setup information. In this case, you may need the services of a disinfection program that does not rely on a database of known viral programs. The chance of this situation happening is slight, but should it arise, "generic" disinfectors could be useful when ordinary disinfectors fail.
These basic types of anti-virus programs have a great many variations. You can run antiviral software as manual utilities (on demand) or set them up to be memory-resident and to scan automatically as potentially infected objects are accessed (on-access or real-time scanning). Some systems cover the entire computer and network in depth; others check only the likeliest areas in order to avoid requiring more processing overhead than the virus risk merits. The vital point to keep in mind is that no single antiviral program is the best for all situations. Software that is great for the data entry pool may be useless in the development office. You must understand both anti-malware technology and your own work environment in order to find the best fit. Many people are interested only in the "best protection program they can get" and do not want to endure any talk about what a virus is or how it works. They want to buy something that enables them to forget about the whole virus situation.
This attitude ignores three vitally important points. The first is that "the best" may not be good enough by itself. No security force would ever pick "the best" guard and then leave him to guard an entire refinery by himself. There is a trade-off between security and cost, but it often makes sense to use multiple antiviral programs - different products, of different classes, and at different operational levels.
Second, even within the limited realm of antiviral programs, data security software operates in many different ways. Thus, one type of security may be better in one situation while another may be better in a different environment.
The final point is that security, of every type, is always a "moving target," and the virus world moves faster than most. Not only are new viral programs being written every day, but new types of viral functions are being coded all the time (albeit at a much slower rate than the run-of-the-mill copycat viruses). Any developer who claims that its antiviral program "guarantees" protection against "all known and unknown" viral programs simply does not comprehend the reality of the situation.
There are two main sub-branches of the generic approach to virus detection: behaviour monitoring/blocking and integrity checking. Monitors and behaviour blockers remain memory-resident throughout a computing session and watch for suspicious processes. If they observe one, they sound an alert. They may, for example, check for any calls to format a disk or attempts to alter or delete a program file while a program other than the operating system is in control. They may be more sophisticated and check for any program that performs "direct" activities with hardware, without using the standard system calls.
Although the analogy should not be stretched too far, behaviour or activity monitors do suggest some characteristics, though not functions, of medical vaccines, being memory-resident and preventive in nature. In addition, blockers actually prevent the execution of the suspicious process. Unfortunately, legitimate programs often perform operations that might look very suspicious, such as writing directly to disk, modifying system areas, deleting files, and so on.
Activity monitors can detect "unknown" (that is, not previously identified) viral programs, and do not require a database of signatures of known viruses. They generally require less frequent updates than do scanners. Activity monitors do not require the same level of setup as do authentication or change-detection systems, and they may be able to function on already infected systems.
Despite some recent announcements, activity monitors represent some of the oldest examples of antiviral software. Generally, such programs followed in the footsteps of the earlier anti-Trojan software, such as BOMBSQAD and WORMCHEK in the MS-DOS arena, which used the same "check what the program tries to do" approach. This tactic can be startlingly effective, particularly given the fact that so much malware is slavishly derivative and tends to use the same functions over and over again. However, activity monitors demand more of the user. Because there is no absolute difference between a legitimate and illegitimate operation, these programs need constant reassurance that operations are legitimate. When they do detect a genuine malicious program, the decision as to what action to take generally remains with the user, who would much rather have the activity monitor deal with the problem automatically.
Also, viral programs that do low-level programming rather than use the standard operating system calls, or those programs that actually replace the standard system calls with viral triggers, may bypass activity monitors. In addition, while viral technologies such as stealth and polymorphism have little effect on activity monitoring, new approaches in viral spread require that new checks be added to monitors.
Activity monitors have a good chance to detect viral activity of new and unknown viral strains, but it would be very difficult to agree with those that claim to be able to detect "all current and future" viral programs. Unfortunately, activity monitors tend to encourage a set-and-forget mentality toward viral protection. You should avoid adopting this attitude at all costs. If activity-monitoring software is your protection method of choice, continue to keep up to date with viral methods and to test your software regularly. We suggest that you use it as a complement to other means of protection rather than as a substitute.
As with mainframe security "permission" systems, operation-restricting packages allow you to restrict the activities that programs can perform, sometimes on a file-by-file basis. However, the more options these programs allow, the more time they will take to set up. You must modify the program each time that you make a valid change to the system, and, as with activity monitors, some viral programs may be able to evade the protection by using low-level programming.
"Sandbox" products, such as SAFETNET, monitor Internet protocols (for example, SMTP, HTTP, and FTP) and/or applications (such as the Office suite), scanning code not for virus signatures, but for conformance with a security policy database. These products do not permit code from a monitored channel to run outside of them unless the code complies with corporate policy. Such applications have advantages in restricting the user's ability to subvert security, but require careful preconfiguration.
Integrity checkers (change detectors) look for changes in system areas and files compared to what one product calls a "baseline snapshot". A change detector examines system and/or program files and configuration, stores the information, and compares it to the actual configuration at a later time. Most of these programs perform a checksum or cyclic redundancy check (CRC) that will detect changes to a file even if the length is unchanged. Some programs will even use sophisticated encryption techniques to generate an authentication signature that is, if not absolutely immune to malicious attack, prohibitively expensive in processing terms, from the point of view of a virus. If a sufficiently broad overview of the system is taken, this signature will provide 100 percent effective detection of a viral infection, but it also may raise a number of false alarms.
NOTE
Strictly speaking, "100 percent effective detection" applies only if you can guarantee that the "day zero" baseline snapshot is of a genuinely clean system, that no malicious code is executed while the database is set up, and that the authentication mechanism can't he spoofed. In other words, it's not quite 100 percent effective.
The integrity-checking approach is fine for monitoring changes to static code such as system utilities, but hopeless for monitoring most Word documents, for instance. Furthermore, this approach works only if you can be sure that the system was clean when you took the "snapshot". Absolute certainty is not usually a possibility; in theory, even a day zero (brand-new) installation of the operating system might have been compromised before delivery. In the end, all generic measures either assume that you've blocked all the entry points or alert you to a possibility that you have malicious code on your system. The decision on how to react to the alert is generally up to you.
Authentication refers to strong encryption systems which both guarantee that a program is unaltered and identify its source. Change detection can be seen as a weaker version of authentication.
A sufficiently advanced change-detection system, which takes into account all factors including system areas of the disk and the computer memory, has the best chance of detecting all current and future viral strains. Even with the most esoteric stealth technology, a virus must change something in the system. Therefore, adequately broadly based change detection is the best bet for absolute detection of all viral programs - if you can put up with the false alarms.
NOTE
Some vendors have a problem with the term "fake alarm", pointing out, quite reasonably, that change-detection software is simply doing its job when it flags a change, irrespective of whether the change really is due to malicious code. In this context, an alert could be reasonably described as a false alarm only if it flagged a change where none had been made. Nonetheless, you must investigate each alert and take appropriate action. The increase in security (arguably, the software will detect all viruses) is offset by the probable increase in incident-management overhead.
Change detection has the highest probability of false alerts, since it will not know whether a change is viral or valid. Additional thought put into the installation of change-detection software will go a long way towards reducing the level of false-positive results. As always with security systems, there is a trade-off between the easy and the effective. The addition of intelligent analysis of the changes detected may mitigate this shortcoming.
Rob Slade frequently (all too frequently) receives a certain type of call from people who think their systems are infected. After some questioning, it generally turns out that they are correct, and they start wondering about how they got the virus, prompting Rob to ask about the last change they made to the system. "But that's just it," they say, "I just got the computer an hour ago!" Then it was infected when you got it: you' d better contact the store and tell them that they are selling infected computers.
This type of call is inevitably followed up 45 minutes later by another from the same, now totally bewildered user. "I called the shop," the user will say, in a mild state of shock. "They said that, yeah, they'd had the virus around and didn't know what to do about it."
We do not mean to leave the impression that all computer retailers are malevolent and ignorant oafs who don't care whether they infect you. But the plain fact is that knowing how to put a computer together and take it apart does not automatically give you the skills to identify and deal with computer virus infections. Most computer retailers or repair shops take some precautions, but few of them have any security expertise.
And, unfortunately, some truly don't care.
Change-detection software provides no protection, but only after-the-fact notification of an infection. It is, therefore, quite possible to install an infected program on your system and have it continue to infect other programs. The change-detection software will (or should) detect the subsequent infections, but will not identify the original culprit. However, deductive reasoning, along with the software's assistance, may help.
You must inform the software of any changes you make to the system; otherwise the change-detection software will generate a false positive. This means that you must have sufficient knowledge of the system to know when you are making changes. Each invocation of the DOS SETVER program, for example, changes the program file, whereas setup changes made to an older version of WordPerfect sometimes alter the program file and/or change an external data file.
The increasing complexity of graphical operating systems with extensive networking capabilities implies that simply opening and closing windows may make significant changes to log files, system files, configuration files, or the Windows Registry (or its equivalent). Opening a Word document and then closing it again may result in the creation of temporary files, adjustment to the global template and other templates, and calls and changes to macros and customizations associated with the menu structure. It is not practical for an external program to assess the "legitimacy" of such transactions. In fact, it is often impractical for the operating system or a vulnerable application itself to distinguish generically between legitimate and illegitimate code. The only long-term solution - short of reengineering operating environments and applications - is to conform to a model whereby code and data are properly separated and users' access and modification privileges are properly defined.
As with scanning software, change-detection software may not see changes made and hidden by stealth viral programs if the software inspects file sizes alone.
There are numerous implementations of change-detection software. Some versions of this software run only at boot time; others check each program as it is run. Some of these systems attach a small piece of code to the files they are protecting, and this may cause programs that have their own change-detection features, or nonstandard internal structures, to fail. Some packages protect only system software; others protect only application files. Some change detectors keep the signature file in the root directory, others in the "local" directories. Some allow you the option of keeping the file on a diskette offline and out of the reach of viruses that might try to damage the file.
An approach sometimes used to reduce the processing overhead associated with virus-specific scanning is to use a hybrid scanning approach, where a change detector is used in conjunction with a virus-specific scanner. An object is first checked for changes; if the software observes no change since it last scanned the object, or since the scanner was last updated, no further action is necessary. However, if the object has changed, the scanner has been updated, or the object has not been scanned previously, the software invokes the virus-specific scanner.
Virus-specific software is effective as long as Virus X (or something closely enough related to it to be detectable by the same scan string) is in the product's current virus definitions database. If you're hit by a virus that your scanner doesn't recognize, you may find that it's a very dumb piece of software indeed. In fact, although we have distinguished between known-virus scanning and generic scanning, all KVS programs are actually hybrid, since all scanning requires a degree of heuristic analysis to work in real time.
Scanners, particularly signature scanners, are currently the most popular of antiviral software. This popularity is probably due to three factors: the fact that viral programs are specifically identified, because disinfecting software is included with most scanners, and because it's easy to play numbers games with signature-scanning programs.
Scanners can find infections only after they occur, but this does not mean that scanners cannot play a preventive role in protecting the system. If you use properly maintained scanning software consistently to check each disk or file that enters a system (as should happen with an on-access scanner), you greatly reduce the chance of allowing a viral infection to enter your system.
Scanners look for known viral scan strings. Because of this, scanning software usually will detect only known viruses and must be updated regularly. Most commercial scanners now have provisions for online updating on a weekly, or even daily, basis. Some scanners will alert users to programs that are "close" to a given signature. (The MS-DOS scanner F-PROT uses at least two signatures to identify a given virus and has always been particularly good at identifying "new" variants.)
There are tens of thousands of PC viruses and variants known at the time of writing (depending on what measurement criteria are used). When a scanner checks for all those viruses and variants, checking for every byte of viral code each time would impose a huge processing overhead. To keep this overhead to a minimum, scanners check for the shortest search strings they can afford and deduce the presence of a given virus accordingly. Scanners may apply a number of heuristics according to virus type, including simple virus string scanning (a long search string in a known location) and complex wildcard searches. In fact, as we've pointed out previously, virus-specific scanning as it is currently implemented is essentially heuristic. The processing overhead of comprehensive checking makes exact identification too resource-intensive for general scanning. Virus-specific scanning is most useful for confirming a possible infection flagged by heuristic scanning, or in support of file disinfection, where the aim is to restore the file to its pre-infected state.
However, the term heuristic analysis is also applied to the process of stepping through a program before it is executed and searching for suspicious code. In fact, an on-access scanner in heuristic mode is very nearly a cross between a known-virus scanner and a monitor. If such a scanner is configured to disallow execution of suspicious code (as is normal), it is for all intents and purposes a behaviour blocker as well. In this mode, a scanner effectively leaves the question of what you do about the suspicious program up to you. That is, you can remove it, take whatever steps are necessary to verify the presumed infection, assume that it's a false alarm and exclude the object from scanning, or reconfigure the scanner so that the offending program is not flagged or blocked from execution.
Heuristic scanning, an analysis of suspect code or files based upon possible activities rather than specific patterns, is nowhere near being a dependable form of viral detection. A great many programs, including antiviral software and other powerful utilities, have been accused (falsely) of being "suspicious" when checked by an aggressively heuristic scanner. At the same time, such scanners may fail to catch a number of other malicious programs. Thus heuristic scanning would fail miserably at the sort of evaluation criteria used to judge KVS software.
It would, though, be a great pity to inhibit the development of heuristic scanning software. This field is really the application of "expert systems" to antiviral software. Using a heuristic scanner is a little like having an "expert" antiviral disassembler check the code for you. Along with hoped-for advances in change detection, this field's development bodes well for the future of antiviral software. Indeed, not only does a heuristic scanner identify suspect viral programs, but it may also, with only minor additions, detect some Trojans and other malware too. A heuristic scanner looks for covert file modifications, unusual calls to the system or to networking software such as the WSOCK32.DLL library and email clients, or other activities associated with virus attacks. When the number and type of such activities exceed a "threshold of tolerance", the software flags the program under examination as being infected. In general, scanners are not either KVS or heuristic; most scanners are virus-specific by default, but can perform heuristic analysis too, as an option. This default mode is probably inevitable, given the additional processing overhead that heuristic scanning software entails.
On-Demand Scanning On-demand KVS scanners run a scan on one or more mounted disks (or individual files or folders) when the user runs them. They can also scan more or less automatically at set times using scheduling software. A primitive implementation of this approach is to run a scan at bootup by calling the scanner from AUTOEXEC.BAT (on DOS-based machines) or using an equivalent script-based approach. Many modern scanners have built-in scheduling and scan in the background by default at set times or when the system is comparatively idle.
On-demand scanners vary widely in their functionality. The fine points will be considered in much more detail when we evaluate anti-virus software.
On-Access Scanning On-access scanning, as the name suggests, tests for the presence of a virus every time an object is accessed. This may occur when a file is read or when a program is executed. On-access scanners are also referred to as resident or TSR (Terminate and Stay Resident) scanners, since in the DOS world the programs had to stay resident in the background in order to operate. Usually the terms on-access and memory-resident are applied only to known-virus-scanning programs. Activity monitors must, by their nature, be resident at all times. Some change-detection software systems also check "on-access", but usually aren't seen as a separate class of software. However, the hybrid change-detector/virus-specific scanner model described earlier suggests that such scanners may be much more useful than their comparative rarity suggests.
In the days of DOS, slower processors, and the 640KB memory limit, resident scanners were sometimes seen as more trouble than they were worth. These programs must, after all, consume memory space and processor cycles every time the system accesses a program or file. In these days of bloatware, and the attendant necessity of huge memories and fast processors, on-access scanners are not so often perceived as significantly draining resources, perhaps because their performance in this respect is not consistently benchmarked.
On-access scanners are often seen as the best form of antiviral software. After all, they operate all the time and do not require any intervention by the user. Nobody has to remember to scan the disk every Monday morning, and a virus infection on Tuesday doesn't have most of a week to spread before the next scanning run. In addition, many modern on-access antiviral programs add capabilities to check automatically any material that comes in via the Internet and Web. On-access or real-time virus-specific scanners don't have to be executed as a conscious act by the user: they're implemented as DOS TSRs, Windows VxDs, Macintosh control panels, and so on, and sit in memory. Such scanners don't usually (by default) scan whole volumes (though they might check floppies as they hit the drive); they scan individual files as they're accessed. This makes them useful for keeping a clean system clean (as long as they're updated regularly), but not very suitable for performing batch disinfection of a heavily infected system.
DOS TSR (memory-resident) scanners are generally rather restricted, mostly due to processing overheads and memory limitations. They are rarely aware of macro viruses (which is reasonable, since some macro viruses cannot normally be executed in a DOS environment). Such scanners are usually unable to detect complex polymorphic viruses, and in modern GUI environments such as the various flavours of Windows, are of secondary importance. Windows-hosted on-access scanners normally remain resident even when a DOS shell process (DOS box) is spawned within the Windows environment. They do still have a use on Windows 9x/Me PCs when booting directly into DOS - for instance, they can be used to disinfect viruses, recover data, or aid in reconfiguration. It's unusual however, for a TSR scanner to remove viruses as well as detect them.
NOTE
TSR stands for Terminate and Stay Resident, referring to a DOS-specific system call (INT 21h, Function 31h). Characteristically, the call is used to load a utility or driver into memory so that it can he reentered through a hardware or software interrupt.
Windows 16-bit and 32-bit VxD (virtual device driver) scanners are also memory-resident, but are not subject to the same limitations as DOS TSRs. They usually detect (almost) the same range of viruses as an associated on-demand scanner (and often use the same virus definitions file). Some VxD scanners can remove viruses on the fly as well as detect them. They may also be capable of enhanced detection similar to that offered by advanced on-demand scanners. Unsurprisingly, these capabilities may entail a noticeable processing overhead. Scanners implemented as Macintosh control panels, system extensions, and so on are approximately equivalent to Windows 95/98/Me VxD scanners. In Windows NT and 2000, on-access scanners are implemented as system services.
However, some serious limitations are ascribed to resident scanners. On-access scanners have sometimes had poorer detection capabilities than their on-demand, or manual, counterparts. The memory resident and on-demand components of a modern anti-virus suite may use the same definitions database and still not score identical results with the identical test set. This is particularly true in respect to encoded and archived file formats. These formats are the very ones that are used to transfer material over the Internet, and therefore there is a rather cruel irony: the antiviral systems that are supposed to provide protection against material from the Internet may perform very poorly in doing so. On the other hand, some modern memory-resident scanners, freed from the tyranny of DOS, may be configurable to include all the functionality of an on-demand scanner. For example, such scanners may be configured to perform heuristic analysis, recursive scanning of archived files (nested zip files, for example), macro and polymorphic detection, disinfection, and on-the-fly decryption of files using low-grade encryption algorithms. Clearly, accepting all these options will have a processing overhead.
Another point in regard to on-access scanners is that, as with any scanning software, the system is only as good as the definitions (scan strings) database. The fact that resident scanners operate all the time does not mean that they update themselves. Indeed, it is important to update on-access scanners more frequently than on-demand scanners, since users tend to rely more on them and dismiss other indications of virus infection.
All of the preceding types of antiviral programs are available in desktop, or stand-alone, versions. Indeed, for many years, stand-alone antiviral software was the only real choice, and network versions merely added some frills to ease updating of files.
Back when LANs (local area networks) and viral programs were both fairly esoteric phenomena, people used to ask if viral programs would work on a network. "Why should they?" would be the reply. "Nothing else does".
Well, times and technologies have changed. Incompatibility is no longer an issue, and therefore no longer any protection. Within limits, viral programs will work, and infect, on networks as well as on stand-alone machines. Indeed, stand-alone machines are the minority in most corporate organizations. All modern operating systems are to some extent multi-user, and the distinction between workstation and server is no longer absolute.
LANs do have certain advantages. Boot-sector infectors, for one thing, will not infect across networks. (Note, however, that we are not claiming that they cannot be transported across networks.) Since LANs have cut down on diskette exchange and "sneakernet", the risk of infection from what was once the most successful class of virus is vastly reduced. However, the risk has only been reduced, not eliminated. And this reduction has little impact on the spread of file infectors and macro viruses.
Novell has been the target of a number of accusations in regard to antiviral security. Understandably, the corporation has been a bit touchy in response. Let it be said, then, that no known virus has successfully been able to subvert Novell's security attributes - when they have been properly implemented.
That said, it must be admitted that very few LAN administrators know how to set up proper security. The establishment of appropriate rights, privileges, and attributes is a task that not all mainframe systems operators understand, and few network managers take the time to ground themselves thoroughly in security concepts. Microsoft does no better; some security experts have opined that the reason it is so hard to understand the Microsoft networking security model is that Microsoft networking does not actually have a security model.
Network security, over the years, has also received some knocks from deliberate attacks. A group of Dutch hackers wrote a program that would look for passwords on the network traffic. Another program exploited an unusual bug in the LOGIN program in an attempt to gain SUPERVISOR access. Both of these programs, however, required physical access to a node on the network for a length of time. Neither was in any way viral.
One Novell-specific virus is known. The GP-1 virus is rather old. It does not manage to break Novell's security and infect properly protected programs. It is designed, however, to reside on workstations and collect passwords as network users log in. These passwords are then broadcast on the 'Net, supposedly to a receiver program. The receiver program has never been found. (This circuitous means of stealing passwords seems to be an unnecessary bit of overkill: it is quite easy to write a program to obtain any passwords transmitted over an Ethernet backbone.)
Most microcomputers in the business environment nowadays are connected to some form of LAN, and the majority of these are also connected to the Internet. You may have noted that the discussion of antiviral software so far has not addressed the use of local area networks. There are two reasons for this. The first is, basically, that any antiviral program can work in a microcomputer attached to a LAN almost as easily as in a microcomputer that is not attached. The second is that LAN-specific antiviral programs follow the same basic operating principles as their desktop counterparts. Indeed, on Microsoft networks, the server and the workstation might be running essentially the same operating system and the same anti-virus program. The same does not apply to Novell networks, by the way. Server-side scanning in such an environment is done with a Novell native executable (a NetWare Loadable Module, or NLM). In principle, though, any server that can be mounted as a virtual drive (irrespective of its native operating system) can be scanned with workstation software from an account with appropriate privileges. Indeed, this strategy was at one time the only way of scanning most servers.
Many LAN functions do not vary among systems. For example, email is almost universal these days. Some of the specialized LAN anti-virus programs use email, text paging, and SMS (Short Messaging System) messaging to alert the administrator to a security breach or possible infection. This is an admirable feature - and one that, with a minimum of time and batch or script programming skills, can be duplicated on many networks. (The more homogenous the network environment, the easier it is in general to introduce such technologies reliably.) The same can be said of centralized logging of scanning and audit reports, updating of scanners from a central resource, and a number of other supposedly advanced features. One need not accept an inferior antiviral product simply because it has LAN capabilities. In fact, since most developers assume a Microsoft network when designing specialized network anti-virus distribution and remote management software, organizations that haven't wholeheartedly embraced Windows as a server operating system are often forced to introduce home-brewed substitutes.
The network administrator can find many uses for LAN features and functions. These do not necessarily require specialized programs for LAN antiviral protection, although small utility programs might assist an administrator for some uses. Each function requires some level of programming skills, and some features and functions may tax the limits of intermediate-level computer users. However, LAN administration is not for the faint of heart anyway.
So you want to make sure that all copies of your antiviral programs are kept up to date? Well, why not just have one copy? It may be possible to call the antiviral program from the server with a memory-resident program on the workstation. Unfortunately, this approach can be network-intensive.
If you really do need copies on each machine, there are a number of ways to ensure regular updates. A solution could be as simple as invoking a copying process when a user signs on to a client-server LAN. In fact, administrators routinely use such techniques as a fallback for sophisticated self-updating mechanisms that don't always work. Small utility programs could compare file dates, or a copy program might only copy a source to a destination if the destination is older than the source.
If you want to collect all audit or report logs to one location, nothing could be simpler. Invoke the antiviral program from a batch file. The batch file will also create a file noting the workstation, date, and time. You can easily append both the identification file and the report file to a master report file in a central location or server. Generally, this appending requires a simple copy function. If you have any problem creating a master file, you can collect separate files in one directory, or in subdirectories for each workstation.
Many antiviral programs will return one code or error level if they find a virus and another if they don't. You can use these codes to decide whether or not to send a mail message. Voilá! We have an automated virus-alert reporting system that can send a warning to the LAN administrator or to the security specialist. The message can be a simple, "Come look at Larry's machine". Alternatively, the report log generated by the anti-virus program could be written to disk and sent as well. Most LAN email systems write messages as a text file in the first place. The log file can simply be sent as a message every time it is run (similar to the collecting of reports at a central location), or, since you really only want the exception reports, sent only if the "found something" flag has been set.
It may be desirable to check for the presence or activity of resident activity monitors or scanners. The better antiviral packages, which contain resident program components, also contain programs that will check for the background program. You can run these checking programs during login on a client-server network - and log out the workstation user if the checks fail.
Generally, an intranet is simply a local or wide area network that makes extensive use of Internet (TCP/IP, Transmission Control Protocol/Internet Protocol) and particularly Web (HTTP, HyperText Transfer Protocol) technologies. Most of the points relating to LANs apply also to intranets.
One additional point should be made: TCP/IP is a layered protocol. For example, web pages may contain many different types of content, transferred by HTTP standards. The HTTP-formatted material may be sent over the network within TCP packets. The TCP packets are probably physically transmitted inside Ethernet packets.
This means that different types of data may be encapsulated inside other types. Therefore, antiviral programs have to be able to analyse material in some depth, particularly if a program is examining material on the fly. As we noted with on-access scanners, the more layered the system, the more likely it is that scanner developers will take shortcuts to avoid slowing down and blocking network traffic.
The most obvious point about an intranet server, though, is that like any other file server, it can contain infective and infected files, irrespective of whether the server itself (or its operating system) is vulnerable to the malware in question. You therefore must protect the server with much the same anti-virus measures as you would a LAN server. The most common intranet platforms are addressed by anti-virus vendors as regards server-hosted solutions.
LANs and intranets usually are controlled by a single organization. As one progresses into the world of wide area networks (WANs), that control may lessen. WAN links are generally provided by an outside utility, and may in fact be shared among a number of enterprises. Therefore, WANs may entail additional security considerations.
Most of these security vulnerabilities do not relate to virus infection or risk. However, to the extent that outside users communicate with the network, there are additional sources of infected files or objects, and administrators are obliged to take appropriate measures.
Aside from the problems of a layered network environment, there are few special considerations in protecting an Internet server from virus infection. Arguably, if you have vulnerabilities that allow someone to submit a virus infection to your server, you have far greater security problems than virus infections. But virus infections do happen.
However, you should bear in mind one factor when considering virus protection for your Internet servers. A server will be distributing files and objects to users both within and without your organization. As with any other file server, an Internet server may carry material infected with latent viruses - code to which the server itself may not be susceptible. When you are implementing server-side protection, detection of native viruses is unlikely to be enough- Distributing an infected file can lose you a lot of goodwill. Servers deserve extra protection on the basis that, by providing infected files to outside users and customers, you are advertising that you are not competent to protect yourself and others, and are therefore to be avoided.
The theory is an obvious, and even logical, one: if you want to keep viruses away from the desktop, examine everything before it gets to the desktop. Therefore, if you scan all materials as they come through your gateway to the Internet, you can keep yourself clear of all known viruses.
The idea is certainly attractive. You only have to install antiviral software at a single chokepoint, and it will deal with everything - file viruses, macro viruses, email viruses, and malicious web pages - before anything ever reaches your users. Updating desktop machines becomes less important as long as the scanner at the main entry point is up to date.
Unfortunately, the theory has a couple of problems. Diskettes, while not as important as they used to be, still exist. Viruses can come into the organization on CD-ROMs. And email viruses usually spread so fast that they have run around the world 17 times before anybody has updated a scanner. (For this reason, the question of the location of the scanner to be updated actually becomes academic. But it's still easier to update one gateway scanner than a whole bunch of workstations.) Still, the argument holds that the best single point to protect is the desktop, since it is the intended target of almost all viruses (including boot-sector viruses, which are difficult to detect anywhere else). On the other hand, the stricture against putting all the eggs in one basket also applies. A single-point solution is a single point of failure, so it's best not to think of this as an "either/or" proposition. Two layers are better than one, especially if you use different products at the gateway and at the desktop.
Still, gateway scanning can catch most carriers of infection. Nevertheless, you should check a few points before you sign up. Be sure that you know what the system will do when it finds an infection, and be prepared to deal with it. Does the software just alert the administrator? Alert the user? Quarantine the file? Delete it? Just stop working?
Real-time gateway scanners, like all real-time or on-access scanners, take shortcuts in order to increase scanning speed. Remember that detection is a weakness in all such products. Also note the performance itself. Gateway scanners have to check everything that is coming into your LAN or WAN, and you need a box that is big enough and sufficiently powerful to handle the task.
In addition, remember that Internet traffic is encoded, and therefore in a sense encrypted, in a variety of ways. Make sure that scanning accuracy and performance speed remain high when scanning encoded, archived, and compressed materials. The software also needs to handle layers of encoding and nested compressed files. Unless the package can deal with 8-to-7-bit conversions, uuencoding, xxencoding, MIME, base64, zip, arc, arj, lha, and all the other possible file format complications, you need to make stern decisions about quarantining or discarding files that can't be scanned. Otherwise, use your second-line defence at the desktop to plug the gaps.
Firewalls have become the magic word in Internet security to many people. While they are valuable and useful tools, they are not silver bullets. Firewalls are complex and poorly understood utilities (or suites of utilities), requiring constant tuning in order for them to remain effective. Like virus-scanning software, they only protect against known attacks, and not all of those. Like a gateway scanner, they don't protect all vectors.
At its simplest, a firewall looks at where a packet is coming from, where it is going, and what type it is, and then makes a send/trash decision. This type of firewall is generally known as a filtering router. At a higher level, some firewalls examine the packet type and then do additional analysis and negotiation on behalf of the user. This activity is usually referred to as proxy or application service; the proxy server is interposed between the client and the remote application server. However, the same firewall can maintain both filtering and proxy services.
There are plenty of books on firewalls. The classic is generally thought to be Firewalls and Internet Security by William R. Cheswick and Steven M. Bellovin (Addison-Wesley, 1994), but the second edition of Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman (O'Reilly and Associates, 2000), is more thorough and addresses today's technology. In any case, we will not try to write another firewalls text here. We will, however, make two points.
Firewalls, especially proxy firewalls, do perform somewhat the same function as virus scanners (both types of program are essentially filters), so adding the functionality to a firewall does make some sense. However, the analysis done by a firewall is not really the same as the full, byte-by-byte reading of an incoming stream that a scanner does. In principle, a firewall is concerned with scanning packets for source addresses, destination addresses, and port numbers rather than the details of the whole stream. Even simple signature scanning requires that the data stream is identified as a program and that the signature be found in the right place (which implies assumptions about the form of the program). Therefore, adding virus scanning to a firewall may seriously slow performance of the network connection as a whole (this drag on performance is sometimes called latency).
In addition, note that firewall scanners are subject to all the same problems and limitations discussed for gateway scanners. Some firewalls (Firewall-1 is a well-known example) can be used with virus scanner plug-ins. Since anti-virus technology at the perimeter works best with store-and-forward technologies (especially email) where the user doesn't notice reasonable latency, some vendors have found it easier to separate the firewall and virus-scanning functions onto separate servers. Sometimes the term viruswall is used to describe a firewall-like server that focuses on real-time virus scanning rather than packet filtering, though the term is often associated with one particular vendor's product (Trend Micro). It's also increasingly common to find a third type of server somewhere near the DMZ (de-militarized zone) doing content filtering (for spam, pornographic material, and so on). Generally, an anti-virus product will be plugged in to such a product (MIMEsweeper, for example) rather than the firewall. Recently, we have been encountering the hideous term contentwall to describe such products. The complementary functionality of these three types of product enhances security, as long as the servers are sufficiently well specified and the network bandwidth is available.
In recent years, personal firewalls have become popular. These sometimes include some intrusion detection capabilities, as well as packet filtering and filtering by source port. This combination provides some potential defence against backdoor Trojans such as NetBus, Sub7, and similar programs. However, for (fairly) complete protection, most home users use such programs as complements to anti-virus programs, not as substitutes.
The latest hot topic in security is intrusion detection. As with any "next great thing", there are a few good (and some really bad) books on the subject, in this case many with pretty much the same title. Edward G. Amoroso's Intrusion Detection (Intrusion.Net Books, 1999) and Rebecca Gurley Bace's Intrusion Detection (Pearson Higher Education, 1999) are both excellent, while Intrusion Detection, by Terry Escamilla (John Wiley & Sons, 1998), is merely a promotional pamphlet for one commercial product. You might also be interested in some research by SRI International posted at http://www.sdl.sri.com/intrusion/index.html and the IDS FAQ at http://www.sans.org.
Intrusion detection is not firmly nailed down yet as a subject or specialty. However, it shares many of the functional characteristics of activity-monitoring software. It involves collection of data concerning activities, a comparison against known dangerous activities in the past, and some analysis of vulnerability. Still, activity monitors look at files on disk, whereas intrusion detection systems (IDS) are concerned with entire networked systems, so the analysis is considerably different. DDoS attacks and some types of worms/Trojans are often effectively detected in this manner. However, consumers and even IDS specialists are sometimes misled by the use of the term signature scanning in IDS and in virus detection into assuming that the technologies are more similar than is actually the case. While further convergence is likely, these are complementary technologies, not alternatives.
Some Internet service providers are now offering scanning services, (or buying them from third parties) such as MessageLabs. These services are essentially gateway, firewall, or content scanners that operate offsite. Note that everything that applies to the previous sections also applies to these scanners, but there is an extra consideration. You don't get to choose how serious the service providers are about your protection.
Outsourcing is less a matter of an alternative technology than of alternative implementation. However, such attempts to extend virus protection beyond the organizational perimeter, and graft such technologies onto the infrastructure of the Internet itself, are having a noticeable impact on the tracking and detection of viral threats, especially through email.
In addition to outsourcing email security, you can also outsource your complete security requirements. Some companies will do a security analysis for you, and then will undertake all the necessary management to take care of normal security activities.
On the one hand, outsourcing such security elements is a terrifying prospect. Your entire business is in the hands of strangers. They will control you completely. The most basic of management tasks will be completely controlled by an outside firm, and taking that control back, if you find you don't like how the firm manages these tasks, will be extremely difficult, and perhaps impossible.
On the other hand, most companies do not need serious security protection, as evidenced by the fact that most firms currently have almost no security. Hiring security can be very expensive, and it is difficult to judge the expertise of professionals. An outside firm probably has more experience in more areas than you can hope to hire. Nonetheless, we've talked to (and been patronized by) consulting firms whose staff would clearly be more at home with a six-gun and branding iron than a full suite of anti-virus software.
One thing to do before signing a contract with an outsourcing firm is to ensure that you have developed your own security policy. This serves two purposes. First, it ensures that you have decided what level and types of security you want. Second, it will greatly assist in ensuring that you get what you want from the contract you eventually sign, which should make reference to your policy.
Having a policy also helps you to evaluate security firms. If they try to take things out of your policy or sell you on additional points, go back and do the policy process over again, yourself. Under no circumstances should you let the firm that is bidding for the security contract also define the policy.
By now you should have a clear idea of the basic mechanisms of malicious software technology and of the technology available to counter them. However, knowing what a word processor does is not, in itself, sufficient qualification to write a best-selling novel. Anti-virus software is an essential tool, but doesn't comprise a security architecture.
Clearly, even if you intend to farm out your malware management function to a third party, you will need to understand what that function is before you can evaluate the fitness of that party to exercise it properly. By a remarkable coincidence, that is the subject of the next chapter.
IN THIS CHAPTER:
We'd like to think that our previous chapters have added substantially to the malware-related information available to the systems professional. However, that additional information, although needed by anti-virus professionals and more accurate and/or up-to-date than the information to be found in most books on the subject, is similar in kind to that offered in other works.
This chapter, however, deals with management of viruses and other malware as a formal function, within a formally defined organizational infrastructure, and that perspective is rather more novel. Some client organizations have long been aware of the need to define such a function, but have not necessarily done so successfully, for lack of reliable information.
Various writers have considered parts of that function in some detail - ready-made security policies often include an anti-virus policy, though nonspecialists in the field, even security practitioners in other fields, may mislead by giving advice based on misconceptions. In any case, it is the task of the individual or unit responsible for virus management to apply policies and strategies in a technically sound manner.
Virus management is often seen as (primarily) a desktop issue. Historically, this makes some sense. Most viruses target the desktop in some way, though this is less true in the age of the worm. Furthermore, desktop software was, for a long time, the primary focus of most anti-virus product ranges, and maintenance was often seen as a conceptually simple matter. A secretary's time would be allocated to checking incoming media and to distributing update diskettes to individuals, who would apply the updates themselves.
In fact, the virus/malware problem ranges across several areas: desktop management, LAN management, and Internet/intranet/extranet management, as well as less obvious areas such as human resources management. Thinking of anti-virus protection as a desktop issue because that's where the software is visible to everyday users is as inappropriate as treating UNIX support as a desktop issue because the desktop is where the telnet client is located. However, organizations that don't run to a full-time security team, let alone a dedicated virus management team, increasingly consider malware management a network/systems issue. This is a more practical approach in a modern environment, where most viruses and worms are email-borne rather than diskette-borne, and distribution of anti-virus updates over networks is taken for granted. Clearly, individuals cannot be relied upon to respond appropriately and in a timely fashion to threats spreading in minutes and hours rather than months. Furthermore, the convergence we have already noted between classic virus technology and other forms of malicious code traditionally addressed by security teams and network administrators argues for a corresponding functional consolidation.
However, grafting the anti-malware function onto the normal network and systems management functions (even when seriously focused on other aspects of security) is insufficient. Instead, by regarding and defining the malware problem globally, we can work towards holistic solutions that cross boundaries within the organization. This approach is much more reliable than concentrating on the piecemeal relief of individual symptoms. We can best achieve a global definition by considering the anti-virus management function independently of assumptions about who is responsible and where those responsible are situated in the infrastructure. Only then is it practical for the individual manager to consider how to apply that functionality within the security architecture of an individual organization.
Security literature has insufficiently analysed what constitutes a comprehensive malware-management function. General security books rarely consider it at all: they assume anti-virus management to be a matter of (somehow) distributing the software and running it (sometime) to check incoming media or to remove an infected file.
NOTE
Security books almost invariably assume tbat virus outbreaks are associated with parasitic file viruses, even though historically the most widespread viruses have tended to be boot-sector viruses, macro viruses, and worms, which are not necessarily parasitic.
Specialist anti-virus books (even the competent and fairly current ones) tend to focus on technology rather than strategy, and are often vendor-oriented. We would prefer you to think of malware management as a vendor-independent, enterprise-wide element of the organizational infrastructure. Anti-virus vendors usually fail to address certain significant aspects of malware management, while others require more than an out-of-the-box solution. An individual or team with appropriate expertise and experience must tailor any solution to the needs and attributes of the client organization, irrespective of whether the individual or team works for the client organization, an anti-virus vendor, or a third-party consultant.
Management of viruses and other malicious software can be divided into two main areas: proactive measures and reactive incident management.
Proactive management includes three main areas: strategy, systems and network administration, and development.
The strategic subfunction can be further subdivided into a number of areas:
Information Gathering and Risk Analysis The broad principles of the analysis-audit feedback cycle are well known and well documented in terms of general security, and we don't intend to consider them at length. The basic principle is to consider the current security status of the organization (security audit). This match ignites a fiery cascade of documentation: business impact analysis, security policy, security plan, disaster recovery plan, another security audit, and back round the loop (perhaps we should say Catherine Wheel).
Risk analysis in the malware management field tends, historically, to be threat-oriented. You compile a list of possible attacks, and then assess the system's degree of exposure and vulnerability to each. The main drawback to this approach in the virus context is that it's better at assessing vulnerability to known risks than to unknown risks. As we've seen with macro viruses, DDoS attacks, and email-borne worms, a hitherto unnoticed or insufficiently anticipated loophole may take months or even years to block completely.
Mission-oriented risk analysis is more generic: instead of compiling a list of specific attacks, the analyst examines systems for potential loopholes (security fault analysis'). Threat analysis examines the capability of a potential attacker to succeed with an attack. Risk reduction aims to ameliorate the exposure to weaknesses identified by the preceding analyses, while security evaluation provides a metric for testing the effectiveness of implemented measures.
Risk analysis in this context is concerned with assessing the likelihood of security breaches and their possible impact on the business if and when they do happen.
Information gathering is a more general, less formal term, and may include risk analysis. It includes such exercises as keeping up with trends in malware and anti-malware technology, strategic and tactical thinking, market trends, legal requirements and other external standards, and product certification status. Tracking such product data actually constitutes the preliminary stage of product evaluation. However, keeping up with anti-malware technology is by no means the same as keeping up with the market. Sometimes a vendor's marketing department makes claims that outstrip the capabilities of the product, or even its readiness for shipping. Information resources for tracking these data are considered in Chapter 8.
Most organizations keep particular watch on products for which they have a current licence. The scope and functionality of a given utility may (in fact certainly will) change, for reasons including the following:
However, reevaluating only when inertia is no longer enough entails trusting the good faith of the vendor and its competence in fields such as development and maintenance. Development competence is reflected by the vendor's proficiency at meeting new types of threats. Maintenance competence is reflected by such features as regular definitions updates that meet all current threats, and support of older configurations and platforms.
Vendors often emphasize their timely response to new viruses. Where once they offered quarterly or (at extra cost) monthly updates, they may now offer weekly, daily, or even hourly definitions updates, or simply provide updates as often as they are needed. Responding in a timely manner matters when a new virus or variant, especially a destructive one, suddenly becomes widespread through distribution via newsgroups and mailing lists, for instance. While someone has to be the first to be hit by a new "In The Wild" virus, a good and up-to-date anti-virus product, safe computing practices, and a closely monitored global early-warning system can combine to restrict the impact of incoming viruses. Indeed, many administrators are now becoming as reliant on generic blocking of suggestive filenames such as badfile.jpg.vbs or "badfile.txt .exe", and on formal or informal information exchange networks such as AVIEN (http://www.avien.org/), as they are on vendor information distribution and timely updates.
However, the appearance of a new type of threat can expose computer users to malicious code known to be already In the Wild while vendor labs put together safe and effective approaches to deal with the code. Informed system administrators were aware of the macro virus problem almost as soon as WM/Concept appeared. Some people inside and outside the security industry were aware of the potential for such an attack long before that first successful "data" virus. However, it took some time (and reverse engineering) before vendors were able to implement effective scanning of the complex and sparsely documented Microsoft Office file formats.
The appearance of seriously polymorphic viruses seems to have been a significant factor in the disappearance of some anti-virus products from the market, while the AutoStart worm had a similar effect on Macintosh packages. System administrators (or, in our terminology, malware managers) were for a while reliant upon home-brewed WordBasic and Visual Basic for Applications (VBA) solutions, such as disabling auto macros and filtering generically for the presence of all macros.
The problem is not only with the varying reaction times of vendors, though, but with the perceptions of consumers. The "Viruses & the Mac" FAQ in Appendix B was written to raise awareness of the cross-platform potential of the macro virus problem. It has been six years since the appearance of the first In the Wild Word macro virus and the warnings that such viruses operated across operating systems, yet we still find Mac users who don't realize that their chosen platform is not invulnerable. Now, however, they are also confused by the differences between Visual Basic scripts (to which they are not generally vulnerable) and VBA macros (to which they may be). Vendors must bear some responsibility for these phenomena: marketing departments are much better at talking about strengths than weaknesses, and products are inconsistent in the range of threats they detect (especially across platforms). However, customers are (despite the frequently voiced suspicion that anti-virus vendors write most viruses) often inclined to believe that the vendor knows best. Furthermore, there's often a wide divergence between the ethically and technically informed observations of anti-virus researchers and the pronouncements of the marketing department.
NOTE
Curiously, some computer users go to the opposite extreme, and trust the virus writer before the vendor. Some virus writers and distributors have noted this tendency with glee, pointing out that it is not they who benefit financially from their creations, but the vendors. This view seems to go hand in hand with the self-image of virus writers as performing a public service by educating their victims. But that's enough surrealism for one note.
Policies, Standards, and Guidelines There is considerable disagreement on how useful policy documents are, depending on the environment. Even when ignored by staff and management alike, these documents define and, in a sense, underpin the whole anti-malware strategy. How effectively and enthusiastically they are accepted and implemented determines how successful they are in practice. However, the formulation process, by defining the aims of the organization, is an important milestone on the road to implementing a security architecture.
Policies define what is to be protected (and why), and define the responsibilities of concerned parties. While the fine detail of malware-related policies is considered in Chapter 11, areas of concern might include the following:
Standards define platform-independent codes of practice and provide a means of measuring performance. They may evolve in response to the need for conformance with internal policies, external standards, and certification processes (ISO 9000 and ISO 7799, for instance). They also respond to the requirements of legislation, such as data protection legislation and laws relating to computer system and network abuse.
Guidelines define how standards are implemented in specific environments.
NOTE
Policies, standards, and guidelines (however their content is defined) should he sensibly integrated into a properly maintained document tree (a structured body of documents classified by function and appropriately cross-referenced - in some organizations the term document library ispreferred). At the same time, it has to he emphasized that documentation is a foundation, not a complete building.
Education, Training, and Information Provision Education generally takes two main directions:
Part of the malware management function is not only to keep abreast of malware and anti-malware technology (self-education), but also to arrange internal and external training and information flow. This function may include authoring and delivering in-house courses, arranging third-party training, outsourcing educational services, and so on. Particular targets may include IT support staff, Help Desk staff, dedicated response teams, and management (inside and outside the IT department).
NOTE
If you can get the message over to the Board of Directors, educating users is a cinch. In fact, you might want to consider exploiting your gifts in other fields, such as herding cats and nailing jelly to walls.
Other channels for disseminating information may include online services such as mailing lists and the intranet, hardcopy documentation, and in-house periodicals. An established and coherent document tree, available across the whole organization, is an instrument not only of disseminating information, but of enforcing policies such as:
Responsibility for virus management is often a subfunction of system security in general. This subfunction is inevitably part of a system manager's job description. There is no absolute boundary between systems administration and system security. Tying together desktop administration, network administration, and systems administration is correct in principle, but often breaks down in practice in the security area, especially in the rather specialized area of virus management.
A UNIX administrator, for instance, may and should be well acquainted with issues relating to maintaining system and file integrity on servers. However, working within a comparatively virus-free environment may blind an administrator to the perils of latent viruses. As we've already pointed out, a UNIX box used as an ftp or HTTP server may be a channel for secondary infection through files including code that can't execute at all under UNIX. NT administrators are also at risk of underestimating the direct and indirect vulnerabilities associated with their chosen platform.
Anti-virus/anti-malware tasks tend to be divorced from the mainstream of security, and the same terminology can be applied quite differently according to context. The worms detected by some PC or Mac desktop software are by no means the same threat as was posed by the Internet Worm. An enthusiastic advocate of intrusion detection and a virus management specialist may be talking about two very different phenomena when they talk about signatures. The term Trojan horse in the context of multi-user systems has largely been associated with password stealing. In the context of desktop machines, the emphasis has tended to be on programs that trash disks or file systems. This is not to deny that threats against both confidentiality and availability may be encountered in both contexts.
The administrator should be aware of a number of considerations relative to virus management:
These listed factors may point to a need to establish communication between disparate units. For instance, where virus management is seen as a desktop issue, the latent virus issue may be missed altogether, because no one has the authority, responsibility, or even the technical overview to come to the right conclusions and act accordingly.
Virus management comes within the domain of conventional systems administration (or overlaps with it) because of the need to address such issues as:
Clearly, the principle of least privilege applies, by which the administrator assigns the lowest possible level of privileged access to all account holders. By "the lowest possible level", we mean the lowest level compatible with the requirements of each user's job. For example, an account holder who needs to read shared data files may not need to be able to modify or delete those files, and will be given read-only permissions. In general, only systems administrators and operators need write access to shared applications, and even then, good practice is to use a privileged account only when specifically logging on to do systems work. This principle has a direct consequence in the anti-virus context: if an infected account holder doesn't have write access, neither does the virus. Thus, the administration of user and group policies and user authentication through passwords has a direct influence on the system's susceptibility to virus infection.
NOTE
Restriction of privilege can have an adverse impact on automation and transparency. For example, making objects in Microsoft Office read/execute only will increase the need for education on how to answer prompts that result, since MS Office modifies various program files that traditionally shouldn't require write permission. We should therefore stress the necessity to determine and review appropriate levels of access control - being aware that they may have residual effects in some applications.
The anti-virus administrator's sphere of responsibility within the organization extends far beyond the desktop and workgroup to the LAN file server, internal ftp server, intranet web server, and internal mail services. Looking beyond the perimeter, probably no anti-virus professional in the 21st century can afford to ignore Internet mail services, inbound or outbound. An outbound virus may harm the organization's reputation more than an inbound virus harms the organization's data. The problem is not only with outbound infected messages, but also outbound traffic resulting from the infection - such as LoveLetter's attempt to connect to an outside resource and send information to remote locations. While rebroadcasting a virus is not inherently embarrassing, it does expose and publicize the company's vulnerability to outsiders. It may also provide a method to come back into the enterprise network through a backdoor (as allegedly occurred with a recent server at Microsoft). Only administrators with absolute confidence in their desktop product and in the adherence of their customers to safe computing guidelines can afford not to protect the mail gateway.
Other Internet and extranet services also pose risks. Most organizations are both consumers and providers of SMTP (mail), ftp (file transfer), and HTTP (Web) services, and possibly others such as chat and NNTP (USENET), so malicious code can go out as readily as it can come in. The malware manager may not have control over content on web servers and the like, but needs to be in close contact with those who do. Even if the manager has no control, he or she may be able to force some comparisons between known correct web content versus the current state of web content, to detect unauthorized or inappropriate modifications.
Defence in depth entails the use of mix-and-match anti-malware measures, integration of different technologies such as intrusion detection, on-access and on-demand virus scanning, and content analysis, and use of similar software at different locations. It may also entail the use of more than one product line performing the same essential function. We address the issues of best practice and multilayered protection in Chapter 11.
Nor is this the only area in which malware management overlaps with other aspects of security. The association of virus infection with pirated software has been overstated, but exists nonetheless. Regulation through policy and by technical means of software auditing and metering lessens the associated risks.
Business continuity plans (BCPs) or disaster recovery plans (DRPs) may have to take into account the specialized risks associated with the action of malicious software. A BCP starts off from the list of possible scenarios brought to light by risk/business impact analysis, and allocates operational and administrative responsibility for dealing with those scenarios if they arise. Operational issues include, for instance, working through predefined protocols such as traversing a telephone tree, with each node being a person or unit with a need to know. Administration issues include such factors as relocation, insurance, replacement kits, and data restoration or re-creation. The latter may be of particular importance where malware has resulted in the loss (or, worse, gradual corruption) of data. Clearly, simple restoration from the most recent backup will not suffice if a slow-burning data diddler is known to have left its footprints.
NOTE
Data diddling is a term commonly applied to the unauthorized alteration of data. We regard this as heing of particular concern when the diddling consists of long-term, inconspicuous, and often random modifications, because of the difficulty of returning the data to a pre-diddled state.
Most viruses (but not all malware) target the desktop. Historically, the priority has been to protect the desktop, despite the difficulties of updating, distribution, and maintenance. Gateway protection has long been regarded as a highly effective supplementary defence for an organization that can afford the extra software and the performance overheads. (The better the network and hardware specifications, the less that cost and overhead are issues.) However, this supplementary defence can't be a complete substitute for desktop protection. After all, a high proportion of malware still gains access via removable media. Other danger areas include:
Server protection is an extension of desktop protection as well as a server-side issue. If installed and configured appropriately, it can offer early warning of desktop problems on specific systems, and a tool for distribution of updates (for example, through login scripts). You can still install, distribute, and update anti-virus and anti-malware software by performing one-to-one installations to individual desktops. However, most modern organizations can perform these tasks more efficiently by using the network as a channel for distribution from a central resource, using pull, push, or hybrid distribution models, such as the following: