So I can't lie - I'm not a big fan of PCI compliance in the slightest. One of my favorite quotes about the subject comes from a thread on the hMailServer forum where a user states "PCI compliance is a load of rubbish, the CC companies can't secure their shit, so they make everyone else do it for them and charge them for the privilege." In my position I do have to deal with certain aspects of it from time to time so every time I get frustrated in my dealings with it I can come back to this quote and at least crack a smile.
Recently I ran into a problem that I was tasked with dealing with in regards to QID 86645 - FrontPage Extensions Configuration Information Obtained:
You would think this one is pretty straightforward based on the information in the screenshot. The scanner application I was using says that it was able to obtain the frontpage configuration from the webserver by requesting the "_vti_inf.html" file which contains this information. To remediate it they say that all you have to do is restrict access to this file so that it can't be publically obtained. In doing my research on this vulnerability I found one person who fixed this by disabling anonymous authentication in IIS but I could not do that because this was a public facing site. So I figured I would just find the file and see if I could rename it or delete it - easy enough right?
So I hunted through the IIS directories on the server trying to find this _vti_inf.html file and I couldn't find it anywhere. For that matter I couldn't find it anywhere on the server at all. Figuring that the file not existing was a pretty good workaround I took this information to the security vendor that I work with and they basically said this:
They could still retrieve the information from the server so even though the file itself didn't live there, it was somehow being returned. After some head scratching which in turn led to head banging onto desk I finally figured out why - Sharepoint!
I should have made the connection from the blog post I linked to earlier where he couldn't find the file on the server either but for some reason I missed it. Since this particular server hosted sites that live in Sharepoint that means the _vti_inf.html file was stored inside some content database somewhere that I did not have access to rather than on the server itself in the file system. Is it possible that I could have gone into the database and purged out the file? I'm honestly not sure - I didn't like the idea of going spelunking into a database that I didn't have much business being in so I didn't want that to be the answer. So along with our fine friends at Microsoft we came up with a decent workaround on how to fix this issue without messing with the Sharepoint databases:
Step 1: Launch IIS Manager and select/connect to the server you are working with.
Step 2: From the main workpane, select "Request Filtering"
Step 3: Click on the URL tab and then click "Deny Sequence"
Step 4: In the Deny Sequence box, enter in "/_vti_inf.html" and then click OK.
That should be it! I don't believe you need to restart IIS for this to take effect so you should be able to test immediately by browsing to http://yourserver/_vti_inf.html and if it's working you should get a 404 error but you may not depending on the browser you are using. If you get a blank page instead of a 404 do a quick view source in your browser and if there's nothing there then you should be in business. Hopefully this helps some folks out there save some time who may run into a similar situation!
