RedTeam

When you’re doing a lot of pentests, you have your standard procedures on how to approach a new test. There is of course always the creative approach, finding the unusual bugs and vulnerabilities, the whole “thinking outside the box” thing. But let’s be honest: A thorough pentest is not all fun and games. There’s also the standard stuff that has to be done. Low hanging fruit. And why has it to be done? Because surprisingly often, it works.

In this post, I want to discuss one standard part of every web application pentest: Searching for standard files. This can be any of:

• Changelog, Readme, License etc. files
• (Example) documentation
• Example web pages
• Example scripts
• …

and many more I probably forgot to mention. I’m talking about all these files that get installed with every standard installation of so many web applications (or servers, e.g. the Apache documentation on every newly installed system).

So, why is it necessary to search for these files, you may ask? Well, first of all, many times they give you valuable information about the application. One thing that crosses the mind is for example version information. It’s always interesting to know what version the web application has you’re pentesting, and more than often you get the information for free by just searching for a Changelog file if the application does not tell you by itself.

Even more interesting are example web pages, scripts and the like. Let me show you why: Search for “example” in the OSVDB (Open Source Vulnerability Database). At the moment, I get about 71 hits for vulnerabilities in all kinds of applications. They range from Cross Site Scripting over SQL Injection up to Remote Command Execution. This means that there’s a serious security risk emanating from these normally totally superflous files. And that’s what makes your local pentester happy, of course ;). Many times, one of the first things I do when pentesting an application which is running on some open source solution is to download the source and have a look at what interesting files there may be, even before starting to get my hands dirty with application-specific tests.

The moral of the story: Keep the attack surface of your web application to a minimum by removing everything which is not needed for it to work properly. This is not only true for your own stuff (old web pages not used any more, scripts etc.) but also for all parts of the standard installation of e.g. the CMS you’re using. Even if on a first glance, the files are seemingly harmless. They’re not, and even if they are, there’s no harm done in removing them if you don’t need them. And believe me, normally you don’t.