Manage Learn to apply best practices and optimize your operations.

Predicting the future of malware and tomorrow's malicious code

The future of malware will grow exponentially. David Harley presents his predictions on blended threats, e-mail exploits, social engineering and more.

This article can also be found in the Premium Editorial Download: Information Security magazine: Special report: Cyber menace:

I may seem to be ignoring Daniel Delbert McCracken's advice not to make predictions about computing that can be checked in my lifetime. I'm not as crazy as all that: I haven't completely migrated from Moore's Law to Old Moore's Almanac. However, based on today's trends, I'll venture some educated (if somewhat reluctant) guesses about the immediate future of malicious code.

Authors of malware generally aren't the moody, inscrutable genies or geniuses of popular imagination, and they have to work with the same application, OS and hardware limitations that we do. Technical details change. Epidemiological patterns change. But the broad issues remain constant.

Recently, AV vendors have made a big deal out of "blended" or "convergent" threats. In the wake of Code Red and Nimda, blended threats remain everybody's pick as the most likely malware threat for the coming year. However, as bad as these were, it should be noted that the author of Code Red didn't invent the IIS exploit used in the attack. And for everyone's talk about Nimda being a "new" type of attack, it's actually a direct descendent of the 1988 Morris worm. Like Nimda, Morris exploited a number of vulnerabilities, arguably to even more dramatic effect. It's a shorter step than some would have us believe from the "file-and-boot" multipartite viruses to the multipolar worm. But I'm getting ahead of myself.

In general, the malware author has to exploit one of three broad classes of vulnerability: software, "liveware" or hybrid. Some threats -- self-launching worms and embedded scripts, for instance -- are software-only: they require no human activity beyond, perhaps, incautious configuration. Some threats -- many Trojan horses, e-mail worms and so on -- achieve their aims by psychologically manipulating the victim (liveware) into running unsafe code. Other threats employ a mixture of these techniques -- for instance, when a user is tricked into turning off protective measures. I'll discuss examples of each of these types and hazard a guess or two about the future directions they may take.

Software-Only Exploits

Malware that exploits only software comprises a small, but significant group. Examples include Code Red (but not its successors), KaK and BubbleBoy. Other threats fully rely on bugs and weaknesses in legitimate software, such as overflows and arbitrary execution of code in an inappropriate context.

Susceptibility to input buffer overflows -- such as those to which unpatched versions of IIS are vulnerable -- has been big news in recent months. Indeed, vulnerabilities in Web services might have been the most bruited issue of 2001. Recent attacks on IIS included not only Code Red's single-point attack and Nimda's multivector mode of replication, but also attempts by Linux and Solaris worms to take advantage of vulnerabilities on remote machines.

The susceptibility of remote systems to exploitation by nonnative programs isn't new. A computer vandal may try to escalate his access privileges on a remote system using Telnet or FTP by methods that don't depend on the application's platform. Distributed denial-of-service (DDoS) attacks are by no means reliant upon the target and victim systems sharing a common operating system.

One thing that has changed, however, is that the distinction between servers and client machines has become more blurred as server and workstation OSes have converged to allow multiple processes and connections. Thus, when Code Red and its siblings cut swathes through corporate networks, it wasn't only heavyweight IIS servers that broadcast probes, but desktop and laptop machines, too.

Since the server and workstation versions of modern OSes often run the same versions of exactly the same applications and utilities, they tend to share the same vulnerabilities. It seems likely, then, that we'll see two continuing trends. First, desktops and laptops running the same services as heavyweight servers will in many instances be affected by malware in the same way. This risk is exacerbated by the fact that the user of a client machine may not be as scrupulous as sysadmins about access control. Second, servers running Windows OSes will be more vulnerable to malware currently associated with desktops. We've already seen the effects of this convergence: viruses that use poorly configured network shares as an entry point.

Other overflow problems -- e.g., format string and heap overflows -- continue to present problems with nonviral attacks. That said, there's no reason why they couldn't be one of the bases of a viral attack. A virus or worm is, after all, only a program with the particular quality of replication: its attack points and incidental functionality can be whatever its author chooses.

A related but different type of vulnerability is represented by allowing code to be executed arbitrarily and inappropriately. A dramatic (and still frequently seen) example is JS/Kak, which takes advantage of a bug in earlier/unpatched versions of IE/Outlook, allowing two ActiveX controls to run at a level of trust. The scriptlet.typelib and Eyedog vulnerabilities have been known and patchable for several years, but are by no means the only way of forcing the execution of untrusted code without the end user's knowledge.

Recent postings on NTBugtraq and elsewhere have demonstrated how the Windows Media Player can be used to bypass Outlook 2002 security settings to execute JavaScript and ActiveX code embedded in HTML mail. Ideas and exploits published on such lists often lead directly to attempts to implement them in the "real" world. Attacks that bypass the need to trick victims into launching them are particularly attractive to black hats, as are any exploits that don't have to be carried in an identifiable (and therefore filterable) file. It's reasonable to expect that the bad guys will continue to try to exploit known (and hitherto unknown) vulnerabilities that bypass generic filtering methods.

Another trend we've seen in the last year involves viruses that (intentionally or otherwise) take advantage of poor handling of MIME boundaries or uuencode headers, allowing client software to execute code inappropriately when it masquerades as a "safe" data type.

Attachments, Social Engineering and IM

Malicious programs have one characteristic in common (apart from malicious intent): They're all programs, and there's no way a program can have its intended direct effect unless it's executed.

Note the use of the term "direct effect." It's certainly possible for software that isn't executed or even "real" to have an indirect effect. For instance, a dummy burglar alarm can be as effective a deterrent as the real thing, and a virus hoax can cause more of a nuisance than a real virus. There are a number of programs that live in the twilight zone between Trojans and joke programs: Web scripts that pop up a fake virus alert, or programs that pretend to be trashing a victim's system, for instance.

Hopefully, most people wouldn't execute a program that arrived with a message saying, "Virus enclosed. Please click here to infect." Probably not many more would click on an attachment that has no explanatory message. Worms with no significant message have been known to creep into the wild, but nowadays people are usually a little more suspicious of e-mail attachments -- especially when they're from complete strangers. We should not, however, forget that some virus authors have made use of spam-like spoofing of e-mail headers, not only to direct leaked data to fixed e-mail addresses from which they may be harvested later, but in some cases to hide the identity of the victim in whose name it was dispatched, so that they can't be warned.

To persuade the victim to step into the trap, the malware author has to find a "hook" to catch the victim's interest. By far the most popular social engineering technique today is to "validate" infected mail by making it appear to originate from an infected system belonging to a previous victim. Secondary (potential) victims become exposed to the virus code in the form of e-mail addresses in the Outlook Address Book or in a cached Web page. In other words, the writer attempts to make the mail look genuine by making a very weak tie appear like a strong personal link, using a message general enough to catch the attention of a high proportion of potential victims.

Some virus writers have shown a surprising aptitude for psychological manipulation. LoveLetter's mechanism, by which the worm is passed off as a love letter, is a good example. Subsequent versions included a fake invoice (who wouldn't want to check a bill for unrecognized services?) and even an "antivirus program."

E-mail is not the only natural habitat for social engineers, however. In the immediate future, attachments will be less popular with virus writers as organizations block more and more attachments at the gateway. At the same time, malware authors are trying to circumvent such filtering by using increasingly obscure file types, or by packaging common executable types inside zip files.

Meanwhile, the number of attacks on users of Internet Relay Chat (IRC) and instant messaging (IM) continues to rise. These attacks consist of attempts to trick the unwary into downloading and executing automated agent software that allows remote systems to use target systems as attack platforms for DDoS attacks against other systems, or as a target for backdoors and Trojans).

We've also seen a rise in attacks coming through home users and small businesses. Such attacks are still predominantly viral, but it's likely that other threats, such as orchestrated DDoS attacks, will increasingly come via this route, especially as DSL and cable modem connections become more common, and entry-level operating environments become more sophisticated.

Hybrid Exploits

It's increasingly rare for a virus to rely purely on software exploits or on social engineering. It's far more common for them to be based on combinations of the two. However, the current catchphrase "blended threat" also applies to combination threats. We've already seen worms that drop parasitic viruses (file viruses), destructive Trojans, password stealers, backdoors, RATs (remote access Trojans) and even rootkits (Trojanized applications that replace legitimate system tools). We'll certainly see more variations on the convergence theme, and further blurring of the distinctions between worms, viruses and Trojans.

It's also likely that we'll see more attempts at multiplatform attacks, though probably not so much in terms of fat binaries that work on any number of incompatible platforms. More likely are single-platform threats (including threats that work on several Windows flavors) with payloads that impact other platforms: Windows-originated worms that use Apache exploits, for instance, or Linux worms that drop .exe Trojans. It's reasonable to assume that any platform in wide use will attract at least low-spread proof-of-concept malware.

It's also likely we'll see more worms and viruses that use spam techniques -- not only the exploitation of unprotected mail relays to maximize spread, but the sort of verbal hook that is intended to persuade the recipient to explore further. Indeed, one clear trend is the continued use of social engineering to trick victims into opening malicious files. As filtering by file type and policy-based solutions are adopted by the rest of the corporate world -- and perhaps at the ISP level -- exploits based on e-mail-embedded scripts, fileless network probes and other attachment-free techniques will be sought and used where possible.

But these are easy guesses, based on constantly recurring patterns and the assumption that malware authors will continue to combine known attacks with new exploits. Somewhere down the line lurks the "Next Big Thing," the next WM/Concept, the next Code Red, the next Nimda, the hitherto unexploited technical vulnerability that we haven't thought of yet. In fact, AV researchers quite often spend time on closed mailing lists discussing "nightmare scenarios," and it's quite possible that the Next Big Thing has already been identified, but not discussed publicly. Whether this will be enough to attenuate its impact is beyond the scope of my crystal ball. However, past experience suggests that it can take quite a while for AV vendors to make major changes to their methodology to counter new, left-field threats.

About the Author: David Harley manages the U.K.'s NHS Information Authority's Threat Assessment Centre, and is the national virus management technical lead within the NHS. He also is coauthor of Viruses Revealed (Osborne/ McGraw-Hill, 2001).

This was last published in May 2002

Dig Deeper on Malware, virus, Trojan and spyware protection and removal

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close