4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
36<br />
Web Application Penetration Testing<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.