Modern hardware devices contain information that assists the operating system in finding appropriate drivers—and intruders in finding out who was doing what when.

June 30, 2006
URL:http://www.drdobbs.com/security/device-trails/189401600

Zvi is founder and CTO of Safend. Avner is a Team Leader in the R&D group. They can be contacted at www.safend.com.

Operating systems such as Windows keep track of devices—disk-on-keys, printers, cameras, headphones, mobile phones, and the like—utilized by users. These devices can be connected via physical or wireless ports, utilizing more than two-dozen protocols ranging from wired protocols such as USB and Firewire, to wireless protocols such as IrDa, Wi-Fi, and Bluetooth.

Although the information Windows saves differs depending on the device and protocol at hand, users can usually acquire information about devices previously connected to a computer. For example, you can learn that a user connected an encrypted disk-on-key to "Joe's" computer, the key manufacturer was Kingston, the key size 128 MB, and so on. Metadata describing this information can be retrieved years after the device was connected to the computer.

This data is valuable to security professionals who use it to learn how computers are used within organizations. For example, a Chief Security Officer (CSO) conducting a risk assessment or incident research would find such information helpful. However, this information could also be used by an unauthorized person who may learn about the organization's device usage from a computer he has access to while breaching the company's privacy.

Modern hardware devices contain information that assists the operating system in finding appropriate drivers to handle the device. This is true for all modern ports—USB, Firewire (IEEE 1394), Bluetooth, PCI, and PCMCIA.

Take USB, for example. Each USB device has to report the information in Table 1 during its handshake process with the host computer. While Table 1 has parameters that are unique to the USB port, other ports have other identifier types. To identify devices in a generic way, Windows translates these IDs to the standard IDs in Table 2. This translation is done by the USB drivers that are an integral part of Windows 2000/XP/2003/VISTA.

Plug-and-Play Forensics

Plug-and-Play (PNP) is the part of Windows responsible for managing device drivers. One of PNP's central functions is to find appropriate drivers for connected devices. To do this, when a device is connected to the computer, PNP queries its port driver for the IDs of newly connected devices; see Table 2. Using this information, PNP can determine if this is the first time it has encountered a particular device. Searching the connected device's Device Instance ID in a database of previously connected devices does this. If the device is found, the computer utilizes the driver that was previously assigned to that particular device.

If such a record is not found, PNP searches all known .INF files for drivers that handle the particular Hardware ID or Compatible ID of the device. Once it finds a proper .INF file, PNP loads the driver and writes the particular device's information into the database. If PNP cannot find the device's IDs in any of its .INF files, it queries users with the "Add new hardware" wizard.

Our interest here is in the database of previously connected devices. This database contains the information of all the devices ever connected to the computer—their Hardware IDs, Compatible IDs, Device Instance ID, associated drivers, and the Windows class they belong to. (This is the class you see in the device manager—display adapters, disk drives, and the like.) Moreover, some devices provide a readable description of their identity; for instance, "Nokia Connectivity Cable DKU-5" for a cable connecting some Nokia cell phones via the USB.

An interesting piece of information might be which port in the computer the device was connected to. Was it at the front of the computer or the back? Was there another hub in the middle? Answers to these questions might be available in some devices. Interestingly enough, the devices that stand out and can be tracked are those without unique IDs. In the case of USB, when Windows is trying to create a unique identifier for the particular device, it asks the device if it has a serial number. If the device has a serial number, the serial number (together with the Hardware ID) creates the Device Instance ID. If the serial number is absent, Windows creates the Instance ID from the exact location where the device was connected.

By default, this database is readable by all of the computer's users. It is stored in the registry, with some Windows API functions giving specific access to this database.

The PNP mechanism we've just described received a slight upgrade in Windows Vista. For instance, domain administrators can set a policy using the GPO, stating which devices can't be installed even by local administrators of the station. The purpose of this mechanism is to give security officers control over what devices are connected to an organization's computers.

The problem with Vista's approach is that a device can be freely used once it has been installed. If an organization's policy prohibits use of a specific device, that device can still be used if it was previously connected and installed. Thus, information regarding historically connected devices on a machine running Windows Vista can be exploited by adversaries to connect prohibited devices. All they need is to find a device that was previously installed on the computer, and then use it. For example, if intruders want to use a specific printer, they might see that it was previously installed and know that they need to connect this specific printer to the computer for it to work.

There's More!

In addition to the basic information kept by the PNP in the registry, much more specific information can often be traced.

When synchronizing a mobile device, such as a Windows Mobile-based pocket PC, ActiveSync (the main application used to synchronize Windows Mobile-based devices with desktops) leaves traces of when the synchronization was done, what was synchronized (e-mail, files, and the like), and more. This information lets anyone with access to the computer know which mobile devices were attached to that computer, as well as names, versions, and so on. If users chose to synchronize files with a device, the folder of that synchronization can be found and the files within it accessed.

Another forensic trail can be found within emerging hardware standards. Given the imminent arrival of wireless USB and wireless Firewire, for instance, Windows is trying to keep pace by delivering standard drivers to new ports.

However, before a device stack is added to the OS, different manufacturers utilize it. In other words, before Microsoft added Bluetooth support to Windows XP SP2, for example, many implementations were popular in the market. These implementations will probably be obsolete in a few years.

Bluetooth Footsteps

Other examples of device-related forensics information can be found when using different driver stacks for Bluetooth. One such driver stack comes with Windows XP SP2 and is written by Microsoft; another popular driver stack is Broadcom's Bluetooth driver stack (www.broadcom.com/products/Bluetooth). A Bluetooth device is connected to a computer with a pairing process. During that pairing process, users might be asked to enter a PIN to both the computer and the associated device. After this process, the computer can interact with the specific device as they share a link key (that is specific to this computer when talking to this device).

This link key must be kept between sessions of Windows if users want to connect to the device again. Thus, a history of all connected Bluetooth devices is kept by the Bluetooth stack implementation (usually in the registry). If adversaries have access to a link key a computer has with, say, a cell phone, they can impersonate a user's computer, stealing personal data and phone call information, or even make some calls on behalf of that user.

Note that this type of exploit is complicated and may require some administrator privileges on the local computer. The difficulty may also depend on the specific Bluetooth stack implementation.

Wi-Fi Networks

Similar to Bluetooth data are wireless network settings. The profiles of all Wi-Fi networks that a computer can access are kept in the host. So, whenever users connect to a new Wi-Fi network and enter the security details needed to access it, information is kept until explicitly deleted. This is done so that when users return to known networks, the computer can connect without repeatedly asking security questions.

Anyone with access to the computer can easily read which profiles are present. In fact, in many Wi-Fi implementations (Windows WZC included), the computer tries to search the available networks whenever it is disconnected from one. This search reveals which profiles and what SSID the computer is searching for. Such information can give attackers significant advantages. If an unsecured network (such as in an Internet cafe or hotel access point) is approved by a user even once, the computer probes for that network wherever it is. Attackers can simulate the SSID of the particular network, and get a LAN connection with the victim machine.

Security Tools

The information we've discussed to this point is of primary interest to security officers who want to enforce the organization's policy. They want to check whether employees used storage devices (MP3 players, for example) that are not permitted by organizational policy. Furthermore, if a data leakage is suspected, they can audit specific computers to detect whether dangerous storage devices have been previously connected.

One such assessment tool dealing with this kind of forensics information is Safend Auditor, a tool our company developed (www.safend.com). With this tool, system administrators can learn about all devices historically connected to computers in their organization. Furthermore, Auditor marks the devices that are currently connected when the scan is administered (Figure 1), letting system administrators catch someone violating organizational policy in real time.

Figure 1: Auditor report.

In addition to knowing if the employees follow security policy, auditing tools can be used as a risk assessment tool, too. Auditor generates an audit report that can be used to illustrate how many unique devices of each kind were introduced in the organization. If a device is lost, an audit report assists in tracking the device's current location by providing a connection history. Quite possibly, the "lost" device will turn up connected to another computer within the network.

To be productive, such a tool requires administrative privileges for the system being scanned. The optional scanning mechanisms—WMI, Remote Registry, Setup API—all require some networking services in the scanned operating system to run. A personal firewall on the scanned computer may interrupt such an audit. If the computer is not responding in any port, no information can be gathered from it.

Gathering Information Remotely

There are numerous methods to gather the information we've discussed. If you have physical access to a computer, you can use the registry editor included in Windows or tools that read this information from the local registry.

You might choose to utilize a tool (such as Safend Protector) that gathers information on all connected devices and sends a log to a central repository. The tool enforces an organization's policy and records all users' activities regarding external and internal device operations.

If an administrator needs to gather device forensics information without running special code on the scanned computer and does not want to approach each machine physically, services can be used that run by default on the OS. Such services include the remote registry service, file/print sharing, and the RPC service. To interact with the scanned computer, a few subsets of Windows API can be used.

One such subset is the Setup API. Among other capabilities, this API can investigate devices on a local/remote computer, disable/enable devices, and install device drivers for those devices. A security tool can use this API to remotely access the PNP manager on the scanned computer and receive a list of all devices that were ever plugged in; see Example 1.

// Get access to all USB devices on remote machine
HDEVINFO deviceClassInfo =   
    SetupDiGetClassDevsEx(NULL, "USB", 0, 
       DIGCF_ALLCLASSES,0, "192.168.24.81", NULL);           
SP_DEVINFO_DATA deviceData; 
char buffer[BUFFER_SIZE];
int index=0;
// Enumerate devices
while (SetupDiEnumDeviceInfo(deviceClassInfo,index,&deviceData))
{
   // Get device's Hardware ID into buffer. An example 
   //   for information that can be gathered
   SetupDiGetDeviceRegistryPropertyW(deviceClassInfo, deviceData, 
        SPDRP_HARDWAREID, ®Type, buffer, BUFFER_SIZE, &size));
  // Gather more information about the device
  ExtractMoreInfo(deviceClassInfo, deviceData);
  ++index;
}

Furthermore, the API provides a means of further investigating connected devices. Using CM routines (the API that Setup API is destined to replace) on connected devices, the tools can access information on what device is connected to which port. It can investigate how many disks there are in a storage device (smart memory cards such as U3 may contain two "children"—one will be a read/write disk and the other is reported as a CD-ROM). Such information cannot be retrieved after the Windows session ends.

Another way to gather the information is using the WMI classes (msdn.microsoft.com/library/). WMI is a method of gathering information from the Windows OS. WMI has different classes, each providing information and control on a different aspect of the OS. WMI classes can be accessed locally or remotely.

Using WMI to get the trails of devices previously connected to the computer can be done using PNP-related classes, such as Win32_PnPEntity, or using simple registry classes that give ability to read/write to the registry (StdRegProv). Safend Auditor uses the Setup API and WMI to get the forensics information in as many environments possible.

Another way for remotely gathering this forensics information is using the Remote Registry API. The Windows API functions responsible for reading/writing to the local registry can operate seamlessly on the remote machines, effectively offering a good way to remotely read all desired information.

But all these methods have an inherent flaw—they use inbound communications such as RPC calls to gather information remotely. An alternate method for auditing device forensics in an organization would be to run a local audit in the domain's start-up script. After users log on to the computer (when it is connected to the domain), an application runs and checks all the forensics data from the local computer. Data can then be sent to a central repository.

Conclusion

While we've focused on Windows 2000/XP/2003/ VISTA in this article, similar results may be found in operating systems such as Linux, Mac OS X, and Windows 9X, among others. It is important to note that device forensics has its limitations. There are devices that connect to the computer through USB or other ports, but do not interact with it. Such devices often just utilize the computer as a power source—a USB phone charger, for instance. These devices will not leave traces in the OS because they do not interact with it. Another drawback to device forensics is that data in the registry can be forged: If someone wants to incriminate a user, the registry can be edited and device connection data added.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.