Well here it is April already. Halfway through April to be exact and I am
behind the power curve. This is being released later than I had hope it would
be due to exams in college. Ah yes, the sacrifices for a better education. :-)
This issue has some new articles and writers that I hope you will enjoy. Mikko Hyppönen's second and final part to his Retroviruses paper is just as informative as the first part was. Rob Slade addresses a subject of great debate and we would like to hear from you folks on Virus Ethics. What are your views on the subject? Read Rob Slade's Guide to Computer Viruses? Well I did and I tell you all about it in this issue.
We "Spotlight" EXEBUG in this issue. A nasty little critter to say the least. If you are an Integrity Master user or an F-Prot user you won't want to miss the pointers on using them against EXEBUG.
Hope you enjoy the issue. Please keep those messages coming in on what you think of The Scanner. With the input I can keep up with what you folks want to see in it.
Keep those AV programs busy !!!!!
"Computer ethics" has been an ongoing study in the technical world. On the one
hand is the study of the ethical, moral, or proper use of computers. On the
other, is the study of computer crime and vandalism. Lately, I have noted a
rather desperate interest in courses or training in computer ethics, as well as
an increase in the frequency and depth of discussions regarding the ethics of
virus writing. I would like to address this latter topic, specifically.
One problem with current discussions and literature regarding the ethics of virus writing and distribution is the lack of dialogue between two opposing camps. This paper is not intended to present any final answer, nor to add to the literature in the field, but to open the field for comment. My purpose in writing this is to provide an initial overview and to elicit feedback from any and all concerned with the topic.
For those of traditional moral stance, the current situation is discouraging.
Peter Denning's Computers Under Attack has a very thorough survey of the field, but it provides little in the way of answers or hope. Deborah Johnson's work Computer Ethics is pre-eminent in the field, but serves only to clarify the problem. Sarah Gordon's interviews with computer students show responses typical of almost all such studies. The base attitude appears to be, "If I find it interesting, and I can do it, why do you say I shouldn't?"
The proponents of security-breaking activities often question the traditional ethical position by asking, "Where's the harm?" This query is directly relevant to discussions of the morality of virus writing.
I should begin by defining two generally opposed groups in this area. First is the "antivirus", or "AV", research community. Many, though not all, of the members of this group would be involved in producing antiviral software. All would study viral programs with a view to eliminating viral programs in the normal computing environment. They take a rather paranoid, and almost obsessive, position with regard to the sharing and distribution of viral code. (They would rejoin this last by pointing out that it isn't paranoia if someone is really out to get you.)
The AV community is not really opposed to the writing of viral programs. It is seen as a trivial, and therefore pointless, exercise; but not necessarily evil, in itself. The communication of viral program code is also a normal professional and academic activity, as long as it is limited, done for a stated purpose, and the recipients are known. It is the unregulated exchange of virus code and source, providing open access to anyone with a computer and a modem, that is upsetting. The opposing group is therefore described as the virus exchange community, or "vx" for short. (This designation was first used by Sarah Gordon.) For the purposes of this paper, therefore, references to "virus writing", "virus exchange" or "vx" will mean the uncontrolled or unregulated exchange or provision of access to virus source and object code.
(This does not necessarily mean deliberate distribution of infected programs by such means as infecting a legitimate program and then posting it, without warning, to a bulletin board system. "Trojanizing" of normal software or malicious invasion of systems is certainly happening in some areas, but it is not needed in the current computing situation. While there is debate over the relative contribution of "natural spread" and virus exchange to the current virus problem, it is known that code made available only as openly published material does eventually infect machines in the normal computing environment.
The term vx does not, therefore, require any imputation of sinister motives or hidden activity for the purposes of this discussion.)
There are some grey areas between these two poles. Some people have both written antiviral software and contributed to viral spread. Given, however, that one could expect a continuum of opinion, those in the middle are remarkably few. Either you are for virus exchange, or against it.
One other, separate, group should be noted. Viral programs are often cited as an example of "artificial life", and the research community in that field, both professional and amateur, have a legitimate interest in viral programming. Work in the a-life field, however, does not justify unregulated code and source exchange. For one thing, current viral programs "in the wild" (those which are to be found in normal home and business computers, as opposed to those which exist only in a research or laboratory environment) have only the most tenuous claim to artificial life. Common viral programs are simplistic snippets of code without anything like the complexity of the simplest known natural life forms. In addition, those who really do work in the artificial life area will be well aware that it does carry possible dangers, and that research should be subject to controls similar to those imposed on biological and genetic study.
The most common argument for virus-writing tends to boil down to, "You can't stop me." Many promote virus writing on the grounds of freedom of speech, a rather curious position in light of the incoherence of the arguments. (The most vocal of these tend to be Americans, who frequently cite "First Amendment Rights". This refers to the first amendment to the U.S. Constitution, which Americans tend to see as some universal law, rather than an arbitrary political document, however desirable.)
Rights, though, carry with them a weight of responsibility. As is often quoted, your "right" to swing your fist ceases at the end of my nose. You have a "right" to free speech--so long as you are responsible and do not perpetrate fraud. You have a "right" to study whatever you like--so long as you are responsible enough not to carry out experiments in poison with human subjects.
No PC is an island--at least, not where viral programs are concerned. Therefore, your "right" to study, write and distribute viral programs carries the responsibility to ensure that your creations do not--ever--run on machines where they are not authorized.
One of the most confusing aspects of the "exchange/no exchange" debate is the concept of the "good" virus. There is nothing inherently evil in the concept of reproduction. (Dangerous, yes.) In fact, the very earliest experiment with self-reproducing programs was the Xerox Worm of Shoch and Hupp. This was designed to spawn "segments" of the central program on other machines in the network, thus bringing the power of many processors to bear on a single problem. Thus, in theory, viral programming could represent the same level of advanced technology in software that parallel processing represents in hardware.
That's the theory. And it is promoted by no less eminent a researcher than Dr. Fred Cohen, who did seminal work on the security-breaking class of viral programs in a thesis, in 1984, and dissertation, in 1986. Unfortunately, the theory founders on some rather hard facts.
There are three questions to ask of a new, inherently dangerous, technology. Has it a useful application? Can it fulfil that application better than current technologies? And, can the danger, either inherently, or effectively, be controlled?
To date, no one has answered those three questions. While a variety of uses have been proposed for viral programs, there are none which are not effectively being done by other means. No viral programs have, indeed, been seen to be as effective as normal systems. Operating system upgrades could not guarantee universal coverage. Network management tasks could not promise reliable feedback. Automated utilities would confuse novice level users, who never run utilities anyway. The most useful function is still that proposed by Shoch and Hupp--and their programs were not, strictly speaking, viral.
(Vesselin Bontchev's examination of this question is the most detailed to date, and is required reading for all who want to join the debate. His proposals, while demonstrating good ideas for safety and control, are still primarily an advanced automated distribution system. The necessity for viral functions in this regard is still unproven.)
Those in the vx camp will point to two current viral programs which, they say, do have useful functions. One of these programs produces compressed executable files, thus saving disk space, while the other performs encryption on files. However, both of these functions are provided by other programs--from which, indeed, code was stolen for those two "good" virals. Neither of the viral programs are as easy to use or control as the original programs, and both have bugs which must place them firmly in the malware grouping, for nuisance value, if nothing else.
Currently, therefore, the utility of viral programs is very much unproven. This would, though, mean only that they are neutral, were it not for the lack of any demonstrable control. Methods of control have been discussed primarily by Fred Cohen, but even he remains unconvincing. The mechanisms generally are limited to environmental checks which can either fail, or be easily cut out of the program. Some have proposed "hunter" virals, to go after programs which "turn rogue", but a program which is corrupted will behave in unpredictable ways and a hunter program would likely consume a lot of resources, fail, or (most likely) both.
(Cohen frequently cites viral "programs which have been running since 1986 with no ill effects" and speaks of a VCE (viral computing environment). There are two points to be noted here. One is that Cohen has not yet described his viral programs in anything like the detail he put into his earlier work, so there can be no independent assessment of his claims. The second point is that the very term, VCE, implies that a viral computing environment is substantially different, and should be kept separate, from the "normal" computing environment as it is currently known. A VCE may very well be a powerful entity, but it is still an unknown and unproven concept.)
Computer viral programs have an inherent danger: that of reproduction and spread. If you study explosives, and pass along that knowledge, you also have to pass along the materials before there is any risk of a blast. Even then, the materials do not multiply themselves: when exhausted, another supply must be found. The same is not true of viral programs. These entities are designed to reproduce. And, unlike the study of dangerous animals, or even germ warfare, viral programs are built to reproduce, multiply and spread without the aid of a skilled, or even aware, operator. If you are careless with a deadly animal or weapon, it is still only a single danger in a localized area. If you are careless with a computer virus, it can spread world-wide.
We do not use computers because they are smart. Computers aren't smart. Sometimes we use them because they can do calculations very quickly, but even this is only a special case of the real value of computers. Computers always do the same thing in the same way. They are repeatable. They are, in this manner, reliable. Even a computer error can be useful to us--so long as it always happens the same way.
Consider, then, the computer virus. In order to reproduce without the informed assistance of the user, the virus must be, in the computer sense, transparent. It must operate without alerting the operator, or interfering with the operator's interaction with the computer. If the virus even posts a notice ("Hi! I am infecting object X!"), it has a nuisance value and is, therefore, not good. (Vesselin Bontchev notes that even such a notice, by possibly delaying a process, may have grave consequences far beyond annoyance.)
If, however, the virus does not notify the operator, then the operator is not aware of some additional code in the machine. This extra code will have an unknown, and inherently unknowable, effect on the computer. The operations of the computer are, therefore, no longer repeatable. This is a Bad Thing (TM).
Some will protest that I have overblown the danger of both the notification messages and the possibility of conflicts. The point that I am trying to make is that you cannot predict the harm which may arise from interference either with the operator or the programs. Software is digital, and is subject to catastrophic collapse without prior warning. For those without a background in computer risk assessment, an excellent overview for the non-professional is found in Lauren Wiener's Digital Woes. An intriguing compilation of the types of things that can go wrong is to be found in Peter Neumann's Computer Related Risks. At the very least, as Sarah Gordon points out, the virus is an autonomous agent, making decisions and carrying out activities according to it's own internal constructs and the intention of its programmer. This is very likely not in correspondence with your own intention, and is therefore an invasion of privacy.
A number of virus writers will object that their creations simply are not harmful. Not only is it impossible to guarantee that your virus will not conflict with existing systems, you also cannot guarantee that a given system will not conflict with your virus. Almost all file infecting viral programs will interfere with applications which have an internal integrity checksum or a non-standard loader, and will cause those applications to fail. (An example of this is that Windows programs infected with DOS viral programs always fail to load.) The "Ohio" virus (a prior version of Den Zuk) was not intended to carry any destructive payload, but an unusual interaction with a certain network operating system caused fatal disk corruption. Since both Ohio and Den Zuk are examples of the often proposed "virus hunter virus", it should be clear that the concept of using a viral program to hunt down and disinfect other viral programs is not a good one.
Historically, and statistically, virus exchange people have been careless and incompetent programmers. Remember that we are talking vx, here, and those viral programs which have been released into the wild. There may be, carefully hidden in the desk of a virus writer, the "perfect" and harmless virus. If so, we haven't seen it yet. The majority have obvious bugs, sloppy coding and derivative programming. Less than one percent are interesting for any reason; only a handful have unique styles of algorithms. And even these last have programming pathologies.
There are two other reasons often given to justify virus exchange. The first is generally described as experimentation and education. The second is described as antiviral research, or, more commonly, assessment of antiviral programs. These arguments do have some validity, and should be examined. Ultimately, though, the reality fails to support the claim.
The call for experimentation is somewhat tied to the argument for a "good" virus. Current viral technology may be crude and ridiculous, but how can it be improved if there isn't any work or sharing of results? Quite true. The vx community, however, have obviously not read or noted any programming journals or texts. Discussions of programming and algorithms are supported by well-annotated code fragments. You don't present a whole program to discuss a specific function any more than you send an entire car with a manual on auto repair. You certainly don't use encoded or "DEBUG script" object code: that has no explanatory value at all.
And I have yet to see, in the vx materials, any discussion of legitimate and positive uses for viral technology, any discussion of control technology, or any discussion directed at ensuring that viral programs do not create conflicts.
In regard to education, it is true that a study of viral programs is related to a knowledge of operating system internals, as well as assembly language programming. However, viral study requires such knowledge, rather than providing it. Giving someone a virus and expecting them to learn from it is akin to "teaching" a surgeon by handing him a scalpel and pointing at a patient. Even the vx "old guard" are beginning to realize this. Viral programs use normal computer functions. If you understand computers, a virus is trivial. If you don't, well ...
As far as virus exchange tutorials go, well, let me put it this way. I am a teacher. Many of you will also know that I review technical books on a daily basis. Some are great, enough are good, many are bad and some are just plain awful. Only a few are worse, in terms of tutorial effectiveness, than vx "zines" (electronic periodicals).
Recently, someone who makes his living pushing virus source code promoted a collection of viral programs by suggesting you could test antiviral programs with it. This, superficially, sounds like a good idea--if you don't know what real software testing is like. What do we know about the quality of this "zoo" (set of virus samples)? What do we know about the structure, organization, documentation and so forth? How many duplicates are there? Of course, we do want duplicates in some cases; we want every possible variation on polymorphs. (For Tremor, that works out to almost six billion files.) But then, this collection was on a CD-ROM. What a pity. The most successful viral programs are boot sector infectors, and you need to have real, infected disks to truly test for them. At a minimum, you'd want all seven "common" disk formats, in both system and non-system versions. That's fourteen disks--for each BSI.
For all the length of this piece, it is still only an overview. And, for all it's length, it probably hasn't convinced anyone. Ethics education (it used to be called "values education"), in whatever form and however presented, has very little to show that it works. There are various theories and models of moral training, the most sophisticated probably being Lawrence Kohlberg's Moral Development schema. All, though, basically boil down to sitting around talking about ethical dilemmas. They may develop debating skills and rhetorical sophistry, but there is no evidence to suggest that any of these programs leads to any significant change in behaviour.
While Kohlberg's model of moral development has the most detailed construction, its utility is questionable. His system is not so much one of values education as of values measurement. It is, therefore, a guideline for evaluating other ethical training methods rather than a means of instruction and change. Moral development is a six stage structure, assessing the type of reasoning which goes into ethical choices. The stages range from "fear of punishment" to "internal ethical principles". There is great difficulty, however, in determining the "stage" of a given individual. Most ethical discussions will be judged as having reasoning at all of stages three, four and five. This entire document, for example, could be dismissed as being level one reasoning since it mentions the possibility of the danger of virus distribution and could therefore be seen as a "fear of punishment" (negative consequences) on my part.
On the other hand, most of Kohlberg's proponents dismiss level six, since even a psychopath could be said to be acting from internal principles. Kohlberg, himself, has stated that he does not know if anyone consistently acts from stage six reasoning.
Probably the major reason for this is that modern society has no fundamental moral foundation. The most widely cited (and Johnson gives an excellent critique of it) is utilitarianism--"the greatest good for the greatest number."
Leaving aside the difficulties of assessing such a measure, utilitarianism, along with all the other modern "humanistic" philosophies, has nothing to support itself. Why is "the greatest good for the greatest number" to be chosen over "what I want"? An alternative is deontology; ethical principles derived from the concept of duty. (Ironically, this philosophy, while arguably superior to utilitarianism, is limited to Kohlberg's stage four almost by definition.) Again, however, there is no underpinning to the concept of duty, itself.
Ironically, the much maligned "Judeo-Christian Ethic" did have such a foundation for moral standards--God. The theistic universe may yet have the last laugh over the mechanical universe of B. F. Skinner's Beyond Freedom and Dignity. Maybe Jesus is the answer--or there may be no answer.
Clarkson, Windows Hothouse, 1994, 0-201-62669-1, U$34.95/C$44.95 - lots of artificial life fun with Visual C++
Cohen, It's Alive!, 1994, 0-471-00860-5, U$39.95 - an intriguing, provoking and practical exploration of computer programs as "artificial life", but somewhat narrow
Denning, ed., Computers Under Attack, 1990, 0-201-53067-8 - collection of essays roughly related to security, also "the net"
Ermann/Williams/Gutierrez, Computers, ethics and society - textbook for computer ethics course: not great
Gordon, Technologically Enabled Crime, 1994
Forester/Morrison, Computer Ethics, 1994, 0-262-56073-9 - lots of great stories, but short on analytical depth
Johnson, Computer Ethics, 1994, 0-13-290339-3 - the basic work in the field, thorough coverage and good discussion starter
Levy, Artificial Life, 1992, 0-679-73489-8, U$13.00/C$17.00 - an interesting wander through fields studying artificial life but no strong points
Neumann, Computer-Related Risks, 1994, 0-201-55805-X, U$24.75 - exhaustive examples from the RISKS-FORUM Digest of potential technological perils
Slade, Robert Slade's Guide to Computer Viruses, 1994, 0-387-94311-0/3-540-94311-0, U$29.95 - chapter seven looks at the computer virus and society
Thro, Artificial Life Explorer's Kit, 1993, 0-672-30301-9, U$24.95/C$31.95 - good fun, but little analysis
Wiener, Digital Woes, 1993, 0-201-62609-8, U$22.95/C$29.95 - excellent introduction to the risks of software
(A fuller bibliography on values education readings is available for those demonstrating a willingness to put some effort into it, since, frankly, it's a really disappointing field. Sarah Gordon's Generic Virus Writer paper has significant resources here.)
Editor's Note: Mikko Hyppönen, who works in Data Fellows Ltd's
F-PROT support, presented the following paper in the Virus Bulletin '94
conference. The treatise is published in two parts. This part was published in
the F-PROT 2.15 Update Bulletin.
The ExeBug virus family uses another way to make it difficult to boot up an infected machine from a clean diskette. The virus modifies the BIOS Setup information to indicate that the machine does not have A: drive at all. Such machine will always boot up from the hard drive. Once the booting has started and the virus code is executed, the virus will check if there is a diskette in drive A:. If so, it will continue the booting from there. In most cases the user is unable to notice this, and thinks that the machine has been booted clean when the virus is already resident.
Yet another way to complicate the recovery process is to set the BIOS boot-up password on with a random password during an activation routine. The method of doing this is documented on most new BIOS brands.
Some integrity checkers are capable of performing a generic disinfection. This means that they try to restore the original file according to the information the checker has previously saved (typically length, checksum, first and last bytes). Such generic routines won't work if a virus makes extensive changes to the program files, for example by encrypting the host file during infection.
The inherent risk of heuristic cleaning is that if the cleaner tries to emulate everything, the virus may assume control inside the emulated environment and finally escape from it - after which it can propagate further or trigger a destructive retaliation routine. There are documented cases of at least one virus doing this, see below.
Peach attacked an integrity checker which worked by creating a checksum file, containing checksums of all executable programs. Peach attacked by deleting this file. After the database was deleted and the checker was executed again, it recreated the file, calculating new checksums from the infected files and failing to report any changes in the system [VB1].
It should be noted that the Peach virus will not be successful against newer versions of this integrity checker, as the name of the checksum file has been changed in newer versions of the product. Similar types of attack still seem to be possible, though.
Even if a checksumming package did report to the user that the database has been deleted without approval, it would be difficult to find the affected files if no recent backup of the database exists.
Several generic attack methods against integrity checkers are discussed in length in [Bontchev].
Here are some examples of known viruses that incorporate retro-routines:
CPW virus family:
The main problem in this case is whether the anti-virus vendor notices what the virus is trying to do. Today, when several new viruses are found every day, there is a limited time in which to analyse any single virus. Virus analysis systems are automated as much as possible, and a virus typically only gets a cursory look - which is usually enough to add detection, identification and disinfection. Such analysis will not reveal any special features the virus may contain. This also explains why there are no anti-virus products which can provide detailed information about each and every virus.
If a retrovirus is run through a standard analysis system, and the product is tested by running it against a sample that is not resident in memory, the retro-features of a virus may not become known until they are observed directly in the real world - after which the virus will certainly get more attention, but this might already be a bit too late. The virus may also start its attack behaviours only after a certain latency time.
In many cases this is the only benefit a retrovirus gains from unloading a resident scanner. The scanner can't be unloaded before it is resident. If the virus is known to the scanning engine, a resident scanner will not let the virus run. If the virus is unknown to the scanner, it can operate even when the scanner is resident. The case is different with behaviour blockers, as they are not trying to find known viruses.
There is very little a product can do against an attack which consists of deleting or replacing the program file itself - if the virus gets control before the anti-virus, the virus makes the rules.
As the virus can try to locate the anti-virus program by its contents as well as by name, the structure or contents of the program file should change with each update.
The best way to make sure that no retrovirus is making its tricks is the old, well-known recipe: boot from a clean diskette and run a fresh copy of the anti-virus program from diskette.
It is not enough to ensure that the program code has not been changed. As demonstrated earlier in this paper, it is enough for a retrovirus to modify the texts or configuration info belonging to the application.
Even though the size of an anti-virus application probably changes during every update, a clever retro-virus can still locate the code it wants to patch by using a search string. This can be overcame by encrypting the application. The protection will be even better if the encryption method or key is changed with every update. Another, easier way to achieve the same results is to provide the executable in packed form, as the packing algorithm will invalidate search strings between different versions of the same program.
The communication channels to a resident part of an anti-virus program should be carefully thought out. If the TSR needs to have an uninstallation routine, it should be implemented so that other programs will find it difficult to request the uninstallation without the user noticing it.
At least three different scanners are known to have been analysed by crackers, up to the point of extracting all search strings of the program. Such attack can be harmful in several ways: the virus writers get to see exactly what they will have to change in a virus to make a new, undetectable variant, and well-chosen search strings are also closely guarded trade secrets.
Popular, easy-to-get programs are the most probable targets for attack routines. This makes commercial products theoretically more safe than shareware or freeware products.
It's time to make sure your anti-virus product is not vulnerable to an attack it could avoid.
[Veldman] Frans Veldman, Combating Viruses Heuristically, Proceedings, 3rd International Virus Bulletin Conference, September 1993, pp. 67-76
[Bontchev] Vesselin Bontchev, Possible Virus Attacks Against Integrity Programs And How To Prevent Them, Proceedings, 2nd International Virus Bulletin Conference, September 1992, pp. 131-141
[VB1] Virus Bulletin, Peach Virus Targets Central Point, Virus Bulletin May 1992, pp. 17-18
[VB2] Virus Bulletin, Tremor - A Shaky Start for DOS 6?, Virus Bulletin March 1993, pp. 10-11
[Fellows] Data Fellows Ltd, F-PROT Professional User Guide rev 4.21
[Siilasmaa] Risto Siilasmaa, Building a Corporate Security Strategy - Coping With Computer Viruses, Proceedings, Cope'IT Conference 1993
Some months ago (June 1994), my wife phoned me advising that the person who
usually gives her information about the statement of our account in the bank,
told her that the system in the bank was halted by a virus attack. (Between us,
what a drain of information! No security at all.) Of course, She didn't have
any info of our account this day.
A further call to the System Administrator of the bank reveals that the virus attack "knocked out" about 150 machines connected with some servers over Novell 3.12. I proceeded to meet this person and talk with him.
After an hour of talking I have the following information:
Name : Avispa (means wasp in English)
Size : Varies between 2048 (+15 bytes).
Infects : EXE files.
Scan string : BB ? 01 ? ? 80 C3 ? ? ? 2E 8B 07 ? ? B9.
In the wild : Yes.
Interrupts : Hooks interrupt 21h and 13h.
Load Address: -----
Polymorphic : Slightly (not exactly performs some bytes
encryption in fixed places).
Resident : Yes.
Size in RAM : 2304 bytes.
Stealth : No.
Text : Not visible its encrypted and varies, exists at
least two version of this virus and one dropper.
The text says:
db "$$ Virus AVISPA $$ Republica Argentina$$ Elijah Baley "
db "$$ Noviembre 10 de 1993 "
db "$$ This program is not an old virus variant, and it was written "
db "in Argentina by Elijah Baley. It uses polymorphic technics to"
db " avoid conventional scanning."
Type : Infects .EXE files, and the virus is appended
to the end of the infected host files. Unusual
Have a routine for overwrite with the text
described before but this takes place in memory
everytime int 13 is used to read the disk.
Other info : This virus was submitted to Wolfgang Stiller
about 03/01/94 and my final analysis 05/19/1994.
Also submitted to David Chess to check some
information on request of a friend of mine
(Claudio Toriano) who works for IBM here in
Argentina (10/21/94).
Both, the explanation of the name and a part of
the encrypted text (not transcribed by "ethic")
are insults to our actual president.
Note: Some time after I could verify some things that I skipped about this
virus.
Every time I verify an infection of this virus the four files listed before result infected. They're .EXE files of course, but some other analysis I read in a local magazine about security published here describe them as "targets" predefined by the author. Other version of this virus ??, maybe.
The source of this virus was published in an "underground" review (about July 1994) and distributed to BBS's. I found this source too and a closer look to it shows that the virus avoid the infection of EXE files which the last two letters of it name ended with:
Some time later I made a revision of the dates in which success happened and I was surprised. Hope this could help and be significant in the study about dispersion of viruses:
Month/Year Observation
---------- -----------
11/1993 The virus was programmed.
02/1994 I Found the virus.
03/1994 Send the virus sample to Stiller Research.
04/1994 Talking with Vesselin Bontchev, he confirmed
this virus as polymorphic. He had a sample.
06/1994 Virus Attack the Bank.
07/1994 Code was published in underground review.
08-12/1994 Begin to appear infections masive.
Aclaration: The name of the Bank, the security company that assist the Bank and
the name of the Antivirus used in the Bank are confidential.
We have a new contributing author, Mario Elkati from Spain. Mario works for ANYWARE AV software. He tells us about the virus stats in Spain today.
The Percentage of viruses reported fall into the following viruse families:
Regards! Mario Elkati
Editor's note: There has been some slight rewording do to the age of some of our readers. :-)
Greetings,For those of you who know me, you may know my various handles, my activities, and causes for what little fame I may possess... I am Stormbringer of Phalcon/SKISM, Black Wolf, and Jesus of the Trinity, and even some others probably no one would recognize. And today, I am retiring.
Last night, I got email from a guy in Singapore.... a nice guy, really, extraordinarily polite for the circumstances.... he had been infected with one of my viruses, Key Kapture 2, by some guy who wanted to mess with his computer. It was filling up his drive (he had only 2 megs left) with captured keystrokes, and he had no way to disinfect it, so he wrote me, asking me for help to cure one of my own creations that had attacked his computer... I called him up voice, and talked with him.... and even then he was kind, almost like he didn't really blame me, although I feel he should. Now, I never released my viruses against the public myself, never wanted them to be in the wild, but it happened. Fortunately, I also never wrote destructive viruses, so I didn't trash the poor guy's computer. It will be fixed, with the main harm being his time and security.
For some reason, this really shook me. I had always written my viruses as educational, research programs for people to learn more from, and for myself to explore my computer and a type of program that I found almost obsessively interesting. All of my viruses were written to explore something new that I had learned, something different, something cool..... and yet, I still managed to hurt someone...
A lot of you people are probably thinking that I'm a wuss, or whatever, and I really could care less.... messing up people's stuff was never my intention, and yet it happened. I have decided that it is time for me to quit writing viruses, and continue on with something more productive, perhaps even benificial to others.
Don't really know what else to say, 'cept that it was an interesting journey..... and I'll still be hanging around somewhere on the nets.....
Cheers,
Stormbringer, Phalcon/Skism
Ex-Virus Writer
Vancouver's Our Computer Player newspaper, in a story without a dateline, but probably from a newswire service, reports that a federation of Japanese computer clubs has stated it will be presenting US President Bill Clinton with a "harmless" computer virus. The stated purpose is to raise awareness of the danger of viri. The purported virus, named as "Kyoto Ichigo" (Kyoto Number One) is said to display the lyrics of a song by a Kyoto amateur band. A spokesman for the federation, identified as Takao Yamamoto, is reported to state that malicious viral programs in Japan are virtually all of US origin, and that he hopes this will suppress the export. (Sounds like these guys have a very tenuous grasp of the concepts, here.)
The jargon contained herein is oriented to IBM's technology, though not uniquely. Terms are included from two ANSI dictionaries (X3.172-1990 and EIA 440-A) and the International Organization for Standardization document ISO/IEC JTC1/SC1 document. Still, this will be quite handy when those who work with real computers have to translate for the blue suits. Net people can regard this as a rather old document: ftp is listed (capitalized) but neither HTML nor Gopher appear.
Given that the majority of entries are either special definitions for common English words, or phrases of English words, the lack of any pronunciation or part-of-speech guidance is understandable. Less usual is the listing of cross references (see also, contrast, etc.) as additional definitions. (This format is not consistent throughout.) Some of the additional definitions are decidedly odd, such as:
About... (1) In SAA Common User Access architecture, a help action that displays ownership and copyright information about the application. (2) In SAA Common User Access architecture, a help action that displays the logo window of the application.It is also very easy for errors of omission to slip into a work of this size, though I must say that I'm a bit put out that both "virus" and "worm" point to "attack", while "attack" points back to neither.
The need for a definition for a lapel mike (especially since it is defined as "synonymous with lavalier") escapes me. I thought I had found some good old hacker-speak when I got to "punch and crunch editing", until I found that the "preferred" term--"assemble editing"--refers to video production. I guess IBMers have to deal more directly with media people than with programmers.
The major part of the book (Travel Tales) reads like a series of short magazine articles. The articles can't be exhaustive (nor can the list of topics), but both material and variety is well chosen. The entries are readable, and easy to take.
An interesting feature is the glossary. There is no attempt to provide a tutorial for life online, but the glossary entries are at least a paragraph in length, and sometimes extend to a page or more. This allows the reader to pursue explanations at his or her own pace.
This book is neither complete enough to serve as a reference, nor organized enough to be a training guide. Those who are curious about the online world, however, will find it an easy and probably appealing entre. Read the "Travel Tales" that sound interesting. Look up the glossary references for new terms. Eventually, you may find it worthwhile to buy a "modem."
Online aficionados may also find this a way to expand horizons. The net is wide. There are lots of interesting tidbits herein.
From that point on the reader is taken into the basics of virus operations and how they work on various systems. The basics of ploymorphism, tunneling, and stealth as well as payloads and triggers are explored.
Chapters Five and Six get into anti-viral procedures and techniques and follow up with AV Software evaluations.
The "appendices are longer than the book" to quote Mr. Slade, however they are very informative. FAQs about viruses, quick reference antiviral review chart, vendors and contacts listing and a bookshelf review are well written and very well catalogued. The glossary is very helpful to the beginner trying to understand the terminology in AV.
Mr. Slade did a wonderful job bringing an otherwise complicated subject matter down to the grass roots level to where the everyday user can get a basic education in anti-virus prevention and techniques. I highly recommend this book to any beginner who is serious about learning all they can about computer viruses and protecting their systems.
It was not released by any AVP agent! This archive did NOT come from CENTRAL COMMAND INC.!
This archive can be named AVP22.ZIP or AVP22US.ZIP
PLEASE DELETE AND REMOVE THIS ARCHIVE IF YOU FIND IT!
If you find this archive please notify Central Command Inc. at our e-mail address at: kapeer@netcom.com or call Keith Peer directly at 216-273-5743. Please leave a message as to what BBS you found it on and what there phone number is. Also, contact the Sysop and have him remove it from his BBS.
If you are a REGISTERED AVP user contact your nearest AVP agent for a authentic version of 2.2. If you need assistance finding your nearest AVP agent you may contact the North Amercia AVP agent Central Command Inc. for a list.
I received a message and a file from a new user on my system. The original message that he sent me is as follows. Since this Person was not able to Totally UUENCODE it and send it in a message to me, he uploaded it and believe it or not, it did pass my file scanner. Please, if you have the following user upload or send you a file,please erase it. It DOES contain the AIDS Virus...
As You Can Notice From the message below, he logged onto my system under the name "JOSH GERWIN" but at the end of the message it is spelled Josh Garwin, so this more than likely is not his name. Please be aware of this person or the file "TriN11.zip"
Woody: I received the message below from Mark West on Delphi
Bill, I have just received a note from the member on Delphi Internet that discovered the Whisper virus on the CD-ROM I spoke of in my last message. The information in my last message has been verified. Here it is again to confirm:
Here is the info on the CD and the infected files:
CD: Companion (second in the series)
Company: GCW,
11 US Route 15 North,
Village Shops,
Dillsburg,PA. 1
(717)432-0404.
The program on the CD is part of "Rise of the Triad" (rott). It is a sound
setup file SNDSETUP.EXE.
Woody: This message was posted into the UNI NET virus conference.
Does anyone know anything about the following??? Is it just another uninformed scare from someone on the net???
W A R N I N G :Editor's Note: This is what I received from Rob Sade on the HOAX:If you are using a DOS or Windows machine, then you are vulnerable to attack from the JPEG virus. THIS IS NOT A JOKE! The JPEG virus has already destroyed the hard disk of a major BBS in Chicago and has caused much grief to several users already (see the section on my personal experience with the JPEG virus for more details).
HOW THE JPEG VIRUS WORKS:
The JPEG virus hides in the comment field of the JPEG (JFIF) file. the JPEG image is loaded into video memory, the JPEG virus is loaded into shadow ROM, affecting the video driver interrupts (int 0x10) and some of the DOS file interrupts (int 0x21).
The JPEG virus takes advantage of a little-known undocumented featur DOS that has been around since DOS 3.3 known as direct execution. For some reason (known only to Microsoft) loading a data file can cause immediate execution of a program file contained within the data file When a DOS interrupt 0x21 is invoked with a function call 0x3F (read from file or device) DOS will scan the data file as it reads it for following information:
Offset Size Description ------ ---- ----------- 0x00 0x08 Magic 8-byte ``Load program'' string 0x08 0x04 Location inside current file where program begins 0x0C 0x04 Length of program 0x10 0x02 Segment address of environment string to pass to loaded program 0x12 0x04 Pointer to the loaded program's command line 0x16 0x04 Pointer to the first default File Control Block (FCB) 0x1A 0x04 Pointer to the second default FCB 0x1E 0x02 ChecksumWhen the magic 8-byte signature is read by DOS, the next 24 bytes are read, the checksum is computed, and compared to the checksum stored the 32-byte header. If the two checksums match, DOS finishes loading the data file, then immediately proceeds to load and execute the program. (Actually, it may first load the data file, then do the ckecksum stuff, but that's an irrelevant detail.)In the case of the JPEG virus, the 32-byte header is located inside comment field, and the JPEG virus is catenated to the end of the JPEG file. When the JPEG virus is loaded, it installs itself into shadow ROM, then executes an IRET which then returns execution back to the original picture viewer. Note that if you have not correctly configured your computer, that the virus will load improperly, and the picture program may appear to crash when you try to load the JPEG image.
HOW TO FIND OUT IF YOUR JPEG FILES ARE INFECTED:
At present, there are no anti-viral utilities which scan for the JPE virus. This is because several strains of the virus are known to exist and there is no simple common pattern which can be used to different between valid JPEG comment fields and infected JPEG files. To be on safe side, you can scan for the JPEG virus yourself. Get a hex edit from WUARCHIVE (or your favorite ftp site) and examine the first few bytes of each one of your JPEG files. The comment field comes in between the first three header bytes (FF D8 FF) and the file type last (4A 46 49 46 == "JFIF"). If you see no comment field, or a valid ASM comment field, then your JPEG file is OK. However, if you see a rand string of hex characters, then your JPEG file may be corrupt.
Sample output from the HEXDUMP program is shown below on an uninfect JPEG file. Note that the comment field contains a valid ASCII comments between bytes 0x06 and 0x4E.
00000000 ff d8 ff fe 00 K * * * * J P E G C 00000010 o m p r e s s o r C o p y r i 00000020 g h t ( C ) 1 9 9 1 - 1 9 9 00000030 2 P o t a p o v W O R K S , 00000040 S T O I K L t d . * * * * ff 00000050 e0 00 10 J F I F 00 01 01 00 00 01 00 01 00 00000060 00 ff db 00 C 00 0a 07 07 08 07 06 0a 08 08 08 00000070 0b 0a 0a 0b 0e 18 10 0e 0d 0d 0e 1d 15 16 11 18I strongly urge that you should scan all your JPEG files for the JPEG virus by examining them with the hex editor found at the end of this post. If you find any strange hex characters where the comment field should be, then you will want to destroy the infected file. Note: if you have a hex editor, you can just over-write the nasty 32-byte header with nice blank spaces. This will "kill" the virus and let you keep your nice images.History of the JPEG Virus:
The first known strain of the JPEG virus was discovered by Dr. Charles Forbin at CERT on 31 October 1993. He immediately informed NSA officials, who promptly declared that such a thing was "physically impossible." In honor of this profound judgement, Dr. Forbin named first JPEG virus "Physically Impossible." Soon, other strains were discovered, most notably being the strains Cruel Tricks 4, Dead Friends, Clueless, and Brain-Dead.
If you think your JPEG files are infected, it's probably Physically Impossible, but it might also be Clueless and/or Brain-Dead.
Note that multiple JPEG viruses may simultaneously infect JPEG files. If too many viruses infect a file, then there is a comment field overflow which can cause the JPEG file to crash your computer. In addition, infected JPEG files can also cause some JPEG viewers to be unpredictably, producing poor quality output. If your JPEG files dont look very good, they may be infected and you should check their comm fields right away.
W A R N I N G :
Although only JPEG files are known to have been infected, there are several other types of image formats with comment fields, including files. This means that ALL your picture files may be subject to infection. If you suspect that your pictures are infected, then check the comment headers right away!
R E C O M M E N D A T I O N :
Do not view ANY JPEG files until you have scanned their headers. Be wary of JPEG files from disreputable sources (FTP/FSP sites, BBS,USENET, etc.) Check the headers of all your JPEG files AT ONCE befor they are infected.
I don't know whether you would have seen the original JPEG "warning" message or a reposting of it, but the original was posted on April 1st this year. In fact, it was posted on April 1st last year as well. The message is a hoax: there is no JPEG virus.
There are several tips in the message that brand it as a fake. First, it states that the purported virus takes advantage of a bug in MS-DOS when loading data files. Such a bug is unlikely to have survived for fourteen years without being detected and fixed. In any case, DOS does not have special routines for handling data: that is done by application programs. (The wording of this "bug" is probably supposed to recall the sendmail data overrun problem used in the Internet Worm.)
Secondly, this is another re-run of the dreaded "monitor destroying virus"--which doesn't exist. There is no known virus that destroys hardware. In any case, the alleged virus is supposed to change the frequency on the "flyback transformer." This is a combination of two technologies. In some very early graphics cards, it was possible to change the frequency of the "sweep rate" of the monitor--and, by changing it to zero, you could stop the scan at one point one the screen. After some time, this would burn the phosphor off that one spot, and leave a tiny dead spot on the screen. The flyback transformer, however, is a high voltage device used on all cathode ray tubes, and is not addressable by software.
Finally, the "expert" quoted in the message, Dr. Charles Forbin, is a fictional character, hero (?) of the book Colossus and the movie The Forbin Project made from it.
While ExeBug is in memory, it will mis-direct attempts to read its code in (cylinder&head 0, sector 1) to the relocated MBR data (in cylinder&head 0, sector 17) which makes it a "stealth" type virus.
From then on, the virus will be in memory, ready to infect other diskettes, on any access (even DIR). The FORMAT command cannot remove this type of virus, since FORMAT doesn't write to sector (cylinder&head 0, sector 1) where the virus code is written.
In addition, ExeBug alters the CMOS data, so that the A: drive is shown as "Not Installed," which may prevent some PCs from being booted from an uninfected DOS boot disk, at least until the CMOS/Setup is restored.
Depending on the computer's BIOS, the A: drive may be accessed temporarily with the <F1> key to allow a boot from an uninfected floppy, necessary before attempting to remove the virus. The CMOS Setup itself may be accessed at the start of the boot process, with the <F2> or <DEL> key, or by a combination of the <Ctrl>+<Alt> plus either <S>, <Esc>, or <Ins> keys. (Some PCs do not have the Setup program built-in, but on a separate diskette.)
Once the PC has been booted from an uninfected boot diskette, DOS won't be able to access the hard disk,displaying an "Invalid drive specification" message, because the partition data which was in sector (cylinder&head 0, sector 1) was written over by the virus.
This virus is an example where the undocumented DOS5/6 command FDISK /MBR is futile, since the partition data will still be missing from (cylinder&head 0, sector 1). Copying the original data from (cylinder&head 0, sector 17 to 1) will write over the virus code, allowing a re-boot from the hard disk.
ExeBug will "trojanize" EXE files, writing a small program in the "slack" space at the end of the file, which can destroy Directory and File Allocation Table data in the month of March, thus causing files to be inaccessible to DOS, and if fragmented, lost to most data recovery programs.
Antivirus programs do not find these trojans, nor are they shown with the DIR command. Although they are harmless once the virus itself is removed, they can be wiped off the disk if a utility is used to "wipe" the file "slack," or if a utility is used to fully de-fragment the disk.
I put an infected floppy disk into the drive the booted the system. This is a very typical scenario. An infected disk is in the system and the user turns the system on. The usual error message comes up and the user removes the disk not knowing that the system is now infected. Well, we see the message:
Non-system disk or disk error
Replace and press any key when ready.
(NOTE: this message will vary from system to system depending on the DOS used
and the language being used in the DOS)
So, I remove the disk and the system comes up all is hunky dorie right? Wrong. I do a chkdsk and see that there are only 654336 total free bytes when there should be 655360 bytes free. The system is infected. At this point I would like to tell you that some systems use a part of the memory for their BIOS operations. If your system is one of these then be sure you know how much memory the system reserves for these operations so you will be familiar with what the total free meory should be.
Diskette drives or Type mismatch error - use setup
Press F1 key to continue or CTL-ALT-ESC for setup
(NOTE: this message will vary from system to system, the point is EXEBUG has
messed up the CMOS and removed the A: drive information so the system will not
recognize the A: drive, forcing the system to boot from the C: drive. If your
boot drive is B: then the B: drive will be disabled)
Make the proper data inputs to the CMOS then continue on. We finally arrive at the start up screen for F-Prot. (Those of you that are more familiar with the program and prefer to use line commands probably don't use this, so be sure you read the DOCs that explain these commands in order to be sure to properly use the program.) Now, there are some things one must be aware of. If we just do a SCAN, F-Prot will come up and say:
Master Boot Sector infection: EXEBUG.AThe following message will appear in a red box:
Error: No hard disk found.This is all you get. You must go back to the opening screen and Tab down to Action. Go into to Action and you can either choose Disinfect/Query or Automatic disinfection. Because this is in the Bootsector these are your only choices for removing this type of infection. Now run the program again. This time you will see a red box with the following message in it:
The Master Boot Sector is infected with the
A variant of the Exbug virus.
Disinfect (Y/N)?
Obviously you would choose Y. The program will then put another red box on the
screen saying:
Error: No hard disk found.Look very carefully below the red box:
Master Boot Sector infection: EXEBUG.A
Virus removed.
See the message that tells you the virus has been removed? This message comes
up because while F-Prot has removed the bug we have not reset the system so it
can see the hard drive. Turn the system off and then back on again and you will
be back in business. If you want to make sure you got it, turn the system off
and put the bootable disk in the system and bootup again. This time just do a
Scan and you will find that the Exebug virus is no longer there. F-Prot has
removed the virus from the system and you are now ready to move on.
A note from Mikko reminded me to tell you that if you use F-Prot from the command line use F-Prot /HARD/DISINF, do not use F-Prot C:/DISINF. For more information see COMMAND.DOC on the F-Prot disk.
F-Prot will remove both variants A and C the same way. It takes longer reading about it than the actual process takes.
The setup of Integrity Master is crucial to its proper use. I speak from experience. :-) I had some problems at first because I did not set it up properly. Thanks to Wolfgang Stiller and Bill Lambdin assisting me I now have the proper set up. So, let me go over the set up first with you so those of you running Integrity Master have a proper set up.
Now, I boot the system form this bootable floppy with the IM files on it. Again, I get the drive mismatch error. Make the changes in the CMOS as needed and continue.
For those of you more familiar with the program, you may be more comfortable with the command line commands. Be sure you keep abreast of any possible changes or add on to these commands as the newer versions come out.
When the main screen comes up tell IM to change disk to C. You will get a big red box with the following text in it:
Disk Change failed. Disk C is not ready.
Please check and make sure the drive is ready.
There are other possible causes for this problem.
They are described in file QUESTION.TXT. TO read
this file, locate your original IM files and enter
the command: IMVIEW QUESTION.TXT
If you have experienced disk corruption or if IM
previously found a virus in memory, you will need
to use the "Missing Partition" option on the
"ReLoad" menu to fix your disk.
After you read this and hit ENTER you will be confronted again with an other
red box. This box will tell you there is an error reading the disk. Keep going,
hit ENTER again. This will take you back to the main screen. Tab over to ReLOad
and Tab down to Missing Partition. Hit ENTER then Tab down to DOS logical drive
letter (A to Z). Press enter and a box will come up asking you what drive you
want to reload the Partition on. Enter C.
At this point you will be warned (again via the red box) that you are about to replace the partition sector with the file on A:. This is what you want to do. Remember, you loaded this onto the rescue disk earlier after you loaded it form the HD to the IM_HOME directory on the floppy. SO, tab down to:
Reload of partition sector completed.Turn the system off and bring it back up again and you are ready to go.
This is a perfect example of how bootsector viruses can spread so rapidly. If the user does not practice some sort of Anti-Virus technique they can infect an office or even a small company in no time.
I tired to get an EXE file to become infected with the Trojan but did not succeed, unfortunately. I will have to do some further tests to check this out.
Preliminary analysis of Green Catepillar by W.H. (Bill) Lambdin
Name ] Green Catepillar
Size ] 1579-1591 bytes
Infects ] .COM .EXE files including COMMAND.COM
Scan String ] No scan string necessary. All scanners detect this
In the wild ] Yes
Activates ] This virus activates by displaying a green catepillar
] crawling down the left side of the screen.
]
Armored ] No
Detected ] Yes
Encrypted ] No
Interrupts ] 21h
Load Address ] 9F8D:0100h on my test machine. The load address will
] vary depending on the amount of RAM available.
Marker ] Date and Time Stamps on Infected host files are
] updated to the date and time of infection
Polymorphic ] No
Resident ] Yes
Size in RAM ] 1840 bytes
Stealthed ] No
Text ] No text visible in files or in memory
Type ] Resident file infector. The virus is appended to the
] end of infected host files
Unusual ] Will infect files as small as two bytes.
So ends another month of virus info. With new viruses coming out everyday it
is a job and a half just keeping up with what is already out there, let alone
what is new and where it came from. Rob Slade hits on a subject that we all
need to look at. With Stormbringer retiring I am sure there will be someone
else to take his place. Why do they do it? I don't know. Some say for fun, some
say to get a message across, some do it because they enjoy making others
miserable, and then again some don't have a clue as to why the do it other than
it being cool. What ever the virus creators reason is for turning the bugs
loose, you as a user need to stay alert. Stay on top of the new techniques and
the new AV programs. The Scanner is just one of the ways to keep up with
the times. There are many conferences you can follow and other publications
that will keep you informed as well. Use them.
There are many many AV products out there. Some better than others. Some promise the program of all programs to end the need to ever need another AV program. Well, I believe the old adage "If it sounds too good to be true then it probably is" applies here. The AV product you use is a personal choice just like the type of computer you choose to use. What ever your choice is pick one and learn it. It takes just a few seconds to properly maintain your system and scan those new programs you download. It will all be worth the time believe me.
Til next month, have a bug free month.