Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

40 Internet Security Threats

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search
40 Internet Security Threats

                          David J. Stang, Ph.D.



With every passing day, we witness a huge increase in interest in Internet
access, sometimes called the "information highway". The public is now aware of
the Internet as a source of valuable information. We now have a glut of books on
how to use the Internet. There is a surge in the number of new Internet users,
new addresses, and sales of hardware and software to permit Internet access. 

We are also witnessing a general awakening to an understanding that there are
security problems that might result when connecting to the Internet. While the
public seems aware that such problems exist, very few people have any detailed
knowledge of what the problems are. Many now think they should buy a firewall
to prevent such problems. They think that firewalls are generic things, like
fire extinguishers, that probably all are about equally effective, and that with a
firewall installed, they will have dealt with the Internet security problems they
have heard of. 

Users are headed for trouble if they continue to believe this. There are a wide
variety of problems. Most firewalls don't stop a fraction of them. Firewalls
differ so widely in what they can do that they hardly deserve to be grouped
together under the same name. 

In this technical report, we will not tackle the entire problem of Internet
security. Rather, we will focus on a manageable set of issues: 

       What are the some of the security problems that can arise with an
       Internet connection? 
       What are the kinds of technology available that might help with such
       problems? 

Your internal network is potentially vulnerable to a wide variety of attacks
from the outside. Here are some examples, each of which you might ask your
firewall to defend you against. Most of the attacks are described in more detail in
Cheswick & Bellovin. We use published descriptions of attacks and provide
fairly little information about each, in an effort to minimize the "training" that
this report might provide to attackers. Our intent is to show the wide array of
mechanisms by which an attacker can get into your kitchen, living room, and
bedroom. Here is a short list of just 40 vulnerabilities: 

    1.Attacks via password guessing. Guessable passwords (such as
       "service" as a password for an account named "field", or the default
       passwords provided at installation time) can defeat nearly any system,
       and are the most common means by which a system is penetrated. A
       proper firewall should establish the non-guessability of all passwords
       used by the system it is protecting. It should also provide additional
       authentication mechanisms, such as authenticating both machine
       (Ethernet address, for instance) and user. It should also limit the
       number of login attempts, to prevent unlimited guessing. 
    2.Brute force password guessing Password guessing attacks on the
       encrypted password file (/etc/passwd) will normally succeed when the
       attacker uses a hacking tool such as CRACK and the file has a sufficient
       number of names in it. Some of these attacks can extract as many as
       25% of the passwords in the file, some of which will be useful in
       entering other systems. A good firewall protects the password file, and
       prevents its transmission or alteration. 
    3.Tapping terminal sessions Tapping terminal sessions is a
       technique in which the attacker merely monitors an active user,
       capturing their keystrokes and looking for a login to another system.
       Such attacks are possible with the default configuration of even
       "secure" versions of UNIX, such as OSF/1. 
    4.Keystroke capture of password via TSRKeystroke capture of
       password via TSR can be done with any number of hacker tools such as
       THIEF or GETIT or even Borland's SUPERKEY. With this attack, the
       hacker is likely to need to be able to later access the local drive to pick
       up the file containing the captured keystrokes. 
    5.A sequence number attack occurs when a hacker predicts the
       target's choice of starting points, places such an origin in the IP source
       address, and then engages any protocol that uses this address for
       authentication (such as the r commands in UNIX). A firewall might be
       expected to prevent such an attack by a more secure authentication of
       the source. 
    6.Spoofing UDP packets is easy for an attacker if your applications
       use the User Datagram Protocol to transmit information. UDP does not
       use handshaking or sequence numbers, and sends all packets for a given
       port to the same process, regardless of source address or port number.
       A firewall might be expected to independently verify the source of a
       UDP packet before processing it, even if the source is internal to the
       organization. 
    7.Tearing down ICMP connectionsTearing down ICMP connections.
       The Internet Control Message Protocol (ICMP) is a mechanism that
       informs hosts of better routing, terminates connections when network
       problems arise and can report routing troubles. Older versions ignore
       the connection-specific information of an ICMP message, and may
       redirect all connections between a pair of hosts, replacing the original
       connection with a new one. Hacking tools to tear down connections using
       this technique are available to the underground. 
    8.Redirecting ICMP connections ICMP messages can be redirected,
       establishing routing between a new pair of hosts. Many routers will
       respond to such instructions, though they should be set to do no such
       thing! A proper firewall design would respond to these instructions only
       when its own trusted router provides the request. 
    9.Loose Source Route option attacksLoose Source Route option
       attacks require that the hacker initiates a TCP connection, specifying an
       explicit path to the destination. When it sees that this procedure is
       being used, the destination uses the inverse of the path if the source is
       trusted (source becomes destination), conforming to RFC 1122. This
       permits any attacker to impersonate a trusted machine. Independent
       authentication by a proper firewall can defeat this approach. 
   10.Bogus Routing Information Protocol attacks insert additional
       RIP packets into a network. If the attacker is closer to the target than
       the original source, traffic is diverted to the attacker. In some
       implementations of RIP, there is no authentication field and no dialog
       between pairs of hosts to establish authenticity. In such a case, it is
       possible for the attacker to provide the host with a host-specific route,
       making this attack more difficult to detect. 
   11.Zone transfer attack. The Domain Name System (DNS) is a
       distributed database that maps host name and IP addresses. TCP queries
       by backup servers can produce zone transfers, in which a full copy of a
       portion of the name space is produced, so that the backup server can do
       its job. In a zone transfer attack, hackers can make similar
       requests of DNS, obtaining a list of potential target hosts and IP
       addresses. 
   12.Inverse mapping tree attack In many systems, the DNS permits
       subtrees to be stored on other servers. Because DNS maintains pairs of
       trees one mapping host names to addresses, and the other mapping
       addresses to names an attacker can modify an inverse record to show the
       name of a trusted host, the address of the attacker. Then, by using
       rlogin, the attacker may be able to convince your machine that it is a
       trusted host. A firewall might be able to prevent such an inverse
       mapping tree attack if it protected the DNS or performed more
       thorough authentication by checking IP addresses. 
   13.DNS cache attacks. In all but the most recent versions of DNS, it is
       possible to pre-contaminate the cache of DNS responses, then
       initiate the call. When the target checks the cache of valid responses, it
       then finds a name match and permits the attack. A firewall must use
       both name-based and address-based authentication, if it is to be trusted.
   14.DNS Resolver attacksDNS Resolver attacks exploit a weakness in
       DNS resolvers in which, to be more efficient, the resolver is willing to
       connect to destinations in which the match on domain names is
       incomplete. Thus a domain with a name in common with a name in a
       desired destination address might be able to intercept traffic intended
       for another destination. 
   15.SMTP overload attacks. The Simple Mail Transport Protocol
       (SMTP) provides a simple set of rules for transporting 7-bit
       messages. The protocol can be imitated easily, and because there is no
       authentication, messages can be entered manually by an attacker.
       Because an attacker can manually specify any source for the mail, it is
       possible for an attacker to overload the system with bogus messages,
       creating a denial of service attack. In such an attack, the mail
       system loses functionality, even if the host doesn't collapse under the
       weight of the bogus incoming messages. 
   16.Alias Expansion. SMTP permits aliases to be used when transmitting
       mail. But commands such as vrfy may translate mail aliases to login
       names, and expn expand mailing list aliases. A firewall should ensure
       that expansion of aliases to names is done inside the organization, to
       preserve the confidentiality of those who use the system. 
   17.sendmail attacks. sendmail is the most common means by which
       SMTP is implemented, and with thousands of lines of code, there are
       many bugs. Root is no place to run such a documentedly-dangerous
       program! sendmail need not run as root unless it is doing local delivery
       on gateway machines. Alternatives to sendmail are available, including
       potentially safer front-ends to it. 
   18.MIME header attacks. A mailer on a machine receiving mail that has
       been encoded with MIME (Multipurpose Internet Mail Extensions)
       might be expected to carry out the instructions in the header of the
       MIME message. Such instructions, if not carefully evaluated before
       execution, can overwrite .rhosts in the current directory and perform
       other forms of mischief. 
   19.Executables attached to mail. If the mail system can be entered by
       an attacker who can forge a message, then the attacker won't have
       difficulty attaching a program to the mail. The program can be designed
       to do anything the attacker wishes, and is likely to be successful with
       this Trojan if it appears to do something useful for the recipient. The
       Trojan, for instance, might seek to capture passwords as a TSR, or
       might merely contain a virus not detected by the recipient's virus
       scanner. Sometimes the Trojan is a "dropper" a program containing a
       virus. The program and virus are usually encrypted, to prevent a
       scanner from detecting the virus; when the program is run, the virus
       is released to infect files, or is placed in a sector, where it will execute
       with the next boot. Trojans and droppers do not require a deliberate
       attack, of course: they can be attached to E-mail by well-meaning
       senders who are unaware of the hidden contents of the program they
       send. 
   20.Attacks via corrupted telnet. telnet provides a user with terminal
       access. In an unsecure system, the telnet program can be compromised
       by an attacker to capture user name, password, or even the entire
       terminal session. Alternatively, if the attacker is not interested in what
       you are doing, but rather wishes to have the access offered by your
       account, the attacker's telnet replacement can simply keep the
       connection open after you think you've logged out. 
   21.Tapping the communications link. When any portion of a
       communications link is tapped, unencrypted passwords cannot be
       trusted. Often the easiest place to attack a communications link is a tap
       on its backbone. 
   22.NTP attacks. When an authentication service is time-sensitive, so
       that a different value for authentication is used at each different time,
       an attacker has an opportunity to capture what was used for
       authentication as well as the time of authentication, then attempt to
       instruct the host via the Network Time Protocol (NTP) to set the time
       back to the captured authentication string's valid time, then simply
       playback the captured authentication string. Such NTP attacks are not
       absolutely prevented by the latest versions of NTP. 
   23.finger attacks. The finger protocol provides information on users
       that is quite useful to attackers, including their name, electronic mail
       address, when the account was last used, where the user last connected
       from, idle periods, unread mail, etc. Attackers appreciate finger for its
       help in identifying relatively unused accounts and the match between
       names and mail addresses handy for password guessing. finger is a
       dangerous service, far less secure than whois. 
   24.Forging UNIX authentication fields in RPC headers. RPC
       (Sun's Remote Procedure Call) is a protocol that provides a designer
       with the means of creating a network service which can reach out and
       make subroutine calls to remote servers. Every RPC message has a
       header which can include authentication information. The information
       might be "null", for anonymous services, or might include "UNIX
       authentication" information, including the supposed numeric user id
       and group id of the caller and the name of the calling machine. All of the
       information in these fields can be readily forged by an attacker, and the
       RPC request can essentially ask for any service available on the host. 
   25.Portmapper denial of service attacks. Portmapper helps connect
       RPC clients and servers, and uses RPC for its work. One call supported
       by portmapper is to unregister a service. Because portmapper does not
       do much to authenticate such a request, portmapper denial of service
       attacks are straight-forward. 
   26.Portmapper reports to attackers via rpcinfo. Portmapper will
       also provide information on each service the server is running,
       including its protocol (e.g., UDP or TCP), its port number, and its
       version number. An attacker's work is easier after they obtain this
       information with rpcinfo. 
   27.Attacks using portmapper to hide source location. Use of RPC
       normally requires that a roundtrip of messages is required to
       determine the real port number of the client/source/attacker. To save
       this trip, portmapper permits the source to request that it transfer its
       request to the target server, carrying portmapper's own return
       address, rather than the actual source's. This ability makes legitimate
       local requests indistinguishable from those made by outside callers.
       While some versions of portmapper can do their own filtering, many
       cannot. 
   28.NIS attacks which obtain the password file, host address
       table, or public and private key databases. Network
       Information Services (NIS, formerly known as YP or Yellow Pages) is a
       service that distributes many important databases from a central
       server to its clients. Such databases include the password file, the host
       address table, and public and private key databases used for Secure RPC.
       This attack instructs NIS to transfer one or more of these key files to
       the attacker. 
   29.Attacks impersonating NIS backup servers NIS clients can be
       told to use a different NIS server, should it go down; the replacement
       server can be fraudulent, and supply false /etc/passwd file entries,
       false host addresses, etc. 
   30.RPC attacks on the NIS shadow password file. A shadow
       password file is a hidden copy of the password file which holds the
       actual, unencrypted passwords. An attacker is unlikely to be able to
       access this file directory, but can make repeated requests for RPC
       services using a variety of passwords. Applications check this file for
       the password, and report back to the attacker whether the password is
       valid. RPC does not log flurries of requests for passwords. 
   31.Attacks using NFS root file handles. To mount a volume for a
       client, a server running NFS (Network File System) the RPC mount
       daemon at the NFS server asks the client for name and requested file
       system, examines an administrator-supplied list, and if the client is on
       the list, sends the client the file handle for the root directory. The
       client maintains this file handle, and uses it in subsequent requests. If
       the client keeps the handle (e.g., records it for later use) the client has
       permanent access to that root. Root file handles can be shared, and once
       a user is given a root file handle, there is no mechanism for later taking
       it back. Considering the many problems that can occur in managing NFS,
       secure alternatives such as the Andrew File System (AFS) should be
       considered. AFS uses Kerberos for its authentication and provides a
       single scalable, global, location-independent file system. Files can
       reside anywhere in the network, with caching occurring transparently. 
   32.Attacks via tftp. The Trivial File Transport Protocol is a UDP-based
       file transfer mechanism which does not support authentication at all. If
       tftp is not restricted to just one or two directories, then attacks on the
       password file are simple. 
   33.Attacks using anonymous ftp. FTP (File Transfer Protocol) is a
       program and file distribution system that rivals e-mail for importance
       on the Internet. Anonymous ftp permits any caller to transfer files
       from a restricted area of the host without providing any further
       authorization. If ftp is set up so that a file or directory in the
       anonymous ftp area is writable or owned by the ftp login, then an
       attacker can use ftp to write a file named .rhosts to ftp's home
       directory, then use that file to authorize an rsh connection to the target
       machine as ftp. From there, the attacker proceeds to transfer files. 
   34.Anonymous ftp captures of /etc/passwd/etc/passwd. If you
       happen to leave the /etc/passwd file in an area reachable by anonymous
       ftp, assume a visitor will help themselves to a copy. 
   35.Undesirable files placed in the publicly writable
       anonymous ftp directory. If you have an area where anonymous ftp
       callers can place files, you should assume that this area will sooner or
       later hold copies of pirated, pornographic, slanderous, or
       virus-infected files. Such files may be placed their for your own
       amusement, for the "benefit" of those within your organization, or
       simply for others witting or unwitting to come and collect. 
   36.Denial of service by filling the publicly writable
       anonymous ftp. If a caller can place files on your system
       anonymously, it may be a matter of time before some caller places an
       expanding file there that fills the available space. Such a project will
       potentially disable any audit trail, slow other processes (or down the
       system), and, at a minimum, deny additional callers write-access to
       this directory. 
   37.Anonymous ftp attacks by replacement of commands within
       the ftp area. Any program such as ls which resides in the ftp area can
       be potentially replaced by an attacker, subsequently resulting in
       unexpected and undesired results. 
   38.Attacks with rlogin. rlogin permits login to a remote machine
       without a password if a few simple conditions are met: the caller must
       be listed in the destination's lists of trusted callers (such as
       /etc/hosts.equiv or $HOME/.rhosts), the caller must come through a
       privileged TCP port, and usually the caller's name must correspond to
       the caller's IP address. Both users and hackers like rlogin. Users like it
       because it does not require password entry, permits them to access
       other remote machines by simply adding them to the user's personal
       .rhosts file, and seems to work fine. Attackers like it because all they
       need to do is drop a file listing them as authorized in /etc/hosts.equiv,
       /usr/spool/uucppublic, /usr/ftp, etc. After they have gotten in with
       rlogin, they can capture lists of other trusting machines from
       /etc/hosts.equiv and other files, and from there explore many other
       machines. 
   39.Attack X11 servers. X11 is the most popular windowing system on
       the Internet. The system treats the user of it as a server, and permits
       applications to interact with it. An application is able to track
       keystrokes, capture screens, simulate keystrokes, etc. The main
       protection of most X11 servers is that they only permit certain
       machines to make requests of them. X11 servers are typically not
       notified of denied access requests, nor can they verify what process is
       using them. Attackers anywhere on the Internet can find and control all
       unprotected X11 servers. 
   40.Tunneling and encapsulation. If you run a firewall that only
       permits certain protocols, other protocols will be able to pass through
       if they are encapsulated within approved protocols, unless you examine
       the contents of each packet before it is permitted to pass through the
       firewall. Once a tunnel has been constructed between a "mole" inside
       your organization and a party outside your organization, bidirectional
       tunnel traffic will not be impaired by your firewall. 

                                                               
                 Last Revised Wednesday April 16, 1997.
   Please direct questions or problems regarding this web site to our Webmaster.
      Š 1997 Seven Locks Software, Inc. All rights reserved. Legal Notices.