Polymorphic viruses escape detection but get our attention Last week, we faced the implications of the next-generation ultrastealth viruses that are now reproducing themselves among us. Because a few of these viruses have already been found to be employing this new scanner-beating self-modifying technology and because their is nothing particularly difficult about writing such a polymorphic virus, I feel there is more good than harm in a public discussion of this nasty new breed. (I know that many readers are wondering what happened to my promised solution to the spread of these viruses; it will come next week after I illustrate the danger of these new germs.) viruses can be detested by recognizing either their dynamic actions or their static presence. Dynamic-action recognition provides the potential benefit of stopping unknown viruses. Nevertheless, today's smarter viruses can circumvent such interception easily. If the virus wishes to have a higher level of software access to the system, several techniques are known for getting underneath DOS and BIOS interception, so resident blockers are all but useless. Static-presence recognition scans the entire system for the "fingerprints" of known viruses. Today's deliberately elusive polymorphic viruses can evade this detection entirely. The simple idea behind the polymorphic virus is that the bulk of the virus can be scrambled by a random number. Every IBM-compatible PC has a counter/timer chip that can be used as the source for a completely nondeterministic 16-bit random number. When the virus clones itself into a new environment, it can use the instantaneous value of the counter/timer as a scrambling starting point. By algorithmically altering every byte of itself based upon this initial number, the newly propagated virus will be immune to fingerprint detection. There's one flaw in this approach: The small kernel of code used to unscramble the body of the virus must be left in an unscrambled state so the computer can execute it and unscramble the balance of the virus. This means the unscrambling portion could still be fingerprinted and identified. This problem could be easily solved: By deliberately interlacing irrelevant "do nothing" instructions among those that perform the unscrambling work, every stored instance of the unscrambling kernel could be completely different from all the others. As the virus copies itself to a new destination, it randomly draws from a repertory of superfluous instructions, peppering them liberally throughout the new copy of itself. As you can see, these techniques can be teamed up with activity interception avoidance to create a new breed of viruses that would be virtually impossible to detect. It is quite annoying that we must expend our resources in the prevention of this software terrorism. But there may be some value in experiencing this terrorism now. Most viruses have been the work of amateurs and are far from devastating. Being told on Friday the 13th that your computer is "stoned" is annoying as hell, and having to type "Happy Birthday to Joshi" early in January makes you wonder who's in charge. But it sure beats being informed that your company's customer list and the archived source code for your next unreleased product have just been transmitted by modem to your competition. When your network's database and modem servers receive remote procedure calls (RPCs) from remote workstations, are you sure they should answer that call? We need to begin tightening up our systems and taking security very seriously. Personal computing is not just a diversion from the tedium of sharpening pencils; it is a serious endeavor that is extremely prone to organized and deliberate attack. If a bored, pimply faced highschool kid is capable of penetrating your corporation's security with his annoying but benign virus, you had better hope he never wants to hurt you. Steve Gibson is the developer and publisher of SpinRite and president of Gibson Research Corp., based in Irvine California. From April 20,1992 issue of InfoWorld\ At last, how to protect yourself from polymorphic viruses My past two columns concerning the threat presented by polymorphic viruses triggered an informative conversation with the industry's chief virus researcher, John McAfee. During that conversation I learned that things are even worse than I'd supposed. It turns out that the " Dark Avenger" bulletin board system, which disseminates virus code, has recently published the complete source code for the Dark Avenger Mutation engine. The mutation engine is nothing less than a first-class code kernel that can be tacked on to any existing or future virus to turn it into a nearly impossible to detect self-encrypting polymorphic virus. My examination of a sample virus encrypted by the Mutation Engine provided by McAfee revealed alarming capabilities. Not only do Dark Avenger Mutation Engine viruses employ all of the capabilities I outlined in last week's theoretical polymorphic virus column, but they also use a sophisticated reversible encryption algorithm generator. The Mutation Engine uses a metalanguage-driven algorithm generator that allows it to create an infinite variety of completely original encryption algorithms. The resulting unique algorithms are then salted with superflous instructions, resulting in decryption algorithms varying from 5 to 200 bytes long. Because McAfee has already received many otherwise known viruses that are now encapsulated with the Mutation Engine's polymorphic encryption, it's clear that viruses of this new breed are now traveling among us. It is clear that the game is forever changed; the sophistication of the Mutating Engine is amazing and staggering. Simple pattern- matching virus scanners will still reliably detect the several thousand well-known viruses; however these scanners are completely incapable of detecting any of the growing number of viruses now being cloaked by the Dark Avenger Mutation Engine. So what can we ultimately do to twart current and future software viruses? After brainstorming through the problem with some of our industry's brightest developers and systems architects, I've reached several conclusions: First, scanning for known viruses within executable program code is fundamentally a dead end. It's the only solution we have for the moment, but the detectors can only find the viruses they are aware of, and new developments such as the Mutation Engine render even these measures obsolete. Second, detecting the reproductive proclivities of viruses on the prowl is prone to frequent false alarms and ultimately complete avoidance. With time the viruses will simply circumvent the detectors, at which time the detectors will only misfire for self- modifying benign programs. Third, the Achilles' heel of our current DOS-based PC is its entirely unprotected nature. As long as executable programs( such as benign and helpful system utilities) are able to freely and directly access and alter the operating system and its file system, our machines will be vulnerable to deliberate viral attack. So here's my recommendation. Only a next-generation protected mode operating system can enforce the levels of security required to provide complete viral immunity. By marking files and code overlays as "read and execute only" and by prohibiting the sorts of direct file system tampering performed by our current crop of system utilities, such operating systems will be able to provide their client programs with complete viral immunity. The final Achilles' heel of a protected-mode operating system is the system boot process, before and during which it is still potentially vulnerable. By changing the system ROM-BIOS' boot priorty to favor hard disc booting over floppy, thios last viral path can be closed and blocked as well. note; Steve Gibson is the developer and publisher of SpinRite and president of Gibson Research Corp., based in Irvine, Calif. Send comments to InfoWorld via MCImail (259-2147) or fax them to (415) 358-1269 Subject: Polymorphic Virus Here is a new entry from the Computer Virus Catalog, produced and distributed by the Computer Anti-Virus Researcher's Organization (CARO), at the University of Hamburg. Note the description of the Polymorphic Method, below, and that this virus can presently be detected in a file only by the file change it produces. ==== Computer Virus Catalog 1.2: Dedicated Virus (31-January 1992) === Entry...............: Dedicated Virus Alias(es)...........: --- Virus Strain........: --- Polymorphism engine.: Mutating Engine (ME) 0.9 Virus detected when.: UK where.: January 1992 Classification......: Polymorphic encrypted program (COM) infector, non-resident Length of Virus.....: 3,5 kByte (including Mutating Engine) --------------------- Preconditions ---------------------------------- Operating System(s).: MS-DOS Version/Release.....: 2.xx upward Computer model(s)...: IBM - PCs, XT, AT, upward and compatibles --------------------- Attributes ------------------------------------- Easy Identification.: COM file growth (no other direct detection means are known as virus encrypts itself, and due to the installed mutation engine, all occu- rences of this virus differ widely) Type of infection...: COM file infector: all COM files in current directory on current drive (disk,diskette) are infected upon executing an infected file. Infection Trigger...: Execution of an infected COM file. Media affected......: Hard disk, any floppy disk Interrupts hooked...: --- Crypto method.....: The virus encrypts itself upon infecting a COM file using its own encryption routine; upon execution, the virus decrypts itself using its own small algorithm. Polymorphic method..: After decryption, the virus' envelope consisting of Mutating Engine 0.9 will widely vary the virus' coding before newly infecting another COM file. Due to this method, common pieces of code of more than three bytes (=signatures) of any two instances of this virus are highly improbable. Remark: Mutating Engine 0.9 very probably was developed by the Bulgarian virus writer "Dark Avenger"; such a program was announced early 1991 as permutating more than 4 billion times, and it appeared in October 1991 or before. The class of permutating viruses is named "polymorphic" to indicate the changing structure which may not be identified with contemporary means. To indicate the relation to such common engine, the term "Polymorhic engine (method)" has been introduced. ME 0.9 was distributed via several Virus Exchange Bulletin Boards, so it is possible that other ME 0.9 related viruses appear. According to (non-validated) information, an- other ME 0.9 based virus (Pogue?) has been detected in North America: COM file infector, memory resident, length about 3,7 kBytes. Damage..............: Virus overwrites at random times random sectors (one at a time) with garbage (INT 26 used). Damage Trigger......: Random time Similarities........: --- Particularities.....: The virus contains a text greeting a US based female hacker; this text is visible after decryption. --------------------- Agents ----------------------------------------- Countermeasures.....: Contemporarily, no automatic method for reliable identification of polymorphic viruses known. - ditto - successful: --- Standard means......: --- --------------------- Acknowledgement -------------------------------- Location............: Virus Test Center, University Hamburg, Germany Classification by...: Vesselin Bontchev, Klaus Brunnstein Documentation by....: Dr. Alan Solomon Date................: 31-January-1992 ===================== End of Dedicated Virus ========================= ====================================================================== == Critical and constructive comments as well as additions are == == appreciated. Descriptions of new viruses are appreaciated. == ====================================================================== == The Computer Virus Catalog may be copied free of charges provided = == that the source is properly mentioned at any time and location == == of reference. == ====================================================================== == Editor: Virus Test Center, Faculty for Informatics == == University of Hamburg == == Vogt-Koelln-Str.30, D2000 Hamburg 54, FR Germany == == Prof. Dr. Klaus Brunnstein, Vesselin Bontchev, == == Simone Fischer-Huebner, Wolf-Dieter Jahn == == Tel: (+40) 54715-406 (KB), -225 (Bo/Ja), -405(Secr.) == == Fax: (+40) 54 715 - 226 == == Email (EAN/BITNET): brunnstein@rz.informatik.uni-hamburg.dbp.de == == bontchev@rz.informatik.uni-hamburg.de> == == FTP site: ftp.informatik.uni-hamburg.de == == Adress: 134.100.4.42 == == login anonymous; password: your-email-adress; == == directory: pub/virus/texts/catalog == ======================================================================  .