Default web server files reachable

A fresh installation delivers more than a working application. Sample pages come with it, along with documentation, test scripts, admin consoles and installation tools. They exist to ease the first steps and should disappear afterwards. This article covers what gets left behind, and when that shifts from a nuisance to something serious.

What are default files?

Default files are the components a product ships at installation and that serve no purpose once it is in use. Four kinds occur, differing sharply in severity.

The most innocent are the sample and welcome pages: a web server’s default page, an application platform’s test page, bundled sample applications. Next come documentation files and licence texts naming the product and version. Then installation scripts, which set the application up and can sometimes be run again. And finally the admin consoles: interfaces for managing the server or platform, sometimes with default credentials.

What they have in common is that nobody deliberately placed them and nobody misses them. They are there because they came along. It resembles a house where, after handover, the drawings, the spare keys and the builder’s sign have been left in the meter cupboard.

What gets found?

Vulnerable:

An attacker checks a series of known paths. That is a fixed list per platform, and it goes quickly:

GET /examples/                     → 200  sample applications
GET /docs/                         → 200  bundled documentation
GET /manager/html                  → 401  admin console present
GET /install.php                   → 200  installation script
GET /phpinfo.php                   → 200  full configuration
GET /CHANGELOG.txt                 → 200  exact version

Each of those responses says something. The sample applications confirm the platform. The changelog gives the exact version, which makes known vulnerabilities lookupable. The configuration page shows modules, paths and sometimes environment variables. And the admin console is the most serious: it is not merely present but is regularly found in practice with credentials that were never changed, which opens the way to deploying your own code.

The installation script deserves separate mention. If it stays reachable and unprotected, someone can sometimes run the installation again and connect the application to their own database or create a new administrator account.

Safe:

# Clean-up as a fixed part of deployment, not a separate action
rm -rf /opt/tomcat/webapps/{examples,docs,manager,host-manager}
rm -f  /var/www/{install.php,phpinfo.php,CHANGELOG.txt,README.md}

# And a safety net for whatever ends up there anyway
location ~* ^/(install|setup|phpinfo|test)\.(php|jsp|aspx)$ {
    deny all;
    return 404;
}
location ~* /(CHANGELOG|README|LICENSE|INSTALL)\.(txt|md)$ {
    deny all;
    return 404;
}

The clean-up should be part of deployment rather than a checklist someone works through after installation. With automated deployment from a hardened base image it happens by itself, including on the next server.

What is the impact of leftover default files?

The severity runs from low to critical, a wider spread than for virtually any other finding in this category. It is determined entirely by what exactly has been left.

At the bottom sits the sample page revealing only the product. That speeds up reconnaissance but grants no access. In the middle sit the configuration and documentation files, which give away the exact version and thereby enable targeted searching for known vulnerabilities. At the top sit the admin consoles and installation scripts, where the impact amounts to full takeover of the application or the server.

There is also a meaning reaching beyond the files themselves. Default files still present mean the installation was never reviewed. To a tester that is a strong indication that more default settings have been left in place: default passwords, broad folder permissions, enabled modules nobody uses. The finding then matters less for itself than as a predictor.

How do you detect leftover default files?

A tester first establishes which platform is running, based on headers, cookie names, path structures and the layout of error pages. Then the corresponding list of default paths is worked through; that differs per product and is well documented for the common platforms.

They do not only watch for a 200. A 401 or 403 is at least as interesting, because it confirms the component is present and merely shielded. With an admin console they then test whether the default credentials still work. They also look for files revealing the version, and for installation scripts that might be runnable again. Subdomains and secondary servers get attention too, because clean-up was skipped there more often than on the main server. AssistSec includes this check in the reconnaissance phase, because what is found here determines where the rest of the investigation focuses.

How do you prevent leftover default files?

• Remove sample applications, documentation and test pages as a fixed part of deployment.
• Remove installation scripts as soon as installation is complete, or block them in the web server.
• Disable admin consoles, or restrict them to an internal network or a VPN.
• Always change the default credentials of every bundled component.
• Deploy from a hardened base image where the clean-up is already done.
• Block known default paths in your web server as a safety net.
• Remove files revealing the version, such as changelogs and readme files.
• Disable modules and functionality you do not use.
• Check automatically after every deployment that the default files are absent, including on new servers.