Remote access to the machine's registry is usually a frown; after all, do you want someone else to see your registry without your knowledge? 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 work experience in the WebSphere Business Integrator team to describe how remote registry access allows you to extract information from multiple machines-and identify vulnerable systems. This article also includes a sample code.
In a software development test environment, tracking machines proved to be very difficult, especially when the number of machines reached two digits. What software is used on which machine? What version of NT is used? What is the level of the service pack? What revisions are installed? You can walk to each machine and check all of these problems manually, but it can be a time-consuming process when the machine is dispersed in a wide area.
In such a case, it would be useful if there was a way to get information about the machine without actually using a machine and installing additional software. The information collected can then be used to allocate resources and identify machines that may be vulnerable to malicious users and programs. This article describes some aspects of taking advantage of remote registry access.
Warning: By using the remote registry features described in this article, you can save a lot of time in system administration. Be careful, however, because editing the registry of another system is as dangerous as editing your own registry (if not more dangerous than editing your own).
Using the installation features
Here in the WebSphere Business Integrator (WSBI) test environment, we have about 40 test machines that are geographically dispersed throughout the UK Hursley Labs. During the initial testing phase, our focus was mainly on the installation and configuration of the WSBI. Constantly installing and reinstalling various products and service packs and prerequisite software on the test machine-you typically have to reinstall the entire operating system. Soon, we found it almost impossible to monitor the status of each test machine. We need a way to quickly know the state of the machine without having to access each machine.
In the WSBI installation, we have installed and configured approximately 15 IBM products in a single installation package-for example, DB2 V7.2, MQSeries V5.2, and HTTP Server V1.3.12. As with all good installers, check the target machine before any installation starts to make sure it meets the prerequisites for the software you are installing-such as service pack levels and related products. This check is usually done by writing a registry script to check the correlation values in the InstallShield script.
For example, one of the most common checks is to verify the NT service pack level. Keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows The registry entries under NT\CurrentVersion, which appear in Regedit.exe.
When querying a registry key in a script, you need to know three things:
The key name to query-in this case, the name of the value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion key, here is "CSDVersion"
The value type being queried, here is a string value
Use the InstallShield script function Regdbgetkeyvalueex to execute a registry query. But suppose you want to check what level of service packs are installed. Listing 1 shows how this can be achieved.
Listing 1. Pull Service Pack 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. You can then know that Service Pack 6 is installed on this machine. By executing a variety of queries like this, you may determine the configuration of a machine and what software is installed on it.
When we realized that we could execute these queries on the remote machine's registry, we made a breakthrough in our lab work.
Connect to Remote Registry
To access the registry on a remote machine through scripting requires administrator privileges on the remote machine. We found that when we ran our script, it was a challenge to have a user account with administrator privileges on the remote machine and to log on to the script running machine with this username and password.
Suppose in our WSBI test environment, there are three test machines, using the fourth station as the audit machine. On each test machine, we need to add a user account and give it administrator privileges; We name the username "auditor" and give it the password "Angelus". This is the only action that needs to be performed manually on each machine. These accounts on each of the test machines now allow us to access the registry of each machine by auditing the script running on the computer.
Now let's assume that we're logged in to auditmachine with the account we just created (username "auditor", password "Angelus"). The next step is to rerun the script on listing 1, but this time not to check the local registry, but rather 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 feature creates a connection to the remote registry. To connect to Gunn, this command is similar to the following:
If all goes well, we can now access the Gunn registry and extract the service pack level.
Next, replace "Gunn" with the corresponding name in the Regbconnectregistry command that represents the other two machines, and then run the same process, and we can extract the service pack levels for both machines.
We note that three times the same code is inefficient, so you can use a looping mechanism to query the registry of each machine in turn. All the information you need to enter is the name of each machine. This can be done by creating a text file in which each row contains the name of a machine. So let's say we've created a text file called MachineList.txt that has entered the names of the three machines we want to query and saves it in the root directory of C disk. Now we can further modify the script to read the machine names into a list structure and connect to each machine's registry in turn.
Listing 3. Pull service pack levels from multiple machines
The above code reads a machine name from the MachineList.txt file, connects to its registry, queries, and then continues to move to the next machine named in the text file. The advantage of using this method is that by simply editing the name in the MachineList.txt file, we can easily add and remove machines from the audit process.
Output information
So far, you may have noticed that when we executed these queries, no output was produced. So, let's talk about determining the best way to represent the output results. Our team decided to format the output as an XML file because it allows us to browse through the retrieved information and allow any other applications that we might develop to take advantage of that data. Listing 4 shows the XML file that was generated with the appropriately named tag.
Listing 4. Extract service pack levels from multiple machines and output to XML files
WriteLine (Nvfilehandle, ";<;/audits&;gt;";);
CloseFile (Nvfilehandle)
If we run Listing 4 on the auditmachine (assuming we have the name of our target machine MachineList.txt) and our audit account is set up correctly, we will generate an output file named Audit.xml. Then, we can browse the file and see what the service pack level is on each machine.
In our example, we performed a small audit by extracting a single piece of information from three machines. Theoretically, there is no limit on how many machines can be extracted or how much information may be extracted in this way. In the WSBI test here, we currently audit about 40 machines each time. Using the techniques described here, our current audit system can determine:
is the machine running NT or 2000?
Whether the service pack has been applied
What revisions are installed
is the Norton anti-virus installed
Which IBM products are installed and what level
For each audit, the principle involved is exactly the same as in our example:
Read the list of machine names or IP addresses
The remote registry that is connected to each machine in turn
Extract information from the registry of each machine
This shows an example of a complete audit of a machine.
This information, collected in a single repository of XML files, gives us an extremely clear picture of our testing environment and enables us to manage hardware resources more effectively. Further expand the principle
So far, we have only queried 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.
Back to our example, suppose those machines are located in three different rooms-gunn in the "The War Room", Wesley in "The Test Cell", Cordelia in "Room 101". If we could introduce some of the methods that would include the location of the machine in the XML file, this would make our audit easier. One solution is to place an extra key in the registry to represent the location of the machine. Using Regedit.exe, under the key hkey_local_machine\software\ibm\machinelocation, we created a new string value named "Location".
But if you have a lot of machines, it's not ideal to traverse each machine and create each location key manually. The better approach is to plug the values into each machine remotely. The method executed is exactly the same as the method that retrieves the registry value. First, connect to the Remote registry:
The audit process can then be queried for this key. You can also update and even delete registry keys in this way, although removing keys from the remote registry is very dangerous.
Advantages
The main advantages of the audit of this approach are:
It eliminates the need to install any Third-party software on the test machine, and therefore eliminates the potential interference that is generated; all that is required is to create a user account on each machine.
You can easily adjust your audit process by modifying the registry keys that you want to query in your scripts and the machines you want to audit.
This audit process does not interfere in any way with the operation being performed on the machine being audited. The user of that machine is completely unaware of the audit. The complete audit XML file contained earlier in this article can be generated in 5 seconds. Improve security
A malicious user
There is no better way to break a machine than to make a random change to the contents of the registry, so a malicious user accessing your registry remotely will be a disaster. However, since the remote-registry account We set up previously is an administrator user, we can restrict remote registry access to administrators by performing these steps.
Click the WinReg key, and then select Permissions (Permissions) from the Security Drop-down menu. Make sure that only administrators with full control appear in the box. To completely limit all remote-registry access, remove all names from the box.
The main way that malicious programs enter the system is to exploit the security vulnerabilities of the operating system. We all know that the recent "Code Red" and similar viruses have led to many problems. Patches that plug these vulnerabilities are usually available a few months before the exploited virus runs rampant, but how can you identify which machines are vulnerable in a multiple-machine environment? 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 the revisions that are currently installed. For example, patches that prevent the "Red Code" virus are called Q300972. On a machine with this revision installed, there will be a key called Q300972 under the key shown above. Therefore, using the techniques described here, we can identify any machines that do not have patches installed and process them accordingly by locating the key during the audit.
Anti-Virus software is an essential part of any security implementation, but some machines may not have anti-virus software installed, or the software may be obsolete, making their portals vulnerable to attack. Remote registry calls can be used to locate these machines.
Installing any anti-virus software will leave some traces in the registry, assuming that on our system, after the anti-virus software is installed, it leaves the following traces in the registry:
The audit can then look for these values to identify the machines that do not have anti-virus software installed or antivirus software that needs to be updated.
If you look at the audit examples provided earlier, you will notice that two checks of this nature have been performed. Our audit examined the existence of the "Red Code" revision, checked the anti-virus software and extracted its version.
Conclusion
This article describes how it becomes a valuable tool to extract information about multiple machines and identify vulnerable machines when using remote registry access with care and accuracy. You can use the examples in this article as a starting point for creating your own related variants. By using it and the source code contained, you should find it easy to implement the Remote Registry tool in your own environment.
(Source: Rising anti-virus information Network)
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
