1BO4r2U
1BO4r2U
1BO4r2U
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
31 32<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
where. This may happen either by error (due to misconfigurations), or<br />
intentionally (for example, unadvertised administrative interfaces).<br />
To address these issues, it is necessary to perform web application<br />
discovery.<br />
Test Objectives<br />
Enumerate the applications within scope that exist on a web server<br />
How to Test<br />
Black Box Testing<br />
Web application discovery is a process aimed at identifying web applications<br />
on a given infrastructure. The latter is usually specified as<br />
a set of IP addresses (maybe a net block), but may consist of a set of<br />
DNS symbolic names or a mix of the two. This information is handed<br />
out prior to the execution of an assessment, be it a classic-style<br />
penetration test or an application-focused assessment. In both<br />
cases, unless the rules of engagement specify otherwise (e.g., “test<br />
only the application located at the URL http: /www.example.com/”),<br />
the assessment should strive to be the most comprehensive in<br />
scope, i.e. it should identify all the applications accessible through<br />
the given target. The following examples examine a few techniques<br />
that can be employed to achieve this goal.<br />
Note: Some of the following techniques apply to Internet-facing<br />
web servers, namely DNS and reverse-IP web-based search services<br />
and the use of search engines. Examples make use of private<br />
IP addresses (such as 192.168.1.100), which, unless indicated otherwise,<br />
represent generic IP addresses and are used only for anonymity<br />
purposes.<br />
There are three factors influencing how many applications are related<br />
to a given DNS name (or an IP address):<br />
1. Different base URL<br />
The obvious entry point for a web application is www.example.<br />
com, i.e., with this shorthand notation we think of the web application<br />
originating at http: /www.example.com/ (the same applies for<br />
https). However, even though this is the most common situation,<br />
there is nothing forcing the application to start at “/”.<br />
For example, the same symbolic name may be associated to three<br />
web applications such as: http: /www.example.com/url1 http: /<br />
www.example.com/url2 http: /www.example.com/url3<br />
In this case, the URL http: /www.example.com/ would not be associated<br />
with a meaningful page, and the three applications would<br />
be “hidden”, unless the tester explicitly knows how to reach them,<br />
i.e., the tester knows url1, url2 or url3. There is usually no need to<br />
publish web applications in this way, unless the owner doesn’t want<br />
them to be accessible in a standard way, and is prepared to inform<br />
the users about their exact location. This doesn’t mean that these<br />
applications are secret, just that their existence and location is not<br />
explicitly advertised.<br />
2. Non-standard ports<br />
While web applications usually live on port 80 (http) and 443 (https),<br />
there is nothing magic about these port numbers. In fact, web applications<br />
may be associated with arbitrary TCP ports, and can be<br />
referenced by specifying the port number as follows: http[s]: /www.<br />
example.com:port/. For example, http: /www.example.com:20000/.<br />
3. Virtual hosts<br />
DNS allows a single IP address to be associated with one or more<br />
symbolic names. For example, the IP address 192.168.1.100 might<br />
be associated to DNS names www.example.com, helpdesk.example.<br />
com, webmail.example.com. It is not necessary that all the names<br />
belong to the same DNS domain. This 1-to-N relationship may be reflected<br />
to serve different content by using so called virtual hosts. The<br />
information specifying the virtual host we are referring to is embedded<br />
in the HTTP 1.1 Host: header [1].<br />
One would not suspect the existence of other web applications in addition<br />
to the obvious www.example.com, unless they know of helpdesk.example.com<br />
and webmail.example.com.<br />
Approaches to address issue 1 - non-standard URLs<br />
There is no way to fully ascertain the existence of non-standardnamed<br />
web applications. Being non-standard, there is no fixed criteria<br />
governing the naming convention, however there are a number of<br />
techniques that the tester can use to gain some additional insight.<br />
First, if the web server is mis-configured and allows directory browsing,<br />
it may be possible to spot these applications. Vulnerability scanners<br />
may help in this respect.<br />
Second, these applications may be referenced by other web pages<br />
and there is a chance that they have been spidered and indexed by<br />
web search engines. If testers suspect the existence of such “hidden”<br />
applications on www.example.com they could search using the site<br />
operator and examining the result of a query for “site: www.example.<br />
com”. Among the returned URLs there could be one pointing to such a<br />
non-obvious application.<br />
Another option is to probe for URLs which might be likely candidates for<br />
non-published applications. For example, a web mail front end might<br />
be accessible from URLs such as https:/www.example.com/webmail,<br />
https:/webmail.example.com/, or https:/mail.example.com/. The<br />
same holds for administrative interfaces, which may be published at<br />
hidden URLs (for example, a Tomcat administrative interface), and yet<br />
not referenced anywhere. So doing a bit of dictionary-style searching<br />
(or “intelligent guessing”) could yield some results. Vulnerability scanners<br />
may help in this respect.<br />
Approaches to address issue 2 - non-standard ports<br />
It is easy to check for the existence of web applications on non-standard<br />
ports. A port scanner such as nmap [2] is capable of performing<br />
service recognition by means of the -sV option, and will identify http[s]<br />
services on arbitrary ports. What is required is a full scan of the whole<br />
64k TCP port address space.<br />
For example, the following command will look up, with a TCP connect<br />
scan, all open ports on IP 192.168.1.100 and will try to determine what<br />
services are bound to them (only essential switches are shown – nmap<br />
features a broad set of options, whose discussion is out of scope):<br />
nmap –PN –sT –sV –p0-65535 192.168.1.100<br />
It is sufficient to examine the output and look for http or the indication<br />
of SSL-wrapped services (which should be probed to confirm<br />
that they are https). For example, the output of the previous command<br />
coullook like:<br />
901/tcp open http Samba SWAT administration server<br />
1241/tcp open ssl Nessus security scanner<br />
3690/tcp open unknown<br />
8000/tcp open http-alt?<br />
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1<br />
From this example, one see that:<br />
• There is an Apache http server running on port 80.<br />
• It looks like there is an https server on port 443 (but this needs to<br />
be confirmed, for example, by visiting https:/192.168.1.100 with a<br />
browser).<br />
• On port 901 there is a Samba SWAT web interface.<br />
• The service on port 1241 is not https, but is the SSL-wrapped Nessus<br />
daemon.<br />
• Port 3690 features an unspecified service (nmap gives back its<br />
fingerprint - here omitted for clarity - together with instructions<br />
to submit it for incorporation in the nmap fingerprint database,<br />
provided you know which service it represents).<br />
• Another unspecified service on port 8000; this might possibly be<br />
http, since it is not uncommon to find http servers on this port. Let’s<br />
examine this issue:<br />
Interesting ports on 192.168.1.100:<br />
(The 65527 ports scanned but not shown below are in state:<br />
closed)<br />
PORT STATE SERVICE VERSION<br />
22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)<br />
80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux))<br />
443/tcp open ssl OpenSSL<br />
This confirms that in fact it is an HTTP server. Alternatively, testers<br />
could have visited the URL with a web browser; or used the GET or<br />
HEAD Perl commands, which mimic HTTP interactions such as the<br />
one given above (however HEAD requests may not be honored by all<br />
servers).<br />
• Apache Tomcat running on port 8080.<br />
The same task may be performed by vulnerability scanners, but first<br />
check that the scanner of choice is able to identify http[s] services<br />
running on non-standard ports. For example, Nessus [3] is capable of<br />
identifying them on arbitrary ports (provided it is instructed to scan all<br />
the ports), and will provide, with respect to nmap, a number of tests<br />
on known web server vulnerabilities, as well as on the SSL configuration<br />
of https services. As hinted before, Nessus is also able to spot<br />
popular applications or web interfaces which could otherwise go unnoticed<br />
(for example, a Tomcat administrative interface).<br />
Approaches to address issue 3 - virtual hosts<br />
There are a number of techniques which may be used to identify DNS<br />
names associated to a given IP address x.y.z.t.<br />
DNS zone transfers<br />
This technique has limited use nowadays, given the fact that zone<br />
transfers are largely not honored by DNS servers. However, it may<br />
be worth a try. First of all, testers must determine the name servers<br />
serving x.y.z.t. If a symbolic name is known for x.y.z.t (let it be www.<br />
example.com), its name servers can be determined by means of tools<br />
such as nslookup, host, or dig, by requesting DNS NS records.<br />
If no symbolic names are known for x.y.z.t, but the target definition<br />
contains at least a symbolic name, testers may try to apply the same<br />
process and query the name server of that name (hoping that x.y.z.t<br />
will be served as well by that name server). For example, if the target<br />
consists of the IP address x.y.z.t and the name mail.example.com, determine<br />
the name servers for domain example.com.<br />
The following example shows how to identify the name servers for<br />
www.owasp.org by using the host command:<br />
$ host -t ns www.owasp.org<br />
www.owasp.org is an alias for owasp.org.<br />
owasp.org name server ns1.secure.net.<br />
owasp.org name server ns2.secure.net.<br />
A zone transfer may now be requested to the name servers for domain<br />
example.com. If the tester is lucky, they will get back a list of the<br />
DNS entries for this domain. This will include the obvious www.example.com<br />
and the not-so-obvious helpdesk.example.com and webmail.<br />
example.com (and possibly others). Check all names returned by the<br />
zone transfer and consider all of those which are related to the target<br />
being evaluated.<br />
Trying to request a zone transfer for owasp.org from one of its name<br />
servers:<br />
$ host -l www.owasp.org ns1.secure.net<br />
Using domain server:<br />
Name: ns1.secure.net<br />
Address: 192.220.124.10#53<br />
Aliases:<br />
Host www.owasp.org not found: 5(REFUSED)<br />
; Transfer failed.<br />
DNS inverse queries<br />
This process is similar to the previous one, but relies on inverse (PTR)<br />
DNS records. Rather than requesting a zone transfer, try setting the<br />
record type to PTR and issue a query on the given IP address. If the<br />
testers are lucky, they may get back a DNS name entry. This technique<br />
relies on the existence of IP-to-symbolic name maps, which is not<br />
guaranteed.<br />
Web-based DNS searches<br />
This kind of search is akin to DNS zone transfer, but relies on webbased<br />
services that enable name-based searches on DNS. One<br />
such service is the Netcraft Search DNS service, available at http:/<br />
searchdns.netcraft.com/?host. The tester may query for a list of<br />
names belonging to your domain of choice, such as example.com.<br />
Then they will check whether the names they obtained are pertinent<br />
to the target they are examining.