[ Pobierz całość w formacie PDF ]
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;elseipproto = 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 routin... [ Pobierz całość w formacie PDF ]