Insane Reality issue #7 - (c)opyright 1995 Immortal Riot File 005 % Virus-Bulletin % ------------------ Here follow a few articles from The Virus-Bulletin. I have no clue of how this material got onto my harddrive, but I find it somehow interesting, and decided to publish it. It's what I was told heavily copyrighted, so if someone get's offended seeing AV-material published in an VX-zine, go sue someone, but don't try anything against me. This zine doesn't have any "responsible publisher", so I cannot be found guilty for anything. Imo, information of any kind worth the effort being typed up, should be free and total and if possible released to the major public (such as included in a zine). If you still think I'm responsible for letting this material out, go figure out a way how to prove that XX really is me :-), or don't bother. Ok? I didn't bother to comment and reply upon all articles included, but ah well, I don't care if you don't. There is, however one article I added a few comments in. It was written by Jim Bates and it's about how to catch a viruswriter ;), and why we should be caught. Hmm, maybe this is a good reason? Hehhe, well, don't try it son, you're not that good :-). - XX ================================================================== ============== VB95_209.TXT 컴컴컴컴컴컴 HEURISTIC SCANNERS: ARTIFICIAL INTELLIGENCE? Righard Zwienenberg Computer Security Engineers, Postbus 85 502, NL-2508 CE Den Haag, The Netherlands Tel +31 70 362 2269 Fax +31 70 365 2286 Email rizwi@csehost.knoware.nl Though not explicitly stated, heuristic anti-virus methods have been in use for almost as long as the virus threat has existed. In the 'old days', FluShot(+) was a very popular monitor, alerting the user when it detected 'strange and dangerous' actions. This can be regarded as simple heuristic analysis, because FluShot did not know if the action was legitimate or not. It just warned the user. During the last couple of years, several resident behaviour-blockers have been developed, used, and dismissed again. In most cases, the user finds warnings irritating, aggravating and incomprehensible. The only resident protection they normally use - if any - is a resident scanner. This makes life easier for the users, because the resident scanner clearly indicates that a file or disk is infected by a certain virus when it pops up its box. The disadvantage, which the user doesn't see, is that it does not detect new viruses. Also, the less popular (but very important) Integrity Checkers may be regarded as heuristic tools. They warn the user when the contents of files have been changed, when files have grown in size, received new time and date stamps, etc. They often display a warning such as: 'file might be infected by an unknown virus' in the case of a changed executable. Especially in a development environment, Integrity Checkers can be really irritating. The user already knows that his executable has changed, because he just changed and recompiled the source code. But how is the Integrity Checker to know that? Using a list of executables to skip is not safe, because a virus may indeed have infected an executable on the list. In that case, the change was not caused by a recompilation. However, the integrity checker can't tell the difference! Based on these early attempts, the first generation of scanners with minor heuristic capabilities were developed. The heuristics they used were very basic and usually generated warnings about peculiar file date and file time stamps, changes to file lengths, strange headers, etc. Some examples: EXAMPLE1. COM 12345 01-01-1995 12:02:62 EXAMPLE2. COM 12345 01-01-2095 12:01:36 EXAMPLE3. EXE Entry point at 0000:0001 The heuristics of the current, second, generation of scanners are much better. All the capabilities of the first generation scanners have obviously been retained, but may new heuristic principles have been added: code analysis, code tracing, strange opcodes, etc. For example: 0F POP CS Strange opcode-an 8086-only instruction! C70600019090 MOV WORD PTR [100],9090 C606020190 MOV WORD PTR [102],90 E9 JMP 0100 Tracing through the code shows that it jumps back to the entrypoint: B9 MOV CX,.... BE.... MOV SI,.... 89F7 MOV DI,SI AC LODSB 34A5 XOR AL,A5 AA STOSB E2 LOOP .... This is obviously decryption code. A (third generation?) scanner type based exclusively on heuristics exists, performing no signature, algorithmic or other checks. Maybe this is the future, but the risk of a false alarm (false positive, true negative) is quite high at the moment. In large corporations, false alarms (false positives) can cost a lot of time and thus money. We are not going to examine this scanner type except to note that it may lead us into a new generation, or area, of system examination and protection: Rule-based Examination Systems. RULE-BASED EXAMINATION SYSTEMS Rule-based systems are as such not a novelty. They already exist, also in the security field. In this field they are often characterised by applying very few, but very broad, rules. What we are going to look at here are Rule-based Examination Systems seen as large heuristics analysers. Looking at this sequence of opcodes: B8DCFE MOV AX,FEDC CD21 INT 21 3D98BA CMP AX,BA98 75.. JNE getint21 E9.. JMP wherever getint21: B92135 MOV AX,3521 CD21 INT 21 everyone in the field of computer security can see that we may have a virus here (or at least suspicious or badly programmed code). The problem is how to convert something we see in a split second into one or more specific and relevant behaviour characteristics, which we can feed into an examination system. This in turn is able to tell us whether or not we are looking at a virus. With most of the rules used by the first generation of heuristic scanners, this was not at all difficult. Most were simple comparisons (<,>,==,!=) of the type: 'If a file date exceeds the current date, or is after the year 2000, give an alert';'If the seconds field of the file time shows 62 seconds, we can conclude that this is pretty strange and give an alert'. This generation of heuristics, of course, did not have the power the analyse the code in the example shown above. The second generation of heuristic scanners has more possibilities. Bearing those in mind, defining a rule to cover the example above is not difficult, but imagine a complex decryption routine preceding the actual (virus/Trojan/suspicious) code or-most likely- legitimate code. For example: re-vector int 3 re-vector int 1 disable keyboard get int1 offset into di get int1 offset into si add counter-1 to si to point to encrypted data add counter-2 to di to point to encrypted data get word into ax perform some calculations with ax to decrypt word store word increase counter-1 increase counter-2 look if end of encrypted code has been reached jmp back if more code to decrypt enable keyboard... In case this is just one of the instances generated by a complex mutation engine, it will be hard to derive a heuristic rule directly to detect a virus using this engine. One of the solutions, maybe the best one, is to include a code emulator in the analysing system as illustrated in the figure above (missing --Ed.), which shows a part of a working network security system. The file to be checked is first given to a checksummer. If the file is already known to the system, a hash code is generated across the file, and this is compared to a stored value. If these are identical, no further action is taken, and the file is declared clean. If not, the file is fed to the emulator, and the results from the code emulation are given to an analyser as described below. Including a code emulator is possible, and as a matter of fact has already been done. It should have special knowledge of a variety of possible tricks used in malicious code; it should know when to stop emulating (e.g. at the end of a decryption routine); it should be able to realise when anti-debug tricks are used, etc. Both in order to obtain portability, and to avoid obvious pitfalls, it must adhere to one basic and important rule: Never actually execute an instruction, only emulate it. In short, the task of the emulator is first to make sure that the code is decrypted (in case it was encrypted), and then to derive and combine relevant behaviour characteristics to pass on to the analyser, which analyses and organises these behaviour characteristics and compares the results of the analysis with a set of rules. ARTIFICIAL INTELLIGENCE From the point of view of the developer it would be nice if such a system were able to learn about behaviour characteristics and generate new rules automatically. If the system bypasses an instance of virus/Trojan/suspicious code because the current rules are no longer sufficient, special examination tools should be able to extract the necessary information from the code in question and create new rules enabling the system to detect this trojan/virus/suspicious code, and hopefully every other form derived from this one. In other words: Artificial Intelligence. For security reasons, these additional tools with their special functionality should not be given to users. Evil-minded knowledgeable persons could use them to do an in-depth disassembly to research the possibilities of bypassing the rules generated by the system. Security through obscurity may not be safe, but it does help... EMULATOR DESIGN ISSUES When designing a code emulator for forensic purposes, a number of special requirements must be met. One problem to tackle is the multiple opcodes and multiple instructions issue: 87 C3 XCHG AX,BX 93 XCHG BX,AX 87 D8 XCHG BX,AX The result is the same, but different opcodes are used. PUSH AX PUSH AX PUSH BX MOV AX,BX POP AX POP BX POP BX These give the same result. More than the five different code sequences shown above exist to exchange the contents of registers AX and BX. The technique of expressing the same functionality using many different sets of opcode sequences is used by encryptors generated by polymorphic engines. Some being over 200 bytes in size, they only contain the functionality of a cleanly coded decryptor of 25 bytes. Most of the remaining code is redundant, but sometimes seemling redundant code is used to initiate registers for further processing. It is the job of the emulator to make sure that the rule-based analyser gets the correct information, i.e. that the behaviour characteristics passed to the analyser reflect the actual facts. No matter which seris of instructions/opcodes are used to perform 3D02h/21h, the analyser only has to know that the behaviour of that piece of code is: Open a file for (both reading and) writing. On the one hand, this may not seem that difficult. Most viruses do perform interrupt calls, and when they do, we just have to evaluate the contents of the register to derive the behaviour characteristic. On the other hand, this is only correct if we talk about simple, straightforward viruses. For viruses using different techniques (hooking different interrupts, using call/jmp far constructions) it may be very difficult for the emulator to keep track of the instruction flow. In any case, the emulator must be capable of reducing instruction sequences to the bare functionality in a well-defined manner. We call the result of this reduction a behaviour characteristic, if it can be found in a pre-compiled list of characteristics to which we attach particular importance. Another problem is that the emulator must be capable of making important decisions, normally based on incomplete evidence (we obviously want to emulate as little code as possible before reaching a conclusion regarding the potential maliciousness of the software in question). Let us illustrate this with a small example: MOV AX, 4567 INT 21 CMP AX, 7654 JNE jmp-1 JMP jmp-2 This is an example of an 'Are you there?' call used by a virus. When tracing through the code, the emulator obviously doesn't know whether jmp-1 or jmp-2 leads to the code which installs the virus in case it is not already there. So, should the emulator continue with the jmp-1 flow or the jmp-2 flow? Now, a simple execution of the code will result in just one of these flows being relevant, whereas a forensic emulator must be able to follow all possible program flows simultaneously, until either a flow leads to a number of relevant behaviour characteristics being detected, at which time the information is passed to the analyser, or a flow has been followed to a point where one of the stop-criteria built into the emulator is met. The strategy used in this part of the emulator is a determining factor when it comes to obtaining an acceptable scanning speed. Hopefully, this has illustrated some of the problems associated with designing a forensic emulator. It is a very diffcult and complex part of this set-up. Once the emulator has finished its job it passes information, a list of behaviour characteristics which it has found in the code, on to the analyser. BEHAVIOUR RULES Before the analyser is able to compare the behaviour characteristics found by the emulator to information in its behaviour database, this database needs to be defined. Assume that we have a COM and an EXE file infecting virus with the following behaviour: ! MODIFY FILE ATTRIBUTE REMOVING READ-ONLY FLAG ! OPEN A FILE FOR (BOTH READING AND) WRITING !* WRITE DATA TO END OF FILE !* MODIFY ENTRY POINT IN HEADER or WRITE TO BEGINNING OF FILE - MODIFY FILE DATE AND FILE TIME - CLOSE FILE - MODIFY FILE ATTRIBUTE If we want to develop a behaviour rule for this virus, it will look like this: 1. MODIFY_FILE_ATTRIBUTE + OPEN_FILE + WRITE_DATA_TO_EOF + MODIFY_EP_IN_HEADER 2. MODIFY_FILE_ATTRIBUTE + OPEN_FILE + WRITE_DATA_TO_EOF + WRITE_DATA_TO_BOF where rule 1 is a rule for the EXE-file, and rule 2 for the COM file. Since a lot of viruses and virus source codes are widely available, a number of different instruction sequences resulting in this functionality will probably show up. Normally, derived viruses contain minor changes to bypass a single scanner by just changing the order of two or more instructions, but sometimes larger code sequences can be changed without changing the functionality of the virus. It is trivial to change the code, so it will first modify the entry-point in the header of change the start-up code, and afterwards write the virus code. In order to detect these changes (variants) the next rules may be added: 3. MODIFY_FILE_ATTRIBUTE + OPEN_FILE + MODIFY_EP_IN_HEADER + WRITE_DATA_TO_EOF @CODE LINE = 4. MODIFY_FILE_ATTRIBUTE + OPEN_FILE + WRITE_DATA_TO_BOF + WRITE_DATA_TO_EOF Another example (an MBR infector): - PERFORM SELF CHECK ! HOOK INT13 ! BECOME RESIDENT ! INTERCEPT READ/WRITE TO MBR ! READ MBR -* WRITE MBR TO OTHER LOCATION !* WRITE NEW MBR Rule: HOOK_INT13 + INTERCEPT_READ/WRITE_TO_MBR + WRITE_NEW_MBR The signs in front of the descriptors in the examples above hint at the weighing procedure used by the analyser to attach significance to the behaviour characteristics supplied by the emulator A. '-' means that the characteristic does not have to be present, an '!' that it must be present (but does not in itself indicate malicious code). A '*' indicates a high weighing value. This '-*' means that the characteristic does not have to be present in the sequence of actions, but if it is, this is a highly important fact. If rules 1-4 above are examined more closely, it can be concluded that they describe behaviour found in a number of viruses from different families. A single behaviour rule may detect an unlimited number of viruses. That is the power behind using behaviour characteristics. While at present we in most cases need a new signature or new (changed) algorithm to detect a new variant of a virus or a new virus family, the behaviour characteristics will continue to do their work. This is extremely important, because it removes the necessity for the virus researcher and the anti-virus developer to react to a new virus unless its technologically innovative. And those are few and far between. Of course, some viruses will be developed which will not be caught by any of the rules in the behaviour database. These must be taken care of just like we do right now with any new virus; but instead of creating a signature, we create a new rule. With a little luck, a new virus behaves like a virus already covered by a rule. If we attach a level of importance to each part of a behaviour characteristic, we can use this in the analyser to arrive at a conclusion. Depending on the level of importance of each individual component of a behaviour characteristic detected, the system may decide to give a message to the user, such as 'may be infected by an unknown virus', or 'suspicious code'. The reason for attaching a level of importance to each individual part of a behaviour characteristic is that it makes it easier to sort out cases where combinations of individually innocent behaviour characteristics put together constitute malicious code-or vice versa. Filedate, from Norton's Utilities, is able to change file date and time; as a matter of fact, this is the purpose of the utility. The ATTRIB command is developed to change file attributes. Evidently, changing file attributes is in itself insufficient evidence of malicious behaviour. A virus needs to write to a file as well. So a file write is mandatory for code to be considered suspicious and is heavily weighted. A change of attributes is not that important, and thus given a lower weighting. If the user so wishes, the file or part of the (decryptor) code on which the analysing system triggered can be checked by a signature scanner to see if a virus can be identified. CREATING RULES AUTOMATICALLY An important part of the system is a Rule Building Utility. Whenever a new virus or Trojan emerges, it may be processing by this utility, which is similar to the emulator, albeit with some important differences. The emulator only collects behaviour information without knowing anything about the importance of a particular type of behaviour, or if the behaviour is suspicious. The Rule Building Utility has to learn the level of importance of behaviour characteristics, has to know which behaviour is mandatory for a virus or Trojan, which behaviour is used by a virus but may be omitted, etc. Because research and development time is very expensive, the utility must be able to remember this for similar behaviour characteristics, and only ask for additional unknown information when needed,, saving the researcher valuable time. Behaviour A: Behaviour B: SEARCH FIRST FILE SEARCH FIRST FILE DELETE FILE DELETE FILE SEARCH NEXT FILE CREATE FILE WRITE CODE INTO FILE SEARCH NEXT FILE When rules have been defined for behaviour B and a file (behaviour A, which was reported being suspicious) is processed, the utility must be able to realise that this behaviour is not as indicative of potential maliciousness as behaviour A. (Typo? Should be B? --Ed.) As a matter of fact, if behaviour A is taken on its own, it might well be a DEL *.* command. At first, the utility will, ask for input frequently, because it needs to build up its database. However, over a period of time this type of utility should make life easier for the researcher. CONCLUSION The number of viruses is increasing rapidly: this is a known fact. The time will soon arrive when scanning using signatures and dedicated algorithms will either use too much memory or just become too slow. With storage media prices dropping fast, lots of systems now come equipped with very large hard disks, which will take more and more time, and thus money, to scan using traditional techniques. A properly designed rule-based analysing system feeding suspicious code into a scanner, which can identify the suspicious code as a known virus or Trojan, or perhaps dangerous code needing further investigation, is bound to save a lot of time. Although it is impossible to prove that code is not malicious without analysing it from one end to the other, we in Computer Security Engineers Ltd believe it possible to reduce significantly the time used to check files by using all the available system knowledge instead of only small bits of it, as it is done today. Using virus scanning as the primary, or in many cases the only, anti-virus defence is an absurd waste of time and money, and furthermore blatantly insecure! ABOUT CSE Computer Security Engineers Ltd is one of the pioneers of anti-virus system development. The anti-virus system PC Vaccine Professional was first published in 1987, and since the start of 1988 a new version has been published each and every month. From 1988, cryptographic checksumming was introduced as the primary line of defence, scanning as the second. in 1992, the emphasis shifted, and behaviour blocking was introduced as the first line of defence, followed by checksumming and-in the case of an alarm from one of these countermeasure or to examine incoming diskettes-scanning for known viruses. Most recently, the basic philosophies underlying PC Vaccine Professional, or PCVP as the system is also known, were expanded into a powerful and easily-maintained network perimeter and an in-depth defence based on the well-known military tenets of:(1) keep them out and (2) if you can't keep them out, find and destroy them as fast as possible. ================================================================== ============= VB_210.TXT 컴컴컴컴컴 VIRUS DETECTION-'THE BRAINY WAY' Glenn Coates&David Leigh Staffordshire University,School of Computing,PO Box 334,Beaconside, Stafford, ST18 ODG,UK Tel +44 1782 294000 Fax +44 1782 353497 ABSTRACT This paper explores the potential opportunities for the use of Neural Networks in the detection of computer viruses. Neural computing aims to model the guiding principles used by the brain for problem solving, and apply them to a computer domain. It is not known how the brain solves problems at a high level;however, it is widely known that the brain uses many small highly interconnected units called 'neurons'. Like the brain, a neural network can be trained to solve a particular problem or recognise a pattern by example. The outcome is an algorithm-driven recogniser which does not exhibit the same behaviour as a deterministic algorithm. According to the way in which it has been trained, it may make 'mistakes'. That is, it may declare a positive result for a smple which is actually negative, and vice-versa. The ratio of correct results to incorrect results can usually be improved by more and better training. Can such pattern recognition be harnessed to the use of virus detection? It could be argued that the characteristics of virus patterns, no matter how they are expressed, are suitable subjects for detection by Neural Networks. INTRODUCTION The received wisdom is that neural computing is an interesting 'academic toy' of little use, apart from modelling the animal brain. If this is true, then it is surprising that 7 out of 10 of the UK's leading blue chip companies are either investigation the potential of neural computing technology or are actually developing neural applications[Con94]. If leading edge companies are prepared to spend money on this 'academic toy', then maybe there are advantages to be gained from its use. Without investigation new techniques (for example heuristic scanning), one must accept that the rapid rise in new viruses will exert a heavy speed penalty from existing virus scanners. As a result of this rise in virus numbers and sophistication, there will be an increasing conflict between acceptable speed and acceptable accuracy. It is easy to become complacent and rely on increasing processor power to bail us out of this problem, but processor design is increasingly becoming a mature technology. What follows are the results of a feasibility study into the utilisation of neural networks within the field of virus detection. WHAT IS A NEURAL NETWORK? The working of the brain are only known at a very basic level. It contains approximately ten thousand million processing units called neurons, each of these neurons is connected to approximately ten thousand others. This network of neurons forms a highly complex pattern recognition tool, capable of conditional learning. Figure 1 illustrates a model of the biological neuron alongside its corresponding mathematical model. This individual neuron is stimulated by one or more inputs. In the biological neuron, some inputs will tend to excite the neuron, whilst others may be inhibitory. That is to say, some carry more 'weight' than others. This is mirrored in the mathematical model via the use of a 'weighting mechanism'. The neuron accumulates the total value of its inputs, before passing through a threshold function to determine its final output. This output is then fired as an input to another (or a number of) neurons, and so on. In the biological neuron, the axon performs the threshold function. The mathematical model would typically used a sigmoid function or a simple binary 'yes/no' threshold function. The reader is referred to [Mar93] for further discussion. NEURAL NETWORK DEVELOPMENT When approaching a problem using a neural network, it is not always necessary to know in detail what is to be done before planning its use. In this sense, they are quite unlike procedurally-based computer programs, which have been written with a distinct goal in mind if they are to work properly. It is not even like a declarative program, for the same rule should apply. It is, perhaps, more like an expert system, where the outcome depends on the way in which an expert has answered a pre-defined series of questions. In this approach, a 'standard' three-layer neural network is constructed using the 'back propagation' learning algorithm. The architecture consists of an input layer, a hidden layer, and an output layer. Training is carried out by submitting a 'training set' of data to the network's input, observing what output is given, and adjusting the variable weights accordingly. Each neuron in the network processes its inputs, with the resultant values steadily percolating through the network until a result is given by the output layer. This output result is then compared to the actual result required for the given input, giving an error value. On the basis of this error value, the weights in the network are gradually adjusted, working backwards from the output layer. This process is repeated until the network has learnt the correct response for the given input [DTI95]. Figure 2 illustrates this. In this instance, the inputs represent the virus information, or other data concerning a virus-infected file. There are only two possible outputs, corresponding to 'possible virus found' and 'file appears to be OK'. The training data is divided into two classes, one containing the data for an infected file;and the other, uninfected files. When a suitable output is generated for the training data, the network is checked with a separate 'validation set'. if the output for the validation set is not acceptable, it is merged with the original training set and the entire process is repeated. This process is described schematically in figure 3. The result should be a very robust fuzzy recogniser capable of coping with unseen data. Because neural networks can process deeply hidden patterns, some have provided decisions superior to those made by trained humans. EXISTING SYSTEMS In 1990, a neural network was developed which acted as a 'communications link' between the mass of virus information available and end-user observations. By answering a set of standard questions regarding information on virus symptoms, the virus could be classified, and a set of remedies was given. Due to the nature of neural networks, the system could cope with incomplete and erroneous data provided by the end user. Even when faced with a new mutation, the system still gave suitable counter-measures and information. See [Gui91] for a full discussion. IDENTIFICATION OF VIRUS CODE PATTERNS VIA NEURAL NETWORKS A neural network could be constructed to learn the actual machine code patterns of a specific virus. However, as most viruses are mutations of existing viruses, a network could be made to identify a virus family. This carries the advantage of being capable of identifying future variants. This would result in a set of sub-networks linked together to provide the end solution. At the lowest level this could be done at the bit level. Figure 4 illustrates this. Although recognition at this level would be very difficult (if not impossible for a human) a neural network would be capable of it. The only limiting factors would be the volume and quality of the training data. The number of input neurons for a 1/2K virus code segment with a one-neuron output would be 4096. Given this, according to the 'geometric pyramid rule', the number of neurons in the hidden layers would be 64. The number of virus samples for effective recognition would be in the region of at least 525,000. This figure should then be trebled for the number of non-infected files. Others would argue far more, due to the problems associated with false positives. At a higher level, the input data could be represented at the byte level, where each byte would correspond to a single input neuron. In this context, the number of hidden neurons would be reduced to 22, and the number of virus samples would be at least 23,000. Again, the same applies for the number of non-infected files. This figure could be reduced further by pre-processing the code segment by extracting operand information, which could also increase accuracy and training time. The British Technology Group, with the involvement of Oxford University, conducted research into such a solution. Although no formal documentation was procued, the results are believed to be negative. From this, it can be seen that the use of neural networks in virus detection only seems practical at a high level. After all, a virus expert armed with a 'Virus Detection Language' and a 'Generic Decryption Engine' can provide a 100% accurate scanning result with advanced polymorphic viruses such as Pathogen in a relatively short period of time. A NEURAL NETWORK POST-PROCESSOR Rather than utilising a neural network to solve the virus alone, one could be used to process high level information, for example, that generated by a heuristic scanner. Currently, most heuristic scanners use a form of emulation in order to determine the behaviour of a program file. Should that program appear to execute a suspicious activity, a 'flag' is set indicating this. However, some of these flags indicate more virus-like activity than others. In order to solve this problem, the flags are weighted via a score. Therefore, a flag indicating a 'suspicious memory reference' may be given more weighting than a flag indicating an 'inconsistent EXE header'. The total weights of the set flags are computed, and if a set threshold value is met, the heuristic scanner issues a suitable warning. In the example of a well-known heuristic scanner, 35 of these flags are used. The weights are applied on an experimental basis. Initially, the weights are applied using a 'best-guess approach', based on the virus experts' knowledge. The reuslts of this are then tested on a virus collection and on a clean set of files. The results are analysed, and the weights adjusted accordingly. This cycle continues until satisfactory results are obtained. Figure 5 illustrates this cycle. This process will probably increase in complexity over the next few years. In the above example, the number of flags could literally double due to the increase in knowledge, new techniques employed by the virus writers, and further development of heuristic scanners. It is imminent that the cycle of adjust, re-adjust will become far more complex and time-consuming. For example, why should flag-x be given a weight of 8, and not 7 or 9, and flag-y be given a weight of 1, and not 2? Already, one can see that the illustrated cycle is very similar in nature to that used in neural network training. Indeed, a neural network could be used in place of the weighting mechanism and bias imposed by the virus expert. Based on the results of other neural network applications, the results should be very accurate, because the neural network will 'learn' the 'optimum' weights. The human element is removed, and the entire learning process is automated. In terms of network size, the number of input neurons would be 35, with 6 hidden neurons, and 1 output neuron. In theory, the minimum number of infected samples required for training would be at least 432. However, there would be no detrimental effects from training the network with higher samples, in order to reflect current virus numbers. CONCLUSIONS Neural computing is no longer seen as a pure academic subject. Indeed, many companies are now looking towards the use of neural networks as serious tools. Many systems are currently in use, with very high success rates. It has been found that it may be feasible to use neural computing technology in the virus detection field. However, at a low level the results are unclear. There seems to be greater accuracy using deterministic techniques. Using a neural network as a pre-/post-processing tool could offer a powerful addition to the virus expert's toolbag. Just one example is with the heuristic scanner. The authors believe other uses will also exist. ACKNOWLEDGMENTS As Bernard of Chartres said, echoed by Sir Isaac Newton:'If [we] have seen further, it is by standing on the shoulders of giants'. The assistance given by the following people is gratefully acknowledged: Jan Hruska, Frans Veldman, Alan Solomon, Martin Slade, Robert Mortimer and Michael Twist. The continuing support of the staff at Staffordshire University and at Visionsoft has also been gratefully appreciated. REFERENCES [Con94] 'Adopting The Neural Approach',Control Magazine,Issue 5, March/April 1994. [DTI95] UK Department Of Trade And Industry,Neural Computing Technology Programme,1995. [Gui91] Dr. Daniel Guinier,'Computer 'virus' identification by neural networks',SIGSAG,1991. [Mar93] Timothy Masters,'Practical Neural Networks in C++',Academic Press,1993. ISBN 0-12-479040-2 Further Reading. 'Neural Computing-an introduction',R Beale and T Jackson, IOP Publishing,1990. Vesseling Bontchev,Future Trends in Virus Writing,Proceedings of the Fourth International Virus Bulletin Conference,1994. Glenn Coates and David J. Leigh,'Virus Detection using a Generalised Virus Description Language',Proceedings of the Fourther International Virus Bulletin Conference,1994. ================================================================== ============= VB95_212.TXT 컴컴컴컴컴컴 SCANNERS OF THE YEAR 2000: HEURISTICS Dmitry O. Gryaznov S&S International Plc,Alton House,Gatehouse Way,Aylesbury,Buck,HP13 3XU,UK Tel +44 1296 318700 Fax +44 1296 318777 Email grdo@sands.co.uk INTRODUCTION At the beginning of 1994, the number of known MS-DOS viruses was estimated around 3,000. One year later, in January 1995, the number of viruses was estimated at about 6,000. By the time this paper was written (July 1995), the number of known viruses exceeded 7000. Several anti-virus experts expect this number to reach 10,000 by the end of the year 1995. This large number of viruses, which keeps growing fast, is known as the glut and it does cause problems to anti-virus software-especially to scanners. Today, scanners are the most frequently used type of anti-virus software. The fast-growing number of viruses means that scanners should be updated frequently enough to cover new viruses. Also, as the number of viruses grows, so does the size of the scanner or its database, and in some implementations the scanning speed suffers. It was always very tempting to find a final solution to the problem; to create a generic scanner which can detect new viruses automatically without the need to update its code and/or database. Unfortunately, as proven by Fred Cohen, the problem of distinguishing a virus from a non-virus program is algorithmically unsolvable as a general rule. Nevertheless, some generic detection is still possible, based on analysing a program for features typical or not typical of viruses. The set of features, possibly together with a set of rules, is known as heuristics. Today, more and more anti-virus software developers are looking towards heuristical analysis as at least a partial solution to the problem. Working at the Virus Lab, S&S International Plc, the author is also carrying out a research project on heuristic analysis. The article explains what heuristics are. Positive and negative heuristics are introduced and some practical heuristics are represented. Different approaches to a heuristical program analysis are discussed and the problem of false alarms is explained and discussed. Several well-known scanner employing heuristics are compared (without naming the scanners) both virus detection and false alarms rate. 1 WHY SCANNERS? If you are following computer virus-related publications, such as the proceedings of anti-virus conferences, magazine reviews, anti-virus software manufacturers' press releases, you read and hear mainly 'scanners,scanners, scanners'. The average user might even get the impression that there is no anti-virus software other than scanners. This is not true. There are other methods of fighting computer viruses-but they are not so popular or as well known as scanners; and anti-virus packages based on non-scanner technology do not sell well. Sometimes people who are trying to promote non-scanner based anti-virus software even come to the conclusion that there must be some kind of an international plot of popular anti-virus scanner producers. Why is this? Let us briefly discuss existing types of anti-virus software. Those interested in more detailed dicussion and comparison of different types of anti-virus software can find it in [Bontchev1], for example. 1.1 SCANNERS So, what is a scanner? Simply put, a scanner is a program which searches files and disk sectors for byte sequences specific to this or that known virus. Those byte sequences are often called virus signatures. There are many different ways to implement a scanning technique; from the so-called 'dumb' or 'grunt' scanning of the whole file, to sophisticated virus-specific methods of deciding which particular part of the file should be compared to a virus signature. Nevertheless, one thing is common to all scanners: they detect only known viruses. That is, viruses which were disassembled or analysed and from which virus signatures unique to a specific virus were selected. In most cases, a scanner cannot detect a brand new virus until the virus is passed to the scanner developer, who then extracts an appropriate virus signature and updates the scanner. This all takes time-and new viruses appear virtually every day. This means that scanners have to be updated frequently to provide adequate anti-virus protection. A version of a scanner which was very good six months ago might be no good today if you have been hit by just one of the several thousand new viruses which have appeared since that version was released. So, are there any other ways to detect viruses? Are there any other anti-virus programs which do not depend so heavily on certain virus signatures and thus might be able to detect even new viruses? The answer is yes, there are: integrity checkers and behaviour blockers(monitors). These types of anti-virus software are almost as old as scanners, and have been known to specialists for ages. Why then are they not used as widely as scanners? 1.2 BEHAVIOUR BLOCKERS A behaviour blocker (or a monitor) is a memory-resident (TSR) program which monitors system activity and looks for virus-like behaviour. In order to replicate, a virus needs to create a copy of itself. Msot often, viruses modify existing executable files to achieve this. So, in most cases, behaviour blockers try to intercept system requests which lead to modifying executable files. When such a suspicious request is intercepted, a behaviour blocker, typically, alerts a user and, based on the user's decision, can prohibit such a request from being executed. This way, a behaviour blocker does not depend on detailed analysis of a particular virus. Unlike a scanner, a behaviour blocker does not need to know what a new virus looks like to catch it. Unfortunately, it is not that easy to block all the virus activity. Some viruses use very effective and sophisticated techniques, such as tunnelling, to bypass behaviour blockers. Even worse, some legitimate programs use virus-like methods which would trigger a behaviour blocker. For example, an install or setup utility is often modifying executable files. So, when a behaviour blocker is triggered by such a utility, it's up to the user to decide whether it is a virus or not-and this is often a tough choice: you would not assume that all users are anti-virus experts, would you? But even an ideal behaviour blocker (there is no such thing in our real world, min you!), which never triggers on a legitimate program and never misses a real virus, still has a major flaw. To enable a behaviour blocker to detect a virus, the virus must be run on a computer. Not to mention the fact that virutally any user would reject the very idea of running a virus on his/her computer, by the time a behaviour blocker catches the virus attempting to modify executable files, the virus could have triggered and destroyed some of you valuable data files, for example. 1.3 INTEGRITY CHECKERS An integrity checker is a program which should be run periodically (say, once a day) to detect all the changes made to your files and disks. This means that, when an integrity checker is first installed on your system, you need to run it to create a database of all the files on your system. During subsequent runs, the integrity checker compares files on your system to the data stored in the database, and detects any changes made to the files. Since all viruses modify either files or system areas of disks in order to replicate, a good integrity checker should be able to spot such changes and alert the user. Unlike a behaviour blocker, it is much more difficult for a virus to bypass an integrity checker, provided you run your integrity checker in a virus clean environment-e.g. having booted your PC from a known virus-free system diskette. But again, as in the case of behaviour blockers, there are many possible situations when the user's expertise is necessary to decide whether changes detected are the result of virus activity. Again, if you run an install or setup utility, this normally results in modifications to your files which can trigger an integrity checker. That is, every time you install new software on your system, you have to tell your integrity checker to register these new files in its database. Also, there is a special type of virus, aimed specifically at integrity checkers-so-called slow infectors. A slow infector only infects objects which are about to be modified anyway; e.g. as a new file being created by a compiler. An integrity checker will add this new file to its database to watch its further changes. But in the case of a slow infector, the file added to the database is infected already! Even if integrity checkers were free of the above drawbacks, there still would be a major flaw. That is, an integrity checks can alert you only after a virus has run and modified your files. As in the example given while discussing behaviour blockers, this might be well too late. 1.4 THAT'S WHY SCANNERS! So, the main drawbacks of both behaviour blockers and integrity checkers, which prevent them from being widely used by an average user, are: 1. Both behaviour blockers and integrity checkers, by their very nature, can detect a virus only after you have run an infected program on your computer, and the virus has started its replication routine. By this time it might be too late-many viruses can trigger and switch to destructive mode before they make any attempts to replicate. It's somewhat like deciding to find out whether these beautiful yet unknown berries are poisonous by eating them and watching the results. Gosh! You would be lucky to get away with just dyspepsia! 2. Often enough, the burden to decide whether it is a virus or not is transferred to the user. It's as if your doctor leaves you to decide whether your dyspepsia is simply because the berries were not ripe enough, or it is the first sign of deadly poisoning, and you'll be dead in few hours if you don't take an antidote immediately. Though choice! On the contrary, a scanner can and should be used to detect viruses before an infected program has a change to be executed. That is, by scanning the incoming software prior to installing it on your system, a scanner tells you whether it is safe to proceed with the installation. Continuing our berries analogy, it's like having a portable automated poisonous plants detector, which quickly checks the berries against its database of known plants, and tells you whether or not its safe to eat the berries. But what if the berries are not in the database of your portable detector? What if it is a brand new species? What if a software package you are about to install is infected with a new, very dangerous virus unknown to your scanner? Relying on your scanner only, you might find yourself in big trouble. This is where behaviour blockers and integrity checkers might be helpful. It's still better to detect the virus while it's trying to infect your system, or even after it has infected but before it destroys your valuable data. So, the best anti-virus strategy would include all three types of anti-virus software: - a scanner to ensure the new software is free of at least known viruses before you run the software - a behaviour blocker to catch the virus while it is trying to infect your system. - an integrity checker to detect infected files after the virus has propagated to your system but not yet triggered. As you can see, the scanners are the first and the most simply implemented line of anti-virus defence. Moreover,most people have scanners as the only line of defence. 2 WHY HEURISTICS? 2.1 GLUT PROBLEM As mentioned above, the main drawback of scanners is that they can detect only known computer viruses. Six or seven years ago, this was not a big deal. New viruses appeared rarely. Anti-virus researchers were literally hunting for new viruses, spending weeks and months tracking down rumours and random reports about a new virus to include its detection in their scanners. It was probably during these times that a most nasty computer virus-related myth was born that anti-virus people develop viruses themselves to force users to buy their products and profit this way. Some people believe this myth even today. Whenever I hear it, I can't help laughing hysterically. Nowadays with two to three hundred new viruses arriving montly, it would be a total waste of time and money for anti-virus manufacturers to develop viruses. Why should they bother if new viruses arrive in dozens virtually daily, completely free of charge? There were about 3,000 known DOS viruses at the beginning of 1994. A year later, in January 1995, the number of viruses was estimated at least 5,000. Another six months later, in July 1995, the number exceeded 7,000. Many anti-virus experts expect the number of known DOS viruses to reach the 10,000 mark by the end of 1995. With this tremendous and still fast-growing number of viruses to fight, traditional virus signature scanning software is pushed to its limits [Skulason, Bontchev2]. While several years ago a scanner was often developed, updated and supported by a single person, today a team of a dozen skilled employers is only barely sufficient. With the increasing number of viruses, R&D and Quality Control time and resource requirements grow. Even monthly scanner updates are often late, by one month at least! Many formerly succesful anti-virus vendors are giving up and leaving the anti-virus battleground and market. The fast-growing number of viruses heavily affects scanners themselves. They become bigger, and sometimes slower. Just few years ago a 360Kb floppy would be enough to hold half a dozen popular scanners, leaving plenty of room for system files to make the diskette bootable. Today, an average good signature- based scanner alone would occupy at least a 720Kb floppy, leaving virtually no room for anything else. So, are we losing the war? I would say: not yet-but if we get stuck with just virus signature scanning, we will lose it sooner or later. Having realised this some time ago, anti-virus researchers started to look for more generic scanning techniques, known as heuristics. 2.1 WHAT ARE HEURISTICS? In the anti-virus area, heuristics are a set of rules which should be applied to a program to decide whether the program is likely to contain a virus or not. From the very beginning of the history of computer viruses different people started looking for an ultimate generic solution to the problem. Really, how does an anti-virus expert know that a program is a virus? It usually involves some kind of reverse engineering (most often disassembly) and reconstructing and understanding the virus' algorithm: what it does and how it does it. Having analysed hundreds and hundreds of computer viruses, it takes just few seconds for an experienced anti-virus researcher to recognise a virus, even it is a new one, and never seen before. It is almost a subconscious, automated process. Automated? Wait a minute! If it is an automated process, let's make a program to do it! Unfortunately (or rather, fortunately) the analytic capabilities of the human brain are far beyond those of a computer. As was proven by Fred Cohen [Cohen], it is impossible to construct an algorithm (e.g. a program) to distinguish a virus from a non-virus with 100 per cent reliability. Fortunately, this does not rule out a possibility of 90 or even 99 per cent reliability. The remaining one per cent, we hope to be able to solve using our traditional virus signatures scanning technique. Anyway, it's worth trying. 2.2 SIMPLE HEURISTICS So, how do they do it? How does an anti-virus expert recognise a virus? Let us consider the simplest case: a parasitic non-resident appending COM file infector. Something like Vienna, but even more primitive. Such a virus appends its code to the end of an infected program, stores (usually just three) first byte of the victim file in the virus body and replaces those bytes with a code to pass control to the virus code. When the infected program is executed, the virus takes control. First, it restores the original victim's bytes in its memory image. It then starts looking for other COM files. When found, the file is opened in Read_and_Write mode;then the virus reads the first few bytes of the file and writes itself to the end of the file. So, a primitive set of heuristical rules for a virus of this kind would be: 1. The program immediately passes control close to the end of itself 2. It modifies some bytes at the beginning of its copy in memory 3. Then it starts looking for executable files on a disk 4. When found, a file is opened 5. Some data is read from the file 6. Some data is written to the end of file. Each of the above rules has a corresponding sequence in binary machine code or assembler language. In general, if you look at such a virus under DEBUG, the favourite tool of anti-virus researchers, it is usually represented in a code similar to this: START: ; Start of the infected program JMP VIRUSCODE ; Rule 1: the control is passed ; to the virus body ; VIRUS: ; Virus body starts here SAVED: ; Saved original bytes of the victim's code MASK: DB '*.COM',0 ; Search mask VIRUSCODE: ; Start of the virus code MOV DI,OFFSET START ; Rule 2: the virus restores MOV SI,OFFSET SAVED ; victim's code MOVSW ; in memory MOVSB MOV DX,OFFSET MASK ; Rule 3: the virus MOV AH,4EH ; looks for other INT 21H ; programs to infect MOV AX, 3D02H ; Rule 4: the virus opens a file INT 21H ; MOV DX,OFFSET SAVED ; Rule 5: first bytes of a file MOV AH,3FH ; are read to the virus INT 21H ; body MOV DX,OFFSET VIRUS ; Rule 6: the virus writes itself MOV AH,40H ; to the file INT 21H When an anti-virus expert sees such code, it is immediately obvious that this is a virus. So, our heuristical program should be able to disassemble a binary machine-language code in a similar manner to DEBUG, and to analyse it, look for particular code patterns in a manner similar to an anti-virus expert. In the simplest cases, such as the one above, a set of simple wildcard signature string matching would do for the analysis. In this case, the analysis itself is simply checking whether the program in question satisfies rules 1 through 6;in other words, whether the program contains pieces of code corresponding to each of the rules. In a more general case, there are many different ways to represent one and the same algorithm in machine code. Polymorphic viruses, for example, do this all the time. So, a heuristic scanner must use many clever methods, rather than simple pattern-matching techniques. Those methods may involve statistical code analysis, partial code interpretation, and even CPU emulation, especially to decrypt self-encrypted viruses: but you would be surprised to know how many real life viruses would be detected by the above six simple heuristics alone! Unfortunately, some non-virus programs would be 'detected' too. 2.3 FALSE ALARMS PROBLEM Strictly speaking, heuristics do not detect viruses. As behaviour blockers, heuristics are looking for virus-like behaviour. Moreover, unlike the behaviour blockers, heuristics can detect not the behaviour itself, but just potential ability to perform this or that action. Indeed, the fact that a program contains a certain piece of code does not necessarily mean that this piece of code is ever executed. The problem of discovering whether this or that code in a program ever gets ontrol is known in the theory of algorithms as the Halting Problem, and is in general unsolvable. This issue was the basis of Fred Cohen's proof of the impossibility of writing a perfect virus detector. For example, some scanners contain pieces of virus code as the signatures for which to scan. Those pieces might correspond to each and every one of the above rules. But they are never executed-the scanner uses them just as its static data. Since, in general, there is no way for heuristics to decide whether these code pieces are ever executed or not, this can (and sometimes does) cause false alarms. A false alarm is when an anti-virus product reports a virus in a program, which in fact does not contain any viruses at all. Different types of false alarms, as well as most widespread causes of false alarms, are described in [Solomon] for example. A false alarm might be even more costly than an actual virus infection. We all keep saying to users:'The main thing to remember when you think you've got a virus-do not panic!' Unfortunately, this does not work well. The average user will panic. And the user panics even more if the anti-virus software is unsure itself whether it is a virus or not. In the case, say, where a scanner definitely detects a virus, the scanner is usually able to detect all infected programs, and to remove the virus. At this point, the panic is usually over;but if it is a false alarm, the scanner will not be able to remove the virus, and most likely will report something like:'This file seems to have a virus',naming just a single file as infected. This is when the user really starts to panic. 'It must be a new virus!'-the user thinks. 'What do I do?!' As a result, the user well might format his/her hard disk, causing himself a far worse disaster than a virus could. Formatting the hard disk is an unnecessary and un-justified act, by the way;even more so as there are many viruses which would survive this act, unlike legitimate software and data stored on the disk. Another problem a false alarm can (and did) cause is negative impact on a software manufacturing company. If an anti-virus software falsely detects a virus in a new software package, the users will stop buying the package and the software developer will suffer not only profit losses, but also a loss of reputation. Even if it was later made known that it was a false alarm, too many people would think:'There is no smoke without fire', and would treat the software with suspicion. This affects the anti-virus vendor as well. There has already been a case where an anti-virus vendor was sued by a software company whose anti-virus protection mistakenly reported a virus. In a corporate environment, when a virus is reported by anti-virus software, whether it is a false alarm or not, the normal flow of operation is interrupted. It takes at best several hours to contact the anti-virus technical support and to ensure it was a false alarm before normal operation is resumed-and, as we all know,time is money. In the case of a big company, time is big money. So, it is not at all surprising that, when asked what level of alarms is acceptable (10 per cent? 1 per cent? 0.1 per cent?), corporate customers answer:'Zero per cent! We do not want any false alarms!' As previously explained, by its very nature heuristic analysis is more prone to false alarms than traditional scanning methods. Indeed, not only viruses but many scanners as well would satisfy the six rules we used as an example: a scanner does look for executable files, opens them, reads some data and even writes something back when removing a virus from a file. Can anything be done to avoid triggering a false positive on a scanner? Let's again turn to the experience of a human anti-virus expert. How does one know that this is a scanner, and not a virus? Well, this is more complicated than the above example of a primitive virus. Still, there are some general rules too. For example, if a program relies heavily on its parameters or involves an extensive dialogue with the user, it is highly unlikely that the program is a virus. Thsi leads us to the idea of negative heuristics;that is, a set of rules which are true for a non-virus program. Then, while analysing a program, our heuristics should estimate the probability of the program to be a virus using both positive heuristics, such as the above six rules, and negative heuristics, typical for non-virus programs and rarely used by real viruses. If a program satisfies all our six positive rules, but also expects some command-line parameters and uses an extensive user dialogue as well, we would not call it a virus. So far so good. Looks like we found a solution to the virus glut problem, right? Not really! Unfortunately, not all virus writers are stupid. Some are also well aware of heuristic analysis, and some of their viruses are written in a way which avoids the most obvious positive heuristics. On the other hand these viruses include otherwise useless pieces of code, the only aim of which is to trigger the most obvious negative heuristics, so that such a virus does not draw the attention of a heuristical analyser. 2.4 VIRUS DETECTION VS. FALSE ALARMS TRADE-OFF Each heuristic scanner developer sooner or later comes to the point when it is necessary to make a decision:'Do I detect more viruses, or do I cause less false alarms?' The best way to decide would be to ask users what do they prefer. Unfortunately, the users' answer is:'I want it all! 100 per cent detection rate and no false alarms!' As mentioned above, this cannot be achieved. So, a virus detection versus false alarms trade-off problem must be decided by the developer. It is very tempting to build the heuristic analyser to detect almost all viruses, despite false alarms. After all, reviewers and evaluators who publish their tests results in magazines read by thousands of users world-wide,are testing just the detection rate. It is much more difficult to run a good false alarms test: there are gigabytes and gigabytes of non-virus software in the world, far more than there are viruses;and it is more difficult to get hold of all this software and to keep it for your tests. 'Not enough disk space' is only one of the problems. So, let's forget false alarms and negative heuristics and call a virus each and every program which happens to satisfy just some of our positive heuristics. This way we shall score top most points in the reviews. But what about the users? They normally run scanners not on a virus collection but on a clean disks. Thus, they won't notice our almost perfect detection rate, but are very likely to notice our not-that-perfect false alarms rate. Tough choice. That's why some developers have at least two modes of operation for their heuristical scanners. The default is the so-called 'norma' or 'low sensitivity' mode, when both positive and negative heuristics are used and a program needs to trigger enough positive heuristics to be reported as a virus. In this mode, a scanner is less prone to false alarms, but its detection rate might be far below what is claimed in its documentation or advertisement. The often-used (in advertising) figures of 'more than 90 per cent' virus detection rate by heuristic analyser refer to the second mode of operation, which is often called 'high sensitivity' or 'paranoid' mode. It is really a paranoid mode: in this mode, negative heuristics are usually discarded, and the scanner reports as a possible virus any program which happens to trigger just one or two positive heuristics. In this mode, a scanner can indeed detect 90 per cent of viruses, but it also produces hundreds and hundreds of false alarms, making the 'paranoid' mode useless and even harmful for real-life everyday use, but still very helpful when it comes to a comparative virus detection test. Some scanners have a special command-line option to switch the paranoid mode on; some others switch to it automatically whenever they detect a virus in the normal low sensitivity mode. Althought the latter approach seems to be a smart one, it takes just a single false alarm out of many thousands of programs on a network file server to produce an avalanche of false virus reports. 2.5 HOW IT ALL WORKS IN PRACTICE: DIFFERENT SCANNERS COMPARED Being myself an anti-virus researcher and working for a leading anti-virus manufacturer, I have developed a heuristic analyser of my own. And of course, I could not resist comparing it to other existing heuristic scanners. We believe the results will be interesting to other people. They underscore what was said about both virus detection and false alarms rates. As the products tested are our competitors, we decided not to publish their names in the test results. So, only FindVirus of Dr Solomon's AntiVirus Toolkit is called by its real name. All the other scanners are referred to with letters: Scanner_A, Scanner_B, Scanner_C and Scanner_D. The latest versions of the scanners available at the time of the test were used. For FindVirus, it was version 7.50-the first version to employ a heuristic analyser. Each scanner tested was run in heuristics-only mode, with normal virus signature scanning disabled. This was achieved by either using a special command-line option, where available, or using a special empty virus signature database in other cases. The test consisted of two parts: virus detection rate and false alarms rate. For the virus detection rate S&S International Plc ONE OF EACH virus collection was used, containing more than 7,000 samples of about 6,500 different known DOS viruses. For the false alarms test the shareware and freeware software collection of SIMTEL20 CD-ROM (fully unpacked), all utilities from different version of MS-DOS, IBM DOS, PC-DOS and other known files were used (current basic S&S fase alarms test set). When measuring false alarms and virus detection rate, all files reported were counted;reported either as 'Infected' or 'Suspicious'. Separate figures for the two categories are given where applicable. In both parts of the test, the products were run in two heuristic sensitivity modes, where applicable: normal or low sensitivity mode, and paranoid or high sensitivity mode. The automatic heuristic sensitivity adjustment was prohibited, where applicable. The results of the tests are as follows: Virus Detection Test Files Files triggered(infected+suspicious) scanned Normal Paranoid FindVirus 7375 5902 (N/A) 80.02% N/A Scanner_D 7375 5743 (0+5743) 77.87% 6182 (0+6182) 83.54% Scanner_C 7375 5692 (0+5692) 77.18% N/A Scanner_A 7375 4250 (N/A) 57.63% 6491 (N/A) 87.74% Scanner_B 7392(*) 3863 (2995+868) 52.38% 6124 (2992+3112)82.68% (*) Scanner_B was tested couple of days later, when 17 more infected files were added to the collection. False Alarms Test Files Files triggered(infected+suspicious) scanned(*) Normal Paranoid FindVirus 13603 0 (N/A) 0.000% N/A Scanner_A 13428 11 (N/A) 0.082% 371 (N/A) 2.746% Scanner_B 13471 17 (0+17) 0.126% 382 (0+382) 2.836% Scanner_D 13840 24 (0+24) 0.173% 254 (0+254) 1.824% Scanner_C 13603 28 (0+28) 0.206% N/A 3 WHY 'OF THE YEAR 2000'? Well, first of all simply because I could not resist the temptation of splitting the name of the paper into three questions and using them as the titles of the main sections of his presentation. I thought it was funny. Maybe I have a weird sense of humour. Who knows... On the other hand, the year 2000 is very attractive by itself. Most people consider it a distinctive milestone in all aspects of human civilisation. This usually happens to the years ending with double zero;still more to the end of a millennium, with its triple zero at the end. The anti-virus arena is not an exclusion. For example, during the EICAR'94 conference there were two panel sessions discussing 'Viruses of the year 2000' and 'Scanners of the year 2000' respectively. The general conclusion made by a panel of well-known anti-virus researcher was that, at the current pace of new virus creation by the year 2000, we well might face dozens (if not hundreds of thousands) of known DOS viruses. As I tried to explain in the second section of this paper (and other authors explained elsewhere [Skulason, Bontchev2], this might be far too much for a current standard scanners' technique, based on known virus signature scanning. More generic anti-virus tools, such as behaviour blockers and integrity checkers, whil being less vulnerable to the growing number of viruses and the rate at which the new viruses appear, can detect a virus only when it is already running on a computer or even only after the virus has run and infected other programs. In many cases, the risk of allowing a virus to run on your computer is just not affordable. Using a heuristic scanner, on the other hand, allows detection of most of new viruses with a regular scanner safe manner: before an infected program is copied to your system and executed. And very much like behaviour blockers and integrity checkers, a heuristic scanner is much more generic than a signature scanner, requires much rare updates, and provides an instant response to a new virus. Those 15-20 per cent of viruses which a heuristic scanner cannot detect could be dealt with using current well-developed signature scanning techniques. This will effective decrease the virus glut problem five fold, at least. Yet another reason for choosing the year 2000 and not, say, 2005 is that I have strong doubts whether the current computer virus situation will survive the year 2000 by more than a couple of years. With new operating systems and environments appearing (Windows NT, Windows'95, etc.) I believe DOS is doomed. So are DOS viruses. So is the modern anti-virus industry. This does not mean viruses are not possible for new operating systems and platforms-they are possible in virtually any operating environment. We are aware of viruses for Windows,OS/2,Apple DOS and even UNIX. But to create viruses for these operating systems, as well as for Windows NT and Windows'95, it requires much more skill, knowledge, effort and time than for the virus-friendly DOS. Moreover, it will be much more difficult for a virus to replicate under these operating systems. They are far more secure than DOS, if it is possible to talk about DOS security at all. Thus, there will be far fewer virus writers and they will be capable of writing far fewer viruses. The viruses will not propagate fast and far enough to represent a major problem. Subsequently, there will be no virus glut problem. Regrettably, there will be a much smaller anti-virus market, and most of today's anti-virus experts will have to find another occupation... But until then, DOS lives, and anti-virus developers still have a lot of work to do! REFERENCES [Bontchev1] Vesselin Bontchev,'Possible Virus Attacks Against Integrity Programs And How To Prevent Them',Proc.2nd Int. Virus Bulleting Conf.,September 1992,pp.131-141. [Skulason] Fridrik Skulason,'The Virus Glut. The Impact Of The Virus Flood',Proc.4th EICAR Conf.,November 1994,pp.143-147. [Bontchev2] Vesselin Bontchev,'Future Trends In Virus Writing',Proc.4th Int. Virus Bulletin Conf.,September 1994,pp.65-81 [Cohen] Fred Cohen,'Computer Viruses-Theory and Experiments',Computer Security: A Global Challenge,Elsevier Science Publishers B. V. (North Holland),1984,pp.143-158. [Solomon] Alan Solomon,'False Alarms',Virus News International, February 1993,pp.50-52. ================================================================== ============= VB95_LT1.TXT 컴컴컴컴컴컴 "Hey, Frisk. Be easy on me, please!" 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 - an IR-member THE EVOLUTION OF POLYMORPHIC VIRUSES Fridrik Skulason Frisk Software International, PO BOX 7180, 127 Reykjavik, Iceland Tel +354 5 617273 Fax +354 5 617274 Email frisk@complex.is The most interesting recent development in the area of polymorphic viruses is how limited their development actually is. This does not mean that there are no new polymorphic viruses, far from it-new ones are appearing constantly, but there is nothing 'new' about them-they are just variations on old and well-known themes. However, looking at the evolution of polymorphic viruses alone only shows half of the picture-it is necessary to consider the development of polymorphic virus detection as well. More complex polymorphic viruses have driven the development of more advanced detection methods, which in turn have resulted in the development of new polymorphic techniques. Before looking at those developments that can be seen, it is perhaps proper to consider some basic issues regarding polymorphic viruses, starting with the question of why they are written. That question is easy to answer-they are written primarily for the purpose of defeating one particular class of anti-virus product-the scanners. Considering virus scanners are the most popular type of anti-virus program, it is not surprising that they are the subject of attacks. At this point it is worth nothing that polymorphic viruses pose no special problems to a different class of anti-virus product, namely integrity checkers. This does not mean that integrity checkers should be considered superior to scanners-after all there is another class of viruses, the 'slow' viruses, which are easily detected by scanners, but which are a real problem for integrity checkers. Fortunately, polymorphic slow viruses are not common at the moment. As a side note 'slow polymorphic' viruses also exist, and should not be confused with 'polymorphic slow' viruses. This category will be described at the end of this paper, together with some other 'nasty' tricks. Considering how virus scanners work, a virus author can in principle attack them in two different ways-either by infecting an object the scanner does not scan, or by making the detection of the virus so difficult that the scanner, or rather the producers of the scanner may not be able to cope with it. Polymorphic viruses attempt to make detection difficult-either too time consuming to be feasible, or beyond the technical capabilities of the anti-virus authors. The success of virus authors depends not only on their programming skills, but also on the detection techniques used. Before describing the current techniques, however, a brief classification of polymorphic viruses is in order. Polymorphic viruses are currently divided into three groups: 1) Encrypted, with variable decryptors. This is the largest and currently the most important group. Several methods to implement the variability are discussed below, but most of them should be familiar to readers of this paper. 2) 'Block-swapping' Viruses. Only a handful of viruses currently belong to this group, but they demonstrate that a polymorphic virus does not have to be encrypted. These viruses are composed of multiple blocks of code, theoretically as small as two instructions, that can be swapped around in any order, making the use of normal search strings nearly impossible. 3) Self-modifying viruses using instruction replacement techniques. This is where the virus may modify itself by replacing one or more instructions in itself with one or more functionally equivalent instruction when it replicates. So far this category is only a theoretical possibility, as no viruses have yet been written that use this technique. It is possible that some such viruses will appear in the future, perhaps only to written to demonstrate that it can indeed be done. Considering that the viruses that currently fall into the second group are easy to detect using ordinary search strings, and that the third group is non-existent, the only polymorphic viruses currently of interest are encrypted ones. For that reason the term 'polymorphic viruses' should, in the rest of this paper, really be understood to mean only viruses of the first group, that is, encrypted with variable decryptors. So, how are those viruses detected? Basically the detection methods fall into two classes-those that detect and identify only the decryptor and those that look 'below' the decryptor, detecting the actual virus. This is not a strict 'either-or' classification- a scanner may analyse the decryption loop to determine that it might have been generated by a particular virus, before spending time decrypting the code. DECRYPTION-LOOP DETECTORS There are several different methods that have been used to detect and identify decryption loops-which used to be the standard way of detecting polymorphic viruses-but there are several significant problems with these methods. The most common methods are described later, but if they are only used as the first step, and the virus then properly decrypted some of the following problems disappear: - Virus-specific. Basically, the detection of one polymorphic virus does not make it any easier to detect another. - More likely to cause false positives. As we get more and more polymorphic viruses, capable of producing an ever-increasing variety of decryptors, the chances of generating a false positive increase, as some innocent code may happen to look just like a possible decryptor. - Identification is difficult. Many polymorphic viruses will generate similar decryptors, and it is entirely possible that a scanner will mis-identify a decryptor generated by one polymorphic virus as having been produced by another, unrelated virus. Also, in the case of variants of the same polymorphic virus, it may be possible to determine the family, but not the variant. - No disinfection. Virus disinfection requires the retrieval of a few critical bytes from the original host file that are stored usually within the encrypted part of polymorphic viruses. This means that virus- specific disinfection is generally not possible, at it would require decrypting the virus. On the positive side, detection of a particular decryptor may be quite easy to add, althought that depends on the design of the scanner and the complexity of the virus. The decryption techniques are old, and several anti-virus producers have abandoned them, in favour of more advanced methods. The most common detection methods in this group are: - Search strings containing simple wildcards - Search strings containing variable-length wildcards - Multiple search strings - Instruction usage recognition - Statistical analysis - Various algorithmic detection methods SEARCHING STRING CONTAINING SIMPLE WILDCARDS The limitation of this method are obvious, as it can only handle a few 'not very polymorphic' viruses, which are sometimes called 'oligomorphic'. They may for example make use of a simple decryption loop, with a single variable instruction. The last variable polymorphic virus uses two different instruction, NEG and NOT, which differ by only one bit. Defeating this detection method is easy: just insert a random number of 'junk' instructions at variable places in the code. 'Junk' does not have to mean 'invalid', but rather any instruction that can be inserted in the decryption loop without having an effect. Typical examples include NOP, JMP $+2, MOV AX,AX and other similar 'do nothing' instructions. SEARCH STRINGS CONTAINING VARIABLE-LENGTH WILDCARDS This method takes care of decryptors that contain those junk instructions. However, there are two problems with this approach. Some scanners cannot use this method as their design does not allow variable-length wildcards, but that really does not matter, as the technique is very easy to defeat: just make the decryptor slightly more variable so that no single search string, even using a variable-length wildcard will match all instances of the decryptor. This can be done in several ways. - Changing register usage: For example the DI register might be used for indexing, instead of SI, or the decryption key might be stored in BX instead of AX - Changing the order of instructions: If the order of instructions does not matter, they can be freely swapped around. - Changing the encryption methods: Instead of using XOR, the virus author could just as well use ADD or SUB. MULTIPLE SEARCH STRINGS This is generally considered an obsolete technique, but many anti-virus producers used it back an 1990 when the Whale virus appeared. This virus could be reliably detected with a fairly large set of simple search strings. Today, however, most of them would probably use a different method. This detection method can easily be defeated by increasing the variability of the decryptor past the point where the number of search string required becomes unreasonably large. There are other cases where the multiple search string technique has been used. One anti-virus company had access to the actual samples of a particular polymorphic virus that were to be used in a comparative product review. Rather than admitting that they were not able to detect the virus, they seem to have added a few search string to detect those particular samples-and they did indeed score 100% in that test, although later examination revealed that they only detected 5% of the virus in question. INSTRUCTION USAGE RECOGNITION This method was developed to deal with Dark Avenger's Mutation engine. It basically involved assuming initially that all files are infected, then tracing through the decryptor, one instruction at a time. If an instruction is found that could not have been generated by a particular virus as a part of the decryptor, then the virus is not infected by that virus. If one reaches the end of the decryptor, still assuming that the file is infected, it is reported as such. There are two major ways to attack this technique, but the more obvious is to increase the number of possible instructions used in the decryptor. If a virus used every possible instruction in a decryptor, it simply could not be detected with this method without modifying it. The second method is more subtle, but it involves making it more difficult to determine when the end of the decryption loop has been reached. STATISTICAL ANALYSIS This method is generally not used, due to the unacceptably large risk of false positives. It basically involves statistical analysis of the number of certain in the decryptor. It works best with viruses that generate large decryptors, that uwe few and uncommon 'do-nothing' instructions. Other algorithmic detection methods are possible, and are frequently used. Sometimes they are inly used to quickly eliminate the possibility of a particular file being infected with a particular virus, for example: IF The file is an EXE-structure file AND The initial CS:IP value equals 0000:0000 THEN The file is not infected by Virus-X In other cases the algorithm provides detection, instead of negative detection: IF The file is a COM-structure file AND It is at least 5623 bytes long AND It starts with a JMP FAR to a location at least 1623 from the end of the file AND The first 10 instructions contain at least 5 instructions from the following set {AAD,NOP,CLI,CLD,STC} AND Within the first 100 bytes from the entry point there is an XOR [SI/DI/BX],AX instruction AND Within the first 200 bytes from the entry point there is a branch instruction that transfers control back to the XOR instruction described above THEN The file is infected with Virus-Y It should be obvious from this example that the rules can get complex, perhaps unreasonably complex, and obviously require significant work to implement. Also, in some instances it is just not possible to get a sufficient number of rules like this to ensure accurate detection, not even considering the rules the virus itself may use to determine if a file has already been infected as the number of false positives would be too high. At this point it is very important to bear in mind that, while false positives are a very serious problem for the anti-virus author, they do not matter at all to the virus author. A false positive just means that the virus will not infect one particular file it might otherwise have infected... so what-after all, it has plenty of other files to infect. Having looked at the detectors that only detect the decryption loop, we must look at the more advanced detectors, which detect the actual virus, instead of just the encryption loop. Compared to the decryptor-detecting methods, the following differences are obvious: - More generic. These methods require significantly more initial work, but the extra effort required to add detection of a new polymorphic virus is far less than with some of the other methods described above. - Less chances of false positives. Having decrypted the virus, it should be possible to reduce the chances of false positives almost down to zero, as the entire virus body should be available. - Identification is easy. When the virus has been decrypted, identification is no more difficult than in the case of non-encrypted viruses. - Easy disinfection. The sample applies to disinfection-it should not be any more difficult than if the virus had not been encrypted to begin with. There are two such techniques which have been used to detect polymorphic viruses. 'X-ray' Generic decryption The X-raying technique was probably only used in two products, both of which have mostly abandoned it by now. It basically involved assuming that a particular block of code had been encrypted with an unknown algorithm, and then deriving the encryption method and the encryption keys from a comparison between the original and encrypted code. As this sounds somewhat complicated, an example is in order: Assume that manual decryption of one virus sample reveals that a particular block of code should contain the following byte sequence: B8 63 25 B9 88 01 CD 21 The corresponding encrypted block of code in a different sample looks like this: 18 C4 8B 0C 34 C2 07 F0 Is there any way this sequence could have been obtained from the first one by applying one or two primitive, reversible operations like for example: XOR with a constant ADD/SUB with a constant ROL/ROR a fixed number of bytes Yes, because XORing the two sequences together generates the sequence: A0 A7 AE B5 BC C3 CA D1 Calculating the differences between the bytes in that sequence give the following result: 07 07 07 07 07 07 07 07 which shows that the original sequence, and (presumably) the entire virus body can be obtained by XORing each byte with a key, and then adding the constant value of 7 to that key, before applying it to the next byte. Using this method, it may be possible to deduce the operation of the decryptor, without looking at it at all. There is a variant of the X-ray method which has been developed by Eugene Kaspersky, which works in a different way, but produces the same result. The reason 'X-raying' has mostly been abandoned is that it can easily be defeated, for example by using an operation the X-ray procedure may not be able to handle, by using three or more operations on each decrypted byte or by using multiple layer of encryption. The last method to be developed does not suffer from that limitation, and can handle decryptors of almost any complexity. It basically involves using the decryptor of the virus to decrypt the virus body, either by emulating it, or by single-stepping through it in a controlled way so the virus does not gain control of the execution. Unfortunately, there are several problem with this method: - Which processor should be emulated? It is perfectly possible to write a virus that only works properly on one particular processor, such as a Cyrix 486 SLC, but the decryptor will just generate garbage if executed on any other processor. An intelligent emulator may be able to deal with this, but not the 'single-stepping' method. - Single-stepping is dangerous-what if the virus author is able to exploit some obscure loophole, which allows the virus to gain control. In this case, just scanning an infected file would result in the virus activating, spreading and possible causing damage, which is totally unacceptable. It should be noted that a very similar situation has actually happened once-however the details will not be discussed here. - Emulation is slow-if the user has to wait a long time while the scanner emulates harmless programs, the scanner will probably be discarded, and obviously a scanner that is not used will not find any viruses. - If the virus decryptor goes into an infinite loop and hangs when run, the generic decryptor might do so too. This should not happen, but one product has (or used to have) this problem. - How does the generic decryptor determine when to stop decrypting code, and not waste unacceptable amount of time attempting to decrypt normal, innocent programs? - What if the decryptor includes code intended to determine if it is being emulated or run normally, such as a polymorphic timing loop, and only encrypts itself if it is able to determine that it is running normally? - What if the decryptor is damaged, so that the virus does not execute normally? A scanner that only attempted to detect the decryptor might be able to do so, but a more advanced scanner that attempts to exploit the decryptor will not find anything. This is for example the case with one of the SMEG viruses-it will occasionally generate corrupted samples. They will not spread further, but should a scanner be expected to find them or not? Finally, it should be noted that there are other ways to make polymorphic viruses difficult than just attacking the various detection techniques as described above. 'Slow polymorphic' viruses are one such method. They are polymorphic, but all samples generated on the same machine will seem to have the same decryptor. This may mislead an anti-virus producer into attempting to detect the virus with a single search string, as if it was just a simple encrypted but not polymorphic virus. However, virus samples generated on a different machine, or on a different day of the week, or even under a different phase of the moon will have different encryptors, revealing that the virus is indeed polymorphic. Another recent phenomena has been the development of more 'normal-looking' polymorphic code. Placing a large number of 'do-nothing' instructions in the decryptor may be the easiest way to make the code look random, but it also makes it look really suspicious to an 'intelligent' scanner, and worthy of detailed study. If the code looks 'normal', for example by using harmless-looking 'get dos-version number' function calls, it becomes more difficult to find. So, where does this leave us? Currently anti-virus producers are able to keep up with the virus developers, but unfortunately the best methods available have certain problems-the one most obvious to users is that scanners are becoming slower. There is no indication that this will get any better, but on the other hand there are no signs that virus authors will be able to come up with new polymorphic techniques which require the development of a new generation of detectors. ================================================================== ============= VB95_LT3.TXT 컴컴컴컴컴컴 CATCHING THE VIRUS WRITERS Jim Bates - Computer Forensics Limited - U.K. JB> = Jim Bates XX> = Someone ;). INTRODUCTION JB> During my work in analysing virus code I have been privileged to be asked to help the Police on a number of occasions and some of my experiences and observations will be described here. XX> I shouldn't really see it as a priviledge to work for the police to bust virus writers or supply them with information they're not worthy of having. If some fucking computer-crime-investigation-agency by any chance gave me such a request because I analyzed virus code, and knew a lot about the virus-community I would've turn them down. Of course, that would probably be impossible looking at my situation today (they don't know who I am), but even if I'd been busted and if they'd been blackmailing mewith all kind of things I still wouldn't cooperate with them, and they would get no information whatsoever from me. It's unmoral to turn friends in, no matter what. Yeah, of course Jim wouldn't see viruswriters as friends, but even if he sees us as enemies, it's still very low. JB> In this presentation I shall try to highlight the problems that computer viruses have caused and how the authorities in the U.K. are dealing with them. I will describe some virus writers and the environment that they work in to produce their programs. I will introduce some of the reasons they have given for writing viruses and in some cases why they feel aggrieved at being "persecuted" by the authorities. Without going into too much detail that might help the really malicious virus writers, I will present details of some of the cases I have been involved in and how the Police tackled the problem of locating and identifying those responsible for particular virus incidents. XX> I don't think Jims little hints of being *really* malicious would help us very much anyways. I mean creativity is everything :) when it comes to being a pain in the ass. If you use your creativity in (general terms) negative way, that's a good start :). JB> WHY DO WE NEED TO CATCH VIRUS WRITERS? XX> It's simple, we don't! Maybe Jim got a perverted appeal to catch one, else there's no reason. Why would they waste police resources to catch a harmless individual who writes computer-programs? I mean, even a damn dangerous writer won't cause the society that very much harm. Go bust some rapists, murderer or some other kind of *real* criminal! JB> There are several reasons why we should want to catch these people-the main reason is quite simply to bring them to book for the loss and disruption that they cause. Another reason is that viruses are a non-productive threat which diverts genuine creative effort from helping to fuel to progress of computing in general. If we accept this then it becomes obvious that we should use any means at our disposal to stop people from writing them and distributing them. It should also be remembered that some at least of the virus writers display an obvious talent for programming and it is a sad lass to the industry that such skill is wasted. XX> Virus writing is for most writer's more a question about attitude than programming. Those people [us] want to write viruses, rather than useful software. If we look at it that way, there is no skill wasted.. And besides, technical minded people are making for example bombs, why wouldn't you rather stop them? It's a waste that highly skilled persons (Stop all Nuclear testing!) -rb are making for example nuclear bombs. JB> There is still a public perception that viruses are just a nuisance and only cause minor annoyance to large companies-"... who can easily afford it." This is just not true-there are documented instances where ordinary people have suffered serious loss and even life-threatening situations as a direct result of virus activity. XX> Well, viruses aren't disciminative, they hit everyone they can. If this means a large company with a lot of cash or a poor XT owner, well, that doesn't really matter for the virus (and not for virus-programmers either.. ). Oh well, some viruswriter's do discriminate by the way! Manzon only hit 80386 computers and above! JB> So, another vital reason for catching them is to deter others. XX> If you catch one swedish viruswriter, I sure as hell will write a lot more destructive code and blame the one catching him for giving me motivation. Rebellion? Perhaps. Right? Of course. Today you can see a few viruses dedicated to busted viruswriter's. Predator#2 for example was dedicated to the ARCV, hehe, just too bad some IR-members fell victim to it :-). (* Priest rox0rs! *) JB> VIRUSES BREAK THE LAW In the U.K. it is illegal to access or modify the contents of a computer without proper authority. It can therefore be argued that a computer virus, since it does not ask for permission to replicate, breaks the law simply by spreading. XX> Well, press lawsuits against the viruses then :-). However, it's not forbidden to create viruses in most countries and therefor he can't say that viruses break the law.. And besides, Stormbringer's GoodVirus did ask for permission to replicate! How to forbid that virus? Asshole! JB> If a virus is executed without the knowledge or permission of the computer owner and the author of that virus can be identified, he or she can be charged under Section 3 of the Computer Misuse Act (1990). This offence carries a maximum sentence of five years in prison and it is one of the few laws where the offence can be committed outside the U.K. XX> Five years? That's fucking overdoing it! To get five years in Sweden, well, even if you kill five persons, it's not sure you'll get over five years prison! Five years in prison!#!�! Thing about it.. Five years for doing *nothing* wrong! The law is *really* screwed up! BIGTIME! JB> Thus it is quite possible for a virus writer to break the law in the U.K. without ever having set foot in the country. Extradition treaties will no doubt be updated by the time computers become obsolete. XX> Let's assume that Manzon infected some people in the U.K. (which it did), then who are to be held responsible for that? Red-A for writing it? An IR-member for deliberate making that Petra-remover which he infected, Btk for distributing it to a few swedish boards, or none of us? Well, I don't really care because if they'd try to press lawsuits against me (or anyone in IR for that matter), they would hardly succed in doing that. We couldn't know that the U.K. would become infected! JB> VIRUSES CAUSE LOSS, DISRUPTION AND DAMAGE By far the largest loss and disruption suffered by the victims of a virus outbreak is that arising from downtime while installations are checked and disinfected. A recent outbreak of the Pathogen virus in a college in England affected 4 file servers and 90 work stations. The college had to be closed for four days while the systems were checked and cleared. The commercial loss of such a shutdown can be imagined. Official complaints to the Police concerning outbreaks of the Pathogen and Queeg viruses (produced at the trial of the virus author) listed estimated losses approaching 500,000 pounds sterling. XX> I guess that's pretty much the same story as when a new variant of Digital Death which TU fixed closed the schools' computer-classes (and more) at a school for over one week. If that cost 500.000 pounds.. Hahahha! Blame their weak security, not TU! JB> Two other incidents will server to show just how serious virus outbreaks can be: 1) An old established small family bakery in south east England was hit by the Casino virus in January. This resulted in the partial loss of both their stock control and their accounts data. Two months later they were hit again, this time by the Michelangelo virus, with the total loss of all data. Backup and protection procedures implemented by a so-called expert after the first incident proved ineffective and very little data was recoverable. The company, employing nine people, went into receivership bankrupting the owner. He lost his business and his home. When I spoke to him, his wife was distraught-not knowing how she was going to care for her two little girls. XX> A very sad story, indeed. I guess they hate computer viruses now, but do however think they should hate the 'expert' rather than the virus writer. The wanna-be expert are to be held responsible for this. JB> 2) A local medical practice in the English Midlands maintained a computer system containing patient records. The system operated by printing a copy of the patient's record in the surgery when the patient arrived in the reception area. While one of the Doctors was on holiday a locum undertook his workload and prescribed a small dose of Penicillin for a regular patient. The computer system was infected with the Nomenklatura virus and some of the records had been corrupted with the result that this particular patient's record was shown incorrectly and did not indicate that the patient was strongly allergic to the drug. The database access system did not signal any errors when displaying or printing records and the locum was unfamiliar with the patient's allergy. These two facts, coupled with the effects of the computer virus meant that the patient who received Penicillin suffered a nasty and uncomfortable reaction. It does not take a long stretch of imagination to the life-threatening potential of such an incident. XX> Jim just listed two very sad stories about what viruses _could_ do. However, if a person died due to a virus, that would hardly be a deliberate attack to kill another person with his creation [the virus]. There is easier things to kill a man than with a virus. Accidents happends, you know. No further comments, you can be run over by a reindeer as well :-). Just ask Anna Jones. . . JB> VIRUSES ARE UNETHICAL Quite apart from the damage and nuisance that viruses cause;and the fact that many countries have now criminalised them-viruses are just not ethical. It is thoroughly mean and nasty to write computer programs designed to deliberately damage data. Every virus writer that I have met has admitted to the cowardly and craven nature of their activities. It somehow reflects upon all of us that human nature can sink so low as to transfer some of its own baser instincts for destruction into an environment which is arguably the most thrilling development since the invention of the wheel. XX> I don't think writing viruses is the act of a coward (We want some chicken tonight!). U.K. viruswriter does risk a lot of things by writing viruses. It doesn't take much guts to do it, but it takes brains to stay away from the NSY. And besides, most viruses aren't designed to deliberately damage data! They just add their code into host-files and replicate without being noticed. A few viruses does however do deliberately damage, but that's quite a few, so ah well :-). JB> There are those who will argue passionately for the freedom to write what they like on their own equipment and I for one am not seeking to prevent them. However, with the ever wider use of computers, the skill to make them do our bidding brings with it a pressing responsibility. There are arguments attempting to liken computer viruses to primitive life-forms. Some people actually believe this and do not respond favourably when it is pointed out to them that similar arguments have been advanced and defeated for crystalline replication or even the growth and spread of fire. In most cases however, these arguments are used simply as a retrospective excuse. XX> Sorta agreed. JB> THE FIELD OF PLAY When the virus problem first arrived and began to grow, several far-sighted individuals saw that some form of defence was going to become absolutely essential if the well-being of computing was to survive. These people could be divided into two groups depending on their original motivation-some rushed to the defence of computing just because it was the right thing to do;other simply saw an opportunity to make lots of money. Sadly, as the problem has grown over the years, the latter group seems to have grown at the expense of the former. We now seem to have a symbiotic relationship between virus writers and anti-virus companies-each feeds on the efforts of the other. It is interesting to speculate that if suddenly all virus writers were to stop their activities, some very large companies might suffer serious financial setbacks. The virus writer (apparently) make no money from their efforts, while the anti-virus companies trade in a market worth many millions each year. There have even been suggestions that some viruses originate from the anti-virus companies themselves. I should add that to date as far as I am aware, none of these suggestions have been substantiated. XX> I don't think AVers writes viruses themself, but it would though be quite cool to see viruses written by them. JB> So we have a situation where virus writers-who often take an anti- establishment stance-are actually feeding the coffers of the very people who they claim to despise. Add to this a few despicable individuals who-in the name of freedom of information-choose to collect and make publicly available who collections of virus code containing all the intricate technical details, and you have a thoroughly confused and tangled industry in which the opportunities for intrigue and deception are rife. In the midst of this shambles is the computer user-caught in the crossfire so to speak. The typical user neither needs nor desires to know how computers work-it is sufficient for him that they DO work. It is understandable therefore that when information built by their own efforts is destroyed by a deliberate indiscriminate act of malice, they should be saddened and angered. Bearing all this in mind, the authorities are right to legislate against the distribution of virus code and we should all try to help in the fight to bring them to justice. XX> Well, I don't expect every computer-user worldwide to know how to protect themself against viruses -- that is quite impossible. Not even me, can gurantee my computer to be total clean from viruses. However, let's assume I got my HD totally fucked up by a virus of a writer who lives no more than 200 meters from me.. Well, I wouldn't like to see him in jail anyways! Why would I bring him to justice? He didn't break the law by writing it, and what if he didn't distribute it himself? Hey presto! He cannot be held responsible for an accident. Shit happends, just too bad it happend too me :). JB> WHO ARE THE VIRUS WRITERS? XX> We are, of course :-). JB> My own observations, confirmed by other people similarly engaged in trying to track them down, are that virus writers are generally 'loners'. XX> ARCV was hardely loners, they were a group of technical-interested youth. JB> Most right thinking people reject the idea of indiscriminately damaging something, especially when it does not belong to you. For this reason a virus writer cannot discuss his hobby with friends or acquaintances. True he may be able to establish contact with like-minded people across computer communication links but even there he must maintain a protective anonymity and so he tends to be a loner. XX> Ah well, when I meet my IRL friends we won't discuss viruses, but some of them know about my interest in viruses and some even write viruses. but it can happen that we discuss computers, but mainly we spend our time together talking about parties and babes.. Confusing chats I tell you! :). JB> Working alone on something as technically challenging as computer virus code takes an enormous amount of time and concentration. The dedicated virus writer may therefore become obsessive and shun any other activities which may take him away from his obsession. This lack of social interaction makes them withdrawn and uncommunicative as well as leading to a general tendency to social inadequacy. XX> Hahahah! Well, I have met quite a few viruswriter's, and I would say that we are no more 'unnormal' than people you meet when you're out getting drunk.. I live a perfectly healthy social life, and most of my fellow writers do as well. The only thing that makes us *really* different to the average blonde-bitch is our IQ, our dicks, our knowledge in computers and low-level assembly language :-). (Well, not total true, but compared to most people, we ain't much different.. ). Jim Bates.. Come and visit me and go get some facts before writing up this typical bogus-shit. AV-people spend *way-more* time in front of their computer than most viruswriters does, and hey.. I've already written a lot of things already about this very topic, so just read that and thrust me on this one: You're wrong! I'm right! (hehe XX can't stop thinking about his dirty fantasies :P) -rb JB> The reasons they become attracted to virus writing in the first place seems to vary widely but are usually preceded by a technical curiosity and in some cases a fascination with the spurious argument that viruses may mimic a simple life-form. As they become more involved, they tend to lose touch with the real world and live almost entirely within the electronic environment that they work in a cyberspace that may seem more real to them than the normal humdrum of human existence. XX> Well, it's easy to get too involved in the VX-underground because it's a very fun place to kill some of your time (Boy, you should not kill time, pressure it, Sieze the day! Uerm, well, could you give me a dollar so I can get loaded??) in. However, once you spend time in front of IRC rather than seeing IRL-friends, getting drunk, or just fucking you girlfriend(s), think twice what you're doing :-)... Just combine it, and don't take the scene too damn serious :-) (words of wizdom, could you please email the money). JB> The inclusion of damaging payloads and intricate trigger mechanisms become just another technical exercise where they can demonstrate their superiority over the rest of us. XX> Not agreed :-). Payloads are trivial to write.. It's no technical challenge in writing a HD-trasher.. Every programmer worth his salt can make one :-). JB> Depending upon the degree of their social degeneration, their activies can be described as ranging from irresponsible and stupid to malicious and hateful. I have not yet come across a virus writer who simply wrote and did not distribute his programs. Distribution in the sense meaning loosing them into the computing community in a way that would ensure their survival and growth. XX> Well, I've written viruses totally motivated by hate (Xxxxx.XXXX), and well that was just another way to express myself.. If I hadn't written it, I sure as hell would have smashed a lot of things just to calm down. Is that better? Of course not! But that's exactly what other people are doing.. Smashing things, beating up to them totally unknown persons, raping girls, etc. Heck, it's a violent sociely we're living in, and viruswriting just isn't that bad.. JB> The intensive and technical nature of virus writing is such that they will usually work from home. A small proportion being their activities within open computing environments at school or college but the large majority either start at or graduate to, a semi-secret existence at home. When they are asked to give their own reasons for writing viruses they often have difficulty. XX> Let's talk about a person we all know :). All he wanted was to release an e-zine, and that it turned out to be a VX-zine wasn't the important thing. It just turned out that way becuase another computer guy he had got in contact with had a keen interest in viruses. Well, that's a reason. Curiousity another. JB> Remember that most of those that I have met have been under investigation precisely because their programs have caused damage at large. In these cases they are aware that their activites have had serious effects and there are probably serious consequences for them to face. They may attempt to justify themselves by suggestion that they were "only testing" or "researching viruses". One incredible argument went as follows:- The virus writer was asked why he wrote and distributed viruses-he replied that he "wanted to be a virus researcher-but no one would give me any so I thought I'd write my own." His interrogator observed, "it's a good job you weren't interested in brain surgery." XX> Well, then who's fault is this? The AV-people I tell you! For example, take the example why TridenT was being formed? (For those who doesn't know shits about TridenT, read the interview's in Insane Reality #4, or in Mark Ludwig's book -The Virus Creation Labs-). Wasn't it because John Tardy was denied source-codes from (among many) Frans Veldman - author of TBAV? JB> The latest reasoning, from the Black Baron, was that he used the viruses as a platform to test and advertise his polymorphic engine. He argued that the SMEG polymorphic code had potentially useful capabilities in copy protection. This highlights another of the most common arguments-that virus code might somehow be beneficial. In nine years of work in this field I have yet to see a demonstrably beneficial use for virus code but still they think that can be a justification for indiscriminate destruction. XX> Well, hard-ass encryption-utilities can be used in useful ways. If you don't like other people to look at or steal your code, encrypt it so the people who are too lazy to write their own code cannot decrypt it. So, imo The black Baron was correct, his program just wasn't any hard to break (one encryption manually, not making a program that breaks all encryptions automatically). JB> Whether you classify them as thoughtless or malicious, these people are criminals and must be caught and punished. The damage they are doing is incalculable. XX> Hey, I'm a unpunished writer of viruses, making me into a non-criminal! I never broke any swedish-law, so come kiss my arse! JB> SO HOW DO WE FIND THEM? Let us look at a possible sequence of events which might lead to catching a virus writer. XX> It ain't hard :). ("Q: How can you tell there is an old man in the dark?) Write a few groundbreaking viruses, go on #virus show 'em up and ask for membership in Phalcon/Skism or VLAD. Scene-secrets are traded quite open between groups and soon or later, you've figured out enough to caught as good as every group-affiliated (and some independent) writers. But what's stopping you is to write those damn viruses.. Asshole! If you want something done, put your crappy ethics aside, and do something for once.. Words won't help you know! :). Whoops! Just gave him *the hint* of how to catch us.. So, beware dudes! Hehe. JB> First someone suffers loss or damage of a sufficient magnitude to persuade them to make an official complaint. The complaint will need to contain details of the virus-including a sample-and details and costs of the damage or disruption suffered. This can be a problem since the first objectie of the victim is to destroy the virus and resume normal operations as soon as possible. In the Black Baron case I analysed in excess of 57 virus samples from various complainants. The most from any site was 9 samples but the majority sent only one or two. The presence of a "generation number" within the virus code made it possible to identify which samples had actually introduced the virus in some instances but a greater number of samples would have made the job of tracing the infection so much easier. It is this tracing process which is so difficult. Victims are rarely able to pinpoint exactly where the infection came from- particularly is the virus is designed to infect slowly and quietly. Once an origin has been established, enquiries can be made to try to trace further back along the chain. A major problem for virus writers is how to get their code into the computing community. Some may upload infected files to Bulletin Boards or Internet sites. Others may try physically passing infected programs around. Whichever method is chosen it is this initial distribution which is the most dangerous area for the virus writer. In the Black Baron case the Police followed up complaints received and were able to determine that initially infected software had been downloaded from various Bulletin Boards. With help from the BBS operators and the telephone company, activity logs and telephone billing records revealed the source of the original uploads. There were other considerations which need not be discussed here but the net result was that the Police knew exactly when and where the infected programs had come from. XX> That was quite ignorant from TBB. Ignorance ain't no good when being in this kinda business. Try tracing the origin of Petra-Rm.Zip.. (Silence.. ). JB> A number of complainants asked for complete confidentiality and this was respected because there were plenty of others willing to stand up in court. However, users must accept that if they want justics they must be prepared to make their complaints public. Once the originator of the infections has been detected and identified, the Police enquiries can focus in earnest and will eventually result in a search and seizure operation. A search warrant is issued and the suspect's home (and possible his workplace) will be visited and all computing equipment seized for investigation. The suspect is interviewed and questioned about the alleged offences and his equipment is examined in minute detail for any evidence linking him to viruses. In one case, the suspect became aware of Police interest and took measures to thoroughly disinfect his computers and his his virus source code. He also sent his machine for safe keeping to a friend, thinking that this left him safe. When the Police did arrive, no computing equipment of any kind was found and he denied any involvement in computing. Sine the Police were well aware of his recent activities-and could prove them-this denial simply confirmed that he had something to hide. The Police knew about the friend and had visited him too! Several computers were seized and the hidden source code was rapidly found and identified. Even without the source code charges would still have been brought, but finding it made the case much stronger. XX> Hint: Encrypt your HD and put all your floppy-discs in the microwave-oven if you are aware of the police are watching you! :). JB> HOW YOU CAN HELP XX> Hey! Send your name in to the NSY :-). .. . That's not too hard! JB> For the best chance of conviction, a series of events must be shown to link the virus writer with the damage. You as a potential victim should bear this in mind so that if you do get hit you can provide a solid start for the Police to investigate the chain of events. What new program or disk brought the infection in? Where did it come from-and when? What damage/disruption did it cause and how much did it cost you as a result? In the U.K. arrangements can be made to take detailed image copies of infected machines so that as much evidence as possible is preserved with the minimum of disruption to you. You can then proceed with the disinfection process and a rapid resumption of normal working. If you operate a Bulletin Board or Internet site, do you log incoming software and callers? Could you provide the evidence that the Police need? The quicker you can provide this information, especially in the case of hitherto unknown viruses, the better the chance of catching the perpetrator. If you are a virus writer-remember that you are not completely anonymous. There are big risks and when you are caught there are heavy consequences. As interesting as you find virus code-are you prepared to go to prison for it? XX> I know that I'm not completely anonymous. But since I am doing nothing wrong, (in the writing itself), I won't care. If Jim Bates wanna try something about (C)opyright-violations, he just gotta figure out who wrote this text :) and decided to include it.. Bah. Good luck asshole, you'll need it.. - (C) 1995 Someone, Anyone, Everyone & Noone INC.