Scanning for Default Files

Just to show how different the life of a pen tester is, I’m going to sidestep from my normal talk of passwords, mobile devices and computer games and go back to an aspect which is the meat of pen testing life: web application testing.

As we all know most sites are built on a collection of different technologies, which may be programing languages or simple frameworks, commercial or open source.

I was tasked to test a site running the Moodle open source learning framework, which is written in the PHP language and something which I had only seen once before.

One aspect of testing standard applications is to check for standard files and extensions, looking in case they reveal information about the build of the site, or even point to “hidden” administrator pages that could allow a toehold into the application.

This is worthwhile doing, even if the application is secure, as mistakes in the application’s configuration could allow access to pages or directories. It can also allow the checking of the install against known vulnerabilities which may have been published.

Now, you could scan for this by loading up your web browser of choice and trying this by hand; but I’m lazy, so the easiest way is to do this automatically. This is attractive to me, not just because I find the tedium of entering lots of URIs manually boring, but also, as I’m one of the maintainers of the Nikto application; I like to show off some of the more fancy things it can do.

I could use OWASP’s dirbuster, but I was trying to keep the traffic low due to some restrictions within scope.

Anyway, the first step is to download a copy of the target application from the homepage onto a virtual machine running your favourite version of Linux (or use Cygwin for Windows) and unzip it:

Then we need a dictionary of all files present in the install, for this I used the find command as it includes the path of the file, although I need to remove the current path at the beginning to get it looking nice:

Once we have the list, we can use Nikto to check for every URI in the list. To do this we need to use a little known plugin that isn’t enabled by default, we can see the plugin from the list of plugins (this is the version from trunk, the latest stable version needs some tuning on this plugin):

So we can call this directly using the GET method, so we can manually ensure that we’re getting an appropriate response from the server:

The magic here is the data after the Plugins parameter. This defines the plugins that are being called and their parameters, in this case it will call the following plugins:

1. dictionary, with the previously set up file, using the GET HTTP method
2. report_text, to save the the found items somewhere

Running this will enumerate through our list responding with found URIs. We can cut this down a bit more, by restricting Nikto to only look for 200 responses (normally it will also look for redirects and unauthorised responses).

This is set in databases/db_variables and we can edit the line:

To read:

And, there we have a simple, quick and nasty enumerator for installed files. Unfortunately this didn’t give me any hidden admin pages, but I gathered information from the server anyway, as shown in some of the (redacted) screenshots below:

Directory indexing being available:

Figure 1- Directory Indexing

A nice error message which tells us the real filesystem path of the directory and the PHP include path; all of which is useful in local file include vulnerabilities and in case there are dodgy directories in the php include path which we could attack later.

Figure 2- Error Message with Path and PHP Include