3

A PCI scanner of a client is current showing a potential path traversal exploit. The document root is set to /home/somefolder/somewebfoldername/

YET, visiting ourwebsite.com/manual shows the Apache manual. The same goes for ourwebsite.com:8443/manual

The exploit highlighted is: ourwebsite.com/manual/howto/ssi.html?..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F/etc/passwd%00

I don't see exactly how this would display the contents of passwd, but my actual questions are two fold:

1) Would deleting the contents of the manual folder solve this? and 2) Is this just masking a larger problem? I thought that apache could never reach outside of the DocumentRoot?

TIA

flukeflume
  • 165
  • 1
  • 1
  • 4

1 Answers1

3

Apache itself should not serve files outside of its DocumentRoot. However, in your example, the directory traversal is done as a GET parameter to the ssi.html file. A script have access to the filesystem with the same permissions as the user running the web server (nobody or www-data is common).

I find it strange that the manual for for SSI should contain a vulnearbility. I cannot find any details about this file being vulnerable pr default for any versions of apache.

It is possible that someone has planted a backdoor (knowingly or not) in this file. Does your url actually respond with the passwd file, and have you inspected this file to see if there have been any modifications to it?

1) Deleting (or removing the configuration for) this should remove the associated vulnerability.

2) This should not create a major problem. There are other ways to harden an apache server. In this context, running it in a chroot jail would make sense.

Dog eat cat world
  • 5,827
  • 1
  • 28
  • 46
  • Hi Dog, Thanks for this - that url doesn't serve up the password file and as far as I can tell it is unchanged. In the meantime I've disabled the 'manual' config in httpd, along with a few aliases like webalizer etc (which I didn't even realise were there!) and I'm re-running the scan. Hopefully it'll be a false positive. – flukeflume Apr 03 '14 at 12:17
  • Ok, so this is a false positive? It might not be the same for your configuration, but take a look at /etc/httpd/conf.d/manual.conf . Here you can remove the line for the manual (Alias /manual/ "/usr/local/apache/htdocs/manual/"). Remember to restart/reload the apache server afterwards. – Dog eat cat world Apr 03 '14 at 12:20
  • Hi Dog, the scanner is still running to determine if this is a False Positive - I've now already disabled the manual.conf, webalizer.conf etc and restarted, so hopefully it'll resolve the issue. I'll post the results when it finishes incase it helps future visitors. – flukeflume Apr 03 '14 at 12:28
  • That would be nice :) – Dog eat cat world Apr 03 '14 at 12:33
  • 1
    sounds like you are relying to heavily on the scanner. Trust your eyes, Luke. Can you enter that url into a browser and see the password file? I've found that false positives are rare for this because the format of the password file is so readily identifiable to automated scanners. – mcgyver5 Apr 03 '14 at 12:34
  • Thanks @mcgyver5 - with security matters, I tend to be incredibly paranoid, just because if I could anticipate all security holes, there would never be any, which is obviously not the case! There are many individuals out there with more zeal \ experience in this than I, so if the scanner says something, I have a small panic. :D

    However, it appears that this was indeed a false positive - No passwords were outputted, and instead the scanner saw the output the Apache manual as a method of path traversal.

     – flukeflume Apr 03 '14 at 16:19
  • @barryfudge: could you please paste the whole line from the logs, if possible? return-code could tell you something. beside this, what Dog eat cat world said – that guy from over there Apr 04 '14 at 12:26