Hacker's view (no kill at all)

Hacker's view (no kill at all)
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


< HTML >< HEAD >


Method Not Implemented
get to /main.html not supported.

Invalid method in request get /

Apache/1.3.6 Server at www.sdn.co.za Port 80

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.