Index of Section 1 Manual Pages

Interix / SUAiss.1Interix / SUA

ISS(1)                                                     ISS(1)



NAME
       iss - Internet Security Scanner

SYNOPSIS
       iss [ -msrdyvpqefo ] #1 #2

DESCRIPTION
       ISS  Internet Security Scanner ( ISS ) is one of the first
       multi-level security scanners available to the public.  It
       was  designed  to  be flexible and easily portable to many
       unix platforms and do its job in a  reasonable  amount  of
       time.   It  provides information to the administrator that
       will fix obvious security misconfigurations.

       ISS does a multi-level scan of security, not just  search-
       ing  for  one  weakness in the system.  To provide this to
       the public or at least to the security conscious crowd may
       cause  people  to  think  that it is too dangerous for the
       public, but many of the (cr/h)ackers are already aware  of
       these security holes and know how to exploit them.

       These security holes are not deep in some OS routines, but
       standard misconfigurations that many domains  on  Internet
       tend  to  show.   Many  of these holes are warned about in
       CERT and CIAC advisories.  This is the  first  release  of
       ISS and there is still much room for improvement.

       ISS  is a project that I started as I became interested in
       security.  As I heard  about  (cr/h)ackers  breaking  into
       NASA  and  universities around the world, I wanted to find
       out the deep secrets of security and how these people were
       able  to  gain  access  to expensive machines that I would
       think were  secure.   I  searched  Internet  for  relative
       information, such as Phrack and CERT advisories.

       Most information was vague and did not explain how intrud-
       ers were able to gain access to most systems.  At most the
       information  told administrators to make password security
       tighter and to apply the vendor's security patches.   They
       lacked real information on how an intruder would look at a
       site to try to gain access.  Having talked  with  security
       experts  and  reading CERT advisories, I started trying to
       look for various security holes within my domain.

       To my surprise, I noticed that many of machines were  ade-
       quately secured, but within a domain there remained enough
       machines with obvious holes that anyone  wanted  into  any
       machine  could  attack the weak 'trusted' machine and from
       there could gain access to the rest of  the  domain.  From
       this  project,  I  have not learned any new deep secret to
       cracking systems, but  with  the  right  tools  that  most
       domains on Internet are insecure.  These holes will not be
       a surprise to any advanced intruder, but  with  this  tool
       administrators  will be able to quickly search for obvious
       holes and prepare to fix them.



OPTIONS
       -d     Ignores Checking Default Logins such as sync.

       -m     Ignores checking for mail port.

       -s     xx number of seconds max to wait.

       -r     Ignores Checking for RPC calls.

       -y     Try to get pw via Ypx.

       -v     Ignores finding Mail  Aliases  for  decode,  guest,
              bbs, lp.

       -p     Scans one Host for all open TCP ports (disables all
              other options).

       -q     Turns off Quick Scan so it finds hosts even with no
              name.

       -e     Only logs directories that can be mounted by every-
              one.

       -f     Ignores Checking FTP port for logging in as  anony-
              mous.

       -o     Changes logfile to something besides ISS.log.

       #1  and #2 are the beginning and end of the domain address
       to scan.

       ISS will scan a domain sequentially  looking  for  connec-
       tions.   When  it  finds  a host it will try to connect to
       various ports.  For starters, it tries  the  telnet  port.
       When  it connects to the telnet port, it logs any informa-
       tion that the host displays.

       With the -d option, ISS ignores trying  default  accounts.
       By default, ISS will then try to log in as 'sync' which is
       a common account name for SunOS and other Unixes.   It  in
       itself  is  not a big hole other than giving more informa-
       tion about type of OS, version number of OS, and  display-
       ing  the  MOTD.   But 'sync' with no password can become a
       security hole as someone with a regular  account  on  that
       host  can  divert  the  'sync'  privileges  and ultimately
       become root.  The 'sync' account should be  passworded  or
       disabled.

       With the -m option, ISS ignores the mail port. By default,
       ISS tries the  mail  port.  Connecting  to  this  provides
       information  regarding the hostname, type of OS it is, and
       even the version number of sendmail.

       With the -v option, ISS wont check for  mail  aliases.  By
       default, it will check for various users and aliases.  The
       obvious aliases to search  for  is  decode  and  uudecode.
       With   these  aliases,  you  are  able  to  send  mail  to
       decode@hostname with a file that  has  been  uuencoded  to
       overwrite  a  systems  file, such as .rhosts.  Some of the
       users it looks for is  'bbs','guest','lp',  and  the  well
       known   debug   and   wiz   backdoors   within   sendmail.
       'bbs','guest', and 'lp' are known to have  weak  passwords
       or no passwords at all.

       With  the  -f  option,  ISS  wont  check  the FTP port. By
       default, it will connect to the ftp port and check to  see
       if  a person can log into anonymous.  Many systems such as
       Macs let anyone log in and look around other  users'  pri-
       vate information.  If it succeeds logging in as anonymous,
       it will then attempt to create a directory.   If  it  does
       that  successfully,  the main directory of the FTP site is
       writeable and open to attack.  Many  anonymous  ftp  sites
       have  security  holes.   Such  weaknesses is being able to
       write to the main directory of the ftp directory, thus  an
       intruder  could  write  a  .rhost  file and log in as ftp.
       Plus, the anonymous ftp site may contain the actual host's
       password file and not just a dummy password file.

       With  the  -r  option,  ISS  ignores  checking for rpc. By
       default, ISS will look for holes  that  most  systems  are
       more  prone to have open.  It uses rpc information to find
       security weaknesses.  It will do a 'rpcinfo -p  hostname'.
       With  this  information  gained,  it finds which hosts are
       running NIS, rexd, bootparam, whose on  the  host,  selec-
       tion_svc, and NFS.

       If  a  system  shows  YPServ, it is likely that it has not
       been patched yet and with the  proper  domainname,  ypserv
       will  provide  the password file to any remote host asking
       for it.  To fix this, apply the proper ypserv  patch  from
       your vendor.  ISS will attempt to guess the domainname and
       that will provide information as to which machine  is  the
       NIS  server  is.    The domainname should be changed if it
       can easily be guessed so that it  will  slow  people  from
       grabbing  the  password file.  Another attempt to fix this
       problem is to make sure that if the password file does get
       out,  none  of the passwords can easily be cracked.  Crack
       (by Alec Muffett alecm@sun.com) does a fine job of finding
       weak passwords. Also shadowing the password file will help
       correct this weakness.

       With the -y option and a program called Ypx (by Rob  Nautu
       rob@wzv.win.tue.nl),  ISS  will  try  to grab the password
       file from ypserv.

       If a system shows Select_svr, selection_svr is running  on
       the  machine  and  there  are  known holes that let anyone
       remotely grab the password file.  Selection_svr should  be
       disabled.

       When  Rexd  is  running  on a remote system, anyone with a
       small C program can emulate the 'on' command spoofing  any
       user  on  the  remote  machine, thus gaining access to the
       password file and adding .rhosts  files.  Rexd  should  be
       disabled.

       If  a  machine is running Bootparam, it is likely a server
       to diskless clients.  One problem with bootparam  is  that
       if  it is running and someone can guess which machines the
       client and servers are, they are able to get  the  domain-
       name  from  bootparam, which goes back to the YPServ prob-
       lem.

       The -e option will only  log  exports  that  everyone  can
       mount.   To  usually  find  out  which  machines  are  its
       clients, by default, log all the  exportable  directories.
       'showmount  -e  hostname'  shows  the  exports on a remote
       host.  If the exported directories look like:

                   /usr              (everyone)
                   /export/placebo    placebo
                   /export/spiff      spiff

       Anyone can mount /usr and possible replace  files  and  do
       other  damage.   Placebo and spiff appear to be clients to
       this server.

       ISS also does a 'rusers -l hostname' searching  for  users
       on  the system.  That provides how busy is the machine and
       possible login entries to try.

       ISS with option -p will support scanning all the ports  on
       a  certain host, thus looking for possible access entries,
       such as gophers, muds, and other applications ran by local
       users.  This has not been implemented yet.

       ISS  will quickly scan the domain. It does not try to con-
       nect to every address, but rather scans  through  doing  a
       name  lookup  for each address.  And if that address has a
       name, it will then do a more thorough lookup  of  informa-
       tion on that host. With the -q option, it will try to con-
       nect to hosts even without names.

       To sum it up, ISS will scan a  domain  grabbing  essential
       information  for administrators to easily sort through and
       give him a chance to secure the open machines on his  net-
       work.


ACKNOWLEDGEMENTS
       I would like to thank the following people for ideas, sug-
       gestions, and help: Scott Miles, Dan Farmer,  Wietse  Ven-
       ema, Alec Muffett, Scott Yelich, Darren Reed, and Tim New-
       sham.


ENHANCEMENTS
       Please send suggestions to
                              cklaus@hotsun.nersc.gov
                                       or
                              coup@gnu.ai.mit.edu.

COPYRIGHT
       Copyright (c) Christopher Klaus, 1992, 1993.  (cklaus@hot-
       sun.nersc.gov or coup@gnu.ai.mit.edu)


BUGS
       May not be ready to compile on machines beside SunOs.



                                                           ISS(1)

Interix / SUAHosted at SUA Community for Interix, SUA and SFUInterix / SUA