Remote access to the machine's registry is often a frowning thing; after all, do you want others to view your registry without you knowing it? However, if handled correctly, this process can be a powerful tool for extracting machine information and identifying potential vulnerabilities in your network. Here, Brian uses his experience with WebSphere Business Integrator Team to describe how remote registry access allows you to extract information from multiple machines — and identify those vulnerable systems. This article also includes code samples.
Tracking machines proves very difficult in a software development testing environment, especially when the number of machines reaches double digits. Which machine is used what software? What version of NT is used? What is the level of a service pack? What revisions are installed? You can walk to each machine to check all these problems manually, but when the machine is scattered in a wide area, doing so can be a very time-consuming process.
In such a situation, it would be useful if there is a way to get information about that machine without actually using a certain machine and without installing additional software. The collected information can then be used to allocate resources and identify machines that may be vulnerable to malicious users and programs. This article describes certain aspects of leveraging remote registry access.
Warning: By using the remote registry features described in this article, you can save a lot of time in system administration. But be careful, because editing another system's registry is as dangerous as editing your own (if not more dangerous than editing your own).
Take advantage of the installation function
In the WebSphere Business Integrator (WSBI) test environment here, we have about 40 test machines that are geographically scattered throughout the Hursley lab in the UK. During the initial testing phase, our focus was mainly on the installation and configuration of WSBI. Continuously installing and reinstalling various products and service packs and essential software on a test machine—the entire operating system must usually be reinstalled. Soon, we found it was nearly impossible to monitor the status of each test machine. We need a way to quickly know the state of each machine without having to access it.
In a WSBI installation, we have installed and configured about 15 IBM products in a single installation package—for example, DB2 V7.2, MQSeries V5.2, HTTP Server V1.3.12. Just like for all good installers, before any installation begins, check the target machine to make sure it meets the prerequisites for the software to be installed—such as service pack level and related products. This check is usually done in the InstallShield script by writing a registry script to check the relevant values.
For example, one of the most common checks is to verify the NT service pack level. The registry keys under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion will appear in .
When querying a registry key in a script, you need to know three things:
The key name to query — In this example, it is the name of the value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion key, here is "CSDVersion"
The type of value being queryed, here is a string value
Use the InstallShield script function RegDBGetKeyValueEx to perform registry queries. But suppose you want to check what level of service pack is installed. Listing 1 shows how this can be achieved.
Listing 1. Extract service package level
STRING szKey, szName, svServicePackVersion；
NUMBER nvType, nvSize；
begin
svKey = "；SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion"；；
svName = "；CSDVersion"；；
nvType = REGDB_STRING；
RegDBGetKeyValueEx （szKey, szName, nvType, svServicePackVersion, nvSize）；
end; Listing 1 returns the value "Service Pack 6" and stores it in svServicePackVersion. Then, you can know that Service Pack 6 is installed on this machine. By performing various queries like this, it is possible to determine the configuration of a machine and what software is installed on it.
Our lab work has made breakthrough progress when we realized that these queries can be performed on the registry of remote machines.
Connect to the remote registry
To access the registry on the remote machine through scripts, administrator privileges on the remote machine are required. We found that when running our script, it is a difficult problem to have a user account with administrator privileges on the remote machine and use this username and password to log in to the machine where the script is running.
Suppose in our WSBI testing environment, there are three test machines, using a fourth as an audit machine. On each test machine, we need to add a user account and give it administrator privileges; we name the user name "auditor" and give it the password "angelus". This is the only operation that needs to be performed manually on each machine. These accounts on each test machine now allow us to access the registry of each machine through scripts running on the audit machine.
Now suppose we log in to AuditMachine with the account we just created (user name "auditor" and password "angelus"). The next step is to rerun the script on Listing 1, but this time instead of checking the local registry, I want to know the service pack level of the machine "Gunn", so we need to connect to its registry. To do this, we use the command RegDBConnectRegistry. This function creates a connection to the remote registry. To connect to Gunn, the command looks like:
RegDBConnectRegistry （"Gunn" , HKEY_LOCAL_MACHINE, 0 ）；
Put it in the script, then we get:
Listing 2. Service Pack Level for Remote Extraction Machine Gunn
begin
RegDBConnectRegistry （"；Gunn"； , HKEY_LOCAL_MACHINE, 0 ）；
svKey = "；SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion"；；
svName = "；CSDVersion"；；
nvType = REGDB_STRING；
RegDBGetKeyValueEx （szKey, szName, nvType, svServicePackVersion, nvSize）；
end；
If all goes well, we can now access Gunn's registry and extract the service pack level.
Next, by replacing "Gunn" with the corresponding name that represents the other two machines in the RegBConnectRegistry command, and then running the same process; we can extract the service package level of these two machines.
We noticed that it is inefficient to input the same code three times repeatedly, so a loop mechanism can be used to take turns querying the registry of each machine. All information that needs to be entered is the name of each machine. This can be done by creating a text file, in which each line contains the name of a machine. So, suppose we have created a text file named , which enters the names of the three machines we want to query and saves it in the root directory of the C drive. Now we can further modify the script to read these machine names into a list structure and connect to each machine's registry in turn.
Listing 3. Extract service pack levels from multiple machines
begin
listMachines = ListCreate（STRINGLIST）；
ListReadFromFile （listMachines, "；c:\\"；）；
nResult = ListGetFirstString （listMachines, svMachineName）；
while （nResult != END_OF_LIST）
RegDBConnectRegistry （svMachineName , HKEY_LOCAL_MACHINE, 0 ）；
svKey = "；SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion"；；
svName = "；CurrentVersion"；；
nvType = REGDB_STRING；
RegDBGetKeyValueEx （svKey, svName, nvType, svServicePackVersion, nvSize）；
nResult = ListGetNextString （listMachines, svMachineName）；
endwhile；
end；
The above code will read a machine name from the file, connect to its registry, query, and then continue to move to the next machine named in the text file. The advantage of using this approach is that by simply editing the names in the file, we can add and remove machines very easily during the audit process.
Output information
By now, you may have noticed that when we execute these queries, no output has been generated. So, now let's discuss the best way to determine the output. Our team decided to format the output as an XML file, because this allows us to browse the retrieved information and allows any other application we may develop to take advantage of this data. Listing 4 shows the XML file generated with the appropriately named tag.
Listing 4. Extract service pack levels from multiple machines and output to XML files
； begin
CreateFile （nvFileHandle, "；C:\"；, "；"；）；
WriteLine（nvFileHandle, "；<；?xml version="；1.0"；?>；"；）；
WriteLine（nvFileHandle, "；<；audits&；gt；"；）；
listMachines = ListCreate（STRINGLIST）；
ListReadFromFile （listMachines, "；c:\"；）；
nResult = ListGetFirstString （listMachines, svMachineName）；
while （nResult != END_OF_LIST）
RegDBConnectRegistry （svMachineName , HKEY_LOCAL_MACHINE, 0 ）；
svKey = "；SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion"；；
svName = "；CurrentVersion"；；
nvType = REGDB_STRING；
RegDBGetKeyValueEx （svKey, svName, nvType, svServicePackVersion, nvSize）；
WriteLine（nvFileHandle, "；<；MachineName&；gt；"；）；
WriteLine（nvFileHandle, "；<；ServicePack&；gt；"； + svCSDVersion+ "；<；/ServicePack&；gt；"；
WriteLine（nvFileHandle, "；<；/MachineName&；gt；"；）；
nResult = ListGetNextString （listMachines, svMachineName）；
endwhile；
WriteLine（nvFileHandle, "；<；/audits&；gt；"；）；
CloseFile（nvFileHandle）
end; If we run Listing 4 on AuditMachine (assuming we have included the name of our target machine) and our audit account is set up correctly, we will generate an output file named . We can then browse this file and see what the service pack level is on each machine.
In our example, by extracting single segment information from three machines, we perform a small audit. In theory, there is no limit on how many machines can be extracted from or how much information can be extracted in this way. In the WSBI tests here, we currently audit about 40 machines per time. Using the techniques described here, our current audit system can determine:
Is the machine running NT or 2000
Whether the service package has been applied
What revisions are installed
Is Norton Anti-Virus installed?
What IBM products are installed and what level are
For each audit, the principles involved are exactly the same as in our example:
Read the list of machine name or IP address
Take turns connecting to the remote registry of each machine
Extract information from the registry of each machine
Here is an example of a complete audit of a machine.
This information collected in a single resource library of XML files gives us an extremely clear understanding of our testing environment and allows us to manage hardware resources more efficiently. Further expanding the principle
So far, we have only queryed the registry of the remote machine. However, it is not limited to queries. It is also possible to edit the registry of the remote machine.
Going back to our example, let's say those machines are in three different rooms—Gunn at “The War Room,” Wesley at “The Test Cell,” Cordelia at “Room 101.” If we could introduce some methods to include machine locations in XML files, this would make our audit easier. One solution is to place an extra key in the registry to indicate the location of the machine. Using , under the key HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MachineLocation, we create a new string value called "location".
But if there are many machines, it would be not ideal to traverse each machine and manually create each position key. A better way is to remotely insert the value into each machine. The execution method is exactly the same as the method of retrieving registry values. First, connect to the remote registry:
RegDBConnectRegistry （"Gunn" , HKEY_LOCAL_MACHINE, 0 ）；
Next, set the registry value:
svKey = "；SOFTWARE\\IBM\\MachineLocation"；；
svName = "；Location"；；
nvType = REGDB_STRING；
svLocation = "；The War Room"；
Finally, perform the registry operation. This time, we use RegDBSetKeyValueEx, which sets the registry value (as its name indicates).
RegDBSetKeyValueEx （svKey, svName, nvType, svLocation, nvSize）；
Then, the audit process can query this key. This method can also be used to update or even delete the registry key, although it is very dangerous to delete the key from the remote registry.
advantage
The main advantages of auditing of this method are:
It removes the need to install any third-party software on the test machine and therefore the potential interference caused; all that needs to be done is to create a user account on each machine.
Your audit process can be easily adjusted by modifying those registry keys you want to query and the machine you want to audit in the script.
This audit process does not interfere in any way the operations performed on the machine being audited. The user of that machine had no idea the audit occurred. The complete audit XML file included earlier in this article can be generated in 5 seconds. Improve safety
Malicious user
There is no better way to break a machine than to randomly change the contents of the registry, so malicious users can access your registry remotely. However, since the remote-registry account we set up before is an administrator user, we can limit the remote registry access to the administrator by performing the following steps.
Run .
Open the following registry keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\WinReg。
Click the WinReg key and select Permissions from the Security drop-down menu. Make sure only administrators with full control appear in the box. To completely restrict all remote-registry access, remove all names from the box.
Malicious programs: Identify vulnerable machines
The main way malicious programs enter the system is to exploit security vulnerabilities in the operating system. We all know that recent "Code Red" and similar viruses have raised many problems. Patches that plug these vulnerabilities are usually available months before those viruses exploiting them run rampantly, but in a multi-machine environment, how can you identify which machines are vulnerable? The installation of patches or revisions always leaves traces in the registry. Open Regedit and browse to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix, listing all currently installed revisions. For example, a patch that prevents "red code" viruses is called Q300972. On a machine with this revision installed, under the keys shown above, there will be a key called Q300972. Therefore, by looking up this key during the audit, we can identify any machines without patches installed and process them accordingly.
Anti-virus software is a necessary part of any security implementation, but some machines may not have anti-virus software installed, or the software may be outdated, making them vulnerable to attacks. Remote registry calls can be used to find these machines.
Installing any antivirus software will leave some traces in the registry. Assume that on our system, after installing the antivirus software, it leaves the following traces in the registry:
The audit can then look for these values to identify machines that do not have anti-virus software installed or anti-virus software that needs to be updated.
If you look at the audit examples provided earlier, you will notice that two checks of this nature are performed. Our audit checks if the "red code" revision exists, checks the anti-virus software and extracts its version.
Conclusion
This article describes how it becomes a valuable tool for extracting information about multiple machines and identifying vulnerable machines when carefully using remote registry access. You can use the examples in this article as a starting point for creating your own related variants. By using it and the included source code, you should find it very easy to implement the remote registry tool in your own environment.
(Source: Rising Anti-Virus Information Network)