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

Text File | 1991-05-28 | 10.6 KB | 195 lines

             *********************************************
             ***   Reports collected and collated by   ***
             ***            PC-Virus Index             ***
             ***      with full acknowledgements       ***
             ***            to the authors             ***
             *********************************************


  Report from Jim Bates - The Virus Information Service - 8th May 1991

  === GP1 Novell Specific Virus (Jerusalem derivative) ===

  Although this virus is based on the Jerusalem series, the specimen
  examined is unusual in several respects.  Firstly, this is the first
  time I have had an original virus generating program to examine,
  meaning that the sample was NOT an infected file but the original
  code by which a virus could be introduced into a system.  Secondly,
  this is the first virus I have seen which contains code specifically
  designed to confirm the existence of NOVELL Network code before
  becoming infective, and finally - accompanying the sample was an
  uncommented assembler listing which shows definite signs of being a
  dissembly of a Jerusalem virus with NOVELL specific and other code
  added to it.

  The actual virus code is unremarkable - infection takes place only
  during LOAD and EXECUTE function calls (4B00h) to DOS INT 21h.  Both
  COM and EXE files are infected but COMMAND.COM is specifically
  excluded.  The "standard" Jerusalem infection pattern is apparent
  whereby COM files have the virus code prefixed to the host file,
  while EXE files have it suffixed (with the attendant changes to the
  file HEADER).  The infective length varies (because of various
  paragraph alignment calculations) between 1563 and 1580 bytes and
  setting the HIDDEN attribute on files is no defence.  The virus
  marks infected files with a "signature" of "MsDOS" as the last five
  bytes of the file, and after infection, the original Date and Time
  settings of the file are restored.  The code contains no stealth
  routines and is not encrypted so detection is a fairly simple matter
  (a recognition signature was published in last month's VB).  The
  code remains resident in memory and monitors only INT 21h although a
  temporary dummy Critical Error handler (INT 24h) is installed during
  infection.   This virus is of the resident type which uses an "Are
  you there?" call, in this case placing a value of 0F7H into the AH
  register and issuing an INT 12h instruction will return a value of
  0300h in AX if the virus is resident.  There is no trigger routine
  although the interference with NOVELL specific operations may cause
  unpredictable effects.

  The sample analysed displays all the appearance of an experimental
  program, and this is one of the aspects which provokes most
  interest.  The actual structure of the program (a genuine EXE file)
  can be divided into several distinct sections - there is the
  resident section of code, consisting of COM file entry routine, EXE
  file entry routine and the usual INT 21h handler (which contains the
  infection routines).  Then there is a section (towards the end of
  the code) which is outside the resident area and this contains the
  program's direct entry point.  Within this non-resident area, the
  code has two distinct purposes depending upon whether the virus code
  is resident and if a parameter has been added to the command line
  used to invoke the program in the first place.  If the virus is NOT
  resident, this initialisation code simply installs it in memory and
  exits through a normal TSR (Terminate and Stay Resident) function
  call.  If the virus IS resident but no parameter was given, the code
  simply exits without doing anything.  However, if the virus is
  resident AND a parameter of 'i' is given when the program loads, the
  virus is removed from memory and a message is displayed which says :
  "GP1 Removed from memory.".  In my experience of disassembling virus
  code, it is unique to come across a program which functions in this
  way and this, in conjunction with one or two other observations
  leads me to conclude that this is the original "virus generating"
  code.

  It should also be noted that this original sample appears to be
  uninfective under any circumstances because the collection of the
  normal NOVELL network handler address is accessed via a FAR JMP
  instruction rather than a FAR CALL (thus giving an incorrect return
  address on the stack to the handler).  Having said that, the
  uncommented assembler file has a conditional structure within it
  which includes this FAR JMP instruction, thus making it possible to
  change the whole complexion of the program code from a relatively
  harmless exercise into a highly infective virus by simply changing
  one instruction.  For the purposes of further analysis therefore, I
  assumed this instruction to have been changed accordingly.

  The NOVELL specific aspects of the program quite naturally formed
  the focus of most attention during disassembly, but for the first
  time during analysis I was unable to verify my analysis by direct
  observation of the virus under actual live conditions.  It is
  understandably difficult to persuade anyone with a Novell Network to
  allow virus code loose on their system, especially when its
  operation is still fairly speculative.  However, most of the code is
  quite obvious in its operation if the low level operation of Novell
  Netware is understood and in only one area was I unable to verify
  the exact operation of the code.


  Operation

  As mentioned above, this virus is NOT infective unless Novell
  networking software is present on the system.  The virus issues a
  special function call to verify the existence of the network
  software and if this fails, processing aborts back to the host
  program.  Once the presence of network software has been verified,
  the entry point of the network IPX service routine is collected and
  stored within the virus code for future use.  The virus INT 21h
  handler monitors all DOS function requests but only intercepts three
  of them.  Two of these will service the virus' own "Are you there?"
  call and the peculiar way in which the Jerusalem virus handles the
  preliminary execution of infected COM files.  The third function
  intercepted is the 0E3h request for service to Novell Netware.  When
  such a request is received, it is checked to see if the subfunction
  is requesting a user logon procedure.  Anything other than this is
  allowed to pass directly on to the normal DOS/Netwar INT 21h handler
  but the logon request is executed under control of the virus so that
  the return code can be examined.  If the return code indicates that
  the logon was unsuccessful then processing is allowed to continue
  unmolested.  Otherwise a series of highly specific network calls are
  issued in a sequence which culminate in the sending of a 'packet' (a
  network message) onto the network which has the effect of allowing
  the virus to gain privileged access to network drives.  The actual
  mechanisms by which this is achieved displays an intimate knowledge
  of the way that the network operates - however, it is neither
  necessary nor prudent to describe these mechanisms in detail within
  this analysis.  Suffice it to say that the effect is to allow the
  virus to spread across the network.  The extent of this spreading is
  the one area that I was unable to verify without access to a
  suitable networked system.


  Conclusions

  The arrival of a PC virus containing network specific code is an
  event which has been predicted for some time by genuine researchers.
  The prudent maxim adopted by most of us is "if it can be done - it
  will be done.".  A recent incident in the U.S.  where an individual
  suggested that a copy of Jerusalem had propagated across a network
  was unsubstantiated.  It appeared that the network may not have been
  securely configured and the virus in question was never produced for
  accurate disassembly.  In this case however, there is no doubt about
  the nature of the code and it is obviously designed to sidestep
  normal network security arrangements. The only minor surprise is
  that it has taken so long to arrive.

  There are many recorded instances of viruses propagating across
  various types of PC networks, but this is invariably when the
  configuration of network security has been lax or non-existent.
  Such propagation occurs purely because the network software is
  designed to be as transparent as possible, even at DOS level.
  However, the security considerations are generally very efficient at
  preventing unauthorised access to areas specified during
  configuration and to date I knew of no virus which could avoid the
  protection measures built into NOVELL Netware.  It now appears that
  the warning that NO protection system can be 100% effective against
  virus code without introducing fundamental changes in machine
  functionality, has been proven once again.

  Examination of the original assembler routine seems to indicate that
  extensive testing was conducted with the idea of violating network
  security in a number of different ways.  This virus was only one
  result of such tests, intelligent guesswork indicates some other
  possibilities which might have equally serious repercussions.  When
  I see a new computer virus - the thought that someone somewhere,
  with enough intelligence to write a computer program, is so warped
  as to want to do this, makes me extremely sad and extremely angry.
  A full report, together with the sample, the assembler and my own
  disassembly and analysis have been passed both to NOVELL in the U.S.
  and the Computer Crime Unit in the U.K.  It is to be hoped that the
  perpetrators (in this case so close) might be apprehended and
  brought to book for indulging in such imbecility.

  VIS Classification - CEARN1563A


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