First and foremost, what exactly is directory listing? Put simply, it’s a feature that’s usually enabled by default on most web servers that allows the content of the server to be listed when there’s no available index file, but can be disabled depending on the server’s configuration. When enabled, web users can access a list of all files and folders that are hosted on that particular web server. Users are then able to traverse to any directory that’s present in the web root, view and download the files available. This is akin to the ‘dir’ command in Windows and ‘ls’ command in Linux environment.
Like anything, the level of risk relies on several different factors. In this case, risk is entirely dependent on the content of the files present in the web root. In the wild, web servers tend to only list default installation files as other directories usually contain an index file in some way or another. These don’t contain the sensitive information adversaries seek and (fortunately!) don’t create much risk or potential negative impact to the business.
However, sometimes the directory contains sensitive information, like financial documents or users’ credentials, or can permit access to the protected area of the web server that normal users don’t have access to when simply browsing the website. This information is highly valuable to attackers and can be used to formulate any number of wide range of attacks that would affect either the confidentiality, integrity or availability of the web site and the supporting server – as well as having an adverse effect on the business. This is when directory listing poses a risk to businesses.
Attackers can identify this issue by using several readily available tools, both commercial and free, to crawl and directory-bust web servers. The most well-known are DirBuster and Gobuster. However, Nikto, Nessus and Burp Suite also have the functionality to crawl and brute force any hidden directories that may be listable. Google hacking and Shodan can also be used to find websites that have listed their directory publicly.
Any real case examples?
1: A web application security assessment against a Hostel Management System. Owned by University A, developed by and hosted on the vendor’s server. The web server was scanned as part of their security testing, and a directory that allowed files and folders to be listed was detected. This directory contained numerous files that disclosed personally identifiable information of students (passports, national identification cards), payment details (account numbers, bank transactions) and also details of their assigned room. The vendor also hosted the Hostel Management System for several other universities on the same server. By traversing the directory, we could see the personal data and payment details of students from another university.
2: During an external penetration test, one host had a directory that listed a text file disclosing admin credentials for a web application that was hosted elsewhere. These credentials were then tested by logging in into the web application – and they worked.
This demonstrates how a seemingly innocent misconfiguration, or lack of hardening, could lead to account takeover and disclosure of sensitive information that breaches the General Data Protection Regulation (GDPR).
How do we prevent this issue?
In general, this can be prevented by hardening the web server by following security best practices. Always:
- Disable directory listing in the web or application-server configuration by default
- Restrict access to unnecessary directories and files
- Create an index (default) file for each directory