In an effort to further strengthen my knowledge on web applications, I was reading through some of the Open Web Application Security Project (OWASP) documentation. The testing documentation is very valuable to any pentesting professional or vulnerability manager. I feel that going back to the basics and understanding the information documented by the subject matter experts is very important. Most of the information that I will be covering in this article is found here, which is part of the OWASP testing guide.
As penetration testers receive scoping documentation from clients, those documents may identify an IP address that is within scope. The IP address, as we already understand, is an identifier which allows that server to communicate with other devices. That IP address is usually given to a network interface card, which could be physical or virtualized. The initial issue with that, as the documentation identifies, is that that identification of an IP address might not be fully identifying all of the applications running on that web server or as written, “that system could “hide” a number of web applications, associated to unrelated symbolic (DNS) names.”
Alas, web application enumeration is something that will come in extremely handy in cases such as this.
Web application enumeration is a process which is aimed at identifying applications that are present on infrastructure. We typically refer to anything regarding enumeration as Black-Box testing, but the same techniques could be used for any type of enumeration, Grey-Box or otherwise. If we had extensive knowledge of the terrain, we might refer to this as White-Box, however the fact that we are attempting to identify applications means that we do not have knowledge of the terrain, so we will be using these Black-Box methodologies.
Three major different factors regarding applications and DNS names:
1. Different base URL
There are situations that might require application developers to host applications at different base URLs. This allows a single DNS name to host multiple applications. This can be done by changing the directory that the URL is pointing at to host an application, such as the example that is identified by OWASP:
“For example, the same symbolic name may be associated to three web applications such as: http://www.example.com/url1http://www.example.com/url2http://www.example.com/url3”
There are vulnerability analysis tools that can be used to find these “hidden” applications, but essentially what you need to do is use common keywords and attempt to run a list of those at the end of the url to see if there is a legit page or application that resolves at those addresses. Nikto has a directory brute-forcing functionality that works very well. Dirbuster and DIRB are built to find hidden directories, and can be used with different keyword lists which enhances their usability and gives them a bit more flexibility.
2. Non-standard ports
In other cases, web hosting for applications can be done using ports, other than the standard port 80 for HTTP and 443 for SSL. Besides being commonly used, there is no reason that those ports need to be used.
To find applications or pages that might be hidden or obfuscated using this technique, port scanners can be extremely helpful. The thing to be careful of is that some port scanners will give you results based on services or applications that typically run on the ports that have been found, and those results need to be manually verified before including them in any reporting. In this example below, the tester uses nmap to scan a host for anything running on port 80. She finds a service using the port, and uses an additional option (-A to enable OS and version detection, script scanning, and traceroute) to do additional verification on the service running there:
Another tool that you can use to manually validate port scanning results is netcat, as seen below:
3. Virtual hosts
The current DNS implementation allows a single IP address to be associated to multiple symbolic names. For example, the IP address 192.168.1.100 might be associated to DNS names www.example.com, helpdesk.example.com, webmail.example.com. Each of those DNS names could be used to house separate applications, and the tester would not know about those additional applications unless those symbolic names were known somehow.