How to fix broken security in Windows 2000?

  • Thread starter Thread starter Shannon Jacobs
  • Start date Start date
How to identify missing security certificates in Windows 2000? I am not
asking about every individual unique case, though there are many of them,
but about the general problem which apparently affects *EVERY* computer
which is still running Windows 2000.
Click to expand...

I haven't been following this thread, but it seems to me you would
need to identify every "executable" on your system and match them to
the certificates.

This may (or may not) be helpful to you.

http://www.microsoft.com/windows2000/techinfo/planning/security/eucertsteps.asp

As far as an automated way of doing this goes I am not aware of one.
 
Yes, that page was moderately helpful in providing some of the background
information, but at this point it is very old news. However, I thank you
(Greg Smith) for your attempt to help, and I will attempt to clarify in
light of your response.

I agree that the perfect solution would probably call for verifying every
executable file, but I think that is probably impossible, since many are not
signed, especially the older ones. In that sense, the general security
problem is unsolvable. However, my concern is slightly more limited than
that. I'm interested in the system files that Microsoft acknowledges
responsibility for, all of which are supposedly known and signed. The System
File Checker is supposed to perform this check in an automated fashion, and
it does for Windows XP (at least on every XP machine I've tested recently).
Unfortunately it fails on every tested Windows 2000 machine, but it does not
provide any detailed information about the failures.

You (in general, not limited to Mr. Smith) can test this by typing "sfc
/scannow" at a CMD prompt. When you get the first error message (with many
more to follow), I strongly recommend that you do *NOT* give it the CD it
requests, but rather that you cancel out of the test program. The error
messages do not provide any information about the details of the problem,
though in one case I did see a request for a different CD. (Usually it asks
for the Windows 2000 Professional CD.)

I feel like that's about all I can substantively say right now. So far there
has been no useful information revealed here in the Microsoft newsgroups,
though a security expert on our intranet says it is an old problem with W2K.
He actually thinks it goes all the way back to SP1. However, I still regard
that as provisional information since our company is (obviously) not part of
the Microsoft food chain.
 
File Checker is supposed to perform this check in an automated fashion, and
it does for Windows XP (at least on every XP machine I've tested recently).
Unfortunately it fails on every tested Windows 2000 machine, but it does not
provide any detailed information about the failures.
Click to expand...

I agree with you. W2K SFC could be more informative.

Maybe you knew this already, but SFC logs information on the file names it
is complaining about in the Windows System Event Log. It does not
necessarily tell you the reason.

I believe SFC on any W2K system will find lots of "missing" and "invalid"
files. The fact that it "finds" these things does not mean your computer is
having a problem that needs to be fixed. This SFC issue is not necessarily
related to any other problem your computers may be experiencing. Also, WFP
and SFC are still helpful in checking your files, it just checks lots of
other files as well.

I believe much of this is not because of missing certificates, but because
the catalog SFC uses might contain lots of extra files by design that are
not needed in your installation, or is incorrect, out of date or needs
refreshing. For example, on my system, it found lots of missing files such
as c:\winnt\system32\agt0804.dll that my system does not seem to need to
function properly. The problem can also occur if your system administrators
have intentionally deleted or put restrictive file ACL permissions on
"unsafe" files like TFTP.EXE from your \system32\dllcache\ folder to prevent
WFP from replacing the files and a hacker from using them, or if methods
other than the approved ones below have been used to distribute updated
Windows files:

http://www.microsoft.com/whdc/winlogo/drvsign/wfp.mspx

How SFC / WFP checks files is described somewhat here:

http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=38776

and here:

http://answers.google.com/answers/threadview?id=8227

"The following files are consulted:

Winnt\System32\CatRoot\SYSMAST.*
Winnt\System32\CatRoot\{F750...295EE}\CATMAST.*
Winnt\System32\CatRoot\{F750...295EE}\HASHMAST.*
Winnt\System32\CatRoot\{F750...295EE}\NT5.CAT "

I believe .CAT files like NT5.CAT contain lists of file hashes, but no file
names. NT5.CAT also mentions "VeriSign Time Stamping Service Root" which
may relate to the "VeriSign Time Stamping CA" cert Windows requires. New
patches install new *.CAT files containing new valid file hashes into the
CatRoot folder, but the article below suggests these are not used by a
manual SFC check:

http://www.winnetmag.com/Article/ArticleID/27471/27471.html

If you are asking how do you fix this issue with SFC finding lots of
"missing" files, I think the answer is you don't. It's an annoyance by
design, but by itself isn't proof that your system is broken or needs
fixing. If you're having other problems besides SFC, remind us of the
details and we can look at those.

Other SFC information and known issues are listed here:

http://labmice.techtarget.com/windows2000/FileMgmt/WFP.htm
The technical question:

How to identify missing security certificates in Windows 2000?
Click to expand...

The certificates that could affect SFC are the six certs mentioned in the MS
article you mentioned in your first post, plus the three certs mentioned in
the article I posted.

You seem to think that because that article did not solve your problem, that
there must therefore be other missing certificates that Microsoft is not
telling you about. I believe this is not the case. So, if you have already
confirmed you have no relevant missing certificates, and you don't need to
check for missing certificates, or ask here how to do so. If you are sure
all the certs in that article are in place and have the right dates, then I
don't think your problem is identifying missing certs.
 
How SFC / WFP checks files is described somewhat here:

http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=38776
Click to expand...
.CAT files like NT5.CAT contain lists of file hashes, but no file
names.
Click to expand...

Furthermore, note that SFC is simply checking file hashes, not file signing.
Comparing file hashes is done without using certificates.

If you need more evidence that certificate issues are not causing your SFC
issues, run SFC and search for the files it flags in Event Viewer on your
hard drive. [I'm not sure if you can get the log entries you need without
clicking Cancel hundreds of times, but you could try running SFC /quiet and
rebooting to see if that does it.]

If none of the files SFC logs are on your hard drive, then the problem is
definitely not certificates. If some of the files are on your hard drive,
then the results are inconclusive, but I still don't think the problem is
certificates. To make it easier for you to find all those files, you could
use Start, find, files or folders to search for all the file names all in
one search, separated by commas [for example,
filename1.dll,filename2.dll,filename3.exe]. Or you could try using Event
Viewer to right-click and save the log file to a .TXT file... then edit that
text file to be a batch file that uses the find /s command for each file.

I'm not saying you have to do all that work, but it would be one way to
prove to you that certificates are not involved in SFC. [Or you could just
read the above article at windowsitpro.com that says that file hashes are
used.]
 
Why thank you (Karl Levinson, mvp). I think this is your first helpful
contribution and it suggests the next path to pursue. You actually reminded
me of something I had forgotten during the original struggles to re-enable
SFC, during which time it was of course not logging anything. I'll continue
working on the problem as time allows.

However, I'd also like to know the real story of what or who reminded you.
 
However, I'd also like to know the real story of what or who reminded you.
Click to expand...

Eric Ice passed me the links. He's good. ;D

The real story is that I read your last description of the problem and then
searched Google.

Your last post caused me to think about this problem as an SFC problem
instead of as a certificate problem. Your post mentioned just the details
of the actual SFC symptoms, and gave details that allowed me to replicate
the problem. Perhaps you gave those details about SFC earlier in the
thread; if you did, it's possible I overlooked those details by
concentrating on the discussion about certificates instead.
 
Back
Top