Shaken-Not-Stirred Technology Mixed Right!

Over the last few years I have gone through making several web servers pass
PCI security scans. It seems that each company that provides the
service has a different take on what passes and what fails. It also
seems that they count on their automated scans doing the right thing,
but it would seem by looking at the output of their scans that who ever
wrote the scans has little or no systems administration knowledge and
the programmer in question was probably a very junior person.

The last server I had to "make secure" had gems such as this in the
report:

THREAT REFERENCE

Summary:
Apache vulnerabilities on Apple HFS+ filesystem

Risk: High (3)
Port: 80/tcp
Protocol: tcp
Threat ID: web_server_apache_machfs

Details: CVE 2004-1083
Two Apache vulnerabilities arise from the Apple HFS+
filesystem. Firstly, the HFS+ filesystem is case-insensitive,
while Apache file access restrictions are case-sensitive.
This allows an attacker to gain unauthorized access to
.htpasswd or .DS_Store files
by changing upper-case letters to lower-case or vice-versa
in an HTTP request. These files could contain encrypted
passwords or other sensitive information.

CVE 2004-1084
The second vulnerability arises because the HFS+ filesystem
allows access to the data stream associated with a file
using a special file name. A remote attacker is able to
access this special file name in an HTTP request, thus
gaining direct access to file data or resource fork content
without going through the normal Apache file handler.

CVE 2004-1082
The fix for these vulnerabilities also fixes a replay problem
in mod_digest_apple due to insufficient
verification of the nonce of a client response.

Information From Target:
Service: http
Sent:
GET /blog/.HTPASSWD HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/4.0
Connection: Keep-alive
Cookie: CUSTOMER_INFO=deleted; frontend=deleted; CUSTOMER_AUTH=deleted;
CUSTOMER=deleted


Received:
HTTP/1.1 200 OK


The server in question is running FreeBSD-9, not Mac OSX. It seems they tried to
grab .HTPASSWD and decided the server must suffer from the case
insensitive HFS file system and is not properly protecting .HTPASSWD.
Did they do a simple content check to see if they really got back an
htpasswd file? No they did not. They based their failure of the site
on getting back an HTTP/1.1 200 OK response. Now for the site in
question if you hit any non-existing page you are directed to the site's
search page and the eventual code you get is 200. It really is not that
hard to check if the file fetched matches the format for .htpasswd, but
instead of making a good test they make poor web retailers spend
hundreds to thousands of dollars on systems staff or consultants time to
"prove the server does not have a problem".

It sure seems like a racket to me. I think the best way to put these
sharks out of business and make way for real and reliable PCI scanner is
to write a FreeSoftware PCI scanner. I bet we could start with nmap and
link in some calls using wget or lynx along with some small use of
netcat or telnet to produce a WORKING PCI scanner.

I do not have the time to do such a thing myself, but I can offer
hosting for the project. If anyone wants to pick up the banner and run
with it count me in on a supporting basis.