Windows Server 2003 Security Guide available

[Michael Howard]

Microsoft Security Solutions is happy to announce the release of the
_Windows Server 2003 Security Guide_ and its companion guide, _Threats
and Countermeasures: Security Settings in Windows Server 2003 and
Windows XP_.=20

The new guides provide detailed security guidance on Microsoft Windows
Server 2003(tm) that is authoritative, proven, and tested. The guides
are designed to allow users to assess and mitigate a wide range of
significant security issues that may exist in their environment.

The Windows Server 2003 Security Guide provides easy to understand
guidance, tools, and templates to effectively secure Windows Server 2003
in a variety of enterprise environments. While the default installation
of the product is designed to be secure, a number of security settings
can be further configured based on specific requirements and scenarios.=20

The Windows Server 2003 Security Guide consists of 12 chapters. Each
chapter builds on the end-to-end process required to implement and
secure Windows Server 2003 in a customer environment. The first few
chapters describe building the foundation for hardening the servers in
your organization; the remaining chapters document the procedures unique
to each server role.

The companion guide, Threats and Countermeasures: Security Settings in
Windows Server 2003 and Windows XP, provides a reference to many of the
security settings available in the current versions of the Microsoft(r)
Windows(r) operating systems.=20
For each setting discussed in this guide, information is provided
regarding the threat that the setting was designed to prevent, the
different countermeasures that can be applied, and the potential impact
of configuring these options.=20

The guides can be found online at:

Windows Server 2003 Security Guide:
http://go.microsoft.com/fwlink/?LinkId=3D14845

Threats and Countermeasures: Security Settings in Windows Server 2003
and Windows XP
http://go.microsoft.com/fwlink/?LinkId=3D15159

MSS Glossary:
http://go.microsoft.com/fwlink/?LinkId=3D16256


Cheers, Michael
Writing Secure Code 2nd Edition=20
http://www.microsoft.com/mspress/books/5957.asp

[Jason Coombs]

For all the progress Microsoft has made lately in understanding security, it's
the simple things that most of us take for granted as obvious that still get
overlooked for some reason.

Microsoft does not distribute these guides using SSL, so the distribution is
vulnerable to MITM attacks.

Anyone interested in downloading these guides must be aware that they are
distributed by Microsoft in the form of self-extracting .exe's bearing digital
signatures embedded in the Portable Executable file's header section. A
properly-constructed malicious .exe could, in principle, embed malicious code
in a PE file header such that the digital signature verification feature of
Windows Explorer could be attacked as signature verification is performed.
Therefore, trusting Windows Explorer to verify the digital signature applied
to .exe's that you download from an untrustworthy remote server (one that does
not use SSL, for example) may itself result in the execution of arbitrary
malicious code selected by the MITM.

Assuming that you're willing to take this risk (which you should do on an
isolated test box for extra safety) you must also be aware that Microsoft
doesn't bother to tell you how you will know if the .exe's signature is the
one they applied; here is what appears to be the public key and thumbprint for
each signature, if you see anything else you should assume that the .exe is
not trustworthy (why Microsoft insists on distributing .exe's for
documentation is another question that we'll probably never get answered):

Each file appears to be signed with the following certificate chain:

certificate subject:

CN = Microsoft Corporation
OU = Copyright (c) 2002 Microsoft Corp.
O = Microsoft Corporation
L = Redmond
S = Washington
C = US

certificate issuer:

CN = Microsoft Code Signing PCA
OU = Copyright (c) 2000 Microsoft Corp.
O = Microsoft Corporation
L = Redmond
S = Washington
C = US

root certificate:

CN = Microsoft Root Authority
OU = Microsoft Corporation
OU = Copyright (c) 1997 Microsoft Corp.

certificate public key:

3082 010A 0282 0101 00AA 99BD 39A8 1827 F42B 3D0B 4C3F 7C77 2EA7 CBB5 D18C
0DC2 3A74 D793 B5E0 A04B 3F59 5ECE 454F 9A79 29F1 49CC 1A47 EE55 C208 3E12
20F8 55F2 EE5F D3E0 CA96 BC30 DEFE 58C8 2732 D085 54E8 F091 10BB F32B BE19
E503 9B0B 861D F3B0 398C B8FD 0B1D 3C73 26AC 572B CA29 A215 9082 15E2 77A3
4052 038B 9DC2 70BA 1FE9 34F6 F335 924E 5583 F8DA 30B6 20DE 5706 B55A 4206
DE59 CBF2 DFA6 BD15 4771 1925 23D2 CB6F 9B19 79DF 6A5B F176 0579 29FC C356
CA8F 4408 8555 8ACB C80F 464B 55CB 8C96 774A 87E8 A941 06C7 FF0D E968 5763
72C3 6957 B443 CF32 3A30 DC1B E9D5 4326 2A79 FE95 DB22 6724 C92F D034 E3E6
FB51 4986 B83C D025 5FD6 EC9E 0361 87A9 6840 C7F8 E203 E6CF 0502 0301 0001

The files are as follows:

Windows Server 2003 Security Guide:
http://go.microsoft.com/fwlink/?LinkId=14845

filename: Windows_Server_2003_Security_Guide.exe
size: 2.33 MB (2,452,088 bytes)

timestamp: Thursday, April 24, 2003 1:31:41 PM

signature sha1 hash: 04 14 4A 56 67 F6 CF 44 58 E4 05 F9 76 54 3C 03 8F 01 73
7A 5A ED

file's SIP sha1 hash:
66-61-CF-B9-0B-EB-F5-A8-37-5A-F4-A2-B7-10-57-BE-6B-F5-83-72

full-file sha1 hash: 6661cfb90bebf5a8375af4a2b71057be6bf58372

--

Threats and Countermeasures: Security Settings in Windows Server 2003
and Windows XP
http://go.microsoft.com/fwlink/?LinkId=15159

filename: Threats_and_Countermeasures_Guide.exe
size: 1.45 MB (1,522,296 bytes)

timestamp: Thursday, April 24, 2003 1:31:11 PM

signature sha1 hash: 04 14 FF 07 49 0F 8B 6A 38 DF BD B9 85 5F 43 54 04 D7 8F
7D 6C 1B

file's SIP sha1 hash:
2C-14-BE-90-4D-47-A9-66-56-07-20-72-1C-C3-3B-9D-76-23-6D-13

full-file sha1 hash: 2c14be904d47a966560720721cc33b9d76236d13

--

MSS Glossary:
http://go.microsoft.com/fwlink/?LinkId=16256

filename: Microsoft_Solutions_for_Security_Glossary.exe
size: 494 KB (506,440 bytes)

timestamp: Thursday, April 24, 2003 10:52:16 AM

signature sha1 hash: 04 14 9C 95 C3 92 93 D6 E1 B7 99 AA A2 EE 42 D9 00 7F E8
DE 15 17

file's SIP sha1 hash:
51-96-51-F5-0F-94-FD-33-79-CA-63-E9-36-63-59-5D-6F-D0-E1-FC

full-file sha1 hash: 519651f50f94fd3379ca63e93663595d6fd0e1fc

--

For each file listed above there is a "full-file sha1 hash" which can be
verified using any full-file sha1 hashing utility. Microsoft does not provide
any such utility, so this is by far the most trustworthy method to ascertain
that the file is what you expect it to be.

For each file listed above, the "file's SIP sha1 hash" is the sha1 hash
produced using the Microsoft Crypto API's SIP hashing provider. The following
C# code will produce this hash for you on the command line, so that you can
verify the SIP hash of each .exe file before you attempt to verify its
attached digital signature:

using System;
using System.Security.Cryptography;
using System.IO;

namespace sha1hasher
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
HashAlgorithm sha = SHA1Managed.Create();
FileStream fs;
byte[] hash;
FileInfo[] fi = new
DirectoryInfo(Directory.GetCurrentDirectory()).Get Files();
foreach(FileInfo f in fi)
{
try
{
fs = f.Open(FileMode.Open);
hash = sha.ComputeHash(fs);
System.Console.WriteLine(f.Name + ": " + BitConverter.ToString(hash));
fs.Close();
}
catch(Exception ex) {
System.Console.WriteLine(ex);
}
}
}
}
}

Microsoft makes this all much more complicated than it needs to be, which is a
vulnerability in and of itself.

I strongly urge Microsoft to stop distributing documentation in .exe format,
as this whole method of digital signature management is ill-conceived and
poorly-implemented.

If you encounter any hash other than the ones listed above, report it to
Microsoft. You can also e-mail me and I'll assist you in determining the
reason for the hash verification failure. This is no more, and no less, than
Microsoft themselves should be offering to do, considering that they are the
ones placing you at risk by refusing to follow industry standard best
practices.

For every .exe that Microsoft distributes, it should consider publishing a
known good full-file hash code so that a hash verification tool of the user's
choice can be used, on a platform of the user's choice, to verify that the
file received over the network is the file they expected -- BEFORE attempting
to use a tool like Windows Explorer to read structured information such as
digital signature data out of the PE file's header sections. Each such attempt
to interpret structured data from inside the PE file's header sections may
result in a buffer overflow attack if there are exploitable bugs present in
the tool used to parse these structured data fields.

Sincerely,

Jason Coombs
jasonc@science.org

-----Original Message-----
From: Michael Howard [mailto:mikehow@microsoft.com]
Sent: Thursday, April 24, 2003 6:36 PM
To: bugtraq@securityfocus.com
Subject: Windows Server 2003 Security Guide available


Microsoft Security Solutions is happy to announce the release of the
_Windows Server 2003 Security Guide_ and its companion guide, _Threats
and Countermeasures: Security Settings in Windows Server 2003 and
Windows XP_.

....

The guides can be found online at:

....

[Jason Coombs]

> what stops them from generating a new SHA-1 or MD5 hash?

The hash is communicated through a different channel. If somebody forges
Microsoft's announcement message or intercepts and changes it during delivery
(omnipotent MITM) then a fake hash can be planted as you suggest. However, the
omnipotent MITM is far less likely than the DNS hijacking/spoofing/poisoning
MITM. The latter can only do harm to outbound requests; inbound traffic
doesn't pass through the hands of the DNS hijacker.

Consider also that in the real world people have friends. Friends also receive
announcements from Microsoft. With hashes friends can cross-check against each
other, whereas this is not practical with signatures. The only way a malicious
attacker could fool everyone is to send forged communications on a large scale
that fools even Microsoft into believing that the forged message was in fact
authentic. If Microsoft fails to monitor, from an outside vantage point, the
communications that appear to be originating from its corporate identity, then
this too is a severe vulnerability; one that we can be certain somebody will
exploit successfully.

> While hashes can verify the integrity of a file, it doesn't do anything
> to verify the authenticity of a file. That can only be done through a
> signature.

Signatures do not accomplish authenticity verification. The very definition of
authenticity refers back to my previous paragraph: did Microsoft really send
out the e-mail announcement that caused you to click the supplied hyperlink?
You have no way to know. Suppose you rely on signatures attached to e-mail and
there are no bugs in the software that produces and verifies these signatures.
How do you know that Microsoft really sent the signed e-mail? You have no way
to know. It is possible that a malicious attacker gained access to the
computer on which Microsoft's digitally-signed communications originate. Even
without access to Microsoft's private key per se, such attacker could send a
perfectly convincing digitally signed message with instructions that you would
have no reason not to follow.

The protection you get from the fact that a community of your peers and
friends also receive the same communication from Microsoft, and the protection
you get from the presumption that Microsoft knows when they send out
communications so that they could detect unauthorized transmissions, combined
with the community-based incident response in the event of forged or
unauthorized signed communications together represent the true security in
this whole scenario. The security is NOT based on technology, but on common
sense and intelligent, informed, alert people who are aware of the potential
risks. Microsoft and other vendors have convinced you that digital signatures
eliminate risks, and this is an outright lie that results in the elimination
of our only real defenses.

If Microsoft really does monitor the communications that appear to originate
from its mouth(s) and they have a master list of authentic communications, why
on earth won't they share that list with the public? It would look a heck of a
lot like a list of authentic hashes of known-good authentic communications
(and code) that Microsoft believes they originated on purpose. A secure
channel (not foolproof-secure, simply secure-by-a-different-dependency) giving
you access to Microsoft's master list of authentic hashes (a Web site
employing SSL, for instance) would be extremely valuable to the ultimate goal
of proving authenticity. It would also rely on a non-technical mechanism for
its operation: human literacy.

> In a perfect world, MS would make their white papers available in an
> widely adopted standard like PDF or PS files, and sign them

To "sign them" Microsoft would presumably utilize their own Portable
Executable file format to attach signature data as they do presently.
Unfortunately, PDF and PS files are not PE's thus they cannot be signed in
this manner.

It would appear that one of the reasons Microsoft distributes executables
rather than PDF and PS files is that they have not built any non-PE mechanism
for managing signatures applied to files. Distributing a block of signature
data separate from the signed file poses the very same circular logic problem
you point out regarding authentic hashes.

Sincerely,

Jason Coombs
jasonc@science.org

-----Original Message-----
From: Frank Knobbe [mailto:fknobbe@knobbeits.com]
Sent: Monday, April 28, 2003 7:53 PM
To: jasonc@science.org
Cc: bugtraq@securityfocus.com
Subject: RE: Windows Server 2003 Security Guide available


On Fri, 2003-04-25 at 16:27, Jason Coombs wrote:
> [...]
> For every .exe that Microsoft distributes, it should consider publishing a
> known good full-file hash code so that a hash verification tool of the
user's
> choice can be used, on a platform of the user's choice, to verify that the
> file received over the network is the file they expected -- BEFORE
attempting
> to use a tool like Windows Explorer to read structured information such as
> digital signature data out of the PE file's header sections.
> [...]

Jason,

I'm not sure how much a file hash will do to alleviate your concern
about MITM attacks. If for example MS web site gets hijacked, or somehow
else someone is able to replace the downloadable files, what stops them
from generating a new SHA-1 or MD5 hash?

While hashes can verify the integrity of a file, it doesn't do anything
to verify the authenticity of a file. That can only be done through a
signature. Of course that requires you to actually trust such a
signature/signer and trust in the method of verifying these signatures.

It sounds like you find flaws in the signature verification of Explorer.
While I agree that is substandard (how many patches are unsigned, but
people install them anyway?), I do believe that only signatures can
correct the deficiency you outline.

In a perfect world, MS would make their white papers available in an
widely adopted standard like PDF or PS files, and sign them using
PGP/GPG. But since this is not a perfect world, and we have to accept
proprietary .doc files or OS dependent executables, why not use a sub
optimal verification process?

Regards,
Frank

[paul]

Jason Coombs wrote:

> Anyone interested in downloading these guides must be aware that they
> are distributed by Microsoft in the form of self-extracting .exe's
> bearing digital signatures embedded in the Portable Executable file's
> header section.

Obviously use self-extracting .exes is a ludicrous idea from a security
point of view, however, at least you don't have to run them:

$ wget
"http://download.microsoft.com/download/3/7/f/37fcf915-c19e-4c09-8b05-1573ea58b164/W2KHG 1.1.exe"
$ unzip W2KHG%201.1.exe
Archive: /arch/W2KHG%201.1.exe
inflating: Windows 2000 Hardening Guide.doc
inflating: Templates/installSceregvl.bat
....

Paul

[David F. Skoll]

On Fri, 25 Apr 2003, Jason Coombs wrote:

> For all the progress Microsoft has made lately in understanding
> security, it's the simple things that most of us take for granted as
> obvious that still get overlooked for some reason.

> Microsoft does not distribute these guides using SSL, so the distribution is
> vulnerable to MITM attacks.

Indeed.

> Anyone interested in downloading these guides must be aware that
> they are distributed by Microsoft in the form of self-extracting
> .exe's bearing digital signatures embedded in the Portable
> Executable file's header section.

Just out of curiosity (I have no Windows systems, but anyway...) I
downloaded the .exe and was able to unpack it under Linux using
"unzip". So if you want to examine this file more-or-less securely,
open it on a UNIX or Linux box instead of Windows.

What I found interesting is that some of the documentation is in
Microsoft Word or MS Excel format. This implies that to take full
advantage of the information, you need to own an MS Office license.
Is this another example of abuse of monopoly? For that matter, are .doc
or .xls documents necessarily safer than .exe's? You decide...

--
David.

[J.'LoneWolf' Mattsson]

<snip>
>For each file listed above there is a "full-file sha1 hash" which can be
>verified using any full-file sha1 hashing utility. Microsoft does not
>provide any such utility

I'd normally not post this type of shameless plug to a mailinglist, but as
I think it's actually on topic this once, here goes:

Since I work with a mixed Windows/Unix environment I frequently do md5 (and
sometimes sha1) full file checks of backups and what not. Finding the lack
of built-in support for this in Windows annoying, I built a shell extension
that is capable of calculating crc16, crc32, md5 and sha1 checksums, from
the file properties sheet.

I have a version available on the web at
http://www.earthmagic.org/?software if you want to have a play with it...

Regards,
/Johny
#-----------------------------------# .
Johny Mattsson / \__/\
lonewolf@earthmagic.org /' , :
http://www.earthmagic.org ; ( o o
irc.sorcery.net:9000 as LoneWolf / , ~. \
System Designer / Support Engineer / ( `- ..__"
#-----------------------------------# ' /'

[Frank Knobbe]

--=-sBUSp9HEL1Hn29YumgSL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2003-04-25 at 16:27, Jason Coombs wrote:
> [...]
> For every .exe that Microsoft distributes, it should consider publishing =
a
> known good full-file hash code so that a hash verification tool of the us=
er's
> choice can be used, on a platform of the user's choice, to verify that th=
e
> file received over the network is the file they expected -- BEFORE attemp=
ting
> to use a tool like Windows Explorer to read structured information such a=
s
> digital signature data out of the PE file's header sections.
> [...]

Jason,

I'm not sure how much a file hash will do to alleviate your concern
about MITM attacks. If for example MS web site gets hijacked, or somehow
else someone is able to replace the downloadable files, what stops them
from generating a new SHA-1 or MD5 hash?

While hashes can verify the integrity of a file, it doesn't do anything
to verify the authenticity of a file. That can only be done through a
signature. Of course that requires you to actually trust such a
signature/signer and trust in the method of verifying these signatures.

It sounds like you find flaws in the signature verification of Explorer.
While I agree that is substandard (how many patches are unsigned, but
people install them anyway?), I do believe that only signatures can
correct the deficiency you outline.

In a perfect world, MS would make their white papers available in an
widely adopted standard like PDF or PS files, and sign them using
PGP/GPG. But since this is not a perfect world, and we have to accept
proprietary .doc files or OS dependent executables, why not use a sub
optimal verification process?=20

Regards,
Frank


--=-sBUSp9HEL1Hn29YumgSL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQA+rhMxpo+MRgtrF98RApDZAJ90b3FLhvw7oAg9oMYCE/bIZyNevQCgpr7U
b/fL26xvYSL5FxXUk6G9ni4=
=du2u
-----END PGP SIGNATURE-----

--=-sBUSp9HEL1Hn29YumgSL--

[Uwe Betz]

> -----Original Message-----
> From: David F. Skoll [mailto:dfs@roaringpenguin.com]=20
> Sent: Tuesday, April 29, 2003 5:08 PM
> To: Jason Coombs
> Subject: RE: Windows Server 2003 Security Guide available
>=20

>=20
> Just out of curiosity (I have no Windows systems, but=20
> anyway...) I downloaded the .exe and was able to unpack it=20
> under Linux using "unzip". So if you want to examine this=20
> file more-or-less securely, open it on a UNIX or Linux box=20
> instead of Windows.

You may also go this way using Windows and i.e. WinRar. Just right-click =
the
exe and choose "deflate to folder" (or simething like that) to get it
unpacked. It's such a lot of tools and information - even =
security-related -
packed into self-extracting .exe. Just to mention PGP with it's option =
to
create an encrypted, self-extracting .exe out of a bunch of files. =
Before
clicking that .exe you'll never know if clicking will then prompt for =
the
passphrase like expected or harm your system.

That's todays way of computer/internet life and (in)security is =
implemented
for free :-)

Jui

[Lucas Holt]

You do not need Microsoft Office to open word documents.. AppleWorks
will do it, and maybe open office/star office? Granted, Microsoft has
a monopoly. I think you can open word documents with Wordpad which is
free (and lousy). If you are reading a windows security document, you
probably have a windows box with wordpad. There used to be a word 97
viewer as well that was free.

Plain text files would be the only "safe" format. Even Acrobat
documents have security problems.

Another thing that troubles me about this debate is MITM attacks
period. Lets face it, any file format is susceptible to this sort of
thing. I could put up a fake microsoft MSDN library website and use
DNS poisoning to give developers bad documentation.

What next? Force users to use SSL for all websites? Stop using the
internet all together?


>
> What I found interesting is that some of the documentation is in
> Microsoft Word or MS Excel format. This implies that to take full
> advantage of the information, you need to own an MS Office license.
> Is this another example of abuse of monopoly? For that matter, are
> .doc
> or .xls documents necessarily safer than .exe's? You decide...
>
> --
> David.
>

Lucas Holt
Luke@FoolishGames.com
__________________________________________________ ______
FoolishGames.com
JustJournal.com

"The next generation of interesting software will be made on a
Macintosh, not an IBM PC."

-- Bill Gates (unconfirmed quote)