home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit v2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Improving-Security / security.txt < prev    next >
Text File  |  1999-11-04  |  15KB  |  423 lines
  1.                         ######    ##   ##    ######
  2.                         ##        ###  ##      ##
  3.                         ######    ## # ##      ##
  4.                             ##    ##  ###      ##
  5.                         ###### .  ##   ## .  ######.
  6.  
  7.                             Secure Networks Inc.
  8.  
  9.                              Security Advisory
  10.                              February 10, 1997
  11.  
  12.                         A simple TCP spoofing attack
  13.  
  14.  
  15. Over the past few years TCP sequence number prediction attacks have become a
  16. real threat against unprotected networks, taking advantage of the inherent
  17. trust relationships present in many network installations.  TCP sequence
  18. number prediction attacks have most commonly been implemented by opening a
  19. series of connections to the target host, and attempting to predict the
  20. sequence number which will be used next.  Many operating systems have
  21. therefore attempted to solve this problem by implementing a method of
  22. generating sequence numbers in unpredictable fashions.  This method does
  23. not solve the problem.
  24.  
  25. This advisory introduces an alternative method of obtaining the initial
  26. sequence number from some common trusted services.  The attack presented here
  27. does not require the attacker to open multiple connections, or flood a port
  28. on the trusted host to complete the attack.  The only requirement is that
  29. source routed packets can be injected into the target network with fake
  30. source addresses.
  31.  
  32. This advisory assumes that the reader already has an understanding of how
  33. TCP sequence number prediction attacks are implemented.
  34.  
  35. The impact of this advisory is greatly diminished due to the large number of
  36. organizations which block source routed packets and packets with addresses
  37. inside of their networks.  Therefore we present the information as more of
  38. a 'heads up' message for the technically inclined, and to re-iterate that
  39. the randomization of TCP sequence numbers is not an effective solution
  40. against this attack.
  41.  
  42.  
  43. Technical Details
  44. ~~~~~~~~~~~~~~~~~
  45.  
  46. The problem occurs when particular network daemons accept connections
  47. with source routing enabled, and proceed to disable any source routing
  48. options on the connection.  The connection is allowed to continue, however
  49. the reverse route is no longer used.  An example attack can launched against
  50. the in.rshd daemon, which on most systems will retrieve the socket options
  51. via getsockopt() and then turn off any dangerous options via setsockopt().
  52.  
  53. An example attack follows.
  54.  
  55. Host A is the trusted host
  56. Host B is the target host
  57. Host C is the attacker
  58.  
  59. Host C initiates a source routed connection to in.rshd on host B, pretending
  60. to be host A.
  61.  
  62. Host C spoofing Host A         <SYN>    -->  Host B in.rshd
  63.  
  64. Host B receives the initial SYN packet, creates a new PCB (protocol
  65. control block) and associates the route with the PCB.  Host B responds,
  66. using the reverse route, sending back a SYN/ACK with the sequence number.
  67.  
  68. Host C spoofing Host A  <--  <SYN/ACK>       Host B in.rshd
  69.  
  70. Host C responds, still spoofing host A, acknowledging the sequence number.
  71. Source routing options are not required on this packet.
  72.  
  73. Host C spoofing Host A         <ACK>    -->  Host B in.rshd
  74.  
  75. We now have an established connection, the accept() call completes, and
  76. control is now passed to the in.rshd daemon.  The daemon now does IP
  77. options checking and determines that we have initiated a source routed
  78. connection.  The daemon now turns off this option, and any packets sent
  79. thereafter will be sent to the real host A, no longer using the reverse
  80. route which we have specified.  Normally this would be safe, however the
  81. attacking host now knows what the next sequence number will be.  Knowing
  82. this sequence number, we can now send a spoofed packet without the source
  83. routing options enabled, pretending to originate from Host A, and our
  84. command will be executed.
  85.  
  86. In some conditions the flooding of a port on the real host A is required
  87. if larger ammounts of data are sent, to prevent the real host A from
  88. responding with an RST.  This is not required in most cases when performing
  89. this attack against in.rshd due to the small ammount of data transmitted.
  90.  
  91. It should be noted that the sequence number is obtained before accept()
  92. has returned and that this cannot be prevented without turning off source
  93. routing in the kernel.
  94.  
  95. As a side note, we're very lucky that TCP only associates a source route with
  96. a PCB when the initial SYN is received.  If it accepted and changed the ip
  97. options at any point during a connection, more exotic attacks may be possible.
  98. These could include hijacking connections across the internet without playing
  99. a man in the middle attack and being able to bypass IP options checking
  100. imposed by daemons using getsockopt().  Luckily *BSD based TCP/IP stacks will
  101. not do this, however it would be interesting to examine other implementations.
  102.  
  103. Impact
  104. ~~~~~~
  105.  
  106. The impact of this attack is similar to the more complex TCP sequence
  107. number prediction attack, yet it involves fewer steps, and does not require
  108. us to 'guess' the sequence number.  This allows an attacker to execute
  109. arbitrary commands as root, depending on the configuration of the target
  110. system.  It is required that trust is present here, as an example, the use
  111. of .rhosts or hosts.equiv files.
  112.  
  113.  
  114. Solutions
  115. ~~~~~~~~~
  116.  
  117. The ideal solution to this problem is to have any services which rely on
  118. IP based authentication drop the connection completely when initially
  119. detecting that source routed options are present.  Network administrators
  120. and users can take precautions to prevent users outside of their network
  121. from taking advantage of this problem.  The solutions are hopefully already
  122. either implemented or being implemented.
  123.  
  124. 1. Block any source routed connections into your networks
  125. 2. Block any packets with internal based address from entering your network.
  126.  
  127. Network administrators should be aware that these attacks can easily be
  128. launched from behind filtering routers and firewalls.  Internet service
  129. providers and corporations should ensure that internal users cannot launch
  130. the described attacks.  The precautions suggested above should be implemented
  131. to protect internal networks.
  132.  
  133. Example code to correctly process source routed packets is presented here
  134. as an example.  Please let us know if there are any problems with it.
  135. This code has been tested on BSD based operating systems.
  136.  
  137.         u_char optbuf[BUFSIZ/3];
  138.         int optsize = sizeof(optbuf), ipproto, i;
  139.         struct protoent *ip;
  140.  
  141.         if ((ip = getprotobyname("ip")) != NULL)
  142.                 ipproto = ip->p_proto;
  143.         else
  144.                 ipproto = IPPROTO_IP;
  145.         if (!getsockopt(0, ipproto, IP_OPTIONS, (char *)optbuf, &optsize) &&
  146.             optsize != 0) {
  147.                 for (i = 0; i < optsize; ) {
  148.                         u_char c = optbuf[i];
  149.                         if (c == IPOPT_LSRR || c == IPOPT_SSRR)
  150.                                 exit(1);
  151.                         if (c == IPOPT_EOL)
  152.                                 break;
  153.                         i += (c == IPOPT_NOP) ? 1 : optbuf[i+1];
  154.                 }
  155.         }
  156.  
  157.  
  158. One critical concern is in the case where TCP wrappers are being used.  If
  159. a user is relying on TCP wrappers, the above fix should be incorporated into
  160. fix_options.c.  The problem being that TCP wrappers itself does not close
  161. the connection, however removes the options via setsockopt().  In this case
  162. when control is passed to in.rshd, it will never see any options present,
  163. and the connection will remain open (even if in.rshd has the above patch
  164. incorporated).  An option to completely drop source routed connections will
  165. hopefully be provided in the next release of TCP wrappers.  The other option
  166. is to undefine KILL_IP_OPTIONS, which appears to be undefined by default.
  167. This passes through IP options and allows the called daemon to handle them
  168. accordingly.
  169.  
  170.  
  171. Disabling Source Routing
  172. ~~~~~~~~~~~~~~~~~~~~~~~~
  173.  
  174. We believe the following information to be accurate, however it is not
  175. guaranteed.
  176.  
  177. --- Cisco
  178.  
  179. To have the router discard any datagram containing an IP source route option
  180. issue the following command:
  181.  
  182. no ip source-route
  183.  
  184. This is a global configuration option.
  185.  
  186.  
  187. --- NetBSD
  188.  
  189. Versions of NetBSD prior to 1.2 did not provide the capability for disabling
  190. source routing.  Other versions ship with source routing ENABLED by default.
  191. We do not know of a way to prevent NetBSD from accepting source routed packets.
  192. NetBSD systems, however, can be configured to prevent the forwarding of packets
  193. when acting as a gateway.
  194.  
  195. To determine whether forwarding of source routed packets is enabled,
  196. issue the following command:
  197.  
  198. # sysctl net.inet.ip.forwarding
  199. # sysctl net.inet.ip.forwsrcrt
  200.  
  201. The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.
  202.  
  203. Forwarding of source routed packets can be turned off via:
  204.  
  205. # sysctl -w net.inet.ip.forwsrcrt=0
  206.  
  207. Forwarding of all packets in general can turned off via:
  208.  
  209. # sysctl -w net.inet.ip.forwarding=0
  210.  
  211.  
  212. --- BSD/OS
  213.  
  214. BSDI has made a patch availible for rshd, rlogind, tcpd and nfsd.  This
  215. patch is availible at:
  216.  
  217. ftp://ftp.bsdi.com/bsdi/patches/patches-2.1
  218.  
  219. OR via their patches email server <patches@bsdi.com>
  220.  
  221. The patch number is
  222. U210-037 (normal version)
  223. D210-037 (domestic version for sites running kerberized version)
  224.  
  225.  
  226. BSD/OS 2.1 has source routing disabled by default
  227.  
  228. Previous versions ship with source routing ENABLED by default.  As far as
  229. we know, BSD/OS cannot be configured to drop source routed packets destined
  230. for itself, however can be configured to prevent the forwarding of such
  231. packets when acting as a gateway.
  232.  
  233. To determine whether forwarding of source routed packets is enabled,
  234. issue the following command:
  235.  
  236. # sysctl net.inet.ip.forwarding
  237. # sysctl net.inet.ip.forwsrcrt
  238.  
  239. The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.
  240.  
  241. Forwarding of source routed packets can be turned off via:
  242.  
  243. # sysctl -w net.inet.ip.forwsrcrt=0
  244.  
  245. Forwarding of all packets in general can turned off via:
  246.  
  247. # sysctl -w net.inet.ip.forwarding=0
  248.  
  249.  
  250. --- OpenBSD
  251.  
  252. Ships with source routing turned off by default.  To determine whether source
  253. routing is enabled, the following command can be issued:
  254.  
  255. # sysctl net.inet.ip.sourceroute
  256.  
  257. The response will be either 0 or 1, 0 meaning that source routing is off,
  258. and 1 meaning it is on.  If source routing has been turned on, turn off via:
  259.  
  260. # sysctl -w net.inet.ip.sourceroute=0
  261.  
  262. This will prevent OpenBSD from forwarding and accepting any source routed
  263. packets.
  264.  
  265.  
  266. --- FreeBSD
  267.  
  268. Ships with source routing turned off by default.  To determine whether source
  269. routing is enabled, the following command can be issued:
  270.  
  271. # sysctl net.inet.ip.sourceroute
  272.  
  273. The response will be either 0 or 1, 0 meaning that source routing is off,
  274. and 1 meaning it is on.  If source routing has been turned on, turn off via:
  275.  
  276. # sysctl -w net.inet.ip.sourceroute=0
  277.  
  278.  
  279. --- Linux
  280.  
  281. Linux by default has source routing disabled in the kernel.
  282.  
  283.  
  284. --- Solaris 2.x
  285.  
  286. Ships with source routing enabled by default.  Solaris 2.5.1 is one of the
  287. few commercial operating systems that does have unpredictable sequence
  288. numbers, which does not help in this attack.
  289.  
  290. We know of no method to prevent Solaris from accepting source routed
  291. connections, however, Solaris systems acting as gateways can be prevented
  292. from forwarding any source routed packets via the following commands:
  293.  
  294. # ndd -set /dev/ip ip_forward_src_routed 0
  295.  
  296. You can prevent forwarding of all packets via:
  297.  
  298. # ndd -set /dev/ip ip_forwarding 0
  299.  
  300. These commands can be added to /etc/rc2.d/S69inet to take effect at bootup.
  301.  
  302.  
  303. --- SunOS 4.x
  304.  
  305. We know of no method to prevent SunOS from accepting source routed
  306. connections, however a patch is availible to prevent SunOS systems from
  307. forwarding source routed packets.
  308.  
  309. This patch is availible at:
  310.  
  311. ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gz
  312.  
  313. To configure SunOS to prevent forwarding of all packets, the following
  314. command can be issued:
  315.  
  316. # echo "ip_forwarding/w 0" | adb -k -w /vmunix /dev/mem
  317. # echo "ip_forwarding?w 0" | adb -k -w /vmunix /dev/mem
  318.  
  319. The first command turns off packet forwarding in /dev/mem, the second in
  320. /vmunix.
  321.  
  322.  
  323. --- HP-UX
  324.  
  325. HP-UX does not appear to have options for configuring an HP-UX system to
  326. prevent accepting or forwarding of source routed packets.  HP-UX has IP
  327. forwarding turned on by default and should be turned off if acting as a
  328. firewall.  To determine whether IP forwarding is currently on, the following
  329. command can be issued:
  330.  
  331. # adb /hp-ux
  332. ipforwarding?X      <- user input
  333. ipforwarding:
  334. ipforwarding: 1
  335. #
  336.  
  337. A response of 1 indicates IP forwarding is ON, 0 indicates off.  HP-UX can
  338. be configured to prevent the forwarding of any packets via the following
  339. commands:
  340.  
  341. # adb -w /hp-ux /dev/kmem
  342. ipforwarding/W 0
  343. ipforwarding?W 0
  344. ^D
  345. #
  346.  
  347. --- AIX
  348.  
  349. AIX cannot be configured to discard source routed packets destined for itself,
  350. however can be configured to prevent the forwarding of source routed packets.
  351. IP forwarding and forwarding of source routed packets specifically can be
  352. turned off under AIX via the following commands:
  353.  
  354. To turn off forwarding of all packets:
  355.  
  356. # /usr/sbin/no -o ipforwarding=0
  357.  
  358. To turn off forwarding of source routed packets:
  359.  
  360. # /usr/sbin/no -o nonlocsrcroute=0
  361.  
  362. Note that these commands should be added to /etc/rc.net
  363.  
  364.  
  365.  
  366. If shutting off source routing is not possible and you are still using
  367. services which rely on IP address authentication, they should be disabled
  368. immediately (in.rshd, in.rlogind).  in.rlogind is safe if .rhosts and
  369. /etc/hosts.equiv are not used.
  370.  
  371.  
  372. Attributions
  373. ~~~~~~~~~~~~
  374.  
  375. Thanks to Niels Provos <provos@physnet.uni-hamburg.de> for providing
  376. the information and details of this attack.  You can view his web
  377. site at http://www.physnet.uni-hamburg.de/provos
  378.  
  379. Thanks to Theo de Raadt, the maintainer of OpenBSD for forwarding this
  380. information to us.  More information on OpenBSD can be found at
  381. http://www.openbsd.org
  382.  
  383. Thanks to Keith Bostic <bostic@bsdi.com> for discussion and a quick
  384. solution for BSD/OS.
  385.  
  386. Thanks to Brad Powell <brad.powell@west.sun.com> for providing information
  387. for Solaris 2.x and SunOS 4.x operating systems.
  388.  
  389. Thanks go to CERT and AUSCERT for recommendations in this advisory.
  390.  
  391. You can contact the author of this advisory at oliver@secnet.com
  392.  
  393. Type Bits/KeyID    Date       User ID
  394. pub  1024/0E7BBA7D 1996/09/18 Oliver Friedrichs <oliver@secnet.com>
  395.  
  396. -----BEGIN PGP PUBLIC KEY BLOCK-----
  397. Version: 2.6.3ia
  398.  
  399. mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1
  400. A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd
  401. Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR
  402. tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO
  403. fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8
  404. 45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU
  405. qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8=
  406. =xq4f
  407. -----END PGP PUBLIC KEY BLOCK-----
  408.  
  409. Copyright Notice
  410. ~~~~~~~~~~~~~~~~
  411. The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,
  412. and may be distributed freely provided that no fee is charged for
  413. distribution, and that proper credit is given.
  414.  
  415.  You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers
  416.  and advisories at ftp://ftp.secnet.com/advisories
  417.  
  418.  You can browse our web site at http://www.secnet.com
  419.  
  420.  You can subscribe to our security advisory mailing list by sending mail to
  421.  majordomo@secnet.com with the line "subscribe sni-advisories"
  422.  
  423.