The Number of the Beast Virus

 

             *********************************************

             ***   Reports collected and collated by   ***

             ***            PC-Virus Index             ***

             ***      with full acknowledgements       ***

             ***            to the authors             ***

             *********************************************

  Vesselin Bontchev reported in May 1990

  The Number of the Beast.

  ========================

  - Three new versions of this virus have appeared. None of them

  contains the "666" string any more. I have difficulties to tell the

  exact order in which these versions were created.  In all of them

  the virus writer has tried to stick more code - but the place is

  *really* too small. In one of them he abandoned the DOS version

  check; in another there is no error checking.  I call these versions

  V512-B, V512-C and V512-D respectively.  The bad news is that John

  McAfee's program SCAN in no longer able to find them.  I do not

  think that this effect is achieved intentionally, maybe John just

  picked a bad search string.

  - In these mutations some of the earlier design bugs in the virus

  were improved. For instance, all of them are able to extract

  correctly the name of the command interpreter on boot time - even if

  it is not in the root directory. Also, the infected program don't

  always exit at DOS prompt when run on a clear system.  The virus

  saves the first one (or two, this depends of the concrete mutation)

  byte of the original file in its own body.  Then, when the infected

  file is executed, the virus reads the first byte after the end of

  file and compares it with the saved one.  If these bytes match, the

  virus tries read the original 512 bytes and to execute the file.  If

  they don't, the file is considered as damaged and the virus

  terminates the program (and exits at DOS prompt).

  - This virus contains a bug I didn't mentioned in my description.

  This is a design bug, not a programmer's one.  The problem is that

  the virus is not always able to check successfully if it is already

  present in memory. It compares the program, which has intercepted

  the INT 21h vector with its own body.  However it does not try to be

  the first program on this vector - like the Dark Avenger virus does.

  Now suppose that your COMMAND.COM is infected and that you have a

  lot of TSR programs in your AUTOEXEC.BAT file, all of which

  intercept INT 21h.  Of course, each of them will become infected.

  However each of them will cause a new copy of the virus to be loaded

  also - since the first program has intercepted INT 21h and the virus

  in the next program will not be able to find that it is already

  present in memory.  Since every copy of the virus will occupy a DOS

  I/O buffer, the operating system will run out of buffers soon.  This

  will lead to bad performance and system crashes.

======= Computer Virus Catalog 1.2: "512" Virus (5-June-1990) ========

Entry...............: "512" Virus

Alias(es)...........: ---

Virus Strain........: ---

Virus detected when.: January 1990

              where.: Bulgaria

Classification......: COM overwriting/extending/resident.

Length of Virus.....: 512 bytes

-------------------- Preconditions -----------------------------------

Operating System(s).: PC/MS-DOS

Version/Release.....:

Computer model(s)...: IBM PC/XT/AT/PS and compatibles

-------------------- Attributes --------------------------------------

Easy Identification.: "666" at offset 509.

Type of infection...: Executable file infection:

                      Overwriting/extending; resident; first 512 bytes

                      placed at free space on last cluster of file,

                      and replaced with the virus code.

                      System infection: RAM-Resident, uses disk buffer

                      space for code in order not to take-up memory.

Infection Trigger...: Any close file (INT 21, Service 3e) or Execute

                      (INT 21, Service 4b) on a .COM file.

Storage media affected: Any Drive

Interrupts hooked...: Int 21 DOS-services

                      Int 13 and Int 24 while infecting.

Damage..............: ---

Damage Trigger......: ---

Particularities.....: If virus is in memory, files are read as unin-

                      fected. Directory never shows size increase,

                      even if the virus is not in memory.  Under DOS

                      3.3, software write protections are bypassed.

Similarities........: ---

-------------------- Agents ------------------------------------------

Countermeasures.....: Monitoring the INT 21 vector.

Countermeasures successful: ---

Standard means......: A Do-it-yourself way: Infect system by running

                      an infected file, ARC/ZIP/LHARC/ZOO all infected

                      COM and EXE files, boot from uninfected floppy,

                      and UNARC/UNZIP/LHARC E etc.  all files.  Pay

                      special attention to disinfection of

                      COMMAND.COM.

-------------------- Acknowledgement ---------------------------------

Location............: Weizmann Institute Of Science, Rehovot, Israel

Classification by...: Ori Berger

Documentation by....: Yuval Tal (NYYUVAL@WEIZMANN.BITNET), Ori Berger

Date................: 6-March-1990

Information Source..: ---

          +++++++ more ++++++

  Report from Jim Bates - The Virus Information Service - April 1990

  === The 666 Virus (aka Number of the Beast) ===

  The '666' virus (also known as 'V512' & 'Number of the Beast') is

  one of the so-called 'Bulgarian 50' group of viruses and although it

  has no trigger routine there are several interesting features which

  make the code worthy of study and analysis.  A trigger routine would

  be somewhat complicated to add to the code because of the size

  limitations and this leads me to suspect that this virus is an

  attempt to prove how clever the programmer is rather than a serious

  attempt at malignant code.  The virus is a parasitic type which

  becomes resident in the system when the code is executed. It infects

  only files which have the letters 'CO' as the first two letters of

  the file extension.  This is obviously targeting .COM files but it

  may also include COBOL source files which conventionally have an

  extension of .COB as well as other files with names matching this

  specification.  The other criteria for infection are that the file

  must have a length between 512 bytes and 65,023 bytes (inclusive)

  and, most important of all, the file length must be such that there

  is at least one free sector of space between the end of the file and

  the end of the last allocated cluster.

  This last requirement highlights one of the weak areas in the MS-DOS

  file storage system which virus researchers have long been aware of.

  The disk space allocation system within MS-DOS works by allocating

  space in predetermined chunks called 'clusters'.  The size of a

  cluster is set when the drive is first formatted and on most systems

  with more than around 10Mbytes of overall disk space the cluster

  size is set to 4 sectors (or 2048 bytes). Since file sizes are

  rarely an exact multiple of clusters in length, there will usually

  be a certain amount of unused space beyond the end of the file but

  still allocated to it.  For example: the COMMAND.COM file on my DOS

  3.30 system is 25,307 bytes long.  This represents slightly over 12

  clusters of disk space so DOS will have allocated 13 clusters.

  Therefore, the allocated space equals 26,624 bytes (13 x 2048) while

  the space actually used by the file is 25,307 bytes.  The difference

  in this case is 1,314 bytes which represents something over 2

  sectors and therefore this particular COMMAND.COM could be infected

  by the 666 virus.   There are some problems associated with using

  this space which I'll come to later but the big advantages are that

  : a) DOS will not overwrite it and :  b) it is considered 'lost' to

  all DOS operations unless special provision is made to access it.

  It is thus an ideal place to 'hide' virus code so that scanning

  programs cannot find it.  Of course, some method must still be used

  to ensure that such code is loaded and presented to the processor

  for execution.  Although there are several ways of doing this, the

  V512 virus uses one of the more interesting ones which also attempts

  to fool both resident and scanning software into 'thinking' that

  nothing is amiss with the host file.  It should go without saying

  that there will be some files which do not have sufficient unused

  space within the final cluster.  However, this virus does check for

  that eventuality and will not attempt to infect such files.

  The virus is 509 bytes long and appears to have been padded with a

  three byte 'signature' consisting of the characters '666' (giving

  rise to its alternative names) to bring the size up to 512 bytes

  (exactly one sector).  It is positioned on the disk to overwrite the

  first sector of the host file.  The original contents of that first

  sector are written beyond the end of the file in the free space just

  discussed.  So, taking events in their proper sequence, I will start

  by describing the actual installation of the virus code when it is

  first executed.

  INSTALLATION

  The code starts by determining the DOS version of the current

  operating system and then collects the INT13H vector from page zero

  of memory.  The DOS version is then checked and if the minor part

  (after the decimal point) of the version number is .30 then a little

  known (and undocumented) DOS function is called which swaps out the

  original (ie: pre-system load) INT13H entry point (this usually

  points to the ROM INT13H routine).  The swapped out address is

  pushed onto the stack and the function is called again to swap the

  vectors back again.  This restores normal system operation at that

  point but leaves the required address on the stack.  This address is

  popped from the stack to take the place of the INT13H vector

  collected from page zero.  If the minor DOS version is NOT .30 then

  the swapping function is not used and processing continues with the

  page zero DOS INT13H vector.  The importance of the swapping process

  can be appreciated since it recovers an entry point into the disk

  I/O services which is not usually monitored by anti-virus software.

  It should be noted however, that it IS possible to hook monitoring

  software into this function and it is also possible to monitor the

  swap function itself and thus intercept this particular virus

  installation routine.  Installation then continues by storing the

  relevant INT13H vector within the virus' code segment and then

  collecting the INT21H vector - again by direct access to page zero

  of RAM.  The offset portion of the INT21H vector is checked for a

  value of 121H and if this is found, the indicated segment is checked

  for the presence of the virus.  Obviously if the virus is already

  resident, processing branches to the portion of the code which is

  processed AFTER the virus has been made resident.  If the virus code

  is NOT resident, the code locates the address of the first Disk I/O

  buffer which DOS uses.  These buffers are exactly 512 bytes long and

  usually have around 16 bytes as a header so there is more than

  enough space for this virus code to be installed in one.  Once the

  whole virus has been moved into the buffer, its address is removed

  from the Disk I/O chain and the INT21H vector is modified to point

  to the interception routine within the newly re-located virus code.

  The code then overwrites a small section of the transient portion of

  the command interpreter.  This is to ensure that when the program

  terminates, COMMAND.COM will be reloaded and, as will be seen,

  infected.  In this way, this virus actually attempts to infect

  COMMAND.COM the very first time it is executed.  The code then goes

  on to check whether the current program is a command process (ie:

  COMMAND.COM itself) or is running as a child of DOS.  If it IS a

  command process, then processing terminates back to DOS and since

  the virus code is now resident, the reloading of COMMAND.COM will

  ensure that it is infected as we shall see later.  An interesting

  point here is that when an infected program is run for the first

  time on a clean system (ie:  COMMAND.COM is NOT infected), the host

  program itself will NOT be executed - but run it a second time, and

  it will be!  The second and subsequent times that the program is

  executed, after the 'parent/child' check, the data that was in the

  original first sector is loaded into the appropriate area

  (overwriting the recently loaded copy of the virus) and execution

  then continues with the original program quite normally.  The method

  of accessing beyond the end of the file is another one of the

  interesting parts of this virus since it is achieved by direct

  manipulation of the DOS System File Table (SFT).  This technique is

  used in several places throughout the code and it allows the virus

  to open a file for READ access (thus NOT alarming any resident

  anti-virus monitoring software) and then to change the SFT to allow

  WRITE access. At the same time, the file length and date/time fields

  can also be modified as required.  However, during the execution

  phase of an infected program, only the file length field is

  adjusted; by adding 512 so that the original data can be read from

  the disk.

  INTERRUPT INTERCEPTION

  As mentioned, only the INT21H vector is hooked during installation

  and the virus code which intercepts this call allows all function

  requests through except for 3FH (READ), 3EH (CLOSE) and 4B00H (LOAD

  & EXECUTE).

  READ FUNCTION

  The READ intercept provides yet another interesting aspect of the

  code in that it attempts to 'hide' the presence of the virus code in

  a way that is reminiscent of the technique used in the BRAIN virus.

  When a READ request is received, the current position of the file

  access pointer is first noted and then the READ is performed

  correctly.  Next the file access pointer is checked to see if the

  read request was for a portion of the file within the first sector.

  If it wasn't, processing is returned to the caller, but if it was,

  the file time stamp field is checked for the existence of 1FH (31

  decimal) in the seconds bits.  This is equivalent to a setting of 62

  seconds and is one of the markers used by the virus to indicate an

  infected file (the other being the presence of the virus code

  itself).  If the file is marked as infected in this way, then the

  SFT is accessed again to modify the file size field and the original

  first sector is read from the last cluster. Then the file size field

  is restored to its former value before processing returns to the

  caller.  Thus the virus has effectively covered its existence by

  supplying the caller with the correct data rather than the virus

  code. This means that simple scanning programs will NOT detect the

  virus code ON AN INFECTED SYSTEM!  This is further evidence of the

  absolute necessity of ensuring that the system is 'clean' before

  starting any tests for the presence of virus code on the disk.

  LOAD & EXECUTE and CLOSE FUNCTIONS

  The intercept routine for these two functions is substantially the

  same except that when closing a file, the file handle is first

  duplicated and subsequent operations are carried out on the

  duplicate handle.  Loading a file for execution results in the file

  being opened (in READ mode) for virus operations.  In both cases the

  file handle being used is closed before the original request is

  allowed to continue normally (using the original file handle).  The

  purpose of the interception is to check the file for existing

  infection and if it is not infected, to check its suitability for

  infection by determining how much unused file space there is in the

  final cluster.

  INFECTION

  After the routine opens (or duplicates) a file handle for the

  target, the file position pointer is set to zero (Beginning of File)

  and the SFT access privilege field is changed to allow WRITE access.

  Then the vector for INT13H is changed to that collected during the

  Installation phase.  Remember that the virus code will usually have

  collected this vector during the initialisation of the system (ie:

  via an infected COMMAND.COM) or from the undocumented vector swap

  interrupt.  Thus it is unlikely that this vector will be monitored

  by anti-virus software.  The virus does not use INT13H directly but

  INT21H functions associated with file I/O use it and could thereby

  alarm monitoring software.  The infection check routine also

  revectors INT24H (Fatal Error Handler) to point to an IRET

  instruction within the code.  This effectively disables error

  reporting for the duration of this section of the code.  Once these

  two interrupt vectors have been modified, the code continues by

  checking the time stamp field for the 62 second marker.  If this

  marker is not found the file extension is tested to see if it begins

  with 'CO', otherwise the extension check is by-passed.  There seems

  no valid reason for this alternative checking, maybe the programmer

  had other options in mind and simply forgot this sloppy piece of

  coding as the virus developed.  Whatever the reason, the assumption

  is that a file with the 62 second marker set will be a .CO?  file.

  From this point on, if a check fails, the handle is closed and

  processing is return to continue the original INT21H function call.

  The next check ensures that the target file is between 512 and

  65,023 bytes long.  A further test looks at the SYSTEM attribute

  setting of the target file and rejects it if it is set.  The final

  check before examining the file for existing infection involves

  testing the file length against the number of sectors per cluster

  and using this to calculate how much unused space is available in

  the final cluster.  Once the target file has passed all these

  checks, the first 512 bytes of the file are read into a buffer.  The

  virus uses the high part of the Interrupt Vector Table as a buffer,

  thus overwriting all Interrupt vectors above 7FH.  This is the most

  serious mistake within the virus since an increasing number of

  machines, most network software and several high-level languages use

  these interrupts for various purposes and the destruction of the

  vectors will cause system failure and give immediate alarm signals

  that something is amiss.

  Once the start of the file has been read, it is checked against the

  existing virus code to see if it is already infected.  If infection

  IS discovered, the time stamp field is set with the 62 second marker

  and the file is closed.  If the file is NOT infected, the contents

  of the buffer are appended to the end of the file and a copy of the

  virus is written to the first sector.  The file size field is

  actually modified during this process but restored afterwards to

  leave the appended code outside the size setting.  The date/time

  field remains substantially unaltered (except for the 62 seconds) as

  a result of direct access to the flags field of the SFT.  These

  actions ensure that the visible directory entry for the file remains

  the same as it was before infection.  Within the infection routine

  there are two calls to Function 40H of Interrupt 21H.  These are

  immediately obvious to monitoring software and can therefore provide

  a useful detection point.

  The use of the LOAD & EXECUTE function as a vehicle for file

  infection has become fairly standard amongst virus authors but the

  use of the CLOSE function is of much more concern.  The Dark Avenger

  virus also subverts this function and causes similar concern.  The

  problem centres around the more simple scanning programs because in

  order to examine a file they must open it using the DOS file I/O

  functions.  Once scanning has been completed the file is closed and

  - if a virus of this type is present - becomes infected.  Thus the

  scanning program becomes the agent for infecting every suitable file

  on the disk at one go!  The answer is to restrict the use of

  scanners to a known clean system, ie:  keep the scanning program on

  a write protected system floppy disk and ONLY use it from there.

  The only scanners which should be used on an automatic basis

  (invoked by AUTOEXEC.BAT) are those which collect file information

  on an absolute sector basis and thereby do not use the DOS file I/O

  facilities.  If the method used by the scanner is not known, assume

  that it DOES use DOS file I/O and take appropriate precautions.

  Virus programmers are, almost by definition, immature and inadequate

  individuals indulging in the electronic equivalent of graffiti and

  it can be interesting to speculate on the personalities who waste

  their time in such childish activities.  My impressions on

  disassembling this virus are of someone who considers himself a cut

  above other virus writers.  The code makes use of some undocumented

  and obscure features of DOS in a way which almost shouts "See how

  clever I am" and yet ignores such obvious giveaways as the

  overwriting of the Interrupt Vector Table and the plain use of the

  WRITE function 40H of Interrupt 21H.  Other problem areas include

  the method of checking for the virus existence in memory.  This will

  cause multiple installation of the virus code if any subsequent

  program re-vectors INT21H.  There are also difficulties if an

  infected program is copied on an uninfected system.  In this case,

  since most COPY routines work on a byte by byte basis (and not

  cluster by cluster) the infected file will lose the contents of the

  unused space at the end of the file and while the copied file will

  still contain the virus, it will no longer perform its original

  function.  Assuming that a virus should NOT announce its presence by

  destroying its host, this is another serious weakness in the code.

  The final flaw in this type of virus, and the one of most interest

  to technicians wishing to protect their systems, is that the spread

  of infection can be stopped quite simply by ensuring that all files

  occupy an exact number of clusters.  Thus no free space is left and

  the virus will be unable to replicate.

  There is a suggestion that this code was developed as a 'LAB' virus,

  intended to test and assist in the development of more effective

  anti-virus software.  This may well be the case but the fact remains

  that it is easily disassembled and contains dangerous techniques

  which could be modified by malicious people to further exacerbate

  the virus threat.  There are enough genuine viruses around without

  irresponsible people developing and distributing new ones.

  VIS Classification - CcARSd512A

  The information contained in this report is the direct result of

  disassembling and analysing a specimen of the virus code.  I take

  great pains to ensure the accuracy of these analyses but I cannot

  accept responsibility for any loss or damage suffered as a result of

  any errors or omissions.  If any errors of fact are noted, please

  let me know at :-

                    The Virus Information Service,

                    Treble Clef House,

                    64, Welford Road,

                    WIGSTON MAGNA,

                    Leicester LE8 1SL

  or call +44 (0)533 883490

  Jim Bates

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  ++++++++++++++++++++++++++ end of reports ++++++++++++++++++++++++

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++