A simple TCP spoofing attackOver the past few years TCP sequence number prediction attacks have become areal threat against unprotected networks, taking advantage of the inherenttrust relationships present in many network installations.  TCP sequencenumber prediction attacks have most commonly been implemented by opening aseries of connections to the target host, and attempting to predict thesequence number which will be used next.  Many operating systems havetherefore attempted to solve this problem by implementing a method ofgenerating sequence numbers in unpredictable fashions.  This method doesnot solve the problem.This advisory introduces an alternative method of obtaining the initialsequence number from some common trusted services.  The attack presented heredoes not require the attacker to open multiple connections, or flood a porton the trusted host to complete the attack.  The only requirement is thatsource routed packets can be injected into the target network with fakesource addresses.This advisory assumes that the reader already has an understanding of howTCP sequence number prediction attacks are implemented.The impact of this advisory is greatly diminished due to the large number oforganizations which block source routed packets and packets with addressesinside of their networks.  Therefore we present the information as more ofa 'heads up' message for the technically inclined, and to re-iterate thatthe randomization of TCP sequence numbers is not an effective solutionagainst this attack.Technical Details~~~~~~~~~~~~~~~~~The problem occurs when particular network daemons accept connectionswith source routing enabled, and proceed to disable any source routingoptions on the connection.  The connection is allowed to continue, howeverthe reverse route is no longer used.  An example attack can launched againstthe in.rshd daemon, which on most systems will retrieve the socket optionsvia getsockopt() and then turn off any dangerous options via setsockopt().An example attack follows.Host A is the trusted hostHost B is the target hostHost C is the attackerHost C initiates a source routed connection to in.rshd on host B, pretendingto be host A.Host C spoofing Host A         <SYN>    -->  Host B in.rshdHost B receives the initial SYN packet, creates a new PCB (protocolcontrol block) and associates the route with the PCB.  Host B responds,using the reverse route, sending back a SYN/ACK with the sequence number.Host C spoofing Host A  <--  <SYN/ACK>       Host B in.rshdHost C responds, still spoofing host A, acknowledging the sequence number.Source routing options are not required on this packet.Host C spoofing Host A         <ACK>    -->  Host B in.rshdWe now have an established connection, the accept() call completes, andcontrol is now passed to the in.rshd daemon.  The daemon now does IPoptions checking and determines that we have initiated a source routedconnection.  The daemon now turns off this option, and any packets sentthereafter will be sent to the real host A, no longer using the reverseroute which we have specified.  Normally this would be safe, however theattacking host now knows what the next sequence number will be.  Knowingthis sequence number, we can now send a spoofed packet without the sourcerouting options enabled, pretending to originate from Host A, and ourcommand will be executed.In some conditions the flooding of a port on the real host A is requiredif larger ammounts of data are sent, to prevent the real host A fromresponding with an RST.  This is not required in most cases when performingthis attack against in.rshd due to the small ammount of data transmitted.It should be noted that the sequence number is obtained before accept()has returned and that this cannot be prevented without turning off sourcerouting in the kernel.As a side note, we're very lucky that TCP only associates a source route witha PCB when the initial SYN is received.  If it accepted and changed the ipoptions at any point during a connection, more exotic attacks may be possible.These could include hijacking connections across the internet without playinga man in the middle attack and being able to bypass IP options checkingimposed by daemons using getsockopt().  Luckily *BSD based TCP/IP stacks willnot do this, however it would be interesting to examine other implementations.Impact~~~~~~The impact of this attack is similar to the more complex TCP sequencenumber prediction attack, yet it involves fewer steps, and does not requireus to 'guess' the sequence number.  This allows an attacker to executearbitrary commands as root, depending on the configuration of the targetsystem.  It is required that trust is present here, as an example, the useof .rhosts or hosts.equiv files.Solutions~~~~~~~~~The ideal solution to this problem is to have any services which rely onIP based authentication drop the connection completely when initiallydetecting that source routed options are present.  Network administratorsand users can take precautions to prevent users outside of their networkfrom taking advantage of this problem.  The solutions are hopefully alreadyeither implemented or being implemented.1. Block any source routed connections into your networks2. Block any packets with internal based address from entering your network.Network administrators should be aware that these attacks can easily belaunched from behind filtering routers and firewalls.  Internet serviceproviders and corporations should ensure that internal users cannot launchthe described attacks.  The precautions suggested above should be implementedto protect internal networks.Example code to correctly process source routed packets is presented hereas an example.  Please let us know if there are any problems with it.This code has been tested on BSD based operating systems.        u_char optbuf[BUFSIZ/3];        int optsize = sizeof(optbuf), ipproto, i;        struct protoent *ip;        if ((ip = getprotobyname("ip")) != NULL)                ipproto = ip->p_proto;        else                ipproto = IPPROTO_IP;        if (!getsockopt(0, ipproto, IP_OPTIONS, (char *)optbuf, &optsize) &&            optsize != 0) {                for (i = 0; i < optsize; ) {                        u_char c = optbuf[i];                        if (c == IPOPT_LSRR || c == IPOPT_SSRR)                                exit(1);                        if (c == IPOPT_EOL)                                break;                        i += (c == IPOPT_NOP) ? 1 : optbuf[i+1];                }        }One critical concern is in the case where TCP wrappers are being used.  Ifa user is relying on TCP wrappers, the above fix should be incorporated intofix_options.c.  The problem being that TCP wrappers itself does not closethe connection, however removes the options via setsockopt().  In this casewhen control is passed to in.rshd, it will never see any options present,and the connection will remain open (even if in.rshd has the above patchincorporated).  An option to completely drop source routed connections willhopefully be provided in the next release of TCP wrappers.  The other optionis to undefine KILL_IP_OPTIONS, which appears to be undefined by default.This passes through IP options and allows the called daemon to handle themaccordingly.Disabling Source Routing~~~~~~~~~~~~~~~~~~~~~~~~We believe the following information to be accurate, however it is notguaranteed.--- CiscoTo have the router discard any datagram containing an IP source route optionissue the following command:no ip source-routeThis is a global configuration option.--- NetBSDVersions of NetBSD prior to 1.2 did not provide the capability for disablingsource routing.  Other versions ship with source routing ENABLED by default.We do not know of a way to prevent NetBSD from accepting source routed packets.NetBSD systems, however, can be configured to prevent the forwarding of packetswhen acting as a gateway.To determine whether forwarding of source routed packets is enabled,issue the following command:# sysctl net.inet.ip.forwarding# sysctl net.inet.ip.forwsrcrtThe response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.Forwarding of source routed packets can be turned off via:# sysctl -w net.inet.ip.forwsrcrt=0Forwarding of all packets in general can turned off via:# sysctl -w net.inet.ip.forwarding=0--- BSD/OSBSDI has made a patch availible for rshd, rlogind, tcpd and nfsd.  Thispatch is availible at:ftp://ftp.bsdi.com/bsdi/patches/patches-2.1OR via their patches email server <patches@bsdi.com>The patch number isU210-037 (normal version)D210-037 (domestic version for sites running kerberized version)BSD/OS 2.1 has source routing disabled by defaultPrevious versions ship with source routing ENABLED by default.  As far aswe know, BSD/OS cannot be configured to drop source routed packets destinedfor itself, however can be configured to prevent the forwarding of suchpackets when acting as a gateway.To determine whether forwarding of source routed packets is enabled,issue the following command:# sysctl net.inet.ip.forwarding# sysctl net.inet.ip.forwsrcrtThe response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.Forwarding of source routed packets can be turned off via:# sysctl -w net.inet.ip.forwsrcrt=0Forwarding of all packets in general can turned off via:# sysctl -w net.inet.ip.forwarding=0--- OpenBSDShips with source routing turned off by default.  To determine whether sourcerouting is enabled, the following command can be issued:# sysctl net.inet.ip.sourcerouteThe response will be either 0 or 1, 0 meaning that source routing is off,and 1 meaning it is on.  If source routing has been turned on, turn off via:# sysctl -w net.inet.ip.sourceroute=0This will prevent OpenBSD from forwarding and accepting any source routedpackets.--- FreeBSDShips with source routing turned off by default.  To determine whether sourcerouting is enabled, the following command can be issued:# sysctl net.inet.ip.sourcerouteThe response will be either 0 or 1, 0 meaning that source routing is off,and 1 meaning it is on.  If source routing has been turned on, turn off via:# sysctl -w net.inet.ip.sourceroute=0--- LinuxLinux by default has source routing disabled in the kernel.--- Solaris 2.xShips with source routing enabled by default.  Solaris 2.5.1 is one of thefew commercial operating systems that does have unpredictable sequencenumbers, which does not help in this attack.We know of no method to prevent Solaris from accepting source routedconnections, however, Solaris systems acting as gateways can be preventedfrom forwarding any source routed packets via the following commands:# ndd -set /dev/ip ip_forward_src_routed 0You can prevent forwarding of all packets via:# ndd -set /dev/ip ip_forwarding 0These commands can be added to /etc/rc2.d/S69inet to take effect at bootup.--- SunOS 4.xWe know of no method to prevent SunOS from accepting source routedconnections, however a patch is availible to prevent SunOS systems fromforwarding source routed packets.This patch is availible at:ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gzTo configure SunOS to prevent forwarding of all packets, the followingcommand can be issued:# echo "ip_forwarding/w 0" | adb -k -w /vmunix /dev/mem# echo "ip_forwarding?w 0" | adb -k -w /vmunix /dev/memThe first command turns off packet forwarding in /dev/mem, the second in/vmunix.--- HP-UXHP-UX does not appear to have options for configuring an HP-UX system toprevent accepting or forwarding of source routed packets.  HP-UX has IPforwarding turned on by default and should be turned off if acting as afirewall.  To determine whether IP forwarding is currently on, the followingcommand can be issued:# adb /hp-uxipforwarding?X      <- user inputipforwarding:ipforwarding: 1#A response of 1 indicates IP forwarding is ON, 0 indicates off.  HP-UX canbe configured to prevent the forwarding of any packets via the followingcommands:# adb -w /hp-ux /dev/kmemipforwarding/W 0ipforwarding?W 0^D#--- AIXAIX cannot be configured to discard source routed packets destined for itself,however can be configured to prevent the forwarding of source routed packets.IP forwarding and forwarding of source routed packets specifically can beturned off under AIX via the following commands:To turn off forwarding of all packets:# /usr/sbin/no -o ipforwarding=0To turn off forwarding of source routed packets:# /usr/sbin/no -o nonlocsrcroute=0Note that these commands should be added to /etc/rc.netIf shutting off source routing is not possible and you are still usingservices which rely on IP address authentication, they should be disabledimmediately (in.rshd, in.rlogind).  in.rlogind is safe if .rhosts and/etc/hosts.equiv are not used.Attributions~~~~~~~~~~~~Thanks to Niels Provos <provos@physnet.uni-hamburg.de> for providingthe information and details of this attack.  You can view his website at http://www.physnet.uni-hamburg.de/provosThanks to Theo de Raadt, the maintainer of OpenBSD for forwarding thisinformation to us.  More information on OpenBSD can be found athttp://www.openbsd.orgThanks to Keith Bostic <bostic@bsdi.com> for discussion and a quicksolution for BSD/OS.Thanks to Brad Powell <brad.powell@west.sun.com> for providing informationfor Solaris 2.x and SunOS 4.x operating systems.Thanks go to CERT and AUSCERT for recommendations in this advisory.You can contact the author of this advisory at oliver@secnet.com-----BEGIN PGP PUBLIC KEY BLOCK-----Version: 2.6.3iamQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJdKd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAURtCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBOfR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe845SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgUqRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8==xq4f-----END PGP PUBLIC KEY BLOCK-----Copyright Notice~~~~~~~~~~~~~~~~The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,and may be distributed freely provided that no fee is charged fordistribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories"