Discovered: January 08, 1999
Updated: February 13, 2007 11:56:34 AM
Also Known As: BeanHive
The BeanHive virus was discovered on Jan 8, 1999 and is the second known Java virus ever developed. While this virus attempts to use a number of interesting new technologies to spread itself, it functions incorrectly under many circumstances and is not likely to constitute a threat to users
Antivirus Protection Dates
- Initial Rapid Release version January 19, 1999
- Latest Rapid Release version August 08, 2016 revision 023
- Initial Daily Certified version January 19, 1999
- Latest Daily Certified version August 09, 2016 revision 001
- Initial Weekly Certified release date January 19, 1999
Click here for a more detailed description of Rapid Release and Daily Certified virus definitions.
This virus was designed to infect both Java applets as well as Java applications. Java applets are Java programs that can be posted on World Wide Web sites and which can be used during typical web surfing. Java applications are stand-alone applications written in Java that are typically used on desktop PCs. Java applications are used infrequently, so during the rest of this paper, we will limit our discussion of this virus and its effects on Java applets.
When a user follows a link to a web site that contains one or more Java applets, these applets are downloaded to the surfer's computer and executed in a sandbox or virtual machine. This virtual machine allows the Java applet to run and ensures that the user's computer is protected from any accidental or malicious activity by the Java applet. Specifically, the virtual machine prevents applets from accessing local files, the Registry and other components of the user's computer. These security features have made Java one of the safest ways to get exciting interactive content over the web.
While the Java virtual machine affords great security to users, it also prevents Java applets from performing many useful tasks. For instance, if someone wanted to build a Java applet that legitimately searched the files on the user's computer, this applet would immediately be terminated for violating the Java virtual machine's security. The designers of Java recognized that it would be difficult to build many useful Java applets because of the security model and decided to loosen the Java protection.
If specifically designed to do so, a Java applet can make a request of the Java virtual machine and ask for greater access to the system. Such a Java applet, for instance, could request access to the local files on the computer. When it makes such a request, the user's web browser will inform and allow the user to either grant or deny the request. The BeanHive virus uses such a technique to obtain access to the users local files; this is the first distinguishing characteristic of this virus. The first Java virus, Strange Brew, would attempt to infect files on the user's computer without properly requesting access and consequently failed to work in the Java virtual machine as an applet.
The BeanHive virus is also noteworthy because it is one of the few viruses that has its logic distributed across many files. In contrast, most computer viruses are entirely self contained; when they infect a new file, all of the virus' replication logic is copied from the old file and inserted into the new file. The virus author has placed seven of the nine files that comprise this virus in an archive file (Called either BeanHive.JAR or BeanHive.CAB. The JAR file is used with Netscape Navigator; the CAB file is used with Internet Explorer).
A user can catch this virus by surfing to a designated web page on the virus author's web-site; when the user reaches this page, the entire JAR (or CAB) file, which contains seven of the virus modules, is automatically downloaded to the user's computer. The virus' main Java component (called BeanHiveFrame.class) then runs on the user's computer within the Java virtual machine. This component first makes a request to obtain access to the local system (as described above). If the user decides to disallow this action, the virus will fail to work and will immediately be terminated. However, if the user decides to grant access to the virus, it continues to run. It is important to note that if the user grants access to the virus, they are essentially granting access to any and all Java programs written by the virus author! (For more information on this, you can search the world wide web for Java code signing.)
After obtaining access, the virus will pop-up a standard dialog box and allow the user to choose a Java file which they would like to infect with the virus. Clearly, this main Java module was intended as a demonstration; most viruses do not allow users to select which files are to be infected. Furthermore, this main Java module is only used to deliver the virus to the user's computer. It is never used again by the virus. In anti-virus lingo, this main Java module is called a virus dropper because it "drops" the virus onto the host computer and is not used during subsequent infections.
After the user selects a file to infect, the virus will employ four additional Java modules contained in the JAR (or CAB) file to infect the suspect file. The first module (called e89a763c.class) contains the main virus infection routine. It contains logic to examine a target Java program and determine whether or not it is suitable for infection by the virus. If this module determines that the selected Java file is appropriate for infection, it calls upon three other Java modules ( c8f67b45.class, dc98e742.class and be93a29f.class) to infect the target Java program. Each of these three files work together to insert the eighth component of the BeanHive virus into the target Java file. At this point, the target Java program has been modified to contain a small subset of the virus' logic. The virus also updates the target Java program so that when the user runs it, the virus logic will execute first, followed by the program's original logic.
If and when the user runs the just-infected Java program, the virus will immediately take control. The virus in the actual infected file contains very simple logic. Basically it only attempts to locate the ninth and final component of the virus (a file called BeanHive.class) and then run it. The virus author has dubbed this ninth viral component the Queen. This file is not contained in the BeanHive.JAR (or BeanHive.CAB) archive and is no where to be found on the user's computer the first time the virus runs. The virus first attempts to locate this file on the user's system and consequently fails. Next, the virus attempts to locate and download this file over the world wide web.
If the infected Java program finds the BeanHive.class file, it immediately downloads and runs it. The BeanHive.class module contains the logic to search the user's current directory for additional Java files to infect. It will attempt to find and infect up to three Java program files before returning control to the host program. This BeanHive.class module employs the same four virus modules used during the original infection: e89a763c.class, c8f67b45.class, dc98e742.class and be93a29f.class. Once again, the BeanHive.class module will call upon these four modules to insert the eighth component of the infection into subsequent Java program files. If these subsequent infections are to spread, they again require both the BeanHive.class component and all components contained in the BeanHive.JAR (BeanHive.CAB) file to be present on the user's computer. If an infected Java file is sent by itself to another computer, or if the other eight components of the BeanHive virus are deleted from the computer, the infected file will be wholly unable to spread on its own.
During extensive testing at the Symantec AntiVirus Research Center, Symantec researchers were unable to make this virus work properly. It contains numerous bugs, which prevent it from properly spreading. Consequently, we do not consider this virus a threat to corporate or home users. Nevertheless, users should not experiment with this virus as it can cause damage to Java files and potentially open other security holes
Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":
- Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world.
- Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.
- Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application.
- Disable AutoPlay to prevent the automatic launching of executable files on network and removable drives, and disconnect the drives when not required. If write access is not required, enable read-only mode if the option is available.
- Turn off file sharing if not needed. If file sharing is required, use ACLs and password protection to limit access. Disable anonymous access to shared folders. Grant access only to user accounts with strong passwords to folders that must be shared.
- Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack.
- If a threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
- Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services.
- Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files.
- Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media.
- Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.
- If Bluetooth is not required for mobile devices, it should be turned off. If you require its use, ensure that the device's visibility is set to "Hidden" so that it cannot be scanned by other Bluetooth devices. If device pairing must be used, ensure that all devices are set to "Unauthorized", requiring authorization for each connection request. Do not accept applications that are unsigned or sent from unknown sources.
- For further information on the terms used in this document, please refer to the Security Response glossary.