Let us then look at another example: www.sensepost.com. Our website (it is
hosted offsite BTW). And let us go through the same steps, assuming we know
nothing about the host.
We telnet to port 25 to find it filtered. The port is not wrapped - wrappers
are very characteristic of UNIX hosts. [ Telling if a services is can be
determined as follows:
# telnet cube.co.za
Trying 196.38.115.250...
Connected to cube.co.za.
Escape character is '^]'.
Connection closed by foreign host.
We see that we can establish a complete connection, but that the connection
is closed immediately. Thus, the service is wrapped (TCP wrappers made
famous by Venema Wietse). Wrappers allows the sysadmin to decide what source
IP address(es) are allowed to connect to the service. It is interesting to
note that wrapper might be set up to work with the source IP, or with the
DNS name of the source. In some situations one can determine if the server
uses IP numbers or DNS names - if the connection is not closed immediately
(say it takes 2-10 seconds) it is probably using DNS names. Another way to
determine if the wrapper is using DNS names or IP numbers is to connect to
it with a IP number that does not have a reverse resolvable name. The server
will attempt to reverse resolve your IP address - this might take a while -
it is this delay that you will be able to see when connecting to the host.
(The interesting part of this is that if the wrapper uses DNS one can get
past it if one has complete control over both the mechanisms that controls
both the forward and reverse DNS entries)]
Getting back to our website. Port 25 is filtered. How about port 80? (I hope
not - else our website is down!) Connecting to port 80 reveals that we are
dealing with a UNIX platform:
# telnet www.sensepost.com 80
Trying 216.0.48.55...
Connected to www.sensepost.com.
Escape character is '^]'.
GET / HTTP/1.0<cr>
<cr>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
get to /main.html not supported.<P>
Invalid method in request get /<P>
<HR>
<ADDRESS>Apache/1.3.6 Server at www.sdn.co.za Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.
Issuing the "GET / HTTP/1.0” command we see a response that includes the
text "Apache/1.3.6", a famous UNIX webserver (I understand that Apache is
now also available for Windows). We know that port 25 is firewalled. This
means that the host is probably properly firewalled. Just to make sure we
telnet to port 23 (telnet) and our suspicion is confirmed - the port is
filtered.
Now what? The idea is now to start a portscan on the host. As mentioned
before we don't want to do a complete scan on the server - we are just
interested in ports that is servicing services that we know are exploitable
or that might turn up interesting information in a vulnerability scanner.
Knowing the O/S could also helps a lot. Thus, a command as follows is
issued:
# nmap -O -sS -P0 216.0.48.55 -p
21,22,53,69,98,110,443,1080,2049,3128,8080,1433,6667
We don't want to look at ports 23 and 80 as we know their status. All the
other ports might service exploitable services. We want to see if there are
any proxies running on the host (1080,3128 and 8080). Port 98 is Linux
config port, 69 is TFTP and 1433 is MSQL (maybe it is a MS box after all).
The output looks like this:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on www.sdn.co.za (216.0.48.55):
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp filtered ssh
69/tcp filtered tftp
80/tcp open http
98/tcp filtered linuxconf
110/tcp filtered pop-3
1080/tcp filtered socks
1433/tcp filtered ms-sql-s
2049/tcp filtered nfsd
3128/tcp filtered squid-http
6667/tcp filtered irc
8080/tcp filtered http-proxy
TCP Sequence Prediction: Class=random positive increments
Difficulty=49224 (Worthy challenge)
Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7
Checking the version of the services on the only two open ports (21 and 80)
we find that this is more of a challenge. Trying common usernames and
passwords at the FTP service also does not prove to work (including
anonymous - as in the previous case).
Maybe we need to do a complete scan on the host - maybe there is an
unprotected root shell waiting on a high port? How about UDP? Maybe putting
on our security assessment hat would prove necessary? Maybe we need to look
more in depth? Now, I am not saying that a hacker will not do this - I am
only going into "assessment" mode, as this is where an assessment will start
anyway.
A complete scan of the host is the place to start. We proceed to do this:
nmap -sS -O -P0 www.sensepost.com
The results looks as follows:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on www.sdn.co.za (216.0.48.55):
(The 1518 ports scanned but not shown below are in state: filtered)
Port State Service
21/tcp open ftp
53/tcp closed domain
80/tcp open http
443/tcp closed https
4321/tcp open rwhois
TCP Sequence Prediction: Class=random positive increments
Difficulty=15377 (Worthy challenge)
Remote operating system guess: Solaris 7
The only other open port is 4321. From the service file it seems that port
4321 is used for rwhois(remote WHOIS queries). But never trust the service
file - 4321 sounds a bit suspect, it could be a backdoor put there by a
previous administrator. We check it out manually:
# telnet www.sensepost.com 4321
Trying 216.0.48.55...
Connected to www.sensepost.com.
Escape character is '^]'.
%rwhois V-1.5:003fff:00 rwhois.sdn.co.za (by Network Solutions, Inc. V-1.5.5)
It checks out pretty OK. The host is running an FTP and HTTP daemon. Are
they using safe versions of these? Is the HTTP server configured properly?
In the next section we look at using tools developed by other people and
companies - these tools will help us to uncover any holes in the defense of
a host.
hosted offsite BTW). And let us go through the same steps, assuming we know
nothing about the host.
We telnet to port 25 to find it filtered. The port is not wrapped - wrappers
are very characteristic of UNIX hosts. [ Telling if a services is can be
determined as follows:
# telnet cube.co.za
Trying 196.38.115.250...
Connected to cube.co.za.
Escape character is '^]'.
Connection closed by foreign host.
We see that we can establish a complete connection, but that the connection
is closed immediately. Thus, the service is wrapped (TCP wrappers made
famous by Venema Wietse). Wrappers allows the sysadmin to decide what source
IP address(es) are allowed to connect to the service. It is interesting to
note that wrapper might be set up to work with the source IP, or with the
DNS name of the source. In some situations one can determine if the server
uses IP numbers or DNS names - if the connection is not closed immediately
(say it takes 2-10 seconds) it is probably using DNS names. Another way to
determine if the wrapper is using DNS names or IP numbers is to connect to
it with a IP number that does not have a reverse resolvable name. The server
will attempt to reverse resolve your IP address - this might take a while -
it is this delay that you will be able to see when connecting to the host.
(The interesting part of this is that if the wrapper uses DNS one can get
past it if one has complete control over both the mechanisms that controls
both the forward and reverse DNS entries)]
Getting back to our website. Port 25 is filtered. How about port 80? (I hope
not - else our website is down!) Connecting to port 80 reveals that we are
dealing with a UNIX platform:
# telnet www.sensepost.com 80
Trying 216.0.48.55...
Connected to www.sensepost.com.
Escape character is '^]'.
GET / HTTP/1.0<cr>
<cr>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
get to /main.html not supported.<P>
Invalid method in request get /<P>
<HR>
<ADDRESS>Apache/1.3.6 Server at www.sdn.co.za Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.
Issuing the "GET / HTTP/1.0” command we see a response that includes the
text "Apache/1.3.6", a famous UNIX webserver (I understand that Apache is
now also available for Windows). We know that port 25 is firewalled. This
means that the host is probably properly firewalled. Just to make sure we
telnet to port 23 (telnet) and our suspicion is confirmed - the port is
filtered.
Now what? The idea is now to start a portscan on the host. As mentioned
before we don't want to do a complete scan on the server - we are just
interested in ports that is servicing services that we know are exploitable
or that might turn up interesting information in a vulnerability scanner.
Knowing the O/S could also helps a lot. Thus, a command as follows is
issued:
# nmap -O -sS -P0 216.0.48.55 -p
21,22,53,69,98,110,443,1080,2049,3128,8080,1433,6667
We don't want to look at ports 23 and 80 as we know their status. All the
other ports might service exploitable services. We want to see if there are
any proxies running on the host (1080,3128 and 8080). Port 98 is Linux
config port, 69 is TFTP and 1433 is MSQL (maybe it is a MS box after all).
The output looks like this:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on www.sdn.co.za (216.0.48.55):
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
22/tcp filtered ssh
69/tcp filtered tftp
80/tcp open http
98/tcp filtered linuxconf
110/tcp filtered pop-3
1080/tcp filtered socks
1433/tcp filtered ms-sql-s
2049/tcp filtered nfsd
3128/tcp filtered squid-http
6667/tcp filtered irc
8080/tcp filtered http-proxy
TCP Sequence Prediction: Class=random positive increments
Difficulty=49224 (Worthy challenge)
Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7
Checking the version of the services on the only two open ports (21 and 80)
we find that this is more of a challenge. Trying common usernames and
passwords at the FTP service also does not prove to work (including
anonymous - as in the previous case).
Maybe we need to do a complete scan on the host - maybe there is an
unprotected root shell waiting on a high port? How about UDP? Maybe putting
on our security assessment hat would prove necessary? Maybe we need to look
more in depth? Now, I am not saying that a hacker will not do this - I am
only going into "assessment" mode, as this is where an assessment will start
anyway.
A complete scan of the host is the place to start. We proceed to do this:
nmap -sS -O -P0 www.sensepost.com
The results looks as follows:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on www.sdn.co.za (216.0.48.55):
(The 1518 ports scanned but not shown below are in state: filtered)
Port State Service
21/tcp open ftp
53/tcp closed domain
80/tcp open http
443/tcp closed https
4321/tcp open rwhois
TCP Sequence Prediction: Class=random positive increments
Difficulty=15377 (Worthy challenge)
Remote operating system guess: Solaris 7
The only other open port is 4321. From the service file it seems that port
4321 is used for rwhois(remote WHOIS queries). But never trust the service
file - 4321 sounds a bit suspect, it could be a backdoor put there by a
previous administrator. We check it out manually:
# telnet www.sensepost.com 4321
Trying 216.0.48.55...
Connected to www.sensepost.com.
Escape character is '^]'.
%rwhois V-1.5:003fff:00 rwhois.sdn.co.za (by Network Solutions, Inc. V-1.5.5)
It checks out pretty OK. The host is running an FTP and HTTP daemon. Are
they using safe versions of these? Is the HTTP server configured properly?
In the next section we look at using tools developed by other people and
companies - these tools will help us to uncover any holes in the defense of
a host.
No comments:
Post a Comment