ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/UTILITY/VIRUS/PCV4RPT.ZIP/NUMBER.RPT

Text File | 1991-05-28 | 23.7 KB | 415 lines

             *********************************************
             ***   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 ([e-mail]), 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 [phone]

  Jim Bates


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