W32.Bolzano

From the replication point of view, there is nothing much remarkable about the first few versions of Bolzano viruses. It is a simple, direct action appending type. It adds its code to the end of the last file section and modifies the entry-point of the program to point to the virus body (A, B and C variants). The D variant does not modify the entry point of PE files; instead, it searches for 12 possible CALL instructions inside the code section of the host and hooks the randomly selected CALLs to the entry point of the virus. The virus creates a thread in the infected process for itself and replicates in the background while it executes the host program (main thread). Therefore the user will not easily notice any delays. Several variants of Bolzano use inserting/polymorphic technique (infection without entry-point modification) and also polymorphic at the same time. This makes the detection of the virus more complicated. Bolzano was reported "in the wild" in France. Most likely the virus writer is from France.

Several variants of the Bolzano virus do not only replicate, but also attack the Windows NT file security system. It uses a new strategy that may be used by NT viruses in the future. This attack will work on any version of Windows NT (Version 3.50 up to 4.0) with each all the service packs. The attack does not work on any betas of Windows 2000, but it remains feasible.

In order for the virus to attempt the attack, it needs administrative rights on a Windows NT Server or Windows NT Workstation during the initial infiltration. Therefore it is not a major security risk, but still is a potential threat. Viruses can always wait until the Administrator or someone with the equivalent rights logs on. In such a case, W32.Bolzano has the chance to patch ntoskrnl.exe, the Windows NT kernel, located in the WINNT\SYSTEM32 directory. The virus modifies only 2 bytes in a security API called SeAccessCheck that is part of ntoskrnl.exe. This way Bolzano is able to give full access to all users to each file regardless of its protection, whenever the machine is booted with the modified kernel. This means that a Guest -having the lowest possible rights on the system- will be able to read and modify all files including files that are normally accessible only by the Administrator. This is a potential problem since the virus can spread everywhere it wants to regardless of the actual access restrictions on the particular machine. Furthermore after the attack, no data can be considered protected from any user. The latest variants of Bolzano also patch MSV1_0.dll in the System32 directory in order to remove password checks from there.

Unfortunately the consistency of ntoskrnl.exe is checked in only one place. The loader, ntldr, is supposed to check it when it loads ntoskrnl.exe into physical memory during machine boot-up. If the kernel gets corrupted ntldr is supposed to stop loading ntoskrnl.exe and display an error message even before a "blue screen" appears. In order to avoid this particular problem W32.Bolzano also patches the ntldr so that no error message will be displayed and Windows NT will boot just fine even if its checksum does not match with the original. Since no code checks the consistency of ntldr itself, the patched kernel will be loaded without notification to the user. Since ntldr is a hidden, system, read-only file W32.Bolzano changes the attributes of it to "archive" before it tries to patch it. The virus does not change the attribute of the ntldr back to its original value after the patch.

Several variants of W32.Bolzano delete the contents of the \WINDOWS\Cookies and \WINNT\Cookies directories. Probably the virus writer wants to introduce the virus onto a machine he was using to cover where he was web-surfing.

Recommendations

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.

Summary