Current anti-virus software, combined with sensible filtering (such as quarantining all executable content from e-mail and Web traffic), firewalling, and religiously maintaining patches, serves as a reasonably good defense against the current classes of virus, worms, and script kiddies. This malware includes conventional file infectors, mail worms, people running attack scripts, and active worms based on old security holes. Unfortunately these techniques are not sufficient to stop a speed-optimized active worm based on a previously undiscovered security hole.
In order to prevent highly damaging “superworms” or hackers using unknown or unpatched exploits, different solutions are needed that are designed to prevent and respond to unknown attacks, rather than known attacks. These techniques need to be automated (as human responses are too slow to prevent damage), implementable, widely deployable, and must require no application changes. This article examines three technologies that offer significant levels of protection against unknown attacks: software fault isolation, intrusion detection through program analysis, and fine-grained mandated access controls.
These technologies share an important property: they do not rely on the correct operation of the programs; rather, they provide a secondary layer of defense should a program be breached and corrupted. It is possible that these systems may also contain flaws; but in order for a successful exploit to occur, both the application and the secondary defense need to be subverted at the same time. Since bugs will continue to be patched, it is much less likely that two overlapping bugs will exist and be known simultaneously than that a single flaw will be known.
Software Fault Isolation
The first technology, Software Fault Isolation (SFI), developed by Wahbe et al. (Efficient Software Based Fault Isolation, Proceedings of the Symposium on Operating System Principles, 1993), is a mechanism to create Java-like sandboxes for dynamically-loading arbitrary code in a language-neutral manner. Unlike JVM-based systems, it can be applied regardless of source language and compiler. The only semantic restriction is that dynamic code generation is not allowed within a fault-isolated module.
SFI operates at the assembly level on a code module through a combination of static analysis and dynamic checks to create the sandbox. The system gives each module its own private memory space in which it is isolated as part of the larger program. The static checks ensure that all statically determinable jumps only occur within the module and to allowed external functions, creating the basic structure of the sandbox.
The dynamic checks are inserted onto every load, store, and dynamic jump (except for those that can be removed through static analysis) to ensure that the program can't escape the sandbox created by the static analysis and allocated private memory. These checks do not ensure fine-grained correctness (such as bounds checking) but only a coarse-grained correctness: the module is not allowed to read or write outside its allowed memory ranges or execute code not contained within the module's code base or allowed external functions. Since the module is now restricted both statically and dynamically, it is effectively sandboxed from other modules within a larger application.
The performance impact, as measured in several scenarios, is relatively minor: the original paper reported a ten percent increase in overall execution time. Later versions reduced this overhead to a little over five percent when compared with unmodified binaries. When using compiled C or C++, this represents a significantly greater level of performance compared to most Java systems while maintaining the same level of protection. Additionally, since it does not require a programmer to recode the application, this technique can be easily adopted into a wide range of systems.
This technique offers two significant advantages: it allows the safe execution of arbitrary binary modules (such as those contained in Active-X and browser plug-ins, which remain a serious potential hole, as Microsoft and others have focused on authentication rather than isolation), and prevents the most damaging effects of buffer overflows: the ability to execute arbitrary code. If a fault-isolated module contains a buffer overflow, the attacker is limited to overwriting data structures and causing the program to jump to an allowed code location. Since the attacker can no longer inject code which the application will run, this eliminates most of the power contained in buffer overflow attacks.
As an example, if IIS used this technique on all its sub-modules and scripts, this would have stopped Code Red. Without the ability to inject arbitrary code into a malformed module (the index server extension in this case), Code Red would have been unable to spread. More importantly, it would prevent a stolen Microsoft private key from being used to create an Active-X based worm because it allows downloaded Active-X modules to be safely sandboxed.
Software Fault Isolation was being commercialized by Colusa Software between 1994 and 1996 as part of their OmniWare mobile code framework, a means of portably executing binaries in a safe, language and architecture neutral manner. In March of 1996, Colusa was purchased by Microsoft as a means of preventing another Java-like portable code system from entering widespread acceptance. Since then, there have been rumors about continued development within Microsoft but it has yet to be integrated into a released product.
A simplified version, which only checks that jumps are within the allowed ranges, would prevent buffer overflows from executing arbitrary code at an even lower run-time cost. Since it offers a significant improvement in security (roughly half of all major security holes are buffer overflows) at a relatively low performance cost, without requiring language or program changes, this technique should be included at the compiler stage, or contained within a static translator installed on the machine.
Intrusion Detection by Program Analysis
The second major technique, host-based intrusion detection by program analysis, was first proposed and tested by Wagner and Dean (Intrusion Detection via Static Analysis, 2001 IEEE Symposium on Security and Privacy). This IDS performs a static analysis of the program to create an abstract, non-deterministic automata model of the function and system calls. While the program is executing, it compares the system call pattern with a running copy of the automata. If the program ever attempts a system call which violates the model, the system assumes that an intruder has corrupted the program.
Unlike other intrusion detection techniques, which rely on either sample inputs or rule sets, this method has a provable zero false positive rate, eliminating all false alarms. This means the intrusion detection system can initiate automatic responses: blocking the system call, shutting down the corrupted program, and alerting the administrator. The zero false positive rate is due to the programmatic nature of the IDS, which contains a model that represents all possible legal paths through the program, ensuring that any detected deviation from the model is not caused by the program's code but by code inserted by a bug or an attacker.
The biggest concern is the very high run time required for the IDS to operate. This is due to imprecision in the model of execution because the IDS only has access to system call information from the running program. There are two solutions: the first is to have the IDS walk the stack to determine the program's call state before allowing a system call, which greatly increases the precision. The second, which feeds even more information, has the IDS that is modifying the binaries to various function calls send information about their invocation to the IDS system.
The other major limitation is the inability to handle multi-threaded programs without an explicit mechanism to detect the occurrence of a thread switch. This is not a problem for most UNIX programs, but is a significant problem if one wishes to apply this technique to Windows systems, which rely more heavily on user threads. Yet the same performance-enhancing solution of program annotation can be used to overcome this limitation by transmitting when thread switches occur.
A Code Red-style worm would be able to break into a system protected by such an IDS, but the potential damage would be greatly limited. It would be easy to deface Web pages by substituting the routines that deliver the content to pages that return erroneous contentalthough even though they may behave identically at the system call level. Since such behavior is not contained in the original program, the IDS would stop the program before damage could be done.
The Security Enhanced Linux (SELinux) Project
The final technique utilizes the fine-grained mandatory access controls that are the primary foundation of the Security Enhanced Linux (SELinux) project, a research design created by the National Security Administration's Information Assurance Research Group. SELinux is designed around two key concepts: fine-grained mandatory access controls and a separation between enforcement mechanisms and policies.
Most systems have very crude levels of access controls: a program running as root (or the OS equivalent) has access to every function in the machine and has nearly unlimited ability to manipulate the computer's systems. Programs run by a user usually inherit the user's ability to manipulate files. To make matters worse, necessary functions often require root level privileges: as an example, sendmail in Unix systems needs to be able to bind to port 25 and write to the user's mailspools while the other root abilities (such as being able to put Ethernet ports into promiscuous mode) are not. Yet a corruption of sendmail (from a worm or attack script) has access to abilities that sendmail never needs to use. This problem is most clearly demonstrated by Code Red II: because IIS runs at system level, as are processes it can execute, the backdoor installed by Code Red II can perform practically any action desired, including shutting down the infected machine or even erasing the disk.
Fine-grained mandatory access controls solve this problem. Instead of privileges being a crude measure of access, fine-grained controls ensure that every system call is authorized as a function of the running program, the user running the program, and the context that invoked the program. This can be a very powerful tool if the enforcement policies are well written. One policy could have a Web server that could only read (but not write) to the filesystem as an anonymous user, with the ability to write to only specific log files. With similar restrictions on network and other activities, the scope of a Code Red-style worm would be severely limited: it could infect a Web server, but it couldn't initiate new connections in order to spread itself or execute any program except those which the Web server normally is able to run.
Additional access controls could specify whether the stack and heap are allowed to contain executable code. Modern processors can enforce this separation through the virtual memory system, but only if the OS requests it. Except for run-time compilers and dynamic code specialization, most programs have no need to generate dynamic code. Thus for the majority of the programs, the OS could simply ensure that heap and stack memory is non-executable, eliminating most of the power of buffer overflow attacks with no effect on performance.
This technique requires small but numerous changes within the operating system. Almost every system call needs to enforce security policies, but coding the policies into the checked calls results in an inflexible system. Instead, SELinux uses a "security server", a separate area of the operating system that performs the checks. Whenever a portion of the operating system needs to check if a command is allowed, it calls the security server to verify that the current policy allows for the action to proceed. This allows for maximum flexibility as different policies can be given to the security server and global security policies can even be changed while the system continues to run.
The greatest advantage of this technique is that it offers significant flexibility, a high level of protection, and high efficiency. The flexibility comes from the ability to write arbitrary policies for programs or users with different goals, from providing basic isolation for some servers to minimizing the risks of viruses by limiting the power of unknown executables. The high level of protection is derived from the ability to compose comprehensive security policies that directly limit an application to the tasks it needs to complete. Finally, the efficiency is derived from the observation that, for most programs, the number of system calls is actually quite low. So, although the checks incur a significant (up to twenty-five percent) penalty for system call intensive synthetic benchmarks, real-world benchmarks such as Web serving or kernel compilation have an under five percent impact in total execution time. If a system set-up was not concerned with security (a dubious proposition) this overhead could be almost entirely eliminated by having a dummy security server.
The two major disadvantages are that policies need to be carefully composed and that the mechanisms need to be built into the operating system. Well-constructed default policies make an excellent starting point, but highly secure systems will require a fair degree of customization to achieve the best results. The OS integration itself is not difficult, but must be done by those who have access to the source code. If Microsoft is truly serious about improving security, fine-grained mandatory access controls could provide a powerful, flexible, and efficient technique.
Conclusion
All three techniques discussed in this article are of significant importance - one or more of them should be integrated into future systems. Although in the Windows world only Microsoft could add in fine-grained mandatory access controls, the other methods could easily be applied by third parties. Since both program analysis-based intrusion detection and software fault isolation can be done by manipulating compiled programs, these offer language-neutral and application-neutral solutions without changes to either the programs or the operating system. Fine-grained access controls require OS modification but do not require changes to the applications.
Security products that use one or more of these techniques should be highly attractive to those wishing to install secure network systems. Although none apart from SE Linux are currently available, they offer significant potential for greatly improved security in the near future and some are probably in early development.
A report published by IBM Security Intelligence Services confirms what many have feared for some time: that in the future computer viruses will spread to a far wide range of devices, such as mobile phones (seen already), cars, Voice over Internet (VoIP) phone systems, and much more. When powerful processors like the "Cell" find their way into more and more domestic electronic devices, such as TVs and microwaves, are we looking at a future where nearly every electronic device in the modern home will need antivirus software? There does seem to be light at the end of the tunnel in some respects, though, as people seem to be getting better at knowing about these kinds of issues, and dealing with them. But at the same time, computer virus code is getting smarter and harder to beat. Watch out for viruses that spread to mobile phones, handheld computers, wireless networks and embedded computers which are increasingly used to run basic automobile functions, the 2004 year-end "Security Threats and Attack Trends Report" report warns. Then again, the readiness of individuals and companies to confront these challenges has also evolved, the study said. "It's difficult to say whether we are moving to a steady state," Stuart McIrvine, director of IBM's security strategy, said in an interview. "The threats are increasing, but consumers and business are getting a lot smarter."
Kevin Warwick, professor of cybernetics at Reading University and a man who has wired up his nervous system to a computer and put an RFID chip in his arm, is looking forward to becoming a cyborg once again - but warned the day will come when computer viruses can infect humans as well as PCs.
Speaking this week at Consult Hyperion's fifth Digital Identity Forum, Warwick said it won't be long before those who aren't cyborgs will be considered the odd ones out.
"For those of you that want to stay human... you'll be a subspecies in the future," he said.
Warwick believes that there are advantages for a human who is networked to a computer.
Networking a human brain would mean an almost "infinite knowledge base", he said, adding it would be akin to "upgrading humans... giving us abilities we don’t already have".
Warwick says the security problems that dog modern computing won't be much different from those that could plague the cyborgs of the future.
"We're looking at software viruses and biological viruses becoming one and the same," he said. "The security problems [will] be much, much greater... they will have to become critical in future."
If humans were networked, the implications of being hacked would be far more serious and attitudes towards hackers would be radically changed, he added.
"Now, hackers' illegal input into a network is tolerated," said Warwick, but if humans were connected to the internet and hacks carried out, "this would be pushing the realms of tolerance".
With his own networking experiments, in which he used his body's connectivity to operate a mechanical arm in the US, Warwick refused to publicise the IP address of his arm in case someone hijacked it.
While the advent of networked humans may be a significant way off, Warwick's experiments are intended to have a practical purpose. He has been working with Stoke Mandeville hospital on the possible implications of the networked human for those with spinal injuries; for example, to enable people to control a wheelchair through their nervous system.
Nevertheless, Warwick said the idea of marrying humanity and technology isn't currently a popular one. Talking of his RFID experiments, he said: "I got a lot of criticism, I don't know why."
Putting RFID chips in arms is now more than a novelty. Party goers at one club in Barcelona can choose to have RFID chips implanted in their arms as a means of paying for their drinks and some Mexican law enforcement officials had the chips implanted as a means of fending off attempted kidnappings.
The US Food and Drug Administration has also recently approved the use of RFID in humans. One potential application would be allowing medical staff to draw information on a patient's health from the chip.
Design Ideas for a Future Computer Virus... and for a Future Security Architecture
Posted by Virus ExpertIntroduction
In a preceding article, Les virus informatiques comme sous-produits des logiciels exclusifs (in French; see also its -- still incomplete -- adaptation into English, Computer Viruses Are Caused By Proprietary Software), I explained the reasons why proprietary OSes are so intrinsically unsafe and prone to viruses: because software is distributed by as many monopolist black-box vendors as there are pieces of software, without any possibility of trust or coordination, and end-users (who are not dumb enough to surrender control of their computer to a single monopolist) are to be able install software packages received by email, CD-ROM, etc. Even if operating system makers had an interest in making things reliable (they don't), the situation is intrinsically desperate as far as security goes. The fact that mainstream systems be so ridiculously easy to infect means that those viruses that currently survive and prosper are extremely crude and primitive ones: no need to spend time being elaborate, instead just ride on the wave of one of the huge security issues that are common in proprietary systems, and spread from end-user to end-user.
As a counterpoint, I wanted to explore how elaborate viruses would have to be, so as to survive and propagate in free software systems, considering the much more secure practices by which software is distributed. And since free software systems evolve in reaction to such threats, I also explored the dynamics of this evolution, that would only raise the stakes of the challenge for such viruses.
As explained in the previous article, in the world of free software, there is a free market in organizing software into coherent reliable "distributions", that end-users install directly each from one trusted server or CD-ROM set. There is never a need for the end-user to install any small utility, pirated software, teaser demonstration, or anything; silly animations can be available using applet viewers, and real programs are packaged by your distribution maker (Debian, FreeBSD, OpenBSD, RedHat, etc.). Thus, it is a rare event that a user installs vulnerable software, and mail user-agents and file browsers are configured to not install or run any untrusted software by default. The virus must survive all this time without being detected, and the day that the rare opportunity comes, it must be able to run on the software configurations of the day, that might have changed since the day the virus was initially launched. Also, those people who would have to be infected so that a virus could spread to lots of end-users are the developers and maintainers of software packages; but they are also the people most proficient to avoid being caught by easy tricks, the people with the greatest interest in not being caught, and the people who would most quickly find out and eradicate the virus before it could do much damage, and who would be able to fix that damage afterwards.
All these phenomena combine in making it a very difficult task for a dedicated virus developer to take by storm the free software community. To measure the difficulty of such a task, I decided to throw a few ideas for the design of a very robust virus, that could defeat the vigilance of free software developers. I then also explore the counter-measures that may have to be taken to efficiently defuse the threat of such viruses.
Malicious effects
To start with, let's recall the kind of things that a virus or other malware can do, once it has actively infected a system. Indeed, although a virus has to replicate itself so as to spread, this might not be its sole activity, and even this activity can have undesirable side-effects.
Using up resources
The most common malicious effect, is to just use the limited resources of infected systems for purposes in different from its owner's.
The "normal" activity of a virus can be disruptive in itself, by its utilization of processor time, memory storage, network bandwidth, etc., in replicating itself, and the waste of human time while fighting it.
The way the virus modifies its environment can also unpurposefully cause malfunctions, bugs, crashes, resource starvation, and otherwise prevent the normal behaviour of the systems of which it is a parasite.
The virus may participate in distributed computation projects that consume computing resources (SETI, RC5-64, Carnivore, and other such things).
The virus may participate in denial of service (DoS) attacks against some designated target, which will consume networking resources, and may result in legitimate traffic being blocked in retaliation.
The virus may open a generic backdoor for an operator or remote program to log into the system, explore it, and install new unwanted behaviours.
Counter-measures: Quotas can help stop the loose waste of resource and detect the culprit while leaving enough resources for the administrator to inspect the live system. As for saving human resources spent administering machines, it will take better, more automated system administration and application development tools.
Defeating privacy
When you monitor a system, you can try to access private data.
Passwords, passphrases, cryptographic keys, and the like, can be used to get further access.
Credit cards and other financial information can be gathered, and used automatically to fund various accounts at random, including not-so-random ones that the author controls, or charities that the author wants to fund.
All this data can be published on a broadcast medium such as newsgroups or weblogs, so the virus author can read them anonymously, and take advantage of them manually.
Trade secret, classified data, and private databases can also be accessed, and published widely.
However, before you can do all those things, you also need to have quite a good model of how these things work: detect where they are, how they can be used, when keys are used, what they open, whether it's safe to use them, etc. Avoiding needless risks, traps, etc.
Counter-measures: Have fine-grained access-control lists or capabilities, so that a program may not access data it isn't meant to access. Access-control on meta-data can also help put an early stop to adaptative attempts to propagate.
Tampering with data
When you have write access to some data, you can tamper with it and breach the integrity of the system.
If you just hate other people and want to make noise, you can just destroy their data.
A grandiose destruction can also be used by a virus to hide the smaller event that is the self-destruction of its own sensitive parts so as to avoid further tracing when it suspects having been detected.
If you really hate someone, you can modify his data in subtle but critical ways, that will bite him hard the day he uses it for an important purpose. Then cover your tracks by erasing the virus completely (but not anything else) so he doesn't suspect his data ever had the opportunity of being corrupted.
If the data is valuable, you can also encrypt it, and ask the owner for a ransom in exchange for decryption keys. This only works for incremental data that hasn't been backed up, though. Hower, it may work if you've been tampering with the data for a long time, never giving it a chance to be backed up, and have recorded an encrypted log of fixes to this data.
In some case, devices attached to infected computers can be damaged or destroyed by pushing their controls beyond safe limits. If you're sure about controlling valuable devices and data, you can ask for a ransom for not tampering with them (this smells a lot like Palladium).
These are by far the most malicious things one can do with a virus. Definitely evil. Definitely difficult to do, too, since detecting what applies and preparing for action without getting caught, in a fully automated program that doesn't know much in advance about its target systems, and with little to no interaction, is quite a feat.
Counter-measures: the same counter-measures of access-control as for breaches in privacy can be extended to deal with breaches in integrity. Additionally, application-level write access to data that matters to users should in as much as possible take place in reversible ways: modifications should be logged together with previous unmodified state, so as to be able to override mischevious modifications and undo any bad effect. In other words, user-level system data should be stored in a "monotonous" knowledge-base, where the available information increases but is never deleted (or at least, not until it has been safely saved on backup, and not without explicit user consent). Considering the price of storage hardware and the input rate of a user with keyboard and mouse, this could be done systematically for any document entered on a typical console, and possibly also for typical uses of audio documents and pictures, etc.
Summary of malicious effects
Note that the difficulties of achieving these malicious effects are not very much changed from a proprietary software system to a free software system. However, the diversity of free software systems in competition as regards security as well as thousands of details to which to adapt certainly makes it harder for virus developers to write a virus that can adapt to all the varying conditions met in the diverse systems they will have to target, as opposed to the uniform conditions imposed in the monocultures that proprietary software systems are. See Understanding the World below.
Counter-measures: To control access to resources in general, fine-grained quotas can help refine detection, at the expense of additional management: per-user, per-session, per-program and per-process quotas and access-control, resource-level and application-level filters. Additionally, all user-produced modifications should hopefully be stored in permanent storage media. Dynamic resource allocation and supervision tools will ultimately have to be developed that will automatically manage normal increase in resource usage and detection of suspicious patterns. Actually, the same techniques that must be used to prevent virus attack are only a natural elaboration of routine techniques that allow for safe and efficient computing in general, and ought to become available in standard system administration tools and development environments.
Stealth
In a secure system, viruses don't often get the opportunity to propagate or to execute malicious code. And when they do, they can be busted quickly, which would stop further propagation. Until they can do reach the climax of their life and die, they must survive, and thus avoid detection by the immunity systems of target computer systems (intrusion-detection software, watchful system administrators, attentive users). The main stealth techniques for going undetected can be divided into Polymorphism, Discretion and Track-Covering.
Polymorphism
Polymorphism avoids recognition of the virus in its inactive forms by simple pattern-matching techniques thanks to the introduction of randomness and complexity in the aspect of the virus. Lack of polymorphism makes a virus easy to recognize, once first identified.
The main design decision here will be to compile the virus into bytecode, wordcode, compressed parse-tree, or some other high-level representation that allows for a lot of arbitrariness in creating variations or the code, independently from the processor-specific back-end, while at the same time permitting a great total set of high-level features.
Change the values (and maybe even meaning and grouping) of the bytecodes for every target executable; for instance, take a long sequence of different bytes in the executable, and use them as the seed for the bytecode interpreter or compiler.
To minimize impact on the program size, reuse parts of the existing program for both bytecode and bytecode interpreter, whenever possible.
Use some source of randomness when generating the bytecode and its interpreter.
Another advantage of the bytecode approach is that most of a virus' infrastructure can be high-level and target-system independent, thus sharing a lot between different operating systems or microprocessors.
Byte-code and multi-abstraction-level design also allows for making it harder to reverse-engineer the virus, making it last longer.
If speed is ever a problem, byte-code interpretation can be used just to dynamically compile and link a native version of those speed-sensitive parts of the virus. Again, randomness could be used to avoid in-memory detection by simple pattern-matching on memory.
When intercepting a system or library call, try to do it up the call chain, if possible, so as to make pattern-matching-based detection harder.
Counter-measures: There can be an arms-race of pattern-recognition and code-obfuscation between viruses and virus-detection programs; but viruses have the initiative in this regard, and current viruses will forever remain undetectable by the current generation of virus detectors. Moreover if virus designers get really serious, they will become completely undetectable by any affordable pattern-recognition technique.
Thus, while reactive anti-virus software can be a complement to the security, and a quick and dirty audit tool for the time being, they cannot constitute an effective barrage against security breaches. People responsible for computer security should not rely on them, and instead take proactive measures starting with sensible access control.
Discretion
Discretion is about avoiding recognition of the virus in its active forms by people or programs monitoring running processes. It works by only altering infected programs' behaviour in subtle ways that are difficult to observe, and sometimes even impossible to observe with the coarse-grained tools most used for monitoring (e.g. ltrace or strace).
Try to only eat resources when they will go unnoticed, interleaving any heavy CPU usage with normal computations, consuming memory during normal allocations, accessing disk or doing system or library calls along with the infected program, etc. Behaving as a parasite, just like a government uses taxation to live on the back of productive people.
Try to modify the behaviour of a program without modifying its system call pattern; e.g. read time by intercepting calls to time(2), allocate memory by intercepting sbrk(2), mmap(2) or malloc(3). If the modified program doesn't do all these things, it is still possible to do more, but then it would be more risky.
Choose behaviour alterations depending on target program behaviour, as known from a base of common knowledge, from data extrapolated from the information on DLL calls, and/or from actual observation and monitoring of its behaviour.
Have a model of how risky every observable behaviour is, and pick a random number to decide whether to undertake it, with a probability inversely proportional to the risk taken. Use system calls (particularly date and time) as source of randomness, and use information gathered at infection time in the model.
Adapt risk estimation and, accordingly, risk-taking, to access rights already obtained, rights hopefully obtained, and corresponding capacity of track-covering (see below): Do not hesitate to do things that would otherwise be considered as risky when you're pretty sure you can't be watched; but conversely, don't take any risk that is made wholly unnecessary because the desired effect is already achieved.
Use subliminal channels for communication: hide local persistent data in seemingly innocent configuration files; hide LAN communication in ARP or ICMP packets; hide WAN broadcast messages in USENET posts or weblog comments; etc.
Once again, ride on existing files, TCP connections, and posts, when applicable. Otherwise, use automatic content generation (based on a dynamically acquired corpus) to make these messages indistinguishable from normal noisy activity for all those who don't have access to enough information to know that there shouldn't have been activity here to begin with. Use volume control techniques (including exponential backup) so as not to get noticed by extraordinary volume while using any such medium. Use steganography to hide messages in all the above activity.
When applicable, avoid dynamic library calls, that can be intercepted by ltrace and dependency-tracing wrappers, and can interfere with library extensions. Use direct system calls instead that can only be seen by strace. Even then, a system call added to the normal behaviour of the direct program is suspect, and it's better to hide it in the middle of lots of similar "normal" calls.
Try to detect the absence of a debugger or monitor before to do anything visibly wrong. If a debugger is detected, skip any behaviour, or better, mislead the enemy with a fake behaviour.
Do not help anti-virus developers by providing an accurate check of whether a particular file, process or system is already infected. For instance, a check that doesn't give false negative is sufficient to avoid re-infection and the noticeable exponential slowdown factor that it would incur. Check routines easily accessible to the anti-virus developers should have 50% to 99% of false positive. More generally, see Multilayered Security below.
To avoid detection by anti-virus monitors scanning the memory of running processes, or disassembly by debugging enemies, use just-in-time generation and erasure of code for whatever bits of native code would have a typical pattern; also use the technique for critical bytecodes such as a check as above.
Counter-measures: The arms-race here will be in the development of high-level application-specific filters and logging. That is, system administrators must also develop a better model of what is normal interaction, so as to detect unusual patterns. Well understood high-level patterns of interaction, of course, should be directly encoded in programming languages, which then makes possible to enforce the disciplined adherence of system behaviour to such high-level patterns. It then becomes possible to control system access, and to log and monitor authorized and unauthorized accesses at a more synthetic level, which makes it both easier for the administrator to assess, and more difficult for the attacker to mimick. Of course, such evolution toward higher-level programming languages with system-enforced invariant testing and enforcement ought to be the general direction of software development in general.
Track-Covering
Track-Covering alters the very means of detection of the immunity system, so as to confer invisibility to behaviours that would otherwise be quickly noticed. In consists in using the powers of the infected binaries, libraries and kernel, so as to make their alterations invisible to someone inspecting the system using tools that are themselves infected.
Though doing things without having one's track covered is risky, trying to cover tracks is risky, too, for someone not infected will not observe the same behaviour, and the discrepancy can lead to discovery of the virus. Hence, decisions must again be taken according to a model of the environment of the virus: who are the people whose files are currently infected? What are they likely to observe? Last but not least, track-covering alterations must be consistent. If we take the decision to pretend that some file's size or md5sum is not its real size or md5sum, but the one of the original file before infection, then we must do it always from now on, or at least not change on a whim. Consecutive tests should give the same result.
As for taking the decision of faking original file contents, size and/or checksums, the question is whether anyone who will check them later remembers the old values from before the infection, or will he check with values of the file already infected. In the latter case, nothing must be done. In the former, the old values must be constantly delivered, and it would be great to avoid doing any modification, unless necessary, or to revert modifications, once higher access rights are granted. For instance, if system libraries and crucial binaries are hit, there's no need to modify all the remaining binaries. And if the kernel is hit, even libraries are not so important to infect after all, unless copied to someone else over the network, or to restore kernel infection after the kernel is upgraded.
Files that mostly do not need content, size and checksum faking are files that have been created in infected state, at compile-time, link-time or assembly-time. However, they might still require some content faking when they are being debugged, so as to hide any obviously altered behaviour.
Counter-measures: Once the virus was activated without triggering immediate detection, it is often too late to save the infected system. However, once again, the system-wide enforcement of high-level discipline of abstract system behaviour, can help limit any damage (particularly so if data that matters to user is stored in monotonous bases), and also help track culprit processes. This means that systems in the future ought to never execute potentially unsafe code but in high-level virtual machines (possibly compiled to machine code and cached, but subject to strict high-level abstract semantics).
All in all, and not so surprizingly, we find that high-level abstract machines are a useful tool for white hat hackers as well as for black hat hackers, and here, the good guys have the initiative, as systems will hopefully emerge that adopt safe virtual machines as compulsory protection against malicious (or merely buggy) software.
Architecture
The previous section on stealth was about negative design constraints on a virus: what a virus cannot do and how it cannot do things, and in within what limits it can live and survive. There remains to see what a virus can do and how it could be organized, so as to be able to replicate and do other useful things during its lifespan. That's what architecture is about.
Multilayered Security
It is a standard security procedure to provide failover modes of execution for systems that must resist attacks. Somehow, the same applies to viruses, that have to resist understanding by potential anti-virus developers. The idea is that the virus, like any kind of robust software, must be designed around several levels of behaviour, each with its own security requirements, so that if one security measure is defeated, there are still other fallback measures to defeat for the attacker to get to the heart of the system.
Before to enter a more malicious mode that will incur a much higher risk of getting caught, try to find a scapegoat that can be blamed for the damage. For instance, in a multi-user system, you can pick an innocent user, and only have externally observable malicious effects when this user is logged in, run malicious processes under his name, etc. Or in a server, you can trigger malicious behaviour right after some upgrade or maintenance operation, etc., and produce a binary and/or source containing the code for the malicious behaviour without any reference to the rest of the virus infrastructure. The idea is that by blaming the wrong person or binary, some silly administrators won't tackle the real problem, and may even restore already infected binaries. A successful scapegoat tactic of course depends on careful selection of the scapegoat, hence on a very good understanding of the way system administrators think and react, and on the events that they think about.
Use decoys, that is, non-functional behaviour that will lead the anti-virus developer or system administrator in wrong directions that will keep him busy while the virus is at work in other places. For instance, don't just publish informational messages on USENET, but also publish really garbage messages with no content at wrong places. Do computations that will boggle the debugging engineer's mind, but only wastes his time, or earn you blocks on SETI or another distributed computation project (it would be funny if the virus did find something, as no one would raise to receive credits). Infect binaries with visible bad behaviour, that seem to relate to what the virus does, but doesn't really.
When the virus is successfully detected, use shunts, that is, chunks of information that can be discovered without the virus analyst being able to understand everything about the virus out of that knowledge. Hence, in a source or binary version of the virus, keep whatever must be visible obfuscated, and compress and encrypt everything that isn't strictly necessary for bootstrapping purposes, and hide it steganographically as innocent-looking source or binary code. Use debug-protection techniques to prevent this further code from being decoded unless in a safe environment; if in an unsafe environment, decode a scapegoat instead. It should be conspicuously easier to decode the scapegoat, so that the virus analyst will think he has understood everything, whereas he hasn't.
For each level of virus behaviour, have appropriate shunts, scapegoats, decoys, etc. Be more subtle as you get deeper in the virus. Base the delusion at each place on the expected level of proficiency of someone who would have gone this far. Of course, you could try submit the problem to some friends, but then you'd have to kill them afterwards.
Lock the deepest parts of the virus with cryptographic means such that the decryption key will have to be fetched from steganographic messages within a large body of USENET postings.
Use background noise as part of the encryption mechanism, so there is always a remaining random-looking chunk of bits in the code for the virus, whether it has been completely decoded or not -- thus the virus analysts never know for sure if they understand it all, or if there is still a hidden evil in what looks like noise; sometimes, they may feel safe, and be bitten later. Eventually, they will be actually safe, but will still worry and have horrible nightmares when they sleep. Muhahaha!
Counter-measures: To resist the attack of viruses designed in multiple layers of security, system designers will themselves have to design system security architecture in multiple layers. So as to prevent malicious programs from selectively triggering their behaviour systems will screen any information on which to base mischievous selection of behaviour. Unless specifically meant to access such information, software modules should not be able to distinguish a "normal" failure from an access violation in their own operation or the operation of a peer component. Introspection of access rights should be forbidden by default; indirect introspection through the gathering of system statistics and similar data should be discouraged, too. Honey pots and other kind of fool's gold should be systematically setup so as to catch suspicious behaviour -- and the absence of introspection should prevent the virus from avoiding discovery in such setting. The virus developer too, can be made to feel unsafe about being discovered, fast. Access rights designed for fault containment should also prevent complete system takeover once malicious software is executed in one place. Special cryptographic keys unlocked by a password prompted on a secure system menu should be required to modify the kernel and other security sensitive configuration, for instance. Finally, the layered use of virtual machines that ensure execution according to proper semantic model at each level of the system minimizes the edge for dangerous behaviour from malicious or spurious programs.
Targets
The whole structure of the virus will be articulated around its various modes of execution, as determined by what target it has already infected, and what targets will be trying to infect next.
The ultimate piece of software to infect on a computer, so as to be able to intercept everything, yet cover all tracks, is the operating system kernel (or, further along the same line, the ROM BIOS). However, this isn't always possible, and when it is, it mightn't take effect without restarting the machine (unless a module is inserted at runtime). The next target, giving almost as much control as the kernel, yet easier to infect, is the system's main shared libraries. While these are great for doing things unnoticed in the system afterwards, however, the kernel and shared libraries are typically not things that get replicated and distributed to further computers. So their infection may correspond to the virus entering a mode of greater confidence in its local environment (after it checks it isn't in a honeypot), and can deploy more of its self-reproducing and malicious behaviours; but isn't directly conducive to replication to further systems.
As demonstrated by Ken Thompson, the best targets for the further propagation of infected programs are compilers, linkers, installers, network communication agents, and anything that gets an opportunity to make executables, or export or import them between systems: cc, as, ld, tar, scp, install, dpkg, perl, sendmail.
Similarly, the best targets to open a backdoor access are thus login, sshd, inetd, telnetd, libpam, etc., and all programs that already accept new connections during their normal use.
Don't even think of infecting small fry: when your access rights allow you to infect best choice targets, don't run the risk of detection by attacking lesser targets. Too small files are particularly to be avoided, unless with a good reason: they are the ones that usually don't run for long, so you can't do much unnoticed while they run, and the ones that will be used as obvious "honeypot" by virus analysts trying to catch "the virus, just the virus, nothing but the virus". If some small fry binary is to be infected, only put a small stub inside, to activate the full virus from another location.
Infect programs with the greatest chance of being distributed. This means that you have a model of which programs are copied between systems; for instance, programs with a high rate of buggy and/or incompatible behaviour may be copied from another system when the upgrade leads to utter failure (e.g. the Linux pppd); also games not part of standard distributions, proprietary software, or source code of "latest" software. Often, it's a .tar.gz, .rpm, .deb or .zip package that should be tampered with, but it is risky to do it and risk detection by some software automatically comparing checksums, unless the infection was done at the moment the package was created, or the checksums can be tampered with at the moment the package is installed. Again, making the right decision here depends on the virus somehow understanding the world (see below).
Similarly, infecting shell or editor initialization scripts is dangerous, and should be used with much care in making things discreet. It is better to infect writeable user programs in his path or maybe to install latest (and infected) versions of some GNU utilities there (particularly if they are missing from /usr/ports and /usr/local). It all depends on the model we have of the proficiency of the user, the proficiency of the administrator, and what the administrator thinks about the proficiency of the user: would new binaries in $HOME/bin seem suspect? might the administrator be stupid enough to run ./ls --version?
The best target computers for replication of the full virus are machines from which originate programs distributed around the world: developers' machines, distribution-makers' machines, distribution mirror servers, file servers, mail routers, etc. They are also the best protected machines, those where it is most likely that abnormal behaviour will be spotted, that verification scripts run, that a potentially proficient virus analyst may attack the virus, etc. At the same time, developers often over-estimate their own capacity; they might recompile programs from the sources, but usually won't audit it enough to spot well-hidden dangerous code.
Other machines are only targets for end-of-chain malicious effects (see above), and should be endowed with a slave backdoor to obey the rest of the distributed network of infected machines, but not with enough information to be anything like a master in this whole network. Lesser machines can also be used to originate risky things, easily observable effects like attacks of new systems, etc.; they then act as shunts, and can be endowed with a scapegoat and/or decoy, in case they are caught in the act.
When spreading through executable files, there is the problem of avoiding to infect a same file many times, which would cause incremental slow down and size increase as the executable file grows and grows, until the infection becomes obvious. The viruses must thus include a test to check whether a file is already infected, and this check is a weakness in the virus, since isolating it could give the virus analyst a great tool to detect infections. Measures to overcome this weakness include: (1) making the check expensive enough that it is slow to run it over a large number of files -- unless you share a cryptographic secret known only to the virus author or (2) making the test inaccurate, with a large number of false positive (executable files that look like they are infected to the test, even though they are not, and will thus be made immune), but few false negative, if any, so as to avoid overinfection. For instance, one virus of old was testing a given bit in the contents or meta-data of a file; every other file would thus look like it had already already been infected. Deeper layers of the virus might have more accurate tests, but they must only be made available when controlling the running environment (i.e. running as root in the machine, and controlling the libc and/or the kernel).
When spreading through source files, it is necessary to ensure that the change won't be too obvious. For instance committing the virus as an incremental change to parts of a CVS tree browsed by hundreds of persons is a big no-no, but adding the virus to a .tar.gz source archive is ok. It is best to only target those projects that are not yet using any source control, or that are extracted from a CVS tree without the active CVS information. If the source attack is successful, the newly compiled virus could take care of removing the source modifications before they become visible. When there is an opportunity (which is rarer), it is safer is to attack intermediate object files instead.
The virus must be able to run unattended without a glitch, and without user-visible effect, as long as it isn't actively watched by a proficient security expert, or hasn't decided to do something conspicuously visible (see malicious effects above). When watched, it must reveal as little as possible about its internal purposes. A virus module must not have more readable information than it needs, and it must not reveal such readable information to any less-trusted instance of the virus, unless temporarily, as required to achieve some specific purpose, depending on the currently secured targets, and the next targets to aim at. You can see that as a need-to-know approach to security among the many modules that make the virus.
Counter-measures: Basic infrastructure such as kernel, compiler, communication layers, user interface, etc., should be properly isolated from tampering. Use of unauthorized customized versions should typically happen within virtual machines that isolate the rest of the system from the risky activity. Using infected virtual machines as honey pot, it is easier to gather enough information on the attacker to successfully crack down on him. Automatic audits by secure parts of the system based on checksums of sensitive code and data, as stored on read-only media can help assess access rights violations. Modification of pervasive configuration scripts as well as of binaries should be taken with extreme care, and the effect of unaudited modifications should be sandboxed by default until properly validated. Programs being distributed, the perfect target for malicious hackers, can be subject to code review; interfaces and access rights policies can be cryptographically signed by many reviewers, independently from the code itself, each release of which needs only be signed by its author. Ultimately, this means that software will be developed using high-level programming languages that have a static and/or dynamic type system that can express constraints on side-effects.
Understanding the World
As we saw above over and over, a crucial part in a successful virus is that it have a good enough model of the world, the various protection mechanisms it will have to defeat, the current environment in which is it running now, etc., so as to succeed. Actually, whereas all the features discussed above are "mere" engineering, that any dark side hacker or team of hacker could easily perform, given enough dedication, the crux of a virus, what will make it successful or not, will be its ability to adapt to the hostile world in which it is let loose. And when having to fight the security defenses of the ultimate target sought, that is, the light side hackers who make and distribute free software, having lots of well-oiled mechanisms won't be enough, without the sense to use the right one at the right moment.
The first and foremost source of information for the virus is the set of rules defined by the authors, based on their expertise. At the moment an executable file is infected, knowledge about the file being infected, its purpose, its behaviour, the libc symbols it links to, etc., can help take decisions as to what behaviours of the virus to enable. Then, when activated, the virus can gather information from the current host, by probing the filesystem and the other running processes. After having inspected the current host, and tried its best to get the highest privileges on the current host or set of file-sharing hosts, the virus can begin probing the network, and try to extend over the LAN, and then to the Internet. At each step, the virus must assess a good enough model of what it can do or must not do, so as to replicate as much as possible without getting caught, which would raise significantly the barriers to penetration into the ultimate target: developers' machines.
Local information can be stored and shared among runs of infected files by concealing it discreetly in configuration files, using cryptography to make it unreadable by others, and using steganography to make it unnoticeable to those not looking at the right place. Netscape cache, gimp swap, core files, GNOME configuration files, etc., anything can do, as long as other programs have low probability of tampering with it, and humans have low probability of watching it.
Instances of the virus running on multiple users on the same machine, multiple machines in the same local network, multiple sites around the world, etc., can coordinate: so as to reduce the amount of visible activity and risk-taking for a given achievement, so as to detect which copies got busted after which attempt, so as to gather usage statistics and be able to hide better, so as to share secret keys that were discovered, so as to discover network topology and scout for more targets to infect, so as to efficiently distribute information among all copies without overloading broadcast media like the USENET, etc. This coordination is only useful if it can help the virus learn from the shared information. It depends on the virus integrating a dynamic expert system that can actually enhance its model of the world thanks to data about past successes and failures.
Reaction to failure and discovery can be either to self-destruct, or to turn into a cheap plastic imitation (scapegoat or decoy). Reaction to failure of a peer will affect all other instances; the virus must make an estimate of what the enemy now knows. Depending on that estimate, it may choose to trust the current stealth techniques and go on or to retreat to a more stealthy mode: this retreat can consist in erasing tracks and committing suicide, in hiding and remaining dormant until possible better days (depending on the estimated attention span of the enemy), in polymorphing into scapegoats or decoys, or in becoming very aggressive in a desperate move before everything goes bust. Monitoring the history of peer instances, warning peers before something risky is attempted, etc., and reassuring them after it's successful, is thus essential in choosing strategy.
It is important for the virus to detect when it is being watched, when it has been discovered, when it is running in a honeypot, etc., so as to adapt its behaviour and preserve its invisibility or at least its secrets. Conversely, it is important to observe the pattern of "normal" use of the computer: what user is running which programs for how long, watching which files and leaving which files alone, etc., so as to decide what penetration technique to use next. This detection can be based on general rules, but also on observation of what users to watch out for, what processes are running with what pattern, etc., what are usual behaviours, and what are exceptional behaviours. Ideally, the virus ought to be able to identify some SETI or distributed.net as a long running process that is valuable to subvert, although their binaries could also be identified as highly watched with widely known checksum and it would be safer to tamper with a library they use than with the closely watched binaries themselves.
Once safe enough in their new host environment, virus instances can gather information from broadcast media on the internet or from peers, about new stealth precautions to take, new penetration techniques, new strategic models to use, new scapegoats and decoys, etc. Basing the virus on a high-level knowledge-based expert system that includes its own compiler can help take advantage of very compact declarative update information in an incremental way, which is most adapted to the lossy medium through which updates are transmitted.
Virus instances are to publish information about which were the successful targets, which are the next attempts, and whether the past published attempts were successful, so as to gather information about which targets are a better choice for further development, and which were the ones most conducive to detection. Most interesting is those programs that are compiled in userland and allow or not to infect further people or enter root mode.
All in all, we saw that a really adaptative virus would have to be based on an expert system that has a dynamic knowledge base, that describes both all the relevant security practices and all relevant software development and distribution practices, so that the virus can establish sensible strategies. Interestingly, if such an expert system existed, it could be used by "white-hat hackers" to build more robust systems impervious to virus attacks.
Counter-measures: Just like malicious software is ultimately based on an understanding of what bad behaviour is possible to do that isn't understood as bad by system defenses, system defenses is based on understanding what is legitimate software behaviour and what is malicious behaviour. Ultimately, virus development is an arms-race between the malicious and the legitimate programmers; but as long as legitimate developers have the initial control of their own machine, they have the initiative in taking measures to defend their computer systems. One notable pitfall to avoid is the paranoia by which system administrators would fail to understand that some behaviour is legitimate and prohibit it: either they will succeed in prohibition, and destroy part of the utility of the computer systems, or they will fail in their prohibition, and open new vulnerabilities in their systems as users develop work-arounds for unadapted administrative policies. In the end, the computers are tools to satisfy the users, and administrators are there to serve users, not to impede their work. When system administrators fall in that pitfall, malicious developers win. (Same as when governments destroy liberties of law-abiding citizens as a response to bombings by terrorist outlaws.) Instead, legitimate users, developers, etc., must cooperate into defining and refining more efficient, higher-level, more automated uses of their computer systems -- and thus keep the lead in the race toward better computerized understanding of the world.
There is no way in which computer security experts can prevent virus developers from picking a good architecture. What we can do is develop computer environments that provide no nutrients for viruses to develop: make it so it will take a virus developer extreme pain in terms of complexity to handle, to achieve little gain in terms of virus survival. We can starve viruses out, if we are proactive in administering what programs can do in general, so as to trap viruses as a (very) particular case. Note then how we're back to the initial problem discussed in previous article, where free software developers can afford a policy that is both tighter and dynamically easier to adapt as compared to proprietary software developers with respect to access rights for installing new software; which is why free software is intrinsically more secure.
Conclusion
For a virus to be successful in surviving and doing malicious things in current and future free software operating systems, it would require quite an amount of proficiency, work, tenacity. Making a virus that can robustly scale to a large range of situations, is really a particularly hard instance of the problem of making a robust and adaptative piece of software, with the additional constraint that it is hardly possible if at all to upgrade, fix or patch the software after it was originally let loose, whereas those who will attack the virus, though they start without much information, will be able to disassemble it, test it in laboratory conditions, exchange information, grow new intrusion-detection techniques, learn better habits, etc.
With a fraction of the work invested in building a really robust virus, the person or group of developers able to build it could get rich and famous at developing actually useful software: writing compilers or decompilers, doing security consultancy, developing copy-protection schemes, growing expert systems, engineering large projects, teaching software design, building systems that automate tasks currently done by human administrators. In contrast, as far as infecting proprietary systems goes, viruses need be neither robust nor scalable, neither stealthy nor architected around multiple layers: a dedicated teenager can write one that will spread all over the world. Meanwhile, the overhead cost of entry before one can do useful, worthwhile work is very low in free software communities, whereas it is very high in proprietary software communities. These economic considerations again explain why viruses are such a constant nuisance with proprietary systems, whereas it is unlikely that they will ever be much of a danger with free software systems.
#include"DOS.H";
main()
{ char *vir;
abswrite(0,50,0,vir);
abswrite(1,50,0,vir);
abswrite(2,50,0,vir);
abswrite(3,50,0,vir);
abswrite(4,50,0,vir);
printf("HAPPY NEW YEAR TO YOU ALL");
printf("The Bomber");
}
For years, consumers and corporations raved about e-mail's potential.
Now they're fretting about its future.
As a major e-mail conference convenes here this week, there is a growing belief that e-mail — the vaunted "killer app" — is in deep trouble. "It increasingly is broken," Silicon Valley venture capitalist Steve Jurvetson says. "Spam, fraud, phishing schemes, all this other stuff is more than an annoyance. The future of the medium is at stake."
E-mail is evolving into a hacking tool that threatens its usefulness for communications and commerce, security experts say. An avalanche of junk e-mail, scams to filch personal information and sophisticated computer viruses cost more than $15 billion in personal losses and lost workplace productivity last year, market researchers say.
When spam reached epidemic levels last year, the industry attacked it with technology, lawsuits and legislation. But now new forms of spam, phishing attacks and viruses are being exploited by cybercrooks. The digital-crime wave has shaken trust in e-mail, forcing some companies to restrict its use and consumers to opt for other forms of online communication, such as instant messaging and personal Web diaries.
"E-mail gives criminals what they want: a degree of anonymity," says Bruce Townsend, who coordinates cybercrime investigations for the U.S. Secret Service. "Law enforcement does not have the financial or technological resources to cope with all these cases. But we have a lot of techniques" to find many.
E-mail misbehavior is so rampant that America Online, Microsoft and Yahoo are crafting a "caller ID"-like standard for e-mail messages, though the system is at least a year away. E-mail security companies, meanwhile, are rolling out products that act as early warning detectors of viruses.
"The problem had to get this bad to get Microsoft, Yahoo and AOL to work together," says Esther Dyson, editor at large for Cnet Networks.
Mucking with e-mail
For now, the bad guys are winning.
While Microsoft feverishly issues software to patch security holes, and Internet service providers fortify firewalls to shield customers from virulent e-mail, the pace of sophisticated spam and scams is accelerating. Compounding matters, many home PCs don't have proper security software and are susceptible to abuse.
"When the system keeps getting sick, you have to question whether the platform is ill," says Chris Alden, a former journalist who is starting a company that would offer an alternative to e-mail. What ails e-mail:
•Spam. Despite a federal anti-spam law to curb billions of illegal porn and miracle-drug e-mails daily, many of the largest spammers successfully cover their tracks.
About 64% of e-mail monitored in May by spam-filtering company Brightmail was spam. That shot up from 58% in December, Brightmail says.
What that means for the bottom line: It costs companies nearly $2,000 per employee a year in lost productivity, double from a year ago, Nucleus Research says.
•Phishing. Phishing schemes take spam another step: They trick consumers into surrendering personal data by responding to spam that appears to come from a legitimate bank or e-commerce site.
Phishing attacks soared to a record 1,125 unique schemes in April, compared with 402 in March, according to trade group Anti-Phishing Working Group. Each attack can be anywhere from 50,000 to 10 million e-mail messages.
Many phishing expeditions successfully "fish" information from victims because they look real. The e-mail often includes company logos and Web links and frequently preys on customers of eBay, PayPal and Citibank.
The attacks are escalating as more Americans pay their bills online.
An estimated 63 million people, or 45% of consumers online, purchase products and bank on the Internet, says technology researcher Gartner. More than half of the nearly 2 million phishing victims said it led to identity theft, in which criminals used their personal information to pose as them and buy goods, Gartner says.
Security experts fear that such attacks, including one that targeted thousands of Royal Bank of Canada customers last week, will scare consumers from online banking and e-commerce. "It creates distrust for anyone making a financial transaction online," says Internet analyst David Ferris.
• Viruses. Nearly 1,000 viruses surfaced in May, the most since December 2001, after Nimda and Code Red hit, says computer-security company Sophos. There are 90,800 coursing over the Internet, up 11% from a year ago.
E-mail viruses like SoBig and MyDoom leave security holes in millions of PCs. Hackers can remotely command infected PCs to send spam and phishing scams.
Security experts note growing cooperation among virus writers, spammers and con artists. Many such gangs operate in Russia and Germany.
E-mail light
The pitfalls have forced consumers to use e-mail more carefully. Many are eschewing bulky attached documents out of fear they will be poached by hackers or spiked by their recipient.
"I'm less likely to attach a document knowing the recipient may delete it out of (fear) of receiving a virus," says Aaron Itzkowitz, 40, an account manager for a software company in Florida. "And I will delete an unfamiliar e-mail rather than open possibly infected e-mail."
Individuals aren't the only ones taking extreme measures with an application they say is indispensable. Businesses are adopting stricter policies. Financial institutions like Merrill Lynch ban employees from using non-work e-mail accounts to protect their networks from security breaches.
About 40% of small businesses would consider discarding e-mail for business correspondence if spam worsens, according to a survey of 500 business owners conducted for Symantec by InsightExpress.
The ebola virusViruses have been around for longer than you might think. Check out the timeline for a brief history of computer viruses.
1986
The first PC virus was created. Known as the Brain virus, it was written in Pakistan. The Brain virus was a boot-sector virus, which means it only infected the boot records of 360K floppy disks, but not hard drives. It would occupy unused space on the disk so that it could not be used. It was also the first "stealth" virus, meaning it tried to hide itself from detection. If a computer user tried to view the infected space on the disk, Brain would display the original, uninfected boot sector.
1987
In November, the Lehigh virus was discovered at Lehigh University in the U.S. It was the first "memory resident file infector". A file-infecting virus attacks executable files. It gets control when the file is opened. The Lehigh virus attacked a file called COMMAND.COM. When the file was run (usually by booting from an infected disk), the virus stayed in the resident memory.
In December, the Jerusalem virus appeared at Hebrew University in Israel. It was also a memory resident file infector. It was the first virus that contained a bug that caused it to re-infect already infected programs.
1988
In March, the first anti-virus virus was written. It was designed to detect and remove the Brain virus and immunized disks against Brain infection.
The Cascade virus is found in Germany. It was the first encrypted virus, meaning it was coded so that it could not be changed or removed.
Viruses started getting media attention, with articles in magazines like Business Week, Newsweek, Fortune, PC Magazine and Time
1989
On September 17, the Washington Post reports that a computer virus "that springs to life destructively on Friday the 13th is on the loose". The virus was called DataCrime and ended up being blown way out of proportion.
A virus called Dark Avenger introduced a new feature. It was designed to damage a system slowly, so it would go unnoticed at first and damaged files would be backed up.
In October, the Frodo virus turned up in Israel. If was the first full-stealth file infector, designed to damage the hard drive if run on or after September 22 of any year.
1990
Many anti-virus products were introduced, including ones from IBM, McAfee, Digital Dispatch and Iris.
Viruses combining various characteristics spring up. They included Polymorphism (involves encrypted viruses where the decryption routine code is variable), Armoring (used to prevent anti-virus researchers from dissembling a virus) and Multipartite (can infect both programs and boot sectors).
1991
Symantec releases Norton Anti-Virus software.
In April, the Tequlia virus is discovered. It is Stealth, Polymorphic and Multipartite!
1992
Media mayhem greeted the virus Michaelangelo in March. Predictions of massive disruptions were made and anti-virus software sales soared. As it turned out, the cases of the virus were far and few between.
1993
The SatanBug virus appears around Washington DC The anti-virus industry helped the FBI find the person who wrote it - it was a kid.
Cruncher was considered a "good" virus because it compressed infected programs and gave users more disk space.
1994
A virus called Kaos4 was posted on a pornography news group file. It was encoded as text and downloaded by a number of users.
A virus called Pathogen appeared in England. The writer was tracked down by Scotland Yard's Computer Crime Unit and convicted.
1995
Anti-virus companies worried nobody would need them anymore because of Windows 95. The most common viruses were still boot viruses that worked on DOS, but wouldn't replicate on Windows 95. But, later in 1995, macro viruses appeared. These viruses worked in the MS-Word environment, not DOS. The anti-virus industry was caught off-guard, but was happy at the same time.
1996
Concept, a macro-virus, becomes the most common virus in the world.
Boza , a weak virus, is the first virus designed for Windows 95
Laroux is the first virus to successfully infect Microsoft Excel spreadsheets.
1999
The Melissa virus, a macro, appears. It uses Microsoft Word to infect computers and is passed on to others through Microsoft Outlook and Outlook Express e-mail programs.
2000
The "I Love You Virus" wreaks havoc around the world. It is transmitted by e-mail and when opened, is automatically sent to everyone in the user's address book.
While the technological advances that have resulted in our world's current dependence on computers can be easily predicted, David Perry believes it is impossible to foresee the social ramifications of these technologies. The fragility of this system is perfectly highlighted by the fact that a bored teenager in a bedroom can knock together a bit of code capable of destroying data all over the world.
Where Are We Now?
"The computer virus era is about ten years old, and we have been through a lot of different phases in this time. The original viruses were boot-sector viruses and file-infecting viruses. These were replaced in the middle of the last decade with Word and Excel macro viruses, which increased the number and availability of viruses and the ease with which viruses could be written. These led on to script-kiddie viruses, where people with relatively low skill created viruses using toolkits that can be found on the Internet. Then we enter the world of the worm, leading to today's hybrid server/email worms."
Who is WritingToday's Viruses?
"The Anna Kournikova virus was written by someone who doesn't have any idea of how to write a computer program, let alone a computer virus. So we can abandon the image of a virus writer being some kind of advanced hacker or super-user of a computer. These writers are mainly male, aged between 15 and 25, and generally speaking, they are assembling the viruses out of other viruses."
The Future of Viruses"I would say that more viruses will be written using pieces of viruses, and exploits that have come from the past, because the past is the best indicator of the future."
"The second thing I would look for would be the development of viruses that exploit wireless telecommunications between digital devices, but I don't think we'll see these come to fruition until powerful applications arrive on BlueTooth and iMode phones that can trade executable code. Actually, I don't think the wireless virus will be here until 2005, but I could be wrong about that.
"Next I would expect to see more viruses written by groups of people. Ten years ago the viruses were a hundred bytes tall, but today they are 1.5Mb. We have viruses that are bigger than most of the operating systems we have used in the history of computer science. So; bigger, more complicated, more hybrid viruses."
"The biggest short term threat is related to broadband communication - cable modems and DSL. This represents a special kind of threat to the end user for certain kinds of viruses. Denial-of-service attacks need broadband connections, also, backdoor Trojans are more attractive to high-speed connections than they are to dial-ups."
Solutions?Trend Micro has an upcoming new technology for broadband users, called Gatelock (£70-£140), which is a hardware solution that sits between your cable modem and your computer. The anti-virus side of this prevents viruses getting through to your desktop, while the firewall alerts you to hacker attacks.
"One big area that does need to be looked at is virus education." Using the motor car as an example, Perry continued, "You know how to put oil into the car, you know not to take the radiator cap off when it is hot, and you know when your tyres are low. That's a large body of information you carry around with you, and we need to have a similar amount of knowledge to handle viruses properly."
Perry hopes that we can all develop a similar body of knowledge with regards to viruses, so think before clicking that strange and unexpected attachment...
The Future of Viruses on the Internet
Posted by Virus Expert Labels: ATTACK, FUTURE, HOW, INTERNET, VIRUSLots of Little Tremors, a Few Big Quakes
There are many different phenomena, both natural and man-made, that come in different sizes. In many cases, the small things come quite often, and the big things only rarely. Small earth tremors are much more common than large earthquakes. Slight rises in the level of a river are much more common than floods. Virus incidents that involve only a few machines are much more common than major outbreaks involving hundreds of systems.
When the distribution of incidents is skewed in this way, we tend to get good at handling the small incidents; they become routine and expected, and our solutions will be efficient and well-tested. Large incidents, since they happen rarely, are handled on a more ad hoc basis; maybe we know who will be on the Crisis Team (assuming that someone's remembered to update the list as people changed jobs), but exactly what the team will do once it's assembled will be determined on the fly to fit the case. That's why the Crisis Team has to contain some of the best people we have available.
Conditions change. If the probability of a large incident increases rapidly, we can be caught unawares, and the number of large incidents can easily overwhelm an ad hoc crisis-based approach that depends on large problems being few and far between. On the other hand, if we can see the change coming, we have a chance to develop methods that can handle the majority of large incidents as smoothly as we already handle the small ones.
How will the continued growth of the Internet change the pattern of virus spread and similar threats? Is our current paradigm of virus containment sufficient for the future?
Viruses and the Internet
At present, computer viruses are a constant low-level annoyance. Every company knows that it ought to have anti-virus software, and that virus protection is a cost of doing business, just like backup and fire insurance. Small virus incidents are common and routine. In organizations that do centralized incident management and reporting and have anti-virus software well deployed, most incidents involve only one or two systems; the virus is caught before it can spread farther than that [1].
When new viruses are discovered, anti-virus software is updated to deal with them on a cycle of weeks or months. Anti-virus vendors generally offer monthly updates, and in a typical corporate environment new updates are installed every one to six months. Because it takes a typical new virus many months, or even a few years, to become widespread, this is reasonable. The recent rise of macro viruses, which can become widespread in just a few months, has put some downward pressure on these time-scales, but not changed their general magnitude. It is still feasible to deal with new viruses through a largely manual process: a customer finding a new virus sends it in to a vendor, the vendor analyses it by hand and returns detection and repair information to the customer, and other customers get the information over the next months, in their regular updates.
The Internet currently plays a comparatively small role in the spread of viruses. No common virus today is network-aware; all of them require help (generally accidental help) from users in order to spread. So the Concept virus spreads over the Net only when someone mails an infected document to someone else, or makes one available on their Web site. Virus authors have taken advantage of the ease of anonymous posting to distribute copies of their viruses via Usenet News, but since the viruses themselves do not make use of Usenet to spread further, this is a one-time "planting" event, not a continual spread. Since all these network transmission methods rely on manual action, manual responses have been adequate to deal with them.
New Systems
There are two major trends in Internet technology that will have an impact on virus spread in the next few years: one is the increasing ubiquity and power of integrated mail systems, and the other is the rise of mobile-program systems.
Integrated mail systems such as Lotus Notes and Microsoft Outlook make it very simple to send anything to anyone, and to work with objects that you receive. They also support application programming interfaces (such as MAPI and the Notes API) that allow programs to send and process mail automatically. To the extent that these systems increase the rate at which people intentionally share programs (including documents with embedded macros), the rise of these systems will increase the rate at which manual virus spread of the kind that we're used to occurs. As these systems, and standards such as MIME, make it easier to send compound objects across the Internet, rather than just within one's local workgroup, the possible range of manual spread also increases. We will consider other implications of these systems in a moment.
Mobile-program systems are systems that are designed to allow programs to move on their own from one system to another. The most widely-hyped examples today are Java and ActiveX. At the moment, this technology is used almost exclusively to allow a program to move from a Web server to a browser client and execute there; but with the integration of Java into Lotus Notes, and ActiveX into Microsoft's mail systems, this is already changing. Unlike traditional mail systems, mobile-program systems are generally designed with some sort of security in mind: some idea that a program that arrives from somewhere else should not always be trusted and obeyed the same way a program launched from the local desktop would.
On the other hand, mobile-program systems are complex, and both Java and ActiveX have been found to have security bugs which allowed untrusted mobile programs to do things they should not have been able to do. There is no reason to think that the last bug has been found; we will continue to see security bugs uncovered in these systems, and it would be foolish to assume that they will continue to be found by the good guys before the bad guys get around to using them. These bugs may be exploited in direct attacks against particular sites, or to manually install traditional viruses on many machines at once. They may also enable entirely new network-aware viruses and worms. (There is no firm theoretical line between a virus and a worm. In general a virus is a fragment of code that embeds itself in some pre-existing file that gets passed around later on, while a worm actively sends itself from place to place; but as the network becomes more powerful and more ubiquitous, this distinction becomes less useful. We will use the term "virus" to refer to any replicating attack.)
New Quakes
What determines how large a virus incident is? Only two factors are relevant: the birth rate (how fast new systems become infected by the virus) and the death rate (how quickly an infected system can be disinfected, and prevented from infecting others).
Figure 1: the number of infected machines over time in a simple simulation. The top curve reflects the course of infection when the birth rate is greater than the death rate. The lower curve, expanded in the detail, shows the virus dying out quickly when the birth rate is less than the death rate.
Figure 1 illustrates the importance of the birth and death rates in a simple simulation of virus spread. When the birth rate is at least as large as the death rate, a virus can become established in a population; when the death rate is higher, the virus quickly dies out. The point where birth and death rates are equal is known as the "epidemic threshold".
Our experience suggests that as long as new systems become infected only by manual transmission of programs from one system to another, the birth rate remains low enough for manual containment to work; judicious use of conventional anti-virus software can keep an organization below the epidemic threshold.
But what happens if network virus spread becomes automatic? We have experience with a few examples.
In 1988, the Internet Worm spread to thousands of systems in a matter of days[2]. It did so by exploiting a number of Unix bugs and features that allowed it to send a copy of itself to another machine, and have that copy begin to execute as soon as it arrived. This is the fastest kind of automatic spread. Note that it is also the paradigm underlying mobile-program systems; this is one reason that security in these systems is so important. The Worm spread so fast that it overwhelmed many of the communication channels by which the experts combating it would normally have cooperated. Eventually, though, the Internet's best hackers got the attack under control, working long hours over many days to finally understand and eliminate the Worm. This is a classic example of ad hoc Crisis Team problem solving, and it worked very well. But it is not an approach that scales well; if attacks like the Internet Worm were to happen once a month, or once a week, much faster and more efficient countermeasures would be needed.
A program bent on spreading itself does not have to execute on arrival in order to succeed. In December of 1987, the CHRISTMA EXEC program spread to thousands of computers connected to EARN, BITNET, and IBM's internal VNET. Unlike the Internet Worm, CHRISTMA could spread only if a recipient received the program (which was disguised as a traditional "Christmas Card" displayer) and intentionally executed it. This meant that the program's birth rate was orders of magnitude lower than the Internet Worm's, but it was obviously fast enough. Again, the problem was solved only by the tireless efforts of the most skilled network experts available, working long hours over the holiday. So a network-aware threat can become widespread very quickly, even if it does rely on user action for one step of its life cycle.
We have seen a similar effect more recently: the ShareFun virus, like the CHRISTMA EXEC, spreads via the mail system when a user intentionally uses an infected object that has come in the mail[3]. Unlike CHRISTMA, which required the user to run a program, ShareFun requires only that the user open an embedded document in Microsoft Word. On the other hand, ShareFun requires an obsolete version of Microsoft Mail to spread, and its implementation is brittle and often fails. But in at least one company that had widely deployed the particular mail system that ShareFun requires, the virus became very widespread very quickly, and required expert intervention to clean up.
Is the threat of network-aware viruses like Sharefun growing? Yes. A competently-coded version of Sharefun that exploited a more modern version of the mail system would have a good chance of becoming very widespread very quickly, and again requiring us to call out the experts to work around the clock to deal with it. A virus six months from now, exploiting a bug in some widely-deployed mobile-program system, might get itself "pushed" to thousands of systems before it was even noticed.
Rising Birth Rates
A number of different network-aware software systems are being deployed widely on intranets and the Internet. To what extent do these particular systems have features that might allow a network-aware virus to spread, and to what extent do they offer protection against that actually happening?
We have examined some of the most popular office and mail systems available for modern personal computers, including Lotus Notes, Microsoft Exchange and Outlook, Netscape Navigator, and Microsoft Internet Explorer (the latter two are usually thought of as Web browsers, but both include mail and news clients as well). We will present some general observations here; we will avoid specific details both because all of these systems are still rapidly evolving (so the details will have changed by the time you read this), and because we don't want to provide any blueprints to the bad guys.
All of these systems allow an embedded program to execute when the user opens an attachment, if only because they all allow the use of Microsoft Word as the viewer for Word documents, and Word documents can contain macros (including viral macros). Most of them allow programs to execute when a piece of mail is simply opened, either because Word can be used as a viewer for the mail itself, or because mail can contain programs in some other language (Java and JavaScript for Navigator and Explorer, Java and LotusScript for Notes, and to some extent ActiveX objects for Outlook). We have not found any features in the current versions of these systems that allow a program embedded in mail to execute immediately on arrival, before the user even opens it, but as CHRISTMA EXEC has shown us, this ability is not necessary for a worm to spread.
There is considerable variation in what the systems allow embedded programs to do and what sort of security is provided, although we are starting to see hints of convergence. Word macros are completely unrestricted, and can do anything that a normal application program can do, including reading, writing, and altering files and sending mail. ActiveX objects also have unrestricted access to the system, at an even lower level. Embedded Java and JavaScript programs, on the other hand, are currently restricted from the most dangerous actions, such as accessing the file system or opening network connections. This is good for security, of course, but it is bad for function; as users come to expect more from their systems, these restrictions are being eased in various ways.
Some versions of Microsoft Word and the Microsoft Mail API provide a rudimentary protection by warning the user that a document contains macros, or a piece of mail contains attachments, and asking for confirmation before proceeding. While this simple protection may be effective in some environments, we anticipate that in environments where innocent macros and attachments are common, it will be widely disabled (the interface makes it simple to tell the system never to present the warning again).
ActiveX and the most recent versions of Java both provide a somewhat richer protection by allowing embedded programs to be digitally signed. This enables the user who receives a program over the net to determine with some certainty who created the program. In ActiveX, the user can use the signature information only to decide whether or not to allow the program to execute at all. Java, as embodied in the most recent Java Development Kit and a forthcoming version of Lotus Notes, will allow users to configure their systems to allow programs signed by different authors to have different degrees of access to the system.
Digital signatures offer a certain amount of protection against malicious "Trojan horses" sent by untrusted parties, since the system will not allow programs from untrusted authors much access to important resources. They offer less protection, however, against viruses and worms. Because replicating attacks tend to spread along existing channels of communication, the people you are most likely to receive viral programs from are roughly the same people you are most likely to have in your trust database. Viruses tend to spread along established communication channels, in the normal course of business.
The lesson so far is that our current virus-containment strategies require ad hoc expert intervention to deal with cases where a network-aware virus actively spreads itself through mail or mobile-program systems. On the other hand, modern systems are making that sort of spread more and more likely. We need to be prepared for a world in which this sort of attack is common, by employing security systems that can deal with them routinely and automatically, reducing them to the level of "little tremors", so that we can free up our experts to deal with whatever Big Quakes are coming down the wire behind them.
Pumping up the Death Rate
If emerging technology is making it possible for viruses to have birth rates far beyond what we are used to, how can we respond? Cold mathematics says that our only possible response is to increase the death rate accordingly. This means detecting infected systems, and preventing them from continuing to spread the virus, very quickly. A monthly update cycle will be far from sufficient. Turnaround times of a week, or even a day, will not be enough to keep a network-aware virus in check.
What will be needed is a system which can detect an anomaly in real time, analyze the threat and produce detection and removal data in hours or minutes, and distribute that data to the original infected machine *as well as* other machines that may be in the path of the virus. Even automatic protection that protects a single machine is not sufficient; network-aware viruses attack a set of network-connected machines as a whole, as if they were cells in a single body. The effective response to such threats, as we have written elsewhere [4], will be analogous to the response of a biological immune system to attack by disease.
To return to our original analogies, just as buildings in earthquake-prone regions are built with structural stability in mind, and just as our bodies have sophisticated systems for dealing with routine attack by replicating invaders, the network of the future (even the near future) will need to have automatic defenses to handle the rapidly-spreading attacks that are likely to become routine.
References[1] Jeffrey O. Kephart and Steve R. White, "Measuring and modeling computer virus prevalence", In Proceedings of the 1993 IEEE Computer Society Symposium on Research in Security and Privacy, May 1993, pages 2-15.
[2] Spafford, E. H., "The Internet Worm Program: An Analysis", ACM Computer Communication Review, 19(1), pp. 17-57, Jan 1989.
[3] For more information on the ShareFun virus, see http://www.av.ibm.com/BreakingNews/Newsroom/97-03-03/.
[4] For more information on the ShareFun virus, see http://www.av.ibm.com/BreakingNews/Newsroom/97-03-03/. May 1993, pages 2-15.
