Re: Microsoft IIS Patch Level Security PCI loophole
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Mon, 25 Feb 2008 03:42:47 -0700
For what it is worth, I went through this some months ago in the
continuing accrediting scan process, and after screen shots, time,
etc. was told they were lowering that test's weight in the scoring.
If you do know they are giving false positive . . .
then you're fine, right? in my case I had to establish to the auditors
that the scans were wrong, and they only would accept a statement
to that effect from the scan provider
"MarkB" <reelmark@xxxxxxxxx> wrote in message
news:44a5dacb-aae4-4390-a8a0-26bfb4391416@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi,
I run a security scanner for PCI credit card(Visa,MC) shopping cart
compliance periodically on my web site, which, upon a recent site scan
on our domain, returned a failing test. The reason that the test did
not pass was because it maintains that the Microsoft IIS Server is
running at a patch level (SP1 specifically) which is lower than the
current patch level, hence the failed test. On the flip side of the
coin, the test is obviously not foolproof and it maintains in the
commentary field the following info:
"The Patch level (Service Pack) of the remote IIS server appears to be
lower than the current IIS service pack level. As each service pack
typically contains many security patches, the server may be at risk.
Note that this test makes assumptions of the remote patch level based
on static return values (Content-Length) within a IIS Server's 404
error message. As such, the test can not be totally reliable and
should be manually confirmed.
Note also that, to determine IIS6 patch levels, a simple test is done
based on strict RFC 2616 compliance. It appears as if IIS6-SP1 will
accept CR as an end-of-line marker instead of both CR and LF."
The Security companies contention (SecurityMetrics) is that it is
better to receive a false positive than to miss an actual threat,
hence a scan which isn't actual proof at all that the web server isn't
compliant. If you note the response above, they tell me the test makes
"assumptions" & the server "*seems" to be running at SP1. If you will
also note in the second paragraph above that the test makes the
assumptions based on the IIS servers 404 error message. My question
is, can this be corrected by something as modifying how the server
handles 404 messages or another setting-assuming the 404/Content-
Length is somehow to blame? In my control panel IIS settings I have
tried both changing the 404 message from the html custom error message
resident server side to the default setting -and back- to no avail.
(Note: I don't have access to the servers web.config or machine.config
file)
Here is the 404 html header info:
HTTP/1.1 404 Not Found
Content-Length: 103
Content-Type: text/html
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Fri, 22 Feb 2008 10:14:04 GMT
Connection: close
I have opened up a support ticket with my web host
(www.hostmysite.com) but they have assured me over the phone that they
have the latest patch levels on their server (after testing them out)
Where to go. What to do...Very frustrating...Any advice is much
appreciated.
Thank you for your time.
.
- References:
- Microsoft IIS Patch Level Security PCI loophole
- From: MarkB
- Microsoft IIS Patch Level Security PCI loophole
- Prev by Date: RE: Is it possible to disable NETBIOS and still allow NTLM and Kerberos authentication?
- Next by Date: Re: Is it possible to disable NETBIOS and still allow NTLM and Kerberos authentication?
- Previous by thread: Re: Microsoft IIS Patch Level Security PCI loophole
- Next by thread: Force HTTPS to forward to HTTP?
- Index(es):
Relevant Pages
|
