G
Guest
Howdy,
I’m troubleshooting some systems that have 'something' changing the way
Windows XP Professional performs port name/ port number lookups against the
Windows Services file ("%SystemRoot%\System32\drivers\etc\services") on what
appears to be random privately owned systems. We have been unable to
replicate the problem on an internally owned system.
The basic symptoms are such that when using telnet.exe (or any other program
dependent on the services file like popupcli.exe) to connect to a system at a
named port rather than a system at a numbered port, the port name to number
translation fails as the services file cannot be located to perform the
translation. However, the services file is in the correct location, has the
correct entries, the correct permissions, and it is properly referenced
within the system registry.
Using a series of utilities from Sysinternals.com like RegMon and FileMon we
have pinpointed the problem but have been unable to find the cause or a
permanent solution. We have a hack that we feel might
temporarily/permanently resolve the problem; however, a more permanent
solution is preferred as when don’t know what new problems this hack will
cause down the road. Any assistance would be appreciated.
Here is a more in-depth description of the problem (pinpointed in item 2):
--------------------
1)
Programs that are dependent on the services file successfully query the
registry at
"HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DatabasePath" for
the location to the services file "%SystemRoot%\System32\drivers\etc\"
(RegMon). On a typical Windows XP Pro installation, this dynamic path should
resolve to “C:\WINDOWS\System32\drivers\etc\â€.
2)
Programs that are dependent on the services file then try to resolve path to
services file and end up getting a “PATH NOT FOUND†error (can been seen with
FileMon) because they resolved the services file to the following location
“C:\WINDOWS\system32\%SystemRoot%\System32\drivers\etc\services†which is
incorrect.
3)
On a functional system, we can see telnet.exe and popupcli.exe accessing the
services file correctly (FileMon) through the proper path lookup as specified
within the registry (RegMon).
4)
On both the problematic and functional systems, “%SystemRoot%†echo’s
correctly to “C:\WINDOWS†at the command prompt.
5)
As a hack, we tried changing the value on the registry key
“HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DatabasePath†to the
static value “C:\WINDOWS\System32\drivers\etc\†and found that this hack
fixed the problem.
6)
Reformatting the system resolves the problem confirming that the problem is
a software setting. We currently suspect the source of the problem to be
malware (spyware, viral, etc.) related; however, we have been unable to find
the case of the problem or how to undo the damage.
7)
Telnet’ing to a system with a specific port number rather than a named port
works on the busted systems because there is no need to reference the
services file.
--------------------
Specific to item 5, it appears that something within the internal system is
causing the dynamic path “%SystemRoot%†to incorrectly resolve in what only
appears to be specific cases per item 4. I feel that taking a look at how
the path to the services file is being incorrectly resolved is the key to the
problem; however, I have been unable to find the cause or how to fix it
outside of modifying the registry key to a non-dynamic value.
Correct Registry lookup for services file and correct path resolution within
application:
%SystemRoot%\System32\drivers\etc\
C:\WINDOWS\System32\drivers\etc\serivces
Correct Registry lookup for services file and bad path resolution within
application:
%SystemRoot%\System32\drivers\etc\
C:\WINDOWS\system32\%SystemRoot%\System32\drivers\etc\services
Any assistance would be appreciated. I have a list of the software
currently installed on some of the non-functional systems but I feel that
this is negligible as the software that may have caused the problem could
have been removed already. I have not looked through the list of currently
running processes. I believe viral scans were returning zero results;
however, the problem could have been caused by a past infection or undetected
payload. I haven’t yet looked at spyware scan results.
Thanks in advance for any assistance!
I’m troubleshooting some systems that have 'something' changing the way
Windows XP Professional performs port name/ port number lookups against the
Windows Services file ("%SystemRoot%\System32\drivers\etc\services") on what
appears to be random privately owned systems. We have been unable to
replicate the problem on an internally owned system.
The basic symptoms are such that when using telnet.exe (or any other program
dependent on the services file like popupcli.exe) to connect to a system at a
named port rather than a system at a numbered port, the port name to number
translation fails as the services file cannot be located to perform the
translation. However, the services file is in the correct location, has the
correct entries, the correct permissions, and it is properly referenced
within the system registry.
Using a series of utilities from Sysinternals.com like RegMon and FileMon we
have pinpointed the problem but have been unable to find the cause or a
permanent solution. We have a hack that we feel might
temporarily/permanently resolve the problem; however, a more permanent
solution is preferred as when don’t know what new problems this hack will
cause down the road. Any assistance would be appreciated.
Here is a more in-depth description of the problem (pinpointed in item 2):
--------------------
1)
Programs that are dependent on the services file successfully query the
registry at
"HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DatabasePath" for
the location to the services file "%SystemRoot%\System32\drivers\etc\"
(RegMon). On a typical Windows XP Pro installation, this dynamic path should
resolve to “C:\WINDOWS\System32\drivers\etc\â€.
2)
Programs that are dependent on the services file then try to resolve path to
services file and end up getting a “PATH NOT FOUND†error (can been seen with
FileMon) because they resolved the services file to the following location
“C:\WINDOWS\system32\%SystemRoot%\System32\drivers\etc\services†which is
incorrect.
3)
On a functional system, we can see telnet.exe and popupcli.exe accessing the
services file correctly (FileMon) through the proper path lookup as specified
within the registry (RegMon).
4)
On both the problematic and functional systems, “%SystemRoot%†echo’s
correctly to “C:\WINDOWS†at the command prompt.
5)
As a hack, we tried changing the value on the registry key
“HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DatabasePath†to the
static value “C:\WINDOWS\System32\drivers\etc\†and found that this hack
fixed the problem.
6)
Reformatting the system resolves the problem confirming that the problem is
a software setting. We currently suspect the source of the problem to be
malware (spyware, viral, etc.) related; however, we have been unable to find
the case of the problem or how to undo the damage.
7)
Telnet’ing to a system with a specific port number rather than a named port
works on the busted systems because there is no need to reference the
services file.
--------------------
Specific to item 5, it appears that something within the internal system is
causing the dynamic path “%SystemRoot%†to incorrectly resolve in what only
appears to be specific cases per item 4. I feel that taking a look at how
the path to the services file is being incorrectly resolved is the key to the
problem; however, I have been unable to find the cause or how to fix it
outside of modifying the registry key to a non-dynamic value.
Correct Registry lookup for services file and correct path resolution within
application:
%SystemRoot%\System32\drivers\etc\
C:\WINDOWS\System32\drivers\etc\serivces
Correct Registry lookup for services file and bad path resolution within
application:
%SystemRoot%\System32\drivers\etc\
C:\WINDOWS\system32\%SystemRoot%\System32\drivers\etc\services
Any assistance would be appreciated. I have a list of the software
currently installed on some of the non-functional systems but I feel that
this is negligible as the software that may have caused the problem could
have been removed already. I have not looked through the list of currently
running processes. I believe viral scans were returning zero results;
however, the problem could have been caused by a past infection or undetected
payload. I haven’t yet looked at spyware scan results.
Thanks in advance for any assistance!