| Downloads |
|---|
| 7254.zip |
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.
BO2K in Action
After you define the parameters within a workspace, connecting to a remote BO2K server is simple. To connect to a server in my network, I double-clicked the server name in the Server List to open the Server Command Client dialog box, which Screen 2 shows. From the Server Command Client, you perform all administrative actions on the server. From this dialog box, I clicked Connect and successfully connected to the server, as the message in the Server Response pane at the bottom of Screen 2 shows. This action also relabels the Connect button as Disconnect, which you can see in Screen 2.
Upon connecting, the client can automatically query the server to discover its capabilities. The client uses the acquired capability list to build the command tree in the left pane of Screen 2. To perform command actions on the server, you navigate through the tree to locate the desired command, click the command name, fill in any required parameters, and press Send Command. Most commands require at least one parameter before you can execute them on the server. In those cases, the Server Command Client displays data entry fields in the right pane. A fair warning is in order here: Malformed command parameters can cause the BO2K server component to crash or lock up, so enter the parameters carefully and pay close attention to the syntax.
Because BO2K is a remote management tool, command functions are paramount to getting work done. When I examined the command tree, I discovered that BO2K can perform a variety of actions. The online sidebar "BO2K Command Usage," http://www.winntmag.com/articles, InstantDoc ID 7253, describes the command structure and the functionality BO2K provides.
The million-dollar question for any remote administration tool is, can it perform necessary administrative actions? With the first release of BO2K, the answer is yes and no—with a heavy slant toward no. Without the BOPEEP plugin, BO2K can't perform simple administrative tasks, such as changing user-account settings and reviewing the event logs. Although you can download and view files, and view, add, and modify Registry entries, these actions aren't especially conducive to simple user and log administration. After all, who wants to sift through the Registry just to view a log entry? BO2K's Registry viewer and editor is purely text based, and although the tool finishes the job, it's cumbersome to use and has no search facility for finding keys or values. Therefore, using the BOTOOL plugin is a must for any serious remote-administration tasks because it adds enhanced file and Registry management to BO2K.
Because BO2K lets you control services, access the Registry, transfer files, and redirect ports, the tool is very conducive to providing one control point to access these types of tools. For example, most prudent administrators block remote Registry access. But with BO2K in place, you can still edit the Registry regardless of whether the administrator has blocked remote Registry access. You can provide the same access for process controls and other NetBIOS-based administration. So, even if your border-protection system (e.g., firewall, proxy) doesn't permit NetBIOS traffic in and out of the network, you can still provide controlled access to a BO2K server port. This capability is a significant benefit of this tool; but then again, other remote administration tools such as pcANYWHERE32 and Remotely Possible/32 offer this benefit.
BO2K's built-in file manipulation ability is admirable, but not complete by any stretch of the imagination. Because BO2K supports 3DES, you can transfer files over a secure connection that is very difficult to crack. When I used the Receive File and Send File commands under the File/Directory command tree, I could securely transmit files back and forth between BO2K servers on the network. However, a major shortcoming with the built-in functionality is that I could only send one file at a time and I have to tell the receiving system what that filename should be before transmission. With this limitation, moving large numbers of files will be cumbersome and time-consuming. However, using the BOTOOL plugin lets you easily overcome the limitations of the built-in file controls.
BO2K also supports straight TCP file transfers. I found this feature handy because I was able to use tools such as L0pht Heavy Industries' Netcat to connect to a BO2K server and retrieve a file. Again, a one-at-a-time architecture limits this functionality.
The tool also comes with a built-in basic Web server so that you can browse for files and directories. This feature makes navigating a hard disk simple and lets you easily download files with the click of a mouse. However, straight HTML directory navigation still pales in comparison with a regular Windows Explorer client. Personally, I'd rather use the BOPEEP or BOTOOL plugins than use NT's built-in Windows Explorer.
BO2K can turn on any audio or video device available on the remote system. I tested this feature, and it worked well; however, I can't think of any genuine administrative uses for this capability other than using it when I want to know what's happening around a given system. For example, if you run BO2K on NT servers kept in a secure area, this feature can help you keep an eye on those facilities.
BO2K supports file compression and decompression. This feature offers a quick and handy way to shrink a large file before you transmit it over the network.
One potential use for BO2K is network surveillance. BO2K can observe the same types of information (e.g., processes running on a remote computer, open connections, shares) that you might use NT's Server Manager to check. BO2K also includes the ability to perform keystroke logging, a feature that might come in handy if you suspect an employee of engaging in malicious or unauthorized activity. I tested this feature without any problems.
You can use BO2K to reboot a remote computer and dump password hashes from the SAM database that you can crack using L0pht Heavy Industries' L0phtCrack tool. Although this second feature might appear to be a security risk, any user with Administrators group privileges can do the same thing using other hash dumping tools that are freely available on the Internet.
One of BO2K's features has no use in the corporate environment: I'm talking about a little command called Lockup. This command locks up the remote computer, forcing you to reboot the machine. If anyone can think of a legitimate use for this functionality, I'd like to hear it—this feature is strictly malicious.
One serious oversight with this release of BO2K is its amazing lack of any interaction with NT's event log; BO2K never creates log entries. To be a genuine remote administration tool, BO2K needs this functionality. Corporate users need to have a logging option to provide footprints on the network and an audit trail for quality control. Granted, not all users want this functionality, but I suspect that most will. And if cDc truly wants the public to view this tool as legitimate and acceptable for corporate use, then the group should immediately add this capability.
The Good, the Bad, and the Ugly
All summed up, BO2K is a great tool, and the fact that it's free makes it appealing. However, it has some serious shortcomings.
The good. Because cDc made the source code available under open-source licensing, anyone who doesn't feel safe about running the compiled BO2K executables can download the code, examine it for security concerns, and compile and run their own executables.
The availability of the source code also means that a programmer can address shortcomings and bugs in the code and extend the overall functionality of the tool. Developers can also use the available SDK to write plug-in extensions for specialized functions. Just be aware that under the BO2K's open-source licensing scheme, you can't commercially sell any modifications you make to the product. However, you can develop custom BO2K plugins and commercially sell support and maintenance for those plugins as long as the plugin remains available for free.
One of the biggest benefits to using BO2K is that it can provide remote access that border-protection systems might otherwise block. This functionality appeals to me because I habitually block all traffic related to NetBIOS and other dangerous protocols from entering or leaving any of my networks. With BO2K, I can minimize traffic-related security rules to some extent while not giving up too much functionality in the process.
In addition, the tool can provide encrypted communication through another tunnel, such as Secure Shell (SSH). To securely move typical NetBIOS-related traffic, many companies use VPN technology, such as Microsoft's PPTP, to tunnel between a client and a remote network. With BO2K and its 3DES support, PPTP might not be necessary on your network, unless you're supporting end-user connectivity. The main difference between PPTP and BO2K is that PPTP provides a tunnel into a server and network, whereas BO2K provides a tunnel in the BO2K application that exposes servers and networks. Using PPTP might be easier than trying to do all your administrative work from within BO2K. However, if cDc puts some heavy polish on BOPEEP, I'd personally rather use BO2K than fuss with PPTP for secure administration.
The bad. Unfortunately, BO2K is still underpowered, even with the addition of the BOPEEP and BOTOOL plugins. cDc needs to add more administrative functionality, such as the ability to control NT service startup properties.
Another shortcoming is that BO2K has some annoying bugs, such as the lack of parameter checking, that might lead to a crashed BO2K server component if you make a mistake in syntax when you enter a command. The initial release of BO2K also suffers from a lack of multiuser support and no support for multiple passphrase storage.
Perhaps cDc didn't address some of these shortcomings on purpose. I know that the company expects the user community to use the open-source availability to improve the tool and offer those improvements back to the community. Whether this tactic will work and improve the product remains to be seen. However, if the developer community does respond, perhaps we'll see a much more powerful BO2K sometime down the road.
The ugly. BO2K's really ugly parts include the fact that anyone can configure the software to be almost completely invisible on the network and that the tool has a Lockup command readily available in the command interface. Toss in the fact that BO2K doesn't log any network events, and you've got the potential for some serious shenanigans to take place in your network environment.
Can you control these concerns? Certainly. You can easily make the tool visible on a system and trust an administrator not to use the Lockup command—most administrators have more than enough network access to crash a system without using BO2K. So BO2K's big, remaining, ugly blemish is logging. Without the ability for BO2K to write event-log entries or provide an audit trail, you're accepting a significant risk by letting BO2K run on your network. Good security practice includes having an audit trail to follow, and even though I can turn on all kinds of auditing within NT, none of that trail will ever reveal what user performed which actions while using BO2K. BO2K handles its connections and can't tie itself into the NT user database (or any other database) for managing connection privileges. For all intents and purposes, NT thinks the built-in System account performed all actions an NT audit trail catches, when in fact BO2K performed them.
The Verdict
BO2K stands poised to become a useful remote administration tool. But before it attains that status, someone needs to add an audit trail capability, either proprietary logging or NT event logging—with NT event logging being the preferred choice for corporate use.
Along with logging, other items on my wish list are controls to manage users and event logs, and controls to manage file, directory, share, and Registry permissions. With these controls added, BO2K would be a more formidable competitor to other remote management packages. But until we see these improvements, I'd be hesitant to deploy BO2K on a corporate network because I would constantly find myself needing to access this type of functionality. And although I can use BOPEEP to access NT's built-in tools that provide this functionality, BOPEEP needs some improvement as well.
Nonetheless, you might want to get a copy of BO2K and begin to familiarize yourself with its use and operability because I suspect we'll see the cDc developers addressing these concerns. You can find BO2K and the available plugins at http://www.bo2k.com.