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 ==
======================================================================