Back Orifice 2000

By now, you've probably heard of Back Orifice 2000 (BO2K), a so-called systems administration tool with a dark side. The BO2K creators, Cult of the Dead Cow (cDc), assert that you can use this free tool for legitimate remote administration on corporate networks, and a lot of people—myself included—have winced at the idea.

To learn as much as I could about this tool, I watched cDc's BO2K presentation (which is available in RealVideo format at http://www.defcon.org/ html/defcon-7-post.html) at this year's DefCon VII convention in Las Vegas. During the presentation, cDc described BO2K's built-in functionality. As the show rolled on, I found myself buying into the idea of using BO2K for remote administration. Based on the presentation, the tool sounded very powerful. When I learned about BO2K's Triple Data Encryption Standard (3DES) encryption support over TCP and UDP, the tool sounded even better. I began wondering whether a person could dispose of PPTP and commercial remote-control software such as Symantec's pcANYWHERE32 and use this lighter-weight tool instead.

Curiosity got the best of me. I decided to take a look under BO2K's hood to determine whether you can use BO2K legitimately and safely in a corporate environment. I examined the BO2K server configuration and the client configuration and identified which parameters you must set before you use the software. I also walked through every feature, tested every command, and checked several plugins that considerably extend BO2K's functionality. As you might suspect, I also looked at the security implications of using this tool on the network for remote administration.

Under the Hood
BO2K uses a client/server architecture to remotely administer both Windows NT and Windows 9x systems. The server component is the real workhorse and can run as an NT service. The server performs all command actions that the client instructs using a fairly small memory footprint. The client component connects to the server and performs various actions, such as modifying a Registry key, mapping shares, and transmitting files.

The BO2K server occupies approximately 113KB of disk space, and when it runs idle in memory, it consumes between 2MB and 3MB of RAM. The client component occupies 568KB of disk space, and when not connected to a BO2K server, the component consumes a little more than 3MB of RAM. When the client connects to a BO2K server, the client uses approximately 4.5MB of RAM, as measured on an NT Workstation 4.0 system. All totaled, BO2K's memory and disk requirements aren't substantial.

BO2K comes in a US version and an international version. Because federal law restricts exporting products that support strong encryption, cDc makes the international version without 3DES support.

A slick feature of BO2K is its support for plugins that extend the tool's functionality. BO2K also supports legacy plugins designed for use with the original Back Orifice program. cDc provides a software development kit (SDK) to help developers get started writing plug-in extensions. One neat plugin I tested is BOPEEP. This plugin provides BO2K with a realtime video display of the remote machine that you're managing. BOPEEP also lets you take control of the remote system's mouse and keyboard as though you were sitting at that system's local console. However, BOPEEP needs some improvement. For more information, see the sidebar "Little BOPEEP."

Another plugin I tested, BOTOOL, provides GUI-based file and Registry management. BOTOOL is a worthy addition because BO2K's built-in file and Registry command structure isn't exactly user-friendly. Although I tested a beta version of BOTOOL, I suspect the first release will be available by the time you read this article. For more information, see the sidebar "BOTOOL."

Server Configuration
Before I could use BO2K, I had to configure various server-component parameters. (For definitions of these parameters, see the online sidebar "BO2K Server Configuration," http://www.winntmag.com/articles, InstantDoc ID 7252.) BO2K comes with a wizard that helps you perform this basic configuration. The wizard asks you to provide the server's executable filename (which can differ from the real executable filename), a network type, a port number, an encryption type, and an encryption passphrase.

Although you can use the default executable filename (bo2k.exe) for the BO2K server, the wizard lets you set the filename to any name you choose. As you know, NT displays the executable filename on the Processes tab in Task Manager. BO2K lets you spoof this name by setting it to anything you like. That way, when you view the processes using Task Manager, the spoofed name will appear instead of the real executable filename. I configured the executable filename within BO2K to reflect something not so obvious, such as rasman32.exe. Also, in an effort to partially obscure the fact that I was running BO2K on my test network, I renamed the executable on disk before I used it to prevent users who were snooping around the disk subsystems from finding the more obvious bo2k.exe filename. The network-type parameter defines the traffic protocol (either TCP or UDP) that you want the server to use to communicate with the client. During my tests, I used both traffic protocols successfully.

The port number setting defines the communications port that you want the server to use to communicate with the client, and the encryption type determines which type of encryption (either exclusive OR—XOR—or DES) you want the server to use. The BO2K international version supports only the weaker XOR encryption—I tested the software using the US version with 3DES encryption. The server uses the passphrase as the encryption key (i.e., the client must use the same passphrase that you configure for use on the server).

After I defined the basic configuration parameters, the wizard wrote them to the BO2K server executable file. Note that BO2K writes these parameters, and others, in the executable as clear text. As a result, if you lose your passphrase, you can always open the executable with Notepad and browse the contents to find the passphrase. Be aware that other users can also search the executable file if you don't secure it. Make sure you set the permissions on the BO2K executable file to allow only administrator access—you need to apply the same precautions to the BO2K client and any plugins you use with the software.

After I finished using the wizard, I configured several other parameters that govern BO2K's stealthlike nature. Using the BO2K Server Configuration tool, the server presents a treeview, as Screen 1 shows, that lets you browse the settings under the Stealth tree. These settings include Run at startup, Delete original file, Insidious mode, Runtime pathname, Hide process, Host process name, and Service name. Make certain that you refer to the online sidebar "BO2K Server Configuration," http://www.winntmag.com/articles, InstantDoc ID 7252, for details about these parameters—they have a significant effect on the visibility and operation of the BO2K server.

Because I was testing BO2K for use in a corporate environment and I wanted administrators to notice the tool, I set the Stealth parameters so that the BO2K server retained its original filename. I also exposed the tool's process name to Task Manager and set the server to automatically start during a system boot. Keep in mind that BO2K doesn't have to be visible in a corporate environment—you can hide BO2K as an added level of safety. When you hide the tool, snoops won't be able to simply look at the services list or processes list under Task Manager to discover that the tool is running on a given system. The trade-off for invisibility is documentation: You need to document which systems are running BO2K server and which executable filenames, port numbers, and passphrases you're using for each BO2K server. If you lose track of this information with the tool running invisibly, you'll have a hard time relocating the information. Use caution, document your settings carefully, and don't forget to store your documentation in a controlled area where snoops can't easily get to it.

Client Configuration
With the server configuration completed, I was ready to fire up the client and try it out. Configuring the client is much easier than configuring the server. At the time of this writing, the BO2K client ran as only a Windows-based desktop application. However, you can bet that a Linux-based client will surface.

The BO2K client uses workspaces that contain profiles for an array of BO2K servers. This workspace design enables the client to better manage large numbers of BO2K-enabled systems.

To configure the client, I first clicked New Workspace on the toolbar to open a new workspace. Next, I clicked Create a new server on the toolbar to add a server to the workspace. The software presented a dialog box to enter the parameters necessary to connect the client to the server. These parameters required the same settings (i.e., TCP, 3DES encryption, the server's port number, and the server's authentication type) that I had defined in the server component. After I entered these settings, I still had to enter the passphrase for the server. To enter the passphrase, I had to add the 3DES plugin to the client and configure the plugin's passphrase property to match the passphrase property configured in the server's 3DES plugin.

The passphrase property within the 3DES plugin is a shortcoming for BO2K because all the servers in a workspace share the same plug-in properties. So, if I want to manage 15 different NT systems in the same workspace, I have to manually reset the passphrase in the 3DES plugin before I connect to a given server. Fortunately, this process is about as difficult as typing in a password at an NT logon prompt. Nonetheless, you'd think BO2K would store each server's passphrase separately, considering that cDc went to the trouble of creating workspaces and support for multiple servers in one client interface.

Although you can configure BO2K to accept multiple simultaneous logons, the software uses a common passphrase across all connections and doesn't perform any user authentication. BO2K's authentication layer performs only NULL user authentications and serves to apply encryption to the network transport. As a result, anyone who has the encryption passphrase can log on. Therefore, you can't set and store different passphrases for different users. After I set the passphrase, I was ready to connect to the BO2K server and put it through the wringer.