In March 2001, a worm (a harmful computer program) known as Magistr augured a new era of vicious attacks on computers. Unlike LoveLetter or Anna Kournikova, which clogged e-mail servers, Magistr is truly malicious. After sitting dormant for a month on the infected PC, the worm then destroys data files and attacks the CMOS (which boots up the PC).
While this harmful program failed to have the widespread impact of LoveLetter or Anna Kournikova, it suggests that virus-writers are becoming more willing to put truly malicious code into the wild. But even the damage done by these two malware programs, which was relatively easy to fix, is not something companies can afford to suffer regularly. Finding a way to defend against such attacks is essential to business continuity and profitability. What can companies do?
Today, most companies use traditional anti-virus software, which is signature-based, meaning that it defends against known signatures (specific programs). But such software is always a step behind the latest virus mutation, as the victims of each new variant learn when they are hit before they get the latest update from their anti-virus vendors. Given that even the slightest variation in an existing program will allow it to slip past this type of virus-detection defense, companies can't afford to rely solely on this reactive approach anymore.
The following overview looks first at how malicious software (or malware) works. It then explores the potential of three preventive approaches to the problem: sandboxes, heuristics, and blocking tools.
What malware is. Malicious code is often referred to as a virus, but variants may actually fit the definition of other categories of malware, such as a worm, which is a script. With some worms, the recipient does not have to run a file to be infected. While viruses and worms are technically different, anti-virus software detects both. (Most of the malware threatening companies today is more like a worm and that term is used throughout this article somewhat interchangeably with malware.)
Among the factors affecting the ease with which worms, also known as vandals, spread today are the code in which they are written, the toolboxes, the modular design, the HTML code embedding, and the spying functions.
Worm code. Today's worms are usually written in Visual Basic Script (VBS--a programming language for Web applications from Microsoft) and Visual Basic for Applications (VBA--a simple programming language embedded into many Microsoft applications). VBS worms, such as Anna Kournikova and LoveLetter, are often transmitted through e-mail. VBA worms, such as Melissa, conceal themselves in macros. (Macros are a series of instructions designed to simplify repetitive tasks within Microsoft Office applications; they execute when the relevant file is opened).
VBS and VBA are so simple that anybody with a little computer knowledge can introduce a slight change in the vandal source code, which is freely visible, and effectively create a completely new vandal. In addition, virus writers can easily convert from VBS to VBA, and vice versa.
Toolboxes. As mentioned, VBS and VBA scripts are relatively easy to write. But novices no longer need to master even that skill. Sophisticated hackers have created and distributed toolboxes, or virus generators, for novice malware programmers that simplify the task of writing a malicious and fast-spreading vandal in both VBS and VBA. Writers merely make the changes they want--for example, which exploit to use, what message to display, what to do to the infected computer, and so on. And each modified version of the code becomes a new variant, undetectable to anti-virus software until it is encountered and a new defense is written and distributed to end users.
The Anna Kournikova vandal was created with such a toolkit. A toolkit also allows the output script to be encrypted and offers a configurable payload (meaning the creator can select what damage the program will do). With a simple toolbox modification, vandals can take advantage of every possible hole in a company's Internet-enabled applications, move through unprotected shared folders on the local area network, and even automatically download the latest and greatest payload configuration from the Internet.
Modular design. What allows more advanced vandals to be modified by a single keystroke is the modular design that has been incorporated into the toolkits. While writing malware in VBS or VBA is easy, it still requires some computer knowledge. But the toolkits contain already-written VBS or VBA code components prepared in modules that can be assembled by anyone. This modular design allows vandals to be developed quickly and easily.
When these features are applied in advanced Trojan toolkits, they could allow the attacker to remotely add or remove new vandal capabilities. The hacker could even remove the vandal altogether so that all traces are eradicated and the victim will never know that its system has been compromised.
Modular design means that for some malicious code there could he dozens of variants, depending on the specific modules incorporated. The notorious SubSeven remote-control Trojan horse, for example, offers at least nine different modules and a software developer's kit that allows even more modules to be mixed and matched. It is important to note that these modules are all a part of the SubSeven distribution, not a result of recompiling the source code. All the hacker has to do is select the desired modules, system activation method, and means of notification and control (that could, for example, notify the hacker via ICQ--a popular Internet messaging program--whenever a victim is online), and a new version will be created in a packed and encrypted "ready to use" file.
Because even the activation method can be customized, traditional anti-virus scanning is less likely to detect such vandals. Traditional anti-virus products, therefore, revert to the solution of analyzing every new sample and distributing an appropriate update. This is not a high-quality solution. "One-time" variants can take weeks and even months to discover.
Furthermore, toolkits that include the complete source code of the vandal, such as BackOrifice 2000, allow even beginning hackers (known as script kiddies) to produce endless variants and easily create one-time code for attacks on specific targets. These toolkits are probably used for industrial and other types of espionage and pose a great challenge for traditional, reactive anti-virus tools.
HTML Another lesser known, but equally sinister, vandal technique is to embed VBS inside e-mail formatted in hypertext markup language (HTML). Because almost every e-mail client today uses HTML to compose and read e-mail, an embedded script can be extremely dangerous. The danger arises because, to activate the malicious script, a user does not have to execute an attached file. The script will automatically run as soon as the e-mail is opened, or even if it's simply viewed in the preview pane. The user will be infected immediately without any indication. Deleting the e-mail will not help. Few anti-virus products are designed to deal with scripts embedded inside e-mail HTML.
This technique is relatively rare because it is not as well known by script kiddies and because no toolkits are currently available. To date, most such vandals are created to attack specific targets and do not use mass-mailing methods. An exception is a vandal named KAK, an HTML-embedded script that uses an unusual and effective method of infection. KAK adds itself to e-mail messages as a signature- e-mail signatures are normally a few lines of text that can be automatically added to the footer of every e-mail and normally contain the name, title, and other details about the sender. KAK adds a malicious script as the default signature to every e-mail, and since script code is invisible to the user, it will not be noticed by either the sender or the recipients.
Though a VBS worm cannot be embedded in HTML using a toolbox, it is relatively simple nonetheless. A virus writer can simply view the HTML coding using Microsoft Outlook Express and paste the script into that code. The composed e-mail can appear very innocent and look like lines of plain text because the script code is hidden, but it will self-execute when the e-mail arrives.
Spying tools. Not only is malicious code becoming easier to propagate, but the code is also carrying more harmful payloads. Most dangerous among these are so-called spying tools. Once installed on the infected system, these tools allow attackers to do virtually anything a legitimate user can do, such as access information, retrieve cached passwords, type messages on the screen, delete files, and even view a PC Webcam.
Spying tools, also known as remote-control agents, are typically contained in a Trojan disguise. They trick a user into executing them by disguising themselves as jokes, utilities, or pictures. But unlike other malware, spying tools do not spread to everyone in the address book. If they do spread, they do it selectively so as not to raise suspicion.
The most significant feature of spying tools is their ability to remain unnoticed: they can reside on a PC for long periods of time (the average is about two or three months, but some have been known to stay put for a year or two). Two of the most notorious examples of malware with this type of payload are SubSeven and BackOrifice, both of which harbor "remote management" spying capabilities that allow a hacker full access to the compromised computer system.
Another difference between spying software and other malicious code is that the latter typically has a specific payload that can be determined after some examination--it sends itself to names in address books, deletes files, or shows a message, for example. With spying software, however, there is no way to tell what was done or what will be done. Instead, experts can only say what the capabilities, which can be virtually limitless, are. The reason for this is that, unlike other forms of malicious code, these tools are designed for two-way communication between the hacker and the compromised system, so the hacker can select what to do at will.
Numerous organizations have been hit by such spying tools. Perhaps the most well-known incident involved the Microsoft QAZ spy, where small but smart remote-control software enabled unknown hackers access to development PCs at Microsoft. The exact effects of the break-ins remain a mystery.
Some of these tools are also responsible for major denial of service (DoS) attacks. In those cases, the spying agents, referred to as "Zombies" or bots, remain dormant on thousands of infected systems, waiting for the hacker to program them. The hacker could, at will, designate the multiagent network he or she devised with an attack target (a URL) and time, then initiate a coordinated DDoS (distributed denial of service) attack.
Solutions. As noted earlier, most companies today defend against viruses with scanners that operate reactively. First, a virus sample is found, then it is analyzed, a definition pattern to identify that virus is added to an update, and the update is distributed to end users. Soon the next variant gets written, and the process starts again. Clearly, this type of pattern-based virus scanning alone is not the answer, although it is one important part of the solution.
The best approach combines this reactive method with proactive techniques that can identify and block as-yet-unknown malicious code. In addition, a good anti-virus program ensures that security is implemented at all levels, from gateways and mail servers to desktops so that there is no weak link in the chain where a hacker can focus attacks.
With regard to the detection of new variants, three methods are currently being used effectively. They include sandboxes, heuristics, and selective blocking. While no one approach is perfect, each has a role to play in helping companies create a secure network defense. It is advisable to use all three in a layered approach to compensate for each method's weaknesses.
Sand boxes. At its most basic level, a sandbox is a set of rules applied to applications or active content. This set of rules defines what activity is internally allowed within the application scope. It creates a security envelope, surrounding the application, sitting quietly in the background until something tries to break the rules. When a violation occurs, the sandbox shrinks, further limiting the violating entity, and the user is notified of that action.
To put it another way, a software application with sandbox rules applied is enveloped in such a way that some activities are acceptable and some are not. A sandbox rule might bar outside access to local files such as the "My Documents" folder or to other designated areas. The sandbox will not permit malicious code to exploit the software environment it runs within, such as Internet Explorer, to do something out of this normal range of operations.
For example, when active content (such as an ActiveX stock ticker or a Java applet game) is downloaded from an Internet site, a browser will observe this application and restrict it to certain boundaries, usually in a cache directory in the browser. If the sandbox rules detect suspicious activity that is emanating from the application, even stricter rules, or tighter boundaries, might be imposed. As another example, a sandbox might be configured to prevent a program attached to an e-mail from deleting files in the hard drive or bar active content in the Web page from getting into the "My Documents" folder. Or if a user receives an e-mail with attached Flash animation, that attachment may be an executable file containing a Trojan that will try to access off-limits areas of the computer and steal data or to install itself on the PC. Sandbox rules will prevent this.
Sandboxes are flexible; some rules can be further adjusted by the user, or globally by an administrator, to accommodate specific requirements. Special sandboxes can even be created to further protect user-side e-commerce or other high-security applications.
Three or four years ago, the early generations of sandboxes were plagued by false alarms, because it was difficult to define what "normal" behavior was. Sandboxes would frequently isolate programs that seemed abnormal but were helpful and innocuous. Over time, programmers have learned to better refine the sandbox rules. They now produce only the rare false alarm.
That's not to say that all the problems have been solved. It is still difficult for administrators to define what "normal" is and to define the sandbox appropriately. The flexibility of a sand-box also may depend on the application. Microsoft applications, for example, are known to require many more access liberties for proper operation and are closely tied with the operating system; this fact makes creating sandbox rules for Microsoft applications nearly a work of art.
But this defense remains a useful technique despite its limitations. The bottom line is that a sandbox makes a system more resilient to attack by limiting the damage that can be done.
Heuristics. Heuristics is a set of rules applied to a program to determine whether that program is likely to contain malicious commands that should he blocked. Heuristic analysis tries to identify possible malicious behavior by looking for sequences of commands that are known to be used by Internet vandals. One type of heuristics uses statistical analysis--analyzing the repetition, order, and type of VBA commands--to distinguish legitimate macros from malicious ones. Heuristic analysis can also be implemented to analyze VBS, which has a similar syntax to VBA.
As with metal detectors, heuristics can be tweaked to catch most anything, but casting the widest possible net will also yield many false positives. A balance must be struck between detection and user convenience, such as mainwining the ability to use sophisticated Microsoft Word and Excel macros. Finely adjusting heuristic detection enables the user to achieve about an 85-percent detection rate when encountering completely new viral macros. Variants of known macro viruses are detected at a much higher rate, more than 95 percent.
Having efficient heuristics minimizes user inconvenience while also providing a high level of security. While 5 percent to 15 percent may seem like a lot of worms to let through, it must be remembered that the proactive measures are designed to be layered, not standalone, so a vandal missed by conventional scanning, for example, might be detected by heuristics or sandboxing.
Heuristics can work efficiently and reliably only on programs written in script or macro languages, which are not compiled. (Compiled viruses are in machine language, which means that the source code of the virus is not visible within the virus code as it is within macros and scripts.) Several anti-virus vendors have also tried to implement heuristic technology for traditional compiled viruses, but the results have been poor.
Using heuristics on compiled code causes many false alarms and is time consuming, problems that render it impractical for normal use. However, since many of the most prevalent Internet vandals are script- and macro-based, heuristic technology is extremely useful in detecting them.
But even with these viruses, one problem is that legitimate, but sporadic activities, such as operating-system upgrades, could be mistaken for vandal activity, causing false alarms. Therefore, some products use "negative heuristics" (which keep track of the code and techniques that definitely do not indicate a virus infection) to examine the file in more detail. They weigh those findings against any alert when the positive heuristic analysis says that a pattern could indicate a virus. That approach tends to solve the false-positive problem.
Blocking. In addition to trying to detect patterns of code that seem likely to contain malware, organizations should have such safeguards as a policy to prohibit certain file types and file elements and the use of certain ports. For example, using a conventional firewall, a company can block certain ports, IP addresses, and applications.
Another method of blocking is to use anti-virus software to block files according to their file type. The software should be sophisticated enough to analyze a file's content to ensure that it is not spoofed. In other words, someone who wants to send or receive executable files, which often are a vehicle for virus code, can circumvent the system administrator's rules by renaming the file with a different extension. A content security product that can detect spoofed files can also be implemented so that users will not be able to circumvent the security system by changing the extension of downloaded or attached files.
There is no reason to allow unrestricted receipt of all attachments. The corporate environment typically uses only specific file types such as Microsoft Office documents (with the familiar .doc, .xls, and .ppt file extensions), graphic files (including .jpg and .gif), and archive files (such as .zip). Other file types, such as .exe, .vbs, and .dll, are potentially dangerous and allowing them in does not benefit the company.
In addition, anti-virus software should be able to block MS Office documents containing macros or remove the macros before admitting the files. This is especially important for Office documents arriving from outside the organization. If such macros are necessary, users can define exception rules for specific users.
Corporate network protection based solely on scanning known virus signatures cannot be the security technology for the future. Preventive techniques, such as sandboxes, heuristics, and selective blocking software, combined with intelligent user policies, are the only way to inoculate a system against infectious code.
Shimon Gruper is vice president of Internet technologies for Aladdin Knowledge Systems of Tel Aviv, Israel. Ofer Elzam is a senior security expert for Aladdin.
|Printer friendly Cite/link Email Feedback|
|Author:||GRUPER, SHIMON; ELZAM, OFER|
|Date:||Aug 1, 2001|
|Previous Article:||What if the Virtual Walls Fall?|
|Next Article:||School security.|