`
`JSSN 0956-9979
`
`THE AUTHORITATIVE INTERNATIONAL PUBLICATION
`ON COMPUTER VIRUS PREVENTION,
`RECOGNITION AND REMOVAL
`
`Editor: Edward Wilding
`
`Technical Editor: Fridrik Skulason
`
`Editorial Advisors: Jim Bates, Bates Associates, UK, Phil Crewe, Fingerprint, UK, David Ferbrache, Defence Research Agency, UK, Ray Glath, RG Software
`Inc., USA, Hans Gliss, Datenschutz Bcrater, West Gennany, Ross M. Greenberg, Software Concepts Design, USA, Dr. Harold Joseph Highland, Compulit
`Microcomputer Security Evaluation Laboratory, USA, Dr. Jan Hruska, Sophos, UK, Dr. Keith Jackson, Walsham Contracts, UK, Owen Keane, Barrister,
`UK, John Laws, Defence Research Agency, UK, David T. Lindsay, Digital Equipment Corporation, UK, Yisrael Radai, Hebrew University of Jerusalem,
`Israel, Martin Samociuk, Network Security Management, UK, John Sherwood, Sherwood Associates, UK, Prof. Eugene Spafford, Purdue University, USA,
`Dr. Peter Tippett, Certus International Corporation, USA, Dr. Ken Wong, PA Consulting Group, UK, Ken van Wyk, CERT, USA.
`
`CONTENTS
`
`EDITORIAL
`
`TECHNICAL NOTES
`
`KNOWN IBM PC VIRUSES
`(UPDATE)
`
`2
`
`3
`
`5
`
`TOOLS & TECHNIQUES
`
`Virus Verification and Removal
`
`7
`
`VIRUS ANALYSES
`
`I . DIR II - The Much Hyped
`
`'Linking' Virus
`
`2. Music Bug
`
`3. Form
`
`1 1
`
`15
`
`16
`
`FIAT LUX
`
`A Pervading Myth: The 'CMOS
`Virus'
`
`ON COMPUSERVE
`
`Troublesome Concubines in the
`Anti-Virus Harem
`
`SCANNER TACTICS
`
`Living Together- Without
`False Alarms!
`
`PRODUCT REVIEW
`
`Virus Buster
`
`END-NOTES & NEWS
`
`17
`
`18
`
`19
`
`20
`
`24
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Science Park, Oxon, OXI4 3YS, England. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is available only to qualitled subscribers. No part of this publication may be reproduced, stored in a retrieval system, or transm itted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 1
`
`
`
`Page 2
`
`VIRUS BULLETIN
`
`November 1991
`
`EDITORIAL
`
`A Little Knowledge is a Dangerous Thing
`
`' Give a child a hammer and all of a sudden things around him
`will start looking like nails.' (Anon.)
`
`No MIS or DP manager in his right mind would hand out The
`Norton Utilities to all PC users regardless of their need or
`ability to use such powerful and potentially destructive
`software. The misuse of Norton (or PC Tools or any other
`powerful disk editor) could cause untold damage if its
`distribution were not limited to technically competent staff.
`
`Neither would it be wise to instruct general users as to the
`existence or nature of certain of the more dangerous DOS
`commands - most PC users in business run a limited set of
`applications (text editors, spreadsheets, databases and DTP
`being prevalent) and can remain happily oblivious to such
`two-edged swords as FORMAT and FDISK. Even the humble
`delete command dons a perplexing mantle when combined
`with those cheeky wildcard characters'*.*'! Obviously, all of
`the DOS commands are thoroughly outlined in the user
`manual - be it from Microsoft or IBM or Digital Research. It
`is fortuitous in this instance, therefore, that people rarely, if
`ever, refer to manuals while using software- this is one of the
`major reasons why software developers employ 'walk-thru'
`menus. The information and resources to cause untold
`accidental damage are readily available within DOS itself but
`are not clearly signposted as such.
`
`The point here is that handing out powerful security and audit
`tools to the masses, and providing superficial education about
`the operating system to people who don't need that informa(cid:173)
`tion, is a recipe for disaster. Instructions to use security tools
`and techniques should be on a 'need to know' basis -PC
`Support should know the exact locations of all such software
`and its distribution should be extremely limited.
`
`In the case of anti-virus software, many packages aim to
`provide comprehensive virus detection and removal facilities.
`'Toolkit' utilities of this sort provide programs to replace boot
`sectors, edit specific areas of disk and even write protect
`drives. Is it wise to place such power in the hands ofusers?
`Even a simple scanner becomes a complex beast when you
`examine the number of menu driven or command line options
`that many developers have provided. Can PC Support be sure
`that users will comply with their ex-cathedra statement to
`boot from a write-protected system floppy disk? Do users
`know what such a disk is, or why they should use it, or how to
`prepare it? Do they even know the difference between drive
`A: and drive C:?
`
`It is sometimes difficult for technicians to appreciate the
`relative ignorance of non-technicians - many developers of
`security software still believe that mass populations can be
`
`trained to use their products correctly and effectively. More
`seasoned and forward-thinking observers knew a long time
`ago that this belief was nothing more than a pipe dream.
`Given that it takes a massive and concerted effort to educate
`users in the most basic aspects of corporate security, training
`a mass community in the use of relatively complex software
`security packages is a wholly untenable objective.
`
`Security managers in many organisations rightly conclude that
`they are simply not prepared to trust end-users with any
`degree of technical responsibility when it comes to combating
`computer viruses. As a result, the tools and techniques for this
`job are restricted to those capable of using them. This is an
`elitist rather than populist approach - considering the wealth
`of accumulated ignorance in any society it is entirely under(cid:173)
`standable and well conceived. This is not to belittle education;
`if a problem can be explained in simple, straightforward and
`readily understood terms then that is all to the good. However,
`there is an enormous divide between understanding the basic
`tenets of a problem and proficiency in dealing with it!
`
`The strategy which is most effective and which has been
`widely adopted combines three elements: central reporting;
`specialist response teams (variously known as PC SWAT or
`CERT, or simply PC Support) and risk analysis. Central
`reporting effectively channels all enquiries and problems to
`the SWAT team - qualified technicians who have studied the
`virus problem and who are supplied with the requisite
`information and tools to deal with any outbreak both swiftly
`and correctly. Risk analysis is the process of identifYing the
`' mission critical' machines within the organisation. These are
`the machines from which any loss of availability or integrity
`would have a serious impact on the overall performance of the
`organisation. A risk analysis of any organisation usually
`shows that 'mission critical' PCs comprise a relatively small
`percentage of overall IT resources. It is vital, however, that
`these PCs are adequately protected and this may necessitate
`the purchase of suitable defensive software.
`
`One questionable strategy is that of equipping every single PC
`with defensive software. This may be necessary in high
`security environments but imposes burdens in terms of
`financial outlay, support costs and inconvenience. Memory(cid:173)
`resident software may well cause memory clashes (with
`Windows 3.0 or SHARE.COM for example), false alarms and
`is critically dependent on user-compliance. Checksumming
`software needs careful implementation and management -
`particularly in an a shifting software environment. Memory(cid:173)
`resident software is prone to subversion by stealth viruses as
`is checksumming software if it is run in an infected DOS
`environment. Monitors and checksummers can be adminis(cid:173)
`tered - but not on 5,000 PCs in 60 or 70 locations!
`
`Ultimately, put the diagnostic tools in capable hands and
`purchase defensive software on the basis of considered risk
`analysis. Finally, make friends with Symantec and the
`Federation Against Software Theft ... locate all unauthorised
`copies of The Norton Utilities and delete them!
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Science Park, Oxon, OX14 3YS, England. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is avai lable only to qualified subscribers. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 2
`
`
`
`November 1991
`
`VIRUS BULLETIN
`
`Page 3
`
`TECHNICAL NOTES
`
`Norton and The Cascade Message
`
`In recent months VB and various anti-virus software manufac(cid:173)
`turers have received a number of calls concerning reports of
`'Cascade' by the System Information (SI) program supplied
`with Norton Utilities version 5.0. These spurious reports have
`nothing to do with the Cascade virus and do not imply
`infection by any virus.
`
`The confusing message is displayed by SI in its list of
`hardware interrupts, as a description of IRQ2 and refers to the
`internal hardware of the PC.
`
`PC-ATs contain two 8259A hardware interrupt controller
`chips, each of which support eight system interrupts. The 8086
`family of microprocessors has a single line to communicate
`with the interrupt controllers, so IRQ2 on the first interrupt
`controller accepts interrupt requests from the second control(cid:173)
`ler. Thus the two controller chips are connected in a cascading
`manner- hence the 'Cascade' message.
`
`The actual Cascade virus has been the cause of various
`misinterpretations; the virus is also known as 1701 which also
`happens to be a standard disk read error message! Perhaps
`Hailstorm, Fall, Autumn Leaves or one of the many other
`aliases for this virus should be adopted and standardised.
`
`FDISK/MBR
`
`Kevin Powis of Visionsofl has brought a little known and very
`useful feature of FDISK supplied with MS-DOS 5 to our
`attention. This feature will effectively remove many current
`viruses which infect the Master Boot Sector (Track 0, Head 0,
`Sector I).
`
`If a PC running MS-DOS 5 is infected by such a virus, the
`user can boot from a clean write-protected system diskette
`upon which is stored a copy of FDISK.
`
`The FDISK program should then be run from the diskette
`drive. By typing FDISK /MBR at the A: prompt, clean Master
`Boot Sector code is written to the first physical sector on the
`hard disk. Moreover, when this FDISK option is invoked, all
`initialisation data in the 64 byte Partition Table stored in
`physical sector I is left completely intact.
`
`Note: this option shou ld only be used if the Partition Table
`in the first physical sector on the hard disk is present and
`correct after the Master Boot Sector has become infected.
`This may not necessarily be the case with future computer
`viruses. [Such viruses may already exist. Tech Ed.]
`
`Fortunately, most viruses which currently infect the Master
`Boot Sector do not tamper with the Partition Table.
`
`This feature, combined with the ability of SYS to remove DOS
`Boot Sector viruses (those which infect the boot sector of the
`active DOS partition), provides users of MS-DOS 5.00 with
`simple standard tools to remove most boot sector viruses
`without having to resort to formatting. This FDISK option is
`only available under MS-DOS version 5 - it does not apply to
`versions prior to 5.
`
`It is still recommended that all PC users store clean write(cid:173)
`protected backups of the boot sectors of their fixed disks
`on diskette.
`
`Non-Compliance
`
`Many resident scanners, monitors and standalone checksum(cid:173)
`ming programs provide the option for PC administrators to
`customise the screen message which appears when these
`programs detect virus activity. System administrators can thus
`instruct the user to contact the relevant PC Support desk and
`provide other information consistent with company policy.
`
`Unfortunately, a user of unauthorised or stolen software, upon
`seeing a virus alert reported on his screen may decide not to
`report the incident to PC Support, particularly so if company
`policy entails severe disciplinary action for illicit software
`use. Subsequently such a user may attempt to disinfect his
`machine which may result in compounded damage.
`
`The problem of the non-compliant user is an extremely
`difficult one to solve. At the recent Sysguard 91 conference in
`London, Noel Bonczoscek of the Computer Crimes Unit
`suggested that developers of memory-resident software might
`consider incorporating a completely customised alert banner
`into their monitors - upon detecting a virus the on-screen alert
`could thus be configured in such a way as not to arouse the
`suspicions of the ' untrusted user' .
`
`This is an interesting suggestion which merits consideration.
`
`Using Virus Guard (from Dr. Solomon's Anti- Virus Toolkit)
`as a representative example, this resident monitor, upon
`detecting a virus, currently flashes a message to screen which
`states prominently:
`
`Virus Alarm
`
`Dr. Solomon's Anti-Virus Toolkit has Intercepted a
`virus:
`
`Close everything down normally, then consult Toolkit
`manual for remedy
`
`However, Bonczoscek said that PC administrators might
`prefer to configure a more subtle display along the lines of
`' Internal Error: Do Not Proceed, Contact PC Support/ Tel
`Extension 203 '.
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Science Park, Oxon, OXI4 3YS, England. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is available only to qualified subscribers. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 3
`
`
`
`Page4
`
`VIRUS BULLETIN
`
`November 1991
`
`This banner would have no reference to a suspected virus
`attack or the anti-virus software that had detected such activity
`but would be sufficient to ensure that the more naive user
`contacted the appropriate support staff.
`
`This is only one suggested (and, to our knowledge, untested)
`proposal to encourage user-compliance. The potential pitfalls
`of such a tactic are readily apparent - not least the fact that a
`genuine operating system error would not direct the user to an
`' in house' telephone extension! Any user recognising this fact
`might well be capable of dealing with a virus attack in the first
`place!
`
`However, Bonczoszek's underlying point is that computer
`administrators should never assume that users will automati(cid:173)
`cally comply with company policy and report virus outbreaks
`or other incidents. (To quote Thomas Harris: 'Never assume
`anything -you'll make an ASS out of U and ME'). Compli(cid:173)
`ance auditing is one of the most complex tasks in computer
`security - making sure that people understand the rules and
`that they are following them is a formidable task and technical
`solutions do not lend themselves easily to it.
`
`Little wonder that the wisest and most experienced computer
`security managers don't allow users anywhere near detection
`and diagnostic software - they know that either it will not be
`used, or that it will be used incorrectly (often with dire
`results), or that alerts and warnings will simply be ignored!
`
`Rage Change
`
`An amended scan string to detect the Rage virus (VB, October
`1991, p. 2 1) has been supplied by Andrew Busey of Microcom
`Software Division Inc. The scan string contains no addresses
`and should be used in preference to either of the previously
`published patterns.
`
`Rage B9FD 01SA 2451 SACS D2C4 59SS 24FE C046
`
`Nobbled Nibble
`
`A one-nibble error in the search pattern published for the
`Liberty virus in last month's VB effectively invalidated the
`string. An amended and corrected pattern. appears below.
`
`Liberty
`
`B931 2S33 D2CD 1306 BB5C 0653 CB2E
`S03E BC06 OA74 4633 COSE
`
`Anti-virus software developers shou ld take note that the
`original pattern for this virus (last published in July 1991)
`should be maintained as essential scan data. This pattern was
`extracted from an earlier version of the virus which is not
`consistently detected by the pattern above. The pattern is
`repeated here:
`
`Liberty
`
`0174 031F 595B 5053 5152 1E06 1EOE
`1FES
`
`VIRUS BULLETIN
`EDUCATION, TRAINING
`AND
`AWARENESS PRESENTATIONS
`
`Education, training and awareness are essential as
`part of an integrated campaign to minimise the
`threat of computer viruses and Trojan horses
`
`Virus Bulletin has prepared a presentation de(cid:173)
`signed to inform users and/or line management
`about this threat and the measures necessary to
`minimise it. The standard presentation consists of
`a ninety minute lecture supported by 35mm
`slides, followed by a question and answer ses(cid:173)
`sion.
`
`Throughout the presentation, technical jargon is
`kept to a minimum and key concepts are ex(cid:173)
`plained in accurate but easily understood lan(cid:173)
`guage. However, a familiarity with basic MS(cid:173)
`DOS functions is assumed. The presentation can
`be tailored to comply with individual company
`requirements and ranges from a basic introduc(cid:173)
`tion to the subject (suitable for relatively inexpe(cid:173)
`rienced users) to a more detailed examination of
`technical developments and available counter(cid:173)
`measures (suitable for MIS departments).
`
`The aim of the basic course is to increase user
`awareness about computer viruses and other
`malicious software without inducing counterpro(cid:173)
`ductive 'paranoia'. The threat is explained in
`comprehensible terms and straightforward,
`proven and easily-implemented countermeasures
`are demonstrated. An advanced course, aimed at
`line management and DP staff, outlines various
`procedural and software approaches to virus
`prevention, detection and recovery.
`
`The presentations, are offered fi·ee of charge
`except for reimbursement of travel and any
`accommodation expenses incurred. Information
`is available fi·om the editor, Virus Bulletin, UK.
`Tel 0235 555139.
`
`VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Science Park, Oxon, OX14 3YS, Engla nd. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is ava ilable only to quali fied subscribers. No part of this publication may be reproduced. stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 4
`
`
`
`November 1991
`
`VIRUS BULLETIN
`
`Page 5
`
`KNOWN IBM PC VIRUSES (UPDATE)
`
`Updates and amendments to the Virus Bulletin Table of Known IBM PC Viruses as of 20th October 1991. Hexadecimal patterns may
`be used to detect the presence of the virus with a disk utility program, or preferably a dedicated virus scanner.
`
`Type Codes
`
`C = COM files
`E= EXE files
`M = Infects Master Boot Sector (Track 0, Head 0, Sector I)
`R = Memory-resident after infection
`P = Companion virus
`
`D = Infects DOS Boot Sector (logical sector 0 on disk)
`N = Not memory-resident atler infection
`L =Link virus
`
`864- CN: This virus adds 864 bytes in front of the files it infects. Awaiting analysis.
`864
`B04D B449 B742 473A 2575 153A 7D01 7510 3A45 0275 OBC6 4502
`1876 - CER: This 1876-byte virus is probably of Polish origin. Awaiting analysis.
`1876
`BECO 33FF 33CO B9FF 7FFC F2AE 26F6 05FF 75F8 83C7 038B D72E
`Best W ishes-970 - CER: This virus is detected by the search pattern for the Attention virus, but not by the pattern for the Best
`Wishes-1024 virus. This variant is not able to infect .EXE files properly.
`
`Black Wizard- EN: A variant of the 'Old Yankee' virus and detected by the pattern for that virus. This variant is 205 1 bytes long and
`plays a different tune than the original virus, but is otherwise similar.
`
`Bulgarian 123 - CN: A simple 123-byte virus from Bulgaria, which does nothing but replicate. It may infect the same file repeatedly.
`Bulgarian 123
`B103 8D54 F4B4 40CD 21B4 3ECD 21B4 4FCD 2173 AFBB 0001 FFE3
`Copmpl - CER. This is a 1111 (COM) or 1114 (EXE) byte Polish variant of the Akuku virus. The name is derived from the following
`text, which can be found inside the virus 'Sorry, I'm copmpletly dead' (sic). The only effect of the virus is to play a tune.
`Copmpl
`80E6 OF8A D680 FAOO 7407 SOFA OB76 06B2 02B4 OECD 218C C88E
`Copyright- CN: A 1193-byte virus from East Europe, which contains a fake Award BIOS copyright message. Awaiting analysis.
`Copyright
`AB4A 75F2 E2EA 33CO CD16 B800 06B7 0733 C9B6 18B2 4FCD 10E9
`DIR-II- LCER: A 1024-byte 'link' virus from Bulgaria. 'Infects' all COM and EXE files in each directory on a single pass. If the
`virus is resident, 'infected' COM and EXE files can be disinfected by renaming their extensions. (VB, Nov 1991).
`DIR II
`BCOO 06FF 06EB 0431 C98E D9C5 06C1 0005 2100 1E50 B430 E824
`DM-400- CR: This 400-byte virus does not seem to do anything but replicate.lt contains the text '(C) I990 DM'.
`DM-400
`80FC 4B74 3380 FC56 7419 FE04 80FC 3D74 12FE 0480 FC3E 751C
`Europe '92- CR: This 421-byte virus activates if the year is set to 1992, when it displays the message: 'Europe/92 4EVER!'
`Europe '92
`B450 CD21 8CD8 488E D8C6 0600 005A 891E 0100 8916 0300 53B8
`Fake-Vir X - CN: A 233-byte virus from Finland which activates on any Friday the 13th, when it displays the message ' Vir X 3/90' .
`Fake-VirX
`408B D5B9 0600 CD21 8801 575A 59CD 21B4 3ECD 21B8 0001 FFEO
`Gergana- CN: Four variants of the Gergana virus, which are longer than the original with improved error handling.
`Gergana-2 22
`8F80 FFB9 3000 F3A4 E9C6 FD5E 8 1C6 0001 8FOO 01B9 DEOO F3A4
`Gergana-300
`BFBO FFB9 3000 F3A4 E985 FD5E 81C6 0001 BFOO 0189 2C01 F3A4
`Gergana-450
`8F80 FF89 3000 F3A4 E97E FD5E 81C6 0001 BFOO 01B9 C201 F3A4
`Gergana-512
`8AOO FA84 3FCD 21C3 8900 0284 40CD 21C3 8801 572E BBOE 5001
`Gosia - CR: A 466-byte virus from Poland. It contains the text 'I ' Gosia' . '
`is the ASCII character (03))
`Gosia
`0275 10AC 268A 2547 3AC4 7405 80CC 203A C4E2 EE9F 03F9 8B1D
`Gotcha - CER: Two related viruses from East Europe, 879 and 881 bytes long. They contain the text string: 'GOTCHA!' .
`Gotcha
`9C3D DADA 7428 BOFC 3D74 OA3D 006C 7405 BOFC 4875 1306 1E50
`Hero-394- ER: Related to the 506-byte Hero virus. but does not damage the files it infects. Awaiting analysis.
`Hero -394
`898A 0133 C08F 0002 0305 83C7 02E2 F929 069C 0388 0042 33C9
`Hu ngarian-482 - CR: This 482-byte virus from Hungary activates on November 7th. If an infected program is run on that date it will
`display the string 'Format ... ' and proceed to format the hard disk.
`Hungarian-482
`5603 F7AC OACO 740A DOES 840E B30 7 CD10 E8F1 8901 008A 8000
`
`VIRU S BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadra nt, Abingdon Science Park, Oxon, OXI4 3YS, England. Te l (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is available only to qualified subscribers. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 5
`
`
`
`Page 6
`
`VIRUS BULLETIN
`
`November 1991
`
`Iron Maiden- CN: A 636-byte vims, which contains the text ' IRON MAIDEN' near the end. It has not been fully analysed, but
`contains destmctive code (INT 26H calls). The original sample of this virus was also infected with the Polish W 13-A virus.
`Iron Maiden
`2425 C021 SFOE 1F88 8557 02A3 0001 BAAS 5902 8826 0201 841A
`Leningrad - CN: Two viruses, 600 and 543 bytes long, first reported in Leningrad (now St. Petersburg), and probably written by the
`same author. The 600 byte variant has not been analysed, but the other variant will activate on any Friday the 13th, and display the
`message 'That could be a crash, crash, crash!'. These vimses were described last month as Sov I and Sov2.
`
`Murphy-Brothers - CER: A 2045-byte Murphy variant. Contains the text: 'Brothers in arms'. Detected by the HIV pattern.
`
`Omega - CN: A 440-byte virus from Finland. It overwrites the beginning of the first two hard disks, trashing the Partition Table.
`Omega
`805C AA89 7E2E 83EC 1589 1500 88FC 88F5 A4E2 FOES 1000 8915
`Path - CN: A 547-byte virus from East Europe, which searches the path for files to infect.
`Path
`890D 0057 8A07 8805 4347 E2F8 C605 OOSF 8801 43CO 2188 023D
`PC-Flu - CR: This 802-byte vims from Poland was made available with the original commented source code from the author. It
`seems to be intended to bypass three specific anti-virus programs, Flushot, Vstop and Virblock, but this has not been tested.
`PC-Flu
`501F 8800 0180 3FE9 7537 4380 3F15 7531 4380 3F05 7528 8800
`PC-Flu-2 - CER: A 2112-byte variant of the previous virus using self-modifying encryption. No simple search pattern is possible.
`
`Plovdiv, New Bulgarian 800 - CR: This vims is 800 bytes long, but the increase is hidden while the virus is active. It contains the text
`'(c) Damage inc.Ver 1.1, Plovdiv,l991 ', but has not been fully analysed yet.
`Plovdiv
`80E2 1F80 FA1E 7506 2681 6F10 2003 0790 5A58 E80 2 C032 559C
`Polish Color - CN: A simple 376-byte Polish virus, which does nothing but replicate.
`Polish Color
`018F 0000 8900 01F3 A45E 88C6 8FOO 0089 0001 F3A4 5E88 C605
`Polish Minimal-45- CN: An attempt to create the world's smallest virus. It overwrites the files it infects which cannot be disinfected.
`Polish-45
`0230 CD21 8808 8440 8AOO 0181 20CO 2184 3ECO 2184 4FE8 OCC3
`Polish Pixel- CN: Two Pixel variants from Poland, which contain crude self-modifying code. They are 457 and 550 bytes long, and
`·
`detected by ~he Pixel-277 pattern.
`
`Rybka- CER: This is a variant of one of the Vacsina (TP-series) viruses. It may infect the same file over and over, increasing its size
`by 1344 bytes each time. Detected by the Vacsina pattern.
`
`Something- CR: A 658-byte virus, which attaches itself in front of .COM files. It appears destructive, containing code to delete files.
`Some thing
`8808 8 9FF FF1E 5233 022E 8E1E 8303 843F C021 725F 3000 E873
`SVC-1740- CER: This 1740-byte virus is closely related to the 1689-byte variant (SVC 4.0) and is detected by the same pattern.
`
`SVC 5.0- CER: An improved version of the earlier SVC viruses, and fully 'stealth'. Awaiting analysis.
`svc 5. 0
`5606 86EO 35FF FFBE COOE 1F33 FF89 9908 FCF3 A607 5E74 03E9
`Vienna-726- CN: A 726-byte variant, detected by the Vienna (4) pattern.
`
`Vienna-Polish 634- CN: This modified version is detected by the Vienna (I) pattern.
`
`Vienna-776- CN: A 776-byte variant. A similar 757-byte variant has also been found. Awaiting analysis.
`Vienna -7 76
`844E 8AOO 0003 0689 0300 C021 E804 844F C02 1 7302 E89F 8884
`Vienna - 757
`844E 8A58 0003 0689 0300 C021 E804 844F C021 7302 E89F 8884
`Voronezh-370- CR: This virus is related to the Voronezh and USSR-600 viruses, perhaps their common ancestor.
`Voronezh - 370
`0500 0188 F08F 0001 FCBA 0434 8888 0546 47E2 F688 0001 50C3
`W13-C - CN: A minor modification of the 507-byte W 13-B variant. The only modification is that this variant sets the month field to
`12, not 13, which makes all files created in December immune to infection. Detected by the Wl3 pattern.
`
`W13-361 - CN: A member of the Wl3 group of Vienna-related viruses. It is detected by the W 13 pattern, but does not function
`properly, as infected programs (second generation) will never run. A 377-byte variant also exists which replicates without problems.
`
`Words - CER: A series of4 Polish viruses, 1069, 1085, 1387 and 1503 bytes long. The two longest variants use self-modifying
`encryption, and no simple search pattern is possible for them. The other variants can be detected with the following pattern:
`Words
`8066 OEFE 5 958 88C1 5E50 90CF 5288 06B4 409C 2EFF 1EOO OOSA
`Yankee-1150 and Yankee-1205- CER: Two stripped-down versions of the Yankee virus which only replicate.
`Yankee- 1150
`C858 5383 E844 C32E 808F 0100 0074 0681 FCFO FF72 ESBC 0848
`Yankee - 1202
`C858 5383 E845 C32E 808F 0100 0074 0681 FCFO FF7 2 E58C 0848
`
`VIRUS BULLETIN ©1991 Viru s Bulletin Ltd, 2 1 The Quadrant, Abingdon Scie nce Park, Oxon, OXI4 3YS, Engla nd. Tel (+44) 235 555139.
`/90/$0.00+2.50 This bulletin is available only to qua litled subscribers. No part ofthis publication may be reproduced, stored in a retrieval system, or transmitted
`by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written perniission of the publishers.
`
`PALO ALTO NETWORKS Exhibit 1062 Page 6
`
`
`
`November 1991
`
`VIRUS BULLETIN
`
`Page 7
`
`TOOLS & TECHNIQUES
`
`David M. Chess
`
`High Integrity Computing Laboratory
`IBM Thomas J. Watson Research Center
`Yorktown Heights, NY, USA
`
`Virus Verification and Removal
`
`The first line of defense against computer viruses consists of
`programs that detect that something is probably wrong. These
`include modification detectors, integrity shells, known-virus
`scanners, access-control programs, and simi lar things. Their
`main function is to alert the user of a machine that a virus,
`some virus, is probably present. The important thing is the
`alert; since something is likely to be wrong, the user should
`stop what he is doing, and take action to correct the problem.
`It doesn't matter much at this stage what the alert says; a first(cid:173)
`line anti-virus system that always said simply 'Something
`virus-like may be going on! ' would be sufficient for most
`environments, if it were usually right.
`
`Once the alert has been given and the infected system taken
`out of immediate contact with other systems, other kinds of
`software become important. Before we can decide how to
`clean up an infected system, and even where else to look for
`infection, we need to know exactly what the infection consists
`of. This paper is a description of one part of the second-line
`toolbox, the virus verifier (and remover).
`
`Virus Verifiers
`
`A virus verifier is a program that, given a file or disk that is
`probably infected with a given virus, determines with a high
`degree of certainty whether the virus is a known strain, or a
`new variant. This is, of course, important to know: if the virus
`is different from any known strain, it will have to be analyzed
`for new effects before we can be confident that we know just
`what to do to clean up after it.
`
`On the other hand, if the virus is identical to a known strain,
`we already know what to do. It is pm1icularly important to
`perform verification in a program that attempts to remove the
`virus infection from an object automatically, restoring it to its
`original uninfected form.
`
`In abstract, a verifier is a program that, given another program
`as input, determines whether or not the given program is part
`of the set of possible ' offspring' of a particular virus. For
`many classes of viruses, including all the viruses actually
`widespread at the moment, this is easy to do. Almost all
`known viruses consist almost entirely of code that does not
`change from infection to infection, except perhaps for a
`
`simple XOR-type garbling, and data areas that are either
`constant, or change in simple ways (or that can be ignored
`entirely for the purposes of verification).
`
`Given a suspect file F and a known virus V, it is therefore
`always relatively simple to answer the question ' is Fa file that
`could have been produced by infection with virus V?'. It is an
`open question of some theoretical interest whether or not
`some future virus might make this harder to do! Reliably
`determining whether a file is infected with any virus at all is
`of course known to be impossible, but we have no similar
`constraint on determining the presence of a specific virus.
`
`Trade-offs and Development Decisions
`
`There are various concrete decisions and trade-offs involved
`in writing a virus verifier; this section will list a few of them,
`while the next sections will describe the verifier currently
`being developed and used at the High Integrity Computing
`Laboratory at IBM's Watson Research Center.
`
`A verifier may be an independent tool, or it may be integrated
`into a virus detector. An integrated detector/verifier can be
`quicker and more convenient, since there's no need for a user
`to find and run a verifier once the detector goes off. On the
`other hand, since most copies of any virus detector will never
`in fact detect a virus (most of the world's computers are not
`infected, after all), integrating a verifier along with the
`detector is in some sense inefficient, in that it adds significant
`code to the detector that may never be used. Howev