From: Chris McDonald (8/21/93) To: virreviews:;@WSMR-SIMTEL20.ARMY, Mail*Link¨ SMTP Revision to Product Test PT Please add the enclosed addendum to PT-61. The addendum is an advance copy of an article to be published in "CHIPS" distributed by the Naval Computer & Telecommunications Command. Thanks, Chris ********** "VDS PRO: When Viral Scanning Is Not Enough" Computer viruses are a legitimate concern for every computer user. The most popular anti-virus tool employs some type of signature scanning and and algorithmic detection. Scanners are essentially static analysis detection tools which perform detection operations based upon known virus signatures. Recently the question has arisen as to whether scanners may at some point be incapable of intelligently performing their anti-virus function. The sheer number of viruses, particularly those in the MS-DOS environment, has placed a severe strain on those who produce and support scanning programs. For example, at the 2nd International Computer Virus Prevention Conference & Exhibition held in San Francisco this February, several viral researchers commented on the fact that they receive from 10-30 new viruses per week. The task of analyzing these submissions, of identifying a reliable search string or virus signature, of testing to ensure that the signature chosen does not result in a false alarm, of adding the search string to the scanner program, and of finally distributing the update to registered users is an extremely complex process. In many cases researchers are simply not analyzing all submissions on the historical evidence that with few exceptions a new virus has very little chance of spreading. In other words anti-viral program authors will ignore a new virus on the presumption that it will only survive in the hands of the viral author and in the researcher's collection. Even if scanners are presently effective tools, there are other options to complement detection programs. One of the most interesting is integrity checking. Integrity checkers operate on the basic principle that all viruses cause modification to a system and/or to executables during the infection and the replication process. If one then searchs for unexpected modifications, one has the potential to identify viruses which are unknown to detection or scanning programs. There is also the potential that integrity checking will identify other types of malicious programs, such as trojan horses, which a scanner may not identify. Virus Detection System (VDS) Professional (PRO) is a commercial integrity checker which creates a "fingerprint" of all system areas and executable files. From April through July of this year I have tested version 1.0 with program updates through July 30, 1993. Tests have occurred on platforms with MS-DOS 3.10 through 5.0 installed. Documentation identifies these minimum system requirements: MS/PC-DOS 3.0 or higher, a hard disk (not compressed or encrypted), 384Kb available memory, 500Kb free space on the hard disk, less than 1500 executable files per partition, and no file larger than 2Mb. VDS PRO has a very specific installation procedure. One must first coldboot the target system with the VDS distribution disk, remove the VDS disk, and then warmboot from a "genuine" DOS disk. The documentation stresses that the DOS disk must be "clean" or uninfected. If the boot is successful, one then must run CHKDSK on every drive where you will install VDS to make sure the files are not corrupted. If any fle is corrupted, one must correct the discrepancies by running CHKDSK with the /F option. If there have been no problems to this point, one then types INSTALL to initiate a series of final procedures in which the user has the ability to customize VDS protection. It is during these later steps that VDS scans for known virus signatures before creating a baseline profile of system areas and executables. The scanning program (VDSFSCAN.EXE) also functions as an independent detection program. I found that the installation routine performed as documented. It did take some time for the program to complete an initial "fingerprint". The default is for VDS to generate a baseline for all executable files as well as system areas such as the master boot record (MBR), partition table and the boot record (BR). File name, size, date, time and signature combine to form a database scheme, to include a fingerprint of the VDS program itself. On one test system I intentionally corrupted a file prior to initial installation to see what would happen if I failed to run CHKDSK. The result was that VDS aborted its installation before it could complete a total profile of the system. When it did abort, I was approximately 5 minutes into the installation and was forced to start from the beginning. Those users who normally avoid documentation or who like to take shortcuts will discover that VDS will simply refuse to install if one does not follow instructions. The installation program generates a customized device driver for each system. This driver is unique and cannot be transferred to another system. During installation one has the option to automatically modify the AUTOEXEC. BAT and CONFIG.SYS files to add the necessary lines to load the VDSDEV.DDR and then run VDS.EXE every time one reboots the system. I experienced no difficulties in choosing the automatic modification on several systems with different configurations. However, if one anticipates that there may be a conflict, one has the alternative to manually modify the respective files. When VDS.EXE runs from the AUTOEXEC.BAT file, it verifies the integrity of its own code and then launches "decoys" (i.e., small executable programs created at run-time) into the system to see if an active virus will "take the bait". VDS next verifies the system areas and all executable code. all executable code. During dozens of operations the sequence described above functioned as documented. I intentionally altered "fingerprints" through several disk editors, infected files with known viral samples, deleted files with fingerprints, and added files without creating a fingerprint. In every case VDS provided an alert message and generated a record in its vds-stat.log file. Upon an alert the program offers a user many options. One may, for example, overwrite a file whose fingerprint has changed; one may choose to update the fingerprint when it is apparent that the change is non-malicious; one may choose to establish a fingerprint for a non-malicious file which may have been recently loaded to the system; one may capture a "suspicious" sample for technical analysis. These are only examples and do not represent a complete listing of options. Since it is important that one determine a system is "clean" before generating a profile, the effectiveness of VDSFSCAN.EXE becomes a critical component in the initial installation. Although I do not have code for all 2 the malicious programs which VDSFSCAN claims to detect, I did test the program against a suite of 721 known malicious programs. The test suite contained approximately 80% to 85% of the "common" or "in the wild" viruses as identified in surveys by "Virus Bulletin" and by the National Computer Security Association. The test suite included MtE, TPE and VCL creations. MtE is the mutating engine object module written by Dark Avenger; TPE is the TridenT Polymorphic Engine; and VCL is the Virus Creation Laboratory written by NoWhere Man. The program identified 100% of the "common" viruses in the test suite. VDSFSCAN identified all MtE, TPE and VCL samples. "Virus News International" evaluated the performance of CatchMtE, which is the freeware version of the module incorporated within VDS PRO. Vesselin Bontchev, Virus Test Center of VTC-Hamburg, documented that the module had a 100% detection rate against 15,994 samples of eight MtE virus samples. Testing suggested that VDS PRO performed efficiently. While the installation procedure is demanding, the logic of its approach conveys the impression of conscious design choices on the part of the program author. VDS provides a user with the capability to automate recovery in the event of a MBR/BR infection through the creation of an emergency diskette during the last stages of the installation process. Limited testing confirmed the functionality of this emergency diskette procedure. VDS also generates an audit record of its operations to assist in the analysis and investigation of changes to the profile or fingerprint. Finally, VDS stores all the fingerprint information in a single file which is an efficient feature and which allows a user to store the information off-line for added security. As with all integrity checkers VDS PRO does present some potential disadvantages. For example, while VDS PRO should be devoid of false negatives for the identification of a change to a file, change in itself does not always imply that a viral infection has occurred. A change in a profile or fingerprint may only reflect non-malicious self-modification, recompilation, or intentional user update to an executable. So one has to be careful in responding to an alarm message. The integrity checker may be extremely easy to use, but the results may be difficult to interpret. My impression of the documentation was that it might easily overwhelm a novice user. On the other hand, those who consider themselves to be expert users, might demand more information on the procedures and algorithm utilized to generate the VDS device driver and the baseline fingerprint. The debate over the strength of integrity checker algorithms and fingerprint generation is admittedly esoteric for most users. Though the potential exists for a viral author to specifically target an integrity checker's profile generation mechanism, there have been few documented attacks. So for most of us, even if we had the additional information and could understand it, it may not be that critical in a real world situation. If one understands that VDS PRO and other integrity checkers detect a virus after infection, then one would be well advised to utilize VDS PRO in conjunction with other anti-viral tools. The combination of a virus 3 scanner and an integrity checker, for example, provides additional functionality. I have always recommended the use of two different scanning programs to increase detection probabilities of "known" viruses as well as to provide for protection in the event a vendor decides to withdraw from the marketplace. The recommendation has nothing to do with the relative merits of VDSFSCAN.EXE. It rather has to do with the fact that different scanners will employ different search strings or virus signatures, and will be updated at different frequencies. The selection of an integrity checker is a more difficult procedure than selection of a scanner. For this reason readers should obtain a copy of the National Institute of Standards And Technology's Special Publication 800-5, "A Guide to the Selection of Anti-Virus Tools and Techniques", December 2, 1992. The publication is available for anonymous ftp from the NIST host 129.5.54.11 in the path /pu/nistpubs. [Author: Chris Mc Donald is a computer systems analyst at White Sands Missile Range, NM. He is a Certified Information Systems Security Professional (CISSP) and a member of ACM, CSI, IEEE, ISSA and NCSA. His reviews on security software for MS-DOS and Macintosh systems can be found on the Virus-L forum and on the NIST Security Bulletin Board.] 4 ------- ------------------ RFC822 Header Follows ------------------ Received: by internetqm.llnl.gov with SMTP;21 Aug 1993 22:05:20 -0800 Return-path: CMCDONALD@WSMR-SIMTEL20.ARMY.MIL Received: from icdc.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H20TUXK2TCAW42QH@icdc.llnl.gov>; Sat, 21 Aug 1993 22:04:02 PDT Received: from pierce.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H20TUF70LCAW42MU@icdc.llnl.gov>; Sat, 21 Aug 1993 22:03:39 PDT Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA21633; Sat, 21 Aug 93 22:04:35 PDT Received: from WSMR-SIMTEL20.ARMY.MIL by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA21624; Sat, 21 Aug 93 22:04:28 PDT Date: 21 Aug 1993 22:56:39 -0700 (MDT) From: Chris McDonald Subject: Revision to Product Test PT-61, VDS-PRO, Addendum Resent-to: BILL_ORVIS@QUICKMAIL.llnl.GOV To: virreviews:;@WSMR-SIMTEL20.ARMY.MIL Resent-message-id: <01H20TUXNK76AW42QH@icdc.llnl.gov> Message-id: <12903043828.14.CMCDONALD@WSMR-SIMTEL20.ARMY.MIL> X-Envelope-to: BILL_ORVIS@QUICKMAIL.llnl.gov X-VMS-To: IN%"virreviews:;@WSMR-SIMTEL20.ARMY.MIL" Content-transfer-encoding: 7BIT ======================================================================